Amicas DB-Interface

[AmicaNoctis]

Aber dazu muss dieser Code auch das DB-Schema kennen. Sonst könnte man in ein Textfeld "true" eingeben und beim nächsten Aufruf wäre es eine Checkbox.
Woher kennt dein Code das DB-Schema? Offensichtlich liest er es aus der DB. Das kostet.

Der Code kennt die DB-Metadaten (ein "Schema" ist in DB-Sprache das was bei MySQL eine "Datenbank" ist) und das castet sich auch praktisch von alleine (siehe erster Beitrag).

Die Metadaten (Spalten, Schlüssel, Constraints) holt sich der Code aus der DB, das ist richtig. Coole Features kosten immer, aber das ist erstens nicht so tragisch und zweitens widme ich mich gerade diesem Problem. Da das sowieso ein richtig fettes Projekt ist, schreibe ich grad an einem nativen PHP-Server, der das (und andere Sachen) dann cachet. Das Auslesen der Metadaten mach ich übrigens nicht nur wegen der Booleans, sondern auch, um das Konzept "virtuelle Tabelle" zu realisieren. Das ist eine Art View, nur dass man den kompletten CRUD-Methodensatz drauf anwenden kann und die Metadaten erhalten bleiben (Schlüssel, Constraints, ...).

Edit: falls du das blödsinnig findest, weil es ja Trigger gibt: Das ganze soll auch auf Shared Servers funktionieren, wo man weder Trigger anlegen kann, noch Lesezugriff auf das Information-Schema hat. Daher muss ich die Metadaten aus dem Create-Table-Statement rausparsen.

Wenn sich bei mir das DB-Schema ändert, spiegelt sich das zuerst im Code wider.

Das ist genau das, was mich stört. Das Teil soll auf einer beliebigen MySQL-DB laufen, auch wenn die der Kunde selbst gebaut hat und die totaler Mist ist oder sich ständig ändert. Außerdem bin ich extrem faul. Wenn ich das DB-Modell auslesen kann, warum sollte ich es dann coden?

[Quetschi]

... der das (und andere Sachen) dann cachet...

Was schwebt dir dazu konkret im Kopf vor?

[AmicaNoctis]

Was schwebt dir dazu konkret im Kopf vor?

Die Benutzerrechte und die gespeicherten Suchfilter der Benutzer, um den Join von user über role_x_user über permission_x_role über permission auf method und den Join von user über filter_x_user über filter auf filter_column nicht bei jeder Anfrage machen zu müssen.

[Quetschi]

Die Benutzerrechte und die gespeicherten Suchfilter der Benutzer, um den Join von user über role_x_user über right_x_role über permission_x_role über permission auf method und den Join von user über filter_x_user über filter auf filter_column nicht bei jeder Anfrage machen zu müssen.

Ich meinte nicht so sehr WAS du cachen willst, sondern vielmehr WIE?

[AmicaNoctis]

Ich meinte nicht so sehr WAS du cachen willst, sondern vielmehr WIE?

Achso, dann versteh ich die Frage nicht ganz. In einem Array oder einem Objekt halt.

[Quetschi]

Das Caching findet also nur zur Laufzeit des Scriptes statt?

[AmicaNoctis]

Das Caching findet also nur zur Laufzeit des Scriptes statt?

Das ist kein Skript, das ist ein Dämon, ein nativer PHP-Server. Jetzt weiß ich, was du meinst. In einem Skript wäre das ja nicht so ohne weiteres machbar

[Quetschi]

Und ich begreif grad mehr, was das Ganze überhaupt soll - bei nem Script wär es zwar möglich, aber das Caching müsste ja auf Datei- oder DB-Ebene verlagert werden und wäre damit wohl recht witzlos

[AmicaNoctis]

Und ich begreif grad mehr, was das Ganze überhaupt soll - bei nem Script wär es zwar möglich, aber das Caching müsste ja auf Datei- oder DB-Ebene verlagert werden und wäre damit wohl recht witzlos

Genau

[unset]

In meiner ZF-Mutation nutzen die Modelle auch das Schema, und bieten dann auch entsprechende Methoden an, um direkt auf FK-Records zugreifen zu können, evtl. Blobs außen vor zu lassen, Compliance-Felder auszuwerten und so weiter …

Allerdings liegt zwischen Modell und Datenbank-Abbildung auch noch eine weitere Abstraktion (heißt intern Item), in der Sonder- und Einzelfälle angefackelt werden. Die sind aber eigentlich auch nur zur automatischen Frontend-Generierung nötig, die natürlich so flexibel wie möglich sein muss, die durchaus extrem komplex werden und dahingehend flexibel bleiben muss. Dadurch handel ich dann Modelle ab, die auf ein und die selbe Datenbasis zugreifen, sich aber anders verhalten sollen.

Im Resultat bedeutet das, dass ich für Modelle kaum noch Code schreiben muss (konkret muss ich nicht mal die Klasse anlegen, da mein Autoloader auch sog. Shadows anbietet, die dem System vorgaukeln, eine Modell-Klasse gefunden zu haben, in Wirklichkeit aber auf die Basis-Klasse zurückgreifen). Ich kann also einfache Modelle erstellen, in dem ich die Tabelle(n) designe und die Klasse instanziere

[AmicaNoctis]

um direkt auf FK-Records zugreifen zu können, evtl. Blobs außen vor zu lassen,

Haargenau. Endlich einer, der mich versteht.

[onemorenerd]

Der Code kennt die DB-Metadaten (ein "Schema" ist in DB-Sprache das was bei MySQL eine "Datenbank" ist) und das castet sich auch praktisch von alleine (siehe erster Beitrag).

Dort sehe ich

Inzwischen nutze ich seit längerem "set('true') not null" und das hat einige Vorteile. Wenn es ganz normal selektiert wird, liefert es "true" oder "", was in PHP auf bool gecastet den korrekten Wert liefert.

Du bekommst also aus deiner SET-Spalte einen String, entweder "true" oder "". Diesen String castest du in PHP nach bool. Aber woher weiß die Applikation, dass sie nach bool casten muss und nicht nach einem anderen Typ oder überhaupt nicht? Das kann die Applikation nicht ohne zusätzliche Informationen entscheiden. Sie muss wissen, dass die Quelle dieses Strings genau den Spaltentyp hat, den du für Booleans verwendest.
Ansonsten würde die Applikation ja auch leere VARCHAR-Felder nach bool casten, oder Felder, die zufällig den String "true" enthalten.
Du sagst ja auch selbst

Die Metadaten (Spalten, Schlüssel, Constraints) holt sich der Code aus der DB, das ist richtig.

So ganz "von alleine" castet sich die SET-Spalte also nicht. Und wenn du schon irgendwo Metadaten zu Rate ziehst, machst du im Grunde das gleiche wie andere DB-Abstraktionen. Nur machst du es eben durch zusätzliches Abfragen der Metadaten aus der DB, andere Abstraktionen ziehen dieses Wissen aus Konfiguration/Code.

... schreibe ich grad an einem nativen PHP-Server, der das (und andere Sachen) dann cachet ...
Das ganze soll auch auf Shared Servers funktionieren

Bin gespannt wie du das unter einen Hut bekommst.

Das Teil soll auf einer beliebigen MySQL-DB laufen, auch wenn die der Kunde selbst gebaut hat und die totaler Mist ist oder sich ständig ändert.

Man kann mit Propel, Doctrine u.a. von einer bestehenden DB ausgehen.
Wenn der Kunde aber die DB ändert und erwartet, dass die Applikation sich daran anpasst, hat er imho was falsch verstanden. Das klappt mit keiner DB-Abstraktion, weil hinter jedem Detail eines Schemas auch Semantik stecken kann, die man nur mit Code abbilden kann.

Letztenendes funktioniert dieser Ansatz deswegen sowieso nur bei sehr generischen Applikationen. Das meinte ich oben mit "nicht praxisrelevant". Nehmen wir mal an, dass in einem Onlineshop ein Boolean darüber entscheidet, ob ein Produkt gerade auf Lager ist. Der Kunde möchte eine Mail bekommen, wenn ein Produkt ausverkauft ist. Dafür gibt es in der Applikation ein if(!$product->inStock).
Jetzt will der Kunde das alles verbessern. Er möchte im Shop die Anzahl noch verfügbarer Artikel anzeigen und wenn es weniger als 3 sind, möchte er eine Mail bekommen.
Wie soll diese Änderung umgesetzt werden? Der Kunde ändert sein DB-Schema, macht aus der SET- eine INT-Spalte. Deine DB-Abstraktion castet nun anders und mit einer kleinen Änderung in einem Template sieht man den Lagerbestand auch im Onlineshop. Aber wie wird die Mail getriggert? Da muss doch irgendwo der Schwellwert 3 in einem if verbastelt werden.

Das war ein Beispiel aus der Praxis. Fast alle Issues, die ich auf den Tisch bekomme und die eine Schemaänderung nötig machen, sehen so aus. Es ist immer irgendwas am Code zu machen. Den Kunden stört es ja nicht, dass in der App booleans statt ints herumfliegen. Das kriegt der gar nicht mit. Er möchte das Verhalten der Applikation ändern und fast jedes Verhalten ist irgendwie in Code gegossen.

Deine DB-Abstraktion ist daher nicht für den Einsatz in einer Applikation geeignet (außer DB-Verwaltungstools). Sie eignet sich vielleicht prima um einen OR-Mapper zu bauen, der aus einer bestehenden DB das Schema extrahiert und gleich ein paar Stubs und Mock-Objects. Gibts aber alles schon.

[AmicaNoctis]

So ganz "von alleine" castet sich die SET-Spalte also nicht.

Da hast du Recht. Ich meinte nur, dass das casten ziemlich intuitiv abläuft, "" == false, "true" == true.

Bin gespannt wie du das unter einen Hut bekommst.

Der Teil ist lange erledigt. Jetzt kommt nur noch der Dämon, den wollte ich aber gleich auf PHP5.3 aufbauen und dafür fehlten noch Extensions.

Edit: wenn es auf einem Shared Server läuft, passiert kein Caching. Dieses Feature bekommen nur die Kunden, die den PHP Dämon dazu nehmen. Das passt auch ganz gut mit dem finanziellen Background des Kunden zusammen. Die, die etwas mehr Geld locker machen können, laufen sowieso nicht auf nem Shared Server und die anderen nehmen die (trotzdem noch akzeptablen) Geschwindigkeitseinbußen für den Preis in Kauf.

Wenn der Kunde aber die DB ändert und erwartet, dass die Applikation sich daran anpasst, hat er imho was falsch verstanden. Das klappt mit keiner DB-Abstraktion, weil hinter jedem Detail eines Schemas auch Semantik stecken kann, die man nur mit Code abbilden kann.

Die ReST-Schnittstelle, also der Webservice, passt sich da schon automatisch an und ist auch sehr generisch. Das Frontend (AJAX) entscheidet natürlich auch noch sehr viel. Im Prinzip ist dieses Interface nur dazu da, mit JavaScript in einem Fat Client das zu machen, was man sonst in PHP macht. Die gesamte Logik steckt in den JS-Klassen. So kann der Server beim Kunden stehen oder im Netz und ist wartungsfrei. Die JS-Klassen werden dagegen von meinem Server geladen und so kann ich in minimaler Responsezeit Updates deployen, die beim nächsten Reload der Seite "eingespielt" sind.

Das Frontend realisiert dann CRMs, CMSe, Ticketsysteme und so weiter und das alles in einer Webtop-Umgebung.