[2.xx] Ideensammlung

Dieser Bereich dient dazu, neue Features zu diskutieren und für die Entwicklung zu dokumentieren. // This area is dedicated to new features including proposals and documentation.
Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [2.xx] Ideensammlung

Beitrag von Megger » 18.05.2011, 10:55:23

Bei MSSQL gibt es doch zum Beispiel kein Limit, oder? Heißt das dort nicht TOP oder soetwas in der Art? Die generierten Statements vom GORM sind auf jedenfall MySQL optimiert
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 18.05.2011, 13:05:07

Achso, der GORM... Ja, das stimmt natürlich... Hmm. Wie könnte man denn dem entgegengehen!? Irgendwann erreicht man doch wieder das Henne-Ei-Problem oder nicht?
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4556
Registriert: 04.11.2007, 16:13:53

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 19.05.2011, 07:57:38

Einfach ist das sicher nicht. Andere Frameworks setzten dabei auf eine Abstraktion der SQL-Sprache, was ich persönlich nicht ideal finde, da eine zusätzliche Meta-Sprache geparst werden muss. Idee kann eine Abstraktion des GORM sein, dem unterschiedliche Sprach-Treiber injiziert werden. Diese gehen dann auf die einzelnen Datenbanken ein. Abhängigkeiten kann man ja direkt zu den Datenbank-Treibern vorsehen, dann ist die Auflösung recht einfach.

Bisher war jedoch MSSQL kein Thema - höchstens PostgreSQL-, die aber halbwegs kompatibel sein sollte.
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 19.05.2011, 08:34:15

Du nutzt doch ohnehin den ConnectionManager mit dem GORM, allerdings halte ich es für eher unglücklich zwischen den GORM und den ConnectionManager noch eine Schicht zwischen zu fügen... Aber wenn es nicht anders geht... :/

EDIT:

Ich mache mir gerade ein paar Gedanken dazu und versuche die mal kurz darzustellen:

Aktuell arbeitet der GORM so:

GDO -> GORM-> MySQL-Queries -> ConnectionManager -> DB

Hierbei werden vom GORM die Queries quasi-manuell auf MySQL-Basis zusammengebaut. Dadurch entsteht eine Inkompatibilität zu alternativen Datenbank-Systemen. Entsprechend müsste die Ebene, in der MySQL-Queries erstellt werden so umgebaut werden, dass eine - nach Möglichkeit automatische - Auftrennung in die verschiedenen Datenbank-Treiber erfolgt:

GDO -> GORM -> DB-Queries (je nach Treiber) -> ConnectionManager -> DB

Eine Idee wäre nun also die aktuelle Struktur als Interface zu definieren, sodass ein DB-Treiber für den GORM entsprechend die wichtigen Methoden definitiv bereitstellen muss.

Die Frage, die ich mir gerade stelle ist allerdings folgende: Sollte im Zuge der grötenteils Neuentwicklung des APF im 2.xx-Zweig eventuell darüber nachgedacht werden, den ConnectionManager mit dem GORM zu verschmelzen? Falls das geht!? Denn dann bräuchte man nurnoch EINEN Treiber je Datenbank und nicht je einen für den GORM und einen für den ConnectionManager ... Das aber erstmal nur ein erster Gedanke, ohne genauer über die Abhängigkeiten nachgedacht zu haben.
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [2.xx] Ideensammlung

Beitrag von Megger » 19.05.2011, 10:26:15

Die Idee ist gar nicht schlecht!
Anstatt das der GORM die Queries generiert, sollte dieser einfach die benötigten Informationen an den entsprechenden ConnectionManager schicken. Dieser baut dann die passenden Statements zusammen.
Ich hatte irgendwann schonmal den GORM umgebaut, sodass man verschiedene Datenbanksysteme verwenden konnte. Damals habe ich das ganze für SQLite2 gebaut. Das müsste auch noch irgendwo im Forum zu finden sein. Ich begebe mich gleich mal auf die Suche! Die Umsetzung war allerdings nicht so toll und die Idee mit der Integration des Connection Managers gefällt mir besser!

Edit:
Hier der Link de/viewtopic.php?f=5&t=404&p=3519&hilit=SQLite#p3519
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 19.05.2011, 11:13:41

Hmm... müsste ich mir mal anschauen, aber mir ist gerade noch eine andere Idee gekommen:

Ich habe mir gerade mal die Sources vom GORM angeschaut und da gibt es ja mehrere Methoden, die dafür sorgen, dass das SQL-Statement zusammengebaut wird. Eine davon ist zum Beispiel auch __buildWhere(), durch die ich gerade auf eine Alternative gekommen bin: Was wäre - wenn man anstatt eigene Treiber zu verwenden - einfach die entsprechenden Statement-Elemente in Templates für das jeweilige DB-System zur Verfügung stellt? Ich weiß leider nicht, ob das klappen kann oder ob ich andere Datenbank-Spezifische Elemente übersehen habe!? Aber vielleicht wäre das ja eine praktikable Lösung für den GORM, indem man ihm mittels ini-File einfach die Formate für die jeweilige Datenbank mitteilt. Für MySQL könnte das in etwa so aussehen:

Code: Alles auswählen

[MySQL]
FIELD = "`{FIELD_NAME}`"
STRING = "'{STRING}'"
EQUAL = "="
NOT_EQUAL = "<>"
LIKE = "LIKE"
INNER_JOIN = "INNER JOIN"
OUTER_JOIN = "OUTER JOIN" 
und so weiter. Aber ich glaube dann kommt das wieder dem sehr nahe, was Christian meinte mit der "Abstraktion des SQL"?! :(
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 19.05.2011, 11:27:46

Hmm... Irgendwie sind die Lösungen alle nicht so toll und wenn man überlegt, dass jeder Treiber dann die Funktionen __buildWhere() & Co. ersetzen bzw. definieren soll könnte das sehr schnell sehr viel Code produzieren, der teilweise das Gleiche macht. Jetzt war mein nächster Gedankengang der, dass man den ohnehin zugriffsfähigen DB-Treiber aus dem ConnectionManager ($this->__DBDriver) nutzt, um bestimmte Dinge direkt vom Treiber des ConnectionManagers zu erledigen. Hierfür würde ich dann nur die Teile ausgliedern, die aktuell in den GORM integriert sind. Als Beispiel mal folgende Zeile:

Code: Alles auswählen

$select .= ' WHERE `'.$sourceObject['Table'].'`.`'.$sourceObject['ID'].'` = \''.$object->getProperty($sourceObject['ID']).'\'';
 
Das würde ich dann eventuell so auslagern:

Code: Alles auswählen

$select .= $this->__DBDriver->buildWhere ('`'.$sourceObject['Table'].'`.`'.$sourceObject['ID'].'`', '=', $object->getProperty($sourceObject['ID']));
 
Oder sind auch die Klammerungen von Tabellen- und Feldnamen unterschiedlich in den verschiedenen Datenbank-Systemen? Dann müsste man eventuell eine Fallunterscheidung einbauen, in der man z.B. prüft, ob der erste und dritte Parameter ein Array oder ein String ist. Bei einem String würde man dann den Inhalt direkt verwenden und mit den typischen Kommata einklammern (bei MySQL entsprechend '), bei einem Array müsste z.B. der Wert "Table" und "Field" vorhanden sein, sodass dann hier die entsprechende Notation zusammengebaut würde. Beispielsweise:

Code: Alles auswählen

function getAsSQLValue ($mValue)
{
  if (is_array ($mValue) === TRUE)
  {
    return '`'.$mValue['Table'].'`.`'.$mValue['Field'].'`';
  }
  else
  {
    return '\''.(string)$mValue.'\'';
  }
}
 
Dann bräuchte man nurnoch in den jeweiligen Methoden einmal den Parameter durch diese Methode parsen lassen und gut wäre es!?

Vorschläge? Ideen? Anmerkungen? Beschimpfungen? :)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [2.xx] Ideensammlung

Beitrag von Megger » 19.05.2011, 11:59:36

Es wäre sicher sinnvoll sich erstmal die Syntax von ein paar Datenbanksystemen anzuschauen! Ich kenne eigentlich auch nur MySQL und SQLite2 (eine schreckliche Syntax :D)
Welche Systeme sind denn wichtig?
- MySQL
- PostreSQL
- MSSQL ?
- SQLite ?
- NoSQL ?
Und um das ganze komplett durcheinander zu bringen -> CouchDB :D Nein nur ein Scherz

Also das mit den config Dateien finde ich nicht gut, dass wird glaube ich zu unübersichtlich! Deine letzte Idee ist doch eigentlich deine erste Idee, oder? Also zumindestens hatte ich deine erste Idee so verstanden, dass der ConnectionManager den Zusammenbau der Statements übernimmt und man dadurch nur noch einen passenden ConnectionManager bzw. DBDriver schreiben muss und schon beherrscht der GORM diese Sache, dass wäre ein gewaltiger Fortschritt (dadurch könnte der GORM dann theoretisch mit jedem Datenbanksystem kommunizieren)
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 19.05.2011, 12:34:26

Ja, das war auch eine Idee von mir weiter oben, aber frag mich jetzt nicht, die wievielte das ist, ich bin selber durcheinandergekommen momentan ;)

Das mit den Config-Files war auch nur ein Gedankengang, zu dem ich mal ein paar Meinungen haben wollte.

Grundsätzlich würde ich aber nicht versuchen wollen den GORM in seiner Funktion auf bestimmte Datenbank-Systeme zu beschränken, denn der Sinn einer generischen Schnittstelle wie dem GORM ist es ja komplett unabhängig zu sein.
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [2.xx] Ideensammlung

Beitrag von Megger » 19.05.2011, 13:21:45

Wenn die Generierung der Statements vom ConnectionManager bzw. DbTreiber übernommen wird, ist der GORM ja unabhängig! Es sollte dann so sein, dass ich mir einen neuen Treiber schreiben kann und der GORM damit funktioniert. Man sollte sich halt mal die anderen Systeme anschauen um zu prüfen, welche Parameter übergeben werden müssen
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von Screeze » 19.05.2011, 13:33:44

Mich würde gerade mal interessieren, wie sehr sich die DB systeme unterscheiden untereinander.
Das Problem hört ja vermutlich nicht bei der Syntax auf oder? Ansonsten wäre es vermutlich wirklich das einfachste einen Treiber für den GORM zu bieten, der für jedes statement das generiert werden muss (und die sammelmethoden) eine eigene Funktion bereithält die der GORM aufrufen kann um das Statement zu bekommen. DIeses übergibt er dann dem DBDriver um die Daten abzuholen.

Den DBDriver generieren lassen würde ich vermutlich nicht, da sind die Abhängigkeiten sonst unter Umständen zu groß.

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [2.xx] Ideensammlung

Beitrag von Megger » 19.05.2011, 15:25:08

Aber warum einen extra GORM Treiber schreiben, wenn der DBTreiber schon vorhanden ist? Eine Abhängigkeit besteht doch so oder so schon! Wenn man natürlich den DBTreiber austauschen wollte, also zum Beispiel nicht den APF internen DBTreiber bzw. ConnectionManager nutzen will, dann muss man nur sicherstellen, dass die Methoden auch vorhanden sind.
Also ich würde versuchen, die Statement Generierung über den DBTreiber zu realisieren. Wenn man nun noch einen GORMTreiber einbaut, dann blickt bald keiner mehr beim GORM durch.
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [2.xx] Ideensammlung

Beitrag von MrNiceGuy » 19.05.2011, 16:48:23

So, wie ich das sehe funktioniert der GORM ohne den ConnectionManager so oder so nicht, also dürfte es keine größere Abhängigkeit geben, als ohnehin schon!?
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von Screeze » 19.05.2011, 16:49:16

ich meinte das der DBdriver abhänigkeiten bekommt, die nur durch den GORM auftreten

Benutzeravatar
dr.e.
Administrator
Beiträge: 4556
Registriert: 04.11.2007, 16:13:53

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 19.05.2011, 20:32:33

Hallo zusammen,

die unterschiedlichen Datenbank-Systeme unterscheiden sich in Syntax und Verhalten einer Query. Ersteres könnte man ja noch halbwegs einfach über eine Statement-Abstraktion regeln, die zwischen GORM und DB-Driver liegt, die zweite Geschichte ist richtig unschön, da man Statements pro DBMS unterschiedlich generieren muss.

Eine weitere Alternative wäre, alle Statements des GORM auszulagern und entsprechend zu dokumentieren. Dann könnte man einfach die Config-Files (*.sql) austauschen und müsste den Code nicht anpassen. Sofern das zu langsam ist, injiziert man dem GORM einfach noch einen Statement-Provider und lagert dorthin alle Methoden der Statement-Generierung aus. Dieser kann dann pro DBMS implementiert werden.

Letzteres halte ich bei gleichzeitiger Umstellung auf DI für die besser Wahl.
Viele Grüße,
Christian

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste