Yep, if you want to do it in the JPA layer you can do something like that. In my case, my front end data objects aren't exposed to our JPA libraries, so it's not an option.
@Romain How do you make a CDI object a remote EJB? Or are you referring to transactional state? As far as I know, you cannot setup an MDB in a CDI extension. On Fri, Jul 12, 2013 at 6:59 AM, hantsy <[email protected]> wrote: > Your requirement is based on your experience, i do not think a must in > REST application. > > Some case we can wrap the result in query result like this. > > select new UserResult(name, email ) from User u > > to get a ValueObject directly. > > > Hantsy > On 7/12/2013 14:12, Romain Manni-Bucau wrote: > > 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 > >>>>>>>>>> > >> > >
