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 <john.d.am...@gmail.com>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 >> <rmannibu...@gmail.com>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 <thomas....@gmail.com> >>> >>>> 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 >>>> <rmannibu...@gmail.com>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 <thomas....@gmail.com> >>>>> >>>>>> 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 >>>>>> <rmannibu...@gmail.com>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 <jeano...@gmail.com> >>>>>>> >>>>>>>> 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 <thomas....@gmail.com> >>>>>>>> >>>>>>>>> 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 < >>>>>> john.d.am...@gmail.com >>>>>>>>>> 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 >>>>>>>>
