Nos. Fogjuk rá, hogy megoldódott a probléma :)<div><i>Az EmbeddedId megoldás nem működőképes (vagy legalábbis nem tudtam azzal megoldani)</i><br><div><br></div><div>A lenti cikk alapján viszont sikerült is összekötni az entitásokat, s minden szépen is működik (látszólag). Viszont elvetettem ezt az EclipseLink-es @Customizer-es megoldást, mert egyrészt "szerintem" elég csúnya, másrészt az idő rövidsége miatt nem látom át, s kipróbálni sincs időm, hogy minden eshetőségben jó fog működni. Pl. ilyesmikre gondolok:</div>
<div><ul><li>cache bekapcsolása után hogy reagál majd az alkalmazás</li><li>az nagyszerű, hogy lookup esetén a megfelelő értékeket tölti fel, de insert/update esetén nem világos miket ellenőriz</li></ul><div><br></div><div>
Bár nem túl bonyolult ezek tesztelése, de amíg kitaláltam addigra be kellett a fejlesztést fejezni :) úgyhogy más megoldás született. Alapvetően a JPA-s @EntityListeners megoldás + cache mögötte amiből validálunk és amiből lookup-olunk (ez is teljesen jól működik, s jóval átláthatóbb). A JPA-k felülete semmiben nem változott az @EntityListeners-es megoldásban, úgyhogy gyakorlatilag elég kevés helyen érintette a kódot.</div>
</div><div><br></div><div><br></div><div><u>Viszont még1 JPA érdekesség (EclipseLink és Hibernate is ugyanazt csinálja alapból): </u></div><div>SQL Server + EcliseLink + identity PK-s tábla + persist művelet. Teljesen jól működik az alkalmazás addig, amíg egy audit jellegű trigger nem kerül rá egyik táblára (miért ne kerülne, hisz ez nem az "alkalmazást" érintő változtatás), ami egy history táblába másolja az aktuális változatot insert-kor is. a probléma az, hogy az ORM eszközök tipikusan a "SELECT @@Identity" utasítással kérik vissza a persist művelet után a létrehozott rekord azonosítóját. Nos ebben az esetben a history tábla azonosítóját kapják meg :)</div>
<div>Van persze rá megoldás, ami most úgy tűnik, hogy működik, s mindkét ORM eszközben simán megoldható. Ezt a "SELECT @@Identity"-t le kell cserélni "SELECT SCOPE_IDENTITY()"-re.</div><div><br></div><div>
Üdv,</div><div>// Tamás<br><div><br><div class="gmail_quote">2012/9/4 Bartuszek Viktor <span dir="ltr"><<a href="mailto:viktor.bartuszek@rhodeus.hu" target="_blank">viktor.bartuszek@rhodeus.hu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br><br>Esetleg @EmbeddedId nem lehet megoldás?<br><br><a href="http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Entities/Ids/EmbeddedId" target="_blank">http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Entities/Ids/EmbeddedId</a><br>
<br>Megpróbálnám az említett "kulcs" mezőket EmbeddedId segítségével összefogni, és arra hivatkozni a joinColumn-ban. (csak egy kósza ötlet :))<br><br>üdv,<br clear="all">--<br>Bartuszek Viktor<div class="HOEnZb">
<div class="h5"><br>
<br><br><div class="gmail_quote">2012/9/3 Tamás Bódis <span dir="ltr"><<a href="mailto:tamas.bodis@gmail.com" target="_blank">tamas.bodis@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>OpenJPA-s megoldást láttam, s eddig ez lenne a legjobb, de openjpa-ra nem válthatunk (Hibernate vagy eclipselink megoldásra van szükség)</div><div>Az eclipselink-es lenti megoldást már megtaláltuk, s épp ezt próbálgatjuk, de személy szerint nem tartom túl elegánsnak ezt a változatot (az openjpa-s sokkal egyszerűbb és átláthatóbb).</div>
<div><br></div><div>// Tomi<br><br><div class="gmail_quote">2012/9/3 cx.chico <span dir="ltr"><<a href="mailto:cx.chico@gmail.com" target="_blank">cx.chico@gmail.com</a>></span><div><div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Szia!<br>
<br>
<br>
OpenJPA esetében (non-standard "constant join"):<br>
<a href="http://stackoverflow.com/questions/9809178/jpa-joincolumn-annotation" target="_blank">http://stackoverflow.com/questions/9809178/jpa-joincolumn-annotation</a><br>
<br>
<br>
EclipseLink (extension):<br>
<a href="http://wiki.eclipse.org/EclipseLink/Examples/JPA/MappingSelectionCriteria#Example_2:_.27active_.3D.3D_true.27_in_1:M" target="_blank">http://wiki.eclipse.org/EclipseLink/Examples/JPA/MappingSelectionCriteria#Example_2:_.27active_.3D.3D_true.27_in_1:M</a><br>
Ezen belül számodra a "Example 2: 'active == true' in 1:M" rész lehet érdekes.<br>
<br>
Úgy rémlik, hogy EclipseLink-kel már megcsináltam máshogy is, de most<br>
nem jut eszembe, hogyan, de utánanézek ha szükséges.<br>
<br>
Üdv,<br>
Chico<br>
<br>
<br>
<br>
Tamás Bódis <<a href="mailto:tamas.bodis@gmail.com" target="_blank">tamas.bodis@gmail.com</a>> írta (2012. szeptember 3. 8:12):<br>
<div><div>> Sziasztok!<br>
><br>
> A következő lenne a feladat. Van 1 nem kimondottan ORM-ből generálódott<br>
> táblaszerkezetünk amiben van az YYY és a SZOTAR tábla. A Szótár tábla ilyen<br>
> nagy összefogó szótár, amelynek bár van saját kulcsa, de van egy<br>
> kategória&kulcs oszlop párja, ami szintén egyedi. A lényeg, hogy a különböző<br>
> táblák nem tényleges külső kulccsal, hanem csak a sima kategória&kulcs<br>
> párból a kulcs értékkel kapcsolódnak. Ez azért 'elég' ebben az esetben, mert<br>
> minden Szótár kapcsolatnál FIX, hogy mi maga a szótár kapcsolat Kategóriája.<br>
> Nos a kérdésem az, hogy ezt a FIX részt milyen megoldással lehetne megadni<br>
> a JPA-nak? Kb. ilyesmire gondoltam.<br>
><br>
> @Entity<br>
> public class Szotar {<br>
> @Id<br>
> private int id;<br>
> @...<br>
> private String kategoria;<br>
> @...<br>
> private String kulcs;<br>
> ....<br>
> }<br>
><br>
> @Entity<br>
> public class YYY {<br>
> ....<br>
> @JoinColumns({<br>
><br>
> @JoinColumn(name="'fixenmegadottkategorianev'",<br>
> referencedColumnName="kategoria"),<br>
> @JoinColumn(name="szotar_oszlop", referencedColumnName="kulcs")<br>
> })<br>
><br>
> )<br>
> private Szotar<br>
><br>
> }<br>
><br>
> Ez egy ennyire extrém mapping igény lenne részemről?<br>
> Jah és EclipseLink aktuálisan a provider, bár más megoldás is érdekelhet.<br>
><br>
> Érdekesség kép az openjpa úgy tűnik támogatja ezt<br>
> <a href="http://openjpa.apache.org/docs/latest/ref_guide_mapping_notes_nonstdjoins.html" target="_blank">http://openjpa.apache.org/docs/latest/ref_guide_mapping_notes_nonstdjoins.html</a><br>
><br>
> Köszi!<br>
> // Tamás<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Javalist mailing list<br>
> <a href="mailto:Javalist@lists.javaforum.hu" target="_blank">Javalist@lists.javaforum.hu</a><br>
> <a href="http://lists.javaforum.hu/mailman/listinfo/javalist" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
><br>
_______________________________________________<br>
Javalist mailing list<br>
<a href="mailto:Javalist@lists.javaforum.hu" target="_blank">Javalist@lists.javaforum.hu</a><br>
<a href="http://lists.javaforum.hu/mailman/listinfo/javalist" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
</blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Üdv,<div>// Tamás</div><br>
</font></span></div>
<br>_______________________________________________<br>
Javalist mailing list<br>
<a href="mailto:Javalist@lists.javaforum.hu" target="_blank">Javalist@lists.javaforum.hu</a><br>
<a href="http://lists.javaforum.hu/mailman/listinfo/javalist" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
<br></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Javalist mailing list<br>
<a href="mailto:Javalist@lists.javaforum.hu">Javalist@lists.javaforum.hu</a><br>
<a href="http://lists.javaforum.hu/mailman/listinfo/javalist" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Üdv,<div>// Tamás</div><br>
</div></div></div>