Update-Assistent erkennt Tabellen ohne "tl_" prefix
Closed this issue · 22 comments
Tabellen ohne "tl_" prefix können mit dem Update-Assistent gelöscht werden.
Gibt es hierfür eine Lösung?
@contao/developers /cc
Die korrekte Lösung ist, dass Erweiterungen die entsprechenden Informationen bereitstellen.
@aschempp in der Datenbank können ja auch Tabellen vorkommen, die gar nichts mit der Contao Installation zu tun haben. Welche Extension sollte dann solche Informationen bereit stellen?
Darüberhinaus informiert das Install Tool ja, dass generell nur Tabellen mit dem tl_ Prefix berücksichtigt werden, was aber momentan nicht der Fall ist, wie es scheint.
Ohne diesen Change funktioniert halt alles was mit Doctrine ORM zu tun hat nicht mehr… Aus meiner Sicht sollte es in derselben Datenbank keine Tabellen geben welche nichts mit der Applikation zu tun haben.
Falls wird das wirklich ändern wollen liegt die Lösung wohl im Doctrine Schema Filter (http://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html#manual-tables)
Also ich hätte gerne, dass alle Tabellen angezeigt werden. Der tl_-Präfix hat für mich noch nie Sinn ergeben. Das stammt aus einer Zeit, als man mehrere Applikationen auf derselben Datenbank laufen liess. Dafür gibt es heute m.M.n. kein valides Argument mehr. Und wenn jetzt gleich einer mit "Hosting Datenbanklimit" kommt: Nein, das ist kein Argument.
Aber es wär trotzdem gut, wenn man dem Install-Tool sagen könnte, es soll gewisse Tabellen ignorieren. Aber nur mit Präfix erlauben, davon sollten wir imho wegkommen.
Also meine Tabellen in MetaModels fangen alle mit mm_ an damit Contao eben NICHT daran rumspielt.
Da soll keiner einfach dran rum machen ohne dass ich es ihm explizit sage.
Explizit meint hier: Mein Code oder Migrations die ich definiere.
Explizit meint hier nicht: Autmagischer Code welcher die Datenbank einliest und meint das gehoert weg weil er es nicht kennt.
@frontendschlampe und @backbone87 verwenden AFAIR auch einen Prefix hofff_ um Tabellen weg zu maskieren. Der Usecase ist durchaus gebraeuchlich.
Aus meiner Sicht sollte es in derselben Datenbank keine Tabellen geben welche nichts mit der Applikation zu tun haben
Das sehe ich auch so.
Also meine Tabellen in MetaModels fangen alle mit mm_ an damit Contao eben NICHT daran rumspielt.
Da soll keiner einfach dran rum machen ohne dass ich es ihm explizit sage.
Die einfache und (imho) korrekte Lösung hierfür ist einfach dass MM diese Informationen dem Schema-Tool zur Verfügung stellt. Dieselben Probleme hast du sonst wenn du Doctrine Migrations oder doctrine:database:update nutzen willst, der löscht dann nämlich entsprechende Tabellen auch.
Doctrine kann ich es aber sagen, beim Schema tool weiss ich dies nicht, allgemein ist dies nun eine Aenderung welche nicht einmal mehr mit der Dokumentation ihrer eigenen Funktion in Einklang ist und somit streng genommen ein bc break.
Aus meiner Sicht sollte es in derselben Datenbank keine Tabellen geben welche nichts mit der Applikation zu tun haben
Das sehe ich auch so.
Nunja, es hat ja schon mit der Applikation zu tun, da die Tabellen aus Contao heraus verwaltet und verwendet werden, nur eben nicht per DC_Table und install tool, welches einiges gar nicht kann (trigger etc).
Wenn du es Doctrine sagen kannst, dann auch dem Schema Tool 😂
Das Install-Tool kann mittlerweile alles was Doctrine Schema kann, entsprechend sehe ich da kein grosses Problem…
das doctrine schema tool ist in keinster weise als ersatz für ein DBA-assistenten gedacht. es bildet (wie das contao 3.5er db-tool) nur eine teilmenge der DDL ab (und diese teilmenge ist nicht mal SQL92-vollständig).
doctrine rät davon ab das schema tool für komplexere systeme einzusetzen und stattdessen auf migrations zu setzen. das schema tool is für rapid development gedacht, um nicht das ganze "standard DDL" selbst generieren zu müssen.
ich benutze in meinen erweiterung views und tabellen mit spatial indexen, welche nicht von contao angefasst werden sollen (da contao sie nicht managen kann wegen (gewolltem) featuremangel).
edit:
ich sehe das so, dass contao "seinen" teil der DB managed, also alle standard contao tabellen + tabellen von erweiterungen/bundles/libs die nach contao schema arbeiten und explizit contao die kontrolle über die DDL dieser db-artefakte lassen. die namen der db-artefakte, welche zu diesem teil gehören, werden per konvention mit "tl_" geprefixt. die alternative wäre via konfiguration contao zu sagen, welche tabellen es verwalten soll, ABER das bringt einen haufen andere probleme mit sich (entfernung von komponenten, entfernt idR auch deren konfiguration, aber nicht deren db-artefakte, somit ist das wissen über diese nicht verfügbar).
edit2:
zu sagen ihr dürft nur db-features verwenden, die das schema-tool kann und contao vereinnahmt die vollständige db, bedeutet das man entweder auf jegliche nicht ins schema tool "geshimte" funktion verzichtet (dazu zählen vorallem views, SPs und trigger, aber auch andere wie "virtuelle" columns) oder eine 2te DB nutzt (was einen haufen neuer Probleme mitbringt)
Ich bin mir nicht sicher worauf du deine Aussage beziehst, Doctrine Migrations nutzt genauso Schema diffs zu generieren.
Noe, es generiert Klassen mit dem diff den es versteht und laesst alles andere dir.
Weiterhin kannst du die Up und down auch komplett von Hand ohne schema diff erzeugen.
Im Ergebnis kommt es auf's selbe raus, du hast hinterher konkrete Klassen die Queries feuern beim up/down grade anstatt dass das Tool automagisch entscheidet wie es denn nun die Tabellen in Ordnung biegt. Das ist der ganze Sinn hinter migrations.
Eine zweite dB Connection nur fürs diffen/Updaten mit einem tablename filter
Man könnte sogar soweit gehen, dass man die zweite Connection von Hand zusammenbaut und mehrere konfigurierbare prefixe zulässt
ich hab mal ein bisschen rumgeschaut.
mit: $conn->setFilterSchemaAssetsExpression('/^tl_/') kann man sicherstellen, dass beim auslesen aus der DB, nur tl_ tabellen genommen werden. siehe https://github.com/doctrine/dbal/blob/ec8fc16604915110eea8046e3ea594c133aee880/lib/Doctrine/DBAL/Configuration.php#L102
jetzt zum problem: https://github.com/contao/core-bundle/blob/master/src/Doctrine/Schema/DcaSchemaProvider.php#L68
Zu erst: Die klasse heißt DCA schema provider, liest aber doctrine metadaten aus? warum?
wo probleme entstehen: Wenn wir mit dem filter von oben den "ist"-stand aus der DB holen, werden natürlich alle tabellen, die nicht mit tl_ beginnen, rausgefiltert. Der dca schema provider benutzt aber die doctrine metadaten, wenn er eine nicht-leere doctrine registry injected bekommt. Und diese metadaten enthalten alle in dieser registry vorhandenen metadaten, also auch von entities deren table nicht mit zwangsweise mit tl_ beginnen. dadurch will das upgrade diff natürlich diese evtl. bereits vorhandenen, aber herausgefilterten tabellen createn.
Die Option um setFilterSchemaAssetsExpression haben wir in diesem Ticket bereits diskutiert: #48 (comment)
Zum DcaSchemaProvider, der erweitert das Doctrine Schema aus DCAs. Das System verhält sich nur anders wenn ORM vorhanden ist, denn dann gibt es einen entsprechenden Event den wir nutzen können, wenn ORM nicht vorhanden ist geht das aber nicht, dann nutzt das Install-Tool den Provider direkt.
ich möchte den filter nicht permanent setzen, sondern nur zum diffen/auslesen des schemas aus der DB. und soweit ich sehen konnte, hat der schema asset filter nur auswirkungen auf den schema manager von dbal