Is it possible to add an extra restriction to Session.update() ?

Example:
Usually, Session.update results in an SQL that looks like this:
UPDATE <table> SET <column> = <value> WHERE id = <id>

I want to add an additional restriction for an attribute:
UPDATE <table> SET <column> = <value> WHERE id = <id> AND name = 'Blabla'



I'm using Hibernate 3.3.1 GA with Mappings (no Annotations).

Maybe with a custom <sql-update> mapping for your class. See http://docs.jboss.org/hibernate/stable/ ... erysql-cud

are you using session.update(entity)? if yes, why do you need that condition?

I have many objects/mappings with a few very complex objects.
Is it possible to add only "AND name = 'Blabla'" to the original query or do I have to write the whole query for each column in <sql-update> (latter wouldn't be an option)?
Also, do I have to write 'Blabla' hardcoded in the mapping or can I use a certain attribute of the object for this?



I'm using Session.update(entityName, object).
My database must also support partitioning, thus I need this additional attribute in each query (needed for partition determination).



Additional information

I already thought of the following options:
A) Adding a composite-id with both keys to the mapping
B) Altering the hibernate source (but I don't know what exactly I have to change)

Restricting with "AND name = 'Blabla" can also be disabled via a certain property, so I'm trying to avoid changes in the mappings since they are hardcoded there and I have to create/use different mappings if the restriction is enabled or disabled.

I would go for option A) Adding a composite-id with both keys to the mapping. I think the other options would not be worth the effort. Don't know how you should be able to disable it though... Wouldn't that mean that there are multiple objects with the same id?

If i choose this option, I have to double all the mappings (since I must use a different one if the restriction is disabled).
That's much effort If i have to add or change some attributes for an object afterwards.
No, every object has it's unique id, I don't need the additional attribute/restriction if I don't use partitioning on my database (thus, it is disabled).

Then I really don't understand why you need the extra restriction on the update. It should update the same record anyway and if the name = 'Blabla' doesn't match you'll get an error and the transaction should be rolled back. What about implementing an Interceptor and in the onFlushDirty() method check the value of 'name'? If it doesn't match you can throw an exception and the end result will be the same.

If my database uses partitioning, every query has to contain this additional restriction in order to determine the correct partition.

I am not sure I understand this partitioning thing you talk about.... You said that you wanted to disable it i some cases... I guess the query will work even when the extra restriction is not there?

Since Hibernate normally generates the SQL at session factory startup the only other option I can think of is to map your classes with <class ... dynamic-update="true" ..>. This makes Hibernate generate the update statement when it is needed, and if you implement an Interceptor it is maybe possible to inject the extra restriction in the Interceptor.onPrepareStatement() method. Lots of if's and maybe's... try it out and see what happens...

I need this additional restriction in every statement in order to determine the correct partition of the database (if a lot of data will be stored on the database, the performance will decrease, so the database is separated in different partition - e.g. for different organizations)
If one partition is enough, this additional restriction can be disabled.

I can't use dynamic-update since I use detached objects and select-before-update will certainly decrease the performance.
An additional listener also isn't an option because I use POJOs and the setters must not contain this sort of logic.
See https://www.hibernate.org/161.html

I don't see the connection here. An Interceptor is configured per session or session factory and will not affect your pojos at all. In any case, I don't have any more advice to give you... Seems like you are cornered by various requirements. I think you need to compromise and decide what is most important and what is not.

I meant the Implementing Solution #2, described in the url above.