View Issue Details

IDProjectCategoryView StatusLast Update
0000216GORM[Adventure PHP Framework] Neues Feature // New Featurepublic2015-05-31 16:03
ReporterGeneral CrimeAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status feedbackResolutionopen 
Product Version[Adventure PHP Framework] 2.1 
Target VersionFixed in Version 
Summary0000216: Keine Prüfung beim erstellen von Kind-Objekten mit COMPOSITION Relation.
DescriptionMir ist aufgefallen das der GORM keine Prüfung mehr durchführt wenn ich ein Objekt speicher welches eine Pflichtverbindung zu einem Eltern-Objekt haben muss.

Wenn dies entfernt wurde und ich es nicht mitbekommen habe bitte ich um Entschuldigung.
Tagsgorm
Codereferenz: ([Datei]:[Zeile])

Activities

ChristianAchatz

2014-07-01 12:36

administrator   ~0000423

Hallo GeneralCrime,

magst du kurz Input geben, unter welchen Umständen die Komposition entfernt werden können?

General Crime

2014-07-01 14:56

developer   ~0000424

Verstehe nicht ganz was das löschen von Objekten mit dem Problem beim erstellen zutun hat? Das löschen wird korrekt geprüft ab Zeile GenericOrRelationMapper:831.

Es geht hier darum das beim speichern keine Prüfung existier bsp:
Tab 1: Strassen (Kind)
Tab 2: Städte (Eltern)
Composition: Source.Städte, Target.Strassen

Wenn ich nun mittels saveObject eine Strasse erstelle ohne vorher anzugeben zu welcher Stadt sie gehört funktioniert dies ohne Probleme. Dieses Verhalten gab es früher meines er achtens nicht da Kamm eine Meldung das man das ElternObjekt mit angeben muss.

dingsda

2014-07-01 20:43

developer   ~0000425

soweit ich bei github in der hystorie sehen konnte, gab es noch nie ein prüfung bei der methode saveObject, ob das SourceObject des zu speichernden kompinierten(?) Objektes existiert.

Entfernt wurde es also nicht, sondern eher vergessen. Oder nicht als aufgabe der GORM erachtet? letztere würde aber keinen sinn machen, da ja auch an anderen stellen verhindert wird, dass ein Objekt oder sein "vater-objekt" existiert.

dingsda

2014-07-01 22:18

developer   ~0000427

Last edited: 2014-07-01 22:22

View 3 revisions

zur lösung könnte die methode saveObject in etwa so verändert werden (ungetestet, nur schnell hingeklatscht)


   public function saveObject(GenericORMapperDataObject &$object, $saveEntireTree = true) {

      // inject o/r mapper into the object to be able
      // to execute custom operations (e.g. create/remove relations)!
      $object->setDataComponent($this);

      // changes start --------------------------------------------------------------------------

      // check if Object is composed and save parent
      $compositions=$this->getCompositionsByObjectName($object->getObjectName(),'target');

      if(!empty($compositions)){
         $parent= $object->getRelatedObjects($compositions[0]);

         if($parent===null){
            throw new GenericORMapperException('bitte vaterobjekt angeben oder so');
         }

         $this->saveObject($parent);

      }

      // changes end -------------------------------------------------------------------------------

      // call event handler
      $object->beforeSave();

      // save the current object (uses parent function with no resolving for relations)
      $id = parent::saveObject($object);

      // in case the user likes to only save this object, the id is returned for further usage.
      if ($saveEntireTree === false) {
         // call event handler
         $object->afterSave();

         return $id;
      }

      // check if object has related objects in it
      $relatedObjects = & $object->getAllRelatedObjects();
      if (count($relatedObjects) > 0) {

         foreach ($relatedObjects as $relationKey => $DUMMY) {
            
            // changes start -----------------------------------------------------------------------------------

            if($this->relationTable[$relationKey]['Type']==='COMPOSITION' && $this->relationTable[$relationKey]['TargetObject']===$object->getObjectName()){
               // we have saved the parent Object before the current object
               // so we do not save it again
               continue;
            }

            // changes end -------------------------------------------------------------------------------------
            
    .... rest von methode unverändert

General Crime

2014-07-01 23:55

developer   ~0000428

Hm naja bin mir fast zu 99% sicher das es das mal gab vor github aber kann mich auch irren. Die Funktion wäre allerdings wie schon erwähnt nicht verkehrt wenn es schone eine prüfung auf Kinder gibt beim löschen der Eltern sollte es auch umgekehrt sein das ein Elternobjekt halt existieren muss beim erstellen des Kindes. logischer nur bei cmp weils ja halt pflicht ist.

ChristianAchatz

2014-08-05 18:06

administrator   ~0000471

Hallo Christian,

die Funktion gab/gibt es bisher nur beim Löschen. Bei der Migration von SVN auf GIT habe ich einen Abgleich der Inhalte aus beiden Repos durchgeführt um sicher zu stellen, dass kein Code verloren geht.

Beim Erstellen kannst du nicht wirklich verbindlich verlangen, dass ein Eltern-Objekt existiert, denn sonst kannst du das erste Objekt (seines Typs) in der Datenbank nicht mehr speichern - dieses hat logischerweise keine Eltern.

Diese Logik muss daher in einer Applikation abgefangen bzw. enthalten sein.

Darf ich das Issue schließen?

General Crime

2014-08-07 12:19

developer   ~0000476

Naja ein Elternobjekt wird ja durch:
"Source_Object" definiert d.h. wenn zb das Objekt Article nirgends im CMP als "Target_Object" deklariert wurde ist es das oberste Objekt.

ChristianAchatz

2014-08-08 13:42

administrator   ~0000478

Das ist technisch absolut korrekt. Die Frage ist nur, ob das Framework die fachliche Anforderung dahinter auch verstehen kann. Manchmal ist es ja auch OK, wenn eine solche Situation auftritt.

Ich brauche also im GORM ein zweites Indiz, um eine solche Prüfung zu erlauben. Hier könnte ich mir ein zweites Konfigurations-Atribut für die Beziehung oder auch ein Setting für den GORM generell (wird dann nur schwierig mit dem automatisierten Anlegen des initialen Objekts).

Mein Vorschlag: lass uns mal alle Fälle in einem Feature-Request zusammentragen und als Erweiterung des GORM einstellen. Passt für dich?

dingsda

2014-08-09 15:40

developer   ~0000479

"Das ist technisch absolut korrekt. Die Frage ist nur, ob das Framework die fachliche Anforderung dahinter auch verstehen kann. Manchmal ist es ja auch OK, wenn eine solche Situation auftritt."
Versteh ich jetzt nicht ganz warum das für das Framework ein Problem sein sollte.
Und vor allem wann solch eine Situation denn ok wäre. Imho ist es doch so, dass eine Komposition eine starke Bindung zwischen dem zwei Objekten. Das Target darf nicht existieren ohne ein Source. Daher dürfte es keine Situation geben in der das ok ist sonst wär es eine Assoziation statt eine Komposition.

ChristianAchatz

2014-08-10 21:29

administrator   ~0000480

Natürlich darf das sein: und zwar beim ersten Objekt, das du in der Datenbank speicherst und dieses den Root-Knoten eines (rekursiven) Baums darstellt... ;)

General Crime

2014-08-10 22:35

developer   ~0000481

Last edited: 2014-08-10 22:36

View 2 revisions

Ja Root das ist logisch aber das Root Objekt hat "kein" Eltern Objekt.

Dingsda hat da schon recht.

Was bringt mir die Prüfung, beim löschen eines Elternobjektes, welches noch Kinder hat. Wenn ich auf der anderen Seite Kinder erstellen kann ohne Eltern.

Selbst Biologisch macht es (auf natürliche weise) keinen sinn.

ChristianAchatz

2014-08-11 15:34

administrator   ~0000484

Last edited: 2014-08-11 15:35

View 2 revisions

Es soll kein falscher Eindruck entstehen, ich bin NICHT gegen das Feature, sondern ich habe lediglich auf den Grenzfall hingewiesen. :)

Ich bekräftige meinen Vorschlag daher: lass uns alle Fälle in einem Feature-Request zusammentragen und als Erweiterung des GORM einstellen. Übernehmt ihr das? Dann können wir das für 3.1 einplanen.

ChristianAchatz

2015-04-15 09:23

administrator   ~0000570

Priorität angepasst (Schwerer Fehler -> Feature Wunsch).

Issue History

Date Modified Username Field Change
2014-06-28 09:19 General Crime New Issue
2014-07-01 12:36 ChristianAchatz Note Added: 0000423
2014-07-01 12:37 ChristianAchatz Status new => feedback
2014-07-01 14:56 General Crime Note Added: 0000424
2014-07-01 14:56 General Crime Status feedback => new
2014-07-01 20:43 dingsda Note Added: 0000425
2014-07-01 22:18 dingsda Note Added: 0000427
2014-07-01 22:21 dingsda Note Edited: 0000427 View Revisions
2014-07-01 22:22 dingsda Note Edited: 0000427 View Revisions
2014-07-01 23:55 General Crime Note Added: 0000428
2014-07-01 23:55 General Crime Tag Attached: gorm
2014-08-05 18:06 ChristianAchatz Note Added: 0000471
2014-08-07 12:19 General Crime Note Added: 0000476
2014-08-08 13:42 ChristianAchatz Note Added: 0000478
2014-08-09 15:40 dingsda Note Added: 0000479
2014-08-10 21:29 ChristianAchatz Note Added: 0000480
2014-08-10 22:35 General Crime Note Added: 0000481
2014-08-10 22:36 General Crime Note Edited: 0000481 View Revisions
2014-08-11 15:34 ChristianAchatz Note Added: 0000484
2014-08-11 15:35 ChristianAchatz Note Edited: 0000484 View Revisions
2015-04-15 09:22 ChristianAchatz Severity major => minor
2015-04-15 09:22 ChristianAchatz Status new => feedback
2015-04-15 09:23 ChristianAchatz Note Added: 0000570
2015-04-15 09:23 ChristianAchatz Severity minor => feature
2015-05-31 16:03 ChristianAchatz Reproducibility always => N/A
2015-05-31 16:03 ChristianAchatz Category Bug => Neues Feature // New Feature