more than one field found...bei update

[skerbis]

Update von: 4.0 auf 4.03.

Exception
more than one field found for table: rex_ycom_user with Fieldidentifier: value, ycom_auth_password, password#

-Was ist schief gelaufen? -Wie kann man das beheben?

Irgendwie ist durch jahrelange Updates für ycom_auth_password in YForm eine 2 Definition für das Feld rex_ycom_user gelangt.

Löschen der überzähligen Definition hilft.

[dergel]

Das irgendwie wäre cool zu wissen. Kannst du das reproduzieren und nochmal prüfen ?

[skerbis]

Leider nicht mehr. Sollte sich wieder was tun, werde ich mich melden.

[alxndr-w]

Anm.: Ich hatte den Fehler auch mal - losgelöst von YCom in YForm und eher im Zusammenhang mit einer alten REDAXO-Installation, evtl. sogar vom Converter angestoßen.

Ich glaube nicht, dass es ein YCom-Problem ist und wenn, dann liegt der Fehler weit in der Vergangenheit und fällt hier korrekterweise auf.

edit: https://github.com/yakamara/redaxo_yform/issues/108

[alxndr-w]

Hatte es jetzt auch in einer 2-3 Jahre alten Installation

Exception: more than one field found for table: rex_ycom_user with Fieldidentifier: value, ycom_auth_password, password File: redaxo/src/addons/yform/plugins/manager/lib/yform/manager/table_api.php Line: 167

Stacktrace

| Function | File | Line | | -------------------------------------------- | ----------------------------------------------------------------------- | -------- | | rex_yform_manager_table_api::setTableField | redaxo/src/addons/yform/plugins/manager/lib/yform/manager/table_api.php | 70 | | rex_yform_manager_table_api::setTable | redaxo/src/addons/yform/plugins/manager/lib/yform/manager/table_api.php | 95 | | rex_yform_manager_table_api::importTablesets | redaxo/src/addons/.new.ycom/update.php | 6 | | include | redaxo/src/core/lib/packages/package.php | 280 | | rex_package->includeFile | redaxo/src/addons/install/lib/package/package_update.php | 64 | | rex_install_package_update->doAction | redaxo/src/addons/install/lib/package/package_download.php | 37 | | rex_install_package_download->run | redaxo/src/addons/install/lib/api/api_package_update.php | 21 | | rex_api_install_package_update->execute | redaxo/src/core/lib/api_function.php | 180 | | rex_api_function::handleCall | redaxo/src/core/backend.php | 229 | | require | redaxo/src/core/boot.php | 141 | | require | redaxo/index.php | 9 |

System report (REDAXO 5.12.1, PHP 7.4.23, MySQL 5.7.33)

| REDAXO | | | ------------: | :--------- | | Version | 5.12.1 | | PHP | | | ------------: | :--------- | | Version | 7.4.23 | | OPcache | no | | Xdebug | no | | Database | | | ------------: | :----------- | | Version | MySQL 5.7.33 | | Character set | utf8mb4 | | Server | | | ------------: | :--------- | | OS | Linux | | SAPI | cgi-fcgi | | Webserver | Apache | | Request | | | ------------: | :------------------- | | Browser | Chrome/92.0.4515.159 | | Protocol | HTTP/1.1 | | HTTPS | yes | | Packages | | | ----------------------: | :---------- | | accessdenied | 1.0.6 | | across | 3.0.0-dev23 | | across/backend | 3.0.0 | | adminer | 1.9.1 | | backup | 2.7.1 | | be_style | 2.12.1 | | be_style/redaxo | 2.12.1 | | bloecks | 3.0.2 | | bloecks/cutncopy | 3.0.2 | | cache_warmup | 3.6.1 | | cke5 | 4.2.2 | | cke5/documentation | 1.0.0 | | consent_manager | 3.0.0 | | cronjob | 2.8.0 | | cronjob/article_status | 2.8.0 | | cronjob/optimize_tables | 2.7.1 | | developer | 3.9.0 | | events | 2.0.0-dev | | feeds | 3.1 | | install | 2.9.1 | | maintenance | 2.6.3 | | markitup | 3.6.1 | | mblock | 3.2.0 | | media_manager | 2.11.1 | | mediapool | 2.10.1 | | metainfo | 2.8.1 | | mform | 6.0.9 | | mform/docs | 1.1 | | minify | 2.2 | | neues | 2.0.0-dev | | phpmailer | 2.10.2 | | product | 2.0.0-dev | | project | dev | | qanda | 2.0.1 | | quick_navigation | 5.1.1 | | redactor2 | 4.1.0 | | sprog | 1.2.0 | | structure | 2.12.1 | | structure/content | 2.12.0 | | structure/version | 2.12.0 | | theme | 1.3.3 | | uploader | 2.2.2 | | url | 2.0.0-beta3 | | users | 2.8.0 | | watson | 2.2.0 | | ycom | 4.0.3 | | ycom/auth | 4.0.3 | | ycom/docs | 4.0.3 | | ycom/group | 4.0.3 | | yform | 3.4.2 | | yform/email | 3.4.2 | | yform/manager | 3.4.2 | | yform_geo_osm | 1.2.3 | | yform_spam_protection | 1.1.0 | | yform_usability | 1.4 | | yrewrite | 2.7 | | zip_install | 1.1 |

[tyrant88]

Hatte ein Bekannter gestern auch. Da war es allerdings das Feld "status". Allerdings aktuell bei 4.0.1 auf 4.0.6.

[alxndr-w]

Meinem Empfinden nach ist das Thema "durch" und lässt ich auch nicht mehr reproduzieren, ggf. ist es sogar unabhängig von YCom. Doppelte Felddefinitionen könnten zukünftig durch Maßnahmen wie https://github.com/yakamara/redaxo_yform/issues/1217 vermieden werden.

[eaCe]

Wieder aktuell in Slack

[alxndr-w]

Bitte https://github.com/yakamara/redaxo_yform/issues/1217 umsetzen, um nachvollziehen zu können, ob das Problem bereits existierte oder erst durch das Update eingeführt wurde.

[alxndr-w]

Ich konnte es jetzt eingrenzen - schlägt eine Addon-Installation fehl oder wird ein reinstall ausgeführt, bei der ein Tableset erneut importiert wird, werden ggf. Felddefinitionen noch einmal hinzugefügt. Das ist mir jetzt auch bei meinem Addon passiert.

Eine UNIQUE-Validierung könnte helfen, um solche Fehler zu verhindern:

Duplicate entry 'rex_event_category-value-event_media-image' for key 'table_name_type_id_type_name_name'

Lösungsvorschlag in YForm: https://github.com/yakamara/redaxo_yform/issues/1217

In meinem Fall ist es so, dass das YCom-E-Mail-Validierungsfeld 3x in der Datenbank war.

[dergel]

ich schließe das hier, weil es ein YForm Problem ist.

[bitshiftersgmbh]

Hab dir hier auch gerade wieder bei YCom 4.0.3 (und Versuch zu reinstallieren oder zu updaten). ycom_auth_password macht Probleme weil es in rex_yform_field doppelt existiert (via Kombination Typ: value | Name: password).

Durch manuelles Löschen der Duplikatszeile(n) löst sich das auf. Dann kommt aber direkt im Anschluss:

More than one field found for table: rex_ycom_user with field identifier: value, ycom_groups.
Remove duplicate field definitions for value, ycom_groups from table rex_yform_field

Ein Hinweis hier: Der Der type_name ist unterschiedlich bei der be_relation. Vielleicht ist das ja ein Ansatz, der wohl darin münden müsste die entsprechenden Table Manager API-Methoden gegen solche Fälle abzusichern (?)

[bitshiftersgmbh]

Kopie aus Slack (von mir):

Habs jetzt auch hinbekomen. Komisch trotzdem. Mir scheinen da einige Check-Methoden bestimmte Fälle nicht ausreichend zu berücksichtigen. Meine Vermutung bei grobem Überfliegen des Codes:

1. Es gibt in der JSON Definitionen bestimmte Felder, die es früher auch schon gab, aber irgendwas hat sich halt geändert (bspw. type_name oder NOT NULL etc.)
2. Weil ein Feld mit kleiner Änderung nicht 1:1 dem schon bestehenden entspricht, wird es nicht als Duplikat eingestuft und neu angelegt (was widerum ein Duplikat erzeugt).
3. Ein späterer Check (rex_yform_manager_table_api::setTableField() Stelle if (count($currentFields) > 1) { ... }) zählt dann durch andere Sicht auf diese Felder 2 (oder mehr) und steigt mit Duplikats-Warnung aus. Kann mich irren, aber es liest sich so, als wären da mehrere verschiedene Checks am Start, deren Duplikat-Erkennung nicht (ausreichend) synchron läuft.

Schlussendlich dürfte das Duplikat (beides mal Typ value, gleiche Table und gleicher name) gar nicht erstellt werden können (Problem also s.o. Punkt 2). Die Methode die das macht, lässt es aber zu. Ergo muss dort ein Check verkäfert sein.

Bei meinem Fall eben was alles top-aktuell (heute geupdated), nur YCom nicht. Beim Installieren werden fast ausschließlich Methoden des Tablemanager-Plugins von YForm benutzt. Das lässt keinen anderen Schluss zu als das der Fehler bei YForm liegt. @marcohanke kann das ebenfalls bestätigen.

Um zu prüfen, ob die Duplikate schon vor dem versuchten YCom-Update existiert haben, konnte ich bei der aktuellen Installation hier gut nachsehen (da das Projekt vorher wegen der vielen großen Updates und großumfänglichem Einsatz von YForm) geklont wurde. Dort gibt es z.B. die Password-Zeile nur 1 mal (group-Zeile ebenso). Allerdings ist dort auch YForm noch auf 3.x. Ich fänd es ja komisch, wenn ausgerechnet nur diese 1 Zeile von YForm aus dupliziert worden sein sollte allein durch ein YForm-Update (ohne YCom anzufassen). Ergibt für mich keinen Sinn, es sei denn, da gibt es irgendwo komische Hooks/Trigger/EPs ...

[alxndr-w]

@bitshiftersgmbh

• gab's irgendwelche Probleme während des Updates?
• Musstest du ein Update 2x ausführen oder im Safe Mode oder nicht?
• Kannst du YForm 3.x updaten auf 4.x und dann nachsehen, ob dann schon alles doppelt ist?
• Hast du Zwischenversionen geupdatet, also 4.0.1 auf 4.0.2 oder bist du direkt durchmarschiert?

Es geht ja darum, spezifisch den Schritt zu isolieren, bei dem die Verdopplung stattfindet.

[bitshiftersgmbh]

Ich hab bei dem Projekt diverse Instanzen am Start. Aktuell ist es der erste Test, wie gut (oder nicht) die Updates durchgehen. Eigentlich wollte ich dann (weil alles noch ohne reale Daten) Files und DB synchen bzw. mergen, um Zeit zu sparen.

Das Updaten hat mich heut den ganzen Tag gekostet. Bei 3 auf 4 gab es Probleme wegen der Versionsvoraussetzungen gegenseitig und zum Core, dann PHP-Version etc. Das Bundle Core / YForm (+ Helper AddOns) / YRewrite / YCom ist bei größeren Update-Pausen schon schwierig, da man nicht wirklich weiß, was zuerst und wann welche PHP-Version ändern etc.

Wie so oft, habe ich bei Dependency-Errors gelöst, indem ich zwischenzeitlich bestimmte AddOns einfach deaktiviert habe. Falls ich doch nochmal Lust habe, alles durchzuklicken, statt zu mergen, achte ich mal pro Schritt auf die betroffene Stelle der DB. So oder so sollte man sich aber mal die Methoden anguclken, die die Inserts in die Field-Table vornehmen, da scheint mir das Problem am wahrscheinlichsten zu liegen.

[alxndr-w]

Also long story short: wir wissen weiterhin nicht, in welchem Schritt unter welcher Voraussetzung das passiert und mit etwas Glück opferst du dich nochmal dafür, es herauszufinden, vielleicht auch nicht.

Ich gehe nicht davon aus, dass Jan allerdings seine Zeit auf gut Glück investieren wird, herauszufinden, woran es liegt, wenn keiner hier (auch ich nicht) das fest reproduzierbar bekommt. Solange müssen wir halt weiter damit leben.

[alxndr-w]

Also, die Überprüfung funktioniert sehr gut - jetzt lässt sich YCom nicht updaten mit folgender Fehlermeldung:

AddOn ycom konnte aus folgendem Grund nicht aktualisiert werden:
SQL error: Error while executing statement "INSERT INTO `rex_yform_field` SET `table_name` = :table_name, `prio` = :prio, `type_id` = :type_id, `type_name` = :type_name, `db_type` = :db_type, `list_hidden` = :list_hidden, `search` = :search, `name` = :name, `label` = :label, `not_required` = :not_required, `message` = :message, `attributes` = :attributes, `rules` = :rules, `script` = :script" using params {"table_name":"rex_ycom_user","prio":9,"type_id":"value","type_name":"ycom_auth_password","db_type":"","list_hidden":1,"search":1,"name":"password","label":"translate:password","not_required":"","message":"translate:ycom_validate_password_policy_rules_error","attributes":"","rules":"{\"length\":{\"min\":8},\"letter\":{\"min\":1},\"lowercase\":{\"min\":1},\"uppercase\":{\"min\":1}}","script":"1"}! SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'rex_ycom_user-value-ycom_auth_password-password' for key 'table_name_type_id_type_name_name'

In der Datenbank ist das Feld password nur einmal vorhanden.

[tyrant88]

Wo kommt denn der constraint her? Hat die Tabelle ein unique?

[alxndr-w]

YForm macht beim Importieren des Tablesets das zur Regel. Mich wundert nur, warum YForm das Feld nach wie vor erneut in die Datenbanktabelle eintragen möchte, statt zu ignorieren/upzudaten wie alle anderen auch.

[tyrant88]

YForm macht beim Importieren des Tablesets das zur Regel

Konnte ich nicht im Code finden.

[alxndr-w]

@tyrant88 ich auch nicht, allerdings auch nicht spezifisch von mir manuell an der Datenbank. In jedem Fall habe ich jetzt für @dergel eine REDAXO-Installation griffbereit, in der man das reproduzieren kann.