Hi guys,

I am having problems while trying to do a bulk delete.

I notice that the syntax has changed for hibernate 3.1 (table aliases cannot be specified) and that it has not yet been updated in the documentation - it would be great if this was updated as it took me a while to figure out :) (I'm happy to do so if required!)

Anyway, I have found that when trying to specify a composite key value it's not doing the funky "translate property name to SQL column name" that I have come to love so much. Eg;

(Note that AdPointContent has a composite key, with iblId being one of these)



and it's generating the following SQL:



which is obviously a bit wrong (it's generating a table alias when it doesn't need to - looks like someone only ripped out most of that code but missed the composite key stuff).


To workaround it I have found that you can just specify the table's column name in your HQL:



which of course defeats the whole point of using HQL (might as well just write out the SQL), but at least it generates the right SQL:



Waahey. Notice that the second parameter _is_ being translated correctly. (Yes, I did put it in there for a reason :) My only gripe with this solution is that it is very confusing for the average user who might stumble across my code (why is one column name specified and the other is the class property?). Of course it's a great way to confuse people so I guess that's a bonus.

Am I doing something stupid? Is there a better way to do this?

By "table aliases" I assume you really mean "class aliases"... They can still be (optionally) used. There is a plethora of test cases in the test suite testing this (as for all things relating to HQL updates and deletes, org.hibernate.test.hql.BulkManipulationsTest is the gospel).

As for the composite id issue, it very well could be that these are not handled correctly. If you add a bug report to JIRA with a small reproducible test case, I'll take a look.

As for the cause, it actually has nothing to do with "ripping stuff out"; on the contrary, it has to do with adding in new support. The HQL parsers (as well as the persister interfaces with which they interact) worked on the assumption that a table aliases would always be used; which was fine at the time considering only select statements were supported via HQL. So quite the contrary, the struggle has been adding in new capability and getting the new parser to use this at the appropriate times/places. If you are going to pontificate about causes, at least get the basis right ;)

Thanks for the quick reply!

It would be great if you could check this one out, if I get time I will try to do a reproducable test case for you to use.

And yes sorry, I did mean class aliases. Are you sure that they can still be used when doing a delete? If I try adding one I get an error:



Not that it really matters, you don't need to specify an alias.

Some examples from the test I mentioned:

delete from Animal as a where a.id = :id

delete Animal a

delete from User u where u not in (select u from User u)

Yeah I spotted them.. but it doesn't make my code work :) They're not using the old parser? Or is ( getDialect().hasSelfReferentialForeignKeyBug() ) returning true and the function exiting?