One question is probably whether it's worth adding something like a MapperResolver instead of referring to the mapper class directly.
On Fri, Nov 15, 2013 at 11:10 AM, Thomas Hug <[email protected]> wrote: > Finally found some spare time to get back to this. You can find an API > proposal at [1] and a sample repository at [2]. > Suggestions? > > [1] > https://github.com/thomashug/DeltaSpike-Mirror/tree/master/deltaspike/modules/data/api/src/main/java/org/apache/deltaspike/data/api/mapping > [2] > https://github.com/thomashug/DeltaSpike-Mirror/blob/master/deltaspike/modules/data/impl/src/test/java/org/apache/deltaspike/data/test/service/SimpleMappedRepository.java > > > > On Tue, Oct 1, 2013 at 5:44 PM, Thomas Hug <[email protected]> wrote: > >> +1 on the feature, just been busy on a project where that would have been >> handy. >> >> And apologies for letting the thread quiet, will I'll try to propose >> something over the next two weeks based on the initial API suggestion (and >> get some other JIRA issues finally done...). >> >> >> On Tue, Oct 1, 2013 at 4:31 PM, Jean-Louis MONTEIRO >> <[email protected]>wrote: >> >>> Yep, I still think it's useful. >>> >>> JLouis >>> >>> >>> 2013/10/1 Romain Manni-Bucau <[email protected]> >>> >>> > Not particularly >>> > >>> > the thread ends while the feature is useful IMO so simply asking what >>> to do >>> > next ;) >>> > >>> > *Romain Manni-Bucau* >>> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> > *Blog: **http://rmannibucau.wordpress.com/*< >>> > http://rmannibucau.wordpress.com/> >>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> > *Github: https://github.com/rmannibucau* >>> > >>> > >>> > >>> > 2013/10/1 Jason Porter <[email protected]> >>> > >>> > > Was this my action item? >>> > > >>> > > Sent from my iPhone >>> > > >>> > > > On Oct 1, 2013, at 7:43, Romain Manni-Bucau <[email protected] >>> > >>> > > wrote: >>> > > > >>> > > > Hi >>> > > > >>> > > > any news on it? >>> > > > >>> > > > @ResultMapper was good to me >>> > > > >>> > > > *Romain Manni-Bucau* >>> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> > > > *Blog: **http://rmannibucau.wordpress.com/*< >>> > > http://rmannibucau.wordpress.com/> >>> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> > > > *Github: https://github.com/rmannibucau* >>> > > > >>> > > > >>> > > > >>> > > > 2013/7/12 Jason Porter <[email protected]> >>> > > > >>> > > >> On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau >>> > > >> <[email protected]>wrote: >>> > > >> >>> > > >>> Ps: you can make a cdi bean an ejb from cdi extension >>> > > >>> >>> > > >> >>> > > >> No, the bootstrapping for each container do not communicate to my >>> > > >> knowledge. >>> > > >> >>> > > >> >>> > > >>> Le 12 juil. 2013 08:12, "Romain Manni-Bucau" < >>> [email protected]> >>> > a >>> > > >>> écrit : >>> > > >>> >>> > > >>>> Hi >>> > > >>>> >>> > > >>>> Depending the case DTO are not an option. >>> > > >>>> >>> > > >>>> I agree in rest app i wouldnt it but if not possible (maybe >>> through >>> > > >>>> another Bean) it would kill this module for half of the usages >>> i see >>> > > >>> since >>> > > >>>> i'd need to add this layer. >>> > > >>>> Le 12 juil. 2013 06:55, "hantsy" <[email protected]> a écrit >>> : >>> > > >>>> >>> > > >>>>> No DTO please, data module for data access, why we care about >>> DTO. >>> > > >>>>> >>> > > >>>>> A question about the data, the difference for EJB and none EJB >>> > > >>>>> environment. >>> > > >>>>> >>> > > >>>>> if possible in a EJB envoriment, proxy the Repository and add >>> > > >> @Stateless >>> > > >>>>> and transaction declaration to Repository automatically at >>> runtime. >>> > > >>>>> >>> > > >>>>> Regards >>> > > >>>>> >>> > > >>>>> Hantsy >>> > > >>>>>> On 7/10/2013 23:23, Thomas Hug wrote: >>> > > >>>>>> I wouldn't label the feature with DTO but rather as some >>> general >>> > > >>> result >>> > > >>>>>> transformation - might also be useful for e.g. native queries. >>> > Going >>> > > >>>>> back >>> > > >>>>>> to the API suggestion, from that perspective such an >>> annotation >>> > > >> should >>> > > >>>>>> probably also work on method level, so I'd keep the forEntity >>> out >>> > > >>> there. >>> > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament < >>> > > >>> [email protected] >>> > > >>>>>> wrote: >>> > > >>>>>> >>> > > >>>>>>> Personally, I don't like this idea. >>> > > >>>>>>> >>> > > >>>>>>> A DAO should do DAO stuff. >>> > > >>>>>>> A DTO should do DTO stuff. >>> > > >>>>>>> >>> > > >>>>>>> The transformation of your entities into some other POJO >>> > shouldn't >>> > > >> be >>> > > >>>>>>> inside your DAO. >>> > > >>>>>>> >>> > > >>>>>>> Right now, I use google guava to do DTO work on entities >>> going >>> > back >>> > > >>> and >>> > > >>>>>>> forth over a REST API. Works well IMHO. >>> > > >>>>>>> >>> > > >>>>>>> John >>> > > >>>>>>> >>> > > >>>>>>> >>> > > >>>>>>> On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau >>> > > >>>>>>> <[email protected]>wrote: >>> > > >>>>>>> >>> > > >>>>>>>> globally my answer meant "if forEntity is sometimes >>> mandatory, >>> > > >>>>> sometimes >>> > > >>>>>>>> not this is maybe not the right place" >>> > > >>>>>>>> >>> > > >>>>>>>> i thought to add it to mapper config >>> > > >>>>>>>> >>> > > >>>>>>>> *Romain Manni-Bucau* >>> > > >>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> > > >>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*< >>> > > >>>>>>>> http://rmannibucau.wordpress.com/> >>> > > >>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> > > >>>>>>>> *Github: https://github.com/rmannibucau* >>> > > >>>>>>>> >>> > > >>>>>>>> >>> > > >>>>>>>> >>> > > >>>>>>>> 2013/7/10 Thomas Hug <[email protected]> >>> > > >>>>>>>> >>> > > >>>>>>>>> Making forEntity non-optional would then be redundant for >>> the >>> > > >>> regular >>> > > >>>>>>>> cases >>> > > >>>>>>>>> using the base interface, so I wouldn't. But I see that it >>> > should >>> > > >>> be >>> > > >>>>>>>>> clearly documented then as things might get confusing... >>> > > >>>>>>>>> >>> > > >>>>>>>>> >>> > > >>>>>>>>> On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau >>> > > >>>>>>>>> <[email protected]>wrote: >>> > > >>>>>>>>> >>> > > >>>>>>>>>> do you mean you force forEntity = Person.class? >>> > > >>>>>>>>>> >>> > > >>>>>>>>>> looks ok for me since the only constraint is to add the >>> dto >>> > > >> types >>> > > >>>>>>>>> somewhere >>> > > >>>>>>>>>> :) >>> > > >>>>>>>>>> >>> > > >>>>>>>>>> *Romain Manni-Bucau* >>> > > >>>>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> > > >>>>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*< >>> > > >>>>>>>>>> http://rmannibucau.wordpress.com/> >>> > > >>>>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> > > >>>>>>>>>> *Github: https://github.com/rmannibucau* >>> > > >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > >>>>>>>>>> 2013/7/10 Thomas Hug <[email protected]> >>> > > >>>>>>>>>> >>> > > >>>>>>>>>>> Hmm and I assumed DTOs are dead and buried :-) >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> Packing this in the base interface feels kind of clunky >>> to >>> > me - >>> > > >>>>>>> also >>> > > >>>>>>>>>>> considering that there are repositories without the need >>> to >>> > > >>> extend >>> > > >>>>>>>> the >>> > > >>>>>>>>>> base >>> > > >>>>>>>>>>> interface. What about something like >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> @Repository(forEntity = Person.class) >>> > > >>>>>>>>>>> @ResultMapper(entityMapper = MapperX.class, keyMapper = >>> > > >>>>>>>> MapperY.class) >>> > > >>>>>>>>>>> public interface PersonRepository extends >>> > > >>>>>>> EntityRepository<PersonDto, >>> > > >>>>>>>>>>> DtoPk> { ... } >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> Having the Entity on @Repository takes precedence and the >>> > type >>> > > >>>>>>>>> parameters >>> > > >>>>>>>>>>> are in this case just for convenience. >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau >>> > > >>>>>>>>>>> <[email protected]>wrote: >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>>> +1 >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> just to complete this thread the main issue is not the >>> > > >>>>>>>> implementation >>> > > >>>>>>>>>> but >>> > > >>>>>>>>>>>> the exposed API: >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> public interface EntityRepository<E, PK extends >>> > Serializable> >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> would become >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> public interface EntityDtoRepository<E, PK extends >>> > > >> Serializable, >>> > > >>>>>>>> Dto, >>> > > >>>>>>>>>>>> DtoPk> >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> *Romain Manni-Bucau* >>> > > >>>>>>>>>>>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau >>> >* >>> > > >>>>>>>>>>>> *Blog: **http://rmannibucau.wordpress.com/*< >>> > > >>>>>>>>>>>> http://rmannibucau.wordpress.com/> >>> > > >>>>>>>>>>>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> > > >>>>>>>>>>>> *Github: https://github.com/rmannibucau* >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> 2013/7/10 Jean-Louis MONTEIRO <[email protected]> >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>>> Hello guys, >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> Just used DS Data module yesturday, and I was >>> wondering if >>> > we >>> > > >>>>>>>> could >>> > > >>>>>>>>>>> add a >>> > > >>>>>>>>>>>>> feature allowing on-the-fly conversion to DTO. >>> > > >>>>>>>>>>>>> For example, we could use modelmapper (or similar to >>> > convert >>> > > >>>>>>> DAO >>> > > >>>>>>>>>> return >>> > > >>>>>>>>>>>>> values to DTO objects). >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> Adding a mapper interface to delegate to would also >>> allow >>> > > >>>>>>> people >>> > > >>>>>>>> to >>> > > >>>>>>>>>>> plug >>> > > >>>>>>>>>>>>> their own implementation in. >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> WDYT? >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> JLouis >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> 2013/7/1 Thomas Hug <[email protected]> >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> Hi John >>> > > >>>>>>>>>>>>>> Thnx for the message, missed that one. Looks like >>> there's >>> > a >>> > > >>>>>>>>> default >>> > > >>>>>>>>>>>>> profile >>> > > >>>>>>>>>>>>>> needed (test-persistence.xml only part of the specific >>> > > >> server >>> > > >>>>>>>>>>>> profiles). >>> > > >>>>>>>>>>>>>> Will check tonight. >>> > > >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament < >>> > > >>>>>>>>>>> [email protected] >>> > > >>>>>>>>>>>>>>> wrote: >>> > > >>>>>>>>>>>>>>> Hi >>> > > >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> Whoever brought in the data module, can you double >>> check >>> > > >>>>>>> your >>> > > >>>>>>>>>> tests >>> > > >>>>>>>>>>>> and >>> > > >>>>>>>>>>>>>>> license headers? >>> > > >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> I think it's just your tests, but it's failing >>> during a >>> > rat >>> > > >>>>>>>>> check >>> > > >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > >>>>>>> >>> > > >>>>> >>> > > >>> >>> > > >> >>> > > >>> > >>> https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/ >>> > > >>>>>>>>>>>>>>> John >>> > > >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> -- >>> > > >>>>>>>>>>>>> Jean-Louis >>> > > >>>>>>>>>>>>> >>> > > >>>>> >>> > > >>>>> >>> > > >>> >>> > > >> >>> > > >> >>> > > >> >>> > > >> -- >>> > > >> Jason Porter >>> > > >> http://en.gravatar.com/lightguardjp >>> > > >> >>> > > >>> > >>> >>> >>> >>> -- >>> Jean-Louis >>> >> >> >
