On 1/18/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Regardless of what's actually happening, the correct way (which we
*must* fix) is to fix the way the current StrutsForm -> Pojo mapping
happens and make sure that id values cannot be copied. As Mitesh said,
we should *never* allow an id on a pojo to be manually set when that
pojo is allowing the framework to manage the id. In fact, in these
cases I think the correct thing to do is to make the setId() method
private, which is actually suggested in the Hibernate In Action book
somewhere.
So what this entails is modifying the pojos to make setId() private
OK. I will do that ASAP.
fixing the way the struts actions/forms work to make sure all actions
which modify an existing pojo actually query for that pojo first, then
mutate it.
I don't think that's an issue any more, but we should check.Now that
we're using the simplified store() method, any parts of the UI that
still do that are now broken.
>> Technically, the call to saveFoo() isn't necessary with Hibernate or
>> JPA because FooData is a persistent/managed object, but perhaps other
>> persistence frameworks (iBatis?) might beed that final call to
>> FooManager.saveFoo().
> We should distinguish between save and update. Thus in above case
> instead of calling FooManager.saveFoo(), we should call
> FooManager.updateFoo() which will be implemented as a noop for JPA or
> Hibernate. Other frameworks can implement it as required.
I disagree. There is no real reason why we must treat saves and updates
separately. I think this is something that the framework can take care
of on it's own and it's actually handled in a very simplistic way ...
if(object.id != null)
update()
else
save()
and the framework manages what attribute of the pojo is the id through
its mapping files. so I don't think we need to do this.
Yes. I believe you are correct Allen. In our current architecture,
there is no reason to support the saving of detached objects. So we
can assume that an object with an ID is a "managed" object.
- Dave
