Allgemeine Fragen zum G-ORM

[Thalo]

Morgen,

beim durchstöbern der Dokumenation für den GORM ist mir aufgefallen, dass dort die ID-Spalten immer vom Typ tinyint sind. Tinyint ist ja nun sehr klein gewählt. Gibt es hier einen besonderen Grund?

Was mich auch irritiert ist, dass die Relationstabellen einen Primärschlüssel benötigen. Wofür genau wird der benötigt?

Desweiteren wäre eine Mehode sich den Query zu Debuggingszwecken ausgeben zu lassen sinvoll.

[MrNiceGuy]

Moin!

Also erstmal sind die PKs vom Typ INT und nicht TINYINT.

Das mit dem PK in den Relation-Tables habe ich auch schon mehrfach angesprochen, aber bisher wurde das noch nicht geändert

Zum Thema Debugging kann ich nicht viel sagen, aber es gibt wohl eine Möglichkeit das Logging zu aktivieren (wenn es das nicht schon standardmäßig ist) und diese schreibt dann ja eventuell den Query in die entsprechende Log-Datei!?

MfG
Lutz

[dr.e.]

Hallo ihr beiden,

Was mich auch irritiert ist, dass die Relationstabellen einen Primärschlüssel benötigen. Wofür genau wird der benötigt?

Das erhöht bei großen Daten-Mengen die Selektivität des Indizes auf der Tabelle, sofern mehrere Beziehungen des gleichen Typs zu den gleichen Objekten vorhanden sind. Es handelt sich also um eine Optimierungs-Maßnahme, die IMHO nicht schadet. Denn: eine INT-Spalte belegt nicht so viel Speicherplatz.

Desweiteren wäre eine Mehode sich den Query zu Debuggingszwecken ausgeben zu lassen sinvoll.

Das gibt es natürlich, denn nur so ist es möglich, die erzeugten Abfragen zu Performance-Optimierungs-Zwecken auch analysieren oder zum Debuggen der Anwendung nutzen zu können. Hierzu muss beim Erzeugen des GORM über die Factory der 5.te Parameter auf true gesetzt werden. Dieser bewirkt, dass alle Abfragen in eine Log-Datei geschrieben werden. Eine direkte Ausgabe macht keinen Sinn, denn sonst produzierst du bei Session-basierten Applikationen ständig "Cannot send session limiter"-Fehler. Die Doku zu diesem Parameter findest du im Kapitel Erzeugen einer Instanz des GORM.

[Screeze]

Zu der sache mit dem Bigint als ID, das wolltest du doch mal einbaun Christian, was ist daraus geworden?

Alternativ kann ich natürlich noch eine Option in das Setup- und Update-Tool einbauen, mit dem der Datentyp für Index- und ID-Spalten definiert werden kann - parallel zu Storage-Engine?

Ich baue eine Option ein und melde mich, sobald der Code im SVN verfügbar ist.

Zitat aus
viewtopic.php?f=1&t=80&hilit=ID+int&start=120

[dr.e.]

Hallo Ralf,

das ist eine berechtigte Frage, das muss bei mir untergegangen sein. Damit das nicht nochmal passiert habe ich das gleich in die Roadmap aufgenommen. Einbauen werde ich das zusammen mit den zusätzlichen Indizes.

[Screeze]

Ok.

Wo wir grade dabei sind, ich hätt auch ne Frage:
Um sicherzugehen dass ich in einer Funktion das RICHTIGE GenericDomainObject bekomme, müsst ich auf $__ObjectName zugreifen, allerdings scheint keine solche funktion vorhanden zu sein, und die get() funktionen bist du ja grad alle am rauswerfen.
Wie finde ich raus welcher Objekttyp (name) das genau ist?

[dr.e.]

Hi Ralf,

ich habe in einem weiteren Checkin die Verwendung von get() für den Namen entfernt. Auf Basis der aktuellen SVN-Version kommst du wie folgt an den Namen:

$user = new GenericDomainObject('User');
echo $user->getObjectName();

Der Name des Objekts muss bei der Instanziierung immer mitgegeben werden. Erzeugst du selbst ein Objekt, bist du als Entwickler dafür verantwortlich. Beziehst du Objekte vom GORM, wird das für dich erledigt.

In 1.11 funktioniert das Code-Snippet wie folgt:

$user = new GenericDomainObject('User');
echo $user->get('ObjectName');

[Screeze]

Alles klar, danke.

[Thalo]

Hey Guys ,

Also erstmal sind die PKs vom Typ INT und nicht TINYINT.

Also in der Dokumenation unter Manuelles Setup

Code: Alles auswählen

`ApplicationID` tinyint(5) NOT NULL auto_increment, 

Code: Alles auswählen

 `GroupID` tinyint(5) NOT NULL auto_increment, 

Code: Alles auswählen

`UserID` tinyint(5) NOT NULL auto_increment, 

usw.

Das erhöht bei großen Daten-Mengen die Selektivität des Indizes auf der Tabelle, sofern mehrere Beziehungen des gleichen Typs zu den gleichen Objekten vorhanden sind. Es handelt sich also um eine Optimierungs-Maßnahme, die IMHO nicht schadet. Denn: eine INT-Spalte belegt nicht so viel Speicherplatz.

Das les ich nun zum ersten mal.. Im Manual hab ich dazu auch nichts finden können. Kannst du da etwas näher drauf eingehen? Meinem Verständnis nach kann immer nur 1 Index benutzt werden.

Wird der {AttributTyp} nur für das automatische Setup der Datenbank benötigt? Wenn ja, kann ich diesen nicht auch weglassen? Da beim automatischen Setup ja keine weiteren Konfigurationen möglich sind, muss ich ja sowieso noch mal Hand anlegen. Wenn ich dann im nachinein den Typ ändere, würde ich dies an zwei Stellen erledigen müssen.

[dr.e.]

Hi Thalo,

Also in der Dokumenation unter Manuelles Setup

Korrekt, dort stehen in den Beispiel-Statements noch "TINYINT". Hierzu habe ich jedoch im SVN (ab Revision ) eine Möglichkeit hinzugefügt, dies beim Setup/Update ändern zu können. Beispiel:

Code: Alles auswählen

$setup = new GenericORMapperSetup();
$setup->setIndexColumnDataType('BIGINT(100) UNSIGNED');

Das les ich nun zum ersten mal.. Im Manual hab ich dazu auch nichts finden können. Kannst du da etwas näher drauf eingehen? Meinem Verständnis nach kann immer nur 1 Index benutzt werden.

Mir hat das mal ein Oracle-DBA erklärt und ich habe das deshalb so umgesetzt. Im Rahmen des neuen Features Zusätzliche Indizes für Setup-/Update-Tool GORM werde ich mir das Thema nochmal genauer ansehen und einige Performance-Tests für MySQL durchführen.

Wird der {AttributTyp} nur für das automatische Setup der Datenbank benötigt?

Ja, wird er.

Wenn ja, kann ich diesen nicht auch weglassen?

Nein, er gehört zur Definition eines Attributes schon dazu.

Da beim automatischen Setup ja keine weiteren Konfigurationen möglich sind, muss ich ja sowieso noch mal Hand anlegen. Wenn ich dann im nachinein den Typ ändere, würde ich dies an zwei Stellen erledigen müssen.

Warum ist beim automatischen Setup keine Konfiguration möglich? Du kannst jeden beliebigen Daten-Typen nutzen. Sofern du diesen ändern musst, kannst du das Update-Tool nutzen. So bleibt die config die zentrale Stelle der Änderung.