OGM-98
by jonathan wood
Hello,
I have a need for resolution of
#OGM-98<https://hibernate.onjira.com/browse/OGM-98> and
would not mind taking a shot at the implementation. Has any work or
analysis been done in this area? I'd love to leverage any knowledge in the
community.
On the surface, this seems quite possible. The current plan would be to
created unit tests around the use cases described in the envers docs .
Outside of Envers, I've abandoned use of CQ in favor of HibernateSearch (A
move that is proving to be a bit easier than expected, gotta love being
able to conjure an index any time you need one). It seems that a custom
class bridge might solve the revision query issues (by allowing an index to
be created upon entity state change). Also under consideration is
reflecting/annotationprocessing to create the Envers model, but that seems
a bit more complicated and error prone.
I'm also looking at the possibility of adding support for a couple of
other backends. Has the recently released Amazon DynamoDB been considered?
Cassandra is also a possibility, but Dynamo seems a closer match to the
key/val implementation used to support Infinispan.
Any thoughts out there? Is this the appropriate place to discuss this?
Thanks,
Jonathan
12 years, 2 months
forced pushes
by Steve Ebersole
Do not use --force with git push when pushing to any of the GitHub
hosted hibernate repos. GitHub does not allow us to disable or
otherwise limit its use.
However, we are now able to see when someone does a forced push. From
this point forward we will be removing write access to anyone doing
forced pushes. This sounds harsh, but we just wasted all morning
recovering from forced pushes as we are trying to get ready for
tomorrows releases. We just don't have time to keep dealing with these.
Thanks.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 2 months
forced update
by Steve Ebersole
Maybe I am just paranoid because of the recent lost commits stuff, but
today I did a pull and got this:
+ d8d1019...92f42e7 3.6 -> origin/3.6 (forced update)
Why a force? To the best of my knowledge I did not have any non-pushed
commits on that 3.6 branch.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 2 months
PERSIST_ON_FLUSH.noCascade()
by Gail Badner
The fix for HHH-1822 throws TransientObjectException when PERSIST_ONFLUSH is not cascaded to a transient entity.
Should this still be the behavior according to JPA 2.0?
I believe that the expected behavior is defined by JPA 2.0, section 3.2.4 "Synchronization to the Database", specifically:
"For any entity Y referenced by a relationship from X, where the
relationship to Y has not been annotated with the cascade element
value cascade=PERSIST or cascade=ALL:
• If Y is new or removed, an IllegalStateException will be
thrown by the flush operation (and the transaction marked
for rollback) or the transaction commit will fail."
It sounds to me that TransientObjectException is the wrong exception. Am I misinterpreting this or taking it out of context?
Related, the work I did for HHH-6957 throws PropertyValueException when an insert depends on a non-nullable, transient value. I agree that PropertyValueException is more meaningful than IllegalStateException/JDBCException. I want to confirm that this isn't going to be a spec violation.
I see some other problems with HHH-1822, particularly after HHH-5472 (re-orders inserts when there are dependencies on non-nullable transient entities) was fixed:
1) it doesn't take into account that there may be another cascade path that will persist the transient entity
2) it doesn't take into account that the transient entity may already be in the process of being saved (i.e., in the cascadeBeforeSave phase).
In case 2), if the transient entity is the association owner, then TransientObjectException would be thrown erroneously, because the current entity being saved must be saved before the transient entity. This is what causes HHH-5299.
I can extend the work I did for HHH-6957 to also look for nullable, transient values. At the end of session.persistOnFlush (when the cascade level == 0), the appropriate exception (whatever is decided) could be thrown. I believe this would cover both cases. IIUC, then PERSIST_ON_FLUSH.noCascade() would no longer be needed. If so, can we deprecate CascadingAction.requiresNoCascadeChecking() and noCascade()?
(As an aside, another improvement could be to delay inserts until all transient references (not just non-nullable) are resolved, if possible. This would avoid nullifying the transient reference on insert and requiring an update on flush. If it's not possible, the behavior would be as it is currently.)
Please provide some feedback so I can proceed with fixing HHH-5299.
Thanks,
Gail
12 years, 2 months
Test failures after pull
by Steve Ebersole
Everyone else seeing these after pulling master?
Test
org.hibernate.test.cascade.circle.MultiPathCircleCascadeCheckNullibilityFalseTest
FAILED
Test org.hibernate.test.cascade.circle.MultiPathCircleCascadeTest FAILED
Test
org.hibernate.test.cascade.circle.MultiPathCircleCascadeCheckNullTrueDelayedInsertTest
FAILED
Test
org.hibernate.test.cascade.circle.MultiPathCircleCascadeCheckNullibilityTrueTest
FAILED
Test
org.hibernate.test.annotations.cascade.circle.identity.CascadeCircleIdentityIdTest
FAILED
Test
org.hibernate.test.annotations.cascade.circle.sequence.CascadeCircleSequenceIdTest
FAILED
--
steve(a)hibernate.org
http://hibernate.org
12 years, 3 months
Re: [hibernate-dev] Question in relation to Hibernate4.0 Final
by Demetz, Guenther
Hi Mr. Andersen,
>>Problem is that it seems 4.1 will cause similar disjunct API
The "Redesigned metamodel" goal, which was planned for 4.1, surely would have caused lots of disjunct API's again,
but now I saw on the hibernate roadmap, that in meantime the "Redesigned metamodel" goal has been shifted to Hibernate 5.0.
So im asking, if nevertheless 4.1 will still cause similar disjunct API ?
Exists there a roadmap for Hibernate-Tools?
Can hibernate-tools users hope to can switch to Hibernate4 or will they must wait until Hibernate5 ?
Best regards
Günther Demetz
Würth Phoenix S.r.l.
Günther Demetz
Product Development (CIS)
Via Kravogl 4
I-39100 Bolzano
Direct: +39 0471 564 061
Fax: +39 0471 564 122
E-Mail: guenther.demetz(a)wuerth-phoenix.com
Website: www.wuerth-phoenix.com
-----Original Message-----
From: Max Rydahl Andersen [mailto:max.andersen@redhat.com]
Sent: Wednesday, December 21, 2011 11:05 AM
To: Strong Liu
Cc: Demetz, Guenther; Hibernate hibernate-dev
Subject: Re: Question in relation to Hibernate4.0 Final
JBoss Tools M5 have an experimental version of the eclipse plugins that works against both 3.6 and 4.0.
We'll get that merged into hibernate tools in the new year.
Problem is that it seems 4.1 will cause similar disjunct API so the problem is just getting worse to keep up and keep a stable API/access for hibernate tools users :(
/max
On Dec 19, 2011, at 14:11, Strong Liu wrote:
> Max?
>
> -------------------------
> Best Regards,
>
> Strong Liu <stliu at hibernate.org>
> http://about.me/stliu/bio
>
> On Dec 19, 2011, at 8:59 PM, Guenther Demetz wrote:
>
>> Hi Strong Liu,
>>
>> do you know, when it is planned a Hibernate-Tools release compatible to Hibernate-Core 4.0 Final ?
>>
>> Me and probably many other hibernate users cannot switch to
>> Hibernate-Core 4.0 as long there no compatible hibernate-tools version available.
>>
>> best regards
>> Guenther Demetz
>>
>> On 09/07/2011 02:10 PM, Strong Liu wrote:
>>> that just because of we don't have enough resource working on
>>> hibernate-tools :( meanwhile, you can use hibernate-tools with
>>> hibernate-core 3.6 to generate schemas
>>>
>>> and thanks for the patches i'm working on it
>>>
>>> -----------
>>> Strong Liu <stliu(a)hibernate.org>
>>> http://hibernate.org
>>> http://github.com/stliu
>>>
>>> On Sep 7, 2011, at 8:09 PM, Guenther Demetz wrote:
>>>
>>>> Hi Strong Liu,
>>>>
>>>> as requested I attached a testcase to HHH-6635.
>>>>
>>>> I have another question regarding Hibernate4:
>>>>
>>>> Till now I used hbm2ddl ant-target of hibernate-tools to create new database schemas.
>>>> but I noticed that so far all Hibernate4 prereleases were provided without a compatible version of hibernate-tools.
>>>>
>>>> -hibernate-tools3.2.4.GA still makes reference to
>>>> org.hibernate.util.StringHelper which in hibernate4 has been moved
>>>> to package org.hibernate.internal.util
>>>>
>>>> -method
>>>> org.hibernate.tool.hbm2ddl.ManagedProviderConnectionHelper#prepare(
>>>> ) in Hiberante-core 4.0.0CR2 has an unimplemented body, so no
>>>> connection is provided for the hbm2ddl tool
>>>>
>>>> So my question is:will hibernate-tools still be supported with hibernate4 or has this module become deprecated ?
>>>>
>>>> best regards
>>>> Guenther Demetz
>>>>
>>>> --
>>>> Würth Phoenix S.r.l.
>>>> Günther Demetz
>>>> Product Development (CIS)
>>>> Via Kravogl 4
>>>> I-39100 Bolzano
>>>> Direct: +39 0471 564 061
>>>> Fax: +39 0471 564 122
>>>> E-Mail: guenther.demetz(a)wuerth-phoenix.com
>>>> Website: www.wuerth-phoenix.com
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Würth Phoenix S.r.l.
>> Günther Demetz
>> Product Development (CIS)
>> Via Kravogl 4
>> I-39100 Bolzano
>> Direct: +39 0471 564 061
>> Fax: +39 0471 564 122
>> E-Mail: guenther.demetz(a)wuerth-phoenix.com
>> Website: www.wuerth-phoenix.com
>
/max
http://about.me/maxandersen
12 years, 3 months
Hibernate 4.0.1: regression with @OneToMany(cascade = CascadeType.REMOVE)
by Guillaume Smet
Hi,
In our test cases, we have a test which checks a lot of cascade
configuration (it's more to document all the cascade behaviors than to
really test an application).
After the upgrade from Hibernate 4.0 to Hibernate 4.0.1, we have a test failing:
- a person is linked to a company
- if we delete a company, it should cascade to the persons due to the
annotation @OneToMany(cascade = CascadeType.REMOVE)
Company {
@OneToMany(cascade = CascadeType.REMOVE)
@JoinTable(name="company_employees4",
joinColumns=@JoinColumn(name="company_id"),
inverseJoinColumns=@JoinColumn(name="employees4_id"))
private List<Person> employees4 = new LinkedList<Person>();
}
In the case of a person linked to 2 companies
- we have an exception with Hibernate 4.0: this is what we expect as
the person is linked to another company and the database warns us
about it thanks to the foreign key;
- the delete is OK with 4.0.1 (no exception due to the foreign key)
and if I try to get the person after that, it's still there so it
seems as if the cascade is not triggered at all.
Does it ring a bell to anyone? I don't have a lot of time atm to
extract a self contained test case so if it's something obvious due to
4.0 -> 4.0.1 fixes, I might pass on this one. I checked the release
notes without finding something which can explain this new behavior.
If it's not something obvious, I'll try to work on a test case in the
next few days. If so, pointers to where I should add the test in the
code base are greatly appreciated.
Thanks for your feedback.
Thanks.
--
Guillaume
12 years, 3 months
