1 Reply Latest reply on Jan 16, 2013 3:16 PM by james_sutherland

    Entity remove triggering select stmts on private owned relationships

      Hi All,
      When ever we do an entityManager.remove on an entity and commit, the eclipse link is doing a realAllQuery.execute (Select stmt) on each of the privateOwned entities of the given entity(irrespective of whether they are present or not) before actually deleting them .
      This is very much redundant especially if there are large number of entities to delete/cascade delete and each has multiple number of private owned rels - Lots of SELECT SQls , and time taken for these select sqls is very much higher than actual delete stmts. Is there a way to remove the private owned rels without selecting them.

      We are using the ecliselink 2.3.1 version.

      This readAllQuery.execute on private owned entitites is triggered during CollectionMapping.recordPrivateOwnedRemovals method of eclipse link during commit.

      Any Input or suggestion greatly appreciated.

        • 1. Re: Entity remove triggering select stmts on private owned relationships
          EclipseLink needs to load an object's private owned relationship to delete the objects, otherwise it does not know which objects to delete.
          The private owned objects can have their own private owned objects and dependent relationships that need to be deleted as well.

          EclipseLink does perform a delete-all optimization for a privately owned OneToMany where the target does not have any dependent relationships (or inheritance/multiple tables/ locking).
          This will occur for a simple OneToMany but most have relationships of their own that prevents the optimization.
          This optimization can also be configured using the @DeleteAll annotation.

          EclipseLink also supports delete cascading on the database, if you have created your foreign key constraint to cascade on delete, or are using EclipseLink to create your schema.
          If you use @CascadeOnDelete, then the related objects should not be loaded.

          If you still think you have more SQL than you think is correct, please include your object model code, and the SQL log for the delete.