[Javalist] pojo merge
Cpt
cpt at freemail.hu
2013. Sze. 23., H, 00:11:25 CEST
a modelmapper-t még nem ismerem kellő mélységben, de ameddig eljutottam, ez a működés, ami nekem kell, túl alacsonszíntű az ő filozófiájához: a modelmapper különböző pojo-kban gondolkodik, a property-jeit meg azonos konvenciók mentén kezeli. amit írtam, az inkább egy plugin-je lehetne a modelmapper-nek, hisz' a modelmapper funkcionalitásából semmit nem tudtam kihasználni; legfeljebb azt tudnám gazdagítani... nem ismerem még eléggé, de igen szimpatikus tool. :) a contr-ot majd meglátom. :) g
"Gábor Garami" <gabor.garami at hron.me> írta:
>40 sor, az nem is sok... :-)
>
>Meg inkabb jobb lenne valahogy a kivetelkezelest belecontributalni a
>ModelMapperbe, nem? Vagy azt bonyolult azon a szinten megoldani?
>Garami Gábor
>E-mail: gabor.garami at hron.me
>Tel: +36 20 235 9621
>MSN: hrgy at vipmail.hu
>Skype: hron84
>
>
>2013/9/20 Cpt <cpt at freemail.hu>:
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/20130923/2b1d7a22/attachment.html>
További információk a(z) Javalist levelezőlistáról