Re: [eclipselink-users] Order of mapping initialization error in Eclipse

[Tom Ware <tom.ware@xxxxxxxxxx>]

Finally got a chance to look at the logging.  It's pretty hard to tell what is 
going on.  It looks like you are doing a bunch more than just adding/removing in 
 this code and you have a bunch more mappings than just the ones you describe 
below.

Is it possible to isolate the case to just include the mappings you are 
describing? i.e. Ideally only populate the part of the object that includes the 
problem and show me the SQL resulting from that population and from the remove 
called on that object.

The other mappings involved in this can have an impact on the order of the SQL 
and potentially what happens at predelete.  That is why it would be ideal to 
have something as specific as possible.

-Tom

Zeb Ford-Reitz wrote:
> I've attached the snippets to this mail. Sorry that the "add" log is so 
> huge. I was unsure of exactly where the important data starts and ends, 
> so I left it pretty much as-is so that there would be no missing 
> information.
>
> Thanks for looking into this.
>
> On 05/18/2011 02:07 PM, Tom Ware wrote:
> > Can you please turn on FINEST logging and send the snippet of logging 
> > that occurs when you add ExecTestCasePO to a SpectTestCasePO and the 
> > snippet of logging that occurs starting at the remove, through to the 
> > exception.
> >
> > - to set logging, set persistence unit property 
> > eclipselink.logging.level to FINEST
> >
> > Zeb Ford-Reitz wrote:
> > > A description with some code is easier for the moment. I'm 
> > > experiencing the problem in the Eclipse project Jubula (see 
> > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=345106), so maybe that 
> > > could count as a recreation (although it's far from small or 
> > > automated). We're using JPA 2.0 with annotations in an OSGi environment.
> > >
> > > The root of a class hierarchy is the NodePO class, which has a 
> > > unidirectional list of children:
> > >
> > >     @ManyToMany(fetch = FetchType.EAGER,
> > >                 cascade = CascadeType.ALL,
> > >                 targetEntity = NodePO.class)
> > >     @JoinTable(name = "NODE_LIST",
> > >                joinColumns = @JoinColumn(name = "PARENT"),
> > >                inverseJoinColumns = @JoinColumn(name = "CHILD"))
> > >     @OrderColumn(name = "IDX")
> > >     List<INodePO> getHbmNodeList() {
> > >         return m_nodeList;
> > >     }
> > >
> > >
> > > I am attaching an image of the class hierarchy for NodePO. In this 
> > > hierarchy are the classes SpecTestCasePO (NodePO -> ParamNodePO -> 
> > > TestCasePO -> SpecTestCasePO) and ExecTestCasePO (NodePO -> 
> > > ParamNodePO -> TestCasePO -> ExecTestCasePO). This is the multiple 
> > > levels of inheritance that I was talking about.
> > >
> > > I can successfully add an ExecTestCasePO to a SpectTestCasePO's node 
> > > list and persist those changes. I can also successfully call 
> > > EntityManager.remove(). However, an attempt to commit the removal 
> > > causes a foreign key violation in NODE_LIST.
> > >
> > > Thanks for your time. Please let me know if you need more information.
> > >
> > > On 05/17/2011 08:03 PM, Tom Ware wrote:
> > > > I am not aware of an existing problem.  Can you provide us with more 
> > > > information?  (ideally an recreation, but otherwise a description of 
> > > > your class structure, the mappings and the code you are running)
> > > >
> > > > Zeb Ford-Reitz wrote:
> > > > > Hello,
> > > > >
> > > > > I'm encountering a problem with EclipseLink 2.3 RC1 that I did not 
> > > > > encounter in EclipseLink 2.2.
> > > > >
> > > > > The problem involves multiple levels of inheritance and 
> > > > > "preDeleteMappings". The resulting error is a foreign key violation 
> > > > > in a join table when committing the removal an entity with a 
> > > > > ManyToMany association.
> > > > >
> > > > > The source of the problem seems to be missing preDeleteMappings, 
> > > > > which would remove the necessary entry from the join table before 
> > > > > removing the entity itself. Essentially, the order in which the 
> > > > > mappings are initialized (and post-initialized) causes several of 
> > > > > our entites to contain the preDeleteMappings from their 
> > > > > corresponding direct parents, but *not* from all of their ancestors.
> > > > >
> > > > > Is this a known issue? If so, is it expected to be fixed in the 
> > > > > near future? If not, can anyone suggest a workaround?
> > > > >
> > > > > Thanks for your time.
> > > > >
> > > > > With best regards,
> > > > > Zeb Ford-Reitz
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------------ 
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > eclipselink-users mailing list
> > > > > eclipselink-users@xxxxxxxxxxx
> > > > > https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> > > > _______________________________________________
> > > > eclipselink-users mailing list
> > > > eclipselink-users@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > eclipselink-users mailing list
> > > eclipselink-users@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> > _______________________________________________
> > eclipselink-users mailing list
> > eclipselink-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users