Re: [play-framework] What is the difference between object.update() and object.update(id) inEbean ORM ?

[Guillaume Bort]

It's basically the same but usually you don't "bind" the ID. It comes from the URL, and from another business rule, and btw must be checked at the security level (otherwise any users can change any id in the form and update any database object).

So the best way to securely bind and update an object is:

1. form(AdminUser.class).bindFromRequest(white, list, of, keys) // If you don't specify the whitelist of parameters to bind, it will bind everything, that is a potential security issue

2. Retrieve the id from the URL (if the request is something like POST /users/:id)

3. Check that the currently connected user has the permission to update this particular object id.

4. use adminUser.update(id), to assign the id before calling EBean, so it will issue the correct UPDATE statement.

On Fri, Feb 8, 2013 at 10:05 AM, Chema <jose...@restalo.com> wrote:

Hello,

I have this code:

Form<AdminUser> adminuserForm = form(AdminUser.class).bindFromRequest();

AdminUser adminUser = adminuserForm.get();

adminUser.update();

What's the difference with:

adminUser.update(id);

And... is this correct?:

adminUser.update( adminUser.getId() ); ?????

Thanks a lot!

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Guillaume Bort, http://guillaume.bort.fr

[Leon Radley]

The problem with this is that it's really hard to do partial updates.

This is because bindFromRequest always creates a brand new version of the entity.

We should have have an option to use a passed in entity as a base, and then apply the white listed properties on the already fetched entity. This way you could call myEntity.save and ebean would not thing it's detached and start throwing errors at you.

This is where the problem lies: https://github.com/playframework/Play20/blob/master/framework/src/play-java/src/main/java/play/data/Form.java#L305

What do you think Guillaume?

[Guillaume Bort]

By default Ebean doesn't update null values. So it supports partial update. 

Otherwise it requires to do a select, create an object that map this entity and then update ALL fields in the database. 

I don't understand what you mean about detached entities... Ebean is stateless and doesn't have notion of detached entities. 

[Thomas W]

Normally binding should "bind into" an entity which has been retrieved from the database? Without having retrieved it already, there is no VERSION stamp.. and hence no locking.

Overwriting an account balance/ or other user's database changes, due to absence of locking, is not very professional :)

Most of the persistence/mapping frameworks I am aware of keep the notions of "identity", "version" and "data members" all together in the same object. While a functional style might want to treat an entity as just a "value object", without identity & version being maintained the database operations will not be reliably correct.

So it seems inconvenient to only be able to bind into a new object.   I'd like to use Play with Hibernate, as that is a well-established technology -- others are yet to be proven to the degree HB has -- and would expect to be able to do so.

Any thoughts?

Regards

Thomas Whitmore