Doppeltes Anführungszeichen statt Leerstring

BugVerdacht ist jetzt ein großes Wort. Zumal mir das bei einem jungfräulich installierten Pendant logischer Weise selber Version nicht passiert, aber ich weiß nicht wo ich anfangen soll mit suchen.

Ich hab mir da nen CE 6.1.2 installiert.

Und beim Anlegen eines neuen Artikels schreibt mir der OXID in die folgenden Felder statt eines leeren Strings oder eines sinnvollen Wertes schlicht zwei einfache Anführungszeichen.
(Default Wert bei der MySQL-Tabelle kann ich ausschließen.)

Betroffen sind aus der oxarticles die Felder: OXPARENTID, OXUNITNAME, OXEXTURL, OXURLDESC, OXURLIMG, OXTHUMB, OXICON, OXPIC1, OXPIC2, OXPIC3, OXPIC4, OXPIC5, OXPIC6, OXPIC7, OXPIC8, OXPIC9, OXPIC10, OXPIC11, OXPIC12 OXSTOCKTEXT, OXNOSTOCKTEXT, OXFILE, OXTEMPLATE, OXQUESTIONEMAIL, OXVARNAME, OXVARSELECT, OXBUNDLEID, OXFOLDER, OXAMITEMID, OXDELTIMEUNIT

Ihr könnt euch ja vorstellen, dass Frontend wie Backend gerade nicht willens sind einen solchen Artikel zu zeigen.

Habt ihr mir eine Idee, wer mir hier den bescheuerten Defaultwert schreibt?
Merci!

Edit: Das scheint ne Art Kapselverhalten zu sein. Hab dem mal testweise 'nen Defaultwert mitgegeben auf der Datenbank und den Kapselt er jetzt auch in Anführungszeichen. Doof.

Jo, das nervt. ich nutze dafür so ein SQL hier: https://gist.github.com/Sioweb/0b229ecd6dfc4a7bb6a9fa1911d68e0f

Das markiert alle Felder als NULL(able) - allerdings habe ich nicht ausgibig getestet ob sich dadurch Probleme ergeben.

Edit: Soweit ich das sehe, wird dass durch Zeile 1332 in BaseModel ausgelöst.::quote liefert bei NULL lediglich zwei Quotes zurück.

2 Likes

Danke für die schnelle Antwort, Sioweb.

Nur leider gewöhnt das NULL-Erlauben ihm nicht das Kapseln ab.

… oh und das Hinterherupdaten will ich ja auch nicht jede Sekunde triggern.
Ich würde gerne näher an die Ursache ran.

Vielleicht bringt die Datenbankversion neue Inspirationen.
Ich bin hier nämlich auf einer 10.3.15-MariaDB-1:10.3.15+maria~bionic unterwegs.

edit: deinen edit muss ich mir noch anschauen, der schaut vielversprechender aus.

Ah klar sorry - das SQL ist falsch - überall wo “NOT NULL” steht, muss natürlich “NULL” stehen :slight_smile: Ich habs noch mal aktualisiert.

… Lösung in einer Zeile:
im Base-Model:

//…
$fieldValue = trim($fieldValue, “'”);
return $database->quote($fieldValue);
//…

Das Problem liegt wahrscheinlich irgendwo in den Datenbanktreiberunterschieden:
php-Doku zu pdo::quote

1 Like

Evt. wäre die Zeile auch gut in der Klasse Database aufgehoben. Dann würde das Problem vermutlich auch an anderen Stellen wo ::quote verwendet wird nicht auftauchen.

Guter Vorschlag.

  • In dem Falle verriß es mir halt die Artikelneuerstellung, daher dieses Plätzchen für den Codeingriff.
  • Vielleicht macht es ja auch manchmal Sinn, eine Quotation-Inception durchzuführen.
  • Angefangen hat es heute mit Error-Logs von wegen er könne da was am Template nicht laden (lag am Eintrag in der oxtemplate-Spalte)
  • Weiter gings mit Variantenkindern, die ihren Vater nicht gefunden haben und daher im Backend nicht wieder auffindbar waren (oxparentid)
  • Jo und dann hab ich mich über die seltsamen doch SO nicht vereinbarten Defaultwerte gewundert.

Wie gesagt, vielleicht macht das Mehrfach-Verkapseln irgendwo Sinn und muss gar nicht generell unterdrückt werden. Bei den Defaultwerten war das aber heute echt ein kleines Mysterium.

Danke für deine Mithilfe, die mich doch schnell auf die richtige Spur gebracht hat.

1 Like

Hallo,
das Verhalten kommt von der Kombination Maria DB >= 10.2.* mit älteren Doctrine Versionen (2.5.*).
Ich hatte da auch mal im Bugtracker ein Ticket erstellt:
https://bugs.oxid-esales.com/view.php?id=6914
Aber wie gesagt, das ist kein Bug, sondern hängt mit den o.g. Versionen zusammen.

Auch mit Doctrin 2.7.2 tritt dieser Fehler auf.

Könnte bitte jemand eine einigermaßen ausführliche Beschreibung machen um diesen “Fehler” zu beheben? Ich habe die Änderungen am Core vorgenommen, leider ist der “Fehler” damit nicht behoben.
Eine “Core” Aktualisierung muss man nicht machen, wenn man etwas verändert hat, oder? Bin leider neu im Thema Oxid.

Danke vorab!

Also. Oxid prüft ob ein Feld NULL sein darf, also dass das Feld leer sein darf. NOT NULL Felder erwarten zwingend einen Wert und je nach Datenbanktreiber gibt die Funktion PDO::quote zwei einfache Anführungszeichen (Singlequotes) zurück. Oxid speichert den Wert in die Datenbank.

Um das zu umgehen gibt es zwei - wirklich sehr unintelligente - Lösungen:

  • Alle Felder auf NULL stellen und die bereits gespeicherten Singlequotes aus den Zeilen entfernen
  • Den Core bearbeiten

Punkt zwei ist klar nicht Updatesicher. Nach einer Aktualisierung sind die Daten wieder weg.
Punkt eins ist in soweit nicht intelligent, weil wenn ein Feld nicht NULL sein darf, muss man dort etwas reinspeichern, da sonst unter Umständen der Ablauf gestört werden könnte, weil zur Berechnung gewisser Daten eben alle Daten vorhanden sein müssen.

Es muss nach der Anpassung in der Datenbank auf jeden Fall getestet werden.

Mir fallen dazu zwei mögliche Lösungen ein:

  • Oxid übernimmt die Core-Anpassung von Jonas
  • Von MariaDB auf MySQL wechseln

Allerdings weiß ich nicht wie MySQL damit umgehen wird, wenn NULL Felder ohne Werte abgespeichert werden.

Guten Abend,

vielen Dank für die Erklärung.
Beide Änderungen wurden soeben auf einer frisch installierten Instanz ausgeführt - leider ohne Erfolg. Weiterhin wie Artikel falsch in die Datenbank übergeben.

Meine letzte Hoffnung wäre der Wechsel von MariaDB auf MySQL.

Hier gibts ne Anleitung wie man den Patch auch in frühere Versionen einspielen kann: Applying patches to OXID eShop projects with composer