@John: oops, was a type, "can" was "cannot", i meant adding @stateless will do nothing.
about dto or not both are needed, i dont propose to force it, i just mention it is common to need it. the proposed API sounds fine for me. I don't want this thread to be a troll, dto usage depends on the architecture of the app and that's not the role of DS to say it is good or not (the answer would obviously be wrong here ;). DTO (or whatever name you want) are larger than entity/other object, it can always be data cleanup. So basically we need a layer to be able to modify what is returned, nothing more. *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 John D. Ament <[email protected]> > 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 > > >>>>>>>>>> > > >> > > > > >
