I'm integrating with a legacy app. One of the tables has all regular data fields, each of which could be changed on client side, so my DAO and Service interfaces look like:

void insert(Foo foo);
void update(Foo foo);

There are though a couple of fields that require a special treatment: IS_DELETED and IS_AGENT. To change any of them a user has to has a special right, so there are two more methods:

void delete(Foo foo);
void makeAgent(Foo foo,boolean isAgent);

The problem is: since those fields are mapped just like regular ones (name, description, ...), they could be changed by a client as well, and next update() will update the IS_DELETED or IS_AGENT fields with no rights check.

Thus, I want to remove those fields from mapping. Still, I need a way to update them in delete() and makeAgent(). I also need to use those fields in HQL query (i.e. getAll() shouldn't return Foos where IS_DELETED=true).

How can I do that? Can I?

P.S. No, I cannot change the database schema. Legacy and big.

How about adding logic to your update() method which checks whether the IS_DELETED or IS_AGENT values changed. If yes the method can throw an exception or ignore the changes and just update the rest.

No, this is bad on so many levels.

First at all, at the moment of update() we have only client-modified version. To make a comparision we need to load current one, which is another SQL query.

Second, having setter for a "secure" property misleads client, who can believe it's alright to change this property directly.

So after some brainwashing ;) I decided to remove those properties from the mapping completely; instead, I introduced a small control mapping for the same table, which contains primary key and "secure" properties. This way client never see those properties as a part of the object, but can manipulate them through DAO-exposed methods. Control beans aren't visible to client, it's a detail of implementation.

mapping:


code (under SpringFramework):


it works fine for me.