I've added an issue for backporting HHH-6855. I thought it was a good idea to
include HHH-6854 so that the backport for HHH-6855 would be tested.
Let me know what you decide about HHH-4358.
Thanks,
Gail
- Original Message -
> From: "Steve Ebersole"
> To: "Gail Badner"
> Cc: "Hibernate
I think HHH-6855 should be. HHH-6854 is just a test fix, I'd say its
not important for backport.
I don't think there is actually any code changes for HHH-4358. I may
have left that fix version there by mistake.
On Thu 19 Jan 2012 04:05:46 PM CST, Gail Badner wrote:
> I've created new issues f
Actually it is not fixed yet :) Let me think about it.
On Thu 19 Jan 2012 08:08:56 PM CST, Steve Ebersole wrote:
> I think HHH-6855 should be. HHH-6854 is just a test fix, I'd say its
> not important for backport.
>
> I don't think there is actually any code changes for HHH-4358. I may
> have l
I've created new issues for backporting fixes for 3.6.10.
Please take a look at:
https://hibernate.onjira.com/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%223.6.10%22+AND+project+%3D+HHH
I'm not planning to backport dialect-related issues, although I could be talked
Just heard back from the sepc lead that this happens exactly according
to spec. The expectation is that you clean up all other cascadeable-to
references to that removed entity. Otherwise, the flush will cascade
PERSIST back to it, canceling out the remove.
I think we should add a flag to make
thanks for the heads up
On Jan 18, 2012, at 9:37 PM, Steve Ebersole wrote:
> We may have to go right to m8...
>
> http://forums.gradle.org/gradle/topics/plugins_and_classloader_isolation
>
>
> On Wed 18 Jan 2012 08:04:02 AM CST, Steve Ebersole wrote:
>> I am in that process. The problem is up
