Fehler mit doppelten / verschwundenen Artikeln

[stese]

Version 4.5.3 vom 9.9.

problem: von heute auf morgen zeigt er mir den eben neu erstellten artikel gleich 3x in einer kategorie an. Des weiteren verschwinden scheinbar wahllos irgendwelche Artikel aus vereinzelten Kategorie.

zur besseren Veranschaulichung ein Screen:


Es wurde nur ein Testartikel angelegt. Dieser erscheint allerdings 3x in der Übersicht. Die Datenbank con_cat_art beinhaltet nur einen Eintrag zu dieser Artikel-ID in der Kategorie. Welche Datenbank-Tabelle ist von der Darstellung betroffen? Ich nehme an, es hat nur eine Tabelle zerhauen, so dass hier eine fehlerhafte Anzeige auftritt. Die betroffenen Artikel werden auch nicht mehr im Frontend korrekt gefunden, wenn diese verschwunden sind, statt dessen wird eine Fehlermeldung angezeigt.

[NACHTRAG] Es hat die Tabelle art_lang erwischt - dort habe ich verschiedene Datensätze mit der gleichen idart, allerdings einer unterschiedlich hohen idartlang - wieso es das macht weiss ich allerdings noch nicht. fakt ist, er hat mir auf einmal in der Artikeleigenschafts-Ansicht auf einmal MultiKategorie-Artikel angezeigt (also Artikel die in mehreren Kategorien vorhanden sein können) obwohl, das in der 4.5. gar nicht mehr möglich ist

[NACHTRAG2] der erste nachtrag scheint wohl durch manipulationen meinerseits um das problem im contenido zu lösen ausgelöst worden zu sein. im ursprungs datenbank dump habe ich in der tabelle con_art doppelte artikel mit gleich lautender idart stehen, in der con_art_lang hingegen sind die datensätze zu diesem zeitpunkt noch unique, allerdings liegen in der con_cat_art unterschiedliche datensätze vor mit den identischen idarts in unterschiedlichen idcat - also scheinbar wurde es irgendwie ausser kraft gesetzt, dass man jeden artikel nur in einer kategorie ablegen darf. also es läuft wieder wie in der 4.4.4. obwohl diese version niemals auf dem server hier lief, kein update davon geschehen ist etc

[stese]

so ich glaube ich habe den Fehler entdeckt: die con_sequence beinhaltet in verschieden datensätzen die falschen werte - er hat sich also verzählt, und zwar ist er zu tief gegangen - z.b. con_art hat die letzte idart = 178 in der con_sequence steht bei con_art die 44 drinnen - irgendwie ist die tabelle vollkommen durcheinander geraten.

[stese]

hat sich erledigt - es hat bei einem db dump einen falschen eintrag
aus der con_sequence hergenommen, da nach dem dump und
serverumzug ein neuer tabellenprefix genommen wurde.

nun ist folgendes aufgetreten: in der con_sequence stehen
alle tabellen der datenbank! nun ist der riesen fehler passiert,
dass in dieser datenbank zwei unterschiedliche contenido
versionen liefen (eine testversion) und eine normale arbeitsversion
mit unterschiedlichen prefixen. der zufall spielte eben mit, das wir
ohne uns dessen bewusst zu sein, einen prefix genommen hatten,
der schon exisitent war. somit wurde nach dem serverwechsel nicht
die eigentlich zugehörigen datensatzstände genommen, sondern die
von unserem testsystem mit weit weniger artikeln.

große Bitte! Könntet ihr die DB Sequenz so umschreiben, dass in
dieser Tabelle NUR die wirklich zur aktuellen Contenido Version
gehörigen Tabellen stehen? Somit kann man fehler vorbeugen!
einfach nur die tabellen suchen, dessen prefix mit dem aus der
config übereinstimmt und das problem tritt nicht mehr auf. Danke!

[HerrB]

Aus verschiedenen Gründen wollten sie nicht:
http://www.contenido.org/forum/viewtopi ... 6846#36846

Gruß
HerrB

[timo]

Ähm jein, das sind ja verschiedene Probleme.

Das Updaten der Sequence funktioniert so:

- SHOW TABLES ausführen auf der aktuellen DB
- für jede gefundene Tabelle den Primary Key holen
- den jeweils höchsten Wert in die Tabelle schreiben

Ich glaube, der Fehler bei dir war, daß du nach dem Dump einspielen eben dieses Script nicht ausgeführt hast...

denn rein technisch gesehen müsstest du ja 2x eine sequence-Tabelle haben:

Einmal mit prefix1_sequence und einmal mit prefix2_sequence

Daß prefix1_sequence einträge aus den Tabelle von prefix2_ hat und umgekehrt ist nicht weiter tragisch, da die jeweils zu vielen Einträge nicht verwendet werden...

[stese]

ja so ähnlich - ich habe eine modifizierte setup routine, die mir schon bei der installation später die korrekten daten welche auf unserem projektserver erstellt wurden direkt mit installiert - heisst also normale setup routine mit dem ansatz, dass es nach dem erstellen der tabellenstruktur die inhalte gleich noch mit auffüllt. das hauptproblem bestand jetzt vor allem daran, dass in der con_sequence tabellen drinnen standen, die nicht zu dieser contenido version gehörten.

SHOW TABLES LIKE '" . $cfg["prefix"] . "_%"' damit wäre sichergestellt dass wirklich nur die zur contenido version zu gehörigen tabellen in der tabelle stehen. Hätte den Vorteil, dass man unnützen Datenballast vermeidet und es keine konflikte mehr geben kann die darauf hinauslaufen. Nachteile sollten sich eigentlich keine ergeben, denn ordentliche entwickler nutzen den gleichen Datenbankprefix auch für Ihre Module oder Plugins

nachtrag:
@timo ja genau das ist passiert. problem war halt nur, dass ich es nicht bemerkt hatte, dass dort wirklich alle tabellen drinn stehen - da wir auf unserem projektserver mitunter 5 oder 6 verschiedene contenido versionen am laufen haben (alle mit unterschiedlich modifizierten plugins etc) und nun gab es auch eine contenido version mit standard prefix, den der kunde dann auf seinem server genommen hat.

[timo]

Ich verstehe das Problem immer noch nicht...ich sagte ja bereits, daß zwar mehr Daten in beiden Sequence-Tabellen drinstehen, aber diese nicht verwendet werden.

In deinem Beispiel heißt das: Du machst ein Setup und schiebst innerhalb vom Setup irgendwelche Datenbankinformationen nach. Und da er über SHOW TABLES geht und die Primary Keys zieht, aktualisiert er doch auch jede Tabelle korrekt - denn zweimal dieselbe Tabelle mit demselben Namen kann es logischerweise nicht geben. Hast du 2 Contenido-Installationen, hast du auch 2x die sequence-Tabelle...oder sehe ich das falsch?

[timo]

nachtrag:
@timo ja genau das ist passiert. problem war halt nur, dass ich es nicht bemerkt hatte, dass dort wirklich alle tabellen drinn stehen - da wir auf unserem projektserver mitunter 5 oder 6 verschiedene contenido versionen am laufen haben (alle mit unterschiedlich modifizierten plugins etc) und nun gab es auch eine contenido version mit standard prefix, den der kunde dann auf seinem server genommen hat.

Also ich glaube immer noch, daß ihr entweder Daten eingespielt habt ohne die Sequence zu updaten oder nach dem Sequence-Update eine alte Version der con_sequence eingespielt habt. Beides wäre aber selbst mit deiner Modifikation oben schiefgelaufen? ...

[stese]

ja das ist absolut korrekt.

aber dass diese daten nicht verwendet werden traf in genau meinem beispiel nicht zu.
ich hatte also eine

con_art
con_art_lang
...
xyz_art
xyz_art_lang

die xyz_art war nun die korrekte mit den korrekten daternsatzzeigern, die con_art die einer anderen und älteren version. da ich das cms nicht selbst installieren konnte und dem kunden ein paket geben musste, wo er dies selbst tat, brauchte ich ein setup was die vorhandenen daten gleich mit einsetzt. nun geschah es aber dass der kunde nicht meinen prefix im setup genommen hatte sondern den standard-prefix, der widerum schon im dump definiert war - mit anderen werten des datensatzzeigers. somit hatte er das problem, dass contenido doch die anderen - ursprünglich nciht relevanten daten genommen hatte. es ändert auf jeden fall nichts an der tatsache, dass ich meine setup routine anpassen muss, wären allerdings nur die daten in der tabelle enthalten die direkt zu der contenido version gehören, hätte es (je nach arbeitsweise des setup und der funktion die die con sequence überwacht) a) entweder eine fehlermeldung gegeben oder b) die korrekten tabellen eingetragen und nicht die alten, weil falschen tabellen hergenommen. danach hat die funktion auch schön weiter hochgezählt, nur war der startwert ein falscher. so wurde der fehler erst sehr spät bemerkt.

ich fände es halt nur deutlich übersichtlicher wenn in dieser tabelle wirklich nur die tabellen ständen, die auch wirklich dazugehören.