[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 &#39;update&#39; pontosan
>> ugyanolyan osztalyu, mint a &#39;model&#39;, 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 &quot;Root&quot; 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.
>>
>> &nbsp;
>>
>>
>> Nézem a ModelMapper nevű cuccot, elég robosztus, biztos, ki lehet belőle
>> hozni ezt, csak még nem látom, hogyan...
>>
>> &nbsp;
>>
>> &nbsp;
>>
>> köszi!
>>
>> &nbsp;
>>
>>
>> &quot;Gábor Garami&quot;  írta:
>>
>> A&nbsp;&quot;Root&quot;&nbsp;osztályokat&nbsp;mindig&nbsp;a&nbsp;&quot;model&quot;-ből&nbsp;vegye,&nbsp;feltéve,&nbsp;ha&nbsp;szerepel
>> az&nbsp;&quot;update&quot;-ben,&nbsp;de&nbsp;minden&nbsp;&quot;Root&quot;-on&nbsp;kívüli&nbsp;adatot&nbsp;pedig&nbsp;az
>> &quot;update&quot;-ből&nbsp;használjon.
>>
>> Szerintem&nbsp;meg&nbsp;kell&nbsp;forditani&nbsp;a&nbsp;gondolatmenetedet.&nbsp;Alapvetoen&nbsp;a&nbsp;model-t
>> updateled&nbsp;az&nbsp;update-tel,&nbsp;tehat&nbsp;csak&nbsp;azokat&nbsp;az&nbsp;infokat&nbsp;kell&nbsp;venni&nbsp;az
>> update-bol,&nbsp;amik&nbsp;valtoztak.&nbsp;Az&nbsp;update-be&nbsp;pedig&nbsp;meg&nbsp;kell&nbsp;kotni,&nbsp;hogy
>> nem&nbsp;kerulhet&nbsp;olyan&nbsp;valtozas,&nbsp;ami&nbsp;a&nbsp;root-ot&nbsp;erintheti.
>>
>>
>> Ami&nbsp;_szerintem_&nbsp;megoldas&nbsp;lehet&nbsp;(ha&nbsp;es&nbsp;amennyiben&nbsp;az&nbsp;&#39;update&#39;&nbsp;pontosan
>> ugyanolyan&nbsp;osztalyu,&nbsp;mint&nbsp;a&nbsp;&#39;model&#39;,&nbsp;hogy&nbsp;a&nbsp;sima&nbsp;JPA-s&nbsp;entitymanageres
>> merge&nbsp;elott&nbsp;az&nbsp;update-ben&nbsp;felulvagod&nbsp;azokat&nbsp;az&nbsp;elemeket,&nbsp;amiknek&nbsp;nem
>> kellene&nbsp;valtozni&nbsp;(igy&nbsp;azok&nbsp;nem&nbsp;is&nbsp;fognak&nbsp;valtozni),&nbsp;utana&nbsp;pedig&nbsp;siman
>> csinalsz&nbsp;egy&nbsp;merge-t.&nbsp;Marmint,&nbsp;ha&nbsp;JPA&nbsp;kornyezetu&nbsp;a&nbsp;kerdes&nbsp;(undefined,
>> nem&nbsp;irtad).
>>
>> Amennyiben&nbsp;nincs&nbsp;JPA&nbsp;a&nbsp;kozelben,&nbsp;akkor&nbsp;tisztan&nbsp;reflectionnel&nbsp;seem
>> ordongosseg&nbsp;megoldani,&nbsp;foleg&nbsp;ha&nbsp;a&nbsp;Java&nbsp;Beanekre&nbsp;vonatkozo&nbsp;megkotesek
>> nagy&nbsp;resze&nbsp;be&nbsp;van&nbsp;tartva&nbsp;(gondolok&nbsp;itt&nbsp;a&nbsp;getFoo/setFoo&nbsp;konvenciokra).
>>
>> De&nbsp;esetleg&nbsp;probalhatnad&nbsp;kicsit&nbsp;specifikalni&nbsp;a&nbsp;kornyezetet,&nbsp;lehet,&nbsp;hogy
>> van&nbsp;benne&nbsp;olyan&nbsp;megoldas,&nbsp;amit&nbsp;te&nbsp;nem&nbsp;ismersz.
>>
>>
>>
>> Garami&nbsp;Gábor
>> E-mail:&nbsp;gabor.garami at hron.me
>> Tel:&nbsp;+36&nbsp;20&nbsp;235&nbsp;9621
>> MSN:&nbsp;hrgy at vipmail.hu
>> Skype:&nbsp;hron84
>>
>>
>> 2013/9/19&nbsp;Cpt&nbsp;:
>>>&nbsp;Sziasztok,
>>>
>>>
>>>&nbsp;van&nbsp;egy&nbsp;apró&nbsp;feladat,&nbsp;ami&nbsp;gerincében&nbsp;teljesen&nbsp;általános,&nbsp;itt-ott&nbsp;kis
>>>&nbsp;specialitással.&nbsp;Találkoztatok&nbsp;már&nbsp;libbel,&nbsp;amit&nbsp;érdemesebb&nbsp;felhasználni,&nbsp;mint
>>>&nbsp;leprogramozni?
>>>
>>>&nbsp;Vannak&nbsp;pojo-k,&nbsp;amiknek&nbsp;van&nbsp;1&nbsp;közös&nbsp;ős&nbsp;osztályuk,&nbsp;legyen&nbsp;&quot;Root&quot;,&nbsp;de
>>>&nbsp;tetszőleges&nbsp;mélységű&nbsp;leszármaztatás&nbsp;lehet.&nbsp;Ezen&nbsp;kívül&nbsp;már&nbsp;csak&nbsp;az&nbsp;&quot;alap&quot;
>>>&nbsp;osztályokat&nbsp;tartalmazza,&nbsp;mint&nbsp;String,&nbsp;Integer,&nbsp;Date,&nbsp;stb.&nbsp;Ilyen&nbsp;fa
>>>&nbsp;struktúrából&nbsp;kettőt&nbsp;kell&nbsp;összemosni,&nbsp;az&nbsp;egyik&nbsp;a&nbsp;&quot;model&quot;,&nbsp;a&nbsp;másik&nbsp;az&nbsp;&quot;update&quot;
>>>&nbsp;A&nbsp;&quot;Root&quot;&nbsp;osztályokat&nbsp;mindig&nbsp;a&nbsp;&quot;model&quot;-ből&nbsp;vegye,&nbsp;feltéve,&nbsp;ha&nbsp;szerepel&nbsp;az
>>>&nbsp;&quot;update&quot;-ben,&nbsp;de&nbsp;minden&nbsp;&quot;Root&quot;-on&nbsp;kívüli&nbsp;adatot&nbsp;pedig&nbsp;az&nbsp;&quot;update&quot;-ből
>>>&nbsp;használjon.&nbsp;Az&nbsp;oka,&nbsp;hogy&nbsp;a&nbsp;&quot;Root&quot;&nbsp;osztályokat&nbsp;a&nbsp;&quot;model&quot;-ből&nbsp;kell&nbsp;venni,&nbsp;az
>>>&nbsp;az,&nbsp;hogy&nbsp;azok&nbsp;lehetnek&nbsp;proxy&nbsp;osztályok&nbsp;is,&nbsp;amire&nbsp;nincs&nbsp;ráhatásom.
>>>
>>>
>>>&nbsp;köszi,&nbsp;Gábor
>>>
>>>&nbsp;_______________________________________________
>>>&nbsp;Javalist&nbsp;mailing&nbsp;list
>>>&nbsp;Javalist at lists.javaforum.hu
>>>&nbsp;http://lists.javaforum.hu/mailman/listinfo/javalist
>>>
>> _______________________________________________
>> Javalist&nbsp;mailing&nbsp;list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>>
>>
>> &nbsp;
>>
>> _______________________________________________
>> 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