[1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relations

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.
Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

[1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relations

Beitrag von MrNiceGuy » 09.08.2012, 05:27:20

Moin moin!

Ich bin gerade am grübeln, wie das umgesetzt werden könnte. Mein erster Gedanke war einfach eine Methode im GDO anzubieten, über die man eine entsprechende - interne - Variable ausliest, die vom GORM automatisch gesetzt wird, wenn das jeweilige Datum vorhanden ist. Nun komme ich aber an einen Punkt wo ich gerade überlege: Ist es überhaupt sinnvoll ein Änderungsdatum zu haben? Also Entweder erstelle oder lösche ich doch eine Beziehung!? Eine Bearbeitung wäre nur dann erforderlich, wenn - vielleicht auch später?! - die Möglichkeit gegeben wäre zusätzlich noch weitere Daten in der Verknüpfung zu speichern, ist das irgendwann einmal vorgesehen? Wenn ja sollte es wohl besser ein eigenes Object werden (neben GDO und GCO dann zusätzlich ein GRO)!?

Für mich wäre das an dieser Stelle interessant, da ich das dann gleich so umsetzen würde, das erspart dann später weitere Arbeit. Ein Vorschlag wäre dann entsprechend eine Methode anzugeben, über die man explizit das Relation-Object ziehen kann. Dabei schweben mir dann zwei Varianten vor, die beide eingebaut werden sollten:
Zum Einen im GORM selbst eine Methode wie loadRelated*(), die statt des verknüpften Objekts eben das Verknüpfungs-Object zurückgibt
und zum Anderen eine Methode loadRelation() im GDO, die einem das Relation-Object zurückgibt. Um den Fall abzufangen, dass es kein Relation-Object geben kann (z.B. weil ein GDO manuell erstellt wurde oder ein Object direkt ausgelesen wurde) wäre mein Vorschlag einen Standard-Rückgabewert von null einzubauen oder eine Exception zu werfen. Was wäre eurer Meinung nach besser? Damit das GRO geladen werden kann bedarf es dann einer entsprechenden Vorbereitung durch die Methode loadRelated*(), die dem GDO mitteilt, dass es ein GRO gibt.

Alternativ - und das ist wahrscheinlich der Weg, den es insgesamt später gehen müsste - wäre die direkte Übergabe eines GRO denkbar, um eben auch Daten in der Verknüpfung speichern zu können. Sprich: Es gibt im GDO eine Eigenschaft in der das GRO gespeichert würde, standardmäßig aber null enthalten ist und dann gibt es eben die get-/set-Methoden für das GRO.

Das mal so meine flüchtigen Gedanken, bevor sie gleich wieder weg sind - Anmerkungen? Verbesserungen? Schelte? :D
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: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von Megger » 09.08.2012, 11:04:17

Hi

Klingt interessant!Darüber haben wir schon öfters mal diskutiert! Ein Beziehungsobjekt zu haben ist auf jedenfall interessant!
...wäre mein Vorschlag einen Standard-Rückgabewert von null einzubauen oder eine Exception zu werfen
Da würde ich null zurückgeben, wie es jetzt halt auch schon ist, wenn man ein Verknüpfungs-Objekt laden will und es keins gibt!
Es gibt im GDO eine Eigenschaft in der das GRO gespeichert würde
Wäre auf jedenfall sinnvoll, dann würde aus

Code: Alles auswählen

[ObjektA] --> [Status] <-- [ObjektB]
nur noch ein

Code: Alles auswählen

[ObjektA] <--> [ObjektB]
werden, wenn man davon ausgeht, dass das Status Objekt nur dafür da ist um zum Beispiel zu speichern, dass ObjektA 10x ObjektB besitzt oder so
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
dr.e.
Administrator
Beiträge: 4556
Registriert: 04.11.2007, 16:13:53

Re: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von dr.e. » 10.08.2012, 10:12:16

Hallo Lutz,

ich denke ebenso, dass die Umsetzung nur dann richtig interessant ist, wenn das Beziehungsobjekt tatsächlich selbst konfigurierbare Daten besitzt - siehe Beispiel von Tobi.
Viele Grüße,
Christian

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

Re: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von MrNiceGuy » 10.08.2012, 12:16:20

Nunja, die Daten der Erstellung der Verknüpfung halte ich so auch schon für interessant genug. Die Frage ist halt, ob auch Daten in den Verknüpfungen gespeichert werden sollen, dann würde ein solches Konstrukut:

Tabelle 1 <-> Relation 1 <-> Tabelle 1-2 <-> Relation 2 <-> Tabelle 2

nurnoch so aussehen:

Tabelle 1 <-> Relation <-> Tabelle 2

Jetzt möchte ich halt wissen, wie umfangreich das werden soll, denn es müssten ja auch Änderungen am Setup/Update gemacht und die Abfragestruktur insgesamt massiv angepasst werden. Oder lieber erstmal die kleine Lösung und das dann für 2.0 vorsehen?
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: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von dr.e. » 10.08.2012, 12:54:36

Hallo Lutz,

für "meine" Anwendungsfälle reicht mir der aktuelle Funktionsumfang. Soweit ich die Diskussionen richtig in Erinnerung habe sind dort zwei Dinge auf der Liste gewesen:
  • Eine Beziehung soll ein Erzeugungs- und/oder Bearbeitungsdatum besitzten um nachvollziehen zu können, wann diese angelegt und/oder bearbeitet wurde.
  • Einer Beziehung sollen eigene Attribute mitgegebenen werden können um diese zu qualifizieren (z.B. für welche Farbe steht die "Color"-Beziehung).
Darüber hinaus haben wir mehfrach den Anwendungsfall von Tobi besprochen - vollwertige Beziehungsobjekte zu Klassifizierung von Objekten. Hierfür habe ich die Meinung vertreten eigene Typ-Objekte zu definieren und Tobi's Ansicht nach wäre die Umsetzung einfacher, wenn eine Beziehung direkt zur Klassifizierung eingesetzt werden könnte.

Um die o.g. Punkte zu realisieren wäre in der Tat ein Redesign des GORM notwendig - zumindest um es vernünftig zu gestalten. Sobald Beziehungen einen eigene, unabhängige Bedeutung erhalten sollten sie - wie du schon beschreibst - als eigene Objekte realisiert werden. Dann ist auch das Anlegen von Attributen für diese Objekte sehr einfach zu regeln und in das Setup/Update zu integrieren.

Ich schlage daher vor, ein Proposal im Wiki zuverfassen um eine neue Modellierung von Objekten (GDO, GCO, GRO) besser diskutieren zu können. Einverstanden?
Viele Grüße,
Christian

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

Re: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von MrNiceGuy » 10.08.2012, 21:13:42

Hmm... dann muss ich mich daran wohl mal versuchen!? Kann aber etwas dauern, ist ja dann doch nicht "mal eben so" realisiert. Wenn du mir dabei helfen magst: nur zu :D
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: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von dr.e. » 11.08.2012, 12:35:20

Ich helfe gerne. Dazu schlage ich vor, dass du dir die Struktur des GORM genauer ansiehst und ein Proposal schreibst, das die Änderungen und die neue Struktur definiert. Anschließend können wir das zusammen diskutieren und ich kann dir bei der Implementierung helfen.
Viele Grüße,
Christian

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

Re: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von MrNiceGuy » 24.08.2012, 07:14:16

Moin!

Ich habe mich erstmal für die kleine Lösung entschieden und die Änderungen soweit fast abgeschlossen. Danach muss ich noch die Funktionalität verifizieren und kann es dann einchecken. Es wird dann erstmal nur ein CreationTimestamp geben, dass man über das GDO auslesen kann (der Wert wird automatisch vom GORM gefüllt, sobald das Objekt über eine Relation geladen wurde; Das Datum entspricht dann dem Datum der entsprechenden Relation).

Ich denke heute Abend werde ich die nötige Zeit haben das abzuschließen. Das Proposal werde ich danach dann angehen, aber die Änderungen sind vermutlich ohnehin so weitreichend, dass ich nicht sicher bin, ob eine Realisierung vor 2.x sinnvoll ist.

Lutz
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: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von MrNiceGuy » 24.08.2012, 23:52:39

So, ich bin dann soweit durch mit dem Thema:

Um das Feature zu aktivieren muss in der Relation-Config der Parameter "Timestamps" auf "TRUE" gesetzt sein:

Code: Alles auswählen

[table2table]
Type = "ASSOCIATION"
SourceObject = "table1"
TargetObject = "table2"
Timestamps = "TRUE"
Das Setup- und das Update-Tool sind entsprechend angepasst und ändern die Konfiguration auch bei bestehenden Datensätzen - allerdings kommen bei alten Datensätzen natürlich keine entsprechenden Daten in das Feld "CreationTimestamp" der Relation ;)

Ansonsten wird der Wert abgerufen, indem man nach dem Laden einer Relation die Methode getRelationCreationTimestamp() aufruft - Rückgabewert ist das MySQL-Timestamp-Format:

Code: Alles auswählen

$aGDO2 = $oGDO1->getRelatedObjects ('table2table');
foreach ($aGDO2 AS &$oGDO2)
{
  echo $oGDO2->getRelationCreationTimestamp();
} 
Der Inhalt aus dem CreationTimestamp wird bei Verwendung der getRelation*-Methoden automatisch in das Rückgabe-GDO injiziert. In obigem Beispiel würde man das selbe Ergebnis erhalten, wenn man es von der "anderen Seite" aus abfragen würde (also von "GDO2" die Relation laden, dann enthielte das "GDO1" entsprechend die Information).

Anmerkungen, Fragen und Verbesserungen können gerne an mich herangetragen werden.

Lutz

PS: Ein Bearbeitungs-Datum ist in dieser Form der Verknüpfung nicht notwendig, da es neben dem Erstellen und Löschen keine Bearbeitung gibt. Dieses Feature wird später Bestandteil der weiteren Aufbohrung dieser Funktion, wenn Relations auch eigene Properties enthalten können (vermutlich aber nicht mehr in 1.16).
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: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von dr.e. » 25.08.2012, 11:43:21

Hallo Lutz,

danke für deine Arbeit! Sobald du eingecheckt hast, schaue ich mir den Code an und gebe dir Feedback.

Welche Bestandteile sollten wir der Dokumentation sponsoren?
Viele Grüße,
Christian

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

Re: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von MrNiceGuy » 25.08.2012, 12:46:18

Ist doch schon eingecheckt!? Habe ich jedenfalls letzte Nacht gemacht :)

Die Doku würde ich höchstens etwas erweitern - undzwar um den optionalen Parameter Timestamps. Ist dieser nicht gesetzt oder auf etwas Anderes als "TRUE", ist das Verhalten wie vorher -> also abwärtskompatibel.

Dann noch kurz beschreiben, wie man den Timestamp auslesen kann und das sollte es gewesen sein. Ich hoffe nur, dass die neue Funktion den GORM nicht zu sehr belastet, das zu testen schien mir gestern irgendwie nicht mehr so möglich zu sein .oO( Was ruft denn da? Mein Bett? ) ;)
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: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von dr.e. » 25.08.2012, 13:14:05

Hi Lutz,

hatte heute noch kein svn up ausgeführt. Jetzt sehe ich deine Änderungen. Feedback folgt. :)
Die Doku würde ich höchstens etwas erweitern - undzwar um den optionalen Parameter Timestamps. Ist dieser nicht gesetzt oder auf etwas Anderes als "TRUE", ist das Verhalten wie vorher -> also abwärtskompatibel.
Passt.
Dann noch kurz beschreiben, wie man den Timestamp auslesen kann und das sollte es gewesen sein.
Das sollten wir auf jeden Fall beschreiben.
Ich hoffe nur, dass die neue Funktion den GORM nicht zu sehr belastet, das zu testen schien mir gestern irgendwie nicht mehr so möglich zu sein .oO( Was ruft denn da? Mein Bett? ) ;)
Sollte mir beim Coding etwas dahingehend auffallen, gebe ich Bescheid. Falls nicht warte ich einfach auf deinen Test.
Viele Grüße,
Christian

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

Re: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von MrNiceGuy » 25.08.2012, 13:31:17

Dann muss ich mir erstmal einen Test einfallen lassen, mit dem sich das überhaupt testen lässt ;)

Eigentlich kann die Schwachstelle ja nur da sein, an dem eine Schleife alle Objekte durchläuft um den Timestamp zu extrahieren. Ich gucke mir das mal an, heute Abend habe ich ja wieder Zeit, wenn die Kleine im Bett und die Große ausm Haus ist ;)
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: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von dr.e. » 25.08.2012, 13:41:24

Ich gucke mir das mal an, heute Abend habe ich ja wieder Zeit, wenn die Kleine im Bett und die Große ausm Haus ist ;)
:D
Viele Grüße,
Christian

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

Re: [1.16] Erzeugungs- und Bearbeitungsdatum für GORM-Relati

Beitrag von MrNiceGuy » 25.08.2012, 20:52:48

Also: Ich habe einmal getestet, wieviel die gesamte Aufgabe an Zeit frist, wenn ich 400 verbundene Datensätze lade (sprich: zwei Tabellen, verbunden mit einer Association und in Tabelle 1 einen Datensatz, der mit 400 Datensätzen in Tabelle 2 verbunden ist). Das Ergebnis zeigt, dass das extrahieren der Timestamps zwischen 0,0022 und 0,0024 s benötigt, im Mittel also ca. 0,0023 s. Die Gesamtzeit zum Laden der Objekte inklusive (!) der Extraktion benötigt zwischen 0,028 und 0,032 s also im Mittel ca. 0,030 s. Damit steht also fest, dass diese Funktion etwa 7,7% der Gesamtzeit benötigt - oder andersrum: Mit dieser Funktion benötigt der GORM ca. 8,3% mehr an Zeit.

Leider wirkt sich dieses Minus auch dann aus, wenn die Fuktion ansich garnicht genutzt wird, deshalb habe ich die Verarbeitung noch einmal verarbeitet, dass die Abarbeitung nur dann erfolgt, wenn auch wirklich ein derartiges Feld enthalten ist (vorher hat er in dem Falle einfach ein NULL aus der DB ausgelesen und extrahiert, dabei war der Wert des CreationTimestamps bereits per default auf null). Nun verbraucht die ganze Geschichte nurnoch zwischen 0,000071 und 0,000076 s - ich denke, dass das hinnehmbar ist (für die Abwärtskompatibilität).

Neuer Code ist eingecheckt!
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast