From sanne at hibernate.org  Sun Nov  1 17:01:18 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 1 Nov 2015 14:01:18 -0800
Subject: [hibernate-dev] Fwd:  Link to test case templates
In-Reply-To: <CAB63Y-drDoQ6DzXaGoH4oaHLGVYNgwAg3+RtgBgZACX0dX=X9w@mail.gmail.com>
References: <CADGJaX-d3DwegXEfFW7C=j0HaRuOqim2_hnqMvsV=HyA1N_Q2w@mail.gmail.com>
	<CAFdSV9vLB7XSTKQmLiTHkPUZ-4PFWPxTWFm=Kpn5B2_7zvfPXw@mail.gmail.com>
	<CAFdSV9uAh2N-Uz--5AJu_AW0ryJvwtQ-L1Fg3vzUPs=rhk9LAw@mail.gmail.com>
	<CAFdSV9tZacyzEOy83Fx-qnuy2JGcN18+9722kuXBKB_uQvwUgg@mail.gmail.com>
	<CADGJaX8ood3xEGGXZ7rS8-9qi45q55n6dEN_UVbgrhYaQp_4Uw@mail.gmail.com>
	<CAFdSV9vcnh1h88OG9Af47S4Mbutomww0EHdET-Vrhv12cxYTgw@mail.gmail.com>
	<CAFm4XO2gVJjiWnN3iZPJ-wcqLLC39jiE17dQLRU3LiEWmOztSQ@mail.gmail.com>
	<CAB63Y-drDoQ6DzXaGoH4oaHLGVYNgwAg3+RtgBgZACX0dX=X9w@mail.gmail.com>
Message-ID: <CAFm4XO2JeeOD83pxbFbWkaso9+8S+AAy3igZ+W2zQOXsD7PXRg@mail.gmail.com>

Adding back the list.

To answer Martijn: personally I don't know the answer, but it sounds
like an excellent idea to implement that, if it's not possible
already.
Keep in mind that Hibernate might need to generate multiple SQL
statements per operation.

Sanne

---------- Forwarded message ----------
From: Martijn Dashorst <martijn.dashorst at gmail.com>
Date: 31 October 2015 at 05:43
Subject: Re: [hibernate-dev] Link to test case templates
To: Sanne Grinovero <sanne at hibernate.org>


Good to see making test cases easier.

Is it possible to test the actual SQL that is emitted by Hibernate
from a test case? I've looked at the github repo but didn't find a
matching method.

Martijn

On Friday, 30 October 2015, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> We should add a page on hibernate.org describing the idea, and from
> there point to github.
>
> On 30 October 2015 at 07:49, Steve Ebersole <steve at hibernate.org> wrote:
> > But that was not the purpose of the content at the old link.   Yes the
> > templates are nice  but that's not the whole picture of what makes a good
> > test case
> >
> > On Fri, Oct 30, 2015, 9:41 AM Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> >> 2015-10-30 15:16 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> > It looks like that may just be an invalid URL.
> >>
> >> Yes, the link should point to
> >> https://github.com/hibernate/hibernate-test-case-templates instead.
> >> There are the test case templates and also a description of their
> >> usage.
> >>
> >>
> >> >  It looks like the content
> >> > that was at that URL was not migrated over in the website migration.
> >> >
> >> > This ties in with an uneasiness that has been growing on me tbh...  We
> >> have
> >> > too many places users have to look for  potential information.  The
> >> website,
> >> > the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds.  It's
> >> hard to
> >> > keep straight :)
> >> >
> >> > Ideally a lot of this would live under hibernate.org website umbrella.
> >> But
> >> > to be frank, I find developing content for hibernate.org and
> >> in.relation.to
> >> > to be cumbersome.  We can get into "why" in a separate subject.
> >> >
> >> >
> >> >
> >> > On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >> >>
> >> >> But for some reason it directs me back to JIra.  Even just clicking that
> >> >> link in the email does.  I wonder if someone set up a bad redirect on
> >> the
> >> >> hibernate.org website for that?
> >> >>
> >> >> On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole <steve at hibernate.org>
> >> >> wrote:
> >> >>>
> >> >>> The link target is
> >> http://www.hibernate.org/issuetracker.html#testcases.
> >> >>> That's not the "JIRA main page".
> >> >>>
> >> >>>
> >> >>> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling <gunnar at hibernate.org>
> >> >>> wrote:
> >> >>>>
> >> >>>> Hi,
> >> >>>>
> >> >>>> When creating a new HHH issue, there is a link "...should generally be
> >> >>>> accompanied by a test case" but it directs to the JIRA main page.
> >> >>>>
> >> >>>> Can we let it point to the test case template repo instead:
> >> >>>>
> >> >>>>     https://github.com/hibernate/hibernate-test-case-templates
> >> >>>>
> >> >>>> Thanks,
> >> >>>>
> >> >>>> --Gunnar
> >> >>>> _______________________________________________
> >> >>>> hibernate-dev mailing list
> >> >>>> hibernate-dev at lists.jboss.org
> >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



--
Become a Wicket expert, learn from the best: http://wicketinaction.com

From rvansa at redhat.com  Mon Nov  2 03:28:52 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 2 Nov 2015 09:28:52 +0100
Subject: [hibernate-dev] Fwd: Link to test case templates
In-Reply-To: <CAFm4XO2JeeOD83pxbFbWkaso9+8S+AAy3igZ+W2zQOXsD7PXRg@mail.gmail.com>
References: <CADGJaX-d3DwegXEfFW7C=j0HaRuOqim2_hnqMvsV=HyA1N_Q2w@mail.gmail.com>
	<CAFdSV9vLB7XSTKQmLiTHkPUZ-4PFWPxTWFm=Kpn5B2_7zvfPXw@mail.gmail.com>
	<CAFdSV9uAh2N-Uz--5AJu_AW0ryJvwtQ-L1Fg3vzUPs=rhk9LAw@mail.gmail.com>
	<CAFdSV9tZacyzEOy83Fx-qnuy2JGcN18+9722kuXBKB_uQvwUgg@mail.gmail.com>
	<CADGJaX8ood3xEGGXZ7rS8-9qi45q55n6dEN_UVbgrhYaQp_4Uw@mail.gmail.com>
	<CAFdSV9vcnh1h88OG9Af47S4Mbutomww0EHdET-Vrhv12cxYTgw@mail.gmail.com>
	<CAFm4XO2gVJjiWnN3iZPJ-wcqLLC39jiE17dQLRU3LiEWmOztSQ@mail.gmail.com>
	<CAB63Y-drDoQ6DzXaGoH4oaHLGVYNgwAg3+RtgBgZACX0dX=X9w@mail.gmail.com>
	<CAFm4XO2JeeOD83pxbFbWkaso9+8S+AAy3igZ+W2zQOXsD7PXRg@mail.gmail.com>
Message-ID: <56371EC4.4010302@redhat.com>

You can mock the JDBC driver and test the emitted SQL from there; I am 
using mockrunner-jdbc [1] to do that. Since Hibernate needs to chat with 
DB a bit before doing the logic of that test, it's convenient to switch 
between real DB and the mocks at runtime. I've created a little tool [2] 
to do that - actually this disables recording of executed statements 
(since I am using this for performance testing rather than behaviour 
verification), but it's trivial to revert that ([3] - just use default 
ctor).

Radim

[1] https://github.com/mockrunner/mockrunner
[2] https://github.com/rvansa/perfmock
[3] 
https://github.com/rvansa/perfmock/blob/master/src/main/java/org/perfmock/PerfMockDriver.java#L179

On 11/01/2015 11:01 PM, Sanne Grinovero wrote:
> Adding back the list.
>
> To answer Martijn: personally I don't know the answer, but it sounds
> like an excellent idea to implement that, if it's not possible
> already.
> Keep in mind that Hibernate might need to generate multiple SQL
> statements per operation.
>
> Sanne
>
> ---------- Forwarded message ----------
> From: Martijn Dashorst <martijn.dashorst at gmail.com>
> Date: 31 October 2015 at 05:43
> Subject: Re: [hibernate-dev] Link to test case templates
> To: Sanne Grinovero <sanne at hibernate.org>
>
>
> Good to see making test cases easier.
>
> Is it possible to test the actual SQL that is emitted by Hibernate
> from a test case? I've looked at the github repo but didn't find a
> matching method.
>
> Martijn
>
> On Friday, 30 October 2015, Sanne Grinovero <sanne at hibernate.org> wrote:
>> We should add a page on hibernate.org describing the idea, and from
>> there point to github.
>>
>> On 30 October 2015 at 07:49, Steve Ebersole <steve at hibernate.org> wrote:
>>> But that was not the purpose of the content at the old link.   Yes the
>>> templates are nice  but that's not the whole picture of what makes a good
>>> test case
>>>
>>> On Fri, Oct 30, 2015, 9:41 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>>
>>>> 2015-10-30 15:16 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>> It looks like that may just be an invalid URL.
>>>> Yes, the link should point to
>>>> https://github.com/hibernate/hibernate-test-case-templates instead.
>>>> There are the test case templates and also a description of their
>>>> usage.
>>>>
>>>>
>>>>>   It looks like the content
>>>>> that was at that URL was not migrated over in the website migration.
>>>>>
>>>>> This ties in with an uneasiness that has been growing on me tbh...  We
>>>> have
>>>>> too many places users have to look for  potential information.  The
>>>> website,
>>>>> the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds.  It's
>>>> hard to
>>>>> keep straight :)
>>>>>
>>>>> Ideally a lot of this would live under hibernate.org website umbrella.
>>>> But
>>>>> to be frank, I find developing content for hibernate.org and
>>>> in.relation.to
>>>>> to be cumbersome.  We can get into "why" in a separate subject.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>>> But for some reason it directs me back to JIra.  Even just clicking that
>>>>>> link in the email does.  I wonder if someone set up a bad redirect on
>>>> the
>>>>>> hibernate.org website for that?
>>>>>>
>>>>>> On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>> The link target is
>>>> http://www.hibernate.org/issuetracker.html#testcases.
>>>>>>> That's not the "JIRA main page".
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling <gunnar at hibernate.org>
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> When creating a new HHH issue, there is a link "...should generally be
>>>>>>>> accompanied by a test case" but it directs to the JIRA main page.
>>>>>>>>
>>>>>>>> Can we let it point to the test case template repo instead:
>>>>>>>>
>>>>>>>>      https://github.com/hibernate/hibernate-test-case-templates
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Gunnar
>>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From gunnar at hibernate.org  Mon Nov  2 08:06:28 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 2 Nov 2015 14:06:28 +0100
Subject: [hibernate-dev] SQM : Criteria translation design
In-Reply-To: <CAFdSV9ubGLZRYEVSp5cUydqp1cDVEftFeDe7T9zYDgdM5OUSKg@mail.gmail.com>
References: <CAFdSV9ubGLZRYEVSp5cUydqp1cDVEftFeDe7T9zYDgdM5OUSKg@mail.gmail.com>
Message-ID: <CADGJaX9OzdfCY=PF=OA0BU4MncJpqLaP2w=OpB1w2gdMPNe8GA@mail.gmail.com>

Hi,

What exactly DYM by "The criteria nodes would be expected to implement
an SQM extension accepting a visitor"?

My first thought would have been a combination of the two approaches:
Let the criteria objects expose all the required data, make them
traversable by means of a visitor and have an SQM-specific visitor
implementation which converts each criteria object into its SQM
counter-part.

--Gunnar




2015-10-30 12:41 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I started work on SQM-24 which covers translation of criteria queries into
> SQM.
>
> The difficulty with this is that the JPA contracts alone do not give enough
> information to really be able to understand the semantics of the query;
> there is just not enough information exposed.  I can get into specific
> examples if that helps, but for now lets take that as a given...
>
> So then how do we go about translating a criteria into an SQM?  There are
> going to be 2 main approaches.  Each requires some level of extension to
> the standard contracts:
>
> The first approach is to use visitation.  The criteria nodes would be
> expected to implement an SQM extension accepting a visitor and do the right
> thing.  The gains here are the normal gains with the visitor pattern.  The
> downside is that this makes SQM highly dependent on the criteria impl doing
> the right thing and makes the criteria impl sensitive to SQM (depending n
> how we expose the visitation methods to a degree).
>
> The second approach would be to extended the standard criteria contracts to
> more fully cover the semantic.  As one example, JPA defines just Predicate
> (for the most part) without exposing the type of predicate.  Is it a LIKE
> expression?  A BETWEEN?  A Comparison (=, !=, <, etc)?  We just don't know
> from the standard contracts.  So we'd have to develop a full semantic
> extension model here.  `interface LikePredicate extends Predicate`,
> `BetweenPredicate extends Predicate`, etc.
>
> I lean towards the visitor approach given these choices.  Anyone else have
> opinions?  Other options?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Nov  2 10:16:35 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 02 Nov 2015 15:16:35 +0000
Subject: [hibernate-dev] HQL and spatial
In-Reply-To: <CAFdSV9uMB-YcNYTDZRKV4F6F0m5z75diX_xyvpj4uHjdERS-7g@mail.gmail.com>
References: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>
	<B7499E79-DCD8-4174-AFFD-8355E1B39780@geovise.com>
	<CAFdSV9tqQvwYze4aE8p2+R9Y-BXWLWVbPX5_OeFOtomLd_1MxQ@mail.gmail.com>
	<425DA269-9600-4F34-8B28-EEFC6140972A@geovise.com>
	<CAFdSV9uMB-YcNYTDZRKV4F6F0m5z75diX_xyvpj4uHjdERS-7g@mail.gmail.com>
Message-ID: <CAFdSV9vsOPZFyCPrYMRGrq3xMucYwJkZRxqeFevQRvZREP3pzg@mail.gmail.com>

Karel,

Any further thoughts?

I looked over the link you gave in regards to literals, but did not fully
understand.  I'd prefer this follow some "escape syntax" form, beyond that
maybe you could just enumerate the literal types you'd want to support and
their formats.

ALso, I have not seen any discussion around "boolean-function-expressions
as predicates" on SQM-15...


On Thu, Sep 10, 2015 at 7:12 AM Steve Ebersole <steve at hibernate.org> wrote:

> It is true that not all applications use spatial, or even that DB?s
>> support (all) spatial functions. But it would help to ensure consistency in
>> the available dialects. Now this consistency is tested for in the
>> integration tests, so not having this at the grammar isn?t a big problem.
>>
>
> Its up to you.  We can add it to the grammar and simply have it throw
> exceptions if those functions are not understood.
>
>
> Support for spatial literals would be a great plus. In my opinion, the
>> best candidate for HQL spatial literals is the Postgis EWKT format (
>> http://postgis.net/docs/manual-2.1/using_postgis_dbmanagement.html#EWKB_EWKT),
>> which is a sane, and popular extension of the purely 2D WKT standard. It
>> is  supported in the geolatte-geom library and many others. I can help by
>> writing a grammar for this.
>>
>
> What I have done thus far in SQM grammars is to borrow from the idea of
> "JDBC escape syntax".  So for example, to define a timestamp literal one
> would say `{ts '2015-10-10 ...'}`
>
>
> There is also at least one HQL syntax change that would help implement
>> spatial functions:  function invocations that evaluate to boolean should be
>> regarded as valid boolean expressions. The HQL currently doesn?t seem to
>> allow this, so I needed to wrap them in equality expressions. But then
>> MySQL wouldn?t use its spatial index (as I wrote before, although I
>> mistakenly wrote ?spatial query? in my original email).
>>
>
> This would require some knowledge of the "metadata" of a function, which
> is not there in SQM at all so far.  Here, I'd have to know the return type
> of the referenced function.  We can contemplate that.
> https://hibernate.atlassian.net/browse/SQM-15
>
>
>

From smarlow at redhat.com  Mon Nov  2 10:50:43 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 2 Nov 2015 10:50:43 -0500
Subject: [hibernate-dev] Hibernate5 migration
In-Reply-To: <CAFdSV9to6qN1OeD2yKJL-oinPRNETEPxP-LZ0rsm1ncOMRUP+Q@mail.gmail.com>
References: <009201d0d53c$8a9acfe0$9fd06fa0$@error.be>
	<CAFdSV9sxCmUGz71whp0XB0UF_AbR2y-aPL4euWS0VZ3eg2xdsA@mail.gmail.com>
	<00a201d0d583$4f5f1d90$ee1d58b0$@error.be>
	<CAFdSV9to6qN1OeD2yKJL-oinPRNETEPxP-LZ0rsm1ncOMRUP+Q@mail.gmail.com>
Message-ID: <56378653.903@redhat.com>

Should the ORM 5 migration documentation [3] mention that 
"hibernate.transaction.factory_class" can no longer be set to 
"org.hibernate.transaction.CMTTransactionFactory"?  I think that 
CMTTransactionFactory is deleted in 5.0.

Scott

[3] 
https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc


On 08/13/2015 08:38 AM, Steve Ebersole wrote:
> For a lot of your questions, I'd highly suggest reading [1] and [2].  They
> are mostly the same content (asciidoc versus docbook).
>
> [1] -
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
> [2] -
> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#bootstrap-native
>
>
>
>
> On Wed, Aug 12, 2015 at 11:58 PM Koen Serneels <ks at error.be> wrote:
>
>> Hi Steve,
>>
>>
>>
>> Let me clarify the first two questions:
>>
>>
>>
>> I?m looking for an entry point/hook in H5 for altering existing class
>> mappings. For example; some of our entities are supposed to be immutable,
>> but only in production mode.
>>
>> When running our tests we are using that same model to setup data in an
>> in-memory database. If the entities would be hardcoded immutable then we
>> would be problematic to use them fully for manipulating setup data in our
>> tests. So, in test mode we actually need the entities to be mutable instead.
>>
>> To accomplish this we  are retrieving  the classMappings from the
>> Configuration which gives us the PersistentClass meta-data. On  this which
>> we can then toggle the mutable flag depending.
>>
>> Since that functionality has now been refactored, I thought that
>> MetadataContributor was the way to go in H5 as it lets me access
>> InFlightMetadataCollector which gives access to getEntityBindingMap which
>> allows to retrieved the PersistentClasses.
>>
>>
>>
>> However, from the source code I understand that the MetadataContributor
>> can only be configured using ServiceLoader. This means it will not be so
>> straightforward/clean to enable or disable that said MetadataContributor
>> dynamically. Now you suggest:  *But if a piece of code is able to
>> determine whether or not to register a MetadataContributor, it could simply
>> contribute said metadata, no?* yes, but this is probably where my
>> understanding is falling short; I was under the impression that the
>> MetadataContributor is **the** new way for contributing changes or
>> additions to existing meta-data. If there is another (programmatic) way
>> without having to register MetadataContributor, then by all means, but
>> how/where?
>>
>>
>>
>> On the JTA question:
>>
>>
>>
>> My question has been answered, thanks, but just to clarify: when using
>> JTA, we can configure the shorthand alias ?jta? for the coordinator as you
>> state.
>>
>> With the second part I meant; what if we are _*not*_ using JTA but are in
>> local transaction mode, should we then also explicitly configure the
>> coordinator (with short name ?jdbc? in that case) or will it be the
>> default? Again you confirm that ?jdbc? is the default so when not using JTA
>> no coordinator setting is required
>>
>>
>>
>> For the last question:
>>
>>
>>
>> Ok thanks for pointing that out. Is there an easy way to get hold of the
>> org.hibernate.boot.Metadata which I need to pass to
>> SchemaCreator/SchemaDropper?
>>
>> I could also use SchemaExport directly from within code, but afaik it will
>> rebuild the metadata which will probably take longer?
>>
>>
>>
>> To give some background how I?m using this:  in some types of test we
>> actually commit data to our in-memory database. In order to clear the
>> database between tests, we simply drop and recreate the entire schema based
>> on the DDL. This was the fastest solution with the least amount of impact.
>> For the record: I?m aware there are other solutions for this, but not all
>> of them are feasible. I?m leaving out the details here as it would go off
>> topic ? at the moment I?m just looking for a way to migrate it to H5
>> keeping the same functionality we have been using (extract the create/drop
>> DDL from a live SF as fast as possible)
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Koen.
>>
>>
>>
>> *From:* Steve Ebersole [mailto:steve at hibernate.org]
>> *Sent:* donderdag 13 augustus 2015 4:24
>> *To:* Koen Serneels; hibernate-dev at lists.jboss.org
>> *Subject:* Re: [hibernate-dev] Hibernate5 migration
>>
>>
>>
>> There is a migration guide:
>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md.
>> It is still a work in progress as in its is not "prettified" yet (as 5.0 is
>> not final yet.  If things are missing please let us know.
>>
>>
>>
>> Some answers inline...
>>
>>
>>
>>
>>
>> - In Hibernate4 we modified mappings on-the-fly by overriding Spring's
>> LocalSessionFactoryBean#buildSessionFactory.
>>
>>
>> Doing so we could first access the getClassMapping on
>> org.hibernate.cfg.Configuration before letting the SF actually build.
>>
>> However, in Hibernate5 the metadata access has been refactored and is no
>> longer part of the Configuration. Should we use MetadataContributor instead
>> for these purposes?
>>
>>
>>
>>
>>
>> Depends what you are trying to achieve specifically.  What do you mean by
>> "modify"?  Do you mean literally that you want to modify (alter) the
>> existing "class mappings", or do you really mean that you want to add
>> additional mappings?
>>
>>
>>
>>
>>
>> - Is there a way to register MetadataContributor dynamically? I see that it
>> is being loaded using Java's ServiceLoader.
>>
>> However, I need some programmatic API access to enable or disable the
>> Contributor (for example based on Spring profiles).
>>
>>
>>
>> No there is not a way to register a MetadataContributor programatically.
>> I really do not see the benefit of having that as a feature.  Maybe you
>> need to explain better?  But if a piece of code is able to determine
>> whether or not to register a MetadataContributor, it could simply
>> contribute said metadata, no?
>>
>>
>>
>>
>>
>> - For JTA integration we were using
>> org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory, but
>> this class is no longer present.
>>
>> Also in org.hibernate.cfg.AvailableSettings the key that was used
>> (hibernate.transaction.factory_class) to configure the factory is also
>> removed.
>>
>> Is hibernate.transaction.coordinator_class the new key we should be using
>> instead with
>>
>> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordi
>> natorImpl as value for JTA?
>>
>>
>>
>> Yes, but I would highly recommend using the short-name config values, e.g.:
>>
>>
>>
>> hibernate.transaction.coordinator_class=jta
>>
>>
>>
>> rather than:
>>
>>
>>
>>
>> hibernate.transaction.coordinator_class=org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl
>>
>>
>>
>> Both do the same thing, the first form is just better (for many reasons).
>>
>>
>>
>>
>>
>> Do we need to configure anything special in case of resource local TX or is
>> JdbcResourceLocalTransactionCoordinatorImpl the default?
>>
>>
>>
>> I'm confused with this last piece in combination with the rest of the
>> questions here.  The rest of the block discusses JTA, but then here you are
>> asking about JDBC-based transactions.  Regardless, the default
>> TransactionCoordinator is in fact the JDBC one.
>>
>>
>>
>>
>>
>> - generateDropSchemaScript and generateSchemaCreationScript have been
>> removed from Configuration. Is there a way to access this in another way?
>>
>>
>>
>> Again, depends on exactly what you hope to accomplish here.  Your main
>> options will be either:
>> 1) grab the org.hibernate.tool.schema.spi.SchemaManagementTool from the
>> StandardServiceRegistry and use it to obtain the SchemaCreator
>> and SchemaDropper, passing them the Metadata.
>>
>> 2) Use the org.hibernate.tool.hbm2ddl.SchemaExport class
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Nov  2 11:02:17 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 02 Nov 2015 16:02:17 +0000
Subject: [hibernate-dev] Hibernate5 migration
In-Reply-To: <56378653.903@redhat.com>
References: <009201d0d53c$8a9acfe0$9fd06fa0$@error.be>
	<CAFdSV9sxCmUGz71whp0XB0UF_AbR2y-aPL4euWS0VZ3eg2xdsA@mail.gmail.com>
	<00a201d0d583$4f5f1d90$ee1d58b0$@error.be>
	<CAFdSV9to6qN1OeD2yKJL-oinPRNETEPxP-LZ0rsm1ncOMRUP+Q@mail.gmail.com>
	<56378653.903@redhat.com>
Message-ID: <CAFdSV9tJr9SCDsE+EJGP-iX8Hwg3XMQupM3Ot_wGSGWRr36fYg@mail.gmail.com>

This is mentioned...
https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc#transactions

Its not just org.hibernate.transaction.CMTTransactionFactory that was
removed; all of the TransactionFactory classes were removed.  Actually I
think we should add them as resolvable names:

* org.hibernate.transaction.CMTTransactionFactory
-> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
* org.hibernate.transaction.JTATransactionFactory
-> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
* org.hibernate.transaction.JDBCTransactionFactory ->
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorBuilderImpl

Add a Jira if you'd like to see them mapped.


On Mon, Nov 2, 2015 at 9:51 AM Scott Marlow <smarlow at redhat.com> wrote:

> Should the ORM 5 migration documentation [3] mention that
> "hibernate.transaction.factory_class" can no longer be set to
> "org.hibernate.transaction.CMTTransactionFactory"?  I think that
> CMTTransactionFactory is deleted in 5.0.
>
> Scott
>
> [3]
> https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc
>
>
> On 08/13/2015 08:38 AM, Steve Ebersole wrote:
> > For a lot of your questions, I'd highly suggest reading [1] and [2].
> They
> > are mostly the same content (asciidoc versus docbook).
> >
> > [1] -
> >
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
> > [2] -
> >
> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#bootstrap-native
> >
> >
> >
> >
> > On Wed, Aug 12, 2015 at 11:58 PM Koen Serneels <ks at error.be> wrote:
> >
> >> Hi Steve,
> >>
> >>
> >>
> >> Let me clarify the first two questions:
> >>
> >>
> >>
> >> I?m looking for an entry point/hook in H5 for altering existing class
> >> mappings. For example; some of our entities are supposed to be
> immutable,
> >> but only in production mode.
> >>
> >> When running our tests we are using that same model to setup data in an
> >> in-memory database. If the entities would be hardcoded immutable then we
> >> would be problematic to use them fully for manipulating setup data in
> our
> >> tests. So, in test mode we actually need the entities to be mutable
> instead.
> >>
> >> To accomplish this we  are retrieving  the classMappings from the
> >> Configuration which gives us the PersistentClass meta-data. On  this
> which
> >> we can then toggle the mutable flag depending.
> >>
> >> Since that functionality has now been refactored, I thought that
> >> MetadataContributor was the way to go in H5 as it lets me access
> >> InFlightMetadataCollector which gives access to getEntityBindingMap
> which
> >> allows to retrieved the PersistentClasses.
> >>
> >>
> >>
> >> However, from the source code I understand that the MetadataContributor
> >> can only be configured using ServiceLoader. This means it will not be so
> >> straightforward/clean to enable or disable that said MetadataContributor
> >> dynamically. Now you suggest:  *But if a piece of code is able to
> >> determine whether or not to register a MetadataContributor, it could
> simply
> >> contribute said metadata, no?* yes, but this is probably where my
> >> understanding is falling short; I was under the impression that the
> >> MetadataContributor is **the** new way for contributing changes or
> >> additions to existing meta-data. If there is another (programmatic) way
> >> without having to register MetadataContributor, then by all means, but
> >> how/where?
> >>
> >>
> >>
> >> On the JTA question:
> >>
> >>
> >>
> >> My question has been answered, thanks, but just to clarify: when using
> >> JTA, we can configure the shorthand alias ?jta? for the coordinator as
> you
> >> state.
> >>
> >> With the second part I meant; what if we are _*not*_ using JTA but are
> in
> >> local transaction mode, should we then also explicitly configure the
> >> coordinator (with short name ?jdbc? in that case) or will it be the
> >> default? Again you confirm that ?jdbc? is the default so when not using
> JTA
> >> no coordinator setting is required
> >>
> >>
> >>
> >> For the last question:
> >>
> >>
> >>
> >> Ok thanks for pointing that out. Is there an easy way to get hold of the
> >> org.hibernate.boot.Metadata which I need to pass to
> >> SchemaCreator/SchemaDropper?
> >>
> >> I could also use SchemaExport directly from within code, but afaik it
> will
> >> rebuild the metadata which will probably take longer?
> >>
> >>
> >>
> >> To give some background how I?m using this:  in some types of test we
> >> actually commit data to our in-memory database. In order to clear the
> >> database between tests, we simply drop and recreate the entire schema
> based
> >> on the DDL. This was the fastest solution with the least amount of
> impact.
> >> For the record: I?m aware there are other solutions for this, but not
> all
> >> of them are feasible. I?m leaving out the details here as it would go
> off
> >> topic ? at the moment I?m just looking for a way to migrate it to H5
> >> keeping the same functionality we have been using (extract the
> create/drop
> >> DDL from a live SF as fast as possible)
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Koen.
> >>
> >>
> >>
> >> *From:* Steve Ebersole [mailto:steve at hibernate.org]
> >> *Sent:* donderdag 13 augustus 2015 4:24
> >> *To:* Koen Serneels; hibernate-dev at lists.jboss.org
> >> *Subject:* Re: [hibernate-dev] Hibernate5 migration
> >>
> >>
> >>
> >> There is a migration guide:
> >>
> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
> .
> >> It is still a work in progress as in its is not "prettified" yet (as
> 5.0 is
> >> not final yet.  If things are missing please let us know.
> >>
> >>
> >>
> >> Some answers inline...
> >>
> >>
> >>
> >>
> >>
> >> - In Hibernate4 we modified mappings on-the-fly by overriding Spring's
> >> LocalSessionFactoryBean#buildSessionFactory.
> >>
> >>
> >> Doing so we could first access the getClassMapping on
> >> org.hibernate.cfg.Configuration before letting the SF actually build.
> >>
> >> However, in Hibernate5 the metadata access has been refactored and is no
> >> longer part of the Configuration. Should we use MetadataContributor
> instead
> >> for these purposes?
> >>
> >>
> >>
> >>
> >>
> >> Depends what you are trying to achieve specifically.  What do you mean
> by
> >> "modify"?  Do you mean literally that you want to modify (alter) the
> >> existing "class mappings", or do you really mean that you want to add
> >> additional mappings?
> >>
> >>
> >>
> >>
> >>
> >> - Is there a way to register MetadataContributor dynamically? I see
> that it
> >> is being loaded using Java's ServiceLoader.
> >>
> >> However, I need some programmatic API access to enable or disable the
> >> Contributor (for example based on Spring profiles).
> >>
> >>
> >>
> >> No there is not a way to register a MetadataContributor programatically.
> >> I really do not see the benefit of having that as a feature.  Maybe you
> >> need to explain better?  But if a piece of code is able to determine
> >> whether or not to register a MetadataContributor, it could simply
> >> contribute said metadata, no?
> >>
> >>
> >>
> >>
> >>
> >> - For JTA integration we were using
> >> org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory, but
> >> this class is no longer present.
> >>
> >> Also in org.hibernate.cfg.AvailableSettings the key that was used
> >> (hibernate.transaction.factory_class) to configure the factory is also
> >> removed.
> >>
> >> Is hibernate.transaction.coordinator_class the new key we should be
> using
> >> instead with
> >>
> >>
> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordi
> >> natorImpl as value for JTA?
> >>
> >>
> >>
> >> Yes, but I would highly recommend using the short-name config values,
> e.g.:
> >>
> >>
> >>
> >> hibernate.transaction.coordinator_class=jta
> >>
> >>
> >>
> >> rather than:
> >>
> >>
> >>
> >>
> >>
> hibernate.transaction.coordinator_class=org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl
> >>
> >>
> >>
> >> Both do the same thing, the first form is just better (for many
> reasons).
> >>
> >>
> >>
> >>
> >>
> >> Do we need to configure anything special in case of resource local TX
> or is
> >> JdbcResourceLocalTransactionCoordinatorImpl the default?
> >>
> >>
> >>
> >> I'm confused with this last piece in combination with the rest of the
> >> questions here.  The rest of the block discusses JTA, but then here you
> are
> >> asking about JDBC-based transactions.  Regardless, the default
> >> TransactionCoordinator is in fact the JDBC one.
> >>
> >>
> >>
> >>
> >>
> >> - generateDropSchemaScript and generateSchemaCreationScript have been
> >> removed from Configuration. Is there a way to access this in another
> way?
> >>
> >>
> >>
> >> Again, depends on exactly what you hope to accomplish here.  Your main
> >> options will be either:
> >> 1) grab the org.hibernate.tool.schema.spi.SchemaManagementTool from the
> >> StandardServiceRegistry and use it to obtain the SchemaCreator
> >> and SchemaDropper, passing them the Metadata.
> >>
> >> 2) Use the org.hibernate.tool.hbm2ddl.SchemaExport class
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Mon Nov  2 11:46:10 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 2 Nov 2015 11:46:10 -0500
Subject: [hibernate-dev] Hibernate5 migration
In-Reply-To: <CAFdSV9tJr9SCDsE+EJGP-iX8Hwg3XMQupM3Ot_wGSGWRr36fYg@mail.gmail.com>
References: <009201d0d53c$8a9acfe0$9fd06fa0$@error.be>
	<CAFdSV9sxCmUGz71whp0XB0UF_AbR2y-aPL4euWS0VZ3eg2xdsA@mail.gmail.com>
	<00a201d0d583$4f5f1d90$ee1d58b0$@error.be>
	<CAFdSV9to6qN1OeD2yKJL-oinPRNETEPxP-LZ0rsm1ncOMRUP+Q@mail.gmail.com>
	<56378653.903@redhat.com>
	<CAFdSV9tJr9SCDsE+EJGP-iX8Hwg3XMQupM3Ot_wGSGWRr36fYg@mail.gmail.com>
Message-ID: <56379352.8070502@redhat.com>


On 11/02/2015 11:02 AM, Steve Ebersole wrote:
> This is mentioned...
> https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc#transactions
>
> Its not just org.hibernate.transaction.CMTTransactionFactory that was
> removed; all of the TransactionFactory classes were removed. Actually I
> think we should add them as resolvable names:
>
> * org.hibernate.transaction.CMTTransactionFactory
> -> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
> * org.hibernate.transaction.JTATransactionFactory
> -> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
> * org.hibernate.transaction.JDBCTransactionFactory ->
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorBuilderImpl
>
> Add a Jira if you'd like to see them mapped.

I added HHH-9411 for mapping the transaction factory classes.

Thanks,
Scott

>
>

From steve at hibernate.org  Mon Nov  2 14:11:40 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 02 Nov 2015 19:11:40 +0000
Subject: [hibernate-dev] SQM : Criteria translation design
In-Reply-To: <CADGJaX9OzdfCY=PF=OA0BU4MncJpqLaP2w=OpB1w2gdMPNe8GA@mail.gmail.com>
References: <CAFdSV9ubGLZRYEVSp5cUydqp1cDVEftFeDe7T9zYDgdM5OUSKg@mail.gmail.com>
	<CADGJaX9OzdfCY=PF=OA0BU4MncJpqLaP2w=OpB1w2gdMPNe8GA@mail.gmail.com>
Message-ID: <CAFdSV9s2RCAK5B8QaavkpB9NcjYEPus+3AXNc4Si9sKe9qy+Ew@mail.gmail.com>

I mean that the JPA contracts in general do not expose enough information
to interpret them.  Take the one example I mentioned in my email...
Predicate.  The JPA contracts do not give enough information to know if a
Predicate is a BETWEEN, or a LIKE or a IS_NULL or ... they are all just
Predicate.  So SQM needs something else.

So I think we need to qualify the term visitor.  The visitor pattern is a
very specific thing.  Visitation, as in the pattern, is defined in terms of
the "visitable" (the Criteria nodes, here) and the "visitor" (the thing
that does walking and is passed into the visitable).  So that was the
"first approach".  We'd have CriteriaVisitor (the visitor).  Each
Predicate, Expression, etc would be a "visitable".  We'd have a
PredicateImplementor that accepts the CriteriaVisitor and returns an SQM
Predicate.  We'd have an ExpressionImplementor that accepts the CriteriaVisitor
and returns the SQM Expression.  Typical vistor pattern.

What you are describing is just a walker.  And yes, that is one of the
options I laid out: the "second approach".  So here we'd classify each
Predicate, Expression, etc possibility as a specific SQM "criteria
extension" type.  So rather than just a "generic" PredicateImplementor with
an accept(CriteriaVisitor) method we'd classify all of the understood
predicate types with an SQM interface that ORM would need to use in its
criteria impls.  So, e.g. in SQM we'd have a
org.hibernate.query.parser.criteria.BetweenPredicateImplementor
that exposes the information we need to interpret that in SQM
(testExpression, lowerBound, upperBound, isNegated).  In
ORM, org.hibernate.jpa.criteria.predicate.BetweenPredicate would need to
implement that contract.  And so on.




On Mon, Nov 2, 2015 at 12:44 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> What exactly DYM by "The criteria nodes would be expected to implement
> an SQM extension accepting a visitor"?
>
> My first thought would have been a combination of the two approaches:
> Let the criteria objects expose all the required data, make them
> traversable by means of a visitor and have an SQM-specific visitor
> implementation which converts each criteria object into its SQM
> counter-part.
>
> --Gunnar
>
>
>
>
> 2015-10-30 12:41 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > I started work on SQM-24 which covers translation of criteria queries
> into
> > SQM.
> >
> > The difficulty with this is that the JPA contracts alone do not give
> enough
> > information to really be able to understand the semantics of the query;
> > there is just not enough information exposed.  I can get into specific
> > examples if that helps, but for now lets take that as a given...
> >
> > So then how do we go about translating a criteria into an SQM?  There are
> > going to be 2 main approaches.  Each requires some level of extension to
> > the standard contracts:
> >
> > The first approach is to use visitation.  The criteria nodes would be
> > expected to implement an SQM extension accepting a visitor and do the
> right
> > thing.  The gains here are the normal gains with the visitor pattern.
> The
> > downside is that this makes SQM highly dependent on the criteria impl
> doing
> > the right thing and makes the criteria impl sensitive to SQM (depending n
> > how we expose the visitation methods to a degree).
> >
> > The second approach would be to extended the standard criteria contracts
> to
> > more fully cover the semantic.  As one example, JPA defines just
> Predicate
> > (for the most part) without exposing the type of predicate.  Is it a LIKE
> > expression?  A BETWEEN?  A Comparison (=, !=, <, etc)?  We just don't
> know
> > from the standard contracts.  So we'd have to develop a full semantic
> > extension model here.  `interface LikePredicate extends Predicate`,
> > `BetweenPredicate extends Predicate`, etc.
> >
> > I lean towards the visitor approach given these choices.  Anyone else
> have
> > opinions?  Other options?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Nov  2 15:32:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 02 Nov 2015 20:32:52 +0000
Subject: [hibernate-dev] Fwd: Link to test case templates
In-Reply-To: <56371EC4.4010302@redhat.com>
References: <CADGJaX-d3DwegXEfFW7C=j0HaRuOqim2_hnqMvsV=HyA1N_Q2w@mail.gmail.com>
	<CAFdSV9vLB7XSTKQmLiTHkPUZ-4PFWPxTWFm=Kpn5B2_7zvfPXw@mail.gmail.com>
	<CAFdSV9uAh2N-Uz--5AJu_AW0ryJvwtQ-L1Fg3vzUPs=rhk9LAw@mail.gmail.com>
	<CAFdSV9tZacyzEOy83Fx-qnuy2JGcN18+9722kuXBKB_uQvwUgg@mail.gmail.com>
	<CADGJaX8ood3xEGGXZ7rS8-9qi45q55n6dEN_UVbgrhYaQp_4Uw@mail.gmail.com>
	<CAFdSV9vcnh1h88OG9Af47S4Mbutomww0EHdET-Vrhv12cxYTgw@mail.gmail.com>
	<CAFm4XO2gVJjiWnN3iZPJ-wcqLLC39jiE17dQLRU3LiEWmOztSQ@mail.gmail.com>
	<CAB63Y-drDoQ6DzXaGoH4oaHLGVYNgwAg3+RtgBgZACX0dX=X9w@mail.gmail.com>
	<CAFm4XO2JeeOD83pxbFbWkaso9+8S+AAy3igZ+W2zQOXsD7PXRg@mail.gmail.com>
	<56371EC4.4010302@redhat.com>
Message-ID: <CAFdSV9sMAegCCepdyh5tF=ZHdWVG5vn20M=tewyVzq4uOaOisw@mail.gmail.com>

The other option is to plug in
a org.hibernate.resource.jdbc.spi.StatementInspector.  You can do this on
the SessionFactory or Session level

On Mon, Nov 2, 2015 at 2:29 AM Radim Vansa <rvansa at redhat.com> wrote:

> You can mock the JDBC driver and test the emitted SQL from there; I am
> using mockrunner-jdbc [1] to do that. Since Hibernate needs to chat with
> DB a bit before doing the logic of that test, it's convenient to switch
> between real DB and the mocks at runtime. I've created a little tool [2]
> to do that - actually this disables recording of executed statements
> (since I am using this for performance testing rather than behaviour
> verification), but it's trivial to revert that ([3] - just use default
> ctor).
>
> Radim
>
> [1] https://github.com/mockrunner/mockrunner
> [2] https://github.com/rvansa/perfmock
> [3]
>
> https://github.com/rvansa/perfmock/blob/master/src/main/java/org/perfmock/PerfMockDriver.java#L179
>
> On 11/01/2015 11:01 PM, Sanne Grinovero wrote:
> > Adding back the list.
> >
> > To answer Martijn: personally I don't know the answer, but it sounds
> > like an excellent idea to implement that, if it's not possible
> > already.
> > Keep in mind that Hibernate might need to generate multiple SQL
> > statements per operation.
> >
> > Sanne
> >
> > ---------- Forwarded message ----------
> > From: Martijn Dashorst <martijn.dashorst at gmail.com>
> > Date: 31 October 2015 at 05:43
> > Subject: Re: [hibernate-dev] Link to test case templates
> > To: Sanne Grinovero <sanne at hibernate.org>
> >
> >
> > Good to see making test cases easier.
> >
> > Is it possible to test the actual SQL that is emitted by Hibernate
> > from a test case? I've looked at the github repo but didn't find a
> > matching method.
> >
> > Martijn
> >
> > On Friday, 30 October 2015, Sanne Grinovero <sanne at hibernate.org> wrote:
> >> We should add a page on hibernate.org describing the idea, and from
> >> there point to github.
> >>
> >> On 30 October 2015 at 07:49, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>> But that was not the purpose of the content at the old link.   Yes the
> >>> templates are nice  but that's not the whole picture of what makes a
> good
> >>> test case
> >>>
> >>> On Fri, Oct 30, 2015, 9:41 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>>
> >>>> 2015-10-30 15:16 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >>>>> It looks like that may just be an invalid URL.
> >>>> Yes, the link should point to
> >>>> https://github.com/hibernate/hibernate-test-case-templates instead.
> >>>> There are the test case templates and also a description of their
> >>>> usage.
> >>>>
> >>>>
> >>>>>   It looks like the content
> >>>>> that was at that URL was not migrated over in the website migration.
> >>>>>
> >>>>> This ties in with an uneasiness that has been growing on me tbh...
> We
> >>>> have
> >>>>> too many places users have to look for  potential information.  The
> >>>> website,
> >>>>> the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds.  It's
> >>>> hard to
> >>>>> keep straight :)
> >>>>>
> >>>>> Ideally a lot of this would live under hibernate.org website
> umbrella.
> >>>> But
> >>>>> to be frank, I find developing content for hibernate.org and
> >>>> in.relation.to
> >>>>> to be cumbersome.  We can get into "why" in a separate subject.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole <steve at hibernate.org>
> >>>> wrote:
> >>>>>> But for some reason it directs me back to JIra.  Even just clicking
> that
> >>>>>> link in the email does.  I wonder if someone set up a bad redirect
> on
> >>>> the
> >>>>>> hibernate.org website for that?
> >>>>>>
> >>>>>> On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole <steve at hibernate.org
> >
> >>>>>> wrote:
> >>>>>>> The link target is
> >>>> http://www.hibernate.org/issuetracker.html#testcases.
> >>>>>>> That's not the "JIRA main page".
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling <
> gunnar at hibernate.org>
> >>>>>>> wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> When creating a new HHH issue, there is a link "...should
> generally be
> >>>>>>>> accompanied by a test case" but it directs to the JIRA main page.
> >>>>>>>>
> >>>>>>>> Can we let it point to the test case template repo instead:
> >>>>>>>>
> >>>>>>>>      https://github.com/hibernate/hibernate-test-case-templates
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> --Gunnar
> >>>>>>>> _______________________________________________
> >>>>>>>> hibernate-dev mailing list
> >>>>>>>> hibernate-dev at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Tue Nov  3 11:10:07 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 3 Nov 2015 16:10:07 +0000
Subject: [hibernate-dev] Triage meeting
Message-ID: <CAL00eSSFHrQajK3tkG_5MdEcM=5ZMXo2d_exNUtcwAmKT4On9g@mail.gmail.com>

sorry but I cannot attend the today triage meeting

From martijn.dashorst at gmail.com  Tue Nov  3 11:13:56 2015
From: martijn.dashorst at gmail.com (Martijn Dashorst)
Date: Tue, 3 Nov 2015 17:13:56 +0100
Subject: [hibernate-dev] Fwd: Link to test case templates
In-Reply-To: <CAFdSV9sMAegCCepdyh5tF=ZHdWVG5vn20M=tewyVzq4uOaOisw@mail.gmail.com>
References: <CADGJaX-d3DwegXEfFW7C=j0HaRuOqim2_hnqMvsV=HyA1N_Q2w@mail.gmail.com>
	<CAFdSV9vLB7XSTKQmLiTHkPUZ-4PFWPxTWFm=Kpn5B2_7zvfPXw@mail.gmail.com>
	<CAFdSV9uAh2N-Uz--5AJu_AW0ryJvwtQ-L1Fg3vzUPs=rhk9LAw@mail.gmail.com>
	<CAFdSV9tZacyzEOy83Fx-qnuy2JGcN18+9722kuXBKB_uQvwUgg@mail.gmail.com>
	<CADGJaX8ood3xEGGXZ7rS8-9qi45q55n6dEN_UVbgrhYaQp_4Uw@mail.gmail.com>
	<CAFdSV9vcnh1h88OG9Af47S4Mbutomww0EHdET-Vrhv12cxYTgw@mail.gmail.com>
	<CAFm4XO2gVJjiWnN3iZPJ-wcqLLC39jiE17dQLRU3LiEWmOztSQ@mail.gmail.com>
	<CAB63Y-drDoQ6DzXaGoH4oaHLGVYNgwAg3+RtgBgZACX0dX=X9w@mail.gmail.com>
	<CAFm4XO2JeeOD83pxbFbWkaso9+8S+AAy3igZ+W2zQOXsD7PXRg@mail.gmail.com>
	<56371EC4.4010302@redhat.com>
	<CAFdSV9sMAegCCepdyh5tF=ZHdWVG5vn20M=tewyVzq4uOaOisw@mail.gmail.com>
Message-ID: <CAB63Y-cd_5fWw8SfAJR3DtL5qd-Uf5TCBpMLoTbRH+xv7mPvjA@mail.gmail.com>

Thanks for the suggestions. I'll look into it for my test case.

Martijn

On Mon, Nov 2, 2015 at 9:32 PM, Steve Ebersole <steve at hibernate.org> wrote:
> The other option is to plug in
> a org.hibernate.resource.jdbc.spi.StatementInspector.  You can do this on
> the SessionFactory or Session level
>
> On Mon, Nov 2, 2015 at 2:29 AM Radim Vansa <rvansa at redhat.com> wrote:
>
>> You can mock the JDBC driver and test the emitted SQL from there; I am
>> using mockrunner-jdbc [1] to do that. Since Hibernate needs to chat with
>> DB a bit before doing the logic of that test, it's convenient to switch
>> between real DB and the mocks at runtime. I've created a little tool [2]
>> to do that - actually this disables recording of executed statements
>> (since I am using this for performance testing rather than behaviour
>> verification), but it's trivial to revert that ([3] - just use default
>> ctor).
>>
>> Radim
>>
>> [1] https://github.com/mockrunner/mockrunner
>> [2] https://github.com/rvansa/perfmock
>> [3]
>>
>> https://github.com/rvansa/perfmock/blob/master/src/main/java/org/perfmock/PerfMockDriver.java#L179
>>
>> On 11/01/2015 11:01 PM, Sanne Grinovero wrote:
>> > Adding back the list.
>> >
>> > To answer Martijn: personally I don't know the answer, but it sounds
>> > like an excellent idea to implement that, if it's not possible
>> > already.
>> > Keep in mind that Hibernate might need to generate multiple SQL
>> > statements per operation.
>> >
>> > Sanne
>> >
>> > ---------- Forwarded message ----------
>> > From: Martijn Dashorst <martijn.dashorst at gmail.com>
>> > Date: 31 October 2015 at 05:43
>> > Subject: Re: [hibernate-dev] Link to test case templates
>> > To: Sanne Grinovero <sanne at hibernate.org>
>> >
>> >
>> > Good to see making test cases easier.
>> >
>> > Is it possible to test the actual SQL that is emitted by Hibernate
>> > from a test case? I've looked at the github repo but didn't find a
>> > matching method.
>> >
>> > Martijn
>> >
>> > On Friday, 30 October 2015, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >> We should add a page on hibernate.org describing the idea, and from
>> >> there point to github.
>> >>
>> >> On 30 October 2015 at 07:49, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>> But that was not the purpose of the content at the old link.   Yes the
>> >>> templates are nice  but that's not the whole picture of what makes a
>> good
>> >>> test case
>> >>>
>> >>> On Fri, Oct 30, 2015, 9:41 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >>>
>> >>>> 2015-10-30 15:16 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >>>>> It looks like that may just be an invalid URL.
>> >>>> Yes, the link should point to
>> >>>> https://github.com/hibernate/hibernate-test-case-templates instead.
>> >>>> There are the test case templates and also a description of their
>> >>>> usage.
>> >>>>
>> >>>>
>> >>>>>   It looks like the content
>> >>>>> that was at that URL was not migrated over in the website migration.
>> >>>>>
>> >>>>> This ties in with an uneasiness that has been growing on me tbh...
>> We
>> >>>> have
>> >>>>> too many places users have to look for  potential information.  The
>> >>>> website,
>> >>>>> the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds.  It's
>> >>>> hard to
>> >>>>> keep straight :)
>> >>>>>
>> >>>>> Ideally a lot of this would live under hibernate.org website
>> umbrella.
>> >>>> But
>> >>>>> to be frank, I find developing content for hibernate.org and
>> >>>> in.relation.to
>> >>>>> to be cumbersome.  We can get into "why" in a separate subject.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole <steve at hibernate.org>
>> >>>> wrote:
>> >>>>>> But for some reason it directs me back to JIra.  Even just clicking
>> that
>> >>>>>> link in the email does.  I wonder if someone set up a bad redirect
>> on
>> >>>> the
>> >>>>>> hibernate.org website for that?
>> >>>>>>
>> >>>>>> On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole <steve at hibernate.org
>> >
>> >>>>>> wrote:
>> >>>>>>> The link target is
>> >>>> http://www.hibernate.org/issuetracker.html#testcases.
>> >>>>>>> That's not the "JIRA main page".
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling <
>> gunnar at hibernate.org>
>> >>>>>>> wrote:
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>> When creating a new HHH issue, there is a link "...should
>> generally be
>> >>>>>>>> accompanied by a test case" but it directs to the JIRA main page.
>> >>>>>>>>
>> >>>>>>>> Can we let it point to the test case template repo instead:
>> >>>>>>>>
>> >>>>>>>>      https://github.com/hibernate/hibernate-test-case-templates
>> >>>>>>>>
>> >>>>>>>> Thanks,
>> >>>>>>>>
>> >>>>>>>> --Gunnar
>> >>>>>>>> _______________________________________________
>> >>>>>>>> hibernate-dev mailing list
>> >>>>>>>> hibernate-dev at lists.jboss.org
>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> > --
>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

From steve at hibernate.org  Tue Nov  3 12:35:25 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 03 Nov 2015 17:35:25 +0000
Subject: [hibernate-dev] Upcoming 5.0 releases
Message-ID: <CAFdSV9vGf6g7yU70B7y=kLzk2BGJ1xSHNxNC1eWw4prO=KO1CQ@mail.gmail.com>

Keeping up with the 4 week timebox for 5.0 bugfix releases unfortunately
puts them on bad days with the upcoming holidays.

5.0.4 would hit Nov 25th which is the day before Thanksgiving here in the US
5.0.5 would hit Dec 23rd, 2 days before Christmas

So I propose pushing 5.0.4 forward or back one week (Nov 18 or Dec 2nd),
and having 5.0.5 4 weeks after that.  Votes?  Preferences?  Silence means I
pick...

From dreborier at gmail.com  Wed Nov  4 01:10:59 2015
From: dreborier at gmail.com (andrea boriero)
Date: Wed, 4 Nov 2015 06:10:59 +0000
Subject: [hibernate-dev] Upcoming 5.0 releases
In-Reply-To: <CAFdSV9vGf6g7yU70B7y=kLzk2BGJ1xSHNxNC1eWw4prO=KO1CQ@mail.gmail.com>
References: <CAFdSV9vGf6g7yU70B7y=kLzk2BGJ1xSHNxNC1eWw4prO=KO1CQ@mail.gmail.com>
Message-ID: <CAL00eSRfwPKRViMaxe7od+y-H4jXr2A7ARoBNMaxpy4HuHGWGA@mail.gmail.com>

I vote for November 18
On 3 Nov 2015 18:36, "Steve Ebersole" <steve at hibernate.org> wrote:

> Keeping up with the 4 week timebox for 5.0 bugfix releases unfortunately
> puts them on bad days with the upcoming holidays.
>
> 5.0.4 would hit Nov 25th which is the day before Thanksgiving here in the
> US
> 5.0.5 would hit Dec 23rd, 2 days before Christmas
>
> So I propose pushing 5.0.4 forward or back one week (Nov 18 or Dec 2nd),
> and having 5.0.5 4 weeks after that.  Votes?  Preferences?  Silence means I
> pick...
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Wed Nov  4 05:27:17 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 4 Nov 2015 11:27:17 +0100
Subject: [hibernate-dev] Link to test case templates
In-Reply-To: <CAFdSV9tZacyzEOy83Fx-qnuy2JGcN18+9722kuXBKB_uQvwUgg@mail.gmail.com>
References: <CADGJaX-d3DwegXEfFW7C=j0HaRuOqim2_hnqMvsV=HyA1N_Q2w@mail.gmail.com>
	<CAFdSV9vLB7XSTKQmLiTHkPUZ-4PFWPxTWFm=Kpn5B2_7zvfPXw@mail.gmail.com>
	<CAFdSV9uAh2N-Uz--5AJu_AW0ryJvwtQ-L1Fg3vzUPs=rhk9LAw@mail.gmail.com>
	<CAFdSV9tZacyzEOy83Fx-qnuy2JGcN18+9722kuXBKB_uQvwUgg@mail.gmail.com>
Message-ID: <20151104102717.GB75457@Nineveh.local>

Hi,

> This ties in with an uneasiness that has been growing on me tbh...  We have
> too many places users have to look for  potential information.  The
> website, the JBoss wiki, the GitHub wiki, README.mds, CONTRIBUTING.mds.
> It's hard to keep straight :)

That has always been my concern.

> Ideally a lot of this would live under hibernate.org website umbrella.

My understanding has always been that this was the plan.

> But to be frank, I find developing content for hibernate.org and in.relation.to
> to be cumbersome.  We can get into "why" in a separate subject.

Sure.

--Hardy


From sanne at hibernate.org  Wed Nov  4 05:28:25 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 04 Nov 2015 10:28:25 +0000
Subject: [hibernate-dev] Upcoming 5.0 releases
In-Reply-To: <CAL00eSRfwPKRViMaxe7od+y-H4jXr2A7ARoBNMaxpy4HuHGWGA@mail.gmail.com>
References: <CAFdSV9vGf6g7yU70B7y=kLzk2BGJ1xSHNxNC1eWw4prO=KO1CQ@mail.gmail.com>
	<CAL00eSRfwPKRViMaxe7od+y-H4jXr2A7ARoBNMaxpy4HuHGWGA@mail.gmail.com>
Message-ID: <CAFm4XO3ba=Vn+hRha5XKZGo6S1ED3Cd8NwjQdjovqdFeFAEe6A@mail.gmail.com>

+1
I generally prefer shorter cycles

On Wed, 4 Nov 2015 06:11 andrea boriero <dreborier at gmail.com> wrote:

> I vote for November 18
> On 3 Nov 2015 18:36, "Steve Ebersole" <steve at hibernate.org> wrote:
>
> > Keeping up with the 4 week timebox for 5.0 bugfix releases unfortunately
> > puts them on bad days with the upcoming holidays.
> >
> > 5.0.4 would hit Nov 25th which is the day before Thanksgiving here in the
> > US
> > 5.0.5 would hit Dec 23rd, 2 days before Christmas
> >
> > So I propose pushing 5.0.4 forward or back one week (Nov 18 or Dec 2nd),
> > and having 5.0.5 4 weeks after that.  Votes?  Preferences?  Silence
> means I
> > pick...
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov  4 11:01:25 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 04 Nov 2015 16:01:25 +0000
Subject: [hibernate-dev] Upcoming 5.0 releases
In-Reply-To: <CAFm4XO3ba=Vn+hRha5XKZGo6S1ED3Cd8NwjQdjovqdFeFAEe6A@mail.gmail.com>
References: <CAFdSV9vGf6g7yU70B7y=kLzk2BGJ1xSHNxNC1eWw4prO=KO1CQ@mail.gmail.com>
	<CAL00eSRfwPKRViMaxe7od+y-H4jXr2A7ARoBNMaxpy4HuHGWGA@mail.gmail.com>
	<CAFm4XO3ba=Vn+hRha5XKZGo6S1ED3Cd8NwjQdjovqdFeFAEe6A@mail.gmail.com>
Message-ID: <CAFdSV9t6NK0i2-330Y5zwwc0z4p8zJn6uQy-HLqfH-NvxwuV2g@mail.gmail.com>

That would still put 5.0.5 in the middle of winter break.

Probably we should schedule that for a 3 week timebox too.  So:

   - 5.0.4 -> November 18th
   - 5.0.5 -> December 9th
   - 5.0.6 -> January 6th (back to normal 4 week timebox)


I generally prefer shorter cycles
>
I agree, to a point.  But I need to balance that with actual
improvement/feature development as well.  4 weeks has been a great sweet
spot for me.

From mih_vlad at yahoo.com  Wed Nov  4 11:18:09 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Wed, 4 Nov 2015 16:18:09 +0000 (UTC)
Subject: [hibernate-dev] Feature proposal: Add Session-level batch size
	configuration
References: <291509020.1757887.1446653889493.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <291509020.1757887.1446653889493.JavaMail.yahoo@mail.yahoo.com>

Hi,
I was browsing the Hibernate code and realized that the Batch/Non-Batch decision is taken based on the value of the "hibernate.jdbc.batch_size" SessionFactory configuration.Wouldn't be more flexible if we allow the Session to have a setBathSize(int size) method to override the batching configuration on a Session-basis.This way we can fine-tune the batch size for each particular DAO method.
Any thoughts?

Vlad

From sanne at hibernate.org  Wed Nov  4 11:39:11 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 4 Nov 2015 16:39:11 +0000
Subject: [hibernate-dev] Upcoming 5.0 releases
In-Reply-To: <CAFdSV9t6NK0i2-330Y5zwwc0z4p8zJn6uQy-HLqfH-NvxwuV2g@mail.gmail.com>
References: <CAFdSV9vGf6g7yU70B7y=kLzk2BGJ1xSHNxNC1eWw4prO=KO1CQ@mail.gmail.com>
	<CAL00eSRfwPKRViMaxe7od+y-H4jXr2A7ARoBNMaxpy4HuHGWGA@mail.gmail.com>
	<CAFm4XO3ba=Vn+hRha5XKZGo6S1ED3Cd8NwjQdjovqdFeFAEe6A@mail.gmail.com>
	<CAFdSV9t6NK0i2-330Y5zwwc0z4p8zJn6uQy-HLqfH-NvxwuV2g@mail.gmail.com>
Message-ID: <CAFm4XO1VkFeBVqD9URYcdutBspWii==AgY0XwstPX=Rpo5Srbg@mail.gmail.com>

On 4 November 2015 at 16:01, Steve Ebersole <steve at hibernate.org> wrote:
> That would still put 5.0.5 in the middle of winter break.
>
> Probably we should schedule that for a 3 week timebox too.  So:
>
> 5.0.4 -> November 18th
> 5.0.5 -> December 9th
> 5.0.6 -> January 6th (back to normal 4 week timebox)
>
>
>> I generally prefer shorter cycles
>
> I agree, to a point.  But I need to balance that with actual
> improvement/feature development as well.  4 weeks has been a great sweet
> spot for me.

Sure. Pick the balance which works best for you, but when you'll ask
to vote for dates I'll vote for the shorter cycle ;)

From mihalcea.vlad at gmail.com  Wed Nov  4 13:04:56 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 4 Nov 2015 20:04:56 +0200
Subject: [hibernate-dev] Feature proposal: Add Session-level batch size
	configuration
Message-ID: <CA+gWKMBi7jj6kc-eRLV1Q7dgfZ4wgn1P1YPtZ5Sg0usnLHU+yA@mail.gmail.com>

Hi,

I was browsing the Hibernate code and realized that the Batch/Non-Batch
decision is taken based on the value of the "hibernate.jdbc.batch_size"
SessionFactory configuration.
Wouldn't be more flexible if we allow the Session to have a setBathSize(int
size) method to override the batching configuration on a Session-basis.
This way we can fine-tune the batch size for each particular DAO method.

Any thoughts?

Vlad

From steve at hibernate.org  Wed Nov  4 13:56:38 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 04 Nov 2015 18:56:38 +0000
Subject: [hibernate-dev] Feature proposal: Add Session-level batch size
	configuration
In-Reply-To: <CA+gWKMBi7jj6kc-eRLV1Q7dgfZ4wgn1P1YPtZ5Sg0usnLHU+yA@mail.gmail.com>
References: <CA+gWKMBi7jj6kc-eRLV1Q7dgfZ4wgn1P1YPtZ5Sg0usnLHU+yA@mail.gmail.com>
Message-ID: <CAFdSV9sOi1sicHMrfNrLm2SHLL2vmRUmCsLKx5LOfGG4x+N_mQ@mail.gmail.com>

At the moment Hibernate builds all of the Loaders that derive from
batchsize when the SessionFactory is built.  So practically speaking you'd
have to account for that change in design.

But in general the idea would be ok.


On Wed, Nov 4, 2015 at 12:05 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I was browsing the Hibernate code and realized that the Batch/Non-Batch
> decision is taken based on the value of the "hibernate.jdbc.batch_size"
> SessionFactory configuration.
> Wouldn't be more flexible if we allow the Session to have a setBathSize(int
> size) method to override the batching configuration on a Session-basis.
> This way we can fine-tune the batch size for each particular DAO method.
>
> Any thoughts?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov  4 14:36:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 04 Nov 2015 19:36:00 +0000
Subject: [hibernate-dev] Another HCANN change
Message-ID: <CAFdSV9vDD-Qku3Db6oRXMnHWe0FHY=GfSe=XW_+5ojODNp+2Hg@mail.gmail.com>

Reference https://hibernate.atlassian.net/browse/HHH-10242

I need to make another change in HCANN and pull that new version into ORM.

From gunnar at hibernate.org  Thu Nov  5 02:46:45 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 5 Nov 2015 08:46:45 +0100
Subject: [hibernate-dev] Branching in HSEARCH
Message-ID: <CADGJaX_SddAQ0-s30kxkesx+ZHH=3AnU=QoRUwhvUp6+Dg+RqQ@mail.gmail.com>

Sanne, all,

Could we please drop the 5.5 branch in the upstream repo. It matches
exactly master (apart from the POM versions), so there is really no
good reason to have it at this point IMHO.

Let's do branches when they actually become necessary. In this case,
work meant only for 5.6 but not for 5.5.1 is about to be merge. Or
just let's do the 5.5.1 release at this point.

The current set-up is confusing, unnecessarily complex and creates
more work than needed (merging PRs to two branches, manage two issue
fix versions etc.).

Thanks,

--Gunnar

From hardy at hibernate.org  Thu Nov  5 03:46:47 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 5 Nov 2015 09:46:47 +0100
Subject: [hibernate-dev] Branching in HSEARCH
In-Reply-To: <CADGJaX_SddAQ0-s30kxkesx+ZHH=3AnU=QoRUwhvUp6+Dg+RqQ@mail.gmail.com>
References: <CADGJaX_SddAQ0-s30kxkesx+ZHH=3AnU=QoRUwhvUp6+Dg+RqQ@mail.gmail.com>
Message-ID: <20151105084647.GA7881@Nineveh.local>

On Thu, Nov 05, 2015 at 08:46:45AM +0100, Gunnar Morling wrote:
> Sanne, all,
> 
> Could we please drop the 5.5 branch in the upstream repo. It matches
> exactly master (apart from the POM versions), so there is really no
> good reason to have it at this point IMHO.

+1

--Hardy

From sanne at hibernate.org  Thu Nov  5 09:11:45 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 5 Nov 2015 14:11:45 +0000
Subject: [hibernate-dev] Branching in HSEARCH
In-Reply-To: <20151105084647.GA7881@Nineveh.local>
References: <CADGJaX_SddAQ0-s30kxkesx+ZHH=3AnU=QoRUwhvUp6+Dg+RqQ@mail.gmail.com>
	<20151105084647.GA7881@Nineveh.local>
Message-ID: <CAFm4XO3cwY4f8fTryUo4j3Naiod_gWQXa0SqX2TJTuAG9iJ2sg@mail.gmail.com>

Hi,
I realize it was a mistake to create it that soon, but it's too late
now: we have contributions being developed from that branch.

Keep in mind 5.5 will definitely need long term maintenance as it's
the version picked for integration in WildFly 10 and all depending
platforms, so it's not that there's any chance to avoid this branch as
might sometimes have happened in the past.
The good news: as long as they don't really diverge, applying a PR to
both is absolutely trivial.

One thing I don't buy: why is it confusing? This is exactly the same
process we've followed since many years, since ever we moved to Git.
Just normally we'll create it a bit later, as needed.. no big deal,
other than normally you might have to reopen closed JIRAs to fix the
versions. This might even sound better in that regard, and "as needed"
doesn't apply as we'll need this for sure.

Thanks,
Sanne

On 5 November 2015 at 08:46, Hardy Ferentschik <hardy at hibernate.org> wrote:
> On Thu, Nov 05, 2015 at 08:46:45AM +0100, Gunnar Morling wrote:
>> Sanne, all,
>>
>> Could we please drop the 5.5 branch in the upstream repo. It matches
>> exactly master (apart from the POM versions), so there is really no
>> good reason to have it at this point IMHO.
>
> +1
>
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Thu Nov  5 09:23:36 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 5 Nov 2015 15:23:36 +0100
Subject: [hibernate-dev] Branching in HSEARCH
In-Reply-To: <CAFm4XO3cwY4f8fTryUo4j3Naiod_gWQXa0SqX2TJTuAG9iJ2sg@mail.gmail.com>
References: <CADGJaX_SddAQ0-s30kxkesx+ZHH=3AnU=QoRUwhvUp6+Dg+RqQ@mail.gmail.com>
	<20151105084647.GA7881@Nineveh.local>
	<CAFm4XO3cwY4f8fTryUo4j3Naiod_gWQXa0SqX2TJTuAG9iJ2sg@mail.gmail.com>
Message-ID: <CADGJaX_A_-q3ytr+0EPzvODxx7YGc2hT5+4QmjcGZWC0sid1uw@mail.gmail.com>

2015-11-05 15:11 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> Hi,
> I realize it was a mistake to create it that soon, but it's too late
> now: we have contributions being developed from that branch.

Who, where? I don't see any branch off 5.5 on GH. As said the branches
are identical, so even if someone has developed off 5.5, it's trivial
to rebase.

>
> Keep in mind 5.5 will definitely need long term maintenance as it's
> the version picked for integration in WildFly 10 and all depending
> platforms, so it's not that there's any chance to avoid this branch as
> might sometimes have happened in the past.
> The good news: as long as they don't really diverge, applying a PR to
> both is absolutely trivial.

Only it creates useless work right now. Just see this discussion for instance ;)

>
> One thing I don't buy: why is it confusing?

Personally I find having to maintain two identical branches confusing.
In the sense "WTH are we doing this".

> This is exactly the same
> process we've followed since many years, since ever we moved to Git.
> Just normally we'll create it a bit later, as needed.. no big deal,
> other than normally you might have to reopen closed JIRAs to fix the
> versions. This might even sound better in that regard, and "as needed"
> doesn't apply as we'll need this for sure.

Sure, I understand it will be needed at *some point*, but it is not now.

>
> Thanks,
> Sanne
>
> On 5 November 2015 at 08:46, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> On Thu, Nov 05, 2015 at 08:46:45AM +0100, Gunnar Morling wrote:
>>> Sanne, all,
>>>
>>> Could we please drop the 5.5 branch in the upstream repo. It matches
>>> exactly master (apart from the POM versions), so there is really no
>>> good reason to have it at this point IMHO.
>>
>> +1
>>
>> --Hardy
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Nov  5 09:31:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 Nov 2015 14:31:52 +0000
Subject: [hibernate-dev] Branching in HSEARCH
In-Reply-To: <CADGJaX_A_-q3ytr+0EPzvODxx7YGc2hT5+4QmjcGZWC0sid1uw@mail.gmail.com>
References: <CADGJaX_SddAQ0-s30kxkesx+ZHH=3AnU=QoRUwhvUp6+Dg+RqQ@mail.gmail.com>
	<20151105084647.GA7881@Nineveh.local>
	<CAFm4XO3cwY4f8fTryUo4j3Naiod_gWQXa0SqX2TJTuAG9iJ2sg@mail.gmail.com>
	<CADGJaX_A_-q3ytr+0EPzvODxx7YGc2hT5+4QmjcGZWC0sid1uw@mail.gmail.com>
Message-ID: <CAFdSV9u2snFbPU0=Ondz2JiG9uyhynRXJNNcHa+=A237DPX3DQ@mail.gmail.com>

Personally I see this as a pragmatic versus correct discussion.   To me,
once you release a final you should create it's branch.   The pragmatism
comes from the fact that following this "correct" approach causes a lot of
"extra work" (extra until there is an actual deviation).

I regularly do this too early in ORM and tend to regret it.   I'd lean
towards being pragmatic personally,  but of course I don't have a horse in
this race..

On Thu, Nov 5, 2015, 8:24 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> 2015-11-05 15:11 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> > Hi,
> > I realize it was a mistake to create it that soon, but it's too late
> > now: we have contributions being developed from that branch.
>
> Who, where? I don't see any branch off 5.5 on GH. As said the branches
> are identical, so even if someone has developed off 5.5, it's trivial
> to rebase.
>
> >
> > Keep in mind 5.5 will definitely need long term maintenance as it's
> > the version picked for integration in WildFly 10 and all depending
> > platforms, so it's not that there's any chance to avoid this branch as
> > might sometimes have happened in the past.
> > The good news: as long as they don't really diverge, applying a PR to
> > both is absolutely trivial.
>
> Only it creates useless work right now. Just see this discussion for
> instance ;)
>
> >
> > One thing I don't buy: why is it confusing?
>
> Personally I find having to maintain two identical branches confusing.
> In the sense "WTH are we doing this".
>
> > This is exactly the same
> > process we've followed since many years, since ever we moved to Git.
> > Just normally we'll create it a bit later, as needed.. no big deal,
> > other than normally you might have to reopen closed JIRAs to fix the
> > versions. This might even sound better in that regard, and "as needed"
> > doesn't apply as we'll need this for sure.
>
> Sure, I understand it will be needed at *some point*, but it is not now.
>
> >
> > Thanks,
> > Sanne
> >
> > On 5 November 2015 at 08:46, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> >> On Thu, Nov 05, 2015 at 08:46:45AM +0100, Gunnar Morling wrote:
> >>> Sanne, all,
> >>>
> >>> Could we please drop the 5.5 branch in the upstream repo. It matches
> >>> exactly master (apart from the POM versions), so there is really no
> >>> good reason to have it at this point IMHO.
> >>
> >> +1
> >>
> >> --Hardy
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Nov  5 09:57:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 Nov 2015 14:57:54 +0000
Subject: [hibernate-dev] Want to contribute to hibernate community .
 Want some initial easy bugs for fixing
In-Reply-To: <CAMnoDvzMn8ic8dcOHAUoFxSepL79RUniX_MsqJCx=w6THOxrfQ@mail.gmail.com>
References: <CAMnoDvxi+Kq10tX+oHtngCU8Fh+My8Rr3QoTdhFe6JM-3XhNPQ@mail.gmail.com>
	<CAFdSV9unSUb0GubGcNJDTzrCJgDy-+mgiavX=KnvG7Mh-PmFVg@mail.gmail.com>
	<CAMnoDvz0kSwtC-r0cjuN_Qr2uYj2hVtFo+qZWccmiqUuhJhgjw@mail.gmail.com>
	<CAFdSV9u8DqtaqYOQMAK8SvBA6T_w6LscRBUTz+WhfYYJRB1WuA@mail.gmail.com>
	<CAMnoDvwpgH1MnaQJYwfEXKvsv8nZKgPQcvyP2GDXVr4_4VrGwQ@mail.gmail.com>
	<CAMnoDvxc=QCKy-QmjLtqLfBWSA1tC1x5aOCCLBx=h3qxURLN_Q@mail.gmail.com>
	<CAFdSV9udNYE0TtTn0Kdpbpu_jLzHrJrihgRT+05wjP+9QTSW3A@mail.gmail.com>
	<CAMnoDvxwQzjf0zxH4N2wa7F3cuWDVEoKetJyXTg1ALYgyOn9GA@mail.gmail.com>
	<CAMnoDvzhPrwW9b81v1msuyOYRsE+GchH8Mvd7qFQVRSVUB17bg@mail.gmail.com>
	<CAMnoDvzMn8ic8dcOHAUoFxSepL79RUniX_MsqJCx=w6THOxrfQ@mail.gmail.com>
Message-ID: <CAFdSV9sLZE7i1DtA2OKeKzeyVEaCVQBXnSYx5oreHsfQ+skX9Q@mail.gmail.com>

I am not really sure what you are asking.

Are there particular bugs you are wanting to fix?  Are you looking to
submit bug reports?

On Thu, Nov 5, 2015 at 8:43 AM Abhimanyu Srivasatava <srabhimanyu at gmail.com>
wrote:

> Sir ,
>   do  I  need  to  build  a  dummy  project  to  apply   various
>  hibernate tools , validator  . I'm using  MySQL  as the  database  . I
> really  want  to  associate  and   contribute  towards  your  community.
>
> On Mon, Sep 28, 2015 at 10:44 AM, Abhimanyu Srivasatava <
> srabhimanyu at gmail.com> wrote:
>
>> Sir  I want to download your irc channel for jboss #hibernate-dev .
>> Please  send me the link  so that I start  hanging out  with you  on
>>  hibernate community dicussion . Post my query.
>>
>> On Mon, Sep 28, 2015 at 10:42 AM, Abhimanyu Srivasatava <
>> srabhimanyu at gmail.com> wrote:
>>
>>> Sir I wasn't able to focus becoz of my university exams , soon  I'll
>>> start fixing your bugs. Please  keep me throughout . Please help me in all
>>> the  possible ways . I want to contribute to your  community  to my full
>>> extent.  How to build source code for hibernate core. Please help me out.
>>>
>>> On Sat, Sep 19, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> https://github.com/hibernate/hibernate-orm/blob/master/CONTRIBUTING.md
>>>>
>>>> On Fri, Sep 18, 2015 at 1:51 PM Abhimanyu Srivasatava <
>>>> srabhimanyu at gmail.com> wrote:
>>>>
>>>>> please send me  link  of   hibernate github account
>>>>>
>>>>> On Mon, Sep 14, 2015 at 7:05 AM, Abhimanyu Srivasatava <
>>>>> srabhimanyu at gmail.com> wrote:
>>>>>
>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Steve Ebersole <steve at hibernate.org>
>>>>>> Date: Thu, Sep 3, 2015 at 5:04 PM
>>>>>> Subject: Re: [hibernate-dev] Want to contribute to hibernate
>>>>>> community . Want some initial easy bugs for fixing
>>>>>> To: Abhimanyu Srivasatava <srabhimanyu at gmail.com>
>>>>>>
>>>>>>
>>>>>> http://hibernate.org/community/
>>>>>>
>>>>>> "Contribute" section: "IRC development channel"
>>>>>>
>>>>>> On Thu, Sep 3, 2015 at 12:01 PM Abhimanyu Srivasatava <
>>>>>> srabhimanyu at gmail.com> wrote:
>>>>>>
>>>>>>> how can i hang with you on irc channel . Please tell me the procedure
>>>>>>>
>>>>>>> On Wed, Sep 2, 2015 at 9:28 AM, Steve Ebersole <steve at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi :)
>>>>>>>>
>>>>>>>> Here[1] is the list of all unassigned issues reported against 5.0.
>>>>>>>> That is a great place to start.  See if any of them pique your interest.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://hibernate.atlassian.net/browse/HHH-10056?jql=project%20%3D%20HHH%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(5.0.0.Beta1%2C%205.0.0.Beta2%2C%205.0.0.CR1%2C%205.0.0.CR2%2C%205.0.0.CR3%2C%205.0.0.CR4%2C%205.0.0.Final%2C%205.0.1%2C%205.0.2)%20AND%20assignee%20in%20(EMPTY)%20ORDER%20BY%20updated%20DESC
>>>>>>>>
>>>>>>>> On Wed, Sep 2, 2015 at 5:32 AM Abhimanyu Srivasatava <
>>>>>>>> srabhimanyu at gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> hibernate-dev mailing list
>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>

From sanne at hibernate.org  Thu Nov  5 10:02:39 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 5 Nov 2015 15:02:39 +0000
Subject: [hibernate-dev] Branching in HSEARCH
In-Reply-To: <CADGJaX_A_-q3ytr+0EPzvODxx7YGc2hT5+4QmjcGZWC0sid1uw@mail.gmail.com>
References: <CADGJaX_SddAQ0-s30kxkesx+ZHH=3AnU=QoRUwhvUp6+Dg+RqQ@mail.gmail.com>
	<20151105084647.GA7881@Nineveh.local>
	<CAFm4XO3cwY4f8fTryUo4j3Naiod_gWQXa0SqX2TJTuAG9iJ2sg@mail.gmail.com>
	<CADGJaX_A_-q3ytr+0EPzvODxx7YGc2hT5+4QmjcGZWC0sid1uw@mail.gmail.com>
Message-ID: <CAFm4XO07Owe2QRe1XUQkjvqpP=YMAh+pE2L_WYaMdPZTpAuXkw@mail.gmail.com>

On 5 November 2015 at 14:23, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2015-11-05 15:11 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> Hi,
>> I realize it was a mistake to create it that soon, but it's too late
>> now: we have contributions being developed from that branch.
>
> Who, where? I don't see any branch off 5.5 on GH. As said the branches
> are identical, so even if someone has developed off 5.5, it's trivial
> to rebase.

GH doesn't give you an overview of people's hard drives, and while
it's all trivial for us it's not trivial at all for people not using
Git on a day to day.

>> Keep in mind 5.5 will definitely need long term maintenance as it's
>> the version picked for integration in WildFly 10 and all depending
>> platforms, so it's not that there's any chance to avoid this branch as
>> might sometimes have happened in the past.
>> The good news: as long as they don't really diverge, applying a PR to
>> both is absolutely trivial.
>
> Only it creates useless work right now. Just see this discussion for instance ;)

Right. Just stop it ;)
I already admitted it was a mistake: you're right on that, but at this
point it's just cheaper to keep it, not to mention that we shouldn't
be deleting published branches from the reference repository.
As I said we'll need this branch soon enough, it's far less work to
merge a couple PRs on both branches than to re-base next week and go
fix all versions on JIRA issues and reconfigure Jenkins, etc..

Sanne

>> One thing I don't buy: why is it confusing?
>
> Personally I find having to maintain two identical branches confusing.
> In the sense "WTH are we doing this".
>
>> This is exactly the same
>> process we've followed since many years, since ever we moved to Git.
>> Just normally we'll create it a bit later, as needed.. no big deal,
>> other than normally you might have to reopen closed JIRAs to fix the
>> versions. This might even sound better in that regard, and "as needed"
>> doesn't apply as we'll need this for sure.
>
> Sure, I understand it will be needed at *some point*, but it is not now.
>
>>
>> Thanks,
>> Sanne
>>
>> On 5 November 2015 at 08:46, Hardy Ferentschik <hardy at hibernate.org> wrote:
>>> On Thu, Nov 05, 2015 at 08:46:45AM +0100, Gunnar Morling wrote:
>>>> Sanne, all,
>>>>
>>>> Could we please drop the 5.5 branch in the upstream repo. It matches
>>>> exactly master (apart from the POM versions), so there is really no
>>>> good reason to have it at this point IMHO.
>>>
>>> +1
>>>
>>> --Hardy
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Nov  5 18:05:17 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 05 Nov 2015 23:05:17 +0000
Subject: [hibernate-dev] Want to contribute to hibernate community .
 Want some initial easy bugs for fixing
In-Reply-To: <CAFdSV9sLZE7i1DtA2OKeKzeyVEaCVQBXnSYx5oreHsfQ+skX9Q@mail.gmail.com>
References: <CAMnoDvxi+Kq10tX+oHtngCU8Fh+My8Rr3QoTdhFe6JM-3XhNPQ@mail.gmail.com>
	<CAFdSV9unSUb0GubGcNJDTzrCJgDy-+mgiavX=KnvG7Mh-PmFVg@mail.gmail.com>
	<CAMnoDvz0kSwtC-r0cjuN_Qr2uYj2hVtFo+qZWccmiqUuhJhgjw@mail.gmail.com>
	<CAFdSV9u8DqtaqYOQMAK8SvBA6T_w6LscRBUTz+WhfYYJRB1WuA@mail.gmail.com>
	<CAMnoDvwpgH1MnaQJYwfEXKvsv8nZKgPQcvyP2GDXVr4_4VrGwQ@mail.gmail.com>
	<CAMnoDvxc=QCKy-QmjLtqLfBWSA1tC1x5aOCCLBx=h3qxURLN_Q@mail.gmail.com>
	<CAFdSV9udNYE0TtTn0Kdpbpu_jLzHrJrihgRT+05wjP+9QTSW3A@mail.gmail.com>
	<CAMnoDvxwQzjf0zxH4N2wa7F3cuWDVEoKetJyXTg1ALYgyOn9GA@mail.gmail.com>
	<CAMnoDvzhPrwW9b81v1msuyOYRsE+GchH8Mvd7qFQVRSVUB17bg@mail.gmail.com>
	<CAMnoDvzMn8ic8dcOHAUoFxSepL79RUniX_MsqJCx=w6THOxrfQ@mail.gmail.com>
	<CAFdSV9sLZE7i1DtA2OKeKzeyVEaCVQBXnSYx5oreHsfQ+skX9Q@mail.gmail.com>
Message-ID: <CAFdSV9vXLt-zXMbKNEFtvMSzQK6WzEzWbRfQVFxKiYpYCH8jpA@mail.gmail.com>

One option for helping, if you are looking for ways to help, would be to
help us verify all the bug reports still awaiting verification in Jira[1].
That involves testing the reported bug against 5.0.  Some of them have
tests, some of them don't.  For the ones that do, some of them need to be
converted to use the Hibernate testing framework[2].

[1] https://hibernate.atlassian.net/browse/HHH-9540?filter=17060
[2] https://github.com/hibernate/hibernate-test-case-templates

On Thu, Nov 5, 2015 at 8:57 AM Steve Ebersole <steve at hibernate.org> wrote:

> I am not really sure what you are asking.
>
> Are there particular bugs you are wanting to fix?  Are you looking to
> submit bug reports?
>
>
> On Thu, Nov 5, 2015 at 8:43 AM Abhimanyu Srivasatava <
> srabhimanyu at gmail.com> wrote:
>
>> Sir ,
>>   do  I  need  to  build  a  dummy  project  to  apply   various
>>  hibernate tools , validator  . I'm using  MySQL  as the  database  . I
>> really  want  to  associate  and   contribute  towards  your  community.
>>
>> On Mon, Sep 28, 2015 at 10:44 AM, Abhimanyu Srivasatava <
>> srabhimanyu at gmail.com> wrote:
>>
>>> Sir  I want to download your irc channel for jboss #hibernate-dev .
>>> Please  send me the link  so that I start  hanging out  with you  on
>>>  hibernate community dicussion . Post my query.
>>>
>>> On Mon, Sep 28, 2015 at 10:42 AM, Abhimanyu Srivasatava <
>>> srabhimanyu at gmail.com> wrote:
>>>
>>>> Sir I wasn't able to focus becoz of my university exams , soon  I'll
>>>> start fixing your bugs. Please  keep me throughout . Please help me in all
>>>> the  possible ways . I want to contribute to your  community  to my full
>>>> extent.  How to build source code for hibernate core. Please help me out.
>>>>
>>>> On Sat, Sep 19, 2015 at 10:58 AM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> https://github.com/hibernate/hibernate-orm/blob/master/CONTRIBUTING.md
>>>>>
>>>>> On Fri, Sep 18, 2015 at 1:51 PM Abhimanyu Srivasatava <
>>>>> srabhimanyu at gmail.com> wrote:
>>>>>
>>>>>> please send me  link  of   hibernate github account
>>>>>>
>>>>>> On Mon, Sep 14, 2015 at 7:05 AM, Abhimanyu Srivasatava <
>>>>>> srabhimanyu at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Steve Ebersole <steve at hibernate.org>
>>>>>>> Date: Thu, Sep 3, 2015 at 5:04 PM
>>>>>>> Subject: Re: [hibernate-dev] Want to contribute to hibernate
>>>>>>> community . Want some initial easy bugs for fixing
>>>>>>> To: Abhimanyu Srivasatava <srabhimanyu at gmail.com>
>>>>>>>
>>>>>>>
>>>>>>> http://hibernate.org/community/
>>>>>>>
>>>>>>> "Contribute" section: "IRC development channel"
>>>>>>>
>>>>>>> On Thu, Sep 3, 2015 at 12:01 PM Abhimanyu Srivasatava <
>>>>>>> srabhimanyu at gmail.com> wrote:
>>>>>>>
>>>>>>>> how can i hang with you on irc channel . Please tell me the
>>>>>>>> procedure
>>>>>>>>
>>>>>>>> On Wed, Sep 2, 2015 at 9:28 AM, Steve Ebersole <steve at hibernate.org
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hi :)
>>>>>>>>>
>>>>>>>>> Here[1] is the list of all unassigned issues reported against
>>>>>>>>> 5.0.  That is a great place to start.  See if any of them pique your
>>>>>>>>> interest.
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://hibernate.atlassian.net/browse/HHH-10056?jql=project%20%3D%20HHH%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(5.0.0.Beta1%2C%205.0.0.Beta2%2C%205.0.0.CR1%2C%205.0.0.CR2%2C%205.0.0.CR3%2C%205.0.0.CR4%2C%205.0.0.Final%2C%205.0.1%2C%205.0.2)%20AND%20assignee%20in%20(EMPTY)%20ORDER%20BY%20updated%20DESC
>>>>>>>>>
>>>>>>>>> On Wed, Sep 2, 2015 at 5:32 AM Abhimanyu Srivasatava <
>>>>>>>>> srabhimanyu at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> hibernate-dev mailing list
>>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>
>>

From karel at geovise.com  Mon Nov  9 15:52:41 2015
From: karel at geovise.com (Karel Maesen)
Date: Mon, 9 Nov 2015 21:52:41 +0100
Subject: [hibernate-dev] HQL and spatial
In-Reply-To: <CAFdSV9vsOPZFyCPrYMRGrq3xMucYwJkZRxqeFevQRvZREP3pzg@mail.gmail.com>
References: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>
	<B7499E79-DCD8-4174-AFFD-8355E1B39780@geovise.com>
	<CAFdSV9tqQvwYze4aE8p2+R9Y-BXWLWVbPX5_OeFOtomLd_1MxQ@mail.gmail.com>
	<425DA269-9600-4F34-8B28-EEFC6140972A@geovise.com>
	<CAFdSV9uMB-YcNYTDZRKV4F6F0m5z75diX_xyvpj4uHjdERS-7g@mail.gmail.com>
	<CAFdSV9vsOPZFyCPrYMRGrq3xMucYwJkZRxqeFevQRvZREP3pzg@mail.gmail.com>
Message-ID: <88CFF02A-4D94-4072-8E8E-D9A6E1E60074@geovise.com>

Hi Steve,


> On 02 Nov 2015, at 16:16, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Any further thoughts?
> 
> I looked over the link you gave in regards to literals, but did not fully understand.  I'd prefer this follow some "escape syntax" form, beyond that maybe you could just enumerate the literal types you'd want to support and their formats.

Spatial literals would be really nice to have, but then it is best to have also spatial functions in the grammar. So let?s try to add them. The escape syntax form is OK for me. We can have something like ?{gm ?SRID=4326;POINT(4.6 52.1)?}? for a geometry literal.

How do we proceed? Do I write something up informally? Or is there a formalism you prefer? 

> 
> ALso, I have not seen any discussion around "boolean-function-expressions as predicates" on SQM-15?

I?ll add some comments on that issue.

Regards,

Karel



From steve at hibernate.org  Mon Nov  9 16:32:40 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 09 Nov 2015 21:32:40 +0000
Subject: [hibernate-dev] HQL and spatial
In-Reply-To: <88CFF02A-4D94-4072-8E8E-D9A6E1E60074@geovise.com>
References: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>
	<B7499E79-DCD8-4174-AFFD-8355E1B39780@geovise.com>
	<CAFdSV9tqQvwYze4aE8p2+R9Y-BXWLWVbPX5_OeFOtomLd_1MxQ@mail.gmail.com>
	<425DA269-9600-4F34-8B28-EEFC6140972A@geovise.com>
	<CAFdSV9uMB-YcNYTDZRKV4F6F0m5z75diX_xyvpj4uHjdERS-7g@mail.gmail.com>
	<CAFdSV9vsOPZFyCPrYMRGrq3xMucYwJkZRxqeFevQRvZREP3pzg@mail.gmail.com>
	<88CFF02A-4D94-4072-8E8E-D9A6E1E60074@geovise.com>
Message-ID: <CAFdSV9vqde+bjkzeC1SmVeViQjV4nfOU+9VUg5akvKoThX_qVQ@mail.gmail.com>

On Mon, Nov 9, 2015 at 2:52 PM Karel Maesen <karel at geovise.com> wrote:

> Hi Steve,
>
>
> > On 02 Nov 2015, at 16:16, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > Any further thoughts?
> >
> > I looked over the link you gave in regards to literals, but did not
> fully understand.  I'd prefer this follow some "escape syntax" form, beyond
> that maybe you could just enumerate the literal types you'd want to support
> and their formats.
>
> Spatial literals would be really nice to have, but then it is best to have
> also spatial functions in the grammar. So let?s try to add them. The escape
> syntax form is OK for me. We can have something like ?{gm
> ?SRID=4326;POINT(4.6 52.1)?}? for a geometry literal.
>

I think it's best to not have the functions defined in the grammar.
Accounting for literals and accounting for functions are really 2 very
different things.

As for what I need... Well I need to understand what spatial types you'd
like to see definable as literals and what forms those literal definitions
might take.  Like looking at your "example" one, I have zero clue what that
is supposed to mean.



> How do we proceed? Do I write something up informally? Or is there a
> formalism you prefer?
>

For now, I think conversation (here, irc, whatever) is better. Let's see
where that leads.


> ALso, I have not seen any discussion around "boolean-function-expressions
> as predicates" on SQM-15?
>
> I?ll add some comments on that issue.
>

Great, thanks...

From steve at hibernate.org  Tue Nov 10 00:44:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Nov 2015 05:44:28 +0000
Subject: [hibernate-dev] Triage tomorrow
Message-ID: <CAFdSV9vfLcqW=KGRgbwwAt1Wy6SM88RnoO_h4fjtnKGywx3thQ@mail.gmail.com>

I won't be able to make the triage meeting tomorrow

From steve at hibernate.org  Tue Nov 10 10:46:10 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 10 Nov 2015 15:46:10 +0000
Subject: [hibernate-dev] Jira - GitHub sync
Message-ID: <CAFdSV9vCrtsf3n_h9fr9Bsj3_gNK3Qt8ZqNevZmPvbJkn8P4dg@mail.gmail.com>

I have been noticing that the "GitHub link" in Jira is no longer
automatically performing syncs.  I have asked Atlassian about it.  In the
meantime, if you use that feature (commit linking, PR linking, etc) you
will have to manually force a sync in Jira

From mihalcea.vlad at gmail.com  Wed Nov 11 00:12:31 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 11 Nov 2015 07:12:31 +0200
Subject: [hibernate-dev] Hibernate documentation on GitHub
Message-ID: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>

Hi,

What do you think if the Hibernate documentation would be on GitHub?
It would be much easier for anyone to contribute to it and maybe fix typos
and suggest improvements.

Vlad

From gunnar at hibernate.org  Wed Nov 11 02:26:43 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 11 Nov 2015 08:26:43 +0100
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
Message-ID: <CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>

Hi Vlad,

Do you mean the *rendered output* of the docs? Because the *sources*
are on GitHub of course (see the "documentation" module of the
individual projects). So users already can contribute to docs by
sending pull requests on GitHub (and that's happening sometimes).

For sure we could try and further lower the bar to contribution (e.g.
by adding "edit" links which then get you to the source on GitHub, as
some other projects do). But I'd prefer to leave the rendered output
on jboss.org, alongside with all other JBoss project's docs.

Cheers,

--Gunnar


2015-11-11 6:12 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> Hi,
>
> What do you think if the Hibernate documentation would be on GitHub?
> It would be much easier for anyone to contribute to it and maybe fix typos
> and suggest improvements.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Wed Nov 11 04:14:28 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 11 Nov 2015 10:14:28 +0100
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
Message-ID: <20151111091428.GA61330@Nineveh.local>

Hi,

> For sure we could try and further lower the bar to contribution (e.g.
> by adding "edit" links which then get you to the source on GitHub, as
> some other projects do).

> But I'd prefer to leave the rendered output
> on jboss.org, alongside with all other JBoss project's docs.

+1 - this goes along with the discussion a week back or so, regarding
documents being spread out across various systems. Things are already
"messy" as they are and if anything we need consolidation. 

In the context of the documentation, we also need to think about that 
we need to host multiple versions. 

Last but not least, afaik the plan was that hibernate.org becomes the place
where things would get consolidated. 

--Hardy



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151111/22ff3a4d/attachment.bin 

From sanne at hibernate.org  Wed Nov 11 07:21:11 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 11 Nov 2015 12:21:11 +0000
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <20151111091428.GA61330@Nineveh.local>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
	<20151111091428.GA61330@Nineveh.local>
Message-ID: <CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>

On 11 November 2015 at 09:14, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
>> For sure we could try and further lower the bar to contribution (e.g.
>> by adding "edit" links which then get you to the source on GitHub, as
>> some other projects do).
>
>> But I'd prefer to leave the rendered output
>> on jboss.org, alongside with all other JBoss project's docs.
>
> +1 - this goes along with the discussion a week back or so, regarding
> documents being spread out across various systems. Things are already
> "messy" as they are and if anything we need consolidation.
>
> In the context of the documentation, we also need to think about that
> we need to host multiple versions.
>
> Last but not least, afaik the plan was that hibernate.org becomes the place
> where things would get consolidated.

I'd really like to see them on hibernate.org: have a better
integration (including look& feel), better control the metadata to
make sure people actually find the latest version on search engines,
and not least to have them load faster.

Sanne

>
> --Hardy
>
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Wed Nov 11 09:28:00 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 11 Nov 2015 15:28:00 +0100
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
	<20151111091428.GA61330@Nineveh.local>
	<CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>
Message-ID: <20151111142800.GB66533@Nineveh.local>

> > Last but not least, afaik the plan was that hibernate.org becomes the place
> > where things would get consolidated.
> 
> I'd really like to see them on hibernate.org: have a better
> integration (including look& feel), better control the metadata to
> make sure people actually find the latest version on search engines,
> and not least to have them load faster.

+1

I guess maybe we need to have this discussion at some stage on why
it is tedious to add content to hibernate.org. ;-)

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151111/a660d116/attachment.bin 

From steve at hibernate.org  Wed Nov 11 09:36:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Nov 2015 14:36:13 +0000
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <20151111142800.GB66533@Nineveh.local>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
	<20151111091428.GA61330@Nineveh.local>
	<CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>
	<20151111142800.GB66533@Nineveh.local>
Message-ID: <CAFdSV9tJTUwQoz0K8tqW5_o-5XLqk6CCkJW-DzatwORYW3TjEw@mail.gmail.com>

I think it makes sense to host these on hibernate.org *after* we figure out
the version-specific content issues I brought up in Barcelona.

However, I am kind of torn.  Unless I misunderstand that would mean moving
the sources out of the upstream projects into the hibernate.org git repo.
I worry about that leading to even less focus on the docs.


On Wed, Nov 11, 2015 at 8:28 AM Hardy Ferentschik <hardy at hibernate.org>
wrote:

>
> I guess maybe we need to have this discussion at some stage on why
> it is tedious to add content to hibernate.org. ;-)
>

My previous comments (and I am not the only one) about this is more geared
toward in.relation.to.  We can discuss them if you want, but of course who
has time to work on it :)

From steve at hibernate.org  Wed Nov 11 12:55:45 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Nov 2015 17:55:45 +0000
Subject: [hibernate-dev] (no subject)
Message-ID: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>

I'd like to more formally deprecate the legacy bytecode enhancement
starting in 5.0.4 and remove it in 5.1.

The new code is superior and already feature compatible back to 5.0 Final.

Any objections?

From dreborier at gmail.com  Wed Nov 11 13:15:17 2015
From: dreborier at gmail.com (andrea boriero)
Date: Wed, 11 Nov 2015 18:15:17 +0000
Subject: [hibernate-dev] (no subject)
In-Reply-To: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>
References: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>
Message-ID: <CAL00eSQ7L8RRwxRpMm5zn0GXTv2dBobrcWU=reCa6cPzK-X6Qw@mail.gmail.com>

no objections

On 11 November 2015 at 17:55, Steve Ebersole <steve at hibernate.org> wrote:

> I'd like to more formally deprecate the legacy bytecode enhancement
> starting in 5.0.4 and remove it in 5.1.
>
> The new code is superior and already feature compatible back to 5.0 Final.
>
> Any objections?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov 11 15:37:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 11 Nov 2015 20:37:44 +0000
Subject: [hibernate-dev] Bytecode interception and attribute name versus
	attribute index
Message-ID: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>

As I work on HHH-10267, a thought that keeps coming up in my head is that
it would be great to avoid Map lookups in the enhancement and interception
code.

As an example of what I mean, consider the reader for a String field named
`name` which roughly looks like:

public String $$_hibernate_read_name() {
    return (String) $$_hibernate_getInterceptor().readObject( this, "name",
this.name );
}

In the interception code we need to resolve the attribute name ("name"
above) to the pertinent information from the persister,etc.  Typically this
is a Map lookup; sometimes it is a done by iterating a String[] of the
attribute names.

Ultimately the information is taken from persister and friends, which means
that the information is generally already readily consumable via array
access once we have resolved the name to a proper index.  Which got me
thinking it would be great if we could encode the attribute index into the
enhanced entity directly.  Going back to the example about.. if we knew
that the "name" attribute was the 4th attribute (index=3) according to the
entity persister we could leverage that information for better performing
access to the attribute metadata in the enhanced code and interceptor:

public String $$_hibernate_read_name() {
    return (String) $$_hibernate_getInterceptor().readObject( this, 3,
this.name );
}

One gotcha - always has to be one devil right ;)  Ok, 2 really...

First, this obviously is more fragile than relying on names; if the order
changes but the bytecode is not re-enhanced, that could lead to very
subtle, nasty problems.

The other issue is that this requires us to be able to consistently be able
to order the attributes.  The Enhancer currently does not rely on the built
metadata (org.hibernate.mapping) at all; it parses the entity annotations
(completely annotation specific) on its own.  Given the 2-phase break down
in JPA bootstrapping, having Enhancer leverage the built metadata is not
really going to be possible.  Which is unfortunate, because doing so would
be nice for other reasons (like supporting XML mappings for enhancement as
well, etc).

That's a lot of information, sorry about that :)

But anyone have thoughts on that?

From gunnar at hibernate.org  Thu Nov 12 03:36:46 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 12 Nov 2015 09:36:46 +0100
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
Message-ID: <CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>

Is there any estimate what would be gained perf-wise by doing this optimization?

> First, this obviously is more fragile than relying on names; if the order
> changes but the bytecode is not re-enhanced, that could lead to very
> subtle, nasty problems.

Agreed, but to me it seems acceptable with such optimization having to
be explicitly enabled and the docs of that setting describing this
matter clearly.

> The other issue is that this requires us to be able to consistently be able
> to order the attributes.

Maybe the enhancer could enhance entities with a (static) method
returning the attribute order it works with, or maybe some separate
contract for making this order available. Then at runtime this order
could be fed to persisters et al. for enhanced entities.

Not sure whether it's doable or how complex it'd be, just throwing out the idea.

--Gunnar


2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> As I work on HHH-10267, a thought that keeps coming up in my head is that
> it would be great to avoid Map lookups in the enhancement and interception
> code.
>
> As an example of what I mean, consider the reader for a String field named
> `name` which roughly looks like:
>
> public String $$_hibernate_read_name() {
>     return (String) $$_hibernate_getInterceptor().readObject( this, "name",
> this.name );
> }
>
> In the interception code we need to resolve the attribute name ("name"
> above) to the pertinent information from the persister,etc.  Typically this
> is a Map lookup; sometimes it is a done by iterating a String[] of the
> attribute names.
>
> Ultimately the information is taken from persister and friends, which means
> that the information is generally already readily consumable via array
> access once we have resolved the name to a proper index.  Which got me
> thinking it would be great if we could encode the attribute index into the
> enhanced entity directly.  Going back to the example about.. if we knew
> that the "name" attribute was the 4th attribute (index=3) according to the
> entity persister we could leverage that information for better performing
> access to the attribute metadata in the enhanced code and interceptor:
>
> public String $$_hibernate_read_name() {
>     return (String) $$_hibernate_getInterceptor().readObject( this, 3,
> this.name );
> }
>
> One gotcha - always has to be one devil right ;)  Ok, 2 really...
>
> First, this obviously is more fragile than relying on names; if the order
> changes but the bytecode is not re-enhanced, that could lead to very
> subtle, nasty problems.
>
> The other issue is that this requires us to be able to consistently be able
> to order the attributes.  The Enhancer currently does not rely on the built
> metadata (org.hibernate.mapping) at all; it parses the entity annotations
> (completely annotation specific) on its own.  Given the 2-phase break down
> in JPA bootstrapping, having Enhancer leverage the built metadata is not
> really going to be possible.  Which is unfortunate, because doing so would
> be nice for other reasons (like supporting XML mappings for enhancement as
> well, etc).
>
> That's a lot of information, sorry about that :)
>
> But anyone have thoughts on that?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From lbarreiro at redhat.com  Thu Nov 12 09:27:50 2015
From: lbarreiro at redhat.com (Luis Barreiro)
Date: Thu, 12 Nov 2015 14:27:50 +0000
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
	<CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
Message-ID: <5644A1E6.5090204@redhat.com>


On 11/12/2015 08:36 AM, Gunnar Morling wrote:
> Is there any estimate what would be gained perf-wise by doing this optimization?
>
>> First, this obviously is more fragile than relying on names; if the order
>> changes but the bytecode is not re-enhanced, that could lead to very
>> subtle, nasty problems.
> Agreed, but to me it seems acceptable with such optimization having to
> be explicitly enabled and the docs of that setting describing this
> matter clearly.
>
>> The other issue is that this requires us to be able to consistently be able
>> to order the attributes.
> Maybe the enhancer could enhance entities with a (static) method
> returning the attribute order it works with, or maybe some separate
> contract for making this order available. Then at runtime this order
> could be fed to persisters et al. for enhanced entities.
>
> Not sure whether it's doable or how complex it'd be, just throwing out the idea.

I was having the same line of though, to expose the attribute order.

Going that route, I don't think we do have to make it consistent with 
the persisters order ... making it more independent, and therefore more 
robust.

What we would need is to understand 'enhancedIndexes' in the integration 
points. I'll try to hack something in the next couple of days.

> --Gunnar
>
>
> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> As I work on HHH-10267, a thought that keeps coming up in my head is that
>> it would be great to avoid Map lookups in the enhancement and interception
>> code.
>>
>> As an example of what I mean, consider the reader for a String field named
>> `name` which roughly looks like:
>>
>> public String $$_hibernate_read_name() {
>>      return (String) $$_hibernate_getInterceptor().readObject( this, "name",
>> this.name );
>> }
>>
>> In the interception code we need to resolve the attribute name ("name"
>> above) to the pertinent information from the persister,etc.  Typically this
>> is a Map lookup; sometimes it is a done by iterating a String[] of the
>> attribute names.
>>
>> Ultimately the information is taken from persister and friends, which means
>> that the information is generally already readily consumable via array
>> access once we have resolved the name to a proper index.  Which got me
>> thinking it would be great if we could encode the attribute index into the
>> enhanced entity directly.  Going back to the example about.. if we knew
>> that the "name" attribute was the 4th attribute (index=3) according to the
>> entity persister we could leverage that information for better performing
>> access to the attribute metadata in the enhanced code and interceptor:
>>
>> public String $$_hibernate_read_name() {
>>      return (String) $$_hibernate_getInterceptor().readObject( this, 3,
>> this.name );
>> }
>>
>> One gotcha - always has to be one devil right ;)  Ok, 2 really...
>>
>> First, this obviously is more fragile than relying on names; if the order
>> changes but the bytecode is not re-enhanced, that could lead to very
>> subtle, nasty problems.
>>
>> The other issue is that this requires us to be able to consistently be able
>> to order the attributes.  The Enhancer currently does not rely on the built
>> metadata (org.hibernate.mapping) at all; it parses the entity annotations
>> (completely annotation specific) on its own.  Given the 2-phase break down
>> in JPA bootstrapping, having Enhancer leverage the built metadata is not
>> really going to be possible.  Which is unfortunate, because doing so would
>> be nice for other reasons (like supporting XML mappings for enhancement as
>> well, etc).
>>
>> That's a lot of information, sorry about that :)
>>
>> But anyone have thoughts on that?
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Luis Barreiro
JBoss^? by Red Hat?????

From steve at hibernate.org  Thu Nov 12 09:29:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 12 Nov 2015 14:29:20 +0000
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
	<CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
Message-ID: <CAFdSV9sM1B0YthDRu_mHYFhL7Sd5heGg1H9zW+p-BV4M-ozBWg@mail.gmail.com>

I have no estimate as to how much this would help.  Many of the
improvements coming from the performance work have been of the sort that is
removing Map lookups; some of them across VERY small (and finite) sets of
Map keys.  My concern here is that the Map look up occurs any time an
enhanced entity's getter or setter is called, which seems like a
potentially bigger performance impact.

I'm going to table this for now until the jandex-binding work.  But as part
of that work, I think it makes a ton of sense to make sure we develop a
strategy for consistent ordering of processing attributes.

On Thu, Nov 12, 2015 at 2:36 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Is there any estimate what would be gained perf-wise by doing this
> optimization?
>
> > First, this obviously is more fragile than relying on names; if the order
> > changes but the bytecode is not re-enhanced, that could lead to very
> > subtle, nasty problems.
>
> Agreed, but to me it seems acceptable with such optimization having to
> be explicitly enabled and the docs of that setting describing this
> matter clearly.
>
> > The other issue is that this requires us to be able to consistently be
> able
> > to order the attributes.
>
> Maybe the enhancer could enhance entities with a (static) method
> returning the attribute order it works with, or maybe some separate
> contract for making this order available. Then at runtime this order
> could be fed to persisters et al. for enhanced entities.
>
> Not sure whether it's doable or how complex it'd be, just throwing out the
> idea.
>
> --Gunnar
>
>
> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > As I work on HHH-10267, a thought that keeps coming up in my head is that
> > it would be great to avoid Map lookups in the enhancement and
> interception
> > code.
> >
> > As an example of what I mean, consider the reader for a String field
> named
> > `name` which roughly looks like:
> >
> > public String $$_hibernate_read_name() {
> >     return (String) $$_hibernate_getInterceptor().readObject( this,
> "name",
> > this.name );
> > }
> >
> > In the interception code we need to resolve the attribute name ("name"
> > above) to the pertinent information from the persister,etc.  Typically
> this
> > is a Map lookup; sometimes it is a done by iterating a String[] of the
> > attribute names.
> >
> > Ultimately the information is taken from persister and friends, which
> means
> > that the information is generally already readily consumable via array
> > access once we have resolved the name to a proper index.  Which got me
> > thinking it would be great if we could encode the attribute index into
> the
> > enhanced entity directly.  Going back to the example about.. if we knew
> > that the "name" attribute was the 4th attribute (index=3) according to
> the
> > entity persister we could leverage that information for better performing
> > access to the attribute metadata in the enhanced code and interceptor:
> >
> > public String $$_hibernate_read_name() {
> >     return (String) $$_hibernate_getInterceptor().readObject( this, 3,
> > this.name );
> > }
> >
> > One gotcha - always has to be one devil right ;)  Ok, 2 really...
> >
> > First, this obviously is more fragile than relying on names; if the order
> > changes but the bytecode is not re-enhanced, that could lead to very
> > subtle, nasty problems.
> >
> > The other issue is that this requires us to be able to consistently be
> able
> > to order the attributes.  The Enhancer currently does not rely on the
> built
> > metadata (org.hibernate.mapping) at all; it parses the entity annotations
> > (completely annotation specific) on its own.  Given the 2-phase break
> down
> > in JPA bootstrapping, having Enhancer leverage the built metadata is not
> > really going to be possible.  Which is unfortunate, because doing so
> would
> > be nice for other reasons (like supporting XML mappings for enhancement
> as
> > well, etc).
> >
> > That's a lot of information, sorry about that :)
> >
> > But anyone have thoughts on that?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Nov 12 09:30:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 12 Nov 2015 14:30:11 +0000
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CAFdSV9sM1B0YthDRu_mHYFhL7Sd5heGg1H9zW+p-BV4M-ozBWg@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
	<CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
	<CAFdSV9sM1B0YthDRu_mHYFhL7Sd5heGg1H9zW+p-BV4M-ozBWg@mail.gmail.com>
Message-ID: <CAFdSV9vPoo5JmWrGGL6ipZGxWVc8=idHun49Y6LG61n60GxHZg@mail.gmail.com>

But I think that just redefines the same problem.  Just that now instead of
String->Integer we need some Integer->Integer resolution.  Not sure that
really gains us anything.

On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole <steve at hibernate.org> wrote:

> I have no estimate as to how much this would help.  Many of the
> improvements coming from the performance work have been of the sort that is
> removing Map lookups; some of them across VERY small (and finite) sets of
> Map keys.  My concern here is that the Map look up occurs any time an
> enhanced entity's getter or setter is called, which seems like a
> potentially bigger performance impact.
>
> I'm going to table this for now until the jandex-binding work.  But as
> part of that work, I think it makes a ton of sense to make sure we develop
> a strategy for consistent ordering of processing attributes.
>
> On Thu, Nov 12, 2015 at 2:36 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Is there any estimate what would be gained perf-wise by doing this
>> optimization?
>>
>> > First, this obviously is more fragile than relying on names; if the
>> order
>> > changes but the bytecode is not re-enhanced, that could lead to very
>> > subtle, nasty problems.
>>
>> Agreed, but to me it seems acceptable with such optimization having to
>> be explicitly enabled and the docs of that setting describing this
>> matter clearly.
>>
>> > The other issue is that this requires us to be able to consistently be
>> able
>> > to order the attributes.
>>
>> Maybe the enhancer could enhance entities with a (static) method
>> returning the attribute order it works with, or maybe some separate
>> contract for making this order available. Then at runtime this order
>> could be fed to persisters et al. for enhanced entities.
>>
>> Not sure whether it's doable or how complex it'd be, just throwing out
>> the idea.
>>
>> --Gunnar
>>
>>
>> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > As I work on HHH-10267, a thought that keeps coming up in my head is
>> that
>> > it would be great to avoid Map lookups in the enhancement and
>> interception
>> > code.
>> >
>> > As an example of what I mean, consider the reader for a String field
>> named
>> > `name` which roughly looks like:
>> >
>> > public String $$_hibernate_read_name() {
>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
>> "name",
>> > this.name );
>> > }
>> >
>> > In the interception code we need to resolve the attribute name ("name"
>> > above) to the pertinent information from the persister,etc.  Typically
>> this
>> > is a Map lookup; sometimes it is a done by iterating a String[] of the
>> > attribute names.
>> >
>> > Ultimately the information is taken from persister and friends, which
>> means
>> > that the information is generally already readily consumable via array
>> > access once we have resolved the name to a proper index.  Which got me
>> > thinking it would be great if we could encode the attribute index into
>> the
>> > enhanced entity directly.  Going back to the example about.. if we knew
>> > that the "name" attribute was the 4th attribute (index=3) according to
>> the
>> > entity persister we could leverage that information for better
>> performing
>> > access to the attribute metadata in the enhanced code and interceptor:
>> >
>> > public String $$_hibernate_read_name() {
>> >     return (String) $$_hibernate_getInterceptor().readObject( this, 3,
>> > this.name );
>> > }
>> >
>> > One gotcha - always has to be one devil right ;)  Ok, 2 really...
>> >
>> > First, this obviously is more fragile than relying on names; if the
>> order
>> > changes but the bytecode is not re-enhanced, that could lead to very
>> > subtle, nasty problems.
>> >
>> > The other issue is that this requires us to be able to consistently be
>> able
>> > to order the attributes.  The Enhancer currently does not rely on the
>> built
>> > metadata (org.hibernate.mapping) at all; it parses the entity
>> annotations
>> > (completely annotation specific) on its own.  Given the 2-phase break
>> down
>> > in JPA bootstrapping, having Enhancer leverage the built metadata is not
>> > really going to be possible.  Which is unfortunate, because doing so
>> would
>> > be nice for other reasons (like supporting XML mappings for enhancement
>> as
>> > well, etc).
>> >
>> > That's a lot of information, sorry about that :)
>> >
>> > But anyone have thoughts on that?
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Thu Nov 12 09:53:15 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 12 Nov 2015 15:53:15 +0100
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CAFdSV9vPoo5JmWrGGL6ipZGxWVc8=idHun49Y6LG61n60GxHZg@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
	<CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
	<CAFdSV9sM1B0YthDRu_mHYFhL7Sd5heGg1H9zW+p-BV4M-ozBWg@mail.gmail.com>
	<CAFdSV9vPoo5JmWrGGL6ipZGxWVc8=idHun49Y6LG61n60GxHZg@mail.gmail.com>
Message-ID: <CADGJaX_Hv6rmFra8A0EnoPcsCoKJciXT7Usm+XT-4ruikcOqFw@mail.gmail.com>

It would be a one-time effort during persister initialisation; At that
time a look-up would happen in order to seed persisters with
attributes in the order as determined by the enhancer. Then at
runtime, upon getter/setter invocation, the index values passed from
the enhanced code would be used as is for array index access in
persisters.

2015-11-12 15:30 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> But I think that just redefines the same problem.  Just that now instead of
> String->Integer we need some Integer->Integer resolution.  Not sure that
> really gains us anything.
>
> On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> I have no estimate as to how much this would help.  Many of the
>> improvements coming from the performance work have been of the sort that is
>> removing Map lookups; some of them across VERY small (and finite) sets of
>> Map keys.  My concern here is that the Map look up occurs any time an
>> enhanced entity's getter or setter is called, which seems like a potentially
>> bigger performance impact.
>>
>> I'm going to table this for now until the jandex-binding work.  But as
>> part of that work, I think it makes a ton of sense to make sure we develop a
>> strategy for consistent ordering of processing attributes.
>>
>> On Thu, Nov 12, 2015 at 2:36 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> Is there any estimate what would be gained perf-wise by doing this
>>> optimization?
>>>
>>> > First, this obviously is more fragile than relying on names; if the
>>> > order
>>> > changes but the bytecode is not re-enhanced, that could lead to very
>>> > subtle, nasty problems.
>>>
>>> Agreed, but to me it seems acceptable with such optimization having to
>>> be explicitly enabled and the docs of that setting describing this
>>> matter clearly.
>>>
>>> > The other issue is that this requires us to be able to consistently be
>>> > able
>>> > to order the attributes.
>>>
>>> Maybe the enhancer could enhance entities with a (static) method
>>> returning the attribute order it works with, or maybe some separate
>>> contract for making this order available. Then at runtime this order
>>> could be fed to persisters et al. for enhanced entities.
>>>
>>> Not sure whether it's doable or how complex it'd be, just throwing out
>>> the idea.
>>>
>>> --Gunnar
>>>
>>>
>>> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>> > As I work on HHH-10267, a thought that keeps coming up in my head is
>>> > that
>>> > it would be great to avoid Map lookups in the enhancement and
>>> > interception
>>> > code.
>>> >
>>> > As an example of what I mean, consider the reader for a String field
>>> > named
>>> > `name` which roughly looks like:
>>> >
>>> > public String $$_hibernate_read_name() {
>>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
>>> > "name",
>>> > this.name );
>>> > }
>>> >
>>> > In the interception code we need to resolve the attribute name ("name"
>>> > above) to the pertinent information from the persister,etc.  Typically
>>> > this
>>> > is a Map lookup; sometimes it is a done by iterating a String[] of the
>>> > attribute names.
>>> >
>>> > Ultimately the information is taken from persister and friends, which
>>> > means
>>> > that the information is generally already readily consumable via array
>>> > access once we have resolved the name to a proper index.  Which got me
>>> > thinking it would be great if we could encode the attribute index into
>>> > the
>>> > enhanced entity directly.  Going back to the example about.. if we knew
>>> > that the "name" attribute was the 4th attribute (index=3) according to
>>> > the
>>> > entity persister we could leverage that information for better
>>> > performing
>>> > access to the attribute metadata in the enhanced code and interceptor:
>>> >
>>> > public String $$_hibernate_read_name() {
>>> >     return (String) $$_hibernate_getInterceptor().readObject( this, 3,
>>> > this.name );
>>> > }
>>> >
>>> > One gotcha - always has to be one devil right ;)  Ok, 2 really...
>>> >
>>> > First, this obviously is more fragile than relying on names; if the
>>> > order
>>> > changes but the bytecode is not re-enhanced, that could lead to very
>>> > subtle, nasty problems.
>>> >
>>> > The other issue is that this requires us to be able to consistently be
>>> > able
>>> > to order the attributes.  The Enhancer currently does not rely on the
>>> > built
>>> > metadata (org.hibernate.mapping) at all; it parses the entity
>>> > annotations
>>> > (completely annotation specific) on its own.  Given the 2-phase break
>>> > down
>>> > in JPA bootstrapping, having Enhancer leverage the built metadata is
>>> > not
>>> > really going to be possible.  Which is unfortunate, because doing so
>>> > would
>>> > be nice for other reasons (like supporting XML mappings for enhancement
>>> > as
>>> > well, etc).
>>> >
>>> > That's a lot of information, sorry about that :)
>>> >
>>> > But anyone have thoughts on that?
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Nov 12 10:07:02 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 12 Nov 2015 15:07:02 +0000
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CADGJaX_Hv6rmFra8A0EnoPcsCoKJciXT7Usm+XT-4ruikcOqFw@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
	<CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
	<CAFdSV9sM1B0YthDRu_mHYFhL7Sd5heGg1H9zW+p-BV4M-ozBWg@mail.gmail.com>
	<CAFdSV9vPoo5JmWrGGL6ipZGxWVc8=idHun49Y6LG61n60GxHZg@mail.gmail.com>
	<CADGJaX_Hv6rmFra8A0EnoPcsCoKJciXT7Usm+XT-4ruikcOqFw@mail.gmail.com>
Message-ID: <CAFdSV9sFrXwRWPnZedptZ3HxhjiPnXovYM6eADUTcVSd31fzfA@mail.gmail.com>

But see that is exactly the problem.  That cannot work.  You want us to
delay enhancement until after the persisters are built.  But building the
persisters requires access to the Class.  But by that time since we have
the Class reference we can no longer enhance it.  It's a chicken-egg
problem.

What I suggest longer term is a slight variation, where we drive the
"indexing" based on the mapping model.  Actually that also will not work as
the code is today.  Really what I'd like to do is to leverage the
jandex-binding work.  Specifically there we have a Jandex-driven
pre-parsing of the domain model (including XML augmentation).  That model
would be perfect for this.

On Thu, Nov 12, 2015 at 9:00 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> It would be a one-time effort during persister initialisation; At that
> time a look-up would happen in order to seed persisters with
> attributes in the order as determined by the enhancer. Then at
> runtime, upon getter/setter invocation, the index values passed from
> the enhanced code would be used as is for array index access in
> persisters.
>
> 2015-11-12 15:30 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > But I think that just redefines the same problem.  Just that now instead
> of
> > String->Integer we need some Integer->Integer resolution.  Not sure that
> > really gains us anything.
> >
> > On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> I have no estimate as to how much this would help.  Many of the
> >> improvements coming from the performance work have been of the sort
> that is
> >> removing Map lookups; some of them across VERY small (and finite) sets
> of
> >> Map keys.  My concern here is that the Map look up occurs any time an
> >> enhanced entity's getter or setter is called, which seems like a
> potentially
> >> bigger performance impact.
> >>
> >> I'm going to table this for now until the jandex-binding work.  But as
> >> part of that work, I think it makes a ton of sense to make sure we
> develop a
> >> strategy for consistent ordering of processing attributes.
> >>
> >> On Thu, Nov 12, 2015 at 2:36 AM Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >>>
> >>> Is there any estimate what would be gained perf-wise by doing this
> >>> optimization?
> >>>
> >>> > First, this obviously is more fragile than relying on names; if the
> >>> > order
> >>> > changes but the bytecode is not re-enhanced, that could lead to very
> >>> > subtle, nasty problems.
> >>>
> >>> Agreed, but to me it seems acceptable with such optimization having to
> >>> be explicitly enabled and the docs of that setting describing this
> >>> matter clearly.
> >>>
> >>> > The other issue is that this requires us to be able to consistently
> be
> >>> > able
> >>> > to order the attributes.
> >>>
> >>> Maybe the enhancer could enhance entities with a (static) method
> >>> returning the attribute order it works with, or maybe some separate
> >>> contract for making this order available. Then at runtime this order
> >>> could be fed to persisters et al. for enhanced entities.
> >>>
> >>> Not sure whether it's doable or how complex it'd be, just throwing out
> >>> the idea.
> >>>
> >>> --Gunnar
> >>>
> >>>
> >>> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >>> > As I work on HHH-10267, a thought that keeps coming up in my head is
> >>> > that
> >>> > it would be great to avoid Map lookups in the enhancement and
> >>> > interception
> >>> > code.
> >>> >
> >>> > As an example of what I mean, consider the reader for a String field
> >>> > named
> >>> > `name` which roughly looks like:
> >>> >
> >>> > public String $$_hibernate_read_name() {
> >>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
> >>> > "name",
> >>> > this.name );
> >>> > }
> >>> >
> >>> > In the interception code we need to resolve the attribute name
> ("name"
> >>> > above) to the pertinent information from the persister,etc.
> Typically
> >>> > this
> >>> > is a Map lookup; sometimes it is a done by iterating a String[] of
> the
> >>> > attribute names.
> >>> >
> >>> > Ultimately the information is taken from persister and friends, which
> >>> > means
> >>> > that the information is generally already readily consumable via
> array
> >>> > access once we have resolved the name to a proper index.  Which got
> me
> >>> > thinking it would be great if we could encode the attribute index
> into
> >>> > the
> >>> > enhanced entity directly.  Going back to the example about.. if we
> knew
> >>> > that the "name" attribute was the 4th attribute (index=3) according
> to
> >>> > the
> >>> > entity persister we could leverage that information for better
> >>> > performing
> >>> > access to the attribute metadata in the enhanced code and
> interceptor:
> >>> >
> >>> > public String $$_hibernate_read_name() {
> >>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
> 3,
> >>> > this.name );
> >>> > }
> >>> >
> >>> > One gotcha - always has to be one devil right ;)  Ok, 2 really...
> >>> >
> >>> > First, this obviously is more fragile than relying on names; if the
> >>> > order
> >>> > changes but the bytecode is not re-enhanced, that could lead to very
> >>> > subtle, nasty problems.
> >>> >
> >>> > The other issue is that this requires us to be able to consistently
> be
> >>> > able
> >>> > to order the attributes.  The Enhancer currently does not rely on the
> >>> > built
> >>> > metadata (org.hibernate.mapping) at all; it parses the entity
> >>> > annotations
> >>> > (completely annotation specific) on its own.  Given the 2-phase break
> >>> > down
> >>> > in JPA bootstrapping, having Enhancer leverage the built metadata is
> >>> > not
> >>> > really going to be possible.  Which is unfortunate, because doing so
> >>> > would
> >>> > be nice for other reasons (like supporting XML mappings for
> enhancement
> >>> > as
> >>> > well, etc).
> >>> >
> >>> > That's a lot of information, sorry about that :)
> >>> >
> >>> > But anyone have thoughts on that?
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Thu Nov 12 10:18:58 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 12 Nov 2015 16:18:58 +0100
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CAFdSV9sFrXwRWPnZedptZ3HxhjiPnXovYM6eADUTcVSd31fzfA@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
	<CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
	<CAFdSV9sM1B0YthDRu_mHYFhL7Sd5heGg1H9zW+p-BV4M-ozBWg@mail.gmail.com>
	<CAFdSV9vPoo5JmWrGGL6ipZGxWVc8=idHun49Y6LG61n60GxHZg@mail.gmail.com>
	<CADGJaX_Hv6rmFra8A0EnoPcsCoKJciXT7Usm+XT-4ruikcOqFw@mail.gmail.com>
	<CAFdSV9sFrXwRWPnZedptZ3HxhjiPnXovYM6eADUTcVSd31fzfA@mail.gmail.com>
Message-ID: <CADGJaX9Q+ZPL3MH+j7KAJttjBGiDLZtef4HVVb-A5AK8x1nSOA@mail.gmail.com>

> You want us to delay enhancement until after the persisters are built.

No, I mean to let enhancement define the attribute ordering and
initialize persisters with that previously defined order.

> What I suggest longer term is a slight variation...

Yes, that sounds nice.


2015-11-12 16:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> But see that is exactly the problem.  That cannot work.  You want us to
> delay enhancement until after the persisters are built.  But building the
> persisters requires access to the Class.  But by that time since we have the
> Class reference we can no longer enhance it.  It's a chicken-egg problem.
>
> What I suggest longer term is a slight variation, where we drive the
> "indexing" based on the mapping model.  Actually that also will not work as
> the code is today.  Really what I'd like to do is to leverage the
> jandex-binding work.  Specifically there we have a Jandex-driven pre-parsing
> of the domain model (including XML augmentation).  That model would be
> perfect for this.
>
> On Thu, Nov 12, 2015 at 9:00 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> It would be a one-time effort during persister initialisation; At that
>> time a look-up would happen in order to seed persisters with
>> attributes in the order as determined by the enhancer. Then at
>> runtime, upon getter/setter invocation, the index values passed from
>> the enhanced code would be used as is for array index access in
>> persisters.
>>
>> 2015-11-12 15:30 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > But I think that just redefines the same problem.  Just that now instead
>> > of
>> > String->Integer we need some Integer->Integer resolution.  Not sure that
>> > really gains us anything.
>> >
>> > On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >>
>> >> I have no estimate as to how much this would help.  Many of the
>> >> improvements coming from the performance work have been of the sort
>> >> that is
>> >> removing Map lookups; some of them across VERY small (and finite) sets
>> >> of
>> >> Map keys.  My concern here is that the Map look up occurs any time an
>> >> enhanced entity's getter or setter is called, which seems like a
>> >> potentially
>> >> bigger performance impact.
>> >>
>> >> I'm going to table this for now until the jandex-binding work.  But as
>> >> part of that work, I think it makes a ton of sense to make sure we
>> >> develop a
>> >> strategy for consistent ordering of processing attributes.
>> >>
>> >> On Thu, Nov 12, 2015 at 2:36 AM Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >>>
>> >>> Is there any estimate what would be gained perf-wise by doing this
>> >>> optimization?
>> >>>
>> >>> > First, this obviously is more fragile than relying on names; if the
>> >>> > order
>> >>> > changes but the bytecode is not re-enhanced, that could lead to very
>> >>> > subtle, nasty problems.
>> >>>
>> >>> Agreed, but to me it seems acceptable with such optimization having to
>> >>> be explicitly enabled and the docs of that setting describing this
>> >>> matter clearly.
>> >>>
>> >>> > The other issue is that this requires us to be able to consistently
>> >>> > be
>> >>> > able
>> >>> > to order the attributes.
>> >>>
>> >>> Maybe the enhancer could enhance entities with a (static) method
>> >>> returning the attribute order it works with, or maybe some separate
>> >>> contract for making this order available. Then at runtime this order
>> >>> could be fed to persisters et al. for enhanced entities.
>> >>>
>> >>> Not sure whether it's doable or how complex it'd be, just throwing out
>> >>> the idea.
>> >>>
>> >>> --Gunnar
>> >>>
>> >>>
>> >>> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >>> > As I work on HHH-10267, a thought that keeps coming up in my head is
>> >>> > that
>> >>> > it would be great to avoid Map lookups in the enhancement and
>> >>> > interception
>> >>> > code.
>> >>> >
>> >>> > As an example of what I mean, consider the reader for a String field
>> >>> > named
>> >>> > `name` which roughly looks like:
>> >>> >
>> >>> > public String $$_hibernate_read_name() {
>> >>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
>> >>> > "name",
>> >>> > this.name );
>> >>> > }
>> >>> >
>> >>> > In the interception code we need to resolve the attribute name
>> >>> > ("name"
>> >>> > above) to the pertinent information from the persister,etc.
>> >>> > Typically
>> >>> > this
>> >>> > is a Map lookup; sometimes it is a done by iterating a String[] of
>> >>> > the
>> >>> > attribute names.
>> >>> >
>> >>> > Ultimately the information is taken from persister and friends,
>> >>> > which
>> >>> > means
>> >>> > that the information is generally already readily consumable via
>> >>> > array
>> >>> > access once we have resolved the name to a proper index.  Which got
>> >>> > me
>> >>> > thinking it would be great if we could encode the attribute index
>> >>> > into
>> >>> > the
>> >>> > enhanced entity directly.  Going back to the example about.. if we
>> >>> > knew
>> >>> > that the "name" attribute was the 4th attribute (index=3) according
>> >>> > to
>> >>> > the
>> >>> > entity persister we could leverage that information for better
>> >>> > performing
>> >>> > access to the attribute metadata in the enhanced code and
>> >>> > interceptor:
>> >>> >
>> >>> > public String $$_hibernate_read_name() {
>> >>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
>> >>> > 3,
>> >>> > this.name );
>> >>> > }
>> >>> >
>> >>> > One gotcha - always has to be one devil right ;)  Ok, 2 really...
>> >>> >
>> >>> > First, this obviously is more fragile than relying on names; if the
>> >>> > order
>> >>> > changes but the bytecode is not re-enhanced, that could lead to very
>> >>> > subtle, nasty problems.
>> >>> >
>> >>> > The other issue is that this requires us to be able to consistently
>> >>> > be
>> >>> > able
>> >>> > to order the attributes.  The Enhancer currently does not rely on
>> >>> > the
>> >>> > built
>> >>> > metadata (org.hibernate.mapping) at all; it parses the entity
>> >>> > annotations
>> >>> > (completely annotation specific) on its own.  Given the 2-phase
>> >>> > break
>> >>> > down
>> >>> > in JPA bootstrapping, having Enhancer leverage the built metadata is
>> >>> > not
>> >>> > really going to be possible.  Which is unfortunate, because doing so
>> >>> > would
>> >>> > be nice for other reasons (like supporting XML mappings for
>> >>> > enhancement
>> >>> > as
>> >>> > well, etc).
>> >>> >
>> >>> > That's a lot of information, sorry about that :)
>> >>> >
>> >>> > But anyone have thoughts on that?
>> >>> > _______________________________________________
>> >>> > hibernate-dev mailing list
>> >>> > hibernate-dev at lists.jboss.org
>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Nov 12 11:39:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 12 Nov 2015 16:39:21 +0000
Subject: [hibernate-dev] (no subject)
In-Reply-To: <CAL00eSQ7L8RRwxRpMm5zn0GXTv2dBobrcWU=reCa6cPzK-X6Qw@mail.gmail.com>
References: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>
	<CAL00eSQ7L8RRwxRpMm5zn0GXTv2dBobrcWU=reCa6cPzK-X6Qw@mail.gmail.com>
Message-ID: <CAFdSV9uHQDY3x45uT3t5xas=dr_8hh379f+bFr=NtZxpqxHiAg@mail.gmail.com>

https://hibernate.atlassian.net/browse/HHH-10280
https://hibernate.atlassian.net/browse/HHH-10281

On Wed, Nov 11, 2015 at 12:15 PM andrea boriero <dreborier at gmail.com> wrote:

> no objections
>
> On 11 November 2015 at 17:55, Steve Ebersole <steve at hibernate.org> wrote:
>
>> I'd like to more formally deprecate the legacy bytecode enhancement
>> starting in 5.0.4 and remove it in 5.1.
>>
>> The new code is superior and already feature compatible back to 5.0 Final.
>>
>> Any objections?
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Thu Nov 12 11:46:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 12 Nov 2015 16:46:01 +0000
Subject: [hibernate-dev] (no subject)
In-Reply-To: <CAFdSV9uHQDY3x45uT3t5xas=dr_8hh379f+bFr=NtZxpqxHiAg@mail.gmail.com>
References: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>
	<CAL00eSQ7L8RRwxRpMm5zn0GXTv2dBobrcWU=reCa6cPzK-X6Qw@mail.gmail.com>
	<CAFdSV9uHQDY3x45uT3t5xas=dr_8hh379f+bFr=NtZxpqxHiAg@mail.gmail.com>
Message-ID: <CAFm4XO3h3ZjtpxAo5KR8V8FVgzG69TkSgKvHFEkzKLmAhgQzyg@mail.gmail.com>

+1

On 12 November 2015 at 16:39, Steve Ebersole <steve at hibernate.org> wrote:
> https://hibernate.atlassian.net/browse/HHH-10280
> https://hibernate.atlassian.net/browse/HHH-10281
>
> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero <dreborier at gmail.com> wrote:
>
>> no objections
>>
>> On 11 November 2015 at 17:55, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> I'd like to more formally deprecate the legacy bytecode enhancement
>>> starting in 5.0.4 and remove it in 5.1.
>>>
>>> The new code is superior and already feature compatible back to 5.0 Final.
>>>
>>> Any objections?
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu Nov 12 11:53:05 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 12 Nov 2015 16:53:05 +0000
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CADGJaX9Q+ZPL3MH+j7KAJttjBGiDLZtef4HVVb-A5AK8x1nSOA@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
	<CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
	<CAFdSV9sM1B0YthDRu_mHYFhL7Sd5heGg1H9zW+p-BV4M-ozBWg@mail.gmail.com>
	<CAFdSV9vPoo5JmWrGGL6ipZGxWVc8=idHun49Y6LG61n60GxHZg@mail.gmail.com>
	<CADGJaX_Hv6rmFra8A0EnoPcsCoKJciXT7Usm+XT-4ruikcOqFw@mail.gmail.com>
	<CAFdSV9sFrXwRWPnZedptZ3HxhjiPnXovYM6eADUTcVSd31fzfA@mail.gmail.com>
	<CADGJaX9Q+ZPL3MH+j7KAJttjBGiDLZtef4HVVb-A5AK8x1nSOA@mail.gmail.com>
Message-ID: <CAFm4XO2+5zDNo0xfWrZBPSKFVc7hTLF4VNXBcQmYc+53toqp_Q@mail.gmail.com>

Sounds like a very interesting patch, I agree with you that there's
much potential.
Although Steve from your description it seems like you don't think it can work?

I would expect something among the lines of what Gunnar described to
be feasible: to let the persisters figure out the right numbers when
they are created (once only). But I am not familiar enough with this
code area to get in the details.

About the method you mentioned " $$_hibernate_read_name()" : who
invokes that, and when is the code which invokes that method
generated?
I'm assuming that would be part of the persister, so it means
persister implementations are defined at runtime via bytecode
manipulation?



On 12 November 2015 at 15:18, Gunnar Morling <gunnar at hibernate.org> wrote:
>> You want us to delay enhancement until after the persisters are built.
>
> No, I mean to let enhancement define the attribute ordering and
> initialize persisters with that previously defined order.
>
>> What I suggest longer term is a slight variation...
>
> Yes, that sounds nice.
>
>
> 2015-11-12 16:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> But see that is exactly the problem.  That cannot work.  You want us to
>> delay enhancement until after the persisters are built.  But building the
>> persisters requires access to the Class.  But by that time since we have the
>> Class reference we can no longer enhance it.  It's a chicken-egg problem.
>>
>> What I suggest longer term is a slight variation, where we drive the
>> "indexing" based on the mapping model.  Actually that also will not work as
>> the code is today.  Really what I'd like to do is to leverage the
>> jandex-binding work.  Specifically there we have a Jandex-driven pre-parsing
>> of the domain model (including XML augmentation).  That model would be
>> perfect for this.
>>
>> On Thu, Nov 12, 2015 at 9:00 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>>
>>> It would be a one-time effort during persister initialisation; At that
>>> time a look-up would happen in order to seed persisters with
>>> attributes in the order as determined by the enhancer. Then at
>>> runtime, upon getter/setter invocation, the index values passed from
>>> the enhanced code would be used as is for array index access in
>>> persisters.
>>>
>>> 2015-11-12 15:30 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>> > But I think that just redefines the same problem.  Just that now instead
>>> > of
>>> > String->Integer we need some Integer->Integer resolution.  Not sure that
>>> > really gains us anything.
>>> >
>>> > On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole <steve at hibernate.org>
>>> > wrote:
>>> >>
>>> >> I have no estimate as to how much this would help.  Many of the
>>> >> improvements coming from the performance work have been of the sort
>>> >> that is
>>> >> removing Map lookups; some of them across VERY small (and finite) sets
>>> >> of
>>> >> Map keys.  My concern here is that the Map look up occurs any time an
>>> >> enhanced entity's getter or setter is called, which seems like a
>>> >> potentially
>>> >> bigger performance impact.
>>> >>
>>> >> I'm going to table this for now until the jandex-binding work.  But as
>>> >> part of that work, I think it makes a ton of sense to make sure we
>>> >> develop a
>>> >> strategy for consistent ordering of processing attributes.
>>> >>
>>> >> On Thu, Nov 12, 2015 at 2:36 AM Gunnar Morling <gunnar at hibernate.org>
>>> >> wrote:
>>> >>>
>>> >>> Is there any estimate what would be gained perf-wise by doing this
>>> >>> optimization?
>>> >>>
>>> >>> > First, this obviously is more fragile than relying on names; if the
>>> >>> > order
>>> >>> > changes but the bytecode is not re-enhanced, that could lead to very
>>> >>> > subtle, nasty problems.
>>> >>>
>>> >>> Agreed, but to me it seems acceptable with such optimization having to
>>> >>> be explicitly enabled and the docs of that setting describing this
>>> >>> matter clearly.
>>> >>>
>>> >>> > The other issue is that this requires us to be able to consistently
>>> >>> > be
>>> >>> > able
>>> >>> > to order the attributes.
>>> >>>
>>> >>> Maybe the enhancer could enhance entities with a (static) method
>>> >>> returning the attribute order it works with, or maybe some separate
>>> >>> contract for making this order available. Then at runtime this order
>>> >>> could be fed to persisters et al. for enhanced entities.
>>> >>>
>>> >>> Not sure whether it's doable or how complex it'd be, just throwing out
>>> >>> the idea.
>>> >>>
>>> >>> --Gunnar
>>> >>>
>>> >>>
>>> >>> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>> >>> > As I work on HHH-10267, a thought that keeps coming up in my head is
>>> >>> > that
>>> >>> > it would be great to avoid Map lookups in the enhancement and
>>> >>> > interception
>>> >>> > code.
>>> >>> >
>>> >>> > As an example of what I mean, consider the reader for a String field
>>> >>> > named
>>> >>> > `name` which roughly looks like:
>>> >>> >
>>> >>> > public String $$_hibernate_read_name() {
>>> >>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
>>> >>> > "name",
>>> >>> > this.name );
>>> >>> > }
>>> >>> >
>>> >>> > In the interception code we need to resolve the attribute name
>>> >>> > ("name"
>>> >>> > above) to the pertinent information from the persister,etc.
>>> >>> > Typically
>>> >>> > this
>>> >>> > is a Map lookup; sometimes it is a done by iterating a String[] of
>>> >>> > the
>>> >>> > attribute names.
>>> >>> >
>>> >>> > Ultimately the information is taken from persister and friends,
>>> >>> > which
>>> >>> > means
>>> >>> > that the information is generally already readily consumable via
>>> >>> > array
>>> >>> > access once we have resolved the name to a proper index.  Which got
>>> >>> > me
>>> >>> > thinking it would be great if we could encode the attribute index
>>> >>> > into
>>> >>> > the
>>> >>> > enhanced entity directly.  Going back to the example about.. if we
>>> >>> > knew
>>> >>> > that the "name" attribute was the 4th attribute (index=3) according
>>> >>> > to
>>> >>> > the
>>> >>> > entity persister we could leverage that information for better
>>> >>> > performing
>>> >>> > access to the attribute metadata in the enhanced code and
>>> >>> > interceptor:
>>> >>> >
>>> >>> > public String $$_hibernate_read_name() {
>>> >>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
>>> >>> > 3,
>>> >>> > this.name );
>>> >>> > }
>>> >>> >
>>> >>> > One gotcha - always has to be one devil right ;)  Ok, 2 really...
>>> >>> >
>>> >>> > First, this obviously is more fragile than relying on names; if the
>>> >>> > order
>>> >>> > changes but the bytecode is not re-enhanced, that could lead to very
>>> >>> > subtle, nasty problems.
>>> >>> >
>>> >>> > The other issue is that this requires us to be able to consistently
>>> >>> > be
>>> >>> > able
>>> >>> > to order the attributes.  The Enhancer currently does not rely on
>>> >>> > the
>>> >>> > built
>>> >>> > metadata (org.hibernate.mapping) at all; it parses the entity
>>> >>> > annotations
>>> >>> > (completely annotation specific) on its own.  Given the 2-phase
>>> >>> > break
>>> >>> > down
>>> >>> > in JPA bootstrapping, having Enhancer leverage the built metadata is
>>> >>> > not
>>> >>> > really going to be possible.  Which is unfortunate, because doing so
>>> >>> > would
>>> >>> > be nice for other reasons (like supporting XML mappings for
>>> >>> > enhancement
>>> >>> > as
>>> >>> > well, etc).
>>> >>> >
>>> >>> > That's a lot of information, sorry about that :)
>>> >>> >
>>> >>> > But anyone have thoughts on that?
>>> >>> > _______________________________________________
>>> >>> > hibernate-dev mailing list
>>> >>> > hibernate-dev at lists.jboss.org
>>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Nov 12 21:32:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 02:32:30 +0000
Subject: [hibernate-dev] Bytecode interception and attribute name versus
 attribute index
In-Reply-To: <CAFm4XO2+5zDNo0xfWrZBPSKFVc7hTLF4VNXBcQmYc+53toqp_Q@mail.gmail.com>
References: <CAFdSV9vdHCOExVyqiSP+5Ej32U86Qe7huxLTOoKzmBxOZmEUXg@mail.gmail.com>
	<CADGJaX9Y50H3WJ_JeO2FPxCjkc6x5YOtbNLJfqFygt2nru=Pxw@mail.gmail.com>
	<CAFdSV9sM1B0YthDRu_mHYFhL7Sd5heGg1H9zW+p-BV4M-ozBWg@mail.gmail.com>
	<CAFdSV9vPoo5JmWrGGL6ipZGxWVc8=idHun49Y6LG61n60GxHZg@mail.gmail.com>
	<CADGJaX_Hv6rmFra8A0EnoPcsCoKJciXT7Usm+XT-4ruikcOqFw@mail.gmail.com>
	<CAFdSV9sFrXwRWPnZedptZ3HxhjiPnXovYM6eADUTcVSd31fzfA@mail.gmail.com>
	<CADGJaX9Q+ZPL3MH+j7KAJttjBGiDLZtef4HVVb-A5AK8x1nSOA@mail.gmail.com>
	<CAFm4XO2+5zDNo0xfWrZBPSKFVc7hTLF4VNXBcQmYc+53toqp_Q@mail.gmail.com>
Message-ID: <CAFdSV9tokpX5rC8VAQ3PDst-ikGtnGgmAzDi-=eig_fU0HJN_Q@mail.gmail.com>

On Thu, Nov 12, 2015 at 2:44 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Sounds like a very interesting patch, I agree with you that there's
> much potential.
> Although Steve from your description it seems like you don't think it can
> work?
>

Not sure I follow.  You agree with the potential of the idea I am
proposing, but then point out how I don't think it will work.  I am
confused :)

I guess I think there are different shades of "it works".  I mean heck "it
works" as is already.  I think it works *best* if there is no need to
"translate" from one canonical form to another.  In other words, if
persisters and bytecode enhancements and dirty tracking all understood the
same attribute indexes I think that is by far the optimal situation
performance-wise.


I would expect something among the lines of what Gunnar described to
> be feasible: to let the persisters figure out the right numbers when
> they are created (once only). But I am not familiar enough with this
> code area to get in the details.
>

But that's not what Gunnar proposed.  Its the same thing I asked him to
clarify.  He proposes the "other way"; have the enhancer define the order
and the persisters pick it up from the enhancer.  Could that work?  I
guess.  Really I have no idea, so many unknowns there.


About the method you mentioned " $$_hibernate_read_name()" : who
> invokes that, and when is the code which invokes that method
> generated?
> I'm assuming that would be part of the persister, so it means
> persister implementations are defined at runtime via bytecode
> manipulation?
>

That is a method generated by the enhancer.  Generally speaking it builds a
reader/writer method pair for each "enhanceable" field.  For readers, the
name of the method follows the pattern "$$_hibernate_read_{fieldName}().
The callers of this method are all done via enhancement as well.

From gunnar at hibernate.org  Fri Nov 13 02:47:01 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 13 Nov 2015 08:47:01 +0100
Subject: [hibernate-dev] (no subject)
In-Reply-To: <CAFm4XO3h3ZjtpxAo5KR8V8FVgzG69TkSgKvHFEkzKLmAhgQzyg@mail.gmail.com>
References: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>
	<CAL00eSQ7L8RRwxRpMm5zn0GXTv2dBobrcWU=reCa6cPzK-X6Qw@mail.gmail.com>
	<CAFdSV9uHQDY3x45uT3t5xas=dr_8hh379f+bFr=NtZxpqxHiAg@mail.gmail.com>
	<CAFm4XO3h3ZjtpxAo5KR8V8FVgzG69TkSgKvHFEkzKLmAhgQzyg@mail.gmail.com>
Message-ID: <CADGJaX9jD+gsPiBCdnJrty_L-y8C_H70QwS8ZvOW8Q2s_=Tmrg@mail.gmail.com>

Hey,

How would migration for a user look like?

Do they need to configure a different Ant/Gradle/Maven task? Would 5.1
(assuming the old enhancer has been removed) be able to work with
entities enhanced by the old one, or would a re-build of the app be
required? Would they see a deprecation at all in their IDE (do they
interact with any classes related to enhancement directly at all)?

Just trying to figure how painless migration for users to the new
enhancer would be and whether 5.1 or possibly 6 would be the best time
to remove the old approach.

Thanks,

--Gunnar


2015-11-12 17:46 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> +1
>
> On 12 November 2015 at 16:39, Steve Ebersole <steve at hibernate.org> wrote:
>> https://hibernate.atlassian.net/browse/HHH-10280
>> https://hibernate.atlassian.net/browse/HHH-10281
>>
>> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero <dreborier at gmail.com> wrote:
>>
>>> no objections
>>>
>>> On 11 November 2015 at 17:55, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> I'd like to more formally deprecate the legacy bytecode enhancement
>>>> starting in 5.0.4 and remove it in 5.1.
>>>>
>>>> The new code is superior and already feature compatible back to 5.0 Final.
>>>>
>>>> Any objections?
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From paranoiabla at gmail.com  Fri Nov 13 06:24:54 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 13 Nov 2015 13:24:54 +0200
Subject: [hibernate-dev] Filter activation
Message-ID: <CAKnbemX6T7jVYUB_7Du4cfy10i6Zjchjjz4QsGDw5YhE4-nr3w@mail.gmail.com>

Hello,

here's a 6-year old issue:

https://hibernate.atlassian.net/browse/HHH-3815

That suggests to add another attribute on the @Filter annotation (something
like activeByDefault=true). Can we have your oppinion on it?
-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Fri Nov 13 07:37:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 12:37:16 +0000
Subject: [hibernate-dev] Filter activation
In-Reply-To: <CAKnbemX6T7jVYUB_7Du4cfy10i6Zjchjjz4QsGDw5YhE4-nr3w@mail.gmail.com>
References: <CAKnbemX6T7jVYUB_7Du4cfy10i6Zjchjjz4QsGDw5YhE4-nr3w@mail.gmail.com>
Message-ID: <CAFdSV9uYAn-pECFT0kN=9u9ORmVaK87Tut_bWyDTY9nF1vMRLw@mail.gmail.com>

Well I like this idea (additional flag on @Filter) better the actual
request (multi-valued config setting).  And what about for the
@FilterDef(inition)?

One concern I have is, e.g., getting a collection with a filter enabled,
now disabling a filter and then initializing the collection.  That seems
like the outcome (the initialization will not be filtered) will not be what
was probably intended.  Filters were designed to be disabled by default and
only enable-able; so a change like this will challenge assumptions
throughout the code.

Is this something you are volunteering to work on?


On Fri, Nov 13, 2015 at 5:25 AM Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hello,
>
> here's a 6-year old issue:
>
> https://hibernate.atlassian.net/browse/HHH-3815
>
> That suggests to add another attribute on the @Filter annotation (something
> like activeByDefault=true). Can we have your oppinion on it?
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From paranoiabla at gmail.com  Fri Nov 13 08:15:08 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 13 Nov 2015 15:15:08 +0200
Subject: [hibernate-dev] Filter activation
In-Reply-To: <CAFdSV9uYAn-pECFT0kN=9u9ORmVaK87Tut_bWyDTY9nF1vMRLw@mail.gmail.com>
References: <CAKnbemX6T7jVYUB_7Du4cfy10i6Zjchjjz4QsGDw5YhE4-nr3w@mail.gmail.com>
	<CAFdSV9uYAn-pECFT0kN=9u9ORmVaK87Tut_bWyDTY9nF1vMRLw@mail.gmail.com>
Message-ID: <CAKnbemVjYe6C_+LAwjEmgeKRB_9Jn7-L-RddfFOG69_iZzsXvA@mail.gmail.com>

Hi Steve,

and thanks for your reply. I guess I have mis-understood what the real
proposal was. Also, unfortunately I don't have enough knowledge of
hibernate's internals and like you already mentioned this change will
actually affect a lot of the code. My question was more to see what the
hibernate team thinks about such a proposal, and if there was something
totally against it. Now I know that it is a valid proposal and might be
included one day in the pipeline.

That's ok for me :)



2015-11-13 14:37 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Well I like this idea (additional flag on @Filter) better the actual
> request (multi-valued config setting).  And what about for the
> @FilterDef(inition)?
>
> One concern I have is, e.g., getting a collection with a filter enabled,
> now disabling a filter and then initializing the collection.  That seems
> like the outcome (the initialization will not be filtered) will not be what
> was probably intended.  Filters were designed to be disabled by default and
> only enable-able; so a change like this will challenge assumptions
> throughout the code.
>
> Is this something you are volunteering to work on?
>
>
> On Fri, Nov 13, 2015 at 5:25 AM Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Hello,
>>
>> here's a 6-year old issue:
>>
>> https://hibernate.atlassian.net/browse/HHH-3815
>>
>> That suggests to add another attribute on the @Filter annotation
>> (something
>> like activeByDefault=true). Can we have your oppinion on it?
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Fri Nov 13 09:11:10 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 14:11:10 +0000
Subject: [hibernate-dev] (no subject)
In-Reply-To: <CADGJaX9jD+gsPiBCdnJrty_L-y8C_H70QwS8ZvOW8Q2s_=Tmrg@mail.gmail.com>
References: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>
	<CAL00eSQ7L8RRwxRpMm5zn0GXTv2dBobrcWU=reCa6cPzK-X6Qw@mail.gmail.com>
	<CAFdSV9uHQDY3x45uT3t5xas=dr_8hh379f+bFr=NtZxpqxHiAg@mail.gmail.com>
	<CAFm4XO3h3ZjtpxAo5KR8V8FVgzG69TkSgKvHFEkzKLmAhgQzyg@mail.gmail.com>
	<CADGJaX9jD+gsPiBCdnJrty_L-y8C_H70QwS8ZvOW8Q2s_=Tmrg@mail.gmail.com>
Message-ID: <CAFdSV9tLFNe=RSpfhvd5DBOEpga9vy_f64wXuQjfwmXDZawZxg@mail.gmail.com>

For runtime enhancement there is no change,  we manage it internally.   For
build-time,  legacy enhancement only offered an Ant task (there is a Maven
plugin developed by another group; I will reach out to them about this). At
the moment those folks would need to point to a new Ant task.  We could
potentially simply have the "old Ant task" call the new enhancement.

The new enhancement is supported for build-time via Ant,  Maven and Gradle.
The Maven and Gradle support are new to that new enhancement, so no real
changes there

On Fri, Nov 13, 2015, 1:47 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hey,
>
> How would migration for a user look like?
>
> Do they need to configure a different Ant/Gradle/Maven task? Would 5.1
> (assuming the old enhancer has been removed) be able to work with
> entities enhanced by the old one, or would a re-build of the app be
> required? Would they see a deprecation at all in their IDE (do they
> interact with any classes related to enhancement directly at all)?
>
> Just trying to figure how painless migration for users to the new
> enhancer would be and whether 5.1 or possibly 6 would be the best time
> to remove the old approach.
>
> Thanks,
>
> --Gunnar
>
>
> 2015-11-12 17:46 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> > +1
> >
> > On 12 November 2015 at 16:39, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> https://hibernate.atlassian.net/browse/HHH-10280
> >> https://hibernate.atlassian.net/browse/HHH-10281
> >>
> >> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero <dreborier at gmail.com>
> wrote:
> >>
> >>> no objections
> >>>
> >>> On 11 November 2015 at 17:55, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>
> >>>> I'd like to more formally deprecate the legacy bytecode enhancement
> >>>> starting in 5.0.4 and remove it in 5.1.
> >>>>
> >>>> The new code is superior and already feature compatible back to 5.0
> Final.
> >>>>
> >>>> Any objections?
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Nov 13 09:23:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 14:23:14 +0000
Subject: [hibernate-dev] (no subject)
In-Reply-To: <CAFdSV9tLFNe=RSpfhvd5DBOEpga9vy_f64wXuQjfwmXDZawZxg@mail.gmail.com>
References: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>
	<CAL00eSQ7L8RRwxRpMm5zn0GXTv2dBobrcWU=reCa6cPzK-X6Qw@mail.gmail.com>
	<CAFdSV9uHQDY3x45uT3t5xas=dr_8hh379f+bFr=NtZxpqxHiAg@mail.gmail.com>
	<CAFm4XO3h3ZjtpxAo5KR8V8FVgzG69TkSgKvHFEkzKLmAhgQzyg@mail.gmail.com>
	<CADGJaX9jD+gsPiBCdnJrty_L-y8C_H70QwS8ZvOW8Q2s_=Tmrg@mail.gmail.com>
	<CAFdSV9tLFNe=RSpfhvd5DBOEpga9vy_f64wXuQjfwmXDZawZxg@mail.gmail.com>
Message-ID: <CAFdSV9vBKfTcLSTWEHSf_v-9sSwiwTe-HnegkouDLk6soKPCQg@mail.gmail.com>

Hmm, looks like I might have been mistaken about the "external Hibernate
Maven plugin".  The only one I can find (cannot remember if this is the one
I was thinking of) just does schema export.

On Fri, Nov 13, 2015 at 8:11 AM Steve Ebersole <steve at hibernate.org> wrote:

> For runtime enhancement there is no change,  we manage it internally.
> For build-time,  legacy enhancement only offered an Ant task (there is a
> Maven plugin developed by another group; I will reach out to them about
> this). At the moment those folks would need to point to a new Ant task.  We
> could potentially simply have the "old Ant task" call the new enhancement.
>
> The new enhancement is supported for build-time via Ant,  Maven and
> Gradle. The Maven and Gradle support are new to that new enhancement, so no
> real changes there
>
> On Fri, Nov 13, 2015, 1:47 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Hey,
>>
>> How would migration for a user look like?
>>
>> Do they need to configure a different Ant/Gradle/Maven task? Would 5.1
>> (assuming the old enhancer has been removed) be able to work with
>> entities enhanced by the old one, or would a re-build of the app be
>> required? Would they see a deprecation at all in their IDE (do they
>> interact with any classes related to enhancement directly at all)?
>>
>> Just trying to figure how painless migration for users to the new
>> enhancer would be and whether 5.1 or possibly 6 would be the best time
>> to remove the old approach.
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>> 2015-11-12 17:46 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> > +1
>> >
>> > On 12 November 2015 at 16:39, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >> https://hibernate.atlassian.net/browse/HHH-10280
>> >> https://hibernate.atlassian.net/browse/HHH-10281
>> >>
>> >> On Wed, Nov 11, 2015 at 12:15 PM andrea boriero <dreborier at gmail.com>
>> wrote:
>> >>
>> >>> no objections
>> >>>
>> >>> On 11 November 2015 at 17:55, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>>
>> >>>> I'd like to more formally deprecate the legacy bytecode enhancement
>> >>>> starting in 5.0.4 and remove it in 5.1.
>> >>>>
>> >>>> The new code is superior and already feature compatible back to 5.0
>> Final.
>> >>>>
>> >>>> Any objections?
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>
>> >>>
>> >>>
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Fri Nov 13 09:50:34 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 14:50:34 +0000
Subject: [hibernate-dev] Filter activation
In-Reply-To: <CAKnbemVx9ex0bUWjMrNRYdsZ-d8NCzE1pRW_R7Rd_kF+-aSP_A@mail.gmail.com>
References: <CAKnbemX6T7jVYUB_7Du4cfy10i6Zjchjjz4QsGDw5YhE4-nr3w@mail.gmail.com>
	<CAFdSV9uYAn-pECFT0kN=9u9ORmVaK87Tut_bWyDTY9nF1vMRLw@mail.gmail.com>
	<CAKnbemVjYe6C_+LAwjEmgeKRB_9Jn7-L-RddfFOG69_iZzsXvA@mail.gmail.com>
	<CAFdSV9uKLvXDi+zRU2S8aBCHrE4ai96zcFkX-xqkogrcBQrdtw@mail.gmail.com>
	<CAKnbemVx9ex0bUWjMrNRYdsZ-d8NCzE1pRW_R7Rd_kF+-aSP_A@mail.gmail.com>
Message-ID: <CAFdSV9sHf4xHc+=GsWpcEJiSOaX0fK5N8C4N+MiBr7q_2opHvg@mail.gmail.com>

Let's keep this on-list, please.  Thanks!

The issue, to be clear, is not auto-enabling filters.. No, the
issues/concern is allowing enabled filters to be later disabled.

On Fri, Nov 13, 2015 at 8:34 AM Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hello,
>
> I'm just chatting with the spring-boot guys now and they ask if hibernate
> allows you to specify the filters to activate in a property file. I guess
> they are interested in adding this functionality to spring-boot too.
>
> 2015-11-13 16:13 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Well not sure I said it is valid ;)  There are open questions such as the
>> one I brought up. For a proposal to be valid (as in possible) all such
>> questions need to have some answer.
>>
>> On Fri, Nov 13, 2015, 7:15 AM Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Hi Steve,
>>>
>>> and thanks for your reply. I guess I have mis-understood what the real
>>> proposal was. Also, unfortunately I don't have enough knowledge of
>>> hibernate's internals and like you already mentioned this change will
>>> actually affect a lot of the code. My question was more to see what the
>>> hibernate team thinks about such a proposal, and if there was something
>>> totally against it. Now I know that it is a valid proposal and might be
>>> included one day in the pipeline.
>>>
>>> That's ok for me :)
>>>
>>>
>>>
>>> 2015-11-13 14:37 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>> > Well I like this idea (additional flag on @Filter) better the actual
>>> > request (multi-valued config setting).  And what about for the
>>> > @FilterDef(inition)?
>>> >
>>> > One concern I have is, e.g., getting a collection with a filter
>>> enabled,
>>> > now disabling a filter and then initializing the collection.  That
>>> seems
>>> > like the outcome (the initialization will not be filtered) will not be
>>> what
>>> > was probably intended.  Filters were designed to be disabled by
>>> default and
>>> > only enable-able; so a change like this will challenge assumptions
>>> > throughout the code.
>>> >
>>> > Is this something you are volunteering to work on?
>>> >
>>> >
>>> > On Fri, Nov 13, 2015 at 5:25 AM Petar Tahchiev <paranoiabla at gmail.com>
>>> > wrote:
>>> >
>>> >> Hello,
>>> >>
>>> >> here's a 6-year old issue:
>>> >>
>>> >> https://hibernate.atlassian.net/browse/HHH-3815
>>> >>
>>> >> That suggests to add another attribute on the @Filter annotation
>>> >> (something
>>> >> like activeByDefault=true). Can we have your oppinion on it?
>>> >> --
>>> >> Regards, Petar!
>>> >> Karlovo, Bulgaria.
>>> >> ---
>>> >> Public PGP Key at:
>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> >
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From steve at hibernate.org  Fri Nov 13 10:49:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 15:49:20 +0000
Subject: [hibernate-dev] (no subject)
In-Reply-To: <CADGJaX9jD+gsPiBCdnJrty_L-y8C_H70QwS8ZvOW8Q2s_=Tmrg@mail.gmail.com>
References: <CAFdSV9vyckgY0aEOmvkCqwE57iyqufz-Es=q6h01_k2WcyriMA@mail.gmail.com>
	<CAL00eSQ7L8RRwxRpMm5zn0GXTv2dBobrcWU=reCa6cPzK-X6Qw@mail.gmail.com>
	<CAFdSV9uHQDY3x45uT3t5xas=dr_8hh379f+bFr=NtZxpqxHiAg@mail.gmail.com>
	<CAFm4XO3h3ZjtpxAo5KR8V8FVgzG69TkSgKvHFEkzKLmAhgQzyg@mail.gmail.com>
	<CADGJaX9jD+gsPiBCdnJrty_L-y8C_H70QwS8ZvOW8Q2s_=Tmrg@mail.gmail.com>
Message-ID: <CAFdSV9tsZeA=qj2D=SqzVynAExfFKP=QakmMuVqru8_oRCJkoQ@mail.gmail.com>

Forgot to address this part...

5.1 will include the ability to define lazy attribute fetch groups,  the
development of which requires a lot of changes to the contracts called from
bytecode enhancement.  So rather than retrofit these changes back into the
legacy enhancement code,  I chose to simply remove that legacy code.   I
abhor throwaway code :)


On Fri, Nov 13, 2015, 1:47 AM Gunnar Morling <gunnar at hibernate.org> wrote:



Just trying to figure how painless migration for users to the new
enhancer would be and whether 5.1 or possibly 6 would be the best time
to remove the old approach.

From steve at hibernate.org  Fri Nov 13 12:08:42 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 17:08:42 +0000
Subject: [hibernate-dev] Attribute laziness and caching
Message-ID: <CAFdSV9t_tpnTAnxXG9vKPcmZJ_nmtjyg=W8d_U5peEP6k2ND9w@mail.gmail.com>

In reworking some of the support for bytecode-enhanced laziness, I started
thinking deeper about this idea of partial caching of such entities.

First and foremost, why do we even allow this?  Essentially what happens is
that we allow a user to partially load an entity, and then stick that
partial state into the cache (along with a boolean indicating that the
state is partial).

I guess I can somewhat see the usefulness of this, but what really gets me
confused is how the caching of this data works..  As far as I can tell, we
never re-cache the entity state after the uninitialized portions have been
initialized.  So the cached representation, iiuc, continues to be the
partial representation.  If we continue to allow the partial representation
to be cached, wouldn't we want to update the cache entry with the
initialized portions once they become available?

From steve at hibernate.org  Fri Nov 13 12:15:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 17:15:37 +0000
Subject: [hibernate-dev] Attribute laziness and caching
In-Reply-To: <CAFdSV9t_tpnTAnxXG9vKPcmZJ_nmtjyg=W8d_U5peEP6k2ND9w@mail.gmail.com>
References: <CAFdSV9t_tpnTAnxXG9vKPcmZJ_nmtjyg=W8d_U5peEP6k2ND9w@mail.gmail.com>
Message-ID: <CAFdSV9vm1Z_rcRyk+jzmbPvW9cHsPWch+bkCR3SS6ubv7A3hRA@mail.gmail.com>

Gah, hit send too soon :)

This comes up because I am working on the idea of lazy attribute fetch
groups.  This means that the simple boolean that we used to store is no
longer going to be sufficient.  This ties in with the discussion I started
the other day about using attribute indexes versus attribute names.  As it
stands now, this boolean needs to become a Collection of Strings (attribute
names) which is a big change perf wise.  This affects one of the classes we
have worked hard to minimize in recent months: EntityEntry.


On Fri, Nov 13, 2015 at 11:08 AM Steve Ebersole <steve at hibernate.org> wrote:

> In reworking some of the support for bytecode-enhanced laziness, I started
> thinking deeper about this idea of partial caching of such entities.
>
> First and foremost, why do we even allow this?  Essentially what happens
> is that we allow a user to partially load an entity, and then stick that
> partial state into the cache (along with a boolean indicating that the
> state is partial).
>
> I guess I can somewhat see the usefulness of this, but what really gets me
> confused is how the caching of this data works..  As far as I can tell, we
> never re-cache the entity state after the uninitialized portions have been
> initialized.  So the cached representation, iiuc, continues to be the
> partial representation.  If we continue to allow the partial representation
> to be cached, wouldn't we want to update the cache entry with the
> initialized portions once they become available?
>

From hardy at hibernate.org  Fri Nov 13 16:30:11 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 13 Nov 2015 22:30:11 +0100
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <CAFdSV9tJTUwQoz0K8tqW5_o-5XLqk6CCkJW-DzatwORYW3TjEw@mail.gmail.com>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
	<20151111091428.GA61330@Nineveh.local>
	<CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>
	<20151111142800.GB66533@Nineveh.local>
	<CAFdSV9tJTUwQoz0K8tqW5_o-5XLqk6CCkJW-DzatwORYW3TjEw@mail.gmail.com>
Message-ID: <20151113213011.GB1199@Nineveh.local>

Hi,

On Wed, Nov 11, 2015 at 02:36:13PM +0000, Steve Ebersole wrote:
> I think it makes sense to host these on hibernate.org *after* we figure out
> the version-specific content issues I brought up in Barcelona.

What issues are you talking about. I know you want to link to different 
versions of the documentation from hibernate.org. AFAIK you already started
with it and made some progress.

 
> However, I am kind of torn.  Unless I misunderstand that would mean moving
> the sources out of the upstream projects into the hibernate.org git repo.

Really, why is that? 

> I worry about that leading to even less focus on the docs.

Yeah, I am not a big fan of this idea either. 

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20151113/8547db7b/attachment.bin 

From steve at hibernate.org  Fri Nov 13 16:39:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 21:39:13 +0000
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <20151113213011.GB1199@Nineveh.local>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
	<20151111091428.GA61330@Nineveh.local>
	<CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>
	<20151111142800.GB66533@Nineveh.local>
	<CAFdSV9tJTUwQoz0K8tqW5_o-5XLqk6CCkJW-DzatwORYW3TjEw@mail.gmail.com>
	<20151113213011.GB1199@Nineveh.local>
Message-ID: <CAFdSV9u+SZo256fzgk+RkKWRXxNgJdQ5o=r2yKx9BP_io+fjEw@mail.gmail.com>

On Fri, Nov 13, 2015 at 3:30 PM Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> On Wed, Nov 11, 2015 at 02:36:13PM +0000, Steve Ebersole wrote:
> > I think it makes sense to host these on hibernate.org *after* we figure
> out
> > the version-specific content issues I brought up in Barcelona.
>
> What issues are you talking about. I know you want to link to different
> versions of the documentation from hibernate.org. AFAIK you already
> started
> with it and made some progress.
>

I made progress on version-specific documentation.  But there is really all
kinds of version-specific data-points on the website in addition to
documentation.  Rather than me cobbling it together piecemeal for each data
point, I proposed that we consider an overall strategy for version specific
information on the website.



> > However, I am kind of torn.  Unless I misunderstand that would mean
> moving
> > the sources out of the upstream projects into the hibernate.org git
> repo.
>
> Really, why is that?
>

What's the other option?  Keeping it upstream, building the docs and
somehow pushing those built artifacts into the hibernate.org git repo?  Or
do y'all mean defining a scp/ftp/rsync dir on the actual box?  Because
today we seem to strive for scriptable rebuilding...

From steve at hibernate.org  Fri Nov 13 16:41:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 21:41:33 +0000
Subject: [hibernate-dev] Attribute laziness and caching
In-Reply-To: <CAFdSV9vm1Z_rcRyk+jzmbPvW9cHsPWch+bkCR3SS6ubv7A3hRA@mail.gmail.com>
References: <CAFdSV9t_tpnTAnxXG9vKPcmZJ_nmtjyg=W8d_U5peEP6k2ND9w@mail.gmail.com>
	<CAFdSV9vm1Z_rcRyk+jzmbPvW9cHsPWch+bkCR3SS6ubv7A3hRA@mail.gmail.com>
Message-ID: <CAFdSV9tzfMkHheqpAGnxYwA_oP_Bamg8U1z9qJbz=3pu_qfiSQ@mail.gmail.com>

I worry that this stuff may just not work too.  The tests that tested this
stuff all expected the the involved entities to be build time enhanced
prior to launching the tests.  Which of course they aren't.  So all the
tests for enhancement + caching have effectively been skipped for years.

On Fri, Nov 13, 2015 at 11:15 AM Steve Ebersole <steve at hibernate.org> wrote:

> Gah, hit send too soon :)
>
> This comes up because I am working on the idea of lazy attribute fetch
> groups.  This means that the simple boolean that we used to store is no
> longer going to be sufficient.  This ties in with the discussion I started
> the other day about using attribute indexes versus attribute names.  As it
> stands now, this boolean needs to become a Collection of Strings (attribute
> names) which is a big change perf wise.  This affects one of the classes we
> have worked hard to minimize in recent months: EntityEntry.
>
>
> On Fri, Nov 13, 2015 at 11:08 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> In reworking some of the support for bytecode-enhanced laziness, I
>> started thinking deeper about this idea of partial caching of such
>> entities.
>>
>> First and foremost, why do we even allow this?  Essentially what happens
>> is that we allow a user to partially load an entity, and then stick that
>> partial state into the cache (along with a boolean indicating that the
>> state is partial).
>>
>> I guess I can somewhat see the usefulness of this, but what really gets
>> me confused is how the caching of this data works..  As far as I can tell,
>> we never re-cache the entity state after the uninitialized portions have
>> been initialized.  So the cached representation, iiuc, continues to be the
>> partial representation.  If we continue to allow the partial representation
>> to be cached, wouldn't we want to update the cache entry with the
>> initialized portions once they become available?
>>
>

From steve at hibernate.org  Fri Nov 13 17:14:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 13 Nov 2015 22:14:14 +0000
Subject: [hibernate-dev] Attribute laziness and caching
In-Reply-To: <CAFdSV9tzfMkHheqpAGnxYwA_oP_Bamg8U1z9qJbz=3pu_qfiSQ@mail.gmail.com>
References: <CAFdSV9t_tpnTAnxXG9vKPcmZJ_nmtjyg=W8d_U5peEP6k2ND9w@mail.gmail.com>
	<CAFdSV9vm1Z_rcRyk+jzmbPvW9cHsPWch+bkCR3SS6ubv7A3hRA@mail.gmail.com>
	<CAFdSV9tzfMkHheqpAGnxYwA_oP_Bamg8U1z9qJbz=3pu_qfiSQ@mail.gmail.com>
Message-ID: <CAFdSV9sPoqE3QFUmrZxM1=kTnPns39KNcpSPi3tv6MDMOVRQJw@mail.gmail.com>

So here is what I plan to do since I have heard no replies...

I went ahead and migrated the tests using enhancement+caching to use the
testing runtime enhancement capabilities Luis and I have built.  On top of
that I am going to start adding more detailed assertions.

It does seem to me that even the old behavior is inaccurate from reading
the documentation.  I ported a test specifying include = "non-lazy" for the
caching.  Based on the documentation[1] I fully expected this to only cache
any of the attributes marked as non-lazy.  However it ends up caching all
of the attributes.  Based on this research, I also have no idea why this
boolean is actually written to the CacheEntry; the value is generally
applicable to the persister, so storing it into the cache per-item is
wasteful.

Similarly, I am not really grokking the point in having that value on
EntityEntry either.  I may end up simply completely removing it from there.

[1]
https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html#performance-cache-mapping


On Fri, Nov 13, 2015 at 3:41 PM Steve Ebersole <steve at hibernate.org> wrote:

> I worry that this stuff may just not work too.  The tests that tested this
> stuff all expected the the involved entities to be build time enhanced
> prior to launching the tests.  Which of course they aren't.  So all the
> tests for enhancement + caching have effectively been skipped for years.
>
> On Fri, Nov 13, 2015 at 11:15 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Gah, hit send too soon :)
>>
>> This comes up because I am working on the idea of lazy attribute fetch
>> groups.  This means that the simple boolean that we used to store is no
>> longer going to be sufficient.  This ties in with the discussion I started
>> the other day about using attribute indexes versus attribute names.  As it
>> stands now, this boolean needs to become a Collection of Strings (attribute
>> names) which is a big change perf wise.  This affects one of the classes we
>> have worked hard to minimize in recent months: EntityEntry.
>>
>>
>> On Fri, Nov 13, 2015 at 11:08 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> In reworking some of the support for bytecode-enhanced laziness, I
>>> started thinking deeper about this idea of partial caching of such
>>> entities.
>>>
>>> First and foremost, why do we even allow this?  Essentially what happens
>>> is that we allow a user to partially load an entity, and then stick that
>>> partial state into the cache (along with a boolean indicating that the
>>> state is partial).
>>>
>>> I guess I can somewhat see the usefulness of this, but what really gets
>>> me confused is how the caching of this data works..  As far as I can tell,
>>> we never re-cache the entity state after the uninitialized portions have
>>> been initialized.  So the cached representation, iiuc, continues to be the
>>> partial representation.  If we continue to allow the partial representation
>>> to be cached, wouldn't we want to update the cache entry with the
>>> initialized portions once they become available?
>>>
>>

From mihalcea.vlad at gmail.com  Fri Nov 13 17:22:10 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 14 Nov 2015 00:22:10 +0200
Subject: [hibernate-dev] Sub entities and Multi-version support
Message-ID: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>

I've been seeing many blogs and articles against single-version optimistic
locking, which can cause a transaction to abort even if two concurrent
transactions don't modify the same records.

While dynamic updates can help, many fear to use it because of performance
issues (for very large tables).

I was wondering if we can have something like a SubEntity, which has the
Entity identifier, some properties and a version of its own. A regular
Entity could be mapped to include multiple such SubEntities, just that
those cannot overlap in properties.

Instead of having only one optimistic locking version, we could have one
version for each SubEntity. Whenever a property becomes dirty, Hibernate
will check the SubEntity it belongs to, and it will use that particular
version.

This is a realistic scenario since many business use cases don't
necessarily overlap when updating a certain Entity.

Besides the concurrency control advantage, we could offer the possibility
of fetching less data for a particular use case. Now Hibernate must fetch a
whole Entity in order to modify just some fields (we lose both on
read-performance and on write-performance this way too).

Let me know what you think of this.

Vlad

From dreborier at gmail.com  Sat Nov 14 09:40:56 2015
From: dreborier at gmail.com (andrea boriero)
Date: Sat, 14 Nov 2015 14:40:56 +0000
Subject: [hibernate-dev] Jenkins
Message-ID: <CAL00eSTak5S015uskWDs2k2k+A9md-MESib7wo_4_-XA5Uuszg@mail.gmail.com>

Am I wrong or Jenkins is not building anymore hibernate-orm?

From sanne at hibernate.org  Sat Nov 14 15:27:53 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 14 Nov 2015 20:27:53 +0000
Subject: [hibernate-dev] Jenkins
In-Reply-To: <CAL00eSTak5S015uskWDs2k2k+A9md-MESib7wo_4_-XA5Uuszg@mail.gmail.com>
References: <CAL00eSTak5S015uskWDs2k2k+A9md-MESib7wo_4_-XA5Uuszg@mail.gmail.com>
Message-ID: <CAFm4XO0nMtaerXL0FWCevrogh__870GKWRv+22OmipwvXn3YgQ@mail.gmail.com>

Looks like you were right.

The local clones of the git repository on the build servers were
corrupt; my guess is that happened when we recently run out of disk
space.

I've reconfigured the job to fully wipe its repository and do a full
clone; I'll let it run this way so that it will iteratively fix the
repositories on each slave, let's remember to revert my configuration
change in some days as it's a bit slower to build when it has to do a
full git clone each time.

Thanks,
Sanne

On 14 November 2015 at 14:40, andrea boriero <dreborier at gmail.com> wrote:
> Am I wrong or Jenkins is not building anymore hibernate-orm?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From dreborier at gmail.com  Sat Nov 14 19:48:50 2015
From: dreborier at gmail.com (andrea boriero)
Date: Sun, 15 Nov 2015 00:48:50 +0000
Subject: [hibernate-dev] Jenkins
In-Reply-To: <CAFm4XO0nMtaerXL0FWCevrogh__870GKWRv+22OmipwvXn3YgQ@mail.gmail.com>
References: <CAL00eSTak5S015uskWDs2k2k+A9md-MESib7wo_4_-XA5Uuszg@mail.gmail.com>
	<CAFm4XO0nMtaerXL0FWCevrogh__870GKWRv+22OmipwvXn3YgQ@mail.gmail.com>
Message-ID: <CAL00eSSkT6HbXTdEy8H3_fhNBLGAjB8OWK=eD2p9Ndi9UuAATw@mail.gmail.com>

Thanks Sanne
On 14 Nov 2015 20:28, "Sanne Grinovero" <sanne at hibernate.org> wrote:

> Looks like you were right.
>
> The local clones of the git repository on the build servers were
> corrupt; my guess is that happened when we recently run out of disk
> space.
>
> I've reconfigured the job to fully wipe its repository and do a full
> clone; I'll let it run this way so that it will iteratively fix the
> repositories on each slave, let's remember to revert my configuration
> change in some days as it's a bit slower to build when it has to do a
> full git clone each time.
>
> Thanks,
> Sanne
>
> On 14 November 2015 at 14:40, andrea boriero <dreborier at gmail.com> wrote:
> > Am I wrong or Jenkins is not building anymore hibernate-orm?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Sun Nov 15 15:32:57 2015
From: dreborier at gmail.com (andrea boriero)
Date: Sun, 15 Nov 2015 20:32:57 +0000
Subject: [hibernate-dev] Jenkins
In-Reply-To: <CAL00eSSkT6HbXTdEy8H3_fhNBLGAjB8OWK=eD2p9Ndi9UuAATw@mail.gmail.com>
References: <CAL00eSTak5S015uskWDs2k2k+A9md-MESib7wo_4_-XA5Uuszg@mail.gmail.com>
	<CAFm4XO0nMtaerXL0FWCevrogh__870GKWRv+22OmipwvXn3YgQ@mail.gmail.com>
	<CAL00eSSkT6HbXTdEy8H3_fhNBLGAjB8OWK=eD2p9Ndi9UuAATw@mail.gmail.com>
Message-ID: <CAL00eSRSyhxktuMtSth_PV0Ojpa+w-7iYrRUu5m6R5BbEsjRsw@mail.gmail.com>

it's seems orm-5.0-h2 suffers the same problem.

On 15 November 2015 at 00:48, andrea boriero <dreborier at gmail.com> wrote:

> Thanks Sanne
> On 14 Nov 2015 20:28, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>
>> Looks like you were right.
>>
>> The local clones of the git repository on the build servers were
>> corrupt; my guess is that happened when we recently run out of disk
>> space.
>>
>> I've reconfigured the job to fully wipe its repository and do a full
>> clone; I'll let it run this way so that it will iteratively fix the
>> repositories on each slave, let's remember to revert my configuration
>> change in some days as it's a bit slower to build when it has to do a
>> full git clone each time.
>>
>> Thanks,
>> Sanne
>>
>> On 14 November 2015 at 14:40, andrea boriero <dreborier at gmail.com> wrote:
>> > Am I wrong or Jenkins is not building anymore hibernate-orm?
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Mon Nov 16 05:08:17 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 16 Nov 2015 10:08:17 +0000
Subject: [hibernate-dev] Jenkins
In-Reply-To: <CAL00eSRSyhxktuMtSth_PV0Ojpa+w-7iYrRUu5m6R5BbEsjRsw@mail.gmail.com>
References: <CAL00eSTak5S015uskWDs2k2k+A9md-MESib7wo_4_-XA5Uuszg@mail.gmail.com>
	<CAFm4XO0nMtaerXL0FWCevrogh__870GKWRv+22OmipwvXn3YgQ@mail.gmail.com>
	<CAL00eSSkT6HbXTdEy8H3_fhNBLGAjB8OWK=eD2p9Ndi9UuAATw@mail.gmail.com>
	<CAL00eSRSyhxktuMtSth_PV0Ojpa+w-7iYrRUu5m6R5BbEsjRsw@mail.gmail.com>
Message-ID: <CAFm4XO0JfK7n-9bU-mofY67RN=uNXnYYJqX6uxbm0R_LY61RkQ@mail.gmail.com>

I don't think orm-5.0-h2 ever worked? The configuration was wrong: it
wasn't fetching the branch 5.0 from the git repository, but it was
configured to monitor that branch for changes.
I changed it now, let me know if it doesn't work.

Sanne

On 15 November 2015 at 20:32, andrea boriero <dreborier at gmail.com> wrote:
> it's seems orm-5.0-h2 suffers the same problem.
>
> On 15 November 2015 at 00:48, andrea boriero <dreborier at gmail.com> wrote:
>>
>> Thanks Sanne
>>
>> On 14 Nov 2015 20:28, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>>>
>>> Looks like you were right.
>>>
>>> The local clones of the git repository on the build servers were
>>> corrupt; my guess is that happened when we recently run out of disk
>>> space.
>>>
>>> I've reconfigured the job to fully wipe its repository and do a full
>>> clone; I'll let it run this way so that it will iteratively fix the
>>> repositories on each slave, let's remember to revert my configuration
>>> change in some days as it's a bit slower to build when it has to do a
>>> full git clone each time.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> On 14 November 2015 at 14:40, andrea boriero <dreborier at gmail.com> wrote:
>>> > Am I wrong or Jenkins is not building anymore hibernate-orm?
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From dreborier at gmail.com  Mon Nov 16 05:25:22 2015
From: dreborier at gmail.com (andrea boriero)
Date: Mon, 16 Nov 2015 10:25:22 +0000
Subject: [hibernate-dev] Jenkins
In-Reply-To: <CAFm4XO0JfK7n-9bU-mofY67RN=uNXnYYJqX6uxbm0R_LY61RkQ@mail.gmail.com>
References: <CAL00eSTak5S015uskWDs2k2k+A9md-MESib7wo_4_-XA5Uuszg@mail.gmail.com>
	<CAFm4XO0nMtaerXL0FWCevrogh__870GKWRv+22OmipwvXn3YgQ@mail.gmail.com>
	<CAL00eSSkT6HbXTdEy8H3_fhNBLGAjB8OWK=eD2p9Ndi9UuAATw@mail.gmail.com>
	<CAL00eSRSyhxktuMtSth_PV0Ojpa+w-7iYrRUu5m6R5BbEsjRsw@mail.gmail.com>
	<CAFm4XO0JfK7n-9bU-mofY67RN=uNXnYYJqX6uxbm0R_LY61RkQ@mail.gmail.com>
Message-ID: <CAL00eSStTta8g7psw73TsAeovoGab4bwbhnKOzcyODKZV4iQcQ@mail.gmail.com>

Thanks Sanne

On 16 November 2015 at 10:08, Sanne Grinovero <sanne at hibernate.org> wrote:

> I don't think orm-5.0-h2 ever worked? The configuration was wrong: it
> wasn't fetching the branch 5.0 from the git repository, but it was
> configured to monitor that branch for changes.
> I changed it now, let me know if it doesn't work.
>
> Sanne
>
> On 15 November 2015 at 20:32, andrea boriero <dreborier at gmail.com> wrote:
> > it's seems orm-5.0-h2 suffers the same problem.
> >
> > On 15 November 2015 at 00:48, andrea boriero <dreborier at gmail.com>
> wrote:
> >>
> >> Thanks Sanne
> >>
> >> On 14 Nov 2015 20:28, "Sanne Grinovero" <sanne at hibernate.org> wrote:
> >>>
> >>> Looks like you were right.
> >>>
> >>> The local clones of the git repository on the build servers were
> >>> corrupt; my guess is that happened when we recently run out of disk
> >>> space.
> >>>
> >>> I've reconfigured the job to fully wipe its repository and do a full
> >>> clone; I'll let it run this way so that it will iteratively fix the
> >>> repositories on each slave, let's remember to revert my configuration
> >>> change in some days as it's a bit slower to build when it has to do a
> >>> full git clone each time.
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>> On 14 November 2015 at 14:40, andrea boriero <dreborier at gmail.com>
> wrote:
> >>> > Am I wrong or Jenkins is not building anymore hibernate-orm?
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From steve at hibernate.org  Mon Nov 16 16:09:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 16 Nov 2015 21:09:52 +0000
Subject: [hibernate-dev] Lazy attribute loading group support
Message-ID: <CAFdSV9th85pStP5NHvXDo8-gVf1vep35LoNEk4tfQff7FH--wQ@mail.gmail.com>

Regarding HHH-10267...

5.1 will include a new feature allowing users to specify groups for
(bytecode enhanced) lazy attribute loading.  In the original support
accessing one of these lazy attributes forced them all to be loaded[1].
For example...

@Entity
public class Company {
    ...
    @Basic( fetch = FetchType.LAZY )
    private String taxIdNumber;
    @Lob
    @Basic( fetch = FetchType.LAZY )
    private Blob logo;
}

Once an application accessed any of the lazy attributes, they were all
loaded/initialized.  So accessing `getTaxIdNumber()` would force `logo` to
be fetched as well.  The new feature here is the ability to segment
attributes into different groups for lazy loading:

@Entity
public class Company {
    ...
    @Basic( fetch = FetchType.LAZY )
    private String taxIdNumber;
    @Lob
    @Basic( fetch = FetchType.LAZY )
    @LazyGroup( "lobs" )
    private Blob logo;
}

`@LazyGroup( "lobs" )` designates that `logo` is part of a specific fetch
group.  Now, when the application accesses `getTaxIdNumber()`, `logo` is no
longer fetched at the same time.

P.S. A related question is this idea of
`@LazyToOne(LazyToOneOption.NO_PROXY)`.  At the moment that is still needed
for "legacy reasons".  The underlying reason is that we don't (didn't) know
when the to-one container is enhanced, so we rely on the user telling us.
I'd like to plan on dropping the requirement for the user to tell us this.
If they are using enhancement I am 99% certain they want NO_PROXY so it
seems redundant to make them tell us.  Unless I am missing some use case.
Any thoughts?

[1] Technically the legacy bytecode enhancement treated collections
differently than other attribute types in this regard.  The new enhancement
does the same as the default.

From mihalcea.vlad at gmail.com  Mon Nov 16 16:51:13 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 16 Nov 2015 23:51:13 +0200
Subject: [hibernate-dev] Lazy attribute loading group support
In-Reply-To: <CAFdSV9th85pStP5NHvXDo8-gVf1vep35LoNEk4tfQff7FH--wQ@mail.gmail.com>
References: <CAFdSV9th85pStP5NHvXDo8-gVf1vep35LoNEk4tfQff7FH--wQ@mail.gmail.com>
Message-ID: <CA+gWKMBh96vCBf=6HnhRfuRLh8ox=vFwoVhFQxz5xkPXs92Otw@mail.gmail.com>

Hi,

Sounds like a good idea. I like the lazy fetch profiles. Previously it
required the Blob to be moved to a different table.

Vlad



Vlad

On Mon, Nov 16, 2015 at 11:09 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> Regarding HHH-10267...
>
> 5.1 will include a new feature allowing users to specify groups for
> (bytecode enhanced) lazy attribute loading.  In the original support
> accessing one of these lazy attributes forced them all to be loaded[1].
> For example...
>
> @Entity
> public class Company {
>     ...
>     @Basic( fetch = FetchType.LAZY )
>     private String taxIdNumber;
>     @Lob
>     @Basic( fetch = FetchType.LAZY )
>     private Blob logo;
> }
>
> Once an application accessed any of the lazy attributes, they were all
> loaded/initialized.  So accessing `getTaxIdNumber()` would force `logo` to
> be fetched as well.  The new feature here is the ability to segment
> attributes into different groups for lazy loading:
>
> @Entity
> public class Company {
>     ...
>     @Basic( fetch = FetchType.LAZY )
>     private String taxIdNumber;
>     @Lob
>     @Basic( fetch = FetchType.LAZY )
>     @LazyGroup( "lobs" )
>     private Blob logo;
> }
>
> `@LazyGroup( "lobs" )` designates that `logo` is part of a specific fetch
> group.  Now, when the application accesses `getTaxIdNumber()`, `logo` is no
> longer fetched at the same time.
>
> P.S. A related question is this idea of
> `@LazyToOne(LazyToOneOption.NO_PROXY)`.  At the moment that is still needed
> for "legacy reasons".  The underlying reason is that we don't (didn't) know
> when the to-one container is enhanced, so we rely on the user telling us.
> I'd like to plan on dropping the requirement for the user to tell us this.
> If they are using enhancement I am 99% certain they want NO_PROXY so it
> seems redundant to make them tell us.  Unless I am missing some use case.
> Any thoughts?
>
> [1] Technically the legacy bytecode enhancement treated collections
> differently than other attribute types in this regard.  The new enhancement
> does the same as the default.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Wed Nov 18 01:32:25 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 17 Nov 2015 22:32:25 -0800
Subject: [hibernate-dev] hibernate-core and hibernate-infinspan failures
Message-ID: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>

I noticed that there are 39 test failures for hibernate-core in 5.0 branch.
[1]

Also, I enabled hibernate-infinispan tests on 5.0 and there are 8 failures.
[2] Some of the failures are due to IllegalLifecycleStateException, which
doesn't look like the intermittent failures I've seen in the past.

I suppose the hibernate-infinispan tests could be failing for the same
reason the hibernate-core tests are failing. I figured I'm mention it in
case they are unrelated.

[1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
[2] http://pastebin.com/LHppW5jm

From mihalcea.vlad at gmail.com  Wed Nov 18 02:45:31 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 18 Nov 2015 09:45:31 +0200
Subject: [hibernate-dev] Why does Hibernate has aggressive connection
	releasing for JTA
Message-ID: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>

Hi,

Does anyone remember why does Hibernate support aggressive connection
releasing?
I've never found this requirement in either JTA or JDBC spec.
Was it something required by the Java EE application server?

Vlad

From gunnar at hibernate.org  Wed Nov 18 03:45:07 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 18 Nov 2015 09:45:07 +0100
Subject: [hibernate-dev] Lazy attribute loading group support
In-Reply-To: <CA+gWKMBh96vCBf=6HnhRfuRLh8ox=vFwoVhFQxz5xkPXs92Otw@mail.gmail.com>
References: <CAFdSV9th85pStP5NHvXDo8-gVf1vep35LoNEk4tfQff7FH--wQ@mail.gmail.com>
	<CA+gWKMBh96vCBf=6HnhRfuRLh8ox=vFwoVhFQxz5xkPXs92Otw@mail.gmail.com>
Message-ID: <CADGJaX98LOjtP3Pz8nOOmykAF409XKK=g4EJKMb3v8Cavnr2tA@mail.gmail.com>

+1 it's a useful thing.

Instead of using Strings to identify loading groups, would it be
better to use class literals? It'd prevent wrong loads due to typos
and would help to identify the attributes of one group e.g. in the
IDE. But it would add the overhead for defining the groups:

    public interface Lobs /* extends LoadGroup (maybe have some marker
interface?) */ {}

And then:

    @LazyGroup( Lobs.class )
    private Blob logo;

I am not sure whether it'd pull its weight, but am keen to learn what
others think.

Cheers,

--Gunnar



2015-11-16 22:51 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> Hi,
>
> Sounds like a good idea. I like the lazy fetch profiles. Previously it
> required the Blob to be moved to a different table.
>
> Vlad
>
>
>
> Vlad
>
> On Mon, Nov 16, 2015 at 11:09 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Regarding HHH-10267...
>>
>> 5.1 will include a new feature allowing users to specify groups for
>> (bytecode enhanced) lazy attribute loading.  In the original support
>> accessing one of these lazy attributes forced them all to be loaded[1].
>> For example...
>>
>> @Entity
>> public class Company {
>>     ...
>>     @Basic( fetch = FetchType.LAZY )
>>     private String taxIdNumber;
>>     @Lob
>>     @Basic( fetch = FetchType.LAZY )
>>     private Blob logo;
>> }
>>
>> Once an application accessed any of the lazy attributes, they were all
>> loaded/initialized.  So accessing `getTaxIdNumber()` would force `logo` to
>> be fetched as well.  The new feature here is the ability to segment
>> attributes into different groups for lazy loading:
>>
>> @Entity
>> public class Company {
>>     ...
>>     @Basic( fetch = FetchType.LAZY )
>>     private String taxIdNumber;
>>     @Lob
>>     @Basic( fetch = FetchType.LAZY )
>>     @LazyGroup( "lobs" )
>>     private Blob logo;
>> }
>>
>> `@LazyGroup( "lobs" )` designates that `logo` is part of a specific fetch
>> group.  Now, when the application accesses `getTaxIdNumber()`, `logo` is no
>> longer fetched at the same time.
>>
>> P.S. A related question is this idea of
>> `@LazyToOne(LazyToOneOption.NO_PROXY)`.  At the moment that is still needed
>> for "legacy reasons".  The underlying reason is that we don't (didn't) know
>> when the to-one container is enhanced, so we rely on the user telling us.
>> I'd like to plan on dropping the requirement for the user to tell us this.
>> If they are using enhancement I am 99% certain they want NO_PROXY so it
>> seems redundant to make them tell us.  Unless I am missing some use case.
>> Any thoughts?
>>
>> [1] Technically the legacy bytecode enhancement treated collections
>> differently than other attribute types in this regard.  The new enhancement
>> does the same as the default.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From ks at error.be  Wed Nov 18 05:20:52 2015
From: ks at error.be (Koen Serneels)
Date: Wed, 18 Nov 2015 11:20:52 +0100
Subject: [hibernate-dev] Accessing metadata when SF is build the legacy way
Message-ID: <008d01d121ea$cdce2c80$696a8580$@error.be>

Hi. I'm digging up an older question
(https://www.mail-archive.com/hibernate-dev at lists.jboss.org/msg12872.html)I
asked about modifying mapping metadata in H5. In short; I want to change the
mutability flag of mappings programmatically.

 

Using H4 there was a method called "getClassMappings" on
org.hibernate.cfg.Configuration. This method no longer exist in H5.

>From the previous answers/docu I understand that when using the new way of
building the SF one can interact with the metadata after building it using
the MetadataBuilder (but  before building the SF) this would solve my
problem as I would be able to access the metadata at that point and change
the behavior.

 

Unfortunately, when using H5 through Spring4, the SF is built as what the
manual describes the "legacy way"; Spring's LocalSessionFactoryBean uses
Spring's LocalSessionFactoryBuilder which on its turn extends
org.hibernate.cfg.Configuration and calls  org.hibernate.cfg.Configuration
#buildSessionFactory to build the SF.

Both metadata and sessionfactory are build in that single method leaving no
hook to modify the metadata.

 

At this point I don't see a normal/clean way in accessing the metadata
before the SF is build using the legacy way. So, am I missing something? Is
there maybe another way to access the metadata?

 

Thanks

 

Koen

 


From johara at redhat.com  Wed Nov 18 05:26:27 2015
From: johara at redhat.com (John O'Hara)
Date: Wed, 18 Nov 2015 10:26:27 +0000
Subject: [hibernate-dev] hibernate-core and hibernate-infinspan failures
In-Reply-To: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>
References: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>
Message-ID: <564C5253.5080102@redhat.com>

Gail,

Tests on hibernate-core in 5.0 branch are failing due to 
https://github.com/hibernate/hibernate-orm/commit/7633d2fce540a979fc0eb5b229023c815b6c5528
lazyPropertiesAreUnfetched should be passed after 
disableVersionIncrement.  I will make the change for steve to pull in

John

On 18/11/15 06:32, Gail Badner wrote:
> I noticed that there are 39 test failures for hibernate-core in 5.0 branch.
> [1]
>
> Also, I enabled hibernate-infinispan tests on 5.0 and there are 8 failures.
> [2] Some of the failures are due to IllegalLifecycleStateException, which
> doesn't look like the intermittent failures I've seen in the past.
>
> I suppose the hibernate-infinispan tests could be failing for the same
> reason the hibernate-core tests are failing. I figured I'm mention it in
> case they are unrelated.
>
> [1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
> [2] http://pastebin.com/LHppW5jm
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From gunnar at hibernate.org  Wed Nov 18 05:52:40 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 18 Nov 2015 11:52:40 +0100
Subject: [hibernate-dev] Sub entities and Multi-version support
In-Reply-To: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>
References: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>
Message-ID: <CADGJaX_nxN49KhNYPuDGAiYLcHPSKWRJodg6YVP8XmJRnGCqfg@mail.gmail.com>

Hi Vlad,

2015-11-13 23:22 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> I've been seeing many blogs and articles against single-version optimistic
> locking, which can cause a transaction to abort even if two concurrent
> transactions don't modify the same records.

Could you give a pointer to such blog? If a TX rolls back upon
modification of different opt-locked *records* that seems like a bug
to me.

But from the remainder of your mail it appears you mean different
*properties* of one record? So IIUC, you suggest to support a specific
opt-lock field for each secondary table of an entity. Personally I'd
say different entities should be used to model this. Could you give an
example where you think this would be helpful?

Regarding your performance concerns, lazy attributes (and the load
groups Steve discussed recently) may be helpful.

All in all, to me it seems a bit you may have attributes within one
entity which may better be modelled by several entities, each only
accessed when actually needed.

--Gunnar




>
> While dynamic updates can help, many fear to use it because of performance
> issues (for very large tables).
>
> I was wondering if we can have something like a SubEntity, which has the
> Entity identifier, some properties and a version of its own. A regular
> Entity could be mapped to include multiple such SubEntities, just that
> those cannot overlap in properties.
>
> Instead of having only one optimistic locking version, we could have one
> version for each SubEntity. Whenever a property becomes dirty, Hibernate
> will check the SubEntity it belongs to, and it will use that particular
> version.
>
> This is a realistic scenario since many business use cases don't
> necessarily overlap when updating a certain Entity.
>
> Besides the concurrency control advantage, we could offer the possibility
> of fetching less data for a particular use case. Now Hibernate must fetch a
> whole Entity in order to modify just some fields (we lose both on
> read-performance and on write-performance this way too).
>
> Let me know what you think of this.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Wed Nov 18 07:08:03 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 18 Nov 2015 14:08:03 +0200
Subject: [hibernate-dev] Sub entities and Multi-version support
In-Reply-To: <CADGJaX_nxN49KhNYPuDGAiYLcHPSKWRJodg6YVP8XmJRnGCqfg@mail.gmail.com>
References: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>
	<CADGJaX_nxN49KhNYPuDGAiYLcHPSKWRJodg6YVP8XmJRnGCqfg@mail.gmail.com>
Message-ID: <CA+gWKMCn=gvH_evs-9DPjYOohuito=MXYgVhUNxQaskio4aVeA@mail.gmail.com>

Hi Gunnar,

The best article on this subject is this one:

http://www.anyware.co.uk/2005/2012/11/12/the-false-optimism-of-gorm-and-hibernate/

Another one which captures the same idea, although it's not as good as the
former one:

https://dzone.com/articles/jpa-in-case-of-asynchronous-processing

I proposed an application-level solution to this problem myself:


http://vladmihalcea.com/2014/11/10/an-entity-modelling-strategy-for-scaling-optimistic-locking/

which splits a table based on write-concerns, to minimize the chance of
getting write conflicts.

I was not implying secondary tables, I was thinking of grouping properties
towards a specific version so that the same table can have multiple
versions.

Sometimes, the optimistic locking failure can be a "false positive". If I
have a Product entity with a description and a price, one transaction
updating the price could fail because someone has changed a type in the
description.
The current optimistic locking approach is an all-or-nothing solution,
because if only one trivial field changes, all concurrent transactions
using the previous versions will fail.

So yes, we can achieve this by splitting the table in multiple sub-tables,
but to fetch the whole entity back, we would have to join all sub-tables,
which has a performance impact on its own.

Vlad

On Wed, Nov 18, 2015 at 12:52 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi Vlad,
>
> 2015-11-13 23:22 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> > I've been seeing many blogs and articles against single-version
> optimistic
> > locking, which can cause a transaction to abort even if two concurrent
> > transactions don't modify the same records.
>
> Could you give a pointer to such blog? If a TX rolls back upon
> modification of different opt-locked *records* that seems like a bug
> to me.
>
> But from the remainder of your mail it appears you mean different
> *properties* of one record? So IIUC, you suggest to support a specific
> opt-lock field for each secondary table of an entity. Personally I'd
> say different entities should be used to model this. Could you give an
> example where you think this would be helpful?
>
> Regarding your performance concerns, lazy attributes (and the load
> groups Steve discussed recently) may be helpful.
>
> All in all, to me it seems a bit you may have attributes within one
> entity which may better be modelled by several entities, each only
> accessed when actually needed.
>
> --Gunnar
>
>
>
>
> >
> > While dynamic updates can help, many fear to use it because of
> performance
> > issues (for very large tables).
> >
> > I was wondering if we can have something like a SubEntity, which has the
> > Entity identifier, some properties and a version of its own. A regular
> > Entity could be mapped to include multiple such SubEntities, just that
> > those cannot overlap in properties.
> >
> > Instead of having only one optimistic locking version, we could have one
> > version for each SubEntity. Whenever a property becomes dirty, Hibernate
> > will check the SubEntity it belongs to, and it will use that particular
> > version.
> >
> > This is a realistic scenario since many business use cases don't
> > necessarily overlap when updating a certain Entity.
> >
> > Besides the concurrency control advantage, we could offer the possibility
> > of fetching less data for a particular use case. Now Hibernate must
> fetch a
> > whole Entity in order to modify just some fields (we lose both on
> > read-performance and on write-performance this way too).
> >
> > Let me know what you think of this.
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov 18 09:05:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 14:05:50 +0000
Subject: [hibernate-dev] Why does Hibernate has aggressive connection
 releasing for JTA
In-Reply-To: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>
References: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>
Message-ID: <CAFdSV9sTCH8cNGgxU5zPnTsdZbrp53kb+kDASvYotGFGMex5+g@mail.gmail.com>

It was to work around certain containers (not just EE containers) that
implement "resource containment" checks.  The Hibernate Session defers
getting a JDBC Connection until it actually needs one, which can lead to
cases like the following where 2 beans share a Session/EM:

Bean1: get Session, but don't use it yet in way that needs Connection
Bean1: call Bean2...
Bean2: get Session, do some work forcing Session to obtain Connection
Bean2: return (Session still hold Connection)

At this point, these containers see this as a "leaked" Connection because
the handle was not released by the end of the scope in which it was
obtained.  Hence, aggressive releasing.  My contention at the time was that
a ConnectionAcquisitionMode would have been better/cleaner.  I still feel
that way, and hope to still come back and add that; so much so in fact that
the enum already exists[1] :).

[1] org.hibernate.ConnectionAcquisitionMode

On Wed, Nov 18, 2015 at 1:45 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> Does anyone remember why does Hibernate support aggressive connection
> releasing?
> I've never found this requirement in either JTA or JDBC spec.
> Was it something required by the Java EE application server?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov 18 09:06:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 14:06:21 +0000
Subject: [hibernate-dev] Lazy attribute loading group support
In-Reply-To: <CADGJaX98LOjtP3Pz8nOOmykAF409XKK=g4EJKMb3v8Cavnr2tA@mail.gmail.com>
References: <CAFdSV9th85pStP5NHvXDo8-gVf1vep35LoNEk4tfQff7FH--wQ@mail.gmail.com>
	<CA+gWKMBh96vCBf=6HnhRfuRLh8ox=vFwoVhFQxz5xkPXs92Otw@mail.gmail.com>
	<CADGJaX98LOjtP3Pz8nOOmykAF409XKK=g4EJKMb3v8Cavnr2tA@mail.gmail.com>
Message-ID: <CAFdSV9v7rD2Eqjc22+ZUBVJHvnuB60Ms9deS4Veiff78P-ckPg@mail.gmail.com>

Personally I find that to be too much work to set up.


On Wed, Nov 18, 2015 at 2:52 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> +1 it's a useful thing.
>
> Instead of using Strings to identify loading groups, would it be
> better to use class literals? It'd prevent wrong loads due to typos
> and would help to identify the attributes of one group e.g. in the
> IDE. But it would add the overhead for defining the groups:
>
>     public interface Lobs /* extends LoadGroup (maybe have some marker
> interface?) */ {}
>
> And then:
>
>     @LazyGroup( Lobs.class )
>     private Blob logo;
>
> I am not sure whether it'd pull its weight, but am keen to learn what
> others think.
>
> Cheers,
>
> --Gunnar
>
>
>
> 2015-11-16 22:51 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> > Hi,
> >
> > Sounds like a good idea. I like the lazy fetch profiles. Previously it
> > required the Blob to be moved to a different table.
> >
> > Vlad
> >
> >
> >
> > Vlad
> >
> > On Mon, Nov 16, 2015 at 11:09 PM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> Regarding HHH-10267...
> >>
> >> 5.1 will include a new feature allowing users to specify groups for
> >> (bytecode enhanced) lazy attribute loading.  In the original support
> >> accessing one of these lazy attributes forced them all to be loaded[1].
> >> For example...
> >>
> >> @Entity
> >> public class Company {
> >>     ...
> >>     @Basic( fetch = FetchType.LAZY )
> >>     private String taxIdNumber;
> >>     @Lob
> >>     @Basic( fetch = FetchType.LAZY )
> >>     private Blob logo;
> >> }
> >>
> >> Once an application accessed any of the lazy attributes, they were all
> >> loaded/initialized.  So accessing `getTaxIdNumber()` would force `logo`
> to
> >> be fetched as well.  The new feature here is the ability to segment
> >> attributes into different groups for lazy loading:
> >>
> >> @Entity
> >> public class Company {
> >>     ...
> >>     @Basic( fetch = FetchType.LAZY )
> >>     private String taxIdNumber;
> >>     @Lob
> >>     @Basic( fetch = FetchType.LAZY )
> >>     @LazyGroup( "lobs" )
> >>     private Blob logo;
> >> }
> >>
> >> `@LazyGroup( "lobs" )` designates that `logo` is part of a specific
> fetch
> >> group.  Now, when the application accesses `getTaxIdNumber()`, `logo`
> is no
> >> longer fetched at the same time.
> >>
> >> P.S. A related question is this idea of
> >> `@LazyToOne(LazyToOneOption.NO_PROXY)`.  At the moment that is still
> needed
> >> for "legacy reasons".  The underlying reason is that we don't (didn't)
> know
> >> when the to-one container is enhanced, so we rely on the user telling
> us.
> >> I'd like to plan on dropping the requirement for the user to tell us
> this.
> >> If they are using enhancement I am 99% certain they want NO_PROXY so it
> >> seems redundant to make them tell us.  Unless I am missing some use
> case.
> >> Any thoughts?
> >>
> >> [1] Technically the legacy bytecode enhancement treated collections
> >> differently than other attribute types in this regard.  The new
> enhancement
> >> does the same as the default.
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov 18 09:19:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 14:19:00 +0000
Subject: [hibernate-dev] Accessing metadata when SF is build the legacy
	way
In-Reply-To: <008d01d121ea$cdce2c80$696a8580$@error.be>
References: <008d01d121ea$cdce2c80$696a8580$@error.be>
Message-ID: <CAFdSV9vWOV9=oVUAnj4zAQ+6pExk53p7Ni_n1PDhGJO079tM4A@mail.gmail.com>

This is a list for the discussion of HIbernate development.  Your question
is not a Hibernate development discussion, its a user question.  In the
future, please refrain from asking usage questions on a developer list.
Thanks.

I will address this one quickly though...

Unfortunately that method is not coming back.  The reasoning has been
discussed many times, many places so I won't get back into all the details
again.

As for Spring and their decision to keep using the legacy bootstrapping
approach...  Well that was their call.  I would assume their logic had more
to do with easiness on their side since the same calls work on 4.x and 5.x
more-or-less in terms of a straight-line building of the SF.  I have to
assume because I was never asked about it,. nor were any other Hibernate
developers as far as I know.  And you're right... it is unfortunate because
that decision probably affects a lot of people.

All that said, as discussed in the the documents I linked in the original
response the legacy bootstrap (Configuration) simply delegates to the new
bootstrapping APIs.  The new APIs have a lot of hook points, many of which
can be automatically discovered (java.util.ServiceLoader).  For
example, org.hibernate.boot.spi.MetadataContributor is one that would best
suit your needs.

On Wed, Nov 18, 2015 at 4:21 AM Koen Serneels <ks at error.be> wrote:

> Hi. I'm digging up an older question
> (
> https://www.mail-archive.com/hibernate-dev at lists.jboss.org/msg12872.html)I
> asked about modifying mapping metadata in H5. In short; I want to change
> the
> mutability flag of mappings programmatically.
>
>
>
> Using H4 there was a method called "getClassMappings" on
> org.hibernate.cfg.Configuration. This method no longer exist in H5.
>
> >From the previous answers/docu I understand that when using the new way of
> building the SF one can interact with the metadata after building it using
> the MetadataBuilder (but  before building the SF) this would solve my
> problem as I would be able to access the metadata at that point and change
> the behavior.
>
>
>
> Unfortunately, when using H5 through Spring4, the SF is built as what the
> manual describes the "legacy way"; Spring's LocalSessionFactoryBean uses
> Spring's LocalSessionFactoryBuilder which on its turn extends
> org.hibernate.cfg.Configuration and calls  org.hibernate.cfg.Configuration
> #buildSessionFactory to build the SF.
>




> Both metadata and sessionfactory are build in that single method leaving no
> hook to modify the metadata.
>
>
>
> At this point I don't see a normal/clean way in accessing the metadata
> before the SF is build using the legacy way. So, am I missing something? Is
> there maybe another way to access the metadata?
>
>
>
> Thanks
>
>
>
> Koen
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov 18 09:20:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 14:20:37 +0000
Subject: [hibernate-dev] hibernate-core and hibernate-infinspan failures
In-Reply-To: <564C5253.5080102@redhat.com>
References: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>
	<564C5253.5080102@redhat.com>
Message-ID: <CAFdSV9vNQzfReg6jnJ6U2P-=PE0K6jLm-3GL=RASuvJ5uj8ifg@mail.gmail.com>

As John pointed out the 39 are from attempting to apply a perf patch to
5.0.

The hibernate-infinispan tests have been an ongoing issue, which is why I
disabled them.  In fact I think after 5.0.4 we ought to stop accepting
patches against hibernate-infinispan until the tests are fixed.

On Wed, Nov 18, 2015 at 4:27 AM John O'Hara <johara at redhat.com> wrote:

> Gail,
>
> Tests on hibernate-core in 5.0 branch are failing due to
>
> https://github.com/hibernate/hibernate-orm/commit/7633d2fce540a979fc0eb5b229023c815b6c5528
> lazyPropertiesAreUnfetched should be passed after
> disableVersionIncrement.  I will make the change for steve to pull in
>
> John
>
> On 18/11/15 06:32, Gail Badner wrote:
> > I noticed that there are 39 test failures for hibernate-core in 5.0
> branch.
> > [1]
> >
> > Also, I enabled hibernate-infinispan tests on 5.0 and there are 8
> failures.
> > [2] Some of the failures are due to IllegalLifecycleStateException, which
> > doesn't look like the intermittent failures I've seen in the past.
> >
> > I suppose the hibernate-infinispan tests could be failing for the same
> > reason the hibernate-core tests are failing. I figured I'm mention it in
> > case they are unrelated.
> >
> > [1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
> > [2] http://pastebin.com/LHppW5jm
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> John O'Hara
> johara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA) and Michael O'Neill (Ireland).
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov 18 09:33:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 14:33:23 +0000
Subject: [hibernate-dev] Sub entities and Multi-version support
In-Reply-To: <CA+gWKMCn=gvH_evs-9DPjYOohuito=MXYgVhUNxQaskio4aVeA@mail.gmail.com>
References: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>
	<CADGJaX_nxN49KhNYPuDGAiYLcHPSKWRJodg6YVP8XmJRnGCqfg@mail.gmail.com>
	<CA+gWKMCn=gvH_evs-9DPjYOohuito=MXYgVhUNxQaskio4aVeA@mail.gmail.com>
Message-ID: <CAFdSV9sqT8s4odYmx17hP5+KBt2vL-1U5_yoS+KC7N68CJOtGQ@mail.gmail.com>

On Wed, Nov 18, 2015 at 6:08 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi Gunnar,
>
> The best article on this subject is this one:
>
>
> http://www.anyware.co.uk/2005/2012/11/12/the-false-optimism-of-gorm-and-hibernate/


To be honest I stop reading after I read things like

<quote>
This is because Hibernate caches the SQL generated for UPDATE statements
such that it updates all the columns. One can only imagine how expensive
this is in network and DB terms with large objects.
</quote>

Essentially he is upset about Hibernate's choice of a default value for a
particular setting, ignoring that:
1) hey, its actually a setting that you can actually change
2) the performance impact of the flip side is far bigger in cases when you
don't need it.

The rest of this section goes on to talk about flipping dynamic update to
be enabled by default and that probably circumventing the need for
optimistic locking at all.  Talk about "overly optimistic"!  Not to mention
he completely misses the fact that Hibernate can couple dynamic update with
a custom optimistic locking strategy that uses the changed fields in the
optimistic lock check (rather than a dedicated version column).

So like I said, I stopped reading about there...

@Version is simplistic.  It's kind of designed that way.  And then
Hibernate builds other strategies on top of that.  So if your situation
does not "fit the simplistic case", why are you trying to use the
"simplistic solution"?

Assuming your thought aligns with those in this article, why does
@DynamicUpdate + @OptimisticLocking(DIRTY) not work?

From steve at hibernate.org  Wed Nov 18 09:34:46 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 14:34:46 +0000
Subject: [hibernate-dev] hibernate-core and hibernate-infinspan failures
In-Reply-To: <564C5253.5080102@redhat.com>
References: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>
	<564C5253.5080102@redhat.com>
Message-ID: <CAFdSV9sCH+fNUhyHec5YrVSk=DxZe+uWbVmk33f-F4rN8PkwZg@mail.gmail.com>

So if I understand correctly, I just inverted the 2 booleans arguments when
trying to apply this to 5.0?


On Wed, Nov 18, 2015 at 4:27 AM John O'Hara <johara at redhat.com> wrote:

> Gail,
>
> Tests on hibernate-core in 5.0 branch are failing due to
>
> https://github.com/hibernate/hibernate-orm/commit/7633d2fce540a979fc0eb5b229023c815b6c5528
> lazyPropertiesAreUnfetched should be passed after
> disableVersionIncrement.  I will make the change for steve to pull in
>
> John
>
> On 18/11/15 06:32, Gail Badner wrote:
> > I noticed that there are 39 test failures for hibernate-core in 5.0
> branch.
> > [1]
> >
> > Also, I enabled hibernate-infinispan tests on 5.0 and there are 8
> failures.
> > [2] Some of the failures are due to IllegalLifecycleStateException, which
> > doesn't look like the intermittent failures I've seen in the past.
> >
> > I suppose the hibernate-infinispan tests could be failing for the same
> > reason the hibernate-core tests are failing. I figured I'm mention it in
> > case they are unrelated.
> >
> > [1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
> > [2] http://pastebin.com/LHppW5jm
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> John O'Hara
> johara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA) and Michael O'Neill (Ireland).
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From johara at redhat.com  Wed Nov 18 09:42:43 2015
From: johara at redhat.com (John O'Hara)
Date: Wed, 18 Nov 2015 14:42:43 +0000
Subject: [hibernate-dev] hibernate-core and hibernate-infinspan failures
In-Reply-To: <CAFdSV9sCH+fNUhyHec5YrVSk=DxZe+uWbVmk33f-F4rN8PkwZg@mail.gmail.com>
References: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>
	<564C5253.5080102@redhat.com>
	<CAFdSV9sCH+fNUhyHec5YrVSk=DxZe+uWbVmk33f-F4rN8PkwZg@mail.gmail.com>
Message-ID: <564C8E63.1060302@redhat.com>

Yes, you can see the difference between the call to createEntityEntry 
for the Mutable and Immutable case here: 
https://github.com/hibernate/hibernate-orm/blob/7633d2fce540a979fc0eb5b229023c815b6c5528/hibernate-core/src/main/java/org/hibernate/engine/internal/StatefulPersistenceContext.java#L505

In the tests where lazyPropertiesAreUnfetched is set to true, the 
disableVersionIncrement was inadvertently being set to true for 
MutableEntitEntry's and therefore the version was not being incremented. 
That was causing the tests to fail as the Entity version was not 
incremented during the tests

On 18/11/15 14:34, Steve Ebersole wrote:
> So if I understand correctly, I just inverted the 2 booleans arguments when
> trying to apply this to 5.0?
>
>
> On Wed, Nov 18, 2015 at 4:27 AM John O'Hara <johara at redhat.com> wrote:
>
>> Gail,
>>
>> Tests on hibernate-core in 5.0 branch are failing due to
>>
>> https://github.com/hibernate/hibernate-orm/commit/7633d2fce540a979fc0eb5b229023c815b6c5528
>> lazyPropertiesAreUnfetched should be passed after
>> disableVersionIncrement.  I will make the change for steve to pull in
>>
>> John
>>
>> On 18/11/15 06:32, Gail Badner wrote:
>>> I noticed that there are 39 test failures for hibernate-core in 5.0
>> branch.
>>> [1]
>>>
>>> Also, I enabled hibernate-infinispan tests on 5.0 and there are 8
>> failures.
>>> [2] Some of the failures are due to IllegalLifecycleStateException, which
>>> doesn't look like the intermittent failures I've seen in the past.
>>>
>>> I suppose the hibernate-infinispan tests could be failing for the same
>>> reason the hibernate-core tests are failing. I figured I'm mention it in
>>> case they are unrelated.
>>>
>>> [1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
>>> [2] http://pastebin.com/LHppW5jm
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> --
>> John O'Hara
>> johara at redhat.com
>>
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903
>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
>> (USA) and Michael O'Neill (Ireland).
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From rvansa at redhat.com  Wed Nov 18 10:08:11 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 18 Nov 2015 16:08:11 +0100
Subject: [hibernate-dev] hibernate-core and hibernate-infinspan failures
In-Reply-To: <CAFdSV9vNQzfReg6jnJ6U2P-=PE0K6jLm-3GL=RASuvJ5uj8ifg@mail.gmail.com>
References: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>
	<564C5253.5080102@redhat.com>
	<CAFdSV9vNQzfReg6jnJ6U2P-=PE0K6jLm-3GL=RASuvJ5uj8ifg@mail.gmail.com>
Message-ID: <564C945B.8020901@redhat.com>

I've been trying to fix the testsuite, and I managed to get rid of some 
of the issues, but without 100% success - I can't reproduce certain 
problems with logs on and I can't fix them without knowing what's going 
on (without the logs). So, honestly, I've given up for a while. ATM 
about every 20th testsuite run in CI (without logs) fails. The most 
annoying thing is 'initial state transfer timed out' - something that 
was there for quite some time.

If anyone (Galder?) is willing to look into it, please feel free to play 
with [1].

Radim

[1] ci.hibernate.org/job/hibernate-orm-infinispan-testsuite-rvansa

On 11/18/2015 03:20 PM, Steve Ebersole wrote:
> As John pointed out the 39 are from attempting to apply a perf patch to
> 5.0.
>
> The hibernate-infinispan tests have been an ongoing issue, which is why I
> disabled them.  In fact I think after 5.0.4 we ought to stop accepting
> patches against hibernate-infinispan until the tests are fixed.
>
> On Wed, Nov 18, 2015 at 4:27 AM John O'Hara <johara at redhat.com> wrote:
>
>> Gail,
>>
>> Tests on hibernate-core in 5.0 branch are failing due to
>>
>> https://github.com/hibernate/hibernate-orm/commit/7633d2fce540a979fc0eb5b229023c815b6c5528
>> lazyPropertiesAreUnfetched should be passed after
>> disableVersionIncrement.  I will make the change for steve to pull in
>>
>> John
>>
>> On 18/11/15 06:32, Gail Badner wrote:
>>> I noticed that there are 39 test failures for hibernate-core in 5.0
>> branch.
>>> [1]
>>>
>>> Also, I enabled hibernate-infinispan tests on 5.0 and there are 8
>> failures.
>>> [2] Some of the failures are due to IllegalLifecycleStateException, which
>>> doesn't look like the intermittent failures I've seen in the past.
>>>
>>> I suppose the hibernate-infinispan tests could be failing for the same
>>> reason the hibernate-core tests are failing. I figured I'm mention it in
>>> case they are unrelated.
>>>
>>> [1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
>>> [2] http://pastebin.com/LHppW5jm
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> --
>> John O'Hara
>> johara at redhat.com
>>
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903
>> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
>> (USA) and Michael O'Neill (Ireland).
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From mihalcea.vlad at gmail.com  Wed Nov 18 10:14:32 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 18 Nov 2015 17:14:32 +0200
Subject: [hibernate-dev] Sub entities and Multi-version support
In-Reply-To: <CAFdSV9sqT8s4odYmx17hP5+KBt2vL-1U5_yoS+KC7N68CJOtGQ@mail.gmail.com>
References: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>
	<CADGJaX_nxN49KhNYPuDGAiYLcHPSKWRJodg6YVP8XmJRnGCqfg@mail.gmail.com>
	<CA+gWKMCn=gvH_evs-9DPjYOohuito=MXYgVhUNxQaskio4aVeA@mail.gmail.com>
	<CAFdSV9sqT8s4odYmx17hP5+KBt2vL-1U5_yoS+KC7N68CJOtGQ@mail.gmail.com>
Message-ID: <CA+gWKMBiR2heRsaMbwisowFOLv8QKC2Xp5MPubBB_gY0qjTkHQ@mail.gmail.com>

I agree that @Version is simplistic, but then we only have one choice, the
@DynamicUpdate solution.

Now, the @DynamicUpdate has one major drawback: it doesn't work with
detached entities.
In the following article I detailed how it can lead to "lost updates":

http://vladmihalcea.com/2014/12/08/the-downside-of-version-less-optimistic-locking/

Only the @Version optimistic locking works with detached objects because
the version is embedded in the entity itself.
The @DynamicUpdate works only for entities that are fetched and modified
within the same Session, but once you detach the entity, the previous state
is lost and so you won't be able to use the previous state in the WHERE
clause so to detect an entity change. One workaround is the EXTENDED
PersistenceContext, but that's usually associated o Java EE (Spring doesn't
really offer it right out of the box).

Does it make sense?

Vlad

On Wed, Nov 18, 2015 at 4:33 PM, Steve Ebersole <steve at hibernate.org> wrote:

>
> On Wed, Nov 18, 2015 at 6:08 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi Gunnar,
>>
>> The best article on this subject is this one:
>>
>>
>> http://www.anyware.co.uk/2005/2012/11/12/the-false-optimism-of-gorm-and-hibernate/
>
>
> To be honest I stop reading after I read things like
>
> <quote>
> This is because Hibernate caches the SQL generated for UPDATE statements
> such that it updates all the columns. One can only imagine how expensive
> this is in network and DB terms with large objects.
> </quote>
>
> Essentially he is upset about Hibernate's choice of a default value for a
> particular setting, ignoring that:
> 1) hey, its actually a setting that you can actually change
> 2) the performance impact of the flip side is far bigger in cases when you
> don't need it.
>
> The rest of this section goes on to talk about flipping dynamic update to
> be enabled by default and that probably circumventing the need for
> optimistic locking at all.  Talk about "overly optimistic"!  Not to mention
> he completely misses the fact that Hibernate can couple dynamic update with
> a custom optimistic locking strategy that uses the changed fields in the
> optimistic lock check (rather than a dedicated version column).
>
> So like I said, I stopped reading about there...
>
> @Version is simplistic.  It's kind of designed that way.  And then
> Hibernate builds other strategies on top of that.  So if your situation
> does not "fit the simplistic case", why are you trying to use the
> "simplistic solution"?
>
> Assuming your thought aligns with those in this article, why does
> @DynamicUpdate + @OptimisticLocking(DIRTY) not work?
>

From steve at hibernate.org  Wed Nov 18 10:15:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 15:15:26 +0000
Subject: [hibernate-dev] hibernate-core and hibernate-infinspan failures
In-Reply-To: <564C945B.8020901@redhat.com>
References: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>
	<564C5253.5080102@redhat.com>
	<CAFdSV9vNQzfReg6jnJ6U2P-=PE0K6jLm-3GL=RASuvJ5uj8ifg@mail.gmail.com>
	<564C945B.8020901@redhat.com>
Message-ID: <CAFdSV9sowJ=QXqGcQGY2nNUyqWfT6VuMrpk4RHMKbeF2m=vapg@mail.gmail.com>

Yes, the inconsistent/transient nature is the most frustrating part.

On Wed, Nov 18, 2015 at 9:08 AM Radim Vansa <rvansa at redhat.com> wrote:

> I've been trying to fix the testsuite, and I managed to get rid of some
> of the issues, but without 100% success - I can't reproduce certain
> problems with logs on and I can't fix them without knowing what's going
> on (without the logs). So, honestly, I've given up for a while. ATM
> about every 20th testsuite run in CI (without logs) fails. The most
> annoying thing is 'initial state transfer timed out' - something that
> was there for quite some time.
>
> If anyone (Galder?) is willing to look into it, please feel free to play
> with [1].
>
> Radim
>
> [1] ci.hibernate.org/job/hibernate-orm-infinispan-testsuite-rvansa
>
> On 11/18/2015 03:20 PM, Steve Ebersole wrote:
> > As John pointed out the 39 are from attempting to apply a perf patch to
> > 5.0.
> >
> > The hibernate-infinispan tests have been an ongoing issue, which is why I
> > disabled them.  In fact I think after 5.0.4 we ought to stop accepting
> > patches against hibernate-infinispan until the tests are fixed.
> >
> > On Wed, Nov 18, 2015 at 4:27 AM John O'Hara <johara at redhat.com> wrote:
> >
> >> Gail,
> >>
> >> Tests on hibernate-core in 5.0 branch are failing due to
> >>
> >>
> https://github.com/hibernate/hibernate-orm/commit/7633d2fce540a979fc0eb5b229023c815b6c5528
> >> lazyPropertiesAreUnfetched should be passed after
> >> disableVersionIncrement.  I will make the change for steve to pull in
> >>
> >> John
> >>
> >> On 18/11/15 06:32, Gail Badner wrote:
> >>> I noticed that there are 39 test failures for hibernate-core in 5.0
> >> branch.
> >>> [1]
> >>>
> >>> Also, I enabled hibernate-infinispan tests on 5.0 and there are 8
> >> failures.
> >>> [2] Some of the failures are due to IllegalLifecycleStateException,
> which
> >>> doesn't look like the intermittent failures I've seen in the past.
> >>>
> >>> I suppose the hibernate-infinispan tests could be failing for the same
> >>> reason the hibernate-core tests are failing. I figured I'm mention it
> in
> >>> case they are unrelated.
> >>>
> >>> [1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
> >>> [2] http://pastebin.com/LHppW5jm
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >> --
> >> John O'Hara
> >> johara at redhat.com
> >>
> >> JBoss, by Red Hat
> >> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> >> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> >> Registered in UK and Wales under Company Registration No. 3798903
> >> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> >> (USA) and Michael O'Neill (Ireland).
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Nov 18 10:18:26 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 18 Nov 2015 17:18:26 +0200
Subject: [hibernate-dev] Why does Hibernate has aggressive connection
 releasing for JTA
In-Reply-To: <CAFdSV9sTCH8cNGgxU5zPnTsdZbrp53kb+kDASvYotGFGMex5+g@mail.gmail.com>
References: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>
	<CAFdSV9sTCH8cNGgxU5zPnTsdZbrp53kb+kDASvYotGFGMex5+g@mail.gmail.com>
Message-ID: <CA+gWKMBgNUhxfFBv5QvH8H4Bprtizk1Uj_z=OLPMemTTFBM7qA@mail.gmail.com>

Thanks for the explanation. I found a discussion from 2006 where you
explained this behavior:

http://lists.jboss.org/pipermail/hibernate-dev/2006-December/000903.html

I am currently testing the AFTER_TRANSACTION release mode with Spring and
Bitronix and I think it can give some performance gain over AFTER_STATEMENT.
I'll keep you posted with the final results.

Do you think we should update the docs to explain that this is rather
required by Java EE containers, and it might be fine with stand-along JTA
transaction managers?

Vlad



On Wed, Nov 18, 2015 at 4:05 PM, Steve Ebersole <steve at hibernate.org> wrote:

> It was to work around certain containers (not just EE containers) that
> implement "resource containment" checks.  The Hibernate Session defers
> getting a JDBC Connection until it actually needs one, which can lead to
> cases like the following where 2 beans share a Session/EM:
>
> Bean1: get Session, but don't use it yet in way that needs Connection
> Bean1: call Bean2...
> Bean2: get Session, do some work forcing Session to obtain Connection
> Bean2: return (Session still hold Connection)
>
> At this point, these containers see this as a "leaked" Connection because
> the handle was not released by the end of the scope in which it was
> obtained.  Hence, aggressive releasing.  My contention at the time was that
> a ConnectionAcquisitionMode would have been better/cleaner.  I still feel
> that way, and hope to still come back and add that; so much so in fact that
> the enum already exists[1] :).
>
> [1] org.hibernate.ConnectionAcquisitionMode
>
> On Wed, Nov 18, 2015 at 1:45 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> Does anyone remember why does Hibernate support aggressive connection
>> releasing?
>> I've never found this requirement in either JTA or JDBC spec.
>> Was it something required by the Java EE application server?
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Nov 18 10:26:56 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 15:26:56 +0000
Subject: [hibernate-dev] hibernate-core and hibernate-infinspan failures
In-Reply-To: <564C8E63.1060302@redhat.com>
References: <CAFDzhiTiiafPs+y+WLs9Y4Hn2fRz20gu+dGjVc-FuNJJEMbAzw@mail.gmail.com>
	<564C5253.5080102@redhat.com>
	<CAFdSV9sCH+fNUhyHec5YrVSk=DxZe+uWbVmk33f-F4rN8PkwZg@mail.gmail.com>
	<564C8E63.1060302@redhat.com>
Message-ID: <CAFdSV9vvEaq53mB3wR5X0zs6mxoT5DtvKeyNSAeRxNXJUutkBw@mail.gmail.com>

http://ci.hibernate.org/job/hibernate-orm-5.0-h2/13/changes

Fixed.  Sorry, I inadvertently inverted those I guess as I cherry-picked
that PR to 5.0.  Master does not use that boolean anymore.

On Wed, Nov 18, 2015 at 8:43 AM John O'Hara <johara at redhat.com> wrote:

> Yes, you can see the difference between the call to createEntityEntry
> for the Mutable and Immutable case here:
>
> https://github.com/hibernate/hibernate-orm/blob/7633d2fce540a979fc0eb5b229023c815b6c5528/hibernate-core/src/main/java/org/hibernate/engine/internal/StatefulPersistenceContext.java#L505
>
> In the tests where lazyPropertiesAreUnfetched is set to true, the
> disableVersionIncrement was inadvertently being set to true for
> MutableEntitEntry's and therefore the version was not being incremented.
> That was causing the tests to fail as the Entity version was not
> incremented during the tests
>
> On 18/11/15 14:34, Steve Ebersole wrote:
> > So if I understand correctly, I just inverted the 2 booleans arguments
> when
> > trying to apply this to 5.0?
> >
> >
> > On Wed, Nov 18, 2015 at 4:27 AM John O'Hara <johara at redhat.com> wrote:
> >
> >> Gail,
> >>
> >> Tests on hibernate-core in 5.0 branch are failing due to
> >>
> >>
> https://github.com/hibernate/hibernate-orm/commit/7633d2fce540a979fc0eb5b229023c815b6c5528
> >> lazyPropertiesAreUnfetched should be passed after
> >> disableVersionIncrement.  I will make the change for steve to pull in
> >>
> >> John
> >>
> >> On 18/11/15 06:32, Gail Badner wrote:
> >>> I noticed that there are 39 test failures for hibernate-core in 5.0
> >> branch.
> >>> [1]
> >>>
> >>> Also, I enabled hibernate-infinispan tests on 5.0 and there are 8
> >> failures.
> >>> [2] Some of the failures are due to IllegalLifecycleStateException,
> which
> >>> doesn't look like the intermittent failures I've seen in the past.
> >>>
> >>> I suppose the hibernate-infinispan tests could be failing for the same
> >>> reason the hibernate-core tests are failing. I figured I'm mention it
> in
> >>> case they are unrelated.
> >>>
> >>> [1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
> >>> [2] http://pastebin.com/LHppW5jm
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >> --
> >> John O'Hara
> >> johara at redhat.com
> >>
> >> JBoss, by Red Hat
> >> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> >> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> >> Registered in UK and Wales under Company Registration No. 3798903
> >> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> >> (USA) and Michael O'Neill (Ireland).
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> John O'Hara
> johara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA) and Michael O'Neill (Ireland).
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Nov 18 10:49:56 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 15:49:56 +0000
Subject: [hibernate-dev] Why does Hibernate has aggressive connection
 releasing for JTA
In-Reply-To: <CA+gWKMBgNUhxfFBv5QvH8H4Bprtizk1Uj_z=OLPMemTTFBM7qA@mail.gmail.com>
References: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>
	<CAFdSV9sTCH8cNGgxU5zPnTsdZbrp53kb+kDASvYotGFGMex5+g@mail.gmail.com>
	<CA+gWKMBgNUhxfFBv5QvH8H4Bprtizk1Uj_z=OLPMemTTFBM7qA@mail.gmail.com>
Message-ID: <CAFdSV9teCuCUd0bzXnJ8Ya+aU6oADdmcCA6mCeo8fbO08q9orw@mail.gmail.com>

Yes, I think that's a good idea.  I also think working
on ConnectionAcquisitionMode is the best option.  The fact that Hibernate
delays getting the Connection is so generally not useful.


On Wed, Nov 18, 2015 at 9:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Thanks for the explanation. I found a discussion from 2006 where you
> explained this behavior:
>
> http://lists.jboss.org/pipermail/hibernate-dev/2006-December/000903.html
>
> I am currently testing the AFTER_TRANSACTION release mode with Spring and
> Bitronix and I think it can give some performance gain over AFTER_STATEMENT.
> I'll keep you posted with the final results.
>
> Do you think we should update the docs to explain that this is rather
> required by Java EE containers, and it might be fine with stand-along JTA
> transaction managers?
>
> Vlad
>
>
>
> On Wed, Nov 18, 2015 at 4:05 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> It was to work around certain containers (not just EE containers) that
>> implement "resource containment" checks.  The Hibernate Session defers
>> getting a JDBC Connection until it actually needs one, which can lead to
>> cases like the following where 2 beans share a Session/EM:
>>
>> Bean1: get Session, but don't use it yet in way that needs Connection
>> Bean1: call Bean2...
>> Bean2: get Session, do some work forcing Session to obtain Connection
>> Bean2: return (Session still hold Connection)
>>
>> At this point, these containers see this as a "leaked" Connection because
>> the handle was not released by the end of the scope in which it was
>> obtained.  Hence, aggressive releasing.  My contention at the time was that
>> a ConnectionAcquisitionMode would have been better/cleaner.  I still feel
>> that way, and hope to still come back and add that; so much so in fact that
>> the enum already exists[1] :).
>>
>> [1] org.hibernate.ConnectionAcquisitionMode
>>
>> On Wed, Nov 18, 2015 at 1:45 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Does anyone remember why does Hibernate support aggressive connection
>>> releasing?
>>> I've never found this requirement in either JTA or JDBC spec.
>>> Was it something required by the Java EE application server?
>>>
>>> Vlad
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From steve at hibernate.org  Wed Nov 18 11:59:12 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 16:59:12 +0000
Subject: [hibernate-dev] Sub entities and Multi-version support
In-Reply-To: <CA+gWKMBiR2heRsaMbwisowFOLv8QKC2Xp5MPubBB_gY0qjTkHQ@mail.gmail.com>
References: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>
	<CADGJaX_nxN49KhNYPuDGAiYLcHPSKWRJodg6YVP8XmJRnGCqfg@mail.gmail.com>
	<CA+gWKMCn=gvH_evs-9DPjYOohuito=MXYgVhUNxQaskio4aVeA@mail.gmail.com>
	<CAFdSV9sqT8s4odYmx17hP5+KBt2vL-1U5_yoS+KC7N68CJOtGQ@mail.gmail.com>
	<CA+gWKMBiR2heRsaMbwisowFOLv8QKC2Xp5MPubBB_gY0qjTkHQ@mail.gmail.com>
Message-ID: <CAFdSV9siAJZ_eW7Er3kkoX-T0e=jWBPKWcczKYoFW=kj57dRBw@mail.gmail.com>

That is kind of true for real re-attachment. But realize that merge() e.g.
is not actually a re-attachment API.  merge() first loads the state and
then applies the detached state over that managed state.   So
@DynamicUpdate does still work.

And even with real re-attachment via update() the same can be achieved with
@SelectBeforeUpdate.

Personally I am inclined to vote -1 to this at the moment,  but I am
interested to hear what others might think.

On Wed, Nov 18, 2015, 10:17 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I agree that @Version is simplistic, but then we only have one choice, the
> @DynamicUpdate solution.
>
> Now, the @DynamicUpdate has one major drawback: it doesn't work with
> detached entities.
> In the following article I detailed how it can lead to "lost updates":
>
>
> http://vladmihalcea.com/2014/12/08/the-downside-of-version-less-optimistic-locking/
>
> Only the @Version optimistic locking works with detached objects because
> the version is embedded in the entity itself.
> The @DynamicUpdate works only for entities that are fetched and modified
> within the same Session, but once you detach the entity, the previous state
> is lost and so you won't be able to use the previous state in the WHERE
> clause so to detect an entity change. One workaround is the EXTENDED
> PersistenceContext, but that's usually associated o Java EE (Spring doesn't
> really offer it right out of the box).
>
> Does it make sense?
>
> Vlad
>
> On Wed, Nov 18, 2015 at 4:33 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>>
>> On Wed, Nov 18, 2015 at 6:08 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi Gunnar,
>>>
>>> The best article on this subject is this one:
>>>
>>>
>>> http://www.anyware.co.uk/2005/2012/11/12/the-false-optimism-of-gorm-and-hibernate/
>>
>>
>> To be honest I stop reading after I read things like
>>
>> <quote>
>> This is because Hibernate caches the SQL generated for UPDATE statements
>> such that it updates all the columns. One can only imagine how expensive
>> this is in network and DB terms with large objects.
>> </quote>
>>
>> Essentially he is upset about Hibernate's choice of a default value for a
>> particular setting, ignoring that:
>> 1) hey, its actually a setting that you can actually change
>> 2) the performance impact of the flip side is far bigger in cases when
>> you don't need it.
>>
>> The rest of this section goes on to talk about flipping dynamic update to
>> be enabled by default and that probably circumventing the need for
>> optimistic locking at all.  Talk about "overly optimistic"!  Not to mention
>> he completely misses the fact that Hibernate can couple dynamic update with
>> a custom optimistic locking strategy that uses the changed fields in the
>> optimistic lock check (rather than a dedicated version column).
>>
>> So like I said, I stopped reading about there...
>>
>> @Version is simplistic.  It's kind of designed that way.  And then
>> Hibernate builds other strategies on top of that.  So if your situation
>> does not "fit the simplistic case", why are you trying to use the
>> "simplistic solution"?
>>
>> Assuming your thought aligns with those in this article, why does
>> @DynamicUpdate + @OptimisticLocking(DIRTY) not work?
>>
>
>

From steve at hibernate.org  Wed Nov 18 13:24:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 18:24:06 +0000
Subject: [hibernate-dev] Starting 5.0.4 release
Message-ID: <CAFdSV9vYMAoS5rhjAUuUAv_vQztxn0xg_BGyKETS7TKrDpxdKw@mail.gmail.com>

Per $subject

From steve at hibernate.org  Wed Nov 18 15:12:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 18 Nov 2015 20:12:27 +0000
Subject: [hibernate-dev] Fourth bug-fix release of Hibernate ORM 5.0
Message-ID: <CAFdSV9tYhKtxbEcMsgR6rLAOMUKMELnFVCsW8=FsmopVgwT-+A@mail.gmail.com>

http://in.relation.to/2015/11/18/hibernate-orm-504-final-release/

From mihalcea.vlad at gmail.com  Thu Nov 19 00:35:13 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 19 Nov 2015 07:35:13 +0200
Subject: [hibernate-dev] Fwd:  Sub entities and Multi-version support
In-Reply-To: <CA+gWKMDmeCy9xEJ=JkUuja5z_S4Z5qNzG4YT2adrJFOfX_cdYw@mail.gmail.com>
References: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>
	<CADGJaX_nxN49KhNYPuDGAiYLcHPSKWRJodg6YVP8XmJRnGCqfg@mail.gmail.com>
	<CA+gWKMCn=gvH_evs-9DPjYOohuito=MXYgVhUNxQaskio4aVeA@mail.gmail.com>
	<CAFdSV9sqT8s4odYmx17hP5+KBt2vL-1U5_yoS+KC7N68CJOtGQ@mail.gmail.com>
	<CA+gWKMBiR2heRsaMbwisowFOLv8QKC2Xp5MPubBB_gY0qjTkHQ@mail.gmail.com>
	<CAFdSV9siAJZ_eW7Er3kkoX-T0e=jWBPKWcczKYoFW=kj57dRBw@mail.gmail.com>
	<CA+gWKMDmeCy9xEJ=JkUuja5z_S4Z5qNzG4YT2adrJFOfX_cdYw@mail.gmail.com>
Message-ID: <CA+gWKMCThJnykX7iW-=oRexkz6WC9QH5N43-D9DH-MjpT5yctw@mail.gmail.com>

Actually both merge() and update() can still cause a "write skew"
phenomena, especially when using dynamic updates + OptimisticLockType DIRTY
<https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotations/OptimisticLockType.html#DIRTY>
or OptimisticLockType ALL
<https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotations/OptimisticLockType.html#ALL>
.
Let's say I have an imaginary Product entity with a price and a quantity,
and when I "purchase" it, I simply decrease its quantity (considering that
the price doesn't change).

1. I load the Product with price 9.99 and quantity 5 in one Hibernate
Session/HTTP request
2. Bob comes and changes the price to 14.99
3. I go back to place my order and I will use merge(). I will load the
Product with the new price but I won't be aware of that, and I'll issue a
dynamic-update on quantity, by simply decreasing.

This anomaly can currently be fixed by @Version implementation. Neither
DIRTY or ALL can detect this anomaly, because they relate to the latest
state (Bob's change) and not what I used to see in my first transaction.
That's how sub-versions would fix this because, by grouping properties
joined by a business transaction rule (price-quantity-discount), we could
eliminate conflicts between distinct groups of properties and only raise an
optimistic locking exception when a property is changed within the same
group (price-quantity-discount).

If we don't even consider something like this, we can still split the
tables into smaller ones to achieve the same goal.

Vlad

From steve at hibernate.org  Thu Nov 19 07:24:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 19 Nov 2015 12:24:53 +0000
Subject: [hibernate-dev] Fwd: Sub entities and Multi-version support
In-Reply-To: <CA+gWKMCThJnykX7iW-=oRexkz6WC9QH5N43-D9DH-MjpT5yctw@mail.gmail.com>
References: <CA+gWKMA-s_sivHTkUOhRw2y050G=K7b5qF9KZY_OKr=HzHX3oQ@mail.gmail.com>
	<CADGJaX_nxN49KhNYPuDGAiYLcHPSKWRJodg6YVP8XmJRnGCqfg@mail.gmail.com>
	<CA+gWKMCn=gvH_evs-9DPjYOohuito=MXYgVhUNxQaskio4aVeA@mail.gmail.com>
	<CAFdSV9sqT8s4odYmx17hP5+KBt2vL-1U5_yoS+KC7N68CJOtGQ@mail.gmail.com>
	<CA+gWKMBiR2heRsaMbwisowFOLv8QKC2Xp5MPubBB_gY0qjTkHQ@mail.gmail.com>
	<CAFdSV9siAJZ_eW7Er3kkoX-T0e=jWBPKWcczKYoFW=kj57dRBw@mail.gmail.com>
	<CA+gWKMDmeCy9xEJ=JkUuja5z_S4Z5qNzG4YT2adrJFOfX_cdYw@mail.gmail.com>
	<CA+gWKMCThJnykX7iW-=oRexkz6WC9QH5N43-D9DH-MjpT5yctw@mail.gmail.com>
Message-ID: <CAFdSV9s9ZnZGBCV-XB2N+ThpVfgmW19QpO1pUxrnNe5LrpKb6Q@mail.gmail.com>

Maybe we should just go "all the way" and have a per-column version? ;)

Anyway, like I said...

Personally I am inclined to vote -1 to this at the moment,  but I am
interested to hear what others might think.

On Wed, Nov 18, 2015 at 11:35 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Actually both merge() and update() can still cause a "write skew"
> phenomena, especially when using dynamic updates + OptimisticLockType DIRTY
> <
> https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotations/OptimisticLockType.html#DIRTY
> >
> or OptimisticLockType ALL
> <
> https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotations/OptimisticLockType.html#ALL
> >
> .
> Let's say I have an imaginary Product entity with a price and a quantity,
> and when I "purchase" it, I simply decrease its quantity (considering that
> the price doesn't change).
>
> 1. I load the Product with price 9.99 and quantity 5 in one Hibernate
> Session/HTTP request
> 2. Bob comes and changes the price to 14.99
> 3. I go back to place my order and I will use merge(). I will load the
> Product with the new price but I won't be aware of that, and I'll issue a
> dynamic-update on quantity, by simply decreasing.
>
> This anomaly can currently be fixed by @Version implementation. Neither
> DIRTY or ALL can detect this anomaly, because they relate to the latest
> state (Bob's change) and not what I used to see in my first transaction.
> That's how sub-versions would fix this because, by grouping properties
> joined by a business transaction rule (price-quantity-discount), we could
> eliminate conflicts between distinct groups of properties and only raise an
> optimistic locking exception when a property is changed within the same
> group (price-quantity-discount).
>
> If we don't even consider something like this, we can still split the
> tables into smaller ones to achieve the same goal.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Nov 19 09:16:10 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 19 Nov 2015 14:16:10 +0000
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <CAFdSV9u+SZo256fzgk+RkKWRXxNgJdQ5o=r2yKx9BP_io+fjEw@mail.gmail.com>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
	<20151111091428.GA61330@Nineveh.local>
	<CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>
	<20151111142800.GB66533@Nineveh.local>
	<CAFdSV9tJTUwQoz0K8tqW5_o-5XLqk6CCkJW-DzatwORYW3TjEw@mail.gmail.com>
	<20151113213011.GB1199@Nineveh.local>
	<CAFdSV9u+SZo256fzgk+RkKWRXxNgJdQ5o=r2yKx9BP_io+fjEw@mail.gmail.com>
Message-ID: <CAFdSV9v2JCvUb7b8iabz7hwz1e9OPP4=3LEs_oqtEEt63deaZA@mail.gmail.com>

Vlad, back to your original question...  What specifically did you mean?
Are you talking about something like https://github.com/integrations/gitbook
 ?

On Fri, Nov 13, 2015 at 3:39 PM Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Nov 13, 2015 at 3:30 PM Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
>> Hi,
>>
>> On Wed, Nov 11, 2015 at 02:36:13PM +0000, Steve Ebersole wrote:
>> > I think it makes sense to host these on hibernate.org *after* we
>> figure out
>> > the version-specific content issues I brought up in Barcelona.
>>
>> What issues are you talking about. I know you want to link to different
>> versions of the documentation from hibernate.org. AFAIK you already
>> started
>> with it and made some progress.
>>
>
> I made progress on version-specific documentation.  But there is really
> all kinds of version-specific data-points on the website in addition to
> documentation.  Rather than me cobbling it together piecemeal for each data
> point, I proposed that we consider an overall strategy for version specific
> information on the website.
>
>
>
>> > However, I am kind of torn.  Unless I misunderstand that would mean
>> moving
>> > the sources out of the upstream projects into the hibernate.org git
>> repo.
>>
>> Really, why is that?
>>
>
> What's the other option?  Keeping it upstream, building the docs and
> somehow pushing those built artifacts into the hibernate.org git repo?
> Or do y'all mean defining a scp/ftp/rsync dir on the actual box?  Because
> today we seem to strive for scriptable rebuilding...
>
>

From mihalcea.vlad at gmail.com  Thu Nov 19 09:27:04 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 19 Nov 2015 16:27:04 +0200
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <CAFdSV9v2JCvUb7b8iabz7hwz1e9OPP4=3LEs_oqtEEt63deaZA@mail.gmail.com>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
	<20151111091428.GA61330@Nineveh.local>
	<CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>
	<20151111142800.GB66533@Nineveh.local>
	<CAFdSV9tJTUwQoz0K8tqW5_o-5XLqk6CCkJW-DzatwORYW3TjEw@mail.gmail.com>
	<20151113213011.GB1199@Nineveh.local>
	<CAFdSV9u+SZo256fzgk+RkKWRXxNgJdQ5o=r2yKx9BP_io+fjEw@mail.gmail.com>
	<CAFdSV9v2JCvUb7b8iabz7hwz1e9OPP4=3LEs_oqtEEt63deaZA@mail.gmail.com>
Message-ID: <CA+gWKMAVEPJhXYtaOGQZ0aCqrJRMJ_F+awptXR3BphCZzgVn8w@mail.gmail.com>

Hi Steve,

I didn't know of GitBook before.

I was thinking if we can embed links in the jboss.org/hibernate
documentation to the actual branch/documentation-file in Github.
Something like a side arrow that, when being clicked, it can navigate to
the GitHub page hosting the actual file that rendered this HTML resource.

This way, the user can:

- suggest typos or corrections
- try to add suggestions, through pull-rquests
- add comments to something that's not clear for them

What do you think?

Vlad

On Thu, Nov 19, 2015 at 4:16 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Vlad, back to your original question...  What specifically did you mean?
> Are you talking about something like
> https://github.com/integrations/gitbook ?
>
> On Fri, Nov 13, 2015 at 3:39 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> On Fri, Nov 13, 2015 at 3:30 PM Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>>
>>> Hi,
>>>
>>> On Wed, Nov 11, 2015 at 02:36:13PM +0000, Steve Ebersole wrote:
>>> > I think it makes sense to host these on hibernate.org *after* we
>>> figure out
>>> > the version-specific content issues I brought up in Barcelona.
>>>
>>> What issues are you talking about. I know you want to link to different
>>> versions of the documentation from hibernate.org. AFAIK you already
>>> started
>>> with it and made some progress.
>>>
>>
>> I made progress on version-specific documentation.  But there is really
>> all kinds of version-specific data-points on the website in addition to
>> documentation.  Rather than me cobbling it together piecemeal for each data
>> point, I proposed that we consider an overall strategy for version specific
>> information on the website.
>>
>>
>>
>>> > However, I am kind of torn.  Unless I misunderstand that would mean
>>> moving
>>> > the sources out of the upstream projects into the hibernate.org git
>>> repo.
>>>
>>> Really, why is that?
>>>
>>
>> What's the other option?  Keeping it upstream, building the docs and
>> somehow pushing those built artifacts into the hibernate.org git repo?
>> Or do y'all mean defining a scp/ftp/rsync dir on the actual box?  Because
>> today we seem to strive for scriptable rebuilding...
>>
>>

From steve at hibernate.org  Thu Nov 19 09:50:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 19 Nov 2015 14:50:57 +0000
Subject: [hibernate-dev] Hibernate documentation on GitHub
In-Reply-To: <CA+gWKMAVEPJhXYtaOGQZ0aCqrJRMJ_F+awptXR3BphCZzgVn8w@mail.gmail.com>
References: <CA+gWKMC5O1+Kx_700Q15uJJzkU3fGu2sKf0jL187gC-TnFbNBg@mail.gmail.com>
	<CADGJaX_2X=f4-6PP2NtY1K01SdjVjWD+X-Y_wqpBWAUt-+tVrg@mail.gmail.com>
	<20151111091428.GA61330@Nineveh.local>
	<CAFm4XO1Jy=uSQi4pY7QQUXuu+dG3eK_TCPbyPaWQXW2fxa6jYg@mail.gmail.com>
	<20151111142800.GB66533@Nineveh.local>
	<CAFdSV9tJTUwQoz0K8tqW5_o-5XLqk6CCkJW-DzatwORYW3TjEw@mail.gmail.com>
	<20151113213011.GB1199@Nineveh.local>
	<CAFdSV9u+SZo256fzgk+RkKWRXxNgJdQ5o=r2yKx9BP_io+fjEw@mail.gmail.com>
	<CAFdSV9v2JCvUb7b8iabz7hwz1e9OPP4=3LEs_oqtEEt63deaZA@mail.gmail.com>
	<CA+gWKMAVEPJhXYtaOGQZ0aCqrJRMJ_F+awptXR3BphCZzgVn8w@mail.gmail.com>
Message-ID: <CAFdSV9vn6dGvYAy6XJwmNynKHwZm2Kk3rvzM9_8LTWGXNUVg9g@mail.gmail.com>

That means some form of customized rendering hooks in both DocBook
(jDocBook) and Asciidoctor for that to happen, as during rendering is the
only time we really understand the correlation between source and rendered
output (assuming a mapping from local doc source file to GitHub url).

On Thu, Nov 19, 2015 at 8:34 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi Steve,
>
> I didn't know of GitBook before.
>
> I was thinking if we can embed links in the jboss.org/hibernate
> documentation to the actual branch/documentation-file in Github.
> Something like a side arrow that, when being clicked, it can navigate to
> the GitHub page hosting the actual file that rendered this HTML resource.
>
> This way, the user can:
>
> - suggest typos or corrections
> - try to add suggestions, through pull-rquests
> - add comments to something that's not clear for them
>
> What do you think?
>
> Vlad
>
> On Thu, Nov 19, 2015 at 4:16 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Vlad, back to your original question...  What specifically did you mean?
>> Are you talking about something like
>> https://github.com/integrations/gitbook ?
>>
>> On Fri, Nov 13, 2015 at 3:39 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> On Fri, Nov 13, 2015 at 3:30 PM Hardy Ferentschik <hardy at hibernate.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Wed, Nov 11, 2015 at 02:36:13PM +0000, Steve Ebersole wrote:
>>>> > I think it makes sense to host these on hibernate.org *after* we
>>>> figure out
>>>> > the version-specific content issues I brought up in Barcelona.
>>>>
>>>> What issues are you talking about. I know you want to link to different
>>>> versions of the documentation from hibernate.org. AFAIK you already
>>>> started
>>>> with it and made some progress.
>>>>
>>>
>>> I made progress on version-specific documentation.  But there is really
>>> all kinds of version-specific data-points on the website in addition to
>>> documentation.  Rather than me cobbling it together piecemeal for each data
>>> point, I proposed that we consider an overall strategy for version specific
>>> information on the website.
>>>
>>>
>>>
>>>> > However, I am kind of torn.  Unless I misunderstand that would mean
>>>> moving
>>>> > the sources out of the upstream projects into the hibernate.org git
>>>> repo.
>>>>
>>>> Really, why is that?
>>>>
>>>
>>> What's the other option?  Keeping it upstream, building the docs and
>>> somehow pushing those built artifacts into the hibernate.org git repo?
>>> Or do y'all mean defining a scp/ftp/rsync dir on the actual box?  Because
>>> today we seem to strive for scriptable rebuilding...
>>>
>>>
>

From martinbraun123 at aol.com  Thu Nov 19 10:14:53 2015
From: martinbraun123 at aol.com (Martin Braun)
Date: Thu, 19 Nov 2015 10:14:53 -0500
Subject: [hibernate-dev] =?utf-8?q?I=EF=BF=BDm_ok=2C_thanks=2E_And_how_are?=
 =?utf-8?b?IHU/?=
Message-ID: <8D2F0F42CE3BA13-954-C7F7F@webmail-vm127.sysops.aol.com>

http://soyuzticaret.com/images/huatbgi.php?refresh=4204118_tb=77184&pID=cjkegeha




From gavin.king at gmail.com  Sat Nov 21 19:56:46 2015
From: gavin.king at gmail.com (Gavin King)
Date: Sun, 22 Nov 2015 01:56:46 +0100
Subject: [hibernate-dev] UserCollectionType mapping for Ceylon
Message-ID: <CAP7PoCdAWHWkDd1LByg73t3Bs-aoDZ+Nh-=57GFaDMRM1hXAgg@mail.gmail.com>

Hi Folks, so I'm making some first baby steps toward implementing
support for Ceylon's collections in Hibernate by trying to make use of
the existing UserCollectionType stuff.

Of course this is surely the ideal way to handle this, but bear with
me for a sec because I would like to know why what I tried didn't
work.

So I wrote my SetUserType to implement UserCollectionType, and then I
wrote the following Ceylon attribute:


    oneToMany { mappedBy="city"; }
    collectionType { type="hib.SetUserType"; }
    shared MutableSet<Person> people = HashSet<Person>();

Which is equivalent in the following Java:

    @javax.persistence.OneToMany(mappedBy = "city")
    @org.hibernate.annotations.CollectionType(type = "hib.SetUserType")
    @com.redhat.ceylon.compiler.java.metadata.Ignore
    private final ceylon.collection.MutableSet<Person> people;

But when I ran the code, I got this error:

Caused by: org.hibernate.AnnotationException: Illegal attempt to map a
non collection as a @OneToMany, @ManyToMany or @CollectionOfElements:
hib.City.people
at org.hibernate.cfg.annotations.CollectionBinder.getCollectionBinder(CollectionBinder.java:322)
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1874)
at org.hibernate.cfg.AnnotationBinder.processIdPropertiesIfNotAlready(AnnotationBinder.java:904)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:731)
at org.hibernate.boot.model.source.internal.annotations.AnnotationMetadataSourceProcessorImpl.processEntityHierarchies(AnnotationMetadataSourceProcessorImpl.java:245)
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess$1.processEntityHierarchies(MetadataBuildingProcess.java:222)
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:265)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:770)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:797)
at org.hibernate.jpa.HibernatePersistenceProvider.createEntityManagerFactory(HibernatePersistenceProvider.java:58)
... 32 more

Is @CollectionType supposed to work with @OneToMany?

Thanks,

Gavin

From gavin.king at gmail.com  Sat Nov 21 19:57:24 2015
From: gavin.king at gmail.com (Gavin King)
Date: Sun, 22 Nov 2015 01:57:24 +0100
Subject: [hibernate-dev] UserCollectionType mapping for Ceylon
In-Reply-To: <CAP7PoCdAWHWkDd1LByg73t3Bs-aoDZ+Nh-=57GFaDMRM1hXAgg@mail.gmail.com>
References: <CAP7PoCdAWHWkDd1LByg73t3Bs-aoDZ+Nh-=57GFaDMRM1hXAgg@mail.gmail.com>
Message-ID: <CAP7PoCeFZy+SbSZr31ADhL8PgAxfFjiJHy-vFvAkhDakkhnJng@mail.gmail.com>

On Sun, Nov 22, 2015 at 1:56 AM, Gavin King <gavin.king at gmail.com> wrote:

> Of course this is surely the ideal way to handle this, but bear with
> me for a sec because I would like to know why what I tried didn't
> work.

I mean "surely *not* the ideal way".

-- 
Gavin King
gavin at ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

From mihalcea.vlad at gmail.com  Sun Nov 22 01:57:57 2015
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sun, 22 Nov 2015 08:57:57 +0200
Subject: [hibernate-dev] UserCollectionType mapping for Ceylon
In-Reply-To: <CAP7PoCeFZy+SbSZr31ADhL8PgAxfFjiJHy-vFvAkhDakkhnJng@mail.gmail.com>
References: <CAP7PoCdAWHWkDd1LByg73t3Bs-aoDZ+Nh-=57GFaDMRM1hXAgg@mail.gmail.com>
	<CAP7PoCeFZy+SbSZr31ADhL8PgAxfFjiJHy-vFvAkhDakkhnJng@mail.gmail.com>
Message-ID: <CA+gWKMBH9K2LB5wMQWc+WpOyGfCUEWjP3r23bsbAzmdM_F50hg@mail.gmail.com>

I think that only the Java Collection types work with the JPA @OneToMany
associations, as it's described int his issue:

https://hibernate.atlassian.net/browse/HHH-4417

So, even when specifying a @CollectionType, the return type must be a
List/Set:

@OneToMany(...)
@CollectionType( type="MyCustomListType" )public List getOrders()

Vlad

On Sun, Nov 22, 2015 at 2:57 AM, Gavin King <gavin.king at gmail.com> wrote:

> On Sun, Nov 22, 2015 at 1:56 AM, Gavin King <gavin.king at gmail.com> wrote:
>
> > Of course this is surely the ideal way to handle this, but bear with
> > me for a sec because I would like to know why what I tried didn't
> > work.
>
> I mean "surely *not* the ideal way".
>
> --
> Gavin King
> gavin at ceylon-lang.org
> http://profiles.google.com/gavin.king
> http://ceylon-lang.org
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gavin.king at gmail.com  Sun Nov 22 05:37:39 2015
From: gavin.king at gmail.com (Gavin King)
Date: Sun, 22 Nov 2015 11:37:39 +0100
Subject: [hibernate-dev] UserCollectionType mapping for Ceylon
In-Reply-To: <CA+gWKMBH9K2LB5wMQWc+WpOyGfCUEWjP3r23bsbAzmdM_F50hg@mail.gmail.com>
References: <CAP7PoCdAWHWkDd1LByg73t3Bs-aoDZ+Nh-=57GFaDMRM1hXAgg@mail.gmail.com>
	<CAP7PoCeFZy+SbSZr31ADhL8PgAxfFjiJHy-vFvAkhDakkhnJng@mail.gmail.com>
	<CA+gWKMBH9K2LB5wMQWc+WpOyGfCUEWjP3r23bsbAzmdM_F50hg@mail.gmail.com>
Message-ID: <CAP7PoCch4huN-hYH0DyR3eruwriirbmxgXrqu5MH2V2DmgF0Ew@mail.gmail.com>

Ah, OK, thanks for the link, Vlad, now I think I sorta maybe see why.
With XML-based mappings, the semantic "kind" of collection is explicit
(<list/> or <set/> or whatever) whereas with annotations that is
determined by looking at the property type. The UserCollectionType
doesn't actually have this information.

So then I guess I'm going to need a bit of a deeper hack to make this work.

On Sun, Nov 22, 2015 at 7:57 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> I think that only the Java Collection types work with the JPA @OneToMany
> associations, as it's described int his issue:
>
> https://hibernate.atlassian.net/browse/HHH-4417
>
> So, even when specifying a @CollectionType, the return type must be a
> List/Set:
>
> @OneToMany(...)
> @CollectionType( type="MyCustomListType" )
> public List getOrders()
>
> Vlad
>
> On Sun, Nov 22, 2015 at 2:57 AM, Gavin King <gavin.king at gmail.com> wrote:
>>
>> On Sun, Nov 22, 2015 at 1:56 AM, Gavin King <gavin.king at gmail.com> wrote:
>>
>> > Of course this is surely the ideal way to handle this, but bear with
>> > me for a sec because I would like to know why what I tried didn't
>> > work.
>>
>> I mean "surely *not* the ideal way".
>>
>> --
>> Gavin King
>> gavin at ceylon-lang.org
>> http://profiles.google.com/gavin.king
>> http://ceylon-lang.org
>> http://hibernate.org
>> http://seamframework.org
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>



-- 
Gavin King
gavin at ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

From bulanovk at gmail.com  Mon Nov 23 03:07:11 2015
From: bulanovk at gmail.com (Konstantin Bulanov)
Date: Mon, 23 Nov 2015 12:07:11 +0400
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
	load-by-multiple-ids (#1136)
In-Reply-To: <hibernate/hibernate-orm/pull/1136/c158413356@github.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
Message-ID: <CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>

Hello Steve, as you asked moving our discussion about HHH-7572 in dev mail
list.



Regarding you question, in current architecture and implementation we have
the following point to perform entity persistence customization.

Annotation:
https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
which allows us to specify our own implementation of
https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html.


One of its methods is:



Object load(Serializable id,

            Object optionalObject,

            LockMode lockMode,

            SessionImplementor session)

     throws HibernateException



Load an instance of the persistent class.



and



Object load(Serializable id,

            Object optionalObject,

            LockOptions lockOptions,

            SessionImplementor session)

     throws HibernateException



Load an instance of the persistent class.



These two methods allows to specify you own Loader implementation to load
Entity by IDS,

in mentioned issue this part of contract was ignored by changing call
sequence on loading by multiple ids.



By Single id;

org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load



By Multiple id:

org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad



So in new API for multiple load we lose at least 2 possible extension
points: onLoadEvent, Persister.load (here we could customize loader -
specify our own instead hardcoded one)



>From my point of view there should be the same approach to get entities by
ID(independent multiple or single).


So which one approach is correct and future-proof for Single id or Multiple
Ids?


20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
notifications at github.com> ???????:

> Customize how? Loader still calls into the persister. Persisters and
> Loaders have a back-and-forth synergy.
>
> Also please discuss this on the hibernate-dev mailing list so others can be
> involved.
>
> On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
> notifications at github.com>
> wrote:
>
> > Hello Steve, could you be so kind to advice why we have different
> behavior
> > for loading by single id and multiple ids?
> >
> > In Case of single id, loading is going through
> > session->IdentifierLoadAccess->event->persister->Loader
> > In Case of multiple ids, loading is going through
> > session->MultiIdentifierLoadAccess->Loader
> >
> > So in case of load by single id it is possible to cutomize loading of
> > Entify using persister, but in new introduced API we lost this
> posibility.
> >
> > ?
> > Reply to this email directly or view it on GitHub
> > <
> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
> >
> > .
> >
>
> ?
> Reply to this email directly or view it on GitHub
> <https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356>
> .
>

From sanne at hibernate.org  Mon Nov 23 07:15:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 23 Nov 2015 12:15:47 +0000
Subject: [hibernate-dev] Hibernate Commons Annotations: releasing a
	5.0.1.Final version?
Message-ID: <CAFm4XO1Qn1D_s4Yuo1U4Jqw204T1xm4b7gCxE+TmNYexcDpiWA@mail.gmail.com>

Hi all,

I just sent a PR for a minor polishing patch to HCANN which seems
pretty safe and yet scores a solid benefit in terms of performance.
Considering how often we apply changes, I'd volunteer to release a
5.0.1.Final as soon as it's merged, as I assume no more changes will
flow in for a while?


There also is a long standing pull request which seems reasonable, but
I'm less familiar with that area; could someone have a look at:
 - https://github.com/hibernate/hibernate-commons-annotations/pull/7

and let me know if that's safe enough to be included soonish as well?

Thanks,
Sanne

From steve at hibernate.org  Mon Nov 23 14:16:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 23 Nov 2015 19:16:49 +0000
Subject: [hibernate-dev] Hibernate Commons Annotations: releasing a
 5.0.1.Final version?
In-Reply-To: <CAFm4XO1Qn1D_s4Yuo1U4Jqw204T1xm4b7gCxE+TmNYexcDpiWA@mail.gmail.com>
References: <CAFm4XO1Qn1D_s4Yuo1U4Jqw204T1xm4b7gCxE+TmNYexcDpiWA@mail.gmail.com>
Message-ID: <CAFdSV9uOAwkUMb6=8tmTgjXthb8JxSuxX+bmo-wE7MxXKkHX7w@mail.gmail.com>

As far as the #7 PR, corry I personally have no idea.  The problem is all
the "other" consumers of HCANN I am always told about when I want to change
things in HCANN.  I have no idea of the type of impact it might have on
some consumers I know nothing about.  For ORM, we do essentially the same
checks in annotation binder as well, so I think that is a reasonable change
in HCANN for ORM's needs.

On Mon, Nov 23, 2015 at 6:16 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
>
> I just sent a PR for a minor polishing patch to HCANN which seems
> pretty safe and yet scores a solid benefit in terms of performance.
> Considering how often we apply changes, I'd volunteer to release a
> 5.0.1.Final as soon as it's merged, as I assume no more changes will
> flow in for a while?
>
>
> There also is a long standing pull request which seems reasonable, but
> I'm less familiar with that area; could someone have a look at:
>  - https://github.com/hibernate/hibernate-commons-annotations/pull/7
>
> and let me know if that's safe enough to be included soonish as well?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Nov 23 14:31:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 23 Nov 2015 19:31:36 +0000
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
Message-ID: <CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>

Personally I think its a questions of semantics; to me a multi-id load
already implies/indicates a certain loading strategy (Loader).  You are
saying you'd like the ability to still decide a specific loading strategy
for multi-id loads.  I seriously doubt that is really what you want, but I
do understand the desire for consistency.  Maybe some others will chime in;
tbh I'm surprised Gunnar and Sanne did not bring this up as well in terms
of integrating this with Search.

Also, that was not the question I asked.  Specifically, what is it you want
to do that you cannot do given the current call chain?



On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov <bulanovk at gmail.com>
wrote:

> Hello Steve, as you asked moving our discussion about HHH-7572 in dev mail
> list.
>
>
>
> Regarding you question, in current architecture and implementation we have
> the following point to perform entity persistence customization.
>
> Annotation:
>
> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
> which allows us to specify our own implementation of
>
> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
> .
>
>
> One of its methods is:
>
>
>
> Object load(Serializable id,
>
>             Object optionalObject,
>
>             LockMode lockMode,
>
>             SessionImplementor session)
>
>      throws HibernateException
>
>
>
> Load an instance of the persistent class.
>
>
>
> and
>
>
>
> Object load(Serializable id,
>
>             Object optionalObject,
>
>             LockOptions lockOptions,
>
>             SessionImplementor session)
>
>      throws HibernateException
>
>
>
> Load an instance of the persistent class.
>
>
>
> These two methods allows to specify you own Loader implementation to load
> Entity by IDS,
>
> in mentioned issue this part of contract was ignored by changing call
> sequence on loading by multiple ids.
>
>
>
> By Single id;
>
>
> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>
>
>
> By Multiple id:
>
>
> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>
>
>
> So in new API for multiple load we lose at least 2 possible extension
> points: onLoadEvent, Persister.load (here we could customize loader -
> specify our own instead hardcoded one)
>
>
>
> From my point of view there should be the same approach to get entities by
> ID(independent multiple or single).
>
>
> So which one approach is correct and future-proof for Single id or Multiple
> Ids?
>
>
> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
> notifications at github.com> ???????:
>
> > Customize how? Loader still calls into the persister. Persisters and
> > Loaders have a back-and-forth synergy.
> >
> > Also please discuss this on the hibernate-dev mailing list so others can
> be
> > involved.
> >
> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
> > notifications at github.com>
> > wrote:
> >
> > > Hello Steve, could you be so kind to advice why we have different
> > behavior
> > > for loading by single id and multiple ids?
> > >
> > > In Case of single id, loading is going through
> > > session->IdentifierLoadAccess->event->persister->Loader
> > > In Case of multiple ids, loading is going through
> > > session->MultiIdentifierLoadAccess->Loader
> > >
> > > So in case of load by single id it is possible to cutomize loading of
> > > Entify using persister, but in new introduced API we lost this
> > posibility.
> > >
> > > ?
> > > Reply to this email directly or view it on GitHub
> > > <
> >
> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
> > >
> > > .
> > >
> >
> > ?
> > Reply to this email directly or view it on GitHub
> > <
> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
> >
> > .
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Nov 23 14:41:38 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 23 Nov 2015 19:41:38 +0000
Subject: [hibernate-dev] UserCollectionType mapping for Ceylon
In-Reply-To: <CAP7PoCch4huN-hYH0DyR3eruwriirbmxgXrqu5MH2V2DmgF0Ew@mail.gmail.com>
References: <CAP7PoCdAWHWkDd1LByg73t3Bs-aoDZ+Nh-=57GFaDMRM1hXAgg@mail.gmail.com>
	<CAP7PoCeFZy+SbSZr31ADhL8PgAxfFjiJHy-vFvAkhDakkhnJng@mail.gmail.com>
	<CA+gWKMBH9K2LB5wMQWc+WpOyGfCUEWjP3r23bsbAzmdM_F50hg@mail.gmail.com>
	<CAP7PoCch4huN-hYH0DyR3eruwriirbmxgXrqu5MH2V2DmgF0Ew@mail.gmail.com>
Message-ID: <CAFdSV9t4Wg6VMba5dQQ1tPkuSL-YSSbwjApVgtFp8Jh4tQWN5g@mail.gmail.com>

The annotation binder code does this checking.  Ultimately (unfortunately)
the binding code does need to understand whether to build a
o.h.mapping.Set, o.h.mapping.List, etc.  It makes the reasonable assumption
that the custom collection type (ceylon.collection.MutableSet) at least
implements one of the standard Java collection framework interfaces.  We
could certainly introduce a hint for cases like yours where that is not the
case (so long as you implement your own PersistentCollection as well that
should be enough).  Something like:

@org.hibernate.annotations.CollectionType(type = "hib.SetUserType",
nature=PluralAttributeNature.SET)

where `CollectionType.nature` is the
org.hibernate.boot.model.source.spi.PluralAttributeNature
enum:


public enum PluralAttributeNature {
BAG( Collection.class, false ),
ID_BAG( Collection.class, false ),
SET( Set.class, false ),
LIST( List.class, true ),
ARRAY( Object[].class, true ),
MAP( Map.class, true );
...
}

On Sun, Nov 22, 2015 at 4:38 AM Gavin King <gavin.king at gmail.com> wrote:

> Ah, OK, thanks for the link, Vlad, now I think I sorta maybe see why.
> With XML-based mappings, the semantic "kind" of collection is explicit
> (<list/> or <set/> or whatever) whereas with annotations that is
> determined by looking at the property type. The UserCollectionType
> doesn't actually have this information.
>
> So then I guess I'm going to need a bit of a deeper hack to make this work.
>
> On Sun, Nov 22, 2015 at 7:57 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > I think that only the Java Collection types work with the JPA @OneToMany
> > associations, as it's described int his issue:
> >
> > https://hibernate.atlassian.net/browse/HHH-4417
> >
> > So, even when specifying a @CollectionType, the return type must be a
> > List/Set:
> >
> > @OneToMany(...)
> > @CollectionType( type="MyCustomListType" )
> > public List getOrders()
> >
> > Vlad
> >
> > On Sun, Nov 22, 2015 at 2:57 AM, Gavin King <gavin.king at gmail.com>
> wrote:
> >>
> >> On Sun, Nov 22, 2015 at 1:56 AM, Gavin King <gavin.king at gmail.com>
> wrote:
> >>
> >> > Of course this is surely the ideal way to handle this, but bear with
> >> > me for a sec because I would like to know why what I tried didn't
> >> > work.
> >>
> >> I mean "surely *not* the ideal way".
> >>
> >> --
> >> Gavin King
> >> gavin at ceylon-lang.org
> >> http://profiles.google.com/gavin.king
> >> http://ceylon-lang.org
> >> http://hibernate.org
> >> http://seamframework.org
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>
>
>
> --
> Gavin King
> gavin at ceylon-lang.org
> http://profiles.google.com/gavin.king
> http://ceylon-lang.org
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From bulanovk at gmail.com  Tue Nov 24 03:11:39 2015
From: bulanovk at gmail.com (Konstantin Bulanov)
Date: Tue, 24 Nov 2015 12:11:39 +0400
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
Message-ID: <CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>

Hello, yes, you are absolutely right, the main concern here is that with
new MultipleLoad API we got inconsistent behavior for loading using
IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.


What regarding my case, it is loading data from EAV model, with predefined
scenarios.


We have 3 tables:


Objects[id ? pk, name, type_id, parent]
Params[attr_id, value, object_id (fk to objects), show_order]
References[ attr_id, reference, object_id( fk to objects), show_order]


Also we have a data loading scenario configuration based on type_id,
identifying set of params\references Entities and Object Entities
referenced by References entity to be Eager load during loading Object
Entities.


We have more than 1k attributes and more than 100Gb of data in
Object\Params\References entities


So it is simple recursive loading task, as per me, the best place for it
persister.load with optimized loader (at least without query hardparse on
each multiloading, this could be done using custom Oracle\PostgreSQL
datatype to pass array of ids as a bind variable in case of bulk load by
Ids)


PostgreSQL ex.:
Select * from objects where id = any(?);


If you could advise better solution to implement such scenario based on EAV
Eager loading I will be very appreciated to you.

2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:

> Personally I think its a questions of semantics; to me a multi-id load
> already implies/indicates a certain loading strategy (Loader).  You are
> saying you'd like the ability to still decide a specific loading strategy
> for multi-id loads.  I seriously doubt that is really what you want, but I
> do understand the desire for consistency.  Maybe some others will chime in;
> tbh I'm surprised Gunnar and Sanne did not bring this up as well in terms
> of integrating this with Search.
>
> Also, that was not the question I asked.  Specifically, what is it you
> want to do that you cannot do given the current call chain?
>
>
>
> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov <bulanovk at gmail.com>
> wrote:
>
>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev mail
>> list.
>>
>>
>>
>> Regarding you question, in current architecture and implementation we have
>> the following point to perform entity persistence customization.
>>
>> Annotation:
>>
>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>> which allows us to specify our own implementation of
>>
>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>> .
>>
>>
>> One of its methods is:
>>
>>
>>
>> Object load(Serializable id,
>>
>>             Object optionalObject,
>>
>>             LockMode lockMode,
>>
>>             SessionImplementor session)
>>
>>      throws HibernateException
>>
>>
>>
>> Load an instance of the persistent class.
>>
>>
>>
>> and
>>
>>
>>
>> Object load(Serializable id,
>>
>>             Object optionalObject,
>>
>>             LockOptions lockOptions,
>>
>>             SessionImplementor session)
>>
>>      throws HibernateException
>>
>>
>>
>> Load an instance of the persistent class.
>>
>>
>>
>> These two methods allows to specify you own Loader implementation to load
>> Entity by IDS,
>>
>> in mentioned issue this part of contract was ignored by changing call
>> sequence on loading by multiple ids.
>>
>>
>>
>> By Single id;
>>
>>
>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>>
>>
>>
>> By Multiple id:
>>
>>
>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>>
>>
>>
>> So in new API for multiple load we lose at least 2 possible extension
>> points: onLoadEvent, Persister.load (here we could customize loader -
>> specify our own instead hardcoded one)
>>
>>
>>
>> From my point of view there should be the same approach to get entities by
>> ID(independent multiple or single).
>>
>>
>> So which one approach is correct and future-proof for Single id or
>> Multiple
>> Ids?
>>
>>
>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>> notifications at github.com> ???????:
>>
>> > Customize how? Loader still calls into the persister. Persisters and
>> > Loaders have a back-and-forth synergy.
>> >
>> > Also please discuss this on the hibernate-dev mailing list so others
>> can be
>> > involved.
>> >
>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>> > notifications at github.com>
>> > wrote:
>> >
>> > > Hello Steve, could you be so kind to advice why we have different
>> > behavior
>> > > for loading by single id and multiple ids?
>> > >
>> > > In Case of single id, loading is going through
>> > > session->IdentifierLoadAccess->event->persister->Loader
>> > > In Case of multiple ids, loading is going through
>> > > session->MultiIdentifierLoadAccess->Loader
>> > >
>> > > So in case of load by single id it is possible to cutomize loading of
>> > > Entify using persister, but in new introduced API we lost this
>> > posibility.
>> > >
>> > > ?
>> > > Reply to this email directly or view it on GitHub
>> > > <
>> >
>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>> > >
>> > > .
>> > >
>> >
>> > ?
>> > Reply to this email directly or view it on GitHub
>> > <
>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>> >
>> > .
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Tue Nov 24 10:14:35 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 24 Nov 2015 15:14:35 +0000
Subject: [hibernate-dev] Release: Hibernate Commons Annotations 5.0.1.Final
Message-ID: <CAFm4XO0ea3MXd+TbvOYNEB88CkcOCB9GN+UbJkZ9aXD_oOLsyg@mail.gmail.com>

Hi all,

Hibernate Commons Annotations 5.0.1.Final is now available in JBoss's
Nexus, and will soon be available via the Maven Central mirros.

Compared to 5.0.0.Final, only one difference:
  https://hibernate.atlassian.net/browse/HCANN-74

That's a little performance improvement.

N.B. :
it's backwards compatible both at runtime and source level, but if you
compile a project using this latest version, it might fail at runtime
if you use 5.0.0.Final instead.

Thanks,
Sanne

From sanne at hibernate.org  Tue Nov 24 10:20:08 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 24 Nov 2015 15:20:08 +0000
Subject: [hibernate-dev] Hibernate Commons Annotations: releasing a
 5.0.1.Final version?
In-Reply-To: <CAFdSV9uOAwkUMb6=8tmTgjXthb8JxSuxX+bmo-wE7MxXKkHX7w@mail.gmail.com>
References: <CAFm4XO1Qn1D_s4Yuo1U4Jqw204T1xm4b7gCxE+TmNYexcDpiWA@mail.gmail.com>
	<CAFdSV9uOAwkUMb6=8tmTgjXthb8JxSuxX+bmo-wE7MxXKkHX7w@mail.gmail.com>
Message-ID: <CAFm4XO0Hs+T9cs0d_f2ox0Y0pVX0gzyJuMpy4jdjdMLDTZDwLg@mail.gmail.com>

Hi Steve,
thanks for the feedback. In doubt, I've released HCANN 5.0.1.Final
without that PR for now.

Thanks,
Sanne

On 23 November 2015 at 19:16, Steve Ebersole <steve at hibernate.org> wrote:
> As far as the #7 PR, corry I personally have no idea.  The problem is all
> the "other" consumers of HCANN I am always told about when I want to change
> things in HCANN.  I have no idea of the type of impact it might have on some
> consumers I know nothing about.  For ORM, we do essentially the same checks
> in annotation binder as well, so I think that is a reasonable change in
> HCANN for ORM's needs.
>
> On Mon, Nov 23, 2015 at 6:16 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi all,
>>
>> I just sent a PR for a minor polishing patch to HCANN which seems
>> pretty safe and yet scores a solid benefit in terms of performance.
>> Considering how often we apply changes, I'd volunteer to release a
>> 5.0.1.Final as soon as it's merged, as I assume no more changes will
>> flow in for a while?
>>
>>
>> There also is a long standing pull request which seems reasonable, but
>> I'm less familiar with that area; could someone have a look at:
>>  - https://github.com/hibernate/hibernate-commons-annotations/pull/7
>>
>> and let me know if that's safe enough to be included soonish as well?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Tue Nov 24 10:58:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 24 Nov 2015 15:58:47 +0000
Subject: [hibernate-dev] GitHub options to disable force pushing
Message-ID: <CAFm4XO05aWfNoBsuisDBei5=iRyMicU7ddXqY8Ugj2XEX8f1hQ@mail.gmail.com>

Hi all,
GitHub now provides an option to:
 - prevent pushing with the "force" option to a specific branch
 - prevent people to delete a specific branch

Considering our workflow and also to prevent user mistakes, I think we
should enable them on the reference repositories (the ones in
github.com/hibernate ).

I did enable this for Hibernate Search. If someone has good reason to
want delete a branch or push with "force" it's just two clicks away to
disable it.. at least I feel confident against unintentional mistakes.

Thanks,
Sanne

From dreborier at gmail.com  Tue Nov 24 11:22:35 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 24 Nov 2015 16:22:35 +0000
Subject: [hibernate-dev] GitHub options to disable force pushing
In-Reply-To: <CAFm4XO05aWfNoBsuisDBei5=iRyMicU7ddXqY8Ugj2XEX8f1hQ@mail.gmail.com>
References: <CAFm4XO05aWfNoBsuisDBei5=iRyMicU7ddXqY8Ugj2XEX8f1hQ@mail.gmail.com>
Message-ID: <CAL00eSRkmLD2HLu5xCzif+wjy24QqVq98nCEe15QFWkuzgFngQ@mail.gmail.com>

+1

On 24 November 2015 at 15:58, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
> GitHub now provides an option to:
>  - prevent pushing with the "force" option to a specific branch
>  - prevent people to delete a specific branch
>
> Considering our workflow and also to prevent user mistakes, I think we
> should enable them on the reference repositories (the ones in
> github.com/hibernate ).
>
> I did enable this for Hibernate Search. If someone has good reason to
> want delete a branch or push with "force" it's just two clicks away to
> disable it.. at least I feel confident against unintentional mistakes.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Nov 24 11:33:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 24 Nov 2015 16:33:03 +0000
Subject: [hibernate-dev] GitHub options to disable force pushing
In-Reply-To: <CAL00eSRkmLD2HLu5xCzif+wjy24QqVq98nCEe15QFWkuzgFngQ@mail.gmail.com>
References: <CAFm4XO05aWfNoBsuisDBei5=iRyMicU7ddXqY8Ugj2XEX8f1hQ@mail.gmail.com>
	<CAL00eSRkmLD2HLu5xCzif+wjy24QqVq98nCEe15QFWkuzgFngQ@mail.gmail.com>
Message-ID: <CAFdSV9uifzMW6WO1Lzm0ECEn2byGdm_oVMRB5ydor=bxaDLmNA@mail.gmail.com>

This has always made me nervous ever since it happened a few times
inadvertently after first moving to git.   Thanks for pointing out that
they finally added support for that.

For reference...
https://github.com/blog/2051-protected-branches-and-required-status-checks

On Tue, Nov 24, 2015, 10:24 AM andrea boriero <dreborier at gmail.com> wrote:

> +1
>
> On 24 November 2015 at 15:58, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > Hi all,
> > GitHub now provides an option to:
> >  - prevent pushing with the "force" option to a specific branch
> >  - prevent people to delete a specific branch
> >
> > Considering our workflow and also to prevent user mistakes, I think we
> > should enable them on the reference repositories (the ones in
> > github.com/hibernate ).
> >
> > I did enable this for Hibernate Search. If someone has good reason to
> > want delete a branch or push with "force" it's just two clicks away to
> > disable it.. at least I feel confident against unintentional mistakes.
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Nov 25 10:09:24 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 25 Nov 2015 15:09:24 +0000
Subject: [hibernate-dev] Released: Hibernate Search 5.5.1.Final
Message-ID: <CAFm4XO0nwuXg055iSjVFAyRiNcVW1RAUEzdYcO8NMeT-+rQMgw@mail.gmail.com>

Hello all,
we just published a very fine Hibernate Search release 5.5.1.Final !

Read about all improvement at:
 - http://in.relation.to/2015/11/25/Hibernate-Search-5/

Enjoy,
Sanne

From sanne at hibernate.org  Fri Nov 27 09:09:05 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 27 Nov 2015 14:09:05 +0000
Subject: [hibernate-dev] JDK9 testing
Message-ID: <CAFm4XO24_aUMQVN=hUcXMDXG-GhQhHhJk56FkB1agP6mzS8khA@mail.gmail.com>

We had several jobs failing on ci.hibernate.org as I had previously
uploaded a "Jigsaw enabled" build of JDK9. Turns out that was a bit
too a daring leap.

I've now replaced it with the latest build JDK 9 b93 "regular", so I
expect most issues to be gone.. I still wish to pursue Jigsaw
compatibility at some point, but let's at least aim at keeping our
projects stable on the regular one as a first step.

There are some goodies in this last build; quoting Rory O'Donnell:

>>>

JEP 254: Compact Strings (http://openjdk.java.net/jeps/254)

This JEP adopts a more space-efficient internal representation for strings.

We propose to change the internal representation of the String class
from a UTF-16 char array to a byte array plus an encoding-flag field.
The new String class will store characters encoded either as
ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes
per character), based upon the contents of the string. The encoding
flag will indicate which encoding is used.

JEP 165: Compiler Control (http://openjdk.java.net/jeps/165)

This JEP proposes an improved way to control the JVM compilers. It
enables runtime manageable, method dependent compiler flags.
(Immutable for the duration of a compilation.)

Method-context dependent control of the compilation process is a
powerful tool for writing small contained JVM compiler tests that can
be run without restarting the entire JVM. It is also very useful for
creating workarounds for bugs in the JVM compilers.

JEP 243: Java-Level JVM Compiler Interface (http://openjdk.java.net/jeps/243)

This JEP instruments the data flows within the JVM which are used by
the JIT compiler to allow Java code to observe, query, and affect the
JVM's compilation process and its associated metadata.

JEP 268: XML Catalog API (http://openjdk.java.net/jeps/268)

This JEP develops a standard XML Catalog API that supports the OASIS
XML Catalogs standard, v1.1. The API will define catalog and
catalog-resolver abstractions which can be used with the JAXP
processors that accept resolvers.

<<<

Thanks,
Sanne

From davidwilliams1978 at gmail.com  Fri Nov 27 16:22:33 2015
From: davidwilliams1978 at gmail.com (David Williams)
Date: Fri, 27 Nov 2015 16:22:33 -0500
Subject: [hibernate-dev] OGM-933 - PostLoad annotation support test
Message-ID: <CAO0keA_f18XEm8BCAa1rU6NstRPuuNoeGa+dxid2HkTE2yBBLg@mail.gmail.com>

Hi,

I'm currently working on adding support for the PostLoad annotation to OGM.
I've got it working against one of my own projects but am looking for some
guidance around test coverage before I submit a pull request. I couldn't
find any existing tests in OGM for other annotations that already work
(e.g. PrePersist and PreUpdate) so wanted to check whether I should include
a test for PostLoad and if so if there was an appropriate package for me to
put it in?

Thanks,
David.

From brett at hibernate.org  Sun Nov 29 13:15:56 2015
From: brett at hibernate.org (Brett Meyer)
Date: Sun, 29 Nov 2015 13:15:56 -0500
Subject: [hibernate-dev] Fwd: Re:  Apache Trafodion Dialect
In-Reply-To: <md5:K7fBjfRgwlqjMl6xF2OImA==>
References: <md5:K7fBjfRgwlqjMl6xF2OImA==>
Message-ID: <565B40DC.2030101@hibernate.org>

Hey Sanne, just realized I never responded to this. That was definitely 
my first thought as well. But, not knowing very much about OGM, are 
there any use cases for plain JPA + Trafodion, vs Hadoop + OGM? A means 
to "try out" Hadoop without jumping into OGM right away?

Even if Hadoop on OGM happens, I guess I don't see a problem also 
including this dialect, if the Trafodion team maintains it. But, that's 
of course only if others would use it...

On Oct 26, 2015 4:10 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> +1 for the usage question! Would be nice to understand the use case of it too.
>
> And in this specific case, I'd also wonder if the same use case
> wouldn't be fulfilled better by an Hibernate OGM dialect.
>
> On 26 October 2015 at 18:13, Brett Meyer <brett at hibernate.org> wrote:
> > All, we've been approached by the team responsible for the Apache
> > Trafodion project, an "SQL-on-Hadoop" solution.  They've developed a
> > Dialect, are willing to contribute it, and are willing to maintain it
> > long term.  The latter has been a requirement for a while -- we have too
> > many Dialects that were contributed then abandoned.
> >
> > However, the other requirement is actual demand by community users. So,
> > out of curiosity, would anyone actually use it?  I'm not at all familiar
> > with the project or space, but it definitely sounds interesting.  If
> > this Dialect would be helpful, please add your vote to the JIRA:
> >
> > https://hibernate.atlassian.net/browse/HHH-10216
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev





From gunnar at hibernate.org  Mon Nov 30 04:59:35 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 30 Nov 2015 10:59:35 +0100
Subject: [hibernate-dev] OGM-933 - PostLoad annotation support test
In-Reply-To: <CAO0keA_f18XEm8BCAa1rU6NstRPuuNoeGa+dxid2HkTE2yBBLg@mail.gmail.com>
References: <CAO0keA_f18XEm8BCAa1rU6NstRPuuNoeGa+dxid2HkTE2yBBLg@mail.gmail.com>
Message-ID: <CADGJaX8AcQu3fP_w2mG=T+OraT7N+ABgqDGtGfEuzjSyU--7wQ@mail.gmail.com>

Hi David,

Cool, thanks a lot for working on this! I suppose there are no tests
for lifecycle events yet, as those that are working, do so
"incidentally" by inheriting the relevant code paths from Hibernate
OGM.

+1 for adding at test for PostLoad as that's triggered by our own
loader. Package-wise, a new package under "backendtck" would be great,
that way it will run once for each backend we support.

Hth,

--Gunnar


2015-11-27 22:22 GMT+01:00 David Williams <davidwilliams1978 at gmail.com>:
> Hi,
>
> I'm currently working on adding support for the PostLoad annotation to OGM.
> I've got it working against one of my own projects but am looking for some
> guidance around test coverage before I submit a pull request. I couldn't
> find any existing tests in OGM for other annotations that already work
> (e.g. PrePersist and PreUpdate) so wanted to check whether I should include
> a test for PostLoad and if so if there was an appropriate package for me to
> put it in?
>
> Thanks,
> David.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From davidwilliams1978 at gmail.com  Mon Nov 30 09:34:35 2015
From: davidwilliams1978 at gmail.com (David Williams)
Date: Mon, 30 Nov 2015 09:34:35 -0500
Subject: [hibernate-dev] OGM-933 - PostLoad annotation support test
In-Reply-To: <CADGJaX8AcQu3fP_w2mG=T+OraT7N+ABgqDGtGfEuzjSyU--7wQ@mail.gmail.com>
References: <CAO0keA_f18XEm8BCAa1rU6NstRPuuNoeGa+dxid2HkTE2yBBLg@mail.gmail.com>
	<CADGJaX8AcQu3fP_w2mG=T+OraT7N+ABgqDGtGfEuzjSyU--7wQ@mail.gmail.com>
Message-ID: <CAO0keA-9PJyiazD4j5zofR99Jz3siog_ayyeNFi2q1NpoPgu+Q@mail.gmail.com>

Hi Gunnar,

That works for me. My plan is to create an OGM counterpart (under
backendtck) to the PostLoadTest in ORM.

Thanks,
Dave.

On Mon, Nov 30, 2015 at 4:59 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi David,
>
> Cool, thanks a lot for working on this! I suppose there are no tests
> for lifecycle events yet, as those that are working, do so
> "incidentally" by inheriting the relevant code paths from Hibernate
> OGM.
>
> +1 for adding at test for PostLoad as that's triggered by our own
> loader. Package-wise, a new package under "backendtck" would be great,
> that way it will run once for each backend we support.
>
> Hth,
>
> --Gunnar
>
>
> 2015-11-27 22:22 GMT+01:00 David Williams <davidwilliams1978 at gmail.com>:
> > Hi,
> >
> > I'm currently working on adding support for the PostLoad annotation to
> OGM.
> > I've got it working against one of my own projects but am looking for
> some
> > guidance around test coverage before I submit a pull request. I couldn't
> > find any existing tests in OGM for other annotations that already work
> > (e.g. PrePersist and PreUpdate) so wanted to check whether I should
> include
> > a test for PostLoad and if so if there was an appropriate package for me
> to
> > put it in?
> >
> > Thanks,
> > David.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Nov 30 14:10:12 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 30 Nov 2015 19:10:12 +0000
Subject: [hibernate-dev] Why does Hibernate has aggressive connection
 releasing for JTA
In-Reply-To: <CA+gWKMByuhFobZ=GboL3cX8sHQ8wHseiWAyz03K7ET_cAWy3TA@mail.gmail.com>
References: <CA+gWKMBxTZSV6RZpJQ+qF+KR=_S=GoN9Hse=xMJSBsH7qxRx0A@mail.gmail.com>
	<CAFdSV9sTCH8cNGgxU5zPnTsdZbrp53kb+kDASvYotGFGMex5+g@mail.gmail.com>
	<CA+gWKMBgNUhxfFBv5QvH8H4Bprtizk1Uj_z=OLPMemTTFBM7qA@mail.gmail.com>
	<CAFdSV9teCuCUd0bzXnJ8Ya+aU6oADdmcCA6mCeo8fbO08q9orw@mail.gmail.com>
	<CA+gWKMByuhFobZ=GboL3cX8sHQ8wHseiWAyz03K7ET_cAWy3TA@mail.gmail.com>
Message-ID: <CAFdSV9uEOqLj6390bG7oLb9T_zGUU_n7D_2CM=b2E2Mz6cjnUA@mail.gmail.com>

I'd like to test this later using the ConnectionAcquitionMode.  In theory
this should led to zero overhead for real applications.

P.S. I had to remove your image as the mailing list does not accept
attachments.

On Thu, Nov 19, 2015 at 1:11 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I wrote a test to replicate the aggressive release overhead (
> https://github.com/vladmihalcea/high-performance-java-persistence/blob/master/core/src/test/java/com/vladmihalcea/book/hpjp/hibernate/connection/jta/JtaConnectionReleaseTest.java
> ) and these are my findings:
>
>
> ?
> The more statements a transaction has, the more obvious the performance
> impact.
> This was tested with Spring and Bitronix and so it measures Bitronix
> overhead.
>
> We'll have to update the docs to advise the clients to consider the
> AFTER_TRANSACTION mode for some stand-alone JTA environments.
> I wonder if today's Java EE application servers still require the
> aggressive release as an workaround to their connection leak detection
> algorithms.
>
> Vlad
>
> On Wed, Nov 18, 2015 at 5:49 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Yes, I think that's a good idea.  I also think working
>> on ConnectionAcquisitionMode is the best option.  The fact that Hibernate
>> delays getting the Connection is so generally not useful.
>>
>>
>> On Wed, Nov 18, 2015 at 9:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Thanks for the explanation. I found a discussion from 2006 where you
>>> explained this behavior:
>>>
>>> http://lists.jboss.org/pipermail/hibernate-dev/2006-December/000903.html
>>>
>>> I am currently testing the AFTER_TRANSACTION release mode with Spring
>>> and Bitronix and I think it can give some performance gain over
>>> AFTER_STATEMENT.
>>> I'll keep you posted with the final results.
>>>
>>> Do you think we should update the docs to explain that this is rather
>>> required by Java EE containers, and it might be fine with stand-along JTA
>>> transaction managers?
>>>
>>> Vlad
>>>
>>>
>>>
>>> On Wed, Nov 18, 2015 at 4:05 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> It was to work around certain containers (not just EE containers) that
>>>> implement "resource containment" checks.  The Hibernate Session defers
>>>> getting a JDBC Connection until it actually needs one, which can lead to
>>>> cases like the following where 2 beans share a Session/EM:
>>>>
>>>> Bean1: get Session, but don't use it yet in way that needs Connection
>>>> Bean1: call Bean2...
>>>> Bean2: get Session, do some work forcing Session to obtain Connection
>>>> Bean2: return (Session still hold Connection)
>>>>
>>>> At this point, these containers see this as a "leaked" Connection
>>>> because the handle was not released by the end of the scope in which it was
>>>> obtained.  Hence, aggressive releasing.  My contention at the time was that
>>>> a ConnectionAcquisitionMode would have been better/cleaner.  I still feel
>>>> that way, and hope to still come back and add that; so much so in fact that
>>>> the enum already exists[1] :).
>>>>
>>>> [1] org.hibernate.ConnectionAcquisitionMode
>>>>
>>>> On Wed, Nov 18, 2015 at 1:45 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Does anyone remember why does Hibernate support aggressive connection
>>>>> releasing?
>>>>> I've never found this requirement in either JTA or JDBC spec.
>>>>> Was it something required by the Java EE application server?
>>>>>
>>>>> Vlad
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>