-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 7 posts ] 
Author Message
 Post subject: Datenbank Design Frage
PostPosted: Sat Jul 29, 2006 1:11 am 
Newbie

Joined: Tue Mar 28, 2006 9:31 pm
Posts: 13
Hallo, ich erklär am besten was ich machen möchte und
zeige den code dafür:


In der Datenbank sind Auftragspunkte definiert die wieder beliebig viele
andere Unterpunkte enthalten können.

Code:
@Entity
@Table(name = "taskitem")

   

    @OneToMany(mappedBy="parent", fetch=FetchType.EAGER)
   public List<TaskItem> getChilds() {
      return childs;
   }

   public void setChilds(List<TaskItem> childs) {
      System.out.println("----TaskItem: setChilds called schild size: "+childs.size());
      
      this.childs = childs;
   }
   
   
    @OneToOne(cascade = CascadeType.ALL, fetch=FetchType.EAGER)
    @JoinColumn(name = "taskItemParent_id", unique = false, nullable = true, insertable = true, updatable = true)
    public TaskItem getParent() {
        return parent;
    }
   
    public void setParent(TaskItem parent) {
        this.parent = parent;
    }



Die Sache ist die, das der Benutzer jetzt bestimme Auftragspunkte (im frontend)auswählen kann und die dann einem Auftrag zugeordenet sind.

das mache ich mittels eine joins:


Code:
@Entity
@Name("task")
@Table(name = "task")

    @ManyToMany(
            targetEntity=TaskItem.class,
            cascade={CascadeType.ALL}
    )
    public List<TaskItem> getTaskItems() {
       return this.taskItems;
    }
    public void setTaskItems(List<TaskItem> taskItems) {
       this.taskItems = taskItems;
    }


Was ich aber eingentlich machen will(und später auch muß) ist wenn eine Benutzer bestimmte Punkte ausgewählt hat, diese Punkte wieder an ihr Elternelement hängen und das Elternelement in den Auftrag speichern - nicht die Ausgewählten Kinder

Code:
    //get selection from frontend
    List<TaskItem> selectedTaskItems
   
    //get selected root tasitem (where parent is null)
    TaskItem selectedRootTaskItem.setChilds(selectedTaskItems);

    //hier hibernate sagen das das nich in die ursprünglich tabelle gehen    soll (selectedRootTaskItem hat sich verändert)
    task.setTaskItem(selectedRootTaskItem);

    //save task to database


Das geht logischerweise so nicht da ich dann die vordefinierte Struktur in der Datenbank verändern würde,die ja nur als Vorlage dient.

Ich müßte hiberate sagen das das ganze(die veränderte struktur) in eine andere Tabelle(nicht in die ursprüngliche die ja nur als vorlage dient und nicht verändert werden darf) gespeichert werden muß oder?

Geht sowas?
Ich hoffe ich konnte mich so halbwegs verständlich machen.

Vielen Dank,

Holger


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 30, 2006 6:30 am 
Beginner
Beginner

Joined: Thu Jul 20, 2006 12:08 pm
Posts: 21
Location: Germany
Hallo Holger,

ich verstehe Deine Struktur noch nicht so ganz. Verstehe ich es richtig daß:

1) Du hast einen Auftrag A
2) Auftrag A besteht aus mehreren Auftragspunkten B
3) Zu jedem B existierten beliebig viele Unterpunkte C
4) Der Anwender soll nun A laden können, B und C verändern können
5) Dann soll B gespeichert werden, nicht jedoch C ?
6) Bestehende B dürfen nicht überschrieben werden ?

HIer ist bei mir ein Knick im Gehirn , was soll er dürfen ?


grüße

ferdinand


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 30, 2006 3:06 pm 
Newbie

Joined: Tue Mar 28, 2006 9:31 pm
Posts: 13
Hallo,

ja hab ich galube auch blöde formuliert, ist auch alles net ganz so einfach ich versuch mal so zu beschreiben wie du es versucht hast.



In der Datenbank sind unveränderbar! definiert:
A) Eine Struktur von Auftragspunkten(rekursiv) die wieder beliebig viele andere Auftragspunkte enthaten kann.



2) Ich möchte jetzt dieselbe Struktur Struktur(A) wiederbenutzen, verändern(benutzer selektiert oder deselektiert bestimmte punkte) und diese veränderte Struktur(A) einem Auftrag(B) zuordnen
dabei soll Struktur A nicht in die ursprüngliche Tabelle gespeichert werden(würde ja die Vorlange überschreiben) sondern in eine andere.


Ich glaube das was ich mir da so vorstelle ist nicht möglich oder?
Wahrscheinlichmuß ich, wenn ich sowas machen will eine Extra Klasse schreiben und diese dann in eine seperate Tabelle speichern:


Code:
@Entity
@Table(name = "changeabletaskitem")
public class ChangeableTaskItem extends TaskItem

@OneToOne
public Task getTask() {
}

....



bzw den Weg gehen den ich mir erst überlegt habe das heißt nur die selektierten Auftragspukte über ein join festelegen.

Code:
    @ManyToMany(
            targetEntity=TaskItem.class,
            cascade={CascadeType.ALL}
    )
    public List<TaskItem> getTaskItems() {
       return this.taskItems;
    }
    public void setTaskItems(List<TaskItem> taskItems) {
       this.taskItems = taskItems;
    }


was aber den Nachteil hat, da sich das ganze um eine rekursive struktur handelt, gehen evtl änderungen in dieser verloren wenn man nur die oberpunkte speichert.


Puhh hoffe das versteht irgendeiner, wen nicht , net so schlimm.
Wies aussieht werde ich sowieso auf die Rekursion verzichten(müßen?), ist zwar sehr schön weil das System damit offen bleibt(erweiterbar), aber
ich kann im frontend das eh nur bis zu1ten Ebene darstellen (benutze jsf)

Aber mir gehts um Prinizip.

Vielen Dank,

Holger[/code]


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 31, 2006 4:13 am 
Beginner
Beginner

Joined: Thu Jul 20, 2006 12:08 pm
Posts: 21
Location: Germany
Hallo Holger,

was spräche denn dagegen im Fall von Änderungen

- einen neuen Auftrag B zu erzeugen
- die geänderten Punkte an B anhängen
- B speichern
- Änderungen an A mit rollback rückgängig machen

Grüße

Ferdinand

P.S.: Wieso willst Du eine weitere Tabelle anlegen ?
Wenn die Struktur identisch ist und die Aufträge sich nur wertmäßig unterscheiden,
so wären doch beide Aufträge in einer Tabelle gut aufgehoben.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 31, 2006 2:48 pm 
Newbie

Joined: Tue Mar 28, 2006 9:31 pm
Posts: 13
Quote:
Änderungen an A mit rollback rückgängig machen


Hmm das wäre in der Tat ne Möglichkeit, nur weiß ich nicht genau wie ich ein
Rollback auslöse - ich kuck mir die Api nochmal an.


"
P.S.: Wieso willst Du eine weitere Tabelle anlegen ?
Wenn die Struktur identisch ist und die Aufträge sich nur wertmäßig unterscheiden,
so wären doch beide Aufträge in einer Tabelle gut aufgehoben.
"

Nee will ich ja nicht machen - wußte mir nur nicht anders zu helfen, klar das da redundanter Code / Datenbanktabellen rauskommen, deswegen poste ich ja hier :-)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 01, 2006 3:16 am 
Expert
Expert

Joined: Tue Oct 05, 2004 9:45 am
Posts: 263
nix für ungut ... zumal ich mir auch im Moment nicht die Zeit nehmen kann über Deine Struktur nachzudenken ...

Aber wenn ich etwas nicht in der Datenbank will, schreibe ich es nicht rein. Allein der Gedanke, Änderungen in der DB zu machen und von Anfang an zu wissen, dass ich sie nur mache um sie per rollback wieder rückgängig zu machen, treibt mir Schauer über den Rücken ...

Ich hoffe das ist nicht Deine bevorzugte Lösung oder ich habe die Grundidee jetzt falsch interpretiert ...


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 01, 2006 2:28 pm 
Newbie

Joined: Tue Mar 28, 2006 9:31 pm
Posts: 13
Hallo ne mit dem Rollback hab ich seingelassen ich mach das jetzt so:


Alle TaskItem Objekte (egal ob vorlage oder einem Task zugeordnet) landen jetzt in derserben Tabelle und um die Vorlagen zu holen schreibe ich


"from TaskItem where parent = null and task = null" damit bekomme ich alle die keinem Auftrag zugeordnet sind.

Damit kann ich mit die Vorlagen holen.Beim Speichern erzeuge ich für jede Vorlage ein neues Objekt(vom selben Typ) , kopiere die Werte rein, ordne die dem Auftrag zu und speicher das ganze.

Naja so richtig gefällt mir das immer noch nicht aber es funktiniert und tut was es tun soll.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 7 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.