Re: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI job

[Gunnar Morling]

Yes, indeed it's properly failing locally. Anyways, have you tried the
latest FailSafe version on CI?

2016-01-20 14:40 GMT+01:00 Sanne Grinovero :
> Thanks for identifying HV-1048 !
>
> About the failsafe plugin: I'll run some tests, but I'm not sure if
> it's just a maven problem as when running it locally it "fails as
> expected".
> Does it work for you all when running locally?
>
> Sanne
>
> On 20 January 2016 at 11:39, Gunnar Morling  wrote:
>> Maybe you hit that one: "Failsafe project does not fail in verify
>> phase when a test case object errors during initialization" [1]. Fixed
>> in 2.19.
>>
>> --Gunnar
>>
>> [1] https://issues.apache.org/jira/browse/SUREFIRE-1127
>>
>>
>>
>> 2016-01-20 12:35 GMT+01:00 Gunnar Morling :
>>> Concerning the original error, we are bitten by the changed version
>>> number scheme in JDK 9 (we evaluate the Java version to enable
>>> specific code when running on JDK 8 or later): We are expecting a
>>> dot-separated version string such as "1.8.0", but JDK 9 returns only
>>> "9" as proposed by JEP 223 [1].
>>>
>>> I've filed HV-1048 [2] for that.
>>>
>>> Regarding the Maven/Jenkins issue I am not fully sure, the FailSafe
>>> plug-in detects "There are test failures" during the verify phase but
>>> for some reason it doesn't fail the build. It's an issue on the Maven
>>> side, not Jenkins; Test failure just mark a build (of Maven job type)
>>> as unstable (yellow), not as failed (red). Maybe you try the latest
>>> FailSafe version (2.19.1)?
>>>
>>> --Gunnar
>>>
>>> [1] http://openjdk.java.net/jeps/223
>>> [2] https://hibernate.atlassian.net/browse/HV-1048
>>>
>>>
>>> 2016-01-20 11:36 GMT+01:00 Sanne Grinovero :
 I'm puzzled.
 There seems to be a javax.validation related issue which is failing
 the integration tests running on Arquillian / WildFly for the
 Hibernate Search / WildFly tests on JDK9.

 http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console

 But more importantly.. anyone has a clue on why the build is marked as
 "SUCCESS" ?

 You actually have to notice the failures in the logs to figure out
 that it's not successful at all;
 search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.

 Sanne
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI job

[Sanne Grinovero]

Thanks for identifying HV-1048 !

About the failsafe plugin: I'll run some tests, but I'm not sure if
it's just a maven problem as when running it locally it "fails as
expected".
Does it work for you all when running locally?

Sanne

On 20 January 2016 at 11:39, Gunnar Morling  wrote:
> Maybe you hit that one: "Failsafe project does not fail in verify
> phase when a test case object errors during initialization" [1]. Fixed
> in 2.19.
>
> --Gunnar
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1127
>
>
>
> 2016-01-20 12:35 GMT+01:00 Gunnar Morling :
>> Concerning the original error, we are bitten by the changed version
>> number scheme in JDK 9 (we evaluate the Java version to enable
>> specific code when running on JDK 8 or later): We are expecting a
>> dot-separated version string such as "1.8.0", but JDK 9 returns only
>> "9" as proposed by JEP 223 [1].
>>
>> I've filed HV-1048 [2] for that.
>>
>> Regarding the Maven/Jenkins issue I am not fully sure, the FailSafe
>> plug-in detects "There are test failures" during the verify phase but
>> for some reason it doesn't fail the build. It's an issue on the Maven
>> side, not Jenkins; Test failure just mark a build (of Maven job type)
>> as unstable (yellow), not as failed (red). Maybe you try the latest
>> FailSafe version (2.19.1)?
>>
>> --Gunnar
>>
>> [1] http://openjdk.java.net/jeps/223
>> [2] https://hibernate.atlassian.net/browse/HV-1048
>>
>>
>> 2016-01-20 11:36 GMT+01:00 Sanne Grinovero :
>>> I'm puzzled.
>>> There seems to be a javax.validation related issue which is failing
>>> the integration tests running on Arquillian / WildFly for the
>>> Hibernate Search / WildFly tests on JDK9.
>>>
>>> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>>>
>>> But more importantly.. anyone has a clue on why the build is marked as
>>> "SUCCESS" ?
>>>
>>> You actually have to notice the failures in the logs to figure out
>>> that it's not successful at all;
>>> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>>>
>>> Sanne
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.1 tentative release date

[Gunnar Morling]

I went for the proposed intermediary step to avoid breaking the API of
SchemaManagementTool and its delegates. If you have a way for not
breaking the API or think breaking it is alright, then +1 for doing
the ProperSolution™ in 5.1.

What would it comprise, changing the delegate methods such as
doCreate() to expect a single parameter object providing all the
required info? Target could be a part of this, just an enum probably,
based on wich delegates would do their thing. If it's that, I can try
and help out with it.

Regarding the release schedule, I'd personally be fine with pushing it
a bit back, but then I don't know whether there are any other hard
timelines to be met.


2016-01-19 16:25 GMT+01:00 Steve Ebersole :
> I'd like to get this work into 5.1.  But, as much as possible, I'd like to
> get the ProperSolution in place rather than just a StepInTheRightDirection.
> If we need to push this date 2-4 weeks I am ok with that.  That would help
> us coordinate with Infinispan 8.2 schedule (iiuc) for hibernate-infinispan,
> not to mention I still have to review the work Vlad has done on the docs
> again as well as polish the load-by-multi-id API[1].
>
> [1] Sanne still waiting on your feedback to the open question of internal
> routing of those calls.
>
> On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling  wrote:
>>
>> Hi Steve,
>>
>> As discussed on IRC, I tried plugging in my own SchemaManagementTool
>> and delegates and letting them do the initialization work required for
>> OGM.
>>
>> I am hitting a wall though when it comes to the usage in the
>> SchemaExport controller: As it's invoking doCreate() and doDrop()
>> right in the constructor with a "fake" target for delegating the SQL
>> statements, I am bitten by the fact that SchemaExport is instantiated
>> twice in SessionFactoryImpl (once for create, once for drop at
>> shutdown), so I see to invocations to doCreate() and doDrop(). Also I
>> am lacking the knowledge of what's passed as Target for the controller
>> invocation.
>>
>> So I went ahead and changed SchemaExport to invoke SchemaCreator and
>> -Dropper only in execute(), passing them actual Target implementations
>> as it's done in SchemaUpdate, too. It's not yet what you described as
>> the ultimate goal (not looping back to Target), but IMO it's a step
>> into the right direction, not the least making things consistent
>> between SchemaExport and SchemaUpdate and also leaving APIs largely
>> unchanged for the time being. With that I should be able to do it on
>> the OGM side as you suggested, essentially ignoring the
>> Target/Exporter stuff.
>>
>> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231
>> for the change. Let me know what you think.
>>
>> Cheers,
>>
>> --Gunnar
>>
>>
>> 2016-01-14 15:51 GMT+01:00 Steve Ebersole :
>> > I am not sure I am a big fan of The String->Object change specifically.
>> > In
>> > theory it sounds great.  But there is a major premise in schema tooling
>> > around the idea of the actions being reduce-able to Strings.  That's
>> > important not just for SQL, but for the idea of writing to a file as
>> > well.
>> > It also affects the whole concept of Exporter/Exportable.
>> >
>> > The ultimate design goal here is to unify schema creation and dropping
>> > across native and JPA requirements.  I just simply have not had the time
>> > to
>> > work on that.  This would all happen "behind" SchemaManagementTool and
>> > friends.  SchemaExport, etc are actually just controllers responsible
>> > for
>> > coordinating the calls into the SchemaManagementTool delegates.  The
>> > main
>> > problem at the moment IMO is that Target gets passed into these
>> > SchemaManagementTool delegates.  Ideally, and certainly this would fit
>> > with
>> > your case, I think we want SchemaManagementTool or its delegates to
>> > handle
>> > interpreting the "arguments".  This was part of the intent of developing
>> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now;
>> > the
>> > idea was to encapsulate the settings each tool needs to operate and
>> > isolate
>> > the process of building/interpreting those args.
>> >
>> > The next step I wanted to look at there was to morph CommandLineArgs
>> > into a
>> > more generic "parameter object" for initializing the actual
>> > SchemaManagementTool delegates.
>> >
>> > The idea is that the more we can push into SchemaManagementTool and its
>> > delegates the more pluggable this entire process becomes.  Ultimately,
>> > as I
>> > mentioned above, I just do not think it is feasible for ORM and OGM to
>> > share all of these implementation contracts.  Forcing a switch from
>> > String
>> > (the DDL) arguments to some amorphic Object reinforces that in my mind.
>> > But that would not stop OGM from completely swapping
>> > SchemaManagementTool
>> > and its delegates and simply not using Target, Exporters, etc.
>> >
>> >
>> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling 
>> > wrote:
>> >
>> >> Hi Steve,
>> >>

Re: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI job

[Gunnar Morling]

Maybe you hit that one: "Failsafe project does not fail in verify
phase when a test case object errors during initialization" [1]. Fixed
in 2.19.

--Gunnar

[1] https://issues.apache.org/jira/browse/SUREFIRE-1127



2016-01-20 12:35 GMT+01:00 Gunnar Morling :
> Concerning the original error, we are bitten by the changed version
> number scheme in JDK 9 (we evaluate the Java version to enable
> specific code when running on JDK 8 or later): We are expecting a
> dot-separated version string such as "1.8.0", but JDK 9 returns only
> "9" as proposed by JEP 223 [1].
>
> I've filed HV-1048 [2] for that.
>
> Regarding the Maven/Jenkins issue I am not fully sure, the FailSafe
> plug-in detects "There are test failures" during the verify phase but
> for some reason it doesn't fail the build. It's an issue on the Maven
> side, not Jenkins; Test failure just mark a build (of Maven job type)
> as unstable (yellow), not as failed (red). Maybe you try the latest
> FailSafe version (2.19.1)?
>
> --Gunnar
>
> [1] http://openjdk.java.net/jeps/223
> [2] https://hibernate.atlassian.net/browse/HV-1048
>
>
> 2016-01-20 11:36 GMT+01:00 Sanne Grinovero :
>> I'm puzzled.
>> There seems to be a javax.validation related issue which is failing
>> the integration tests running on Arquillian / WildFly for the
>> Hibernate Search / WildFly tests on JDK9.
>>
>> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>>
>> But more importantly.. anyone has a clue on why the build is marked as
>> "SUCCESS" ?
>>
>> You actually have to notice the failures in the logs to figure out
>> that it's not successful at all;
>> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>>
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI job

[Gunnar Morling]

Concerning the original error, we are bitten by the changed version
number scheme in JDK 9 (we evaluate the Java version to enable
specific code when running on JDK 8 or later): We are expecting a
dot-separated version string such as "1.8.0", but JDK 9 returns only
"9" as proposed by JEP 223 [1].

I've filed HV-1048 [2] for that.

Regarding the Maven/Jenkins issue I am not fully sure, the FailSafe
plug-in detects "There are test failures" during the verify phase but
for some reason it doesn't fail the build. It's an issue on the Maven
side, not Jenkins; Test failure just mark a build (of Maven job type)
as unstable (yellow), not as failed (red). Maybe you try the latest
FailSafe version (2.19.1)?

--Gunnar

[1] http://openjdk.java.net/jeps/223
[2] https://hibernate.atlassian.net/browse/HV-1048


2016-01-20 11:36 GMT+01:00 Sanne Grinovero :
> I'm puzzled.
> There seems to be a javax.validation related issue which is failing
> the integration tests running on Arquillian / WildFly for the
> Hibernate Search / WildFly tests on JDK9.
>
> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>
> But more importantly.. anyone has a clue on why the build is marked as
> "SUCCESS" ?
>
> You actually have to notice the failures in the logs to figure out
> that it's not successful at all;
> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI job

[Davide D'Alto]

I wonder if it's a problem of integration between Jenkins and the maven
failsafe plugin

On Wed, Jan 20, 2016 at 10:36 AM, Sanne Grinovero 
wrote:

> I'm puzzled.
> There seems to be a javax.validation related issue which is failing
> the integration tests running on Arquillian / WildFly for the
> Hibernate Search / WildFly tests on JDK9.
>
>
> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>
> But more importantly.. anyone has a clue on why the build is marked as
> "SUCCESS" ?
>
> You actually have to notice the failures in the logs to figure out
> that it's not successful at all;
> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] JDK9 / WildFly / Validator issue with Search CI job

[Sanne Grinovero]

I'm puzzled.
There seems to be a javax.validation related issue which is failing
the integration tests running on Arquillian / WildFly for the
Hibernate Search / WildFly tests on JDK9.

http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console

But more importantly.. anyone has a clue on why the build is marked as
"SUCCESS" ?

You actually have to notice the failures in the logs to figure out
that it's not successful at all;
search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.

Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 2LC docs

[Vlad Mihalcea]

Hi Radim,

I'm now filling in the missing sections on the Caching chapter in the 5.1
User Guide.

Vlad

On Wed, Jan 20, 2016 at 11:32 AM, Radim Vansa  wrote:

> I would say that the best source is 4.x docs, since the cited source is
> what I describe by 'close to nothing'.
>
> I understand that for 5.1 the transformation might be unfinished, but I
> was surprised by the same for 5.0 - missing information that's written,
> maybe just not formatted properly for asciiidoc. In such case, link to
> appropriate chapter in older docs would be useful.
>
> Radim
>
> On 01/19/2016 07:04 PM, Steve Ebersole wrote:
> > The docs are in a state of flux for 5.1.  For now your best bet is the
> > source:
> documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc
> >
> > On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa  > > wrote:
> >
> > Hi,
> >
> > I was about to fill some gaps in 2LC docs regarding improvements in
> > 5.0/5.1, but when I took a look into 5.0 docs [1] there's close to
> > nothing; is it by purpose? In 4.3 docs [2], there's much more on this
> > subject. Am I looking in a wrong place?
> >
> > Radim
> >
> > [1]
> >
> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
> > [2]
> >
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
> >
> > --
> > Radim Vansa mailto:rva...@redhat.com>>
> > JBoss Performance Team
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org 
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
> --
> Radim Vansa 
> JBoss Performance Team
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)

[Sanne Grinovero]

Hi Steve,
Hibernate Search doesn't customize the loaders: if any we want to make
sure that whatever customization has been defined is being used by
Search as well.
Hibernate OGM does of course replace the default loaders; I'm not sure
how nicely that interacts with the user wanting to override it.

-- Sanne

On 19 January 2016 at 22:30, Steve Ebersole  wrote:
> Sanne, Gunnar any thoughts/input here?
>
>
> On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov 
> wrote:
>
>> 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 :
>>
>>> 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 
>>> 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

Re: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)

[Gunnar Morling]

The direct link to DynamicBatchingEntityLoaderBuilder makes it fail
with OGM; So yes, going through EntityPersister for obtaining the
right loader would be great so we can make multi-id-load work with
OGM.

2016-01-19 23:30 GMT+01:00 Steve Ebersole :
> Sanne, Gunnar any thoughts/input here?
>
>
> On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov 
> wrote:
>
>> 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 :
>>
>>> 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 
>>> 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 f

Re: [hibernate-dev] 2LC docs

[Radim Vansa]

I would say that the best source is 4.x docs, since the cited source is 
what I describe by 'close to nothing'.

I understand that for 5.1 the transformation might be unfinished, but I 
was surprised by the same for 5.0 - missing information that's written, 
maybe just not formatted properly for asciiidoc. In such case, link to 
appropriate chapter in older docs would be useful.

Radim

On 01/19/2016 07:04 PM, Steve Ebersole wrote:
> The docs are in a state of flux for 5.1.  For now your best bet is the 
> source: 
> documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc
>
> On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa  > wrote:
>
> Hi,
>
> I was about to fill some gaps in 2LC docs regarding improvements in
> 5.0/5.1, but when I took a look into 5.0 docs [1] there's close to
> nothing; is it by purpose? In 4.3 docs [2], there's much more on this
> subject. Am I looking in a wrong place?
>
> Radim
>
> [1]
> 
> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
> [2]
> 
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
>
> --
> Radim Vansa mailto:rva...@redhat.com>>
> JBoss Performance Team
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


-- 
Radim Vansa 
JBoss Performance Team

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for load-by-multiple-ids (#1136)

[Konstantin Bulanov]

Hello, Steve,


I absolutely agree with you regarding LoadEvent, but if LoadEvent will be
omitted and it will be possible to implement custom MultiIdentifierLoader,  it
is better to move L2 and L1 cache support to one place, for example to
MultiIdentifierLoadAccess (right now I couldn’t find where multiLoad stack
works with L2 cache ).


So if we a goes with proposed version (MultiIdentifierLoadAccess -> (*)
EntityPersister#multiLoad -> (*) MultiIdentifierLoader#multiLoad) it will
give a possibility to use same(customized) loader as for loading by single
id and restore framework consistent behavior.

2016-01-20 2:45 GMT+04:00 Steve Ebersole :

> Konstantin, I am not sure what you are asking exactly, mainly in your last
> email..
>
> From your first reply it sounded like you just wanted the call stack here
> to route through EntityPersister (MultiIdentifierLoadAccess ->
> EntityPersister -> [some-multi-id-load-loader]) rather than directly going
> to DynamicBatchingEntityLoader (MultiIdentifierLoadAccess -> 
> DynamicBatchingEntityLoader).
> That is certainly something I am willing to consider.
>
> You had mentioned LoadEvent(Listener); personally I don't see the argument
> for having a new event/listener for this.  It would be consistent,
> certainly, but I am just not sure what we'd gain.
>
> So I can specifically see the calls here going MultiIdentifierLoadAccess
> -> (*) EntityPersister#multiLoad -> (*) MultiIdentifierLoader#multiLoad
>
>
> [*] - new method/contract
>
>
>
>
> On Tue, Jan 19, 2016 at 4:30 PM Steve Ebersole 
> wrote:
>
>> Sanne, Gunnar any thoughts/input here?
>>
>>
>> On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov 
>> wrote:
>>
>>> 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 :
>>>
 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 
 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