Does a JPQL statement DELETE FROM Order o WHERE o.createdAt < :cutoff, executed with executeUpdate(), also remove the child rows mapped with cascade = REMOVE or orphanRemoval? What typically goes wrong if you assume it does?

## Two different deletion mechanisms JPA has two ways to delete, and they share almost nothing. Entity removal is the object-layer path: em.remove(order) marks the managed instance for deletion; at flush Hibernate walks the association graph, applies cascade = REMOVE and orphanRemoval, fires @PreRemove/@PostRemove callbacks, deletes collection rows and join-table rows, and orders the statements so children go before parents. Bulk deletion is the statement path: a JPQL DELETE is translated to SQL and executed. Hibernate knows the entity's tables and the WHERE clause and nothing more. There is no graph walk because there is no graph. ## What that means concretely Given Order with @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true) List<OrderLine> lines, the bulk statement 'delete from Order o where o.createdAt < :cutoff' emits roughly `delete from orders where created_at < ?`. The order_line rows are untouched. If order_line.order_id has a foreign key with the default NO ACTION / RESTRICT behaviour, the database rejects the DELETE and Hibernate surfaces a constraint violation exception. Many developers meet the feature this way, which is the lucky case: the database protected them. The unlucky case is a schema without that constraint, or one where the FK column is nullable with ON DELETE SET NULL. Then the statement succeeds and leaves orphan rows behind - storage that grows forever, reports that double count, and later imports that trip over ids pointing at nothing. The same applies to many-to-many join tables and element-collection tables: those rows belong to a collection table that a bulk delete on the owning entity does not consider at all. ## Doing it correctly Delete children first. Issue bulk deletes bottom-up in one transaction: first 'delete from OrderLine l where l.order.id in (select o.id from Order o where o.createdAt < :cutoff)', then the delete on Order itself. This keeps the set-based performance and satisfies the constraints. Watch that the subquery is evaluated per statement - on large data sets, collect ids into a staging table or process in chunks. Let the database cascade. ON DELETE CASCADE on the FK moves the work into the engine, and a single bulk delete on the parent then removes children too. It is fast and correct, but it is invisible from the Java side, it still fires no callbacks, and it can delete far more than expected if the graph is deep - so it is a schema decision to make deliberately. Use entity removal for small sets. If the number of rows is modest and you need @PreRemove hooks, auditing or business validation, load and remove(). You pay N statements but you get the object-layer semantics. ## The other bypassed behaviours Beyond cascades, a bulk delete skips lifecycle callbacks and entity listeners, and it ignores optimistic version checks - it deletes whatever matches the WHERE clause regardless of concurrent modification. It also leaves the persistence context alone: an Order you loaded earlier stays managed after its row is gone, and flushing a modification of that instance can produce a confusing update-count-mismatch failure. Clear the persistence context after bulk deletes for the same reason you do after bulk updates. Finally, for entities in a joined inheritance hierarchy or with secondary tables, Hibernate cannot express the delete as one statement; it selects the matching ids into a temporary id table and deletes from each table in turn. That is why a one-line bulk delete can produce several statements plus temporary-table DDL in the SQL log. ## Rule of thumb Bulk statements are SQL with entity names. Anything that lives in the object layer - cascade, orphanRemoval, callbacks, versioning, the persistence context - is not part of the deal, and you either re-express it in SQL or in the schema.