Re: [hibernate-dev] ORM Jenkins Builds

We should remove that -XX:MaxPermSize=512m setting as we discussed before. I understand all of that. I still think its probably worthwhile to look at minimizing the amount of time and resources. For a couple of reasons. First I am doing a lot of dev right now. In the 40-50 minutes it takes to r

Re: [hibernate-dev] ORM Jenkins Builds

Hi Steve, don't worry for the resources they consume. Each build job which we run is fully isolated and running on independent hardware, so it's not going to slow down any other build. Since we now have a set of small servers, one each dedicated for a job at a time, I've opted for low spec machine

[hibernate-dev] ORM Jenkins Builds

I was curious why it took so long to run the master ORM jobs on the CI machine compared to running the job locally. Locally I run `clean test` at the root prject quite often and it takes roughly 9-10 minutes. The master CI jobs generally take 45-50 minutes to complete. So I enabled "Gradle build

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

I had been working on the assumption that the entity is mutable/immutable. Is it possible for EntityEntry to be immutable? e.g. is it valid for states such as BooleanState.IS_BEING_REPLICATED or BooleanState.LOADED_WITH_LAZY_PROPERTIES_UNFETCHED to change during the lifetime of the EntityEntry

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

The only distinction we care about is EntityPetsister#isMutable. The read-only case should be handled by the normal MutableEntityEntry. In other words there is nothing to pass to EntityPersister to make a decision based on; just getEntityEntryBuilder (). As far as LockMode, I think it makes the

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

On 27/03/15 12:14, Sanne Grinovero wrote: > Also from OGM and Search perspective, we're not expecting any of this > to be backported. > It's not a functional blocker, "just" significant performance improvements. > > How do we move further? John, I'm not familiar with the requirements > for the by

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

Also from OGM and Search perspective, we're not expecting any of this to be backported. It's not a functional blocker, "just" significant performance improvements. How do we move further? John, I'm not familiar with the requirements for the bytecode instrumentation, but can help a bit on the other

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

Steve, From our point of view, we would not be looking to backport any features introduced to any of the ORM4 releases. Our focus has shifted to the next major release of EAP as we have a number of issues we need to overcome. Getting this feature into ORM5 sooner rather than later is essentia

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

BTW, if we go this route this *cannot* be backported because we do allow users to override EntityPersister; its an extension point. Adding a new method to extension points in bugfixes is a no-no. On Fri, Mar 27, 2015 at 6:35 AM, Steve Ebersole wrote: > An EntityPersister describes each entity y

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

An EntityPersister describes each entity you defined in your model. Its one-to-one between @Entity and EntityPersister. And really, it is totally reasonable to have the EntityPersister determine the "EntityEntry builder" to use. That also eliminates needing to develop yet-another-extension-point

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

On 26/03/15 16:22, Steve Ebersole wrote: > The contract I suggested btw is missing one use case I know we have > discussed in regards to OGM a few times... the ability to store > references to datastore specific locators (I think the use case was to > efficiently load collections through that da

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

On 26/03/15 16:35, Steve Ebersole wrote: > Now the "meat"... > > On Thu, Mar 26, 2015 at 10:20 AM, Sanne Grinovero > wrote: > > > What is your primary differentiator between 'SharedEntityEntry' and > 'StatefulEntityEntry' ? > For our purposes I'd have used d

Re: [hibernate-dev] Bytecode enhanced, Reference Cached immutable Entities

On 26/03/15 15:20, Sanne Grinovero wrote: > [adding the mailing list] > > Generally speaking, looks like we agree on the direction: EntityEntry > needs to be an interface, and some clever logic to select the > appropriate implementations. > In your draft you're having a single EntityEntryFactory as