[Javalist] pojo merge
Cpt
cpt at freemail.hu
2013. Sze. 20., P, 12:15:02 CEST
Az archívum kedvéért :) Végülis a ModelMapper-ből nem tudtam ezt a működést kierőszakolni, mert nem találtam lehetőséget property-k másolásának kivételkezelésére; nekem kellett volna a Pojo property-jeit végigiterálnom. Így inkább a org.apache.commons.beanutils.BeanUtils csomagot felhasználva írtam egy cirka 40 laza soros merge-ölőt. Peresze ezt a megoldást be lehetne csomagolni egy ModelMapper Converter-be, ha kéne a ModelMapper robosztussága. Gábor
Cpt <cpt at freemail.hu> írta:
>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. Nézem a ModelMapper nevű cuccot, elég robosztus, biztos, ki lehet belőle hozni ezt, csak még nem látom, hogyan... köszi!
>"Gábor Garami" <gabor.garami at hron.me> írta:
>>A "Root" osztályokat mindig a "model"-ből vegye, feltéve, ha szerepel
>>az "update"-ben, de minden "Root"-on kívüli adatot pedig az
>>"update"-ből használjon.
>>
>>Szerintem meg kell forditani a gondolatmenetedet. Alapvetoen a model-t
>>updateled az update-tel, tehat csak azokat az infokat kell venni az
>>update-bol, amik valtoztak. Az update-be pedig meg kell kotni, hogy
>>nem kerulhet olyan valtozas, ami a root-ot erintheti.
>>
>>
>>Ami _szerintem_ megoldas lehet (ha es amennyiben az 'update' pontosan
>>ugyanolyan osztalyu, mint a 'model', hogy a sima JPA-s entitymanageres
>>merge elott az update-ben felulvagod azokat az elemeket, amiknek nem
>>kellene valtozni (igy azok nem is fognak valtozni), utana pedig siman
>>csinalsz egy merge-t. Marmint, ha JPA kornyezetu a kerdes (undefined,
>>nem irtad).
>>
>>Amennyiben nincs JPA a kozelben, akkor tisztan reflectionnel seem
>>ordongosseg megoldani, foleg ha a Java Beanekre vonatkozo megkotesek
>>nagy resze be van tartva (gondolok itt a getFoo/setFoo konvenciokra).
>>
>>De esetleg probalhatnad kicsit specifikalni a kornyezetet, lehet, hogy
>>van benne olyan megoldas, amit te nem ismersz.
>>
>>
>>
>>Garami Gábor
>>E-mail: gabor.garami at hron.me
>>Tel: +36 20 235 9621
>>MSN: hrgy at vipmail.hu
>>Skype: hron84
>>
>>
>>2013/9/19 Cpt <cpt at freemail.hu>:
>>> Sziasztok,
>>>
>>>
>>> van egy apró feladat, ami gerincében teljesen általános, itt-ott kis
>>> specialitással. Találkoztatok már libbel, amit érdemesebb felhasználni, mint
>>> leprogramozni?
>>>
>>> Vannak pojo-k, amiknek van 1 közös ős osztályuk, legyen "Root", de
>>> tetszőleges mélységű leszármaztatás lehet. Ezen kívül már csak az "alap"
>>> osztályokat tartalmazza, mint String, Integer, Date, stb. Ilyen fa
>>> struktúrából kettőt kell összemosni, az egyik a "model", a másik az "update"
>>> A "Root" osztályokat mindig a "model"-ből vegye, feltéve, ha szerepel az
>>> "update"-ben, de minden "Root"-on kívüli adatot pedig az "update"-ből
>>> használjon. Az oka, hogy a "Root" osztályokat a "model"-ből kell venni, az
>>> az, hogy azok lehetnek proxy osztályok is, amire nincs ráhatásom.
>>>
>>>
>>> köszi, Gábor
>>>
>>> _______________________________________________
>>> 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
>
>
>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.
>
>
>
>Nézem a ModelMapper nevű cuccot, elég robosztus, biztos, ki lehet belőle hozni ezt, csak még nem látom, hogyan...
>
>
>
>
>
>köszi!
>
>
>
>
>"Gábor Garami" írta:
>
>A "Root" osztályokat mindig a "model"-ből vegye, feltéve, ha szerepel
>az "update"-ben, de minden "Root"-on kívüli adatot pedig az
>"update"-ből használjon.
>
>Szerintem meg kell forditani a gondolatmenetedet. Alapvetoen a model-t
>updateled az update-tel, tehat csak azokat az infokat kell venni az
>update-bol, amik valtoztak. Az update-be pedig meg kell kotni, hogy
>nem kerulhet olyan valtozas, ami a root-ot erintheti.
>
>
>Ami _szerintem_ megoldas lehet (ha es amennyiben az 'update' pontosan
>ugyanolyan osztalyu, mint a 'model', hogy a sima JPA-s entitymanageres
>merge elott az update-ben felulvagod azokat az elemeket, amiknek nem
>kellene valtozni (igy azok nem is fognak valtozni), utana pedig siman
>csinalsz egy merge-t. Marmint, ha JPA kornyezetu a kerdes (undefined,
>nem irtad).
>
>Amennyiben nincs JPA a kozelben, akkor tisztan reflectionnel seem
>ordongosseg megoldani, foleg ha a Java Beanekre vonatkozo megkotesek
>nagy resze be van tartva (gondolok itt a getFoo/setFoo konvenciokra).
>
>De esetleg probalhatnad kicsit specifikalni a kornyezetet, lehet, hogy
>van benne olyan megoldas, amit te nem ismersz.
>
>
>
>Garami Gábor
>E-mail: gabor.garami at hron.me
>Tel: +36 20 235 9621
>MSN: hrgy at vipmail.hu
>Skype: hron84
>
>
>2013/9/19 Cpt :
>> Sziasztok,
>>
>>
>> van egy apró feladat, ami gerincében teljesen általános, itt-ott kis
>> specialitással. Találkoztatok már libbel, amit érdemesebb felhasználni, mint
>> leprogramozni?
>>
>> Vannak pojo-k, amiknek van 1 közös ős osztályuk, legyen "Root", de
>> tetszőleges mélységű leszármaztatás lehet. Ezen kívül már csak az "alap"
>> osztályokat tartalmazza, mint String, Integer, Date, stb. Ilyen fa
>> struktúrából kettőt kell összemosni, az egyik a "model", a másik az "update"
>> A "Root" osztályokat mindig a "model"-ből vegye, feltéve, ha szerepel az
>> "update"-ben, de minden "Root"-on kívüli adatot pedig az "update"-ből
>> használjon. Az oka, hogy a "Root" osztályokat a "model"-ből kell venni, az
>> az, hogy azok lehetnek proxy osztályok is, amire nincs ráhatásom.
>>
>>
>> köszi, Gábor
>>
>> _______________________________________________
>> 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
>
>
>
>
>_______________________________________________
>Javalist mailing list
>Javalist at lists.javaforum.hu
>http://lists.javaforum.hu/mailman/listinfo/javalist
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20130920/1553b0b5/attachment.html>
További információk a(z) Javalist levelezőlistáról