[Javalist] JPA joincolumn fix értékkel

[Tamás Bódis]

Nos. Fogjuk rá, hogy megoldódott a probléma :)
*Az EmbeddedId megoldás nem működőképes (vagy legalábbis nem tudtam azzal
megoldani)*

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:

   - cache bekapcsolása után hogy reagál majd az alkalmazás
   - az nagyszerű, hogy lookup esetén a megfelelő értékeket tölti fel, de
   insert/update esetén nem világos miket ellenőriz


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.


*Viszont még1 JPA érdekesség (EclipseLink és Hibernate is ugyanazt csinálja
alapból): *
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 :)
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.

Üdv,
// Tamás

2012/9/4 Bartuszek Viktor <viktor.bartuszek at rhodeus.hu>

> Hello,
>
> Esetleg @EmbeddedId nem lehet megoldás?
>
>
> http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Entities/Ids/EmbeddedId
>
> 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 :))
>
> üdv,
> --
> Bartuszek Viktor
>
>
>
> 2012/9/3 Tamás Bódis <tamas.bodis at gmail.com>
>
>> 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)
>> 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).
>>
>> // Tomi
>>
>> 2012/9/3 cx.chico <cx.chico at gmail.com>
>>
>> Szia!
>>>
>>>
>>> OpenJPA esetében (non-standard "constant join"):
>>> http://stackoverflow.com/questions/9809178/jpa-joincolumn-annotation
>>>
>>>
>>> EclipseLink (extension):
>>>
>>> http://wiki.eclipse.org/EclipseLink/Examples/JPA/MappingSelectionCriteria#Example_2:_.27active_.3D.3D_true.27_in_1:M
>>> Ezen belül számodra a "Example 2: 'active == true' in 1:M" rész lehet
>>> érdekes.
>>>
>>> Úgy rémlik, hogy EclipseLink-kel már  megcsináltam máshogy is, de most
>>> nem jut eszembe, hogyan, de utánanézek ha szükséges.
>>>
>>> Üdv,
>>> Chico
>>>
>>>
>>>
>>> Tamás Bódis <tamas.bodis at gmail.com> írta (2012. szeptember 3. 8:12):
>>> > Sziasztok!
>>> >
>>> >     A következő lenne a feladat. Van 1 nem kimondottan ORM-ből
>>> generálódott
>>> > táblaszerkezetünk amiben van az YYY és a SZOTAR tábla. A Szótár tábla
>>> ilyen
>>> > nagy összefogó szótár, amelynek bár van saját kulcsa, de van egy
>>> > kategória&kulcs oszlop párja, ami szintén egyedi. A lényeg, hogy a
>>> különböző
>>> > táblák nem tényleges külső kulccsal, hanem csak a sima kategória&kulcs
>>> > párból a kulcs értékkel kapcsolódnak. Ez azért 'elég' ebben az
>>> esetben, mert
>>> > minden Szótár kapcsolatnál FIX, hogy mi maga a szótár kapcsolat
>>> Kategóriája.
>>> >   Nos a kérdésem az, hogy ezt a FIX részt milyen megoldással lehetne
>>> megadni
>>> > a JPA-nak? Kb. ilyesmire gondoltam.
>>> >
>>> > @Entity
>>> > public class Szotar {
>>> >    @Id
>>> >    private int id;
>>> >    @...
>>> >    private String kategoria;
>>> >    @...
>>> >    private String kulcs;
>>> >    ....
>>> > }
>>> >
>>> > @Entity
>>> > public class YYY {
>>> >     ....
>>> >    @JoinColumns({
>>> >
>>> >         @JoinColumn(name="'fixenmegadottkategorianev'",
>>> > referencedColumnName="kategoria"),
>>> >         @JoinColumn(name="szotar_oszlop", referencedColumnName="kulcs")
>>> >     })
>>> >
>>> >    )
>>> >    private Szotar
>>> >
>>> > }
>>> >
>>> > Ez egy ennyire extrém mapping igény lenne részemről?
>>> > Jah és EclipseLink aktuálisan a provider, bár más megoldás is
>>> érdekelhet.
>>> >
>>> > Érdekesség kép az openjpa úgy tűnik támogatja ezt
>>> >
>>> http://openjpa.apache.org/docs/latest/ref_guide_mapping_notes_nonstdjoins.html
>>> >
>>> > Köszi!
>>> > // Tamás
>>> >
>>> >
>>> > _______________________________________________
>>> > Javalist mailing list
>>> > Javalist at lists.javaforum.hu
>>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>>> >
>>> _______________________________________________
>>> Javalist mailing list
>>> Javalist at lists.javaforum.hu
>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>
>>
>>
>>
>> --
>> Üdv,
>> // Tamás
>>
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>


-- 
Üdv,
// Tamás
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20120905/6e49796b/attachment.html>