<div>
<div>
Szerintem, egyre gondolunk, csak más szemszögből nézzük a dolgot. Nem JPA-s környezetről van szó (bár, általános a feladat, olyanban is felhasználásra kerül, de ez most lényegtelen). Mindössze annyi kötöttség van napjain keretrendszeri miatt, hogy ha egy "Root" proxy osztályként kötődik valamihez (entity manager-hez vagy bármi máshoz), akkor a kötődés infói ez a tool ne rontsa el. Ha a model objektumfában megvan az update-beli entitás (neve alapján), akkor azt használja; ha nincs, akkor törölje; ha új, akkor állítsa be.</div>
<div>
</div>
<div>
Nézem a ModelMapper nevű cuccot, elég robosztus, biztos, ki lehet belőle hozni ezt, csak még nem látom, hogyan...</div>
<div>
</div>
<div>
</div>
<div>
köszi!</div>
<div>
</div>
<div>
<br />
"Gábor Garami" <gabor.garami@hron.me> írta:
<blockquote style="border-left:3px solid lightGray;padding-left:3px;">
A "Root" osztályokat mindig a "model"-ből vegye, feltéve, ha szerepel<br />
az "update"-ben, de minden "Root"-on kívüli adatot pedig az<br />
"update"-ből használjon.<br />
<br />
Szerintem meg kell forditani a gondolatmenetedet. Alapvetoen a model-t<br />
updateled az update-tel, tehat csak azokat az infokat kell venni az<br />
update-bol, amik valtoztak. Az update-be pedig meg kell kotni, hogy<br />
nem kerulhet olyan valtozas, ami a root-ot erintheti.<br />
<br />
<br />
Ami _szerintem_ megoldas lehet (ha es amennyiben az 'update' pontosan<br />
ugyanolyan osztalyu, mint a 'model', hogy a sima JPA-s entitymanageres<br />
merge elott az update-ben felulvagod azokat az elemeket, amiknek nem<br />
kellene valtozni (igy azok nem is fognak valtozni), utana pedig siman<br />
csinalsz egy merge-t. Marmint, ha JPA kornyezetu a kerdes (undefined,<br />
nem irtad).<br />
<br />
Amennyiben nincs JPA a kozelben, akkor tisztan reflectionnel seem<br />
ordongosseg megoldani, foleg ha a Java Beanekre vonatkozo megkotesek<br />
nagy resze be van tartva (gondolok itt a getFoo/setFoo konvenciokra).<br />
<br />
De esetleg probalhatnad kicsit specifikalni a kornyezetet, lehet, hogy<br />
van benne olyan megoldas, amit te nem ismersz.<br />
<br />
<br />
<br />
Garami Gábor<br />
E-mail: gabor.garami@hron.me<br />
Tel: +36 20 235 9621<br />
MSN: hrgy@vipmail.hu<br />
Skype: hron84<br />
<br />
<br />
2013/9/19 Cpt <cpt@freemail.hu>:<br />
> Sziasztok,<br />
><br />
><br />
> van egy apró feladat, ami gerincében teljesen általános, itt-ott kis<br />
> specialitással. Találkoztatok már libbel, amit érdemesebb felhasználni, mint<br />
> leprogramozni?<br />
><br />
> Vannak pojo-k, amiknek van 1 közös ős osztályuk, legyen "Root", de<br />
> tetszőleges mélységű leszármaztatás lehet. Ezen kívül már csak az "alap"<br />
> osztályokat tartalmazza, mint String, Integer, Date, stb. Ilyen fa<br />
> struktúrából kettőt kell összemosni, az egyik a "model", a másik az "update"<br />
> A "Root" osztályokat mindig a "model"-ből vegye, feltéve, ha szerepel az<br />
> "update"-ben, de minden "Root"-on kívüli adatot pedig az "update"-ből<br />
> használjon. Az oka, hogy a "Root" osztályokat a "model"-ből kell venni, az<br />
> az, hogy azok lehetnek proxy osztályok is, amire nincs ráhatásom.<br />
><br />
><br />
> köszi, Gábor<br />
><br />
> _______________________________________________<br />
> Javalist mailing list<br />
> Javalist@lists.javaforum.hu<br />
> http://lists.javaforum.hu/mailman/listinfo/javalist<br />
><br />
_______________________________________________<br />
Javalist mailing list<br />
Javalist@lists.javaforum.hu<br />
http://lists.javaforum.hu/mailman/listinfo/javalist</blockquote>
</div>
</div>
<div>
</div>