[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229?page=c... ] Chris Bredesen commented on HHH-3229: ------------------------------------- And of course #1 becomes an difficult problem when you consider Annotations... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229?page=c... ] Gail Badner commented on HHH-3229: ---------------------------------- <sebersole> i think the best we could get would be to psuedo-code the cascade algo <breddy> or just a "whatever we encounter first in the mappings sticks" scenario? <sebersole> again, thats simplistic <sebersole> the difficulty is almost always graphs <breddy> but you see where I'm going <breddy> so a pseudo code of the algorithm, that's cool I think <breddy> let's pause on this for a moment ... <sebersole> now, i think i general rule which *should* work would be to map non-cascaded associations last <breddy> and look at option 4 <gbadner> (thinking slowly...) <breddy> fix HHH so that the rules are the rules regardless of mapping order (and thus cascade paths) <breddy> is that OFF the table? <breddy> s/fix/enhance/ <breddy> :) <sebersole> i'd need to look at the perf implications <gbadner> btw, mapping the cascaded associations first wouldn't have helped here <breddy> we also might not be able to change the default behavior in a dot release <breddy> if it could affect existing stuff <sebersole> gbadner: perhaps, perhaps not; i have not looked ... <sebersole> i have not had time to really think through the problem, but for example... <gbadner> one thing that might work is to stash away transient (non-cascaded) entities and continue with the next cascades; after the first pass, stashed objects won't be transient anymore if they were cascaded elsewhere <sebersole> a trivial solution code-wise is to <sebersole> thats similar to what i was going to say <gbadner> great minds think alike... <sebersole> we'd just need to key them properly to see if the TOE is still pertinent after the cascase cycle <sebersole> but... <sebersole> again, my concern is the perf <sebersole> i'll allow you to ponder it for a bit <sebersole> ;) <gbadner> suppose it's a huge collection that ends up being transient... ... <gbadner> it might be nice if the user was able to affect the order <sebersole> they can <sebersole> :) <breddy> :D <breddy> btw is there anywhere today that we discuss/mandate the order of mapped properties in the XML? <breddy> all this goes out the window with annotations so it's kinda crazy <gbadner> I was looking at how properties are added to PersistentClass <gbadner> hmmm, does it go out the windows with annotations? <breddy> well the ordering is completely different <breddy> and is not even guaranteed AFAIK <breddy> different VM's order the properties differently (don't quote me on that but it has come up) <gbadner> Is it possible to use annotations and mapping files? <breddy> in JPA yes <breddy> but in hbm.xml the hbm overrides all annotations <breddy> if we are giong to make this explicit, it has to be somewhere other than the ordering <gbadner> why? <breddy> becuase of what I just said <breddy> well <gbadner> I get it for annotations; but it should be ok for mapping files <breddy> maybe not; we could mandate hbm.xml I guess <breddy> I don't think any of this is specified in JPA <breddy> anyway like steve said, this is simplistic and if we're going to depend on the XML property order, we have to be able to explain it in the manual <breddy> IOW, ordering is simplistic in and of itself <breddy> but the implications are not trivial <sebersole> if we are going to be in here, another thing it is probably worthwhile to take a look at is a way to allow user control when to cascade <sebersole> if they know they have a certain usage pattern, they may not need both cascades <breddy> at runtime you mean? <sebersole> well i mean a global type setting <sebersole> as opposed to per-association <breddy> I thought we had default-cascade <sebersole> thats different <sebersole> right now we do cascades at operation time and at flush time <sebersole> so... <sebersole> session.save( something ) <sebersole> we cascade immediately <sebersole> but, we also cascade later at flush time <sebersole> which is a "catch all" algo <breddy> yeah you'd have to cascade at flush if you then did something.setOther(transientOther) <breddy> gotcha <sebersole> exactly <sebersole> but not everyone uses that pattern <breddy> so you're saying to allow the user to specify which of the two are used? <sebersole> or both <sebersole> yeah <breddy> yah <breddy> hmmm <sebersole> and actually... <breddy> there would be times when you could not defer the cascade to flush time <sebersole> if this store/recheck TOE algo works out <sebersole> we could make that configurable too ... <sebersole> so before i was just saying that if that particular algo works out perf-wise <sebersole> then we could just make it configurable w/ default = off as a means to maintain back-compat <sebersole> off = throw the TOE immediately <sebersole> on = store for recheck after casade cycle <breddy> alright lets' have some discussion on the jira http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229 <breddy> I can add the test case as a patch or we can leave it off for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229?page=c... ] Gail Badner commented on HHH-3229: ---------------------------------- I've committed a test (org.hibernate.test.cascade.MultiPathCascadeTest) to Branch3_2 that show that the problem seems to only affect merging a detached entity. Using Session.update() to update a detached entity and using Session.get() to get the entity then modifying the entity works without throwing a TransientObjectException. The failing test case that modifies a detached entity and uses Session.merge() is MultiPathCascadeTest.testMultiPathMergeDetachedFailureExpected(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229?page=c... ] Gail Badner updated HHH-3229: ----------------------------- Fix Version/s: 3.3.0.CR2 3.2.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229?page=c... ] Paul Benedict commented on HHH-3229: ------------------------------------ Was the documentation ever updated so that more of Hibernate's design decisions are known on this issue? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229?page=c... ] Gail Badner updated HHH-3229: ----------------------------- Issue Type: Bug (was: Improvement) Summary: Merge can fail when there is a transient entity reachable by multiple paths and at least one path does not cascade on merge (was: Make cascade rules more transparent/explicit/deterministic) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira