Yes please! :-)
On 18 August 2014 20:22, Romain Manni-Bucau wrote:
> well we have to make it working with openjpa by default. We should
> also introduce an interface the entity can implement to say if it is
> new or not (testing business id typically)
>
>
> Romain Manni-Bucau
> Twitter: @rmanni
well we have to make it working with openjpa by default. We should
also introduce an interface the entity can implement to say if it is
new or not (testing business id typically)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/r
So isNew is broken for openjpa and one should live with it? This will
basically make deltaspike data not usable because you kinda need merge to
work properly...
On 17 June 2014 19:11, Thomas Hug wrote:
> Actually the simple mapper is doing that since the last update, just to
> find the entity b
Actually the simple mapper is doing that since the last update, just to
find the entity based on the PK so you receive an attached entity (also
valid for chained mappers, when injected)
BTW, if you need something different in save, you can still define your own
reusable repository methods:
http://
Yes, but that s not an issue since you can get it injected
Le lundi 16 juin 2014, Karl Kildén a écrit :
> But then I need to use the entityManager in the mapper or am I missing
> something?
>
>
> On 16 June 2014 11:17, Romain Manni-Bucau wrote:
>
>> Yes you need to merge it but the responsabilit
But then I need to use the entityManager in the mapper or am I missing
something?
On 16 June 2014 11:17, Romain Manni-Bucau wrote:
> Yes you need to merge it but the responsability is yours (user) IMO.
> Le 16 juin 2014 09:56, "Karl Kildén" a écrit :
>
> > Hrmm maybe I mixed things up now.
> >
Yes you need to merge it but the responsability is yours (user) IMO.
Le 16 juin 2014 09:56, "Karl Kildén" a écrit :
> Hrmm maybe I mixed things up now.
>
> If you have a relationship to another pre existing entity can it be
> detached when you save? All I am really looking for is the groupId to b
Hrmm maybe I mixed things up now.
If you have a relationship to another pre existing entity can it be
detached when you save? All I am really looking for is the groupId to be
updated but maybe JPA can't determine this in a good way. And updating the
entity itself is solved by including it as an ar
Cause mapping can be done through several transactions (think jaxrs) so it
would be wrong. PersistenceUtil has some good things to gey id or null if
new but IIRC some impl are broken.
Le 16 juin 2014 09:31, "Thomas Andraschko" a
écrit :
> Why don't we use entityManager#contains instead of checkin
Actually you want to override isNew and not save I think. This should be
doable (@Alternative maybe) but the mapper should be responsible of
ensuring collections are well mapped (find if needed) mainly because you
dont always map 1-1 (otherwise it is almost useless).
Le 16 juin 2014 09:22, "Karl K
Why don't we use entityManager#contains instead of checking the ID?
2014-06-16 10:22 GMT+02:00 Karl Kildén :
> Hi,
>
> On could argue that the real problem is that the algorithm that decides if
> it should be a save or persist. It uses some portable way of deciding this
> that requires the entit
Hi,
On could argue that the real problem is that the algorithm that decides if
it should be a save or persist. It uses some portable way of deciding this
that requires the entity to be managed.
That algorithm could be improved in each project.
@Override
@RequiresTransaction
public E
Thanks Karl for the clarification!
If you assign a new group, I'd first make sure you have this one persisted
as well (or we do too much in the mapper IMO). Then save the userDto with
something like
User toEntity(User user, UserDto dto) {
...
user.setGroup(groupMapper.toEntity(dto.getGroup
Not sure I get myself ;)
Lets walk through how I see it:
1. User "foo" is created and is assigned to the preexisting group "Admin".
It goes like this in the flow: user = new UserDTO() ->
*user*.setGroupDTO(selectedGroup)
-> save
Some logic must make sure that we don't get EntityExistsException
Hi Karl
Sorry not sure if I get you right. Why would user.getGroup() be stale? As
in the update case user has just been fetched by the PK, user.getGroup()
should lazyload the group - right?
On Fri, Jun 13, 2014 at 2:51 PM, Karl Kildén wrote:
> Hi and hrmmm,
>
> What if user group was changed?
Hi and hrmmm,
What if user group was changed? groupMapper.toEntity(user.getGroup(),
userDto.getGroup()); This would then operate on stale data unless you fetch
and send in correct group. And managing new groups is easy for me I think,
I would call the method using groupMapper.toEntity(new Group()
Hey Karl
Sorry missed your mail indeed - it's probably time I subscribe to the user
mailing list too :-)
You can still chain those mappers together, but I agree the casting and
wiring is clunky. As options I see:
- we add a public E toEntity(Dto dto) back which basically does the same as
mapParam
I wrote a response to the users list but not sure it came through. It kinda
belongs in this thread so here it goes.
So I ran into issues with the DTO mapper api and voiced my concerns in irc.
I saw this discussion and now I am trying the solution present in the
current SNAPSHOT. However I have on
Yep, missed it.
Works for me. Maybe the name should be closer to other methods,
mapKey? But whatever you choose as name this solution works :).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.
It's the PK, not the Entity ;) In SimpleQueryInOutMapperBase, it could be
something like
@Inject
private QueryInvocationContext context;
protected abstract Object getPrimaryKey(Dto dto);
protected E findEntity(Object pk)
{
return (E) context.getEntityManager().find(context.getEntityClass(),
would work while return is and not Object ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-17 11:47 GMT+02:00 Thomas Hug :
> Or a protected abstract Object getPrima
Or a protected abstract Object getPrimaryKey(Dto dto). We can get the EM
over an injected QueryInvocationContext.
On Thu, May 15, 2014 at 9:06 PM, Romain Manni-Bucau
wrote:
> I think a protected findEntity(id) in the mapper can be enough.
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog:
I think a protected findEntity(id) in the mapper can be enough.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-05-07 22:29 GMT+02:00 Thomas Hug :
> Hi Romain,
> See your
Hi Romain,
See your point. But if we only get the DTO - with what would we call the
find? Could even be that the PK is a DTO or encoded / encrypted and needs
to go through the mapper first. Maybe we can provide some convenience
methods in the base mapper?
On Tue, May 6, 2014 at 7:41 PM, Romain Ma
Hi guys,
DTO feature is awesome but doesn't work in update mode since isNew
doesn't use a managed entity.
When using a mapper we should call find and pass it to the mapper (or
create a new unmanaged entity if not found). So mapper signature
should be Entity toEntity(Entity, DTO) no?
Otherwise us
25 matches
Mail list logo
