Open stefanheimes opened 10 years ago
HellPat
commented
10 years ago Kann man nicht vielleicht auch da ansetzen dass der Kunde auf Live und Preview arbeitet?
Die News auch auf Preview pflegen lassen, eine REST-Api bauen und die Daten von der Preview-Umgebung ziehen und mittels eines FE-Moduls auf Live von extern einbinden?
-> Kann aber auch eine dumme Idee sein
andreasisaak
commented
10 years ago @psren Nein, das ist doch nur Symptombekämpfung für einen Anwendungsfall. Beim nächsten Mal sind es Newsletter und Galeriemodule. Bitte lasst uns überlegen wie wir das generelle Problem lösen können.
leo-unglaub
commented
10 years ago Wir haben das gerde im IRC diskutiert und nach langem Hin und Her wäre ich für Lösung 2. So eine Tabelle ist meiner Meinung nach die sauberste Lösung, zumindest deutlich besser als ein weiteres FEld uuid1, uuid2, ... .
tristanlins
commented
10 years ago @leofeyer ich würde mich zur Verfügung stellen, einen POC zu schreiben, wenn wir wissen, in welche Richtung es gehen soll :-)
stefanheimes
commented
10 years ago Es wäre hilfreich wenn wir dies in irgendeiner Form schon in die 3.2.x bekommen, da dies die neue LTS ist.
leofeyer
commented
10 years ago Für die 3.2 steht das nicht zur Debatte. Neues Feature == nächste Minor-Version (ohne BC-Break) bzw. nächste Major-Version (mit BC-Break).
@andreasisaak hatte das Problem schon mal angesprochen und damals sind wir schon auf Probleme mit dem Ansatz gestossen. Am besten besprechen wir das daher nochmal auf Mumble.
andreasisaak
commented
10 years ago Ich kann auch voll mit Contao 3.3 leben. Btw, als wir das damals angesprochen haben, war uns noch nicht die Idee mit der Symlink Tabelle gekommen. Vielleicht ist das eine einfachere Implementierung.
tim-bec
commented
10 years ago Könnte die Implementierung in 3.2 bitte noch mal diskutiert werden?
Ich verstehe schon den Sinn und Zweck eines Release Plan und dessen Phasen. Wir haben nun so nach und nach unsere Projekte auch genau deshalb auf LTS Versionen umgestellt, migrieren derzeit immer mehr Installationen von 2.11 auf 3.2 und nutzen synccto intensiv.
Unser Staging Workflow sieht unter 2.11 in den meisten Installationen so wie bei Menatwork aus. Wenn das Problem aber nicht in 3.2 angegangen wird, hieße das, das wir aus dem LTS ausbrechen müssen, oder wir bis Juni nächsten Jahres mit der Migration warten. Beides nicht so Ideal.
TLDR; Bitte bitte solch ein wichtiges Feature nicht aus einer LTS raushalten!
aschempp
commented
10 years ago Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
Definitiv nicht.
tristanlins
commented
10 years ago Ich habe mir gerade nochmal Gedanken über den Vorschlag 2 gemacht, dieser impliziert einen BC break, weil ich als Entwickler halt immer auch in die Symlink Tabelle joinen müsste. Aber auch ein doppelter Eintrag in tl_files ist nicht BC break-less...
Irgendwie gerade ne doofe Situation :-/ Muss ich mir noch ein paar zusätzliche Gedanken machen...
tim-bec
commented
10 years ago Ich frag mal vorsichtig nach ob es zu diesem Thema schon einen weiteren Vorstoß gibt?
Moin,
wir benutzen für Contao 3 unser neues syncCto 2.6 um Dateien und Datenbank Einträge zu synchronisieren. Mit dem DBAFS haben wir nun allerdings noch ein Problem. Zwar sind die Einträge, dank der UUID, übertragbar allerdings sind wir nun auf ein anderes Problem gestoßen.
Wir benutzen bis zu 3 Systeme, Entwicklung <-> Preview <-> Live, damit wir und die Kunden zeitgleich entwickeln können. Nun kann es leider dazu kommen das der Kunde Live und auf der Preview arbeitet (Bedingt durch Newsletter und News). Dies kann dazu führen das Dateien, die gleich sind, sowohl auf der Preview als auch der Live Installation angelegt bzw. hochgeladen werden jedoch verschiedene UUID's bekommen.
Damit kommt syncCto dann nicht mehr zu zurecht. Als Notlösung verschieben wir die eine Datei und erstellen eine neue mit der UUID vom anderen System. Dies sorgt nun aber dafür das wir mehrere Datein, die eigentlich gleich sind, anlegen. Leider können wir diese Workflow nicht abändern, da der Kunde diesen so haben möchte und sich mittlerweile auch von anderen CMS'en daran gewöhnt hat, die auch Live/Stagingsysteme bieten.
Lösung 1: Eine Lösung wäre, wenn es die Möglichkeit gäbe für eine File mehrere UUID anzugeben. So eine Art symbolische Verknüpfung, es gibt immer noch den Haupteintrag im DBAFS, allerdings kann ein anderer Eintrag auf die Datei XXX verweisen.
Lösung 2: Es wird eine neue Tabelle angelegt "tl_files_symlinks". Hier gibt es das Feld id, pid, uuid. Die pid verweißt dabei auf einen Eintrag in "tl_files". So könnte das Model bei der Suche findByPK oder findByUUID einen JOIN auf die neue Tabelle machen und hier auch noch suchen.
Lösung 3: Alternativ könnte ein Hook helfen der aufgerufen wird, wenn eine UUID unbekannt ist. Dann könnte sich darum immer noch eine andere Logik kümmern und versuchen die UUID aufzulösen. Ob diese dann wie Lösung 1 oder 2 arbeitet, kann Contao in dem Moment egal sein.