# DAL-taugliche Tabelle OHNE UUID-Spalte?

**URL:** https://forum.shopware.com/t/dal-taugliche-tabelle-ohne-uuid-spalte/68867
**Category:** Programmierung
**Created:** [9. August 2020 um 13:53 UTC](https://forum.shopware.com/t/dal-taugliche-tabelle-ohne-uuid-spalte/68867 "2020-08-09T13:53:22Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![wolkenkrieger](https://avatars.discourse-cdn.com/v4/letter/w/85e7bf/32.png) [@wolkenkrieger](https://forum.shopware.com/u/wolkenkrieger)
#### Post date: [9. August 2020 um 13:53 UTC](https://forum.shopware.com/t/dal-taugliche-tabelle-ohne-uuid-spalte/68867/1 "2020-08-09T13:53:22Z")

</div>

Ich scheitere gerade daran, eine DAL-taugliche Tabelle zu definieren, deren primary key ganz klassisch ein Integer-Feld ist, das selber zwar unique aber nicht autoincrement ist 😑

Ich hab’s jetzt so:

```
return new FieldCollection([
	(new IntField('id', 'id'))->addFlags(new Required(), new PrimaryKey()), ...

```

Das Problem ist nun, dass ich kein create machen kann und stattdessen folgende Meldung bekomme

```
Expected primary key field id for definition [...] not provided

```

Der DAL-Validator auf der Konsole meldet 0 Fehler. Und selbstredend wird das id-Feld im Datenarray mit übergeben.

---

<div class="post-metadata">

### Author: ![wolkenkrieger](https://avatars.discourse-cdn.com/v4/letter/w/85e7bf/32.png) [@wolkenkrieger](https://forum.shopware.com/u/wolkenkrieger)
#### Post date: [10. August 2020 um 04:45 UTC](https://forum.shopware.com/t/dal-taugliche-tabelle-ohne-uuid-spalte/68867/2 "2020-08-10T04:45:55Z")

</div>

[Nachtrag]

Ich habe es jetzt (erstmal) mit einer “normalen” ID-Spalte gelöst. Das Problem daran ist, dass wir die Daten aus einer externen Quelle erhalten (CSV-Import im 5stelligen Zeilebereich!) und die o.g. Integer-Spalte der Dreh- und Angelpunkt der gesamten Datenlogik ist.

Ich muss jetzt also bei jedem einzelnen Datensatz vorher prüfen, ob diese ID schon vorhanden ist und wenn ja, dann die uuid dazu ermitteln … um dann das upsert zu machen (und ggf. vorher eine neue uuid generieren) … das ist Datenbanklast, die eigentlich nicht nötig wäre.

Wenn sich das einer vom Team mal angucken könnte, bitte? Ich kann mir nicht vorstellen, dass das grundsätzliche Konzept an der Stelle wirklich so unausgegoren ist?!
