[Solved] Mapping 1:0,1 unidirektional

ChrLipp · **Joined:** Thu Jul 24, 2008 3:33 am **Posts:** 20

Habe eine Frage bezüglich des Mappings von 2 Tabellen, Tabelle "Vorgang" und "VorgangsStatistik".

Beide Tabellen verwenden diesselbe ID, die zweite Tabelle nimmt Details auf,
d.h. ein Eintrag in "VorgangsStatistik" kann zu einem bestehenden Eintrag in "Vorgang" vorhanden sein, muss aber nicht.
Man soll von Vorgang zu VorgangsStatistik navigieren können, aber nicht umgekehrt.

Wenn ich nun einen Vorgang suche, möchte ich nicht, dass ein SELECT für VorgangsStatistik abgesetzt wird.
Genau das bringe ich aber nicht hin und bitte daher um Hilfe.

Mein Code - Klasse Vorgang:

Code:

@Entity
@Table(name="VORGANG")
public class Vorgang
{
   @Id
   @Column(name="ID")
   private String id;
   
   /**
    * Zugehörige Statistik
    */
   @OneToOne(fetch=FetchType.LAZY)
   @PrimaryKeyJoinColumn
   private VorgangsStatistik vorgangsStatistik;
}

Mein Code - Klasse VorgangsStatistik:

Code:

@Entity
@Table(name="VORGANGSSTATISTIK")
public class VorgangsStatistik
{
   @Id
   @Column(name="ID")
   String id;

}

Nun das Problem, bei folgender Zeile

Code:

Vorgang vorgang = vorgangDao.find(transactionId);

werden zwei Selects ausgelöst, erst wird der Vorgang gesucht, danach die zugehörige VorgangsStatistik.
Wie verhindere ich das?

Danke für Eure Hilfe,
CL

mmerder · **Posted:** Thu Jan 29, 2009 8:16 am

wie sieht der Inhalt der VorgangDAO aus?

ChrLipp · **Joined:** Thu Jul 24, 2008 3:33 am **Posts:** 20

mmerder wrote:

wie sieht der Inhalt der VorgangDAO aus?

Das find ist im Vorgänger und sieht wie folgt aus:

Code:

   /**
    * Ermittelt ein Objekt über die ID.
    * Sofortige DB-Abfrage, existiert gesuchter Datensatz nicht, wird NULL returniert.
    * @param id      Primary key des Objektes
    * @return         Das gesuchte Objekt
    */
   @Override
   @SuppressWarnings("unchecked")
   public T find(ID id)
   {
        return (T) sessionFactory.getCurrentSession().get(type, id);
   }

Danke, CL

ChrLipp · **Joined:** Thu Jul 24, 2008 3:33 am **Posts:** 20

Habe gerade gesehen, dass ich dasselbe Problem (immer noch nicht gelöst) schon mal gepostet habe (siehe http://forum.hibernate.org/viewtopic.php?t=988983),) aber durch Einfügen von Lazy von einen Outerjoin zu 2 SELECTs gekommen bin. Auch habe ich gegenüber den alten Post die Richtung unidiretional gemacht.

mmerder · **Posted:** Thu Jan 29, 2009 9:10 am

Wenn du eine OneToOne-Assoziation über den Primary Key machst, muss hibernate das select ausführen, um zu prüfen, ob die Referenz nicht null ist. Es kann schließlich nicht einen Proxy erstellen, obwohl da null drin sein sollte. Hast du statt des PKs einen extra FK, geht es einfach davon aus, dass wenn der FK nicht null ist, es auch eine Statistik gibt.
Dies ist hiersehr gut erklärt.

Du kannst das select verhindern, indem du die Beziehung als optional=false mappst (@OneToOne(fetch=FetchType.LAZY, optional=false)). Dann muss es jedoch zu jedem Vorgang definitiv eine Statistik geben.

Rating ist willkommen. ;-)

ChrLipp · **Joined:** Thu Jul 24, 2008 3:33 am **Posts:** 20

Danke für den Link und die Antwort.
Jetzt ist es mir klar, auch wenn es mir nicht gefällt.

Eine Alternative (die im Link fehlt, wahrscheinlich weil sie schlecht ist oder nicht funktioniert):

Beziehung als one-to-many definieren, Container als private Instanzvariable anlegen und im Getter bzw. im Setter nur auf das 1. Element losgehen. Somit würde das SELECT verhindert, allerdings habe ich eine Collection zusätzlich im Speicher, auch wenn nur ein Objekt drin ist.

mmerder · **Posted:** Thu Jan 29, 2009 10:15 am

Da ist das optional=false doch die beste Lösung, oder?

ChrLipp · **Joined:** Thu Jul 24, 2008 3:33 am **Posts:** 20

Bin mir nicht sicher.

Wenn ich optional=false verwende, was passiert, wenn ich darauf mittels Getter zugreife? Hibernate wird einen Proxy verwenden und beim ersten Zugriff in die DB gehen und dann eine Exception werfen, weil der Satz ja nicht existiert, nehme ich an. Diese Exception kann ich aber nicht fangen, weil diese im Code meiner Clients liegt (sprich bei dem, der den Getter aufruft).

Wenn ich aber die Collection verwende, die als Proxy aggiert, dann kann ich im Getter auf das Einzelobjekt den Zugrif abfangen und wenn die Statistik nicht existiert, null zurückgeben.

Was würdest du dazu sagen?
Danke, CL

mmerder · **Posted:** Thu Jan 29, 2009 10:35 am

Ok, das stimmt natürlich. Du hast also drei möglichkeiten:
1. Ignoriere den zusätzlichen select. ;-) Viel Performance kostet er nicht.
2. Mach den select über ein join. dann hast du wenigstens nur ein statement.
3. Leg immer eine Statistik an, diese kann ja auch noch leer sein.

ChrLipp · **Joined:** Thu Jul 24, 2008 3:33 am **Posts:** 20

Oder 4) die im vorigen Post skizzierte Variante mit der Collection. Die probiere ich aus. Das 2. Statement ist auf jeden Fall weg, soviel sehe ich schon.

Ich danke dir, du hast mir sehr geholfen.
CL