@PreCascade

["Trenton D. Adams" <tr...@trentonadams.ca>]

I have an idea for a new feature of JPA.  I am not sure if it's useful or not, or if I'm missing anything obvious.  I'm quite new (like REALLY new) to JPA and EJB.  

Anyhow, my suggestion is that perhaps there should be an @PreCascade.  This would be used in circumstances, for example, when you have an Embeddable PK of a child, that has the ID of the parent.

Person (personId auto generated)
 -> Address
   -> AddressPK(personId, addressType)

So, the PK of the address could not be known prior to Person being persisted.  So, the only way of doing it right now, is to persist the person, then add an address, and merge the person.

With @PreCascade, you would be able to update the addresses with an appropriate primary key, before the cascade occurs.

A generic @PreCascade on a no-arg method could be supported, which is just saying "we're about to persist all of your cascade elements".

An argument based @PreCascade method could be supported, which would pass the object that is about to be cascaded.  This would work well for Collection items, so the developer doesn't have to do the loop (I'm lazy), but with a small performance hit due to method calls for EVERY object, and the need for "instanceof".


Here's an example...

And my persistence is effectively done like this...
        final EntityType entityType = store.getEntityType("TEST");
        Entity entity = new Entity("Callable Entity",
            "Entity with a telephone number", entityType);
        entity = store.addEntity(entity);
        entity.addTelephone(new Telephone("780", new Teletypes("HOME"),
            "XXXXXXX"));
        entity.addTelephone(new Telephone("780", new Teletypes("BUS"),
            "XXXXXXX"));
        entity.addTelephone(new Telephone("780", new Teletypes("CELL"),
            "XXXXXXX"));
        final Entity newEntity = store.updateEntity(entity);

    public void addTelephone(final Telephone telephone)
    {  // Entity knows what the PK should be, because it has already been persisted itself
        telephone.setTelephonePK(new TelephonePK(entityId,
            telephone.getTeleType().getTeleType()));
        telephones.add(telephone);
    }

store methods...
    public Entity addEntity(final Entity entity)
    {
        entityManager.persist(entity);
        entityManager.flush();
        return entity;
    }

    public Entity updateEntity(final Entity entity)
    {
        final Entity newEntity = entityManager.merge(entity);
        entityManager.flush();
        return newEntity;
    }

Re: @PreCascade

["Trenton D. Adams" <tr...@trentonadams.ca>]

Do any of the developers have any thoughts on this?  Am I missing something obvious, err, um, obvious to someone who knows what they are doing that is. :P

----- "Trenton D. Adams" <tr...@trentonadams.ca> wrote:

> From: "Trenton D. Adams" <tr...@trentonadams.ca>
> To: users@openjpa.apache.org
> Sent: Monday, May 24, 2010 4:33:44 PM GMT -07:00 US/Canada Mountain
> Subject: @PreCascade
>
> I have an idea for a new feature of JPA.  I am not sure if it's useful
> or not, or if I'm missing anything obvious.  I'm quite new (like
> REALLY new) to JPA and EJB.  
> 
> Anyhow, my suggestion is that perhaps there should be an @PreCascade. 
> This would be used in circumstances, for example, when you have an
> Embeddable PK of a child, that has the ID of the parent.
> 
> Person (personId auto generated)
>  -> Address
>    -> AddressPK(personId, addressType)
> 
> So, the PK of the address could not be known prior to Person being
> persisted.  So, the only way of doing it right now, is to persist the
> person, then add an address, and merge the person.
> 
> With @PreCascade, you would be able to update the addresses with an
> appropriate primary key, before the cascade occurs.
> 
> A generic @PreCascade on a no-arg method could be supported, which is
> just saying "we're about to persist all of your cascade elements".
> 
> An argument based @PreCascade method could be supported, which would
> pass the object that is about to be cascaded.  This would work well
> for Collection items, so the developer doesn't have to do the loop
> (I'm lazy), but with a small performance hit due to method calls for
> EVERY object, and the need for "instanceof".
> 
> 
> Here's an example...
> 
> And my persistence is effectively done like this...
>         final EntityType entityType = store.getEntityType("TEST");
>         Entity entity = new Entity("Callable Entity",
>             "Entity with a telephone number", entityType);
>         entity = store.addEntity(entity);
>         entity.addTelephone(new Telephone("780", new
> Teletypes("HOME"),
>             "XXXXXXX"));
>         entity.addTelephone(new Telephone("780", new
> Teletypes("BUS"),
>             "XXXXXXX"));
>         entity.addTelephone(new Telephone("780", new
> Teletypes("CELL"),
>             "XXXXXXX"));
>         final Entity newEntity = store.updateEntity(entity);
> 
>     public void addTelephone(final Telephone telephone)
>     {  // Entity knows what the PK should be, because it has already
> been persisted itself
>         telephone.setTelephonePK(new TelephonePK(entityId,
>             telephone.getTeleType().getTeleType()));
>         telephones.add(telephone);
>     }
> 
> store methods...
>     public Entity addEntity(final Entity entity)
>     {
>         entityManager.persist(entity);
>         entityManager.flush();
>         return entity;
>     }
> 
>     public Entity updateEntity(final Entity entity)
>     {
>         final Entity newEntity = entityManager.merge(entity);
>         entityManager.flush();
>         return newEntity;
>     }