Skip to main content

JPA cacade remove operation: Spec vs. TLE implementation

22 replies [Last post]
hewagn00
Offline
Joined: 2006-03-27

After using the JPA cascade entity operation feature, I had several problems when removing entities from the database, that should cascade their remove operation to dependent entities as this results in a database constraints violation. There are several issues already filed, but it seems they have low priority/importace (P4), thus impliying that it is not a mandatory feature required by the JPA spec. From my understandig of the spec e.g., it is completely legal to have a unidirectional @OneToMany relation set to cascade type ALL. Are there any plans to support cascading of remove operations for the release of Glassfish V2?

Regards
Heiko

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
msell
Offline
Joined: 2007-07-16

Any idea of when the fix will be available?

Thanks!

msell
Offline
Joined: 2007-07-16

I can't believe that there has been a "production" release already with this bug - this is certainly a showstopper issue.

I've voted for this one to get fixed. The final release should not happen until this is fixed...

vladperl
Offline
Joined: 2004-08-11

>The final release should not happen until this is fixed...

I'm going to try Hibernate.

Don't waste your time on Toplink.

If they don't understand how important cascading operations are what else can i say.

mf125085
Offline
Joined: 2005-03-29

I have a partial fix for this problem. Its gonna fix uni-directional delete dependencies between different classes. The remaining problem would be cascade deletes on uni-directional self-relationships. I still have to do all necessary actions to get it integrated, which might take a few more days. We also gonna push for it to get into V2.

vladperl
Offline
Joined: 2004-08-11

>We also gonna push for it to get into V2

I appreciate that you got the message.

Good luck with fixing this issue.

mf125085
Offline
Joined: 2005-03-29

Code freeze for V2 was July 30th, so my fix might not go into V2.

But it will certainly be in GlassFish V2 UR1. The fix will also be available in the nightly and promoted builds of both GlassFish and TopLink Essentials that can be downloaded from

https://glassfish.dev.java.net/public/downloadsindex.html

I'll update issue 2991 as soon as I check in.

vladperl
Offline
Joined: 2004-08-11

>The fix will also be available in the nightly and promoted builds of both GlassFish

I always use promoted builds so it's ok to have fix this way.

Thank you very much for keeping us posted.

I think that would be very useful for many developers to have project that can demonstrate how to implement all kind of tricks related to persistence provider.

Let me describe how I see that in details:

1) netbeans 6 based

2) directly available from glassfish site

3) demonstrate how to use and when to use all functionality that provide "toplink essential"

4) the toplink team constantly review the project and make necessary improvements that probably in many cases will be triggered by improvements in persistence provider itself.

5) project should be semantic oriented. To reach this goal it necessary to have xml based file that will be able to describe all semantic relations that exist between entities.
Keep in mind that entity mapping descriptor (aka orm.xml) doesn't provide all information that need to know to implement application.

Having this file will provide the possibility to generate whole database oriented application.
As additional benefit we don't need to have much documentation that describe entities and relationships between them.
I called this file semantic because it will use semantic concepts like parent, child, owner and etc.



If the team interesting in this kind of project I'm ready to start preparing some material in this direction.



Sincerely,

Vladimir

mf125085
Offline
Joined: 2005-03-29

The fix has been checked in and should be available soon. Please let me know, if there are still problems!

vladperl
Offline
Joined: 2004-08-11

> The fix has been checked in and should be available
> soon. Please let me know, if there are still problems!

Thanks for fixing this issue!
When build 59 will be available I let you know if there is still a problem.

hewagn00
Offline
Joined: 2006-03-27

I totally agree with cameronr. The point is that:

a) TLE violates the JPA spec
I consider this to be not acceptable for the RI, even if there is no test in the TCK.

b) It is a "show stopper" bug
Several people have already complained about the cascade bugs on the issue tracker and on the forum.

c) Workarounds that mess up the application design do not help
There have been several suggestions for cascade bug workarounds like:
- Name your entities in proper alphabetical order: I do not give my entities a special name for no reason.
- Do not use the cascade feature an manually remove the entities: What is a spec good for, when you can't rely on it to build portable applications.
- Do not use unidirectional OneToMany relations: I use relations the way it makes sense for the application, not for the persistence provider.

Regards
Heiko

chris_delahunt
Offline
Joined: 2005-07-06

There is one more workaround:
Add a constraint dependency on A to B - assuming A has the unidirectional OneToMany to B. This should cause TopLink to process As first, causes TopLink to clean up the relation table before deleting the A, and before attempting to delete Bs.

Customizers can be used to add constraint dependencies, which are useful when you have unmapped constraints in your objects. Try using a descriptor customizer on the A class, and then call descriptor.addConstraintDependencies(B.class);

This may not work in all cases - if the relation is self referencing or if there is another 1:1 from A to B that would force B to be deleted/processed first - but should still help until it can be fixed.

Best Regards,
Chris

hewagn00
Offline
Joined: 2006-03-27

Getting back to my original question, is there any plan when it will be fixed? Will the fix be included in the Glassfish V2 final release?

mvatkina
Offline
Joined: 2005-04-04

It is too late for V2.

vladperl
Offline
Joined: 2004-08-11

>Please check issue 2991

I just put all my 10 votes on this issue.

I suggest that everybody who is interesting in fixing this issue do the same.

vladperl
Offline
Joined: 2004-08-11

>Are there any plans to support cascading of remove operations for the release of Glassfish V2?

I'm asking the same question how long we have to wait for full implementation cascading operations?

Looks like the team doesn't have enough resources to implement this.

They just putting every time low priority for very important issues.

I believe that is bad practice and I'm angry on the team that responsible for implementing "TopLink Essentials".
I already said this on the forum once but they don't care.

Glassfish already in state release candidate but "TopLink Essentials" far from it in my opinion.

hewagn00
Offline
Joined: 2006-03-27

Although I am quite sure that support for cascaded remove operation is a mandatory feature in the spec, I am not sure if there is a test for it in the TCK. So someone can argue it is not needed to be JPA compliant. As a german idiom says: "You can do anything, when you manage not to be caught." So maybe someone of the JSR 220 TCK team might help out, by adding a proper test cases for the CascadeType[] field of the various relational mapping annotions. ;-)

Regards
Heiko

vladperl
Offline
Joined: 2004-08-11

I'm wondering if it makes sense to switch to another persistence provider.

I'd like to know good alternative to "Toplink Essentials".

Regarding to test cases good idea to put them on the glassfish website with detail description.
Problem only is that cascading functionality not fully implemented.
By the way they have implementation many-to-many cascading operation.

samdoyle
Offline
Joined: 2006-12-27

You can try Hibernate for your persistence provider. I'm not sure if this will solve your problem but it might be worth a shot.

S.D.

vladperl
Offline
Joined: 2004-08-11

Thank you for suggestion. If nothing will change in a few days I definitely will try Hibernate.

mf125085
Offline
Joined: 2005-03-29

Please check issue 2991

https://glassfish.dev.java.net/issues/show_bug.cgi?id=2991

for further information and possible workarounds.

cameronr
Offline
Joined: 2006-07-27

Hi there,

This issue keeps cropping up for us as well and it is very frustrating. In many instances it does not make sense to have a bidirectional relationship. For example we have many different entities with a oneToMany relationship to the same type of entity (for storing xml based metadata). This scenario does not allow for a bidirectional relationship.

Obviously there are workarounds - but there should be no need to perform them. This problem is clearly a bug - the implementation does not match the specification. I still don't understand how it can be a P4.

Cameron

vladperl
Offline
Joined: 2004-08-11

Cameron,

It's good to see the same view on this matter.

Probably couple more posting in this direction and situation with cascading operations will be improved :)



Vladimir