loading this entire archived tree into memory is a waste of time and resources if i follow the H2 style deletion. H3 deletion is a good step forward but practically of no use in this regard. as of this writing i still don’t see an efficient solution to large tree deletions (bulk or not).

Bulk delete with cascading is nice. For example, I need to remove all record of a clients project details. Of course, in practice they tend to be “logical” deletes anyway, so perhaps this is a storm in a teacup.

However I understand that “true” bulk deletes would be pretty hard to do without just effectively doing fetch into memory, call delete, cascade underneath.

But now I know to explicitly do it – great !

Perhaps no-one who understands the difficulties expects cascades to be respected; but naively I did, and I’m sure other people naively have as well. Perhaps the use case I had for it (a test utility to reset the database to a clean state) is unusual for production code.

In any case, once I became aware of the differences, the differences weren’t a problem; it was the lack of knowledge that hurt. This (and the other) blog entries are largely to help me never forget.

(1) Fetch a bunch of objects into memory, delete them all, respecting cascades and other lifecycle. You can still do this in HB3, just run a query and iterate over the results, calling delete(). There is no need for the redundant deprecated method.

(2) True bulk delete, which no-one truly expects to respect cascades. (Yes, perhaps it would be *possible* to implement this efficiently in *some cases*, but no-one has ever implemented such a thing before and it looks *very* difficult.) Actually, IMO, bulk delete is not really that useful; it is the bulk *update* that is the most useful piece here.

The way Hibernate 3 works is that deletes cascade when they are called on individual entities (via the Session.delete(Object) method). This, of course, is what Hibernate 2 did under the covers. It’s only when you use the bulk DELETE query that you don’t get the cascade behavior.

The EJB 3 Persistence spec, in its current form (2nd public draft) has exactly 0 words on the interaction of bulk delete or update queries with the EJB lifecycle. According to comments from Hibernate developers, the EJB lifecycle documented in Section 2.3 (where the cascade rules are defined) refers only to in-memory instances that you call remove() on explicitly.

Section 3.11 of the EJB spec defines the bulk UPDATE and DELETE queries. Section 2.3 defines EJB lifecycles – Hibernate objects conform to a similar (but not identical) lifecycle.

There is nothing inherently bad about the hibernate cascade delete other then the n+1 (but if the method was named suitably, then people would understand what they are getting into when the call the method).

Cascading deletes is one of the scary things in RDBMSes (at least it is for this person, who still wakes up screaming at night… jooohnnnnyyyy).

I know the EJB 3 spec isn’t finished yet, but it would be a bit sad if they left cascade deletes out (the logic would be “well RDBMSes do that best in one call” -but this would mean essentially keeping your relationship logic in the database as well as the hibernate/ejb3 mappings).

Will be an interesting one to watch.