#262 Export/Import-Modul => IDs als Hash (state: open)

Ich hatte in dem Post mich über die Möglichkeit (Notwendigkeit?) der IDs als Hash ausgelassen https://community.contao.org/de/showthread.php?43458-MetaModels-grupieren&p=283260&viewfull=1#post283260 Da eine Umstellung von Integer auf Hash den Core betreffen würde, hier das Posting

Allgemein stimme ich dir vollkommen zu. Ich hatte auch schon vor der ersten Beta mit dem Gedanken gespielt, eine unique ID (UUID/GUID) zu verwenden, dies jedoch aus Grynden der Kompatibilitaet zum Contao Core verworfen. Es spricht jedoch nichts dagegen, dies in einer weiteren Version umzustellen/zu mappen. Hierzu braucht es dann aber einen sauberen Upgradehandler, welcher die id in uid umschreibt. und dies in allen sekundaertabellen und tertiaertabellen.

dann bin ich gespannt wie das Ex-Im-Portmodul funktioniert... Ich kann mir nur vorstellen, dass man alle MMs komplett exportiert und wieder importieren kann. Dann wird man leider kein "MM-Set" von einem + ein "MM-Set" von einem anderen Entwickler importieren können - z.B. Musikverwaltung von A und Shopverwaltung von B. Was mir an der Stelle auch nicht so ganz einleuchtet, warum alle Relationen in einer Tabelle landen? Mit Hinblick auf den Export/Import und ggf. Performance(?) könnten separate Tabellen die bessere Variante sein - wie im Post geschrieben z.B. als mmrel Von TimG ist zwar der Einwand gekommen, dass es beim Umbenennen von Tabellen es zu Problemen kommen könnte - ich denke das Umbenennen wäre bei einen festen Schema kein unlösbares Problem und Präfix "rel" könnte man als Tabellenname sperren. Gruss

... Thema Upgradehandler: wohl war - das ist nicht ganz ohne... eine Idee wäre die aktuellen IDs und PIDs in neue Spalten zur Sicherung zu kopieren und anschließend die neuen UIDs zu setzen - wenn die Säge irgendwo klemmt, hat man noch die alten Werte und kann auch mehrmals über eine Tabelle gehen

um dem Thema etwas "Rückenwind" zu verleihen, die folgenen Anmerkungen: offensichtlich wird die Pflege des EFG immer zäher - ist aber m.E. eines der beliebtesten Erweiterungen bei Contao. Ich habe/hatte zumindest keine Installation ohne EFG... In der Zwischenzeit schwenke ich als Alternative zum EFG auf eine Kombi aus

• normalem Formular per Contao-Generator
• Notification Center (NC) für die E-Mail-Verarbeitung
• MM für die Speicherung der Daten und Ausgabe im FE inkl. Filter Mit der Kombi kann man fast alles umsetzen, was im EFG als Standard machbar ist - die Aktivierung der Kommentarfunktion per Checkbox fehlt (noch). Wozu die Ausführungen? den meisten Usern wird man das nicht "zumuten" können, sich das alles selbst zusammen zu stricken - hier könnte ein MM-NC-Bundle inkl. einem "EFG-MM" ein "Renner" sein...

Nachtrag zur gestrigen "Diskussion" - an welcher Stelle müss(t)en wir auf Contao-Core Rücksicht nehmen? Weil wir die API für den DB-Zugriff verwenden? Ansonsten bildet MM doch ein relativ "geschlossenes System" - spontan fällt mir nur ein, wenn MM Kindtabelle von tl_* ist, müssten die PIDs als INT gespeichert werden ... das könnte man aber auch in einer "tl_pid" machen

Exakt sowas ist z.B. ein Kriterium. Aktuell myssen wir auch lokal kompatibel bleiben und somit die UUID zusaetzlich implementieren (analog wie es tl_files macht), denn alle verlassen sich aktuell auf die numerische id in der DB und da kann man denen nicht ploetzlich einen string vorsetzen.

Frage ist, ob bei einem Wechsel von MM auf Contao 4 nicht sowieso soviel ändert, dass man das hier - nach Ansage - ändern kann als MM 3.0

Ich will eigentlich nicht gleich mit 3.0 loslegen wenn 2.0 noch nichtmal sauber aus der Tyr ist... @MetaModels/team was meint ihr?

wenn wir uns den Zeitplan von Contao ansehen und die Updates von MM, dann kommt für C3.5 doch "nur" noch ein 2.1 mit den dort hin verlagerten "optischen&usability Anpassungen"

Ich denke, je eher man grundlegende Änderungen kommuniziert, um so besser... Die Umstellung der Icons ging doch im Grunde ohne große "Krokodilstränen" über die Bühne...

siehe auch https://github.com/contao/contao/issues/402