Re: [hibernate-dev] Metamodel - Entity primary key mappings
by Steve Ebersole
So we need to decide how to best represent the identifier for the entity.
That's ultimately the disconnect here. Hibernate historically had 3 ways
to represent ids:
* simple - these were explicitly basic type ids: longs, ints, strings, etc.
== <hbm:id/>
* aggregated composite - essentially @EmbeddedId
* non-aggregated composite - like @IdClass cases, but without the @IdClass;
the entity itself was the identifier value.
Notice a few things:
1) A simple identifier could never be an association in legacy Hibernate.
A "key-many-to-one" was ALWAYS wrapped in a composite, even if it was the
attribute on the composite. Now Hibernate also has the concept of a 1-1
with a "foreign generator" which is essentially the same as the JPA feature
of `@Id @ManyToOne` or `@Id @OneToOne`. Recently I made some significant
changes to "simple derived ids" such that they no longer get wrapped in a
virtual embedded composite.
2) For composite ids, JPA requires either a EmbeddedId or a IdClass.
Legacy Hibernate does not, via its "embedded (virtual) identifier". While
I think we should continue to support non-aggregated composite without an
IdClass, I do think we should warn users when they do this. So at the
moment we really have the following ways to represent an id:
* simple basic id
* simple derived id ( @Id + @OneToOne or @ManyToOne )
* aggregated composite
* non-aggregated composite
* non-aggregated composite + IdClass
3) JPA allows EmbeddedId to have (singular) associations. IdClass cannot;
in cases where IdClass maps one or more associations.. well the convoluted
rules in "derived identities" section kick in. But the important take away
is that the structure of the 2 id representations is very different. For
example:
@Entity
class Customer {
@Id Integer id;
...
}
class OrderIdClass implements Serializable {
Integer customer;
int orderNumber;
}
@Entity
@IdClass(OrderIdClass.class)
class Order implements Serializable {
@Id @ManyToOne ...
Customer customer;
@Id
int orderNumber;
...
}
Looking at Order, the internal representation of its identity (used to
cache it within the Session ,etc) is the Order itself - Hibernate's legacy
"embedded identifier" which includes the many-to-one. The representation
used in lookups is OrderIdClass which does not contain the many-to-one.
Note that EmbeddedId can follow the same paradigm according to JPA, which
is another use-case of MapsId:
@Embeddable
class OrderId implements Serializable {
Integer customer;
int orderNumber;
}
@Entity
class Order implements Serializable {
@EmbeddedId
OrderId id;
@MapsId
@ManyToOne ...
Customer customer;
...
}
Ugh.
On Tue, Apr 8, 2014 at 6:32 PM, Gail Badner <gbadner(a)redhat.com> wrote:
> Hi Steve,
>
> Problem happens when a @ManyToOne is assocated with an entity that has an
> @IdClass.
>
> I looked for a core test that reproduces the problem, but it looks like
> the core tests using @IdClass that fail for a different reason before this
> problem shows up.
>
> The following envers tests reproduce the problem:
>
>
> org.hibernate.envers.test.integration.onetoone.bidirectional.ids.MulIdBidirectional
>
> org.hibernate.envers.test.integration.onetomany.detached.BasicDetachedSetWithMulId
> org.hibernate.envers.test.integration.onetomany.BasicSetWithMulId
> org.hibernate.envers.test.integration.query.ids.MulIdOneToManyQuery
>
> When binding the JdbcDataType for the ID:
>
> EntityType.getIdentifierOrUniqueKeyType( metadataCollector() ) is called,
> which ends up calling:
>
> InFlightMetadataCollectorImpl.getIdentifierType( associatedEntityName )
> which returns
>
>
> entityBinding.getHierarchyDetails().getEntityIdentifier().getAttributeBinding()
> .getHibernateTypeDescriptor()
> .getResolvedTypeMapping();
>
> which returns an EmbeddedComponentType; its PojoComponentTuplizer is
> expecting to get/set values in the entity object.
>
> InFlightMetadataCollectorImpl.getIdentifierType( associatedEntityName )
> should be returning the ComponentType for the @IdClass. Problem is the
> ComponentType for the @IdClass is not built until the persisters are being
> built and PropertyFactory.buildIdentifierProperty() is called. This is
> because I didn't think it was needed until then. Now I see that it is
> needed when binding the JdbcDataType.
>
> The test ultimately fails due to PropertyAccessException when trying to
> insert the many-to-one. This is because the ID value for the associated
> entity is gotten from the EntityEntry and it is an instance of the @IdClass
> class, while the PojoComponentTuplizer for the ID is expecting an entity
> instance.
>
> Gail
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve(a)hibernate.org>
> > To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org>
> > Sent: Monday, April 7, 2014 4:45:18 PM
> > Subject: Re: [hibernate-dev] Metamodel - Entity primary key mappings
> >
> > What I am thinking at the moment is to change up
> > org.hibernate.metamodel.spi.binding.EntityIdentifier to look like:
> >
> > public class EntityIdentifier {
> > private final EntityBinding entityBinding;
> >
> > private EntityIdentifierNature nature;
> > private IdentifierAttributeBindings attributeBindings;
> > private IdClassBinding idClassBinding;
> > private Map<String,String> derivedIdMap;
> > private IdentifierGenerator generator;
> > }
> >
> >
> > 1) IdentifierAttributeBindings would play sort of the same role
> > as
> >
> org.hibernate.metamodel.spi.binding.EntityIdentifier.EntityIdentifierBinding.
> > Essentially it would hold the binding state for each of the identifier
> > attributes (those marked with @Id or @EmbeddedId). Still not sure the
> best
> > external representation of this. Exposing a simple
> > List<SingularAttributeBinding> for all identifier natures versus
> > specialized IdentifierAttributeBindings for each nature are running a
> > neck-and-neck race atm. Thoughts? Votes?
> >
> > 2) IdClassBinding would be a
> > specialized
> org.hibernate.metamodel.spi.binding.EmbeddableBindingContributor
> > for describing the @IdClass mapping
> >
> > 3) `derivedIdMap` holds the various @MapsId mappings for the entity. I
> was
> > tempted to move this off to IdClassBinding except that @MapsId also
> refers
> > to @EmbeddedId attributes.
> >
> > Thoughts? Worries? Concerns?
> >
> >
> >
> >
> > On Mon, Apr 7, 2014 at 10:27 AM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
> >
> > > I've been spending a lot of time the last 2 weeks trying to get a good
> > > "mental model" as to how to best model the information pertaining to an
> > > entity's primary key. Most of this effort went into trying to
> understand
> > > JPA's "derived identity" support.
> > >
> > > First and foremost I want to get away from modelling this (in the
> > > metamodel) as a singular attribute. This is unnatural in the
> > > "non-aggregated composite id" case forcing us to build a "virtual"
> > > attribute. I think that this is very doable with the distinction I
> > > recently added to the metamodel between Embedded/Embeddable.
> > >
> > > Next is to finish up support for IdClass, which should be close to
> done.
> > > Gail, I know you had mentioned a case where that support was lacking.
> > > Could you send me the specifics so I make sure we get that case
> covered?
> > >
> > > Beyond that is mainly incorporating support for JPA "derived
> identities".
> > > With that, I want to share some of my understanding and see if I
> missed
> > > anything...
> > >
> > > "Derived identity" support is essentially Hibernate's much older
> "foreign"
> > > identifier generator, namely that the child entity gets (all of or
> part of)
> > > its identifier from a to-one association defined on it, from its
> "foreign
> > > key" value. But of course the spec verbosely covers all the ways this
> > > might happen.
> > >
> > > The very first thing I noticed is that the examples in the spec come
> in 2
> > > distinct top-level flavors. Examples 1-3 are cases where the "parent
> id"
> > > is simply part of the "derived (child) id". Examples 4-6 are cases
> where
> > > the parent id *is* the child id (shared pk). I am not sure how
> important
> > > this distinction is in practice, but I also noticed that @MapsId is
> only
> > > pertinent wrt the second set of cases where we have the shared pk.
> This
> > > was the first time I have noticed that distinction.
> > >
> > > The one monkey wrench that JPA throws into the works here is that there
> > > are essentially multiple views of an entity's PK. As one example,
> take the
> > > spec's "Example 4.a":
> > >
> > > @Entity
> > > public class Person {
> > > @Id String ssn;
> > > ...
> > > }
> > >
> > > @Entity
> > > public class MedicalHistory {
> > > @Id
> > > @OneToOne
> > > @JoinColumn(name="FK")
> > > Person patient;
> > > ...
> > > }
> > >
> > > Ultimately, the primary key of MedicalHistory is the `ssn` of its
> > > associated Person. Thus both of these are valid:
> > >
> > > entityManager.find( MedicalHistory.class, somePerson );
> > > entityManager.find( MedicalHistory.class, somePerson.ssn );
> > >
> > > For those who have seen it, this is the reason for the wonkiness inside
> > > Hibernate's runtime engine wrt incoming id type while doing a load.
> > >
> > >
> > > I am still going through all the use cases (ours plus JPA) to make
> sure we
> > > get everything covered. But I wanted to hopefully get some discussion
> > > started around this and get any thoughts y'all might have.
> > >
> > >
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
10 years, 8 months
Jira / GitHub issues
by Steve Ebersole
Just a heads up that as or tomorrow (April 10) we should see the Jira /
GitHub issues resolved. The last 2 issues we have been waiting on were
just resolved:
1) https://jira.atlassian.com/browse/DCON-391
2) https://jira.atlassian.com/browse/DCON-393
Essentially this most recent problem has been the synchronization process.
Those 2 issues addressed different parts of that.
All-in-all, that should mean:
* Commit info should start synchronizing automatically again
* We should start to see Pull Requests automatically linked to the Jira
issue provided the Pull Request refers to the Jira issue key in its title.
10 years, 8 months
Why Hibernate 4.2.x should receive more updates
by Marc Schipperheyn
Just wanted to outline some reasons for keeping the Hibernate 4.2.x release
train alive.
I would love to update today to 4.3.x. But I'm on Spring 3.x and the
Hibernate 4.3.x line only made it into Spring 4.x. So everybody using
Spring 3.x will be stuck on 4.2.x. I would say that's prob just about
everybody using Spring. Spring 4 was only recently released.
IMHO this is not on the Spring team but on the fact that a significant
refactoring was executed post Hibernate 4.0.x. The corresponding Spring
JIRA is here SPR-10839 <https://jira.spring.io/browse/SPR-10839>
One idea would be to release an adapter that allows Hibernate to be used
with Spring 3.x. I'll be upgrading to Spring 4 soon, so I only care fore
convenience sake, but I control my IT infra. If you guys want the latest
and greatest Hibernate on all Spring installs this year, you might consider
helping that along a little.
Cheers,
Marc
10 years, 8 months
HHH-9106: Multiple detached representations of the same entity cannot be merged
by Gail Badner
After fixing HHH-6848, Hibernate throws IllegalStateException when merging entity 'x' if it has references to 2 detached entities 'y1' and 'y2' obtained from different sessions, and y1 and y2 represent the same persistent entity. In other words, y1 != y2.
I've pushed some FailureExpected test cases to org.hibernate.test.ops.MergeTest that illustrate this. [1]
Before fixing HHH-6848, one of the representations would be merged and the other would be ignored (probably overwritten).
I'm looking into a fix that will restore this functionality as well as provide logging for this situation. I'll discuss logging in a separate email.
Merging multiple representations that have equivalent state would be straightforward. Things are more complicated when the representations do not have equivalent state. I'd like to discuss and get feedback before fixing this.
I am a little leery about allowing multiple representations that are not equivalent to be merged because data could be lost. I would prefer to throw an exception by default, and then provide a flag to override this behavior as suggested in HHH-8570. I discussed briefly with Steve E., and he preferred to address this concern by logging a warning. Opinions?
In any case, here are 2 possible strategies:
1) The last one copied will "win". First, the state from one will be copied onto a pre-existing managed entity or a new managed copy, then later when the merge operation is cascaded to the other representation, a copy of its state will overwrite the managed entity state.
2) The first representation detected will "win". The idea here is that y1 and y2 are both representations of the same entity; only 1 can be merged. When the first is detected, the merge operation is cascaded to its associations with cascade=MERGE or cascade=AL, then its state will be copied onto a pre-existing managed entity or a new managed copy. When a later representation is detected, it's state is not copied and the merge operation is not cascaded to its associations with cascade=MERGE or cascade=ALL.
I think 2) fits in better With the way merge currently works.
A problem with 1) is that we won't know when we are processing the last representation until all cascade-merges are finished. By then, the session may contain entities from cascading the merge operation from the earlier representations. This could result in persisting transient entities or updating entites that are only associated with earlier representations.
With 2) we always know when we are processing the first representation and can more easily skip cascading the merge operation for representations detected later.
Comments?
Thanks,
Gail
[1] https://github.com/hibernate/hibernate-orm/blob/0118376f8efd9b35d8be815c8...
10 years, 8 months
Re: [hibernate-dev] "Stale" Hibernate issues
by Brett Meyer
But Martijn, you're still missing my main points.
"...awaiting a response from the core team..."
"...without any evidence of a core member looking at the issue..."
"...your users..."
You're still thinking of this community in a proprietary product sense. It's not. The core team is small and focused. All individual contributors work on what they're most interested in or the biggest priority in their environment. If you have an issue that's important/urgent for you, then take a stab at fixing it! If everyone had that attitude within open source communities, some incredible things would result. Directly emailing the core team members, complaining that they haven't given your specific issue enough attention isn't going to accomplish anything. But that's certainly not to say that the core team is hands off. We all work hard. Really hard. And if something critical comes up, it's usually pounced on promptly.
Before I started tackling the state of our JIRA instance, there were over 3k unresolved issues. Like I've already mentioned all over the place, that's not indicative of quality. It simply stems from a complex, 10+ year old project with thousands of users. When that many issues are open, it is *impossible* to identify what's still an issue. Going through them one-by-one is not even remotely reasonable. The policies we're trying to enforce are not simply to assist the core team, but the community as a whole. Imagine someone who is interested in getting started with contributing to ORM. If they pull up JIRA, how in the world would they know where to start?
I will most definitely take a look at your project in HHH-9105 and roll something out for everyone to use as needed. Thanks for that. I'm definitely up for any more *constructive* ideas/feedback.
Brett Meyer
Red Hat, Hibernate ORM
----- Original Message -----
From: "Martijn Dashorst" <martijn.dashorst(a)gmail.com>
To: "Brett Meyer" <brmeyer(a)redhat.com>
Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org>
Sent: Monday, April 7, 2014 4:29:38 PM
Subject: Re: "Stale" Hibernate issues
I know that open source projects are run by volunteers. I appreciate the
efforts folks put in, even if they don't get to look at my issue-especially
when I can work around the issue with a fugly solution, awaiting a response
from the core team.
I don't find my issue super duper important: we were able to work around
it, and we check with every major release if someone has considered solving
it-being disappointed, having a bitter laugh, and continue with our day to
day job.
My issue with the treatment is that after five years of neglect, without
any evidence of a core member looking at the issue, it gets the "give us a
test case or we will close it" treatment, combined with the "we don't want
to look arrogant" attitude.
There's a quid-pro-quo: if you ask your users to do something for you, you
have to give something in return. As a user I have done quite a lot:
described the issue I found in detail, provided mappings. Multiple users
have reported the same behaviour, even in a 4.0-beta.
Given that nobody from the core hibernate team has ever commented on the
issue, I do remain with my opinion that the issue has not been taken
seriously, giving me-a user who has put effort into reporting with proper
detail what the issue is-the willies of ever reporting an issue with
Hibernate again.
So I have gone about and had to shave a yak or two to actually reproduce
the issue at hand (creating a hibernate project, setting up a database,
finding the magical incantations to start up a Hibernate configuration),
fixing the logging, etc) taking up my free evening I could have spent on my
own open source project, or socialising with my wife, or etc. All of this
probably would have taken a core dev about 2 minutes given that you have
the environment setup and know your testing framework in and out.
So I will comment on HHH-3930 that the issue is still present in Hibernate
4.3.5, and also create a new issue with an empty test case which you can
incorporate into your bug reporting template as a test case builder for
folks reporting bugs. I hope you will incorporate this into your project
and save everybody hours of time.
See https://hibernate.atlassian.net/browse/HHH-9105 for the setup. It uses
one deprecated API (config.buildSessionFactory()), but I figure you can
improve upon this easily.
This is also easily converted to a Maven archetype that can be generated
with your normal release cycle. You can then create a online wizard that
allows folks to quickly generate a quick start based on a specific version
of Hibernate. See for example
http://wicket.apache.org/start/quickstart.htmlfor such a page, and
https://github.com/apache/wicket/tree/master/archetypes/quickstart for the
implementation of that archetype.
Martijn
On Mon, Apr 7, 2014 at 9:05 PM, Brett Meyer <brmeyer(a)redhat.com> wrote:
> Hi Martijn, I'm CC'ing the mailing list -- there are a few misconceptions
> I'd like to clear up for everyone.
>
> First and foremost, statements like "But nobody from the Hibernate has
> ever taken a look" are frankly frustrating. Hibernate is an open source
> project, not a proprietary product with separated groups of consumers and
> producers. We all have our own interests and priorities. If HHH-3930 is
> important for someone, pull requests or patches would be fantastic and much
> appreciated by the community!
>
> Your point argues against itself. There are so many issues that deserve
> the community's attention, and HHH-3930 is no different from the rest. But
> due to the sheer amount of open tickets, it was getting impossible to sort
> through them all. We have to do *something* to narrow it down, and this
> was the best solution we could find.
>
> Everyone, please keep in mind that if an issue is still valid on ORM 4,
> simply say so in a comment. I'm more than happy to re-open them on a
> case-by-case basis. An aggressive approach was necessary -- simply letting
> thousands of tickets sit there is, imho, much worse.
>
> Regarding the development of test cases, we've said from the beginning
> that, although we certainly prefer runnable cases (either standalone or
> extending an existing unit test), I've always thought that enough detail in
> the description (entities, mappings, applicable settings, and code
> snippets) were perfectly acceptable and definitely making a big attempt at
> helping out. That hasn't changed. However, several people have mentioned
> wishing for a template project to use in creating standalone reproducers --
> that's a great idea. I'm planning on putting one together soon and will
> share it.
>
> Brett Meyer
> Red Hat, Hibernate ORM
>
> ----- Original Message -----
> From: "Martijn Dashorst" <martijn.dashorst(a)gmail.com>
> To: brmeyer(a)redhat.com
> Sent: Monday, April 7, 2014 2:41:20 PM
> Subject: "Stale" Hibernate issues
>
> Dear Brett,
>
> I understand the necessity of sorting out stale issues in a large project
> as Hibernate, but blindly shafting folks that are waiting 5 years for a
> proper response from the hibernate team is not the way to go.
>
> Case in point: HHH-3930 has been open for 5 years, has provided a clear
> description and code for two entities afflicted entities. But nobody from
> the Hibernate has ever taken a look and commented on it for specific
> information.
>
> Only canned responses from mass updates have been provided.
>
> I urge you to actually look at this issue and give proper feedback on what
> is needed for it to be considered.
>
> If the information is incomplete, or the report unclear, say so.
>
> IMO you can only require folks adding a test case if you have a decent
> guide of how to write one. Provide a maven archetype for it.
>
> Requiring folks to have to checkout the hibernate project, figure out the
> coding guidelines, having to peruse the test cases to figure out what to do
> is really stretching it.
>
> You state that you don't want to come across as arrogant, but from my
> standpoint, the current actions actually make me wish I never had filed the
> issue and just work around it, polluting my model and never going to file a
> bug report with Hibernate ever again.
>
> Martijn
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
10 years, 8 months
Metamodel - Entity primary key mappings
by Steve Ebersole
I've been spending a lot of time the last 2 weeks trying to get a good
"mental model" as to how to best model the information pertaining to an
entity's primary key. Most of this effort went into trying to understand
JPA's "derived identity" support.
First and foremost I want to get away from modelling this (in the
metamodel) as a singular attribute. This is unnatural in the
"non-aggregated composite id" case forcing us to build a "virtual"
attribute. I think that this is very doable with the distinction I
recently added to the metamodel between Embedded/Embeddable.
Next is to finish up support for IdClass, which should be close to done.
Gail, I know you had mentioned a case where that support was lacking.
Could you send me the specifics so I make sure we get that case covered?
Beyond that is mainly incorporating support for JPA "derived identities".
With that, I want to share some of my understanding and see if I missed
anything...
"Derived identity" support is essentially Hibernate's much older "foreign"
identifier generator, namely that the child entity gets (all of or part of)
its identifier from a to-one association defined on it, from its "foreign
key" value. But of course the spec verbosely covers all the ways this
might happen.
The very first thing I noticed is that the examples in the spec come in 2
distinct top-level flavors. Examples 1-3 are cases where the "parent id"
is simply part of the "derived (child) id". Examples 4-6 are cases where
the parent id *is* the child id (shared pk). I am not sure how important
this distinction is in practice, but I also noticed that @MapsId is only
pertinent wrt the second set of cases where we have the shared pk. This
was the first time I have noticed that distinction.
The one monkey wrench that JPA throws into the works here is that there are
essentially multiple views of an entity's PK. As one example, take the
spec's "Example 4.a":
@Entity
public class Person {
@Id String ssn;
...
}
@Entity
public class MedicalHistory {
@Id
@OneToOne
@JoinColumn(name="FK")
Person patient;
...
}
Ultimately, the primary key of MedicalHistory is the `ssn` of its
associated Person. Thus both of these are valid:
entityManager.find( MedicalHistory.class, somePerson );
entityManager.find( MedicalHistory.class, somePerson.ssn );
For those who have seen it, this is the reason for the wonkiness inside
Hibernate's runtime engine wrt incoming id type while doing a load.
I am still going through all the use cases (ours plus JPA) to make sure we
get everything covered. But I wanted to hopefully get some discussion
started around this and get any thoughts y'all might have.
10 years, 8 months
Re: [hibernate-dev] "Stale" Hibernate issues
by Brett Meyer
Hi Martijn, I'm CC'ing the mailing list -- there are a few misconceptions I'd like to clear up for everyone.
First and foremost, statements like "But nobody from the Hibernate has ever taken a look" are frankly frustrating. Hibernate is an open source project, not a proprietary product with separated groups of consumers and producers. We all have our own interests and priorities. If HHH-3930 is important for someone, pull requests or patches would be fantastic and much appreciated by the community!
Your point argues against itself. There are so many issues that deserve the community's attention, and HHH-3930 is no different from the rest. But due to the sheer amount of open tickets, it was getting impossible to sort through them all. We have to do *something* to narrow it down, and this was the best solution we could find.
Everyone, please keep in mind that if an issue is still valid on ORM 4, simply say so in a comment. I'm more than happy to re-open them on a case-by-case basis. An aggressive approach was necessary -- simply letting thousands of tickets sit there is, imho, much worse.
Regarding the development of test cases, we've said from the beginning that, although we certainly prefer runnable cases (either standalone or extending an existing unit test), I've always thought that enough detail in the description (entities, mappings, applicable settings, and code snippets) were perfectly acceptable and definitely making a big attempt at helping out. That hasn't changed. However, several people have mentioned wishing for a template project to use in creating standalone reproducers -- that's a great idea. I'm planning on putting one together soon and will share it.
Brett Meyer
Red Hat, Hibernate ORM
----- Original Message -----
From: "Martijn Dashorst" <martijn.dashorst(a)gmail.com>
To: brmeyer(a)redhat.com
Sent: Monday, April 7, 2014 2:41:20 PM
Subject: "Stale" Hibernate issues
Dear Brett,
I understand the necessity of sorting out stale issues in a large project
as Hibernate, but blindly shafting folks that are waiting 5 years for a
proper response from the hibernate team is not the way to go.
Case in point: HHH-3930 has been open for 5 years, has provided a clear
description and code for two entities afflicted entities. But nobody from
the Hibernate has ever taken a look and commented on it for specific
information.
Only canned responses from mass updates have been provided.
I urge you to actually look at this issue and give proper feedback on what
is needed for it to be considered.
If the information is incomplete, or the report unclear, say so.
IMO you can only require folks adding a test case if you have a decent
guide of how to write one. Provide a maven archetype for it.
Requiring folks to have to checkout the hibernate project, figure out the
coding guidelines, having to peruse the test cases to figure out what to do
is really stretching it.
You state that you don't want to come across as arrogant, but from my
standpoint, the current actions actually make me wish I never had filed the
issue and just work around it, polluting my model and never going to file a
bug report with Hibernate ever again.
Martijn
10 years, 8 months
CI environment
by Steve Ebersole
There is something very very funky going on in the CI environment.
The ORM master job hangs almost every run now. Oddly, it hangs trying to
compile test classes. I have tried a number of things in attempt to find
out why. I have added `strace` to the job command, ssh'iong to the box and
manually watching processes. None of this has illuminated the cause for
me. Interestingly, I tried using Gradle's --debug option but then of
course the job does not hang.
OGM job (at least #110) is fubar as well. It is just sitting there
spinning. The console shows absolutely nothing. Its been in that state
for "Started 9 hr 48 min ago" as of the time I write this.
10 years, 9 months
