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
>> 

Reply via email to