Fortlaufende Nummern für Einträge im Backend

[Tim G]

Ich glaube nicht, dass das mit der ID funktioniert.
Die ID ist increment also immer +1, auch nach dem löschen eines Eintrages. Damit wird eine Eindeutigkeit geschaffen, auch für den Fall eines Rückgängigmachens.

Bei Artikeln, Seiten und Inhaltselmenten ist das das Gleiche.
Der erste Eintrag hat noch id=1, der zweite auch. Löscht man dann den zweiten und erstellt einen neuen zweiten, hat dieser die id=3.

Man muss auszählen.

Bitte um Korrektur falls der catalog da "klüger" ist

[MacKP]

Oha, ne stimmt. Da hast recht.. sorry.

Dann kommt man wirklich nicht um ein eigenen Feldtyp drum herum.

Viele Grüße

[Tim G]

Oha, ne stimmt. Da hast recht.. sorry.

Dann kommt man wirklich nicht um ein eigenen Feldtyp drum herum.

Viele Grüße

Ich befürchte nicht.

Das wäre optimalerweise ein Feldtyp, der nicht änderbar ist in den Einträgen, sondern nur in den Einstellungen zum Feld selbst.
Dort sollte man gleich noch ein Suffix, oder Prefix mit angeben können ala Rechnungsnummer und Kundennummer.

Dann könnte man die Mitarbeiterzahlen von anderen unterscheiden: z.b. mitarbeiter-01, mitarbeiter-02... aber eben nicht per ID, sondern real gezählt.

[jschma]

OK, also wenn ich es richtig verstanden habe geht es mit dem Catalog - wie er ist - nicht und man müsste eine kleine Extension für den Catalog beauftragen?

[Tim G]

Ich sehe keinen anderen Weg als Feldtyp, wie es MacKP bereits angesprochen hatte.

[jschma]

OK danke für das Feedback. Weißt Du zufällig an wen ich mich wenden könnte, wenn ich das gerne in Auftrag geben würde? Der Kreis der Verdächtigen dürfte vermutlich relativ gering sein, zumindest wenn es in die Tiefen des catalogs geht oder?

[Tim G]

Kannst mich fragen, MacKP, xtra, toflar. Da gibts schon einige.

[jschma]

Kannst mich fragen, MacKP, xtra, toflar. Da gibts schon einige.

OK Ich werde mich melden... aber erstmal muss ich meine anderen vermutlich bald anfallenden Problemchen zusammenschreiben

[Toflar]

Ich meld mich mal eben direkt hier, weil ich den Thread jetzt gelesen hab.

Lustigerweise habt ihr die Unterschiede zwischen der ID und der gewollten Zählung zwar aufgezeigt und seid dann zu einem eigenen Feldtypen gekommen.
Ich hab allerdings immer noch nicht verstanden, wieso die ID nicht genau das ist, was gesucht ist

Dies war die Aussage, weshalb ihr auf einen eigenen Feldtypen gekommen seid:

Der erste Eintrag hat noch id=1, der zweite auch. Löscht man dann den zweiten und erstellt einen neuen zweiten, hat dieser die id=3.

Die stimmt soweit. Aber was ist das anderes als die Anforderung:

Und was steht da, wenn du 3 angelegt hast, inzwischen 2 gelöscht hast? Steht dann da ne 4, oder ne 2? - das ist des Pudels Kern.

Na eine 4!

Äh, also von mir aus gesehen wäre das in dem Falle genau das was die ID macht?

Entscheidend ist eher folgendes Szenario:

Vorhandene Nummern in der Datenbank:

• 1
• 2
• 3
• 4

Ich entferne 3 & 4 und lege einen neuen Eintrag an. Kriegt der jetzt 5 (das wäre dann das Verhalten einer ID) oder 3 (die höchste verfügbare Nummer)?

Ersteres müsste problemlos jetzt schon möglich sein. Anpassen muss man daran ja nichts mit Feld berechnen und blabla - schliesslich soll es ja nur ausgegeben werden und nicht änderbar sein oder? Ansonsten macht das Teil ja keinen Sinn. Also einfach mal in der Listenansicht {{id}} verwenden und testen

Letzteres braucht einen eigenen Feldtypen, richtig.

[Tim G]

Nein, die ID zählt ja nicht die aktuelle Anzahl an Einträgen und darum geht es.

Du kannst 10 Einträge anlegen und diese dann löschen. Der nächste Eintrag hätte die ID 11, aber die Anzahl an Einträgen wäre 1. In SQL Sprache wäre das ein COUNT hier.

[jschma]

Naja ich selbst habe den Unterschied noch nicht 100% verstanden, aber ich muss das ja auch nicht programmieren können

Brauche ich denn die Anzahl? Also es ist tatsächlich so, dass es Mitarbeiternummern werden sollen...im Unternehmen werden alte MA-Nummern auch nicht von neuen MA eingenommen, da wäre ja die ganze Historie weg

[Tim G]

Dann sollten es doch die ID sein, weil die ist einzigartig.
So kommt es nie zu Überschneidungen mit vergangenen Nummern.

Ist die Zahl aus der Anzahl an Einträgen generiert kommt es natürlich permanent zu Überschneidungen. Immer wenn ein Eintrag gelöscht wird und ein neuer ergänzt wird. - wäre das für das System die gleiche Nummer.

Das geht ohne Erweiterung.

[jschma]

Dann sollten es doch die ID sein, weil die ist einzigartig.
So kommt es nie zu Überschneidungen mit vergangenen Nummern.

Ist die Zahl aus der Anzahl an Einträgen generiert kommt es natürlich permanent zu Überschneidungen. Immer wenn ein Eintrag gelöscht wird und ein neuer ergänzt wird. - wäre das für das System die gleiche Nummer.

Das geht ohne Erweiterung.

Hi Tim,

das sieht spitze aus und macht genau das was es soll Vielen Dank!
Eine Rückfrage habe ich noch: Ich importiere bestehende Daten via CSV, hier sind schon Werte bis 11020 verwendet. Kann man direkt in die DB die ID "Faken", das er eben erst bei 11021 anfängt zu zählen?

[Tim G]

Hi Tim,

das sieht spitze aus und macht genau das was es soll Vielen Dank!
Eine Rückfrage habe ich noch: Ich importiere bestehende Daten via CSV, hier sind schon Werte bis 11020 verwendet. Kann man direkt in die DB die ID "Faken", das er eben erst bei 11021 anfängt zu zählen?

Ja, du kannst beim Bearbeiten der Spalte den increment-Wert der ID auf 11020 setzen. Dann ist nächste Wert 11021.

[jschma]

Ja, du kannst beim Bearbeiten der Spalte den increment-Wert der ID auf 11020 setzen. Dann ist nächste Wert 11021.

OK dann such ich mit mal die DB-Tabelle vom entsprechenden Catalog durch, irgendwo wird das Feld schon sein