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 <lightguard...@gmail.com> > On Fri, Jul 12, 2013 at 12:13 AM, Romain Manni-Bucau > <rmannibu...@gmail.com>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" <rmannibu...@gmail.com> 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" <han...@yahoo.com.cn> 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 < > > 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 > > >> >>>>>>>> > > >> > > >> > > > > > > -- > Jason Porter > http://en.gravatar.com/lightguardjp >
