From amits.84 at gmail.com  Wed Jul  1 03:38:18 2015
From: amits.84 at gmail.com (amit shah)
Date: Wed, 1 Jul 2015 13:08:18 +0530
Subject: [hibernate-dev] Hibernate 4 Multi-tenancy Issue - No Entity
	Persisters Found
Message-ID: <CALpK9-RwevqLs-8mY00co9qCLEMW4XZwGXZinPTYzHRMDofkww@mail.gmail.com>

Hello,

I have been trying to integrate hibernate 4 multi-tenancy support in our
application but I get the below exception on executing an hql query

java.lang.ArrayIndexOutOfBoundsException: 0
    at org.hibernate.jpa.spi.AbstractEntityManagerImpl.resultClassChecking(AbstractEntityManagerImpl.java:362)
    at org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:344)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:344)
    at com.sun.proxy.$Proxy288.createQuery(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:291)
    at com.sun.proxy.$Proxy43.createQuery(Unknown Source)

The hql query is -

List<Field> fields = entityManager.createQuery("from " +
Employee.class.getName() +
                    " where " + getQueryForInClause("id", ids),
Employee.class).getResultList();

On debugging hibernate source, I realize that this is because
hibernate's *SessionFactory
instance does not have any entityPersister instances* due to which the hql
query does have any translator's.

Is it because the Entity beans are not getting scanned? If so what could be
the cause?

The entityFactory spring is declared as below

<property name="persistenceProviderClass"
value="org.hibernate.jpa.HibernatePersistenceProvider"/><property
name="persistenceXmlLocation"
value="/com/software/persistence/persistence.xml"/><property
name="jpaProperties">
    <map>
        <entry key="hibernate.id.new_generator_mappings" value="true"/>
        <entry key="hibernate.cache.use_second_level_cache" value="false"/>
        <entry key="hibernate.dialect"
value="com.software.persistence.ExtendedOracle10gDialect"/>
        <entry key="hibernate.jdbc.batch_size" value="10"/>
        <entry key="hibernate.jdbc.batch_versioned_data" value="true"/>
        <entry key="hibernate.jdbc.batch.builder"
value="com.software.persistence.OracleBatchBuilder"/>
        <entry key="hibernate.multiTenancy" value="DATABASE"/>
        <entry key="hibernate.tenant_identifier_resolver"

value="com.software.persistence.MultitenantIdentifierResolver"/>
        <entry key="hibernate.multi_tenant_connection_provider"
                  value-ref="multiTenantConnectionProvider" />
    </map></property>

Thanks,
Amit.
P.S - Since I am not getting any traction on this on the hibernate user
forum, I am re-posting this question on the dev forum.

From karel at geovise.com  Wed Jul  1 05:57:34 2015
From: karel at geovise.com (Karel Maesen)
Date: Wed, 1 Jul 2015 11:57:34 +0200
Subject: [hibernate-dev] Problems running matrix tests
Message-ID: <087B1CA7-66CB-4007-AC5A-DB2501D08364@geovise.com>


I?v tried to run my matrix tests for hibernate-spatial and I?m running into some problems.

First problem is that setting JAVA6_HOME on OS X didn't work because Gradle apparently can?t find the runtime jar (the Home layout of JDK 1.6 on Mac seems to be non-standard). I worked around that by pointing that variable to a JDK1.7.

Next problem is that I now get an exception when I run:
$ ../gradlew -Dhibernate-matrix-databases=`pwd`/databases -Dhibernate-matrix-ignore='mysql50,mysql51,postgresql82,postgresql83,postgresql84' tasks ?stacktrace

The exception is: 
Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin [id 'hibernate-matrix-testing']
	at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:160)
	at org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:112)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyType(DefaultObjectConfigurationAction.java:113)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:36)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:80)
	at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136)
	at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46)
	at org.gradle.api.plugins.PluginAware$apply.call(Unknown Source)
	at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.groovy:34)
	at org.gradle.api.Script$apply.callCurrent(Unknown Source)
	at hibernate_core_28emj67po4a3o66dseh0ycn0w.run(/Users/maesenka/workspaces/github/hibernate-core/hibernate-core/hibernate-core.gradle:8)
	at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:74)
	... 91 more
Caused by: groovy.lang.MissingPropertyException: No such property: testReportDir for class: org.gradle.api.tasks.testing.Test_Decorated
Possible solutions: testReporter
	at org.gradle.api.internal.plugins.ExtraPropertiesDynamicObjectAdapter.setProperty(ExtraPropertiesDynamicObjectAdapter.java:46)
	at org.gradle.api.internal.CompositeDynamicObject.setProperty(CompositeDynamicObject.java:122)
	at org.gradle.api.tasks.testing.Test_Decorated.setProperty(Unknown Source)
	at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.prepareNodeTask(MatrixTestingPlugin.groovy:154)
	at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.this$2$prepareNodeTask(MatrixTestingPlugin.groovy)
	at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin$this$2$prepareNodeTask.callCurrent(Unknown Source)
	at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.apply(MatrixTestingPlugin.groovy:89)
	at org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.apply(MatrixTestingPlugin.groovy)
	at org.gradle.api.internal.plugins.ImperativeOnlyPluginApplicator.applyImperative(ImperativeOnlyPluginApplicator.java:35)
	at org.gradle.api.internal.plugins.RuleBasedPluginApplicator.applyImperative(RuleBasedPluginApplicator.java:43)
	at org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:144)
	... 102 more

Anyone an idea on what is going on here? I also tried to run this command on hibernate-core and it produced the same result. 

Regards,

Karel

From msimka at redhat.com  Wed Jul  1 06:06:25 2015
From: msimka at redhat.com (Martin Simka)
Date: Wed, 1 Jul 2015 06:06:25 -0400 (EDT)
Subject: [hibernate-dev] Problems running matrix tests
In-Reply-To: <087B1CA7-66CB-4007-AC5A-DB2501D08364@geovise.com>
References: <087B1CA7-66CB-4007-AC5A-DB2501D08364@geovise.com>
Message-ID: <254829368.24197009.1435745185269.JavaMail.zimbra@redhat.com>

Hi, 

testReportDir and testResultsDir were removed in Gradle 2.0,  check HHH-9884 for details

[1] https://hibernate.atlassian.net/browse/HHH-9884

BR,
Martin

----- Original Message -----
> From: "Karel Maesen" <karel at geovise.com>
> To: hibernate-dev at lists.jboss.org
> Sent: Wednesday, 1 July, 2015 11:57:34 AM
> Subject: [hibernate-dev] Problems running matrix tests
> 
> 
> I?v tried to run my matrix tests for hibernate-spatial and I?m running into
> some problems.
> 
> First problem is that setting JAVA6_HOME on OS X didn't work because Gradle
> apparently can?t find the runtime jar (the Home layout of JDK 1.6 on Mac
> seems to be non-standard). I worked around that by pointing that variable to
> a JDK1.7.
> 
> Next problem is that I now get an exception when I run:
> $ ../gradlew -Dhibernate-matrix-databases=`pwd`/databases
> -Dhibernate-matrix-ignore='mysql50,mysql51,postgresql82,postgresql83,postgresql84'
> tasks ?stacktrace
> 
> The exception is:
> Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed
> to apply plugin [id 'hibernate-matrix-testing']
> 	at
> 	org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:160)
> 	at
> 	org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:112)
> 	at
> 	org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyType(DefaultObjectConfigurationAction.java:113)
> 	at
> 	org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:36)
> 	at
> 	org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:80)
> 	at
> 	org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136)
> 	at
> 	org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46)
> 	at org.gradle.api.plugins.PluginAware$apply.call(Unknown Source)
> 	at
> 	org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.groovy:34)
> 	at org.gradle.api.Script$apply.callCurrent(Unknown Source)
> 	at
> 	hibernate_core_28emj67po4a3o66dseh0ycn0w.run(/Users/maesenka/workspaces/github/hibernate-core/hibernate-core/hibernate-core.gradle:8)
> 	at
> 	org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:74)
> 	... 91 more
> Caused by: groovy.lang.MissingPropertyException: No such property:
> testReportDir for class: org.gradle.api.tasks.testing.Test_Decorated
> Possible solutions: testReporter
> 	at
> 	org.gradle.api.internal.plugins.ExtraPropertiesDynamicObjectAdapter.setProperty(ExtraPropertiesDynamicObjectAdapter.java:46)
> 	at
> 	org.gradle.api.internal.CompositeDynamicObject.setProperty(CompositeDynamicObject.java:122)
> 	at org.gradle.api.tasks.testing.Test_Decorated.setProperty(Unknown Source)
> 	at
> 	org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.prepareNodeTask(MatrixTestingPlugin.groovy:154)
> 	at
> 	org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.this$2$prepareNodeTask(MatrixTestingPlugin.groovy)
> 	at
> 	org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin$this$2$prepareNodeTask.callCurrent(Unknown
> 	Source)
> 	at
> 	org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.apply(MatrixTestingPlugin.groovy:89)
> 	at
> 	org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.apply(MatrixTestingPlugin.groovy)
> 	at
> 	org.gradle.api.internal.plugins.ImperativeOnlyPluginApplicator.applyImperative(ImperativeOnlyPluginApplicator.java:35)
> 	at
> 	org.gradle.api.internal.plugins.RuleBasedPluginApplicator.applyImperative(RuleBasedPluginApplicator.java:43)
> 	at
> 	org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:144)
> 	... 102 more
> 
> Anyone an idea on what is going on here? I also tried to run this command on
> hibernate-core and it produced the same result.
> 
> Regards,
> 
> Karel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From jonathan.halliday at redhat.com  Wed Jul  1 10:59:13 2015
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Wed, 01 Jul 2015 15:59:13 +0100
Subject: [hibernate-dev] OGM embedded collection handling
Message-ID: <55940041.1040200@redhat.com>


So I'm tinkering with the cassandra OGM backend, looking particularly at 
@ElementCollection since cassandra has native collection types, use of 
which would sidestep the current limitations on List's bag semantics at 
the same time as improving performance.

The ORM core we sit on assumes that such collections map to a separate 
table, that being the Relational Way.  So assorted munging of metadata 
is needed to change that model in the backend...

At schema definition time it's necessary to identify which Tables should 
just pass though to underlying db tables and which should be intercepted 
and rewritten as embedded collection types in the owning table. (hint: 
associationKeyMetadata.getAssociationKind() == 
AssociationKind.EMBEDDED_COLLECTION)

Having picked out the ones to embed, it's then necessary to figure out 
what to embed them into. This is where things get sticky - chaining 
through to the EntityKeyMetaData's Table should reveal where the 
collection belongs, but it seems that currently 
OgmCollectionPersister.targetEntityKeyMetadata initialises that to point 
to the embedded table, not the owning entity's table.  IMO that's a bug, 
but I may be misinterpreting the intent of that metadata.  If it is 
behaving correctly, then how can the relationship information be discovered?

thanks

Jonathan.

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)

From abjitu at gmail.com  Wed Jul  1 13:05:08 2015
From: abjitu at gmail.com (Jitu)
Date: Wed, 1 Jul 2015 22:35:08 +0530
Subject: [hibernate-dev] Hibernate 4 Multi-tenancy Issue - No Entity
 Persisters Found
In-Reply-To: <CALpK9-RwevqLs-8mY00co9qCLEMW4XZwGXZinPTYzHRMDofkww@mail.gmail.com>
References: <CALpK9-RwevqLs-8mY00co9qCLEMW4XZwGXZinPTYzHRMDofkww@mail.gmail.com>
Message-ID: <CACP9B1KF_pTS08cYuSC=-A6U+R5GoV8=3Kd1q_iem1WCNYB+ww@mail.gmail.com>

As per the exception. it looks like hibernate is not not able to find
querytranslator which means hibernate is not able to translate HQL query to
SQL query. So increase log level to TRACE and provide more logs.


On Wed, Jul 1, 2015 at 1:08 PM, amit shah <amits.84 at gmail.com> wrote:

> Hello,
>
> I have been trying to integrate hibernate 4 multi-tenancy support in our
> application but I get the below exception on executing an hql query
>
> java.lang.ArrayIndexOutOfBoundsException: 0
>     at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.resultClassChecking(AbstractEntityManagerImpl.java:362)
>     at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:344)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at
> org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:344)
>     at com.sun.proxy.$Proxy288.createQuery(Unknown Source)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at
> org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:291)
>     at com.sun.proxy.$Proxy43.createQuery(Unknown Source)
>
> The hql query is -
>
> List<Field> fields = entityManager.createQuery("from " +
> Employee.class.getName() +
>                     " where " + getQueryForInClause("id", ids),
> Employee.class).getResultList();
>
> On debugging hibernate source, I realize that this is because
> hibernate's *SessionFactory
> instance does not have any entityPersister instances* due to which the hql
> query does have any translator's.
>
> Is it because the Entity beans are not getting scanned? If so what could be
> the cause?
>
> The entityFactory spring is declared as below
>
> <property name="persistenceProviderClass"
> value="org.hibernate.jpa.HibernatePersistenceProvider"/><property
> name="persistenceXmlLocation"
> value="/com/software/persistence/persistence.xml"/><property
> name="jpaProperties">
>     <map>
>         <entry key="hibernate.id.new_generator_mappings" value="true"/>
>         <entry key="hibernate.cache.use_second_level_cache" value="false"/>
>         <entry key="hibernate.dialect"
> value="com.software.persistence.ExtendedOracle10gDialect"/>
>         <entry key="hibernate.jdbc.batch_size" value="10"/>
>         <entry key="hibernate.jdbc.batch_versioned_data" value="true"/>
>         <entry key="hibernate.jdbc.batch.builder"
> value="com.software.persistence.OracleBatchBuilder"/>
>         <entry key="hibernate.multiTenancy" value="DATABASE"/>
>         <entry key="hibernate.tenant_identifier_resolver"
>
> value="com.software.persistence.MultitenantIdentifierResolver"/>
>         <entry key="hibernate.multi_tenant_connection_provider"
>                   value-ref="multiTenantConnectionProvider" />
>     </map></property>
>
> Thanks,
> Amit.
> P.S - Since I am not getting any traction on this on the hibernate user
> forum, I am re-posting this question on the dev forum.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From abjitu at gmail.com  Wed Jul  1 13:06:53 2015
From: abjitu at gmail.com (Jitu)
Date: Wed, 1 Jul 2015 22:36:53 +0530
Subject: [hibernate-dev] Hibernate 4 Multi-tenancy Issue - No Entity
 Persisters Found
In-Reply-To: <CACP9B1KF_pTS08cYuSC=-A6U+R5GoV8=3Kd1q_iem1WCNYB+ww@mail.gmail.com>
References: <CALpK9-RwevqLs-8mY00co9qCLEMW4XZwGXZinPTYzHRMDofkww@mail.gmail.com>
	<CACP9B1KF_pTS08cYuSC=-A6U+R5GoV8=3Kd1q_iem1WCNYB+ww@mail.gmail.com>
Message-ID: <CACP9B1Ky5CdgO0y8FnaCFaUat2CsCLwp_OiTgK2-5MK31r9h9g@mail.gmail.com>

I have tried hibernate 4 multi-tenancy with Spring. Please check if this
helps you in anyway https://github.com/abjitu/multitenancy

On Wed, Jul 1, 2015 at 10:35 PM, Jitu <abjitu at gmail.com> wrote:

> As per the exception. it looks like hibernate is not not able to find
> querytranslator which means hibernate is not able to translate HQL query to
> SQL query. So increase log level to TRACE and provide more logs.
>
>
> On Wed, Jul 1, 2015 at 1:08 PM, amit shah <amits.84 at gmail.com> wrote:
>
>> Hello,
>>
>> I have been trying to integrate hibernate 4 multi-tenancy support in our
>> application but I get the below exception on executing an hql query
>>
>> java.lang.ArrayIndexOutOfBoundsException: 0
>>     at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.resultClassChecking(AbstractEntityManagerImpl.java:362)
>>     at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:344)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>     at
>> org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:344)
>>     at com.sun.proxy.$Proxy288.createQuery(Unknown Source)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>     at
>> org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:291)
>>     at com.sun.proxy.$Proxy43.createQuery(Unknown Source)
>>
>> The hql query is -
>>
>> List<Field> fields = entityManager.createQuery("from " +
>> Employee.class.getName() +
>>                     " where " + getQueryForInClause("id", ids),
>> Employee.class).getResultList();
>>
>> On debugging hibernate source, I realize that this is because
>> hibernate's *SessionFactory
>> instance does not have any entityPersister instances* due to which the hql
>> query does have any translator's.
>>
>> Is it because the Entity beans are not getting scanned? If so what could
>> be
>> the cause?
>>
>> The entityFactory spring is declared as below
>>
>> <property name="persistenceProviderClass"
>> value="org.hibernate.jpa.HibernatePersistenceProvider"/><property
>> name="persistenceXmlLocation"
>> value="/com/software/persistence/persistence.xml"/><property
>> name="jpaProperties">
>>     <map>
>>         <entry key="hibernate.id.new_generator_mappings" value="true"/>
>>         <entry key="hibernate.cache.use_second_level_cache"
>> value="false"/>
>>         <entry key="hibernate.dialect"
>> value="com.software.persistence.ExtendedOracle10gDialect"/>
>>         <entry key="hibernate.jdbc.batch_size" value="10"/>
>>         <entry key="hibernate.jdbc.batch_versioned_data" value="true"/>
>>         <entry key="hibernate.jdbc.batch.builder"
>> value="com.software.persistence.OracleBatchBuilder"/>
>>         <entry key="hibernate.multiTenancy" value="DATABASE"/>
>>         <entry key="hibernate.tenant_identifier_resolver"
>>
>> value="com.software.persistence.MultitenantIdentifierResolver"/>
>>         <entry key="hibernate.multi_tenant_connection_provider"
>>                   value-ref="multiTenantConnectionProvider" />
>>     </map></property>
>>
>> Thanks,
>> Amit.
>> P.S - Since I am not getting any traction on this on the hibernate user
>> forum, I am re-posting this question on the dev forum.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From hardy at hibernate.org  Thu Jul  2 06:25:50 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 2 Jul 2015 12:25:50 +0200
Subject: [hibernate-dev] HSEARCH: Removing dynamic analyzer mapping?
In-Reply-To: <CAFm4XO2PKqPZhPDkZhw1-c0Cj2qbr4V-+TdK6ybJ829HPXP4qQ@mail.gmail.com>
References: <CAFm4XO2PKqPZhPDkZhw1-c0Cj2qbr4V-+TdK6ybJ829HPXP4qQ@mail.gmail.com>
Message-ID: <20150702102550.GA87785@Nineveh.lan>

Hi,

> This means we might need to drop our "Dynamic Analyzer" feature:
>  http://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#_dynamic_analyzer_selection

I think that seems rather harsh. 

> So, the alternatives I'm seeing:
>  # Dropping the Dynamic Analyzer feature
>  # Cheat and pass in a mutable Analyzer - needs some caution re concurrent usage
>  # Cheat and pass in a pre-analyzed Document
>  # Fork & patch the IndexWriter

What's about the alternative to close the IndexWriter and re-open it? Obviously this could be
optimised, but storing the field to analyzer map together with the open IndexWriter and only 
re-open if the mapping changes. As long as the mapping is the same the same IndexWriter can be used.
This way we could keep the feature with a potential performance hit for the people who are using it.
Still better than removing it, right? That said, what are the exact performance impacts? Did you run 
a test?

Funny enough, what the Lucene guys try to prevent by the API change can still be done, namely
by just re-opening the IndexWriter. So they are effectively forcing people who want to use this 
analyzer per document feature to go down an even more slippery slope. I would not be surprised if
this change get reverted. 

> My favourite long-term solution would be to do pre-analysis:

How would that look like and did we not once discuss exactly the opposite (aka letting even
the Document be built on the master)?

> master/slave clustering approach, that would have several other
> benefits:
>  - move the analyzer work to the slaves

Why is that a benefit? 

>  - reduce the network payloads

Really, is it actually not increasing payloads?

>  - remove the need to be able to serialize analyzers

We don't serialize analyzers afaik

--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/20150702/1904126e/attachment.bin 

From sanne at hibernate.org  Thu Jul  2 07:20:46 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 2 Jul 2015 12:20:46 +0100
Subject: [hibernate-dev] HSEARCH: Removing dynamic analyzer mapping?
In-Reply-To: <20150702102550.GA87785@Nineveh.lan>
References: <CAFm4XO2PKqPZhPDkZhw1-c0Cj2qbr4V-+TdK6ybJ829HPXP4qQ@mail.gmail.com>
	<20150702102550.GA87785@Nineveh.lan>
Message-ID: <CAFm4XO242HdXV-NPb6xaaJVmdRcUSie+Bv-U5yVkWxv1XX+JQw@mail.gmail.com>

On 2 July 2015 at 11:25, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
>> This means we might need to drop our "Dynamic Analyzer" feature:
>>  http://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#_dynamic_analyzer_selection
>
> I think that seems rather harsh.

I agree, I'd be quite unhappy if it comes to that. If we do it, we
should at least provide an alternative way to handle multi-language
indexing.
Ideally we should provide something similar to the Dynamic Analyzer
feature but which also multiplexes an entity property into multiple
fieldnames;
for example
 property "title"
    -> title_en & analyzer en
    -> title_de & analyzer de

The selection would work based on the Discriminator field, much like
the current Dynamic Analyzer.
Still, even if we were to find the bandwidth to make that, we'd need a
deprecation path for the existing feature. So for now I'm focusing on
trying to keep the existing feature to work somehow, we can then work
on the better solution as follow-up step.

>> So, the alternatives I'm seeing:
>>  # Dropping the Dynamic Analyzer feature
>>  # Cheat and pass in a mutable Analyzer - needs some caution re concurrent usage
>>  # Cheat and pass in a pre-analyzed Document
>>  # Fork & patch the IndexWriter
>
> What's about the alternative to close the IndexWriter and re-open it? Obviously this could be
> optimised, but storing the field to analyzer map together with the open IndexWriter and only
> re-open if the mapping changes. As long as the mapping is the same the same IndexWriter can be used.
> This way we could keep the feature with a potential performance hit for the people who are using it.
> Still better than removing it, right? That said, what are the exact performance impacts? Did you run
> a test?

The performace impact is huge as it would prevent you from using both
NRT and the new backend strategy to pack multiple blocks in commit
cycles;
that means the impact is in the 3 to 4 orders of magnitude in throughput.
Another problem is that you'd have to apply such a strategy in all
cases, even if they don't use Dynamic Analyzers as the backend can't
really auto-detect when such a Work item is about to be processed (I
just tried it, it's getting very hairy).

I could apply your suggestion in practice if we go for setting a flag
in the backend to change strategy, depending if any entity is using
the Discriminator feature, but beyond that we also have the problem of
different entities sharing the same index but potentially using a
different analyzer for the same named field... I'd agree with the
Lucene developers that people should really not do it, but we support
that today.

>
> Funny enough, what the Lucene guys try to prevent by the API change can still be done, namely
> by just re-opening the IndexWriter. So they are effectively forcing people who want to use this
> analyzer per document feature to go down an even more slippery slope. I would not be surprised if
> this change get reverted.

Right, there are many ways around, they are just forcing us to write
uglier and slower code. I hope they'll accommodate for it.

>
>> My favourite long-term solution would be to do pre-analysis:
>
> How would that look like and did we not once discuss exactly the opposite (aka letting even
> the Document be built on the master)?

We discussed to not create a Document instance on the slave, to only
serialize a custom serializable-friendly container, but that doesn't
prevent you to pre-tokenize the text on the slaves.
AFAIR we discussed to create a "master node" which doesn't need the
user classes so that would be an easy to start service w/o need for
much more than some configuration properties.. if you don't
pre-tokenize this configuration would still need the classes to read
our analyzer definitions from annotations.

>
>> master/slave clustering approach, that would have several other
>> benefits:
>>  - move the analyzer work to the slaves
>
> Why is that a benefit?

- removes the need to have the analyzer definitions on the master (see above).
- spreads out the CPU and memory allocations cost to each slave node:
better scalability than have it all done on the master.

>>  - reduce the network payloads
>
> Really, is it actually not increasing payloads?

I would expect so: a pre-filtered token sequence is usually smaller
than the source text, often by a good margin.

>>  - remove the need to be able to serialize analyzers
>
> We don't serialize analyzers afaik

Right, not sure why I wrote that. I was probably thinking of the
Map<fieldName, AnalyzerName> which we ship with each Work to the
backend to apply custom overrides.. a little simplification but not a
big win.

Sanne

>
> --Hardy

From hardy at hibernate.org  Thu Jul  2 07:50:31 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 2 Jul 2015 13:50:31 +0200
Subject: [hibernate-dev] HSEARCH: Removing dynamic analyzer mapping?
In-Reply-To: <CAFm4XO242HdXV-NPb6xaaJVmdRcUSie+Bv-U5yVkWxv1XX+JQw@mail.gmail.com>
References: <CAFm4XO2PKqPZhPDkZhw1-c0Cj2qbr4V-+TdK6ybJ829HPXP4qQ@mail.gmail.com>
	<20150702102550.GA87785@Nineveh.lan>
	<CAFm4XO242HdXV-NPb6xaaJVmdRcUSie+Bv-U5yVkWxv1XX+JQw@mail.gmail.com>
Message-ID: <20150702115031.GB87785@Nineveh.lan>

Hi,

On Thu, Jul 02, 2015 at 12:20:46PM +0100, Sanne Grinovero wrote:
> Ideally we should provide something similar to the Dynamic Analyzer
> feature but which also multiplexes an entity property into multiple
> fieldnames;
> for example
>  property "title"
>     -> title_en & analyzer en
>     -> title_de & analyzer de
> 
> The selection would work based on the Discriminator field, much like
> the current Dynamic Analyzer.

That might be a possibility, even though I am not quite sure how exactly this would
look like. I would first need to dig in more into the existing code.
Do you have a more concrete idea on how this would look like?

> Still, even if we were to find the bandwidth to make that, we'd need a
> deprecation path for the existing feature

Well, in the above case we are not talking about deprecation right? It would be more of
a change in behavior and use!?

> > What's about the alternative to close the IndexWriter and re-open it? Obviously this could be
> > optimised, but storing the field to analyzer map together with the open IndexWriter and only
> > re-open if the mapping changes. As long as the mapping is the same the same IndexWriter can be used.
> > This way we could keep the feature with a potential performance hit for the people who are using it.
> > Still better than removing it, right? That said, what are the exact performance impacts? Did you run
> > a test?
> 
> The performace impact is huge as it would prevent you from using both
> NRT and the new backend strategy to pack multiple blocks in commit
> cycles;
> that means the impact is in the 3 to 4 orders of magnitude in throughput.

Might be still worth testing and prototyping. 

> I could apply your suggestion in practice if we go for setting a flag
> in the backend to change strategy, depending if any entity is using
> the Discriminator feature, 

That would work for me.

> but beyond that we also have the problem of
> different entities sharing the same index but potentially using a
> different analyzer for the same named field... I'd agree with the
> Lucene developers that people should really not do it, but we support
> that today.

Ok. In this case I am more inclined to enforce the same analyzer.

> > How would that look like and did we not once discuss exactly the opposite (aka letting even
> > the Document be built on the master)?
> 
> We discussed to not create a Document instance on the slave, to only
> serialize a custom serializable-friendly container, but that doesn't
> prevent you to pre-tokenize the text on the slaves.
> AFAIR we discussed to create a "master node" which doesn't need the
> user classes so that would be an easy to start service w/o need for
> much more than some configuration properties.. if you don't
> pre-tokenize this configuration would still need the classes to read
> our analyzer definitions from annotations.

Ok, that is possible as well. I think we discussed both and I was indeed
referring to the approach where the master node would do the index using 
user classes and the corresponding Search metadata. 

I like the solution you are referring to much better, since it also works
better with the ideas I have regarding the clustering of the index (eg with
RAFT). As you suggest, it would be beneficial if only the slaves would need
to know about the user classes.

> >> master/slave clustering approach, that would have several other
> >> benefits:
> >>  - move the analyzer work to the slaves
> >
> > Why is that a benefit?
> 
> - removes the need to have the analyzer definitions on the master (see above).

Ok, in the light of the above discussed solution, you would not need the analyzers
on the master node. Not sure whether this such an important thing so. 

> - spreads out the CPU and memory allocations cost to each slave node:
> better scalability than have it all done on the master

Well, one could also take the point of view that the slaves should do as little as possible
and let the master do the heavy lifting. It depends really for what you are optimizing imo.

> >>  - reduce the network payloads
> >
> > Really, is it actually not increasing payloads?
> 
> I would expect so: a pre-filtered token sequence is usually smaller
> than the source text, often by a good margin.

True, in the usual cases that is probably the case.

--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/20150702/eb9a59e0/attachment.bin 

From gunnar at hibernate.org  Thu Jul  2 07:53:48 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 2 Jul 2015 13:53:48 +0200
Subject: [hibernate-dev] OGM options and ORM 5 bootstrap
Message-ID: <CADGJaX8n6xORdd4wYFLOB_nO1NeEG6ykxdmXVRvWGBfY6c94qQ@mail.gmail.com>

Hi Emmanuel, all,

Prior to ORM 5, we used to have OgmConfiguration (sub-class of the dreaded
Configuration), which provided an entry point into our custom option API:

    OgmConfiguration config = ...
    config.configureOptionsFor( MongoDB.class )
        .associationStorage(IN_ENTITY)
        ...
    OgmSessionFactory osf = config.buildSessionFactory();

Now as of my current in-flight branch of migrating over to ORM 5, the
equivalent is writing a configurator callback (which also is the only way
today to do it under JPA):

    public class MyConfigurator extends OptionConfigurator {
        public void configure(Configurable configurable) {
            configurable.configureOptionsFor( MongoDB.class )
                .associationStorage(IN_ENTITY)
        }
    }

And then plugging it in like so:

    OgmSessionFactory osf = new MetadataSources(
        new StandardServiceRegistryBuilder()
                .applySetting( "hibernate.ogm.option.configurator",
MyConfigurator.class )
                .build();
         )
        .buildMetadata()
        .getSessionFactoryBuilder()
        .unwrap( OgmSessionFactoryBuilder.class )
        .build();

Do you consider that good enough? The alternative would be providing our
own OgmStandardServiceRegistryBuilder or some unwrap on
StandardServiceRegistryBuilder (it has to be that early, because the
datastore provider service lives in that service registry, and it may
consume settings such as the global write concern which is passed to
MongoDB when connecting). Personally I think what we have is good enough.

Thanks,

--Gunnar

From emmanuel at hibernate.org  Thu Jul  2 10:47:50 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 2 Jul 2015 16:47:50 +0200
Subject: [hibernate-dev] OGM options and ORM 5 bootstrap
In-Reply-To: <CADGJaX8n6xORdd4wYFLOB_nO1NeEG6ykxdmXVRvWGBfY6c94qQ@mail.gmail.com>
References: <CADGJaX8n6xORdd4wYFLOB_nO1NeEG6ykxdmXVRvWGBfY6c94qQ@mail.gmail.com>
Message-ID: <E36C2561-EDC8-4FC1-8757-CC6DB7B51AAB@hibernate.org>

I?m torn.
I anticipate that the option programmatic API will be very commonly used, especially when we start bringing new things like custom denormalisation.
It looks quite verbose for a single setting change :/ Is that how all property changes will have to be done in native Hibernate ORM bootstrapping? Or is that not really a user API and people are expected to use JPA?s bootstrap API?
How would the solution look like with an OgmStandardServiceRegistryBuilder?

Emmanuel


> On 02 Jul 2015, at 13:53, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi Emmanuel, all,
> 
> Prior to ORM 5, we used to have OgmConfiguration (sub-class of the dreaded
> Configuration), which provided an entry point into our custom option API:
> 
>    OgmConfiguration config = ...
>    config.configureOptionsFor( MongoDB.class )
>        .associationStorage(IN_ENTITY)
>        ...
>    OgmSessionFactory osf = config.buildSessionFactory();
> 
> Now as of my current in-flight branch of migrating over to ORM 5, the
> equivalent is writing a configurator callback (which also is the only way
> today to do it under JPA):
> 
>    public class MyConfigurator extends OptionConfigurator {
>        public void configure(Configurable configurable) {
>            configurable.configureOptionsFor( MongoDB.class )
>                .associationStorage(IN_ENTITY)
>        }
>    }
> 
> And then plugging it in like so:
> 
>    OgmSessionFactory osf = new MetadataSources(
>        new StandardServiceRegistryBuilder()
>                .applySetting( "hibernate.ogm.option.configurator",
> MyConfigurator.class )
>                .build();
>         )
>        .buildMetadata()
>        .getSessionFactoryBuilder()
>        .unwrap( OgmSessionFactoryBuilder.class )
>        .build();
> 
> Do you consider that good enough? The alternative would be providing our
> own OgmStandardServiceRegistryBuilder or some unwrap on
> StandardServiceRegistryBuilder (it has to be that early, because the
> datastore provider service lives in that service registry, and it may
> consume settings such as the global write concern which is passed to
> MongoDB when connecting). Personally I think what we have is good enough.
> 
> Thanks,
> 
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From sanne at hibernate.org  Thu Jul  2 12:24:21 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 2 Jul 2015 17:24:21 +0100
Subject: [hibernate-dev] HSEARCH: Removing dynamic analyzer mapping?
In-Reply-To: <20150702115031.GB87785@Nineveh.lan>
References: <CAFm4XO2PKqPZhPDkZhw1-c0Cj2qbr4V-+TdK6ybJ829HPXP4qQ@mail.gmail.com>
	<20150702102550.GA87785@Nineveh.lan>
	<CAFm4XO242HdXV-NPb6xaaJVmdRcUSie+Bv-U5yVkWxv1XX+JQw@mail.gmail.com>
	<20150702115031.GB87785@Nineveh.lan>
Message-ID: <CAFm4XO2DySj=-hyL8Lhw-zGkDgJYdL6JoDwbQTqN=jdf9LR-Zw@mail.gmail.com>

On 2 July 2015 at 12:50, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> On Thu, Jul 02, 2015 at 12:20:46PM +0100, Sanne Grinovero wrote:
>> Ideally we should provide something similar to the Dynamic Analyzer
>> feature but which also multiplexes an entity property into multiple
>> fieldnames;
>> for example
>>  property "title"
>>     -> title_en & analyzer en
>>     -> title_de & analyzer de
>>
>> The selection would work based on the Discriminator field, much like
>> the current Dynamic Analyzer.
>
> That might be a possibility, even though I am not quite sure how exactly this would
> look like. I would first need to dig in more into the existing code.
> Do you have a more concrete idea on how this would look like?

I did not sketch an implementation.

>> Still, even if we were to find the bandwidth to make that, we'd need a
>> deprecation path for the existing feature
>
> Well, in the above case we are not talking about deprecation right? It would be more of
> a change in behavior and use!?

Right, the above example would be quite different, for example queries
would need to target the right field - and using the right analyzer -
and that would need explicit user input.
So to provide a deprecation path, we'd need a version which supports
both approaches so that people can move from one to the other.. which
implies keeping the existing model around for a little longer, which
is problematic.
In other words, discussing a better solution is good but doesn't avoid
the need to keep the existing functionality around.

>
>> > What's about the alternative to close the IndexWriter and re-open it? Obviously this could be
>> > optimised, but storing the field to analyzer map together with the open IndexWriter and only
>> > re-open if the mapping changes. As long as the mapping is the same the same IndexWriter can be used.
>> > This way we could keep the feature with a potential performance hit for the people who are using it.
>> > Still better than removing it, right? That said, what are the exact performance impacts? Did you run
>> > a test?
>>
>> The performace impact is huge as it would prevent you from using both
>> NRT and the new backend strategy to pack multiple blocks in commit
>> cycles;
>> that means the impact is in the 3 to 4 orders of magnitude in throughput.
>
> Might be still worth testing and prototyping.
>
>> I could apply your suggestion in practice if we go for setting a flag
>> in the backend to change strategy, depending if any entity is using
>> the Discriminator feature,
>
> That would work for me.
>
>> but beyond that we also have the problem of
>> different entities sharing the same index but potentially using a
>> different analyzer for the same named field... I'd agree with the
>> Lucene developers that people should really not do it, but we support
>> that today.
>
> Ok. In this case I am more inclined to enforce the same analyzer.

Right, especially as we can detect the inconsistency at boot time and
raise an appropriate warning.
In this case I'd not expect a nice deprecation path as the existing
usage (if any user did this) would have been problematic already.

>
>> > How would that look like and did we not once discuss exactly the opposite (aka letting even
>> > the Document be built on the master)?
>>
>> We discussed to not create a Document instance on the slave, to only
>> serialize a custom serializable-friendly container, but that doesn't
>> prevent you to pre-tokenize the text on the slaves.
>> AFAIR we discussed to create a "master node" which doesn't need the
>> user classes so that would be an easy to start service w/o need for
>> much more than some configuration properties.. if you don't
>> pre-tokenize this configuration would still need the classes to read
>> our analyzer definitions from annotations.
>
> Ok, that is possible as well. I think we discussed both and I was indeed
> referring to the approach where the master node would do the index using
> user classes and the corresponding Search metadata.
>
> I like the solution you are referring to much better, since it also works
> better with the ideas I have regarding the clustering of the index (eg with
> RAFT). As you suggest, it would be beneficial if only the slaves would need
> to know about the user classes.

+1

>
>> >> master/slave clustering approach, that would have several other
>> >> benefits:
>> >>  - move the analyzer work to the slaves
>> >
>> > Why is that a benefit?
>>
>> - removes the need to have the analyzer definitions on the master (see above).
>
> Ok, in the light of the above discussed solution, you would not need the analyzers
> on the master node. Not sure whether this such an important thing so.

Above you said you like it much better to not need the user classes on
the master.
We build the analyzers from the annotations on the user classes - not
least we allow the user to provide custom analyzer implementations.
So avoiding the need to have the analyzers on the master node is a
pre-requisite to get rid of the user classes.

>
>> - spreads out the CPU and memory allocations cost to each slave node:
>> better scalability than have it all done on the master
>
> Well, one could also take the point of view that the slaves should do as little as possible
> and let the master do the heavy lifting. It depends really for what you are optimizing imo.

Good point, one might prefer the opposite. But by decoupling the chain:
  entity -> [tokenizing && indexwriting]
into
  entity -> tokenizing -> indexwriting
Then you can easily provide an option to let the user make this choice
about were you want the tokenizing to happen.

I'd wager though that most will want to favour scalability, so I'd
implement that first.

>> >>  - reduce the network payloads
>> >
>> > Really, is it actually not increasing payloads?
>>
>> I would expect so: a pre-filtered token sequence is usually smaller
>> than the source text, often by a good margin.
>
> True, in the usual cases that is probably the case.

I can only think of the opposite to happen in context of information
enrichment, such as Apache UIMA or Stanbol, but in these cases the
high level of computation would even more want you to choose for
scalability, i.e. pre-process each case on the slave rather than
killing your master nodes.

Anyway, nice brainstorming but I'm not even sure how feasible it would
be to do pre-processing without the IndexWriter :)

Sanne

From gunnar at hibernate.org  Fri Jul  3 04:27:37 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 3 Jul 2015 10:27:37 +0200
Subject: [hibernate-dev] OGM options and ORM 5 bootstrap
In-Reply-To: <E36C2561-EDC8-4FC1-8757-CC6DB7B51AAB@hibernate.org>
References: <CADGJaX8n6xORdd4wYFLOB_nO1NeEG6ykxdmXVRvWGBfY6c94qQ@mail.gmail.com>
	<E36C2561-EDC8-4FC1-8757-CC6DB7B51AAB@hibernate.org>
Message-ID: <CADGJaX86Cx8EB=com6KCdUdz9C_95YM502ic4RPXsB7c4YiAUA@mail.gmail.com>

2015-07-02 16:47 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I?m torn.
> I anticipate that the option programmatic API will be very commonly used,
> especially when we start bringing new things like custom denormalisation.
> It looks quite verbose for a single setting change :/ Is that how all
> property changes will have to be done in native Hibernate ORM
> bootstrapping? Or is that not really a user API and people are expected to
> use JPA?s bootstrap API?
>

AFAICS, it'd be the way for bootstrapping native Hibernate. Note that for
most settings there are proper typed setters on MetadataBuilder. Things
like dialect, user name etc. can be configured through props in the usual
files, the same could be done for our OGM configurator class name.


> How would the solution look like with an OgmStandardServiceRegistryBuilder?
>

The problem is that the option API allows to set things possibly needed by
the datastore provider. Which is a service in the standard service
registry, so we cannot apply these configurations only at the
(Ogm)SessionFactoryBuilder level, that'd be too late.

The following would be possible:

    OgmStandardServiceRegistryBuilder ossrb = new
OgmStandardServiceRegistryBuilder();
    ossrb.configureOptionsFor( MongoDB.class )
        .associationStorage(IN_ENTITY);

    OgmSessionFactory osf = new MetadataSources( ossrb.build() )
        .buildMetadata()
        .getSessionFactoryBuilder()
        .unwrap( OgmSessionFactoryBuilder.class )
        .build();

I wouldn't like it too much though because it seems very odd to have these
mapping options exposed at that level.

One alternative would be to make DatastoreProvider a service of the
SessionFactory service registry; Then these options could be configured at
a later point (e.g. an OGM-specific MetadataBuilder impl as discussed in
the other mail, or on our SessionFactoryBuilder) which seems nicer. It'd
require though that the operations of GridDialect (which is a standard
service itself, and I think it needs to stay that way as it is exposed
through OgmDialect to id generators) receive DatastoreProvider as parameter.

Or we don't support configurator options targeting DatastoreProvider (which
may be fine, e.g. write concern/read pref in MongoDB can be passed to all
driver ops, so there is no strong need to pass them upon connection
creation).

Personally I think specifying the configurator FQN as prop e.g. in
hibernate.cfg.xml is acceptable (similar to what you did for JPA).



> Emmanuel
>
>
> > On 02 Jul 2015, at 13:53, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > Hi Emmanuel, all,
> >
> > Prior to ORM 5, we used to have OgmConfiguration (sub-class of the
> dreaded
> > Configuration), which provided an entry point into our custom option API:
> >
> >    OgmConfiguration config = ...
> >    config.configureOptionsFor( MongoDB.class )
> >        .associationStorage(IN_ENTITY)
> >        ...
> >    OgmSessionFactory osf = config.buildSessionFactory();
> >
> > Now as of my current in-flight branch of migrating over to ORM 5, the
> > equivalent is writing a configurator callback (which also is the only way
> > today to do it under JPA):
> >
> >    public class MyConfigurator extends OptionConfigurator {
> >        public void configure(Configurable configurable) {
> >            configurable.configureOptionsFor( MongoDB.class )
> >                .associationStorage(IN_ENTITY)
> >        }
> >    }
> >
> > And then plugging it in like so:
> >
> >    OgmSessionFactory osf = new MetadataSources(
> >        new StandardServiceRegistryBuilder()
> >                .applySetting( "hibernate.ogm.option.configurator",
> > MyConfigurator.class )
> >                .build();
> >         )
> >        .buildMetadata()
> >        .getSessionFactoryBuilder()
> >        .unwrap( OgmSessionFactoryBuilder.class )
> >        .build();
> >
> > Do you consider that good enough? The alternative would be providing our
> > own OgmStandardServiceRegistryBuilder or some unwrap on
> > StandardServiceRegistryBuilder (it has to be that early, because the
> > datastore provider service lives in that service registry, and it may
> > consume settings such as the global write concern which is passed to
> > MongoDB when connecting). Personally I think what we have is good enough.
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Fri Jul  3 04:53:46 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 3 Jul 2015 10:53:46 +0200
Subject: [hibernate-dev] HSEARCH: Removing dynamic analyzer mapping?
In-Reply-To: <CAFm4XO2DySj=-hyL8Lhw-zGkDgJYdL6JoDwbQTqN=jdf9LR-Zw@mail.gmail.com>
References: <CAFm4XO2PKqPZhPDkZhw1-c0Cj2qbr4V-+TdK6ybJ829HPXP4qQ@mail.gmail.com>
	<20150702102550.GA87785@Nineveh.lan>
	<CAFm4XO242HdXV-NPb6xaaJVmdRcUSie+Bv-U5yVkWxv1XX+JQw@mail.gmail.com>
	<20150702115031.GB87785@Nineveh.lan>
	<CAFm4XO2DySj=-hyL8Lhw-zGkDgJYdL6JoDwbQTqN=jdf9LR-Zw@mail.gmail.com>
Message-ID: <CADGJaX_Af=YdZw7D1qMLkRkHXekuUdfJSK6ZG43Jtbm-5YUxWQ@mail.gmail.com>

> Anyway, nice brainstorming but I'm not even sure how feasible it would
be to do pre-processing without the IndexWriter :)

Where/when is that pre-processing happening today? IMO we must start and
consider non-Lucene backends in all our plans.



2015-07-02 18:24 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 2 July 2015 at 12:50, Hardy Ferentschik <hardy at hibernate.org> wrote:
> > Hi,
> >
> > On Thu, Jul 02, 2015 at 12:20:46PM +0100, Sanne Grinovero wrote:
> >> Ideally we should provide something similar to the Dynamic Analyzer
> >> feature but which also multiplexes an entity property into multiple
> >> fieldnames;
> >> for example
> >>  property "title"
> >>     -> title_en & analyzer en
> >>     -> title_de & analyzer de
> >>
> >> The selection would work based on the Discriminator field, much like
> >> the current Dynamic Analyzer.
> >
> > That might be a possibility, even though I am not quite sure how exactly
> this would
> > look like. I would first need to dig in more into the existing code.
> > Do you have a more concrete idea on how this would look like?
>
> I did not sketch an implementation.
>
> >> Still, even if we were to find the bandwidth to make that, we'd need a
> >> deprecation path for the existing feature
> >
> > Well, in the above case we are not talking about deprecation right? It
> would be more of
> > a change in behavior and use!?
>
> Right, the above example would be quite different, for example queries
> would need to target the right field - and using the right analyzer -
> and that would need explicit user input.
> So to provide a deprecation path, we'd need a version which supports
> both approaches so that people can move from one to the other.. which
> implies keeping the existing model around for a little longer, which
> is problematic.
> In other words, discussing a better solution is good but doesn't avoid
> the need to keep the existing functionality around.
>
> >
> >> > What's about the alternative to close the IndexWriter and re-open it?
> Obviously this could be
> >> > optimised, but storing the field to analyzer map together with the
> open IndexWriter and only
> >> > re-open if the mapping changes. As long as the mapping is the same
> the same IndexWriter can be used.
> >> > This way we could keep the feature with a potential performance hit
> for the people who are using it.
> >> > Still better than removing it, right? That said, what are the exact
> performance impacts? Did you run
> >> > a test?
> >>
> >> The performace impact is huge as it would prevent you from using both
> >> NRT and the new backend strategy to pack multiple blocks in commit
> >> cycles;
> >> that means the impact is in the 3 to 4 orders of magnitude in
> throughput.
> >
> > Might be still worth testing and prototyping.
> >
> >> I could apply your suggestion in practice if we go for setting a flag
> >> in the backend to change strategy, depending if any entity is using
> >> the Discriminator feature,
> >
> > That would work for me.
> >
> >> but beyond that we also have the problem of
> >> different entities sharing the same index but potentially using a
> >> different analyzer for the same named field... I'd agree with the
> >> Lucene developers that people should really not do it, but we support
> >> that today.
> >
> > Ok. In this case I am more inclined to enforce the same analyzer.
>
> Right, especially as we can detect the inconsistency at boot time and
> raise an appropriate warning.
> In this case I'd not expect a nice deprecation path as the existing
> usage (if any user did this) would have been problematic already.
>
> >
> >> > How would that look like and did we not once discuss exactly the
> opposite (aka letting even
> >> > the Document be built on the master)?
> >>
> >> We discussed to not create a Document instance on the slave, to only
> >> serialize a custom serializable-friendly container, but that doesn't
> >> prevent you to pre-tokenize the text on the slaves.
> >> AFAIR we discussed to create a "master node" which doesn't need the
> >> user classes so that would be an easy to start service w/o need for
> >> much more than some configuration properties.. if you don't
> >> pre-tokenize this configuration would still need the classes to read
> >> our analyzer definitions from annotations.
> >
> > Ok, that is possible as well. I think we discussed both and I was indeed
> > referring to the approach where the master node would do the index using
> > user classes and the corresponding Search metadata.
> >
> > I like the solution you are referring to much better, since it also works
> > better with the ideas I have regarding the clustering of the index (eg
> with
> > RAFT). As you suggest, it would be beneficial if only the slaves would
> need
> > to know about the user classes.
>
> +1
>
> >
> >> >> master/slave clustering approach, that would have several other
> >> >> benefits:
> >> >>  - move the analyzer work to the slaves
> >> >
> >> > Why is that a benefit?
> >>
> >> - removes the need to have the analyzer definitions on the master (see
> above).
> >
> > Ok, in the light of the above discussed solution, you would not need the
> analyzers
> > on the master node. Not sure whether this such an important thing so.
>
> Above you said you like it much better to not need the user classes on
> the master.
> We build the analyzers from the annotations on the user classes - not
> least we allow the user to provide custom analyzer implementations.
> So avoiding the need to have the analyzers on the master node is a
> pre-requisite to get rid of the user classes.
>
> >
> >> - spreads out the CPU and memory allocations cost to each slave node:
> >> better scalability than have it all done on the master
> >
> > Well, one could also take the point of view that the slaves should do as
> little as possible
> > and let the master do the heavy lifting. It depends really for what you
> are optimizing imo.
>
> Good point, one might prefer the opposite. But by decoupling the chain:
>   entity -> [tokenizing && indexwriting]
> into
>   entity -> tokenizing -> indexwriting
> Then you can easily provide an option to let the user make this choice
> about were you want the tokenizing to happen.
>
> I'd wager though that most will want to favour scalability, so I'd
> implement that first.
>
> >> >>  - reduce the network payloads
> >> >
> >> > Really, is it actually not increasing payloads?
> >>
> >> I would expect so: a pre-filtered token sequence is usually smaller
> >> than the source text, often by a good margin.
> >
> > True, in the usual cases that is probably the case.
>
> I can only think of the opposite to happen in context of information
> enrichment, such as Apache UIMA or Stanbol, but in these cases the
> high level of computation would even more want you to choose for
> scalability, i.e. pre-process each case on the slave rather than
> killing your master nodes.
>
> Anyway, nice brainstorming but I'm not even sure how feasible it would
> be to do pre-processing without the IndexWriter :)
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Jul  3 05:14:41 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 3 Jul 2015 10:14:41 +0100
Subject: [hibernate-dev] HSEARCH: Removing dynamic analyzer mapping?
In-Reply-To: <CADGJaX_Af=YdZw7D1qMLkRkHXekuUdfJSK6ZG43Jtbm-5YUxWQ@mail.gmail.com>
References: <CAFm4XO2PKqPZhPDkZhw1-c0Cj2qbr4V-+TdK6ybJ829HPXP4qQ@mail.gmail.com>
	<20150702102550.GA87785@Nineveh.lan>
	<CAFm4XO242HdXV-NPb6xaaJVmdRcUSie+Bv-U5yVkWxv1XX+JQw@mail.gmail.com>
	<20150702115031.GB87785@Nineveh.lan>
	<CAFm4XO2DySj=-hyL8Lhw-zGkDgJYdL6JoDwbQTqN=jdf9LR-Zw@mail.gmail.com>
	<CADGJaX_Af=YdZw7D1qMLkRkHXekuUdfJSK6ZG43Jtbm-5YUxWQ@mail.gmail.com>
Message-ID: <CAFm4XO0DDnOpq2Sd3SZ7P9aGJm6GXFZr0g178AbCeBmM0xp55A@mail.gmail.com>

On 3 July 2015 at 09:53, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Anyway, nice brainstorming but I'm not even sure how feasible it would
> be to do pre-processing without the IndexWriter :)
>
> Where/when is that pre-processing happening today? IMO we must start and
> consider non-Lucene backends in all our plans.

Today the tokenization (analysis) happens during indexwriting:

  indexWriter.addDocument( Document d, Analyzer a );

We don't do pre-processing, which is what I'm suggesting we might want
to do to avoid these problems, and like you say it might help with
other backends.
Keep in mind that the alternative backends we're aiming at are all
"Lucene based" though.. they certainly support performing the analysis
on their side so this isn't the only way.
If we decide to rely on their own analysis capabilities, we'll need to
be have these configured in some specific way to match our needs;
since today we have a nice set of annotations to define these options,
there's a risk of having the user to have to maintain duplicate
declarations.
So we'll either have the user configure them manually to match our
expectations, or we do pre-processing, or we generate configuration
files, or maybe we can directly "set" the configuration automatically.

What they all have in common, is the mapping fieldname -> Analyzer
Chain needs to be consistent, but we gave more flexibility away.


>
>
>
> 2015-07-02 18:24 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 2 July 2015 at 12:50, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> > Hi,
>> >
>> > On Thu, Jul 02, 2015 at 12:20:46PM +0100, Sanne Grinovero wrote:
>> >> Ideally we should provide something similar to the Dynamic Analyzer
>> >> feature but which also multiplexes an entity property into multiple
>> >> fieldnames;
>> >> for example
>> >>  property "title"
>> >>     -> title_en & analyzer en
>> >>     -> title_de & analyzer de
>> >>
>> >> The selection would work based on the Discriminator field, much like
>> >> the current Dynamic Analyzer.
>> >
>> > That might be a possibility, even though I am not quite sure how exactly
>> > this would
>> > look like. I would first need to dig in more into the existing code.
>> > Do you have a more concrete idea on how this would look like?
>>
>> I did not sketch an implementation.
>>
>> >> Still, even if we were to find the bandwidth to make that, we'd need a
>> >> deprecation path for the existing feature
>> >
>> > Well, in the above case we are not talking about deprecation right? It
>> > would be more of
>> > a change in behavior and use!?
>>
>> Right, the above example would be quite different, for example queries
>> would need to target the right field - and using the right analyzer -
>> and that would need explicit user input.
>> So to provide a deprecation path, we'd need a version which supports
>> both approaches so that people can move from one to the other.. which
>> implies keeping the existing model around for a little longer, which
>> is problematic.
>> In other words, discussing a better solution is good but doesn't avoid
>> the need to keep the existing functionality around.
>>
>> >
>> >> > What's about the alternative to close the IndexWriter and re-open it?
>> >> > Obviously this could be
>> >> > optimised, but storing the field to analyzer map together with the
>> >> > open IndexWriter and only
>> >> > re-open if the mapping changes. As long as the mapping is the same
>> >> > the same IndexWriter can be used.
>> >> > This way we could keep the feature with a potential performance hit
>> >> > for the people who are using it.
>> >> > Still better than removing it, right? That said, what are the exact
>> >> > performance impacts? Did you run
>> >> > a test?
>> >>
>> >> The performace impact is huge as it would prevent you from using both
>> >> NRT and the new backend strategy to pack multiple blocks in commit
>> >> cycles;
>> >> that means the impact is in the 3 to 4 orders of magnitude in
>> >> throughput.
>> >
>> > Might be still worth testing and prototyping.
>> >
>> >> I could apply your suggestion in practice if we go for setting a flag
>> >> in the backend to change strategy, depending if any entity is using
>> >> the Discriminator feature,
>> >
>> > That would work for me.
>> >
>> >> but beyond that we also have the problem of
>> >> different entities sharing the same index but potentially using a
>> >> different analyzer for the same named field... I'd agree with the
>> >> Lucene developers that people should really not do it, but we support
>> >> that today.
>> >
>> > Ok. In this case I am more inclined to enforce the same analyzer.
>>
>> Right, especially as we can detect the inconsistency at boot time and
>> raise an appropriate warning.
>> In this case I'd not expect a nice deprecation path as the existing
>> usage (if any user did this) would have been problematic already.
>>
>> >
>> >> > How would that look like and did we not once discuss exactly the
>> >> > opposite (aka letting even
>> >> > the Document be built on the master)?
>> >>
>> >> We discussed to not create a Document instance on the slave, to only
>> >> serialize a custom serializable-friendly container, but that doesn't
>> >> prevent you to pre-tokenize the text on the slaves.
>> >> AFAIR we discussed to create a "master node" which doesn't need the
>> >> user classes so that would be an easy to start service w/o need for
>> >> much more than some configuration properties.. if you don't
>> >> pre-tokenize this configuration would still need the classes to read
>> >> our analyzer definitions from annotations.
>> >
>> > Ok, that is possible as well. I think we discussed both and I was indeed
>> > referring to the approach where the master node would do the index using
>> > user classes and the corresponding Search metadata.
>> >
>> > I like the solution you are referring to much better, since it also
>> > works
>> > better with the ideas I have regarding the clustering of the index (eg
>> > with
>> > RAFT). As you suggest, it would be beneficial if only the slaves would
>> > need
>> > to know about the user classes.
>>
>> +1
>>
>> >
>> >> >> master/slave clustering approach, that would have several other
>> >> >> benefits:
>> >> >>  - move the analyzer work to the slaves
>> >> >
>> >> > Why is that a benefit?
>> >>
>> >> - removes the need to have the analyzer definitions on the master (see
>> >> above).
>> >
>> > Ok, in the light of the above discussed solution, you would not need the
>> > analyzers
>> > on the master node. Not sure whether this such an important thing so.
>>
>> Above you said you like it much better to not need the user classes on
>> the master.
>> We build the analyzers from the annotations on the user classes - not
>> least we allow the user to provide custom analyzer implementations.
>> So avoiding the need to have the analyzers on the master node is a
>> pre-requisite to get rid of the user classes.
>>
>> >
>> >> - spreads out the CPU and memory allocations cost to each slave node:
>> >> better scalability than have it all done on the master
>> >
>> > Well, one could also take the point of view that the slaves should do as
>> > little as possible
>> > and let the master do the heavy lifting. It depends really for what you
>> > are optimizing imo.
>>
>> Good point, one might prefer the opposite. But by decoupling the chain:
>>   entity -> [tokenizing && indexwriting]
>> into
>>   entity -> tokenizing -> indexwriting
>> Then you can easily provide an option to let the user make this choice
>> about were you want the tokenizing to happen.
>>
>> I'd wager though that most will want to favour scalability, so I'd
>> implement that first.
>>
>> >> >>  - reduce the network payloads
>> >> >
>> >> > Really, is it actually not increasing payloads?
>> >>
>> >> I would expect so: a pre-filtered token sequence is usually smaller
>> >> than the source text, often by a good margin.
>> >
>> > True, in the usual cases that is probably the case.
>>
>> I can only think of the opposite to happen in context of information
>> enrichment, such as Apache UIMA or Stanbol, but in these cases the
>> high level of computation would even more want you to choose for
>> scalability, i.e. pre-process each case on the slave rather than
>> killing your master nodes.
>>
>> Anyway, nice brainstorming but I'm not even sure how feasible it would
>> be to do pre-processing without the IndexWriter :)
>>
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Sun Jul  5 15:43:35 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 5 Jul 2015 20:43:35 +0100
Subject: [hibernate-dev] Building snapshots of Hibernate ORM / master
Message-ID: <CAFm4XO1mApDfDXGA2KxY1eQN3hSKRszfvW5_uG1QSzzf-cT38g@mail.gmail.com>

Hi all,
I'm trying to build Hibernate ORM's latest to try debugging some of
the latest changes for Wildfly and Search integrations.

The README mentions I should be able to

 ./gradlew clean publishToMavenLocal

but that fails on the hibernate-osgi module. I then tried "publish" to
upload a snapshot, but that prouces the same error message:

:hibernate-osgi:publishMavenJavaPublicationToJboss-snapshots-repositoryRepository
FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task
':hibernate-osgi:publishMavenJavaPublicationToJboss-snapshots-repositoryRepository'.
> Failed to publish publication 'mavenJava' to repository 'jboss-snapshots-repository'
   > Invalid publication 'mavenJava': artifact file does not exist:
'/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.1-SNAPSHOT-karaf.xml'

On the version, I was expecting it to build some "5.0.0-SHAPSHOT" but
it's actually building a "5.0.1-SNAPSHOT",  is that expected?

I was hoping I could ignore the osgi module and take what it built to
experiment with Scott's branch, but while on HHH-9887 he mentions
being down to two failures, I'm having still dozens of failures so I
suspect I'll need some advice on the build.

Scott, could you share which exact commit id did you use to test
Hibernate ORM on your branch "hibernate5_july2", and how I can build
it like yours ?

Thanks,
Sanne

From steve at hibernate.org  Sun Jul  5 16:50:47 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 05 Jul 2015 20:50:47 +0000
Subject: [hibernate-dev] Building snapshots of Hibernate ORM / master
In-Reply-To: <CAFm4XO1mApDfDXGA2KxY1eQN3hSKRszfvW5_uG1QSzzf-cT38g@mail.gmail.com>
References: <CAFm4XO1mApDfDXGA2KxY1eQN3hSKRszfvW5_uG1QSzzf-cT38g@mail.gmail.com>
Message-ID: <CAFdSV9sUs-K+=J7TDiX8404zB4k_YQJ8n3rcLUG9QtrPoZx=-g@mail.gmail.com>

The expectation around CR releases is that they are the Final release.  It
just so happened that CR1 had a major bug that I felt warranted another
CR.  After the first CR release I general point the version to the next
point release.  IMO pushing new 5.0.0 SNAPSHOTs after a 5.0.0 Final or CR
is inaccurate.  So yes, 5.0.1-SNAPSHOT is the expected current master
version.  Its only really an issue in cases like this where CR1 has such a
major bug.

Scott just uses the built jars directly iiuc rather than relying on
Maven/Gradle/etc resolution, so he would just do a `gradle jar` and grab
the jars.

I do not have this problem running releases nor do the CI jobs have this
problem.  These both do a publish.  So I find this weird.  It would seem to
be a task dependency problem.  Try building hibernate-osgi first, and then
running the publish.


On Sun, Jul 5, 2015 at 2:45 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
> I'm trying to build Hibernate ORM's latest to try debugging some of
> the latest changes for Wildfly and Search integrations.
>
> The README mentions I should be able to
>
>  ./gradlew clean publishToMavenLocal
>
> but that fails on the hibernate-osgi module. I then tried "publish" to
> upload a snapshot, but that prouces the same error message:
>
>
> :hibernate-osgi:publishMavenJavaPublicationToJboss-snapshots-repositoryRepository
> FAILED
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task
>
> ':hibernate-osgi:publishMavenJavaPublicationToJboss-snapshots-repositoryRepository'.
> > Failed to publish publication 'mavenJava' to repository
> 'jboss-snapshots-repository'
>    > Invalid publication 'mavenJava': artifact file does not exist:
>
> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.1-SNAPSHOT-karaf.xml'
>
> On the version, I was expecting it to build some "5.0.0-SHAPSHOT" but
> it's actually building a "5.0.1-SNAPSHOT",  is that expected?
>
> I was hoping I could ignore the osgi module and take what it built to
> experiment with Scott's branch, but while on HHH-9887 he mentions
> being down to two failures, I'm having still dozens of failures so I
> suspect I'll need some advice on the build.
>
> Scott, could you share which exact commit id did you use to test
> Hibernate ORM on your branch "hibernate5_july2", and how I can build
> it like yours ?
>
> 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  Sun Jul  5 17:02:40 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 05 Jul 2015 21:02:40 +0000
Subject: [hibernate-dev] Building snapshots of Hibernate ORM / master
In-Reply-To: <CAFdSV9sUs-K+=J7TDiX8404zB4k_YQJ8n3rcLUG9QtrPoZx=-g@mail.gmail.com>
References: <CAFm4XO1mApDfDXGA2KxY1eQN3hSKRszfvW5_uG1QSzzf-cT38g@mail.gmail.com>
	<CAFdSV9sUs-K+=J7TDiX8404zB4k_YQJ8n3rcLUG9QtrPoZx=-g@mail.gmail.com>
Message-ID: <CAFdSV9ttzs8zojVQsuZqKCJP0=XOP4xH5cbfSWgiHGOZAj+x1Q@mail.gmail.com>

BTW, https://hibernate.atlassian.net/browse/HHH-9893  for the task
dependency issue



On Sun, Jul 5, 2015 at 3:50 PM Steve Ebersole <steve at hibernate.org> wrote:

> The expectation around CR releases is that they are the Final release.  It
> just so happened that CR1 had a major bug that I felt warranted another
> CR.  After the first CR release I general point the version to the next
> point release.  IMO pushing new 5.0.0 SNAPSHOTs after a 5.0.0 Final or CR
> is inaccurate.  So yes, 5.0.1-SNAPSHOT is the expected current master
> version.  Its only really an issue in cases like this where CR1 has such a
> major bug.
>
> Scott just uses the built jars directly iiuc rather than relying on
> Maven/Gradle/etc resolution, so he would just do a `gradle jar` and grab
> the jars.
>
> I do not have this problem running releases nor do the CI jobs have this
> problem.  These both do a publish.  So I find this weird.  It would seem to
> be a task dependency problem.  Try building hibernate-osgi first, and then
> running the publish.
>
>
> On Sun, Jul 5, 2015 at 2:45 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Hi all,
>> I'm trying to build Hibernate ORM's latest to try debugging some of
>> the latest changes for Wildfly and Search integrations.
>>
>> The README mentions I should be able to
>>
>>  ./gradlew clean publishToMavenLocal
>>
>> but that fails on the hibernate-osgi module. I then tried "publish" to
>> upload a snapshot, but that prouces the same error message:
>>
>>
>> :hibernate-osgi:publishMavenJavaPublicationToJboss-snapshots-repositoryRepository
>> FAILED
>>
>> FAILURE: Build failed with an exception.
>>
>> * What went wrong:
>> Execution failed for task
>>
>> ':hibernate-osgi:publishMavenJavaPublicationToJboss-snapshots-repositoryRepository'.
>> > Failed to publish publication 'mavenJava' to repository
>> 'jboss-snapshots-repository'
>>    > Invalid publication 'mavenJava': artifact file does not exist:
>>
>> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.1-SNAPSHOT-karaf.xml'
>>
>> On the version, I was expecting it to build some "5.0.0-SHAPSHOT" but
>> it's actually building a "5.0.1-SNAPSHOT",  is that expected?
>>
>> I was hoping I could ignore the osgi module and take what it built to
>> experiment with Scott's branch, but while on HHH-9887 he mentions
>> being down to two failures, I'm having still dozens of failures so I
>> suspect I'll need some advice on the build.
>>
>> Scott, could you share which exact commit id did you use to test
>> Hibernate ORM on your branch "hibernate5_july2", and how I can build
>> it like yours ?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From smarlow at redhat.com  Mon Jul  6 09:22:51 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 6 Jul 2015 09:22:51 -0400
Subject: [hibernate-dev] Building snapshots of Hibernate ORM / master
In-Reply-To: <CAFm4XO1mApDfDXGA2KxY1eQN3hSKRszfvW5_uG1QSzzf-cT38g@mail.gmail.com>
References: <CAFm4XO1mApDfDXGA2KxY1eQN3hSKRszfvW5_uG1QSzzf-cT38g@mail.gmail.com>
Message-ID: <559A812B.40507@redhat.com>


> I was hoping I could ignore the osgi module and take what it built to
> experiment with Scott's branch, but while on HHH-9887 he mentions
> being down to two failures, I'm having still dozens of failures so I
> suspect I'll need some advice on the build.
>
> Scott, could you share which exact commit id did you use to test
> Hibernate ORM on your branch "hibernate5_july2", and how I can build
> it like yours ?

To build ORM, I use:

./gradlew clean install generateKarafFeatures publishToMavenLocal

I last built against ORM master commit id 
9b5bb9751cdd15eaf1049d2b51f6f4a61b878ed8

Then I built WildFly via:

cd wildfly
/build.sh clean install -DskipTests=true

To recreate the WildFly test failures:
cd wildfly/testsuite/integration/basic
mvn clean install -Dtest=*JPA*


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

From bdshadow at gmail.com  Mon Jul  6 09:29:28 2015
From: bdshadow at gmail.com (Dmitry Bocharov)
Date: Mon, 6 Jul 2015 16:29:28 +0300
Subject: [hibernate-dev] Hibernate Search fails to generate anything
Message-ID: <CAM4O4P5uAbdeCMHY_HP+TRd3k+Er+nZuJPiSsr8gUMLvY2DYjw@mail.gmail.com>

Hello, everyone!
I'd like to discuss with you the problem. I'm writing a hibernate-search
eclipse plugin and currently I have a problem with generating indexes.
I try to generate indexes in HSearchServiceProxy class
<https://github.com/Sanne/org.jboss.tools.hibernate.search/blob/master/hsearchplugins/org.jboss.tools.hibernate.search.runtime.v_4_5/src/org/jboss/tools/hibernate/search/HSearchServiceProxy.java>.
The code runs till the end fine. I was able to debug it. However, nothing
is created.

I have a user project. In hibernate.cfg.xml there is:

*  <property
name="hibernate.search.default.directory_provider">filesystem</property>*
*  <property
name="hibernate.search.default.indexBase">D:\Spring\HibernateWS\gen_indexes</property>*

Also there is
*        <dependency>*
*  <groupId>org.hibernate</groupId>*
*  <artifactId>hibernate-search-orm</artifactId>*
*  <version>5.0.1.Final</version>*
*  </dependency>*
in the *pom.xml* in order to annotate entities to index them:

*@Entity*
*@Indexed*
*public class Person implements java.io.Serializable {*
* @Id*
* @GeneratedValue*
* private int id;*
* @Field(analyze=Analyze.YES, store=Store.NO)*
* private String login;*

When i try to create indexes as a user - it works fine. However, when I try
to do it from my plugin nothing happens. I debugged and found that the call
stack is the following: MassIndexerImpl.startAndWait() ->
FullTextSessionImpl.getSearchIntegrator() ->
ContextHelper.getSearchintegratorBySFI(SessionFactoryImplementor sfi) ->
SearchFactoryReference.getSearchIntegrator(). And here
<https://github.com/hibernate/hibernate-search/blob/c06e4fe5fbc6b5a09195f40d760a093691f2c7f2/orm/src/main/java/org/hibernate/search/hcore/impl/SearchFactoryReference.java>
it
creates and exception in getSearchIntegrator() because
this.extendedIntegrator returns null.

As I understand plugin classloader is different from user classloader. So
that can be a problem. In my plugin I have hibernate-core 4.3.1 (from
jbosstolls-hibernate) and hibernate-search (5.0.1 as a fragment of this
jbosstolls-hibernate plugin) in the classpath. I found that versions are
compatible, so it's not a problem.

So the only problem, as I think, are different classloaders.

Koen Aers and Sanne Grinovero are in touch with the problem. So If anyone
else has any thoughts, it would be great to see =)

Thanks in advance!
Dmitry

From steve at hibernate.org  Mon Jul  6 10:17:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 06 Jul 2015 14:17:03 +0000
Subject: [hibernate-dev] Building snapshots of Hibernate ORM / master
In-Reply-To: <559A812B.40507@redhat.com>
References: <CAFm4XO1mApDfDXGA2KxY1eQN3hSKRszfvW5_uG1QSzzf-cT38g@mail.gmail.com>
	<559A812B.40507@redhat.com>
Message-ID: <CAFdSV9sCRu91Au69b02ouPF_p00JJorK+9fKZZJt5+E5-KAH5w@mail.gmail.com>

After HHH-9893 you will no longer need to explicitly call the
generateKarafFeatures
task.  Also, install and publishToMavenLocal are the same task.

On Mon, Jul 6, 2015 at 8:23 AM Scott Marlow <smarlow at redhat.com> wrote:

>
> > I was hoping I could ignore the osgi module and take what it built to
> > experiment with Scott's branch, but while on HHH-9887 he mentions
> > being down to two failures, I'm having still dozens of failures so I
> > suspect I'll need some advice on the build.
> >
> > Scott, could you share which exact commit id did you use to test
> > Hibernate ORM on your branch "hibernate5_july2", and how I can build
> > it like yours ?
>
> To build ORM, I use:
>
> ./gradlew clean install generateKarafFeatures publishToMavenLocal
>
> I last built against ORM master commit id
> 9b5bb9751cdd15eaf1049d2b51f6f4a61b878ed8
>
> Then I built WildFly via:
>
> cd wildfly
> /build.sh clean install -DskipTests=true
>
> To recreate the WildFly test failures:
> cd wildfly/testsuite/integration/basic
> mvn clean install -Dtest=*JPA*
>
>
> >
> > 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 steve at hibernate.org  Mon Jul  6 10:19:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 06 Jul 2015 14:19:20 +0000
Subject: [hibernate-dev] Building snapshots of Hibernate ORM / master
In-Reply-To: <CAFdSV9sCRu91Au69b02ouPF_p00JJorK+9fKZZJt5+E5-KAH5w@mail.gmail.com>
References: <CAFm4XO1mApDfDXGA2KxY1eQN3hSKRszfvW5_uG1QSzzf-cT38g@mail.gmail.com>
	<559A812B.40507@redhat.com>
	<CAFdSV9sCRu91Au69b02ouPF_p00JJorK+9fKZZJt5+E5-KAH5w@mail.gmail.com>
Message-ID: <CAFdSV9v0PPrCBYaB_fD=3MZe0_2sy=6voPN928j47eVE7XCPWw@mail.gmail.com>

Actually... I am not even sure where you are getting install as a valid
task.

On Mon, Jul 6, 2015 at 9:17 AM Steve Ebersole <steve at hibernate.org> wrote:

> After HHH-9893 you will no longer need to explicitly call the generateKarafFeatures
> task.  Also, install and publishToMavenLocal are the same task.
>
> On Mon, Jul 6, 2015 at 8:23 AM Scott Marlow <smarlow at redhat.com> wrote:
>
>>
>> > I was hoping I could ignore the osgi module and take what it built to
>> > experiment with Scott's branch, but while on HHH-9887 he mentions
>> > being down to two failures, I'm having still dozens of failures so I
>> > suspect I'll need some advice on the build.
>> >
>> > Scott, could you share which exact commit id did you use to test
>> > Hibernate ORM on your branch "hibernate5_july2", and how I can build
>> > it like yours ?
>>
>> To build ORM, I use:
>>
>> ./gradlew clean install generateKarafFeatures publishToMavenLocal
>>
>> I last built against ORM master commit id
>> 9b5bb9751cdd15eaf1049d2b51f6f4a61b878ed8
>>
>> Then I built WildFly via:
>>
>> cd wildfly
>> /build.sh clean install -DskipTests=true
>>
>> To recreate the WildFly test failures:
>> cd wildfly/testsuite/integration/basic
>> mvn clean install -Dtest=*JPA*
>>
>>
>> >
>> > 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 gbadner at redhat.com  Mon Jul  6 18:58:18 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 6 Jul 2015 18:58:18 -0400 (EDT)
Subject: [hibernate-dev] Hibernate 4 Multi-tenancy Issue - No Entity
 Persisters Found
In-Reply-To: <CACP9B1Ky5CdgO0y8FnaCFaUat2CsCLwp_OiTgK2-5MK31r9h9g@mail.gmail.com>
References: <CALpK9-RwevqLs-8mY00co9qCLEMW4XZwGXZinPTYzHRMDofkww@mail.gmail.com>
	<CACP9B1KF_pTS08cYuSC=-A6U+R5GoV8=3Kd1q_iem1WCNYB+ww@mail.gmail.com>
	<CACP9B1Ky5CdgO0y8FnaCFaUat2CsCLwp_OiTgK2-5MK31r9h9g@mail.gmail.com>
Message-ID: <799369910.14995892.1436223498705.JavaMail.zimbra@redhat.com>

This mailing list is for Hibernate development. Please move your discussion to the user forum (https://forum.hibernate.org/).

Thanks,
Gail

----- Original Message -----
> From: "Jitu" <abjitu at gmail.com>
> To: "amit shah" <amits.84 at gmail.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, July 1, 2015 10:06:53 AM
> Subject: Re: [hibernate-dev] Hibernate 4 Multi-tenancy Issue - No Entity Persisters Found
> 
> I have tried hibernate 4 multi-tenancy with Spring. Please check if this
> helps you in anyway https://github.com/abjitu/multitenancy
> 
> On Wed, Jul 1, 2015 at 10:35 PM, Jitu <abjitu at gmail.com> wrote:
> 
> > As per the exception. it looks like hibernate is not not able to find
> > querytranslator which means hibernate is not able to translate HQL query to
> > SQL query. So increase log level to TRACE and provide more logs.
> >
> >
> > On Wed, Jul 1, 2015 at 1:08 PM, amit shah <amits.84 at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I have been trying to integrate hibernate 4 multi-tenancy support in our
> >> application but I get the below exception on executing an hql query
> >>
> >> java.lang.ArrayIndexOutOfBoundsException: 0
> >>     at
> >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.resultClassChecking(AbstractEntityManagerImpl.java:362)
> >>     at
> >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:344)
> >>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>     at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >>     at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>     at
> >> org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:344)
> >>     at com.sun.proxy.$Proxy288.createQuery(Unknown Source)
> >>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>     at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >>     at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>     at
> >> org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:291)
> >>     at com.sun.proxy.$Proxy43.createQuery(Unknown Source)
> >>
> >> The hql query is -
> >>
> >> List<Field> fields = entityManager.createQuery("from " +
> >> Employee.class.getName() +
> >>                     " where " + getQueryForInClause("id", ids),
> >> Employee.class).getResultList();
> >>
> >> On debugging hibernate source, I realize that this is because
> >> hibernate's *SessionFactory
> >> instance does not have any entityPersister instances* due to which the hql
> >> query does have any translator's.
> >>
> >> Is it because the Entity beans are not getting scanned? If so what could
> >> be
> >> the cause?
> >>
> >> The entityFactory spring is declared as below
> >>
> >> <property name="persistenceProviderClass"
> >> value="org.hibernate.jpa.HibernatePersistenceProvider"/><property
> >> name="persistenceXmlLocation"
> >> value="/com/software/persistence/persistence.xml"/><property
> >> name="jpaProperties">
> >>     <map>
> >>         <entry key="hibernate.id.new_generator_mappings" value="true"/>
> >>         <entry key="hibernate.cache.use_second_level_cache"
> >> value="false"/>
> >>         <entry key="hibernate.dialect"
> >> value="com.software.persistence.ExtendedOracle10gDialect"/>
> >>         <entry key="hibernate.jdbc.batch_size" value="10"/>
> >>         <entry key="hibernate.jdbc.batch_versioned_data" value="true"/>
> >>         <entry key="hibernate.jdbc.batch.builder"
> >> value="com.software.persistence.OracleBatchBuilder"/>
> >>         <entry key="hibernate.multiTenancy" value="DATABASE"/>
> >>         <entry key="hibernate.tenant_identifier_resolver"
> >>
> >> value="com.software.persistence.MultitenantIdentifierResolver"/>
> >>         <entry key="hibernate.multi_tenant_connection_provider"
> >>                   value-ref="multiTenantConnectionProvider" />
> >>     </map></property>
> >>
> >> Thanks,
> >> Amit.
> >> P.S - Since I am not getting any traction on this on the hibernate user
> >> forum, I am re-posting this question on the dev forum.
> >> _______________________________________________
> >> 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 emmanuel at hibernate.org  Tue Jul  7 03:24:02 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 7 Jul 2015 09:24:02 +0200
Subject: [hibernate-dev] SOAP / XML-RPC from JIRA is going dark on the 20th
Message-ID: <F380C7F2-EBF9-4CFB-9D04-0F3EEE18D2E7@hibernate.org>

Hi guys,

JIRA will no longer support SOAP / XML-RPC calls on our instance. If any of you has tools or scripts using these APIs, check out the migration page
https://confluence.atlassian.com/display/JIRAKB/SOAP+and+XML-RPC+removal+in+JIRA+Cloud

Emmanuel

From martinbraun123 at aol.com  Tue Jul  7 04:26:15 2015
From: martinbraun123 at aol.com (Martin Braun)
Date: Tue, 7 Jul 2015 04:26:15 -0400
Subject: [hibernate-dev] Hibernate Search fails to generate anything
In-Reply-To: <CAM4O4P5uAbdeCMHY_HP+TRd3k+Er+nZuJPiSsr8gUMLvY2DYjw@mail.gmail.com>
References: <CAM4O4P5uAbdeCMHY_HP+TRd3k+Er+nZuJPiSsr8gUMLvY2DYjw@mail.gmail.com>
Message-ID: <14e679f6064-668-15a27@webprd-m13.mail.aol.com>

Hi,


sounds a lot like Hibernate Search is not properly started yet if the ExtendedSearchIntegrator 
is equal to null.


Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke




-----Original Message-----
From: Dmitry Bocharov <bdshadow at gmail.com>
To: Koen Aers <koen.aers at gmail.com>; hibernate-dev <hibernate-dev at lists.jboss.org>
Sent: Mon, Jul 6, 2015 3:30 pm
Subject: [hibernate-dev] Hibernate Search fails to generate anything


Hello, everyone!
I'd like to discuss with you the problem. I'm writing a
hibernate-search
eclipse plugin and currently I have a problem with generating
indexes.
I try to generate indexes in HSearchServiceProxy
class
<https://github.com/Sanne/org.jboss.tools.hibernate.search/blob/master/hsearchplugins/org.jboss.tools.hibernate.search.runtime.v_4_5/src/org/jboss/tools/hibernate/search/HSearchServiceProxy.java>.
The
code runs till the end fine. I was able to debug it. However, nothing
is
created.

I have a user project. In hibernate.cfg.xml there is:

* 
<property
name="hibernate.search.default.directory_provider">filesystem</property>*
*
<property
name="hibernate.search.default.indexBase">D:\Spring\HibernateWS\gen_indexes</property>*

Also
there is
*        <dependency>*
*  <groupId>org.hibernate</groupId>*
* 
<artifactId>hibernate-search-orm</artifactId>*
* 
<version>5.0.1.Final</version>*
*  </dependency>*
in the *pom.xml* in order to
annotate entities to index them:

*@Entity*
*@Indexed*
*public class Person
implements java.io.Serializable {*
* @Id*
* @GeneratedValue*
* private int
id;*
* @Field(analyze=Analyze.YES, store=Store.NO)*
* private String
login;*

When i try to create indexes as a user - it works fine. However, when
I try
to do it from my plugin nothing happens. I debugged and found that the
call
stack is the following: MassIndexerImpl.startAndWait()
->
FullTextSessionImpl.getSearchIntegrator()
->
ContextHelper.getSearchintegratorBySFI(SessionFactoryImplementor sfi)
->
SearchFactoryReference.getSearchIntegrator(). And
here
<https://github.com/hibernate/hibernate-search/blob/c06e4fe5fbc6b5a09195f40d760a093691f2c7f2/orm/src/main/java/org/hibernate/search/hcore/impl/SearchFactoryReference.java>
it
creates
and exception in getSearchIntegrator() because
this.extendedIntegrator returns
null.

As I understand plugin classloader is different from user classloader.
So
that can be a problem. In my plugin I have hibernate-core 4.3.1
(from
jbosstolls-hibernate) and hibernate-search (5.0.1 as a fragment of
this
jbosstolls-hibernate plugin) in the classpath. I found that versions
are
compatible, so it's not a problem.

So the only problem, as I think, are
different classloaders.

Koen Aers and Sanne Grinovero are in touch with the
problem. So If anyone
else has any thoughts, it would be great to see
=)

Thanks in
advance!
Dmitry
_______________________________________________
hibernate-dev
mailing
list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

 

From sanne at hibernate.org  Tue Jul  7 10:29:15 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 7 Jul 2015 15:29:15 +0100
Subject: [hibernate-dev] Hibernate Search work-in-progress meeting logs
Message-ID: <CAFm4XO2urDHLNfiJrF+A+qG6g_3F9LasK1On0fdi5Sg-QC5tUA@mail.gmail.com>

We had our bi-weekly IRC meeting; today's subject was progress on the
current work on Hibernate Search:

 http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-07-13.22.html

From smarlow at redhat.com  Tue Jul  7 16:50:36 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 7 Jul 2015 16:50:36 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test
	failure with ORM 5
Message-ID: <559C3B9C.5070007@redhat.com>

Hardy,

It seems that the ValidatorFactoryBean#createConstraintValidatorFactory 
is getting called too late for some reason. 
http://pastebin.com/WrdD91Hr shows the call stack for 
ValidatorFactoryBean#create(CreationalContext<ValidatorFactory> ctx) 
which calls createConstraintValidatorFactory, which seems too late 
(CdiValidatorFactoryService is shutting down).

To recreate the WildFly ORM 5 issue on WildFly (if you want to see it 
yourself), steps are:

1.  Build latest ORM master branch (./gradlew clean publishToMavenLocal).

2.  Build https://github.com/scottmarlow/wildfly/tree/hibernate5_july2 
branch (./build.sh clean install -DskipTests=true).

3. change into wildfly/testsuite/integration/basic folder and run "mvn 
clean install -Dtest=*BeanValidationCdiIntegrationTestCase*
"

To run WildFly with the debugger, cd into 
wildfly/dist/target/wildfly-10.0.0.Alpha5-SNAPSHOT/bin and edit the 
standalone.conf file.  Uncomment the "remote socket debugger" line #57 
to look something like the following:

JAVA_OPTS="$JAVA_OPTS 
-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y"

Then start WildFly, via ./standalone.sh and open port 8787 with your 
debugger.

Then run the test (step #3 above) and your debugger breakpoint should be 
hit.

Scott

From hardy at hibernate.org  Wed Jul  8 06:42:13 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 8 Jul 2015 12:42:13 +0200
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <559C3B9C.5070007@redhat.com>
References: <559C3B9C.5070007@redhat.com>
Message-ID: <20150708104213.GB33832@Nineveh.lan>

On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
> Hardy,
> 
> It seems that the ValidatorFactoryBean#createConstraintValidatorFactory is
> getting called too late for some reason. http://pastebin.com/WrdD91Hr shows
> the call stack for
> ValidatorFactoryBean#create(CreationalContext<ValidatorFactory> ctx) which
> calls createConstraintValidatorFactory, which seems too late
> (CdiValidatorFactoryService is shutting down).

Did you not change some of the integration code in order to upgrade to ORM 5
within Wildfly? It is not just a version upgrade, right? 

The reason I am asking is that afaik we jump through quite some hoops regarding
the Bean Validation integration to ensure that the JNDI bound Validator(Factory)
is CDI enabled and identical to the one which can be retrieved via CDI. This
is the whole LazyValidatorFactory stuff. I am not so familiar with this code,
but I am wondering whether your changes for the ORM 5 integration interfere with
the Bean Valiadtion bootstrapping. What needed to change for the ORM 5 integration?
I know that you and Sanne discussed the ability to bootstrap the PersistenceProvider
using the API as defined by JPA. Did you go in this direction?

> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
> yourself), steps are:

Ok, I'll take a look at your branch.

Is this test failure the last hurdle to integrate ORM5 into Wildfly 10?

--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/20150708/d1298f38/attachment.bin 

From sanne at hibernate.org  Wed Jul  8 07:15:41 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 8 Jul 2015 12:15:41 +0100
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <20150708104213.GB33832@Nineveh.lan>
References: <559C3B9C.5070007@redhat.com> <20150708104213.GB33832@Nineveh.lan>
Message-ID: <CAFm4XO3sOzTmDKamx40UK34uQzxjb6HbjgeDG0zMnmDsXZxwTw@mail.gmail.com>

On 8 July 2015 at 11:42, Hardy Ferentschik <hardy at hibernate.org> wrote:
> On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>> Hardy,
>>
>> It seems that the ValidatorFactoryBean#createConstraintValidatorFactory is
>> getting called too late for some reason. http://pastebin.com/WrdD91Hr shows
>> the call stack for
>> ValidatorFactoryBean#create(CreationalContext<ValidatorFactory> ctx) which
>> calls createConstraintValidatorFactory, which seems too late
>> (CdiValidatorFactoryService is shutting down).
>
> Did you not change some of the integration code in order to upgrade to ORM 5
> within Wildfly? It is not just a version upgrade, right?
>
> The reason I am asking is that afaik we jump through quite some hoops regarding
> the Bean Validation integration to ensure that the JNDI bound Validator(Factory)
> is CDI enabled and identical to the one which can be retrieved via CDI. This
> is the whole LazyValidatorFactory stuff. I am not so familiar with this code,
> but I am wondering whether your changes for the ORM 5 integration interfere with
> the Bean Valiadtion bootstrapping. What needed to change for the ORM 5 integration?
> I know that you and Sanne discussed the ability to bootstrap the PersistenceProvider
> using the API as defined by JPA. Did you go in this direction?
>
>> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
>> yourself), steps are:
>
> Ok, I'll take a look at your branch.
>
> Is this test failure the last hurdle to integrate ORM5 into Wildfly 10?

I have the same question, I'm confused as yesterday I heard we were
down to zero failures.
Did something else change, or are tests being run in incremental
iterations? Just wondering how confident we are about not seeing more
issues being reported tomorrow.

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 Jul  8 08:16:18 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 8 Jul 2015 14:16:18 +0200
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <559C3B9C.5070007@redhat.com>
References: <559C3B9C.5070007@redhat.com>
Message-ID: <20150708121618.GA34086@Nineveh.lan>

On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
> yourself), steps are:

For the record, I see the same test failures locally. I have not looked any
further regarding their cause.

@Scott, on a high level what are the changes which were required to integrate ORM 5.
Anything which you in your opinion interfere with the Bean Validation integration?

--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/20150708/60ebf8b3/attachment.bin 

From smarlow at redhat.com  Wed Jul  8 08:29:12 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 08:29:12 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <CAFm4XO3sOzTmDKamx40UK34uQzxjb6HbjgeDG0zMnmDsXZxwTw@mail.gmail.com>
References: <559C3B9C.5070007@redhat.com> <20150708104213.GB33832@Nineveh.lan>
	<CAFm4XO3sOzTmDKamx40UK34uQzxjb6HbjgeDG0zMnmDsXZxwTw@mail.gmail.com>
Message-ID: <559D1798.2070203@redhat.com>



On 07/08/2015 07:15 AM, Sanne Grinovero wrote:
> On 8 July 2015 at 11:42, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>>> Hardy,
>>>
>>> It seems that the ValidatorFactoryBean#createConstraintValidatorFactory is
>>> getting called too late for some reason. http://pastebin.com/WrdD91Hr shows
>>> the call stack for
>>> ValidatorFactoryBean#create(CreationalContext<ValidatorFactory> ctx) which
>>> calls createConstraintValidatorFactory, which seems too late
>>> (CdiValidatorFactoryService is shutting down).
>>
>> Did you not change some of the integration code in order to upgrade to ORM 5
>> within Wildfly? It is not just a version upgrade, right?
>>
>> The reason I am asking is that afaik we jump through quite some hoops regarding
>> the Bean Validation integration to ensure that the JNDI bound Validator(Factory)
>> is CDI enabled and identical to the one which can be retrieved via CDI. This
>> is the whole LazyValidatorFactory stuff. I am not so familiar with this code,
>> but I am wondering whether your changes for the ORM 5 integration interfere with
>> the Bean Valiadtion bootstrapping. What needed to change for the ORM 5 integration?
>> I know that you and Sanne discussed the ability to bootstrap the PersistenceProvider
>> using the API as defined by JPA. Did you go in this direction?

The ORM integration code does not interact with the Bean Validation 
bootstrapping.  That is done the same (by the JPA 
container/deployer/subsystem) for any persistence provider that we 
integrate with.

>>
>>> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
>>> yourself), steps are:
>>
>> Ok, I'll take a look at your branch.
>>
>> Is this test failure the last hurdle to integrate ORM5 into Wildfly 10?

Yes.

>
> I have the same question, I'm confused as yesterday I heard we were
> down to zero failures.

There were certain tests that I was not running locally.  I found that 
the following command runs all of the WildFly tests that I really wanted 
to run:

./integration-tests.sh -Dts.basic -Dmaven.test.failure.ignore=true 
-DfailIfNoTests=false

I also ran the WildFly clustering tests which replicate an extended 
persistence context.  No failures with those.

> Did something else change, or are tests being run in incremental
> iterations? Just wondering how confident we are about not seeing more
> issues being reported tomorrow.

I am planning on running the EE TCK tests with ORM 5 CR2 after it is 
merged.  There may be EE TCK test failures with ORM 5 that will need to 
be addressed this summer (before end of August).

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

From smarlow at redhat.com  Wed Jul  8 08:32:01 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 08:32:01 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <20150708121618.GA34086@Nineveh.lan>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
Message-ID: <559D1841.4040301@redhat.com>



On 07/08/2015 08:16 AM, Hardy Ferentschik wrote:
> On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
>> yourself), steps are:
>
> For the record, I see the same test failures locally. I have not looked any
> further regarding their cause.
>
> @Scott, on a high level what are the changes which were required to integrate ORM 5.
> Anything which you in your opinion interfere with the Bean Validation integration?

The same test works with the WildFly master branch, which is using ORM 
4.3.x.  The Bean Validation integration code is unchanged in my WildFly 
branch, as is the Bean Validator.  The only thing different, is the ORM 
5 integration code and the ORM 5 persistence provider.

>
> --Hardy
>

From gunnar at hibernate.org  Wed Jul  8 08:33:24 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 8 Jul 2015 14:33:24 +0200
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <559D1841.4040301@redhat.com>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com>
Message-ID: <CADGJaX8JEU9FmazfSsUFQkG=GK1xYp8290q2ZZo4Affj250tzw@mail.gmail.com>

Scott, could you update the Gist with the complete stack trace you got? It
seems to only contains parts of it.

2015-07-08 14:32 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

>
>
> On 07/08/2015 08:16 AM, Hardy Ferentschik wrote:
> > On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
> >> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
> >> yourself), steps are:
> >
> > For the record, I see the same test failures locally. I have not looked
> any
> > further regarding their cause.
> >
> > @Scott, on a high level what are the changes which were required to
> integrate ORM 5.
> > Anything which you in your opinion interfere with the Bean Validation
> integration?
>
> The same test works with the WildFly master branch, which is using ORM
> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
> branch, as is the Bean Validator.  The only thing different, is the ORM
> 5 integration code and the ORM 5 persistence provider.
>
> >
> > --Hardy
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Wed Jul  8 08:58:53 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 08:58:53 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <CADGJaX8JEU9FmazfSsUFQkG=GK1xYp8290q2ZZo4Affj250tzw@mail.gmail.com>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com>
	<CADGJaX8JEU9FmazfSsUFQkG=GK1xYp8290q2ZZo4Affj250tzw@mail.gmail.com>
Message-ID: <559D1E8D.8030907@redhat.com>

Here are a few different call stacks:

1.  http://pastebin.com/ZiZL5vEh shows the call stack when running 
against the WildFly master branch (with ORM 4.3.x) and the @Inject works 
(the test 
org.jboss.as.test.integration.jpa.beanvalidation.cdi.CustomMinValidator.setMinimumValueProvider() 
method is being called in the call stack).

2.  http://pastebin.com/ApYVvUHL shows the NPE that I get on the 
https://github.com/scottmarlow/wildfly/tree/hibernate5_july2 branch to 
run the BeanValidationCdiIntegrationTestCase.  The NPE occurs because 
the 
org.jboss.as.test.integration.jpa.beanvalidation.cdi.CustomMinValidator.setMinimumValueProvider() 
is not called.

On 07/08/2015 08:33 AM, Gunnar Morling wrote:
> Scott, could you update the Gist with the complete stack trace you got?
> It seems to only contains parts of it.

I captured the call stack http://pastebin.com/WrdD91Hr right before 
stepping into the call to private method 
org.hibernate.validator.internal.cdi.ValidatorFactoryBean#createConstraintValidatorFactory() 
which is called from 
ValidatorFactoryBean.create(CreationalContext<ValidatorFactory> ctx).

>
> 2015-07-08 14:32 GMT+02:00 Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>>:
>
>
>
>     On 07/08/2015 08:16 AM, Hardy Ferentschik wrote:
>      > On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>      >> To recreate the WildFly ORM 5 issue on WildFly (if you want to
>     see it
>      >> yourself), steps are:
>      >
>      > For the record, I see the same test failures locally. I have not
>     looked any
>      > further regarding their cause.
>      >
>      > @Scott, on a high level what are the changes which were required
>     to integrate ORM 5.
>      > Anything which you in your opinion interfere with the Bean
>     Validation integration?
>
>     The same test works with the WildFly master branch, which is using ORM
>     4.3.x.  The Bean Validation integration code is unchanged in my WildFly
>     branch, as is the Bean Validator.  The only thing different, is the ORM
>     5 integration code and the ORM 5 persistence provider.
>
>      >
>      > --Hardy
>      >
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From hardy at hibernate.org  Wed Jul  8 09:02:31 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 8 Jul 2015 15:02:31 +0200
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <559D1841.4040301@redhat.com>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com>
Message-ID: <20150708130231.GB35306@Nineveh.lan>

Hi,

> The same test works with the WildFly master branch, which is using ORM
> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
> branch, as is the Bean Validator.  The only thing different, is the ORM 5
> integration code and the ORM 5 persistence provider.

Just fishing here, but "integration code and the ORM 5 persistence provider" might
indicate a problem in the persistence bootstrapping. 
Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
validation from the properties passed via the Persistence bootstrap. The property name
is javax.persistence.validation.factory. If there is no instance passed ORM will bootstrap
a default factory using  Validation.buildDefaultValidatorFactory(). The latter would 
of course not be CDI enabled. This would explain why validation occurs, but not CDI injection.
I would for sure put a breakpoint in there as well (and some trace/debug log would be probably
nice to have as well to easily tell whether a factory is passed or a default one is generated.

--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/20150708/c3b11d92/attachment.bin 

From smarlow at redhat.com  Wed Jul  8 09:11:55 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 09:11:55 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <20150708130231.GB35306@Nineveh.lan>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com> <20150708130231.GB35306@Nineveh.lan>
Message-ID: <559D219B.7050409@redhat.com>



On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
> Hi,
>
>> The same test works with the WildFly master branch, which is using ORM
>> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
>> branch, as is the Bean Validator.  The only thing different, is the ORM 5
>> integration code and the ORM 5 persistence provider.
>
> Just fishing here, but "integration code and the ORM 5 persistence provider" might
> indicate a problem in the persistence bootstrapping.
> Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
> Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
> validation from the properties passed via the Persistence bootstrap. The property name
> is javax.persistence.validation.factory. If there is no instance passed ORM will bootstrap
> a default factory using  Validation.buildDefaultValidatorFactory(). The latter would
> of course not be CDI enabled. This would explain why validation occurs, but not CDI injection.
> I would for sure put a breakpoint in there as well (and some trace/debug log would be probably
> nice to have as well to easily tell whether a factory is passed or a default one is generated.

Good suggestion, the validation factory does get passed in during the 
second bootstrap phase.  If we looked for it during the first JPA 
bootstrap phase, we would not see it in Hibernate ORM 5.  We should 
check that.

>
> --Hardy
>

From smarlow at redhat.com  Wed Jul  8 09:28:31 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 09:28:31 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <20150708130231.GB35306@Nineveh.lan>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com> <20150708130231.GB35306@Nineveh.lan>
Message-ID: <559D257F.5010000@redhat.com>



On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
> Hi,
>
>> The same test works with the WildFly master branch, which is using ORM
>> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
>> branch, as is the Bean Validator.  The only thing different, is the ORM 5
>> integration code and the ORM 5 persistence provider.
>
> Just fishing here, but "integration code and the ORM 5 persistence provider" might
> indicate a problem in the persistence bootstrapping.
> Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
> Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
> validation from the properties passed via the Persistence bootstrap. The property name
> is javax.persistence.validation.factory. If there is no instance passed ORM will bootstrap
> a default factory using  Validation.buildDefaultValidatorFactory(). The latter would
> of course not be CDI enabled. This would explain why validation occurs, but not CDI injection.
> I would for sure put a breakpoint in there as well (and some trace/debug log would be probably
> nice to have as well to easily tell whether a factory is passed or a default one is generated.

http://pastebin.com/4X0h1VPA is the call stack in.  We are in the second 
bootstrap phase, which is good.  The validator factory is passed into 
the integration properties but we are only checking the persistence unit 
properties in ORM 5.  Since we are not looking in the integration 
properties for the "javax.persistence.validation.factory", we are not 
seeing it.  So your are right on the money, great suggestion.

I'll check next why the 
EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is 
also ignored.



>
> --Hardy
>

From hardy at hibernate.org  Wed Jul  8 09:32:37 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 8 Jul 2015 15:32:37 +0200
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <559D219B.7050409@redhat.com>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com> <20150708130231.GB35306@Nineveh.lan>
	<559D219B.7050409@redhat.com>
Message-ID: <20150708133237.GC35306@Nineveh.lan>

On Wed, Jul 08, 2015 at 09:11:55AM -0400, Scott Marlow wrote:
> >Just fishing here, but "integration code and the ORM 5 persistence provider" might
> >indicate a problem in the persistence bootstrapping.
> >Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
> >Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
> >validation from the properties passed via the Persistence bootstrap. The property name
> >is javax.persistence.validation.factory. If there is no instance passed ORM will bootstrap
> >a default factory using  Validation.buildDefaultValidatorFactory(). The latter would
> >of course not be CDI enabled. This would explain why validation occurs, but not CDI injection.
> >I would for sure put a breakpoint in there as well (and some trace/debug log would be probably
> >nice to have as well to easily tell whether a factory is passed or a default one is generated.
> 
> Good suggestion, the validation factory does get passed in during the second
> bootstrap phase.  If we looked for it during the first JPA bootstrap phase,
> we would not see it in Hibernate ORM 5.  We should check that

+1

I am also confused about your debugging instructions. You are suggesting to use the Wildfly instance
under dist/target. When I do that and have this instance running when while executing 
'mvn install -Dtest=*BeanValidationCdiIntegrationTestCase*' the tests actually pass. Apparently
in this case Arquillian is configured to run against the running Wildfly instance.
If I, however, run the tests without having a running Wildfly instance the tests keep failing. Seems
to me that a different Wildfly instance is used. I guess I don't fully understand the test setup
in the widlfly repo and this integration tests in particular, but obviously I want to debug the 
right thing.

--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/20150708/8b16ea88/attachment.bin 

From smarlow at redhat.com  Wed Jul  8 09:37:17 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 09:37:17 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <559D219B.7050409@redhat.com>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com> <20150708130231.GB35306@Nineveh.lan>
	<559D219B.7050409@redhat.com>
Message-ID: <559D278D.8020305@redhat.com>

org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl#populate(SessionFactoryBuilder 
sfBuilder, StandardServiceRegistry ssr) does pass the correct VF to 
sfBuilder.applyValidatorFactory (using the ValidatorFactory passed to 
the EntityManagerFactoryBuilderImpl.withValidatorFactory).  However,  a 
bit later when we reach 
org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory, 
we aren't using the SessionFactoryBuilder or 
EntityManagerFactoryBuilderImpl to obtain the VF.  Instead, we are 
looking in the persistence unit properties.  This sounds wrong to me.

On 07/08/2015 09:11 AM, Scott Marlow wrote:
>
>
> On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
>> Hi,
>>
>>> The same test works with the WildFly master branch, which is using ORM
>>> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
>>> branch, as is the Bean Validator.  The only thing different, is the ORM 5
>>> integration code and the ORM 5 persistence provider.
>>
>> Just fishing here, but "integration code and the ORM 5 persistence provider" might
>> indicate a problem in the persistence bootstrapping.
>> Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
>> Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
>> validation from the properties passed via the Persistence bootstrap. The property name
>> is javax.persistence.validation.factory. If there is no instance passed ORM will bootstrap
>> a default factory using  Validation.buildDefaultValidatorFactory(). The latter would
>> of course not be CDI enabled. This would explain why validation occurs, but not CDI injection.
>> I would for sure put a breakpoint in there as well (and some trace/debug log would be probably
>> nice to have as well to easily tell whether a factory is passed or a default one is generated.
>
> Good suggestion, the validation factory does get passed in during the
> second bootstrap phase.  If we looked for it during the first JPA
> bootstrap phase, we would not see it in Hibernate ORM 5.  We should
> check that.
>
>>
>> --Hardy
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Wed Jul  8 09:41:08 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 09:41:08 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <20150708133237.GC35306@Nineveh.lan>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com> <20150708130231.GB35306@Nineveh.lan>
	<559D219B.7050409@redhat.com> <20150708133237.GC35306@Nineveh.lan>
Message-ID: <559D2874.1080407@redhat.com>



On 07/08/2015 09:32 AM, Hardy Ferentschik wrote:
> On Wed, Jul 08, 2015 at 09:11:55AM -0400, Scott Marlow wrote:
>>> Just fishing here, but "integration code and the ORM 5 persistence provider" might
>>> indicate a problem in the persistence bootstrapping.
>>> Have a look at org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
>>> Basically ORM expects to retrieve the ValidatorFactory to use for the life cycle based
>>> validation from the properties passed via the Persistence bootstrap. The property name
>>> is javax.persistence.validation.factory. If there is no instance passed ORM will bootstrap
>>> a default factory using  Validation.buildDefaultValidatorFactory(). The latter would
>>> of course not be CDI enabled. This would explain why validation occurs, but not CDI injection.
>>> I would for sure put a breakpoint in there as well (and some trace/debug log would be probably
>>> nice to have as well to easily tell whether a factory is passed or a default one is generated.
>>
>> Good suggestion, the validation factory does get passed in during the second
>> bootstrap phase.  If we looked for it during the first JPA bootstrap phase,
>> we would not see it in Hibernate ORM 5.  We should check that
>
> +1
>
> I am also confused about your debugging instructions. You are suggesting to use the Wildfly instance
> under dist/target. When I do that and have this instance running when while executing
> 'mvn install -Dtest=*BeanValidationCdiIntegrationTestCase*' the tests actually pass. Apparently
> in this case Arquillian is configured to run against the running Wildfly instance.
> If I, however, run the tests without having a running Wildfly instance the tests keep failing. Seems
> to me that a different Wildfly instance is used. I guess I don't fully understand the test setup
> in the widlfly repo and this integration tests in particular, but obviously I want to debug the
> right thing.

I don't know why that is happening.  It sounds like we have enough 
information from your previous suggestion though and my last email. 
I'll follow up with you on IRC next. :)

>
> --Hardy
>
>

From hardy at hibernate.org  Wed Jul  8 09:53:24 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 8 Jul 2015 15:53:24 +0200
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <559D257F.5010000@redhat.com>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com> <20150708130231.GB35306@Nineveh.lan>
	<559D257F.5010000@redhat.com>
Message-ID: <20150708135324.GD35306@Nineveh.lan>

Hi,
 
> http://pastebin.com/4X0h1VPA is the call stack in.  We are in the second
> bootstrap phase, which is good.  The validator factory is passed into the
> integration properties but we are only checking the persistence unit
> properties in ORM 5.  Since we are not looking in the integration properties
> for the "javax.persistence.validation.factory", we are not seeing it.  So
> your are right on the money, great suggestion.

I am not sure how this all maps to the different phases and properties types, but 
the JPA specs says in 3.6.2 Providing the ValidatorFactory - 

"In Java EE environments, a ValidatorFactory instance is made available by the Java EE container.
The container is responsible for passing this validator factory to the persistence provider via the
map that is passed as an argument to the createContainerEntityManagerFactory call. The
map key used by the container must be the standard property name javax.persistence.validation.
factory"

I am not sure where the properties of this map end up during the current bootstrapping process,
but where ever that is, that's where we have to look in TypeSafeActivator (and potentially ask us
the question whether it is the right place).
 
> I'll check next why the
> EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is also
> ignored.

Sure. Seems we have a solid lead now.

--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/20150708/c50213fe/attachment.bin 

From smarlow at redhat.com  Wed Jul  8 10:41:03 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 10:41:03 -0400
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <20150708135324.GD35306@Nineveh.lan>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com> <20150708130231.GB35306@Nineveh.lan>
	<559D257F.5010000@redhat.com> <20150708135324.GD35306@Nineveh.lan>
Message-ID: <559D367F.9020607@redhat.com>

Steve,

I created HHH-9905 for this, which I was able to workaround with a quick 
hack (set the missing "javax.persistence.validation.factory" property in 
the ConfigurationService).  I was able to pass the WildFly test with the 
workaround.

Steve, is that the right fix?  I assigned the jira to you.  Can we fix 
this for the CR2 build?  If we use the hack workaround, it will probably 
be coded a little different (the hack worked in the debugger but there 
is probably a more elegant way to code it).

Scott

On 07/08/2015 09:53 AM, Hardy Ferentschik wrote:
> Hi,
>
>> http://pastebin.com/4X0h1VPA is the call stack in.  We are in the second
>> bootstrap phase, which is good.  The validator factory is passed into the
>> integration properties but we are only checking the persistence unit
>> properties in ORM 5.  Since we are not looking in the integration properties
>> for the "javax.persistence.validation.factory", we are not seeing it.  So
>> your are right on the money, great suggestion.
>
> I am not sure how this all maps to the different phases and properties types, but
> the JPA specs says in 3.6.2 Providing the ValidatorFactory -
>
> "In Java EE environments, a ValidatorFactory instance is made available by the Java EE container.
> The container is responsible for passing this validator factory to the persistence provider via the
> map that is passed as an argument to the createContainerEntityManagerFactory call. The
> map key used by the container must be the standard property name javax.persistence.validation.
> factory"
>
> I am not sure where the properties of this map end up during the current bootstrapping process,
> but where ever that is, that's where we have to look in TypeSafeActivator (and potentially ask us
> the question whether it is the right place).
>
>> I'll check next why the
>> EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is also
>> ignored.
>
> Sure. Seems we have a solid lead now.
>
> --Hardy
>

From steve at hibernate.org  Wed Jul  8 10:59:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jul 2015 14:59:01 +0000
Subject: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase
 test failure with ORM 5
In-Reply-To: <559D367F.9020607@redhat.com>
References: <559C3B9C.5070007@redhat.com> <20150708121618.GA34086@Nineveh.lan>
	<559D1841.4040301@redhat.com> <20150708130231.GB35306@Nineveh.lan>
	<559D257F.5010000@redhat.com> <20150708135324.GD35306@Nineveh.lan>
	<559D367F.9020607@redhat.com>
Message-ID: <CAFdSV9u_A18R122k+Ltgc83vUHCTre+PoELqUuFsQ_VE8S8nZA@mail.gmail.com>

Looks like I missed a small piece there.  The intention was to have
TypeSafeActivator
pick up SessionFactoryOptions#getValidatorFactoryReference.  Scott, can you
make sure SessionFactoryOptions#getValidatorFactoryReference contains the
proper ValidatorFactory reference when we get into TypeSafeActivator in WF?

On Wed, Jul 8, 2015 at 9:41 AM Scott Marlow <smarlow at redhat.com> wrote:

> Steve,
>
> I created HHH-9905 for this, which I was able to workaround with a quick
> hack (set the missing "javax.persistence.validation.factory" property in
> the ConfigurationService).  I was able to pass the WildFly test with the
> workaround.
>
> Steve, is that the right fix?  I assigned the jira to you.  Can we fix
> this for the CR2 build?  If we use the hack workaround, it will probably
> be coded a little different (the hack worked in the debugger but there
> is probably a more elegant way to code it).
>
> Scott
>
> On 07/08/2015 09:53 AM, Hardy Ferentschik wrote:
> > Hi,
> >
> >> http://pastebin.com/4X0h1VPA is the call stack in.  We are in the
> second
> >> bootstrap phase, which is good.  The validator factory is passed into
> the
> >> integration properties but we are only checking the persistence unit
> >> properties in ORM 5.  Since we are not looking in the integration
> properties
> >> for the "javax.persistence.validation.factory", we are not seeing it.
> So
> >> your are right on the money, great suggestion.
> >
> > I am not sure how this all maps to the different phases and properties
> types, but
> > the JPA specs says in 3.6.2 Providing the ValidatorFactory -
> >
> > "In Java EE environments, a ValidatorFactory instance is made available
> by the Java EE container.
> > The container is responsible for passing this validator factory to the
> persistence provider via the
> > map that is passed as an argument to the
> createContainerEntityManagerFactory call. The
> > map key used by the container must be the standard property name
> javax.persistence.validation.
> > factory"
> >
> > I am not sure where the properties of this map end up during the current
> bootstrapping process,
> > but where ever that is, that's where we have to look in
> TypeSafeActivator (and potentially ask us
> > the question whether it is the right place).
> >
> >> I'll check next why the
> >> EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is
> also
> >> ignored.
> >
> > Sure. Seems we have a solid lead now.
> >
> > --Hardy
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jul  8 12:06:42 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jul 2015 16:06:42 +0000
Subject: [hibernate-dev] SOAP / XML-RPC from JIRA is going dark on the
	20th
In-Reply-To: <F380C7F2-EBF9-4CFB-9D04-0F3EEE18D2E7@hibernate.org>
References: <F380C7F2-EBF9-4CFB-9D04-0F3EEE18D2E7@hibernate.org>
Message-ID: <CAFdSV9v33pbv3xMKQShQS-D2-vEU_pMnbENcdygq795gFnCaqA@mail.gmail.com>

I would assume part of that is the Atlassian Connector for IntelliJ that I
use.  Which sucks because now I would have to use the non-community version
of the IDE to use tasks stuff.

Out of curiosity, how does everyone else using IntelliJ connect it to Jira
or do y'all not connect it at all?

On Tue, Jul 7, 2015 at 2:24 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Hi guys,
>
> JIRA will no longer support SOAP / XML-RPC calls on our instance. If any
> of you has tools or scripts using these APIs, check out the migration page
>
> https://confluence.atlassian.com/display/JIRAKB/SOAP+and+XML-RPC+removal+in+JIRA+Cloud
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jul  8 12:18:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jul 2015 16:18:21 +0000
Subject: [hibernate-dev] Starting 5.0.0 CR2 release
Message-ID: <CAFdSV9vca4vZ6bg75kWEEHFnELdEYD3y267EoV8coQtkAnUTrw@mail.gmail.com>

Please no more pushing to master until I am done.  Thanks

From steve at hibernate.org  Wed Jul  8 13:34:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jul 2015 17:34:54 +0000
Subject: [hibernate-dev] Starting 5.0.0 CR2 release
In-Reply-To: <CAFdSV9vca4vZ6bg75kWEEHFnELdEYD3y267EoV8coQtkAnUTrw@mail.gmail.com>
References: <CAFdSV9vca4vZ6bg75kWEEHFnELdEYD3y267EoV8coQtkAnUTrw@mail.gmail.com>
Message-ID: <CAFdSV9u7JLbnPaY5+F1iPrd76f6GASN0OSbfAmn8FmBx-+X0VQ@mail.gmail.com>

Ok, I am done with the release.  I am still writing up the announcement in
the new blog system; the information is here too:
https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR2

On Wed, Jul 8, 2015 at 11:18 AM Steve Ebersole <steve at hibernate.org> wrote:

> Please no more pushing to master until I am done.  Thanks
>

From steve at hibernate.org  Wed Jul  8 15:12:46 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jul 2015 19:12:46 +0000
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
Message-ID: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>

Hibernate ORM 5.0.0.CR2 has just been released.  Details can be found at
https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR2

* - I ran into problems getting the new blog site to work for me, so
pointed here to the GitHub release comment

From steve at hibernate.org  Wed Jul  8 15:17:07 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jul 2015 19:17:07 +0000
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
Message-ID: <CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>

As I said, I had trouble writing this blog in the new asciidoctor stuff.  I
had some trouble getting ruby etal set up locally.  Sanne had mentioned
that I could just push to staging branch and CI would automatically build
it for me and I could check it that way.  Well the CI job clearly saw my
change and initiated a build[1].  The staging build succeeded, but my post
was never displayed on the staging.in.relation.to site.

[1] - http://ci.hibernate.org/view/Website/job/staging.in.relation.to/66/

On Wed, Jul 8, 2015 at 2:12 PM Steve Ebersole <steve at hibernate.org> wrote:

> Hibernate ORM 5.0.0.CR2 has just been released.  Details can be found at
> https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR2
>
> * - I ran into problems getting the new blog site to work for me, so
> pointed here to the GitHub release comment
>

From steve at hibernate.org  Wed Jul  8 15:30:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jul 2015 19:30:54 +0000
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
Message-ID: <CAFdSV9uLfAvUraSG49-NdLfNdPxY2nzFC8n8zFc7cnRVYAaQOg@mail.gmail.com>

Wow, now it shows up.  Like almost an hour later.

On Wed, Jul 8, 2015 at 2:17 PM Steve Ebersole <steve at hibernate.org> wrote:

> As I said, I had trouble writing this blog in the new asciidoctor stuff.
> I had some trouble getting ruby etal set up locally.  Sanne had mentioned
> that I could just push to staging branch and CI would automatically build
> it for me and I could check it that way.  Well the CI job clearly saw my
> change and initiated a build[1].  The staging build succeeded, but my post
> was never displayed on the staging.in.relation.to site.
>
> [1] - http://ci.hibernate.org/view/Website/job/staging.in.relation.to/66/
>
>
> On Wed, Jul 8, 2015 at 2:12 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Hibernate ORM 5.0.0.CR2 has just been released.  Details can be found at
>> https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR2
>>
>> * - I ran into problems getting the new blog site to work for me, so
>> pointed here to the GitHub release comment
>>
>

From smarlow at redhat.com  Wed Jul  8 16:00:58 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 16:00:58 -0400
Subject: [hibernate-dev] WildFly error running
 org.jboss.as.test.integration.jpa.hibernate.classfiletransformertest.ClassFileTransformerTestCase
 (sets hibernate.ejb.use_class_enhancer to true)
Message-ID: <559D817A.3030501@redhat.com>

We are getting a "Failed to define class 
org.jboss.as.test.integration.jpa.hibernate.SFSBHibernateSessionFactory" 
error when running the WildFly tests on the CI machine.  I don't see 
this error locally which is why we didn't see this before.

[1] shows the WildFly console at the time of error.

The class that cannot be defined is 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java 
[2]

I suspect that this is some type of race condition that we are hitting 
with deployment of three persistence units [3] concurrently from three 
threads.  The persistence units have "hibernate.ejb.use_class_enhancer" 
set to true.  This might have something to do with the same appliation 
class being enhanced concurrently from three threads.

The test case [4] is verifying that enhanced application classes can be 
used.

I'm not exactly sure why the SFSBHibernateSessionFactory class is being 
enhanced.  I thought we only enhanced the entity classes 
(SFSBHibernateSessionFactory references the Employee entity class but is 
not an entity class).

Scott

[1] https://gist.github.com/scottmarlow/c56cfe07f2ea514354aa

[2] 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java

[3] 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/persistence.xml

[4] 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java

From hardy at hibernate.org  Wed Jul  8 16:10:06 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 8 Jul 2015 22:10:06 +0200
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
Message-ID: <20150708201006.GG35306@Nineveh.lan>

Hi,

On Wed, Jul 08, 2015 at 07:17:07PM +0000, Steve Ebersole wrote:

> As I said, I had trouble writing this blog in the new asciidoctor stuff.  I
> had some trouble getting ruby etal set up locally

Can you provide any more info than that? I am happy to help you setting
this up, but I need some more information. If you tell me which your Linux
flavour of the days is, I can also try in a local VM before I send you down
any wrong path.

--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/20150708/c84f0522/attachment.bin 

From hardy at hibernate.org  Wed Jul  8 17:12:25 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 8 Jul 2015 23:12:25 +0200
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
Message-ID: <20150708211225.GH35306@Nineveh.lan>

> As I said, I had trouble writing this blog in the new asciidoctor stuff.  I
> had some trouble getting ruby etal set up locally.  Sanne had mentioned
> that I could just push to staging branch and CI would automatically build
> it for me and I could check it that way.  Well the CI job clearly saw my
> change and initiated a build[1].  The staging build succeeded, but my post
> was never displayed on the staging.in.relation.to site.

I just did two test builds and in both cases the changes were visible directly
after the CI build finished. I would say try again and if you see the same problem
again we take a closer look.

--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/20150708/e68d5e89/attachment.bin 

From smarlow at redhat.com  Wed Jul  8 19:00:18 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 19:00:18 -0400
Subject: [hibernate-dev] WildFly error running
 org.jboss.as.test.integration.jpa.hibernate.classfiletransformertest.ClassFileTransformerTestCase
 (sets hibernate.ejb.use_class_enhancer to true)
In-Reply-To: <559D817A.3030501@redhat.com>
References: <559D817A.3030501@redhat.com>
Message-ID: <559DAB82.3050909@redhat.com>

I noticed that CI test failure is only occurring on Windows.  I wonder 
if 
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/bytecode/enhance/spi/Enhancer.java#L114 
is misbehaving on Windows.

On 07/08/2015 04:00 PM, Scott Marlow wrote:
> We are getting a "Failed to define class
> org.jboss.as.test.integration.jpa.hibernate.SFSBHibernateSessionFactory"
> error when running the WildFly tests on the CI machine.  I don't see
> this error locally which is why we didn't see this before.
>
> [1] shows the WildFly console at the time of error.
>
> The class that cannot be defined is
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
> [2]
>
> I suspect that this is some type of race condition that we are hitting
> with deployment of three persistence units [3] concurrently from three
> threads.  The persistence units have "hibernate.ejb.use_class_enhancer"
> set to true.  This might have something to do with the same appliation
> class being enhanced concurrently from three threads.
>
> The test case [4] is verifying that enhanced application classes can be
> used.
>
> I'm not exactly sure why the SFSBHibernateSessionFactory class is being
> enhanced.  I thought we only enhanced the entity classes
> (SFSBHibernateSessionFactory references the Employee entity class but is
> not an entity class).
>
> Scott
>
> [1] https://gist.github.com/scottmarlow/c56cfe07f2ea514354aa
>
> [2]
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
>
> [3]
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/persistence.xml
>
> [4]
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Wed Jul  8 21:03:32 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 8 Jul 2015 21:03:32 -0400
Subject: [hibernate-dev] WildFly error running
 org.jboss.as.test.integration.jpa.hibernate.classfiletransformertest.ClassFileTransformerTestCase
 (sets hibernate.ejb.use_class_enhancer to true)
In-Reply-To: <559DAB82.3050909@redhat.com>
References: <559D817A.3030501@redhat.com> <559DAB82.3050909@redhat.com>
Message-ID: <559DC864.4010608@redhat.com>



On 07/08/2015 07:00 PM, Scott Marlow wrote:
> I noticed that CI test failure is only occurring on Windows.  I wonder
> if
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/bytecode/enhance/spi/Enhancer.java#L114
> is misbehaving on Windows.

We might need to use '/' instead of File.separatorChar.

See javadoc for Class#getResourceAsStream:
"
public InputStream getResourceAsStream(String name)

     Finds a resource with a given name. The rules for searching 
resources associated with a given class are implemented by the defining 
class loader of the class. This method delegates to this object's class 
loader. If this object was loaded by the bootstrap class loader, the 
method delegates to ClassLoader.getSystemResourceAsStream(java.lang.String).

     Before delegation, an absolute resource name is constructed from 
the given resource name using this algorithm:

         If the name begins with a '/' ('\u002f'), then the absolute 
name of the resource is the portion of the name following the '/'.
         Otherwise, the absolute name is of the following form:

                modified_package_name/name


         Where the modified_package_name is the package name of this 
object with '/' substituted for '.' ('\u002e').
"

>
> On 07/08/2015 04:00 PM, Scott Marlow wrote:
>> We are getting a "Failed to define class
>> org.jboss.as.test.integration.jpa.hibernate.SFSBHibernateSessionFactory"
>> error when running the WildFly tests on the CI machine.  I don't see
>> this error locally which is why we didn't see this before.
>>
>> [1] shows the WildFly console at the time of error.
>>
>> The class that cannot be defined is
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
>> [2]
>>
>> I suspect that this is some type of race condition that we are hitting
>> with deployment of three persistence units [3] concurrently from three
>> threads.  The persistence units have "hibernate.ejb.use_class_enhancer"
>> set to true.  This might have something to do with the same appliation
>> class being enhanced concurrently from three threads.
>>
>> The test case [4] is verifying that enhanced application classes can be
>> used.
>>
>> I'm not exactly sure why the SFSBHibernateSessionFactory class is being
>> enhanced.  I thought we only enhanced the entity classes
>> (SFSBHibernateSessionFactory references the Employee entity class but is
>> not an entity class).
>>
>> Scott
>>
>> [1] https://gist.github.com/scottmarlow/c56cfe07f2ea514354aa
>>
>> [2]
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
>>
>> [3]
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/persistence.xml
>>
>> [4]
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java
>> _______________________________________________
>> 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 lbarreiro at redhat.com  Thu Jul  9 01:08:48 2015
From: lbarreiro at redhat.com (Luis Barreiro)
Date: Thu, 9 Jul 2015 06:08:48 +0100
Subject: [hibernate-dev] WildFly error running
 org.jboss.as.test.integration.jpa.hibernate.classfiletransformertest.ClassFileTransformerTestCase
 (sets hibernate.ejb.use_class_enhancer to true)
In-Reply-To: <559DC864.4010608@redhat.com>
References: <559D817A.3030501@redhat.com> <559DAB82.3050909@redhat.com>
	<559DC864.4010608@redhat.com>
Message-ID: <559E01E0.6090709@redhat.com>

I did review the code and come up with the same conclusion.

Issue: https://hibernate.atlassian.net/browse/HHH-9907

PR open: https://github.com/hibernate/hibernate-orm/pull/996

Regards,

On 07/09/2015 02:03 AM, Scott Marlow wrote:
>
> On 07/08/2015 07:00 PM, Scott Marlow wrote:
>> I noticed that CI test failure is only occurring on Windows.  I wonder
>> if
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/bytecode/enhance/spi/Enhancer.java#L114
>> is misbehaving on Windows.
> We might need to use '/' instead of File.separatorChar.
>
> See javadoc for Class#getResourceAsStream:
> "
> public InputStream getResourceAsStream(String name)
>
>       Finds a resource with a given name. The rules for searching
> resources associated with a given class are implemented by the defining
> class loader of the class. This method delegates to this object's class
> loader. If this object was loaded by the bootstrap class loader, the
> method delegates to ClassLoader.getSystemResourceAsStream(java.lang.String).
>
>       Before delegation, an absolute resource name is constructed from
> the given resource name using this algorithm:
>
>           If the name begins with a '/' ('\u002f'), then the absolute
> name of the resource is the portion of the name following the '/'.
>           Otherwise, the absolute name is of the following form:
>
>                  modified_package_name/name
>
>
>           Where the modified_package_name is the package name of this
> object with '/' substituted for '.' ('\u002e').
> "
>
>> On 07/08/2015 04:00 PM, Scott Marlow wrote:
>>> We are getting a "Failed to define class
>>> org.jboss.as.test.integration.jpa.hibernate.SFSBHibernateSessionFactory"
>>> error when running the WildFly tests on the CI machine.  I don't see
>>> this error locally which is why we didn't see this before.
>>>
>>> [1] shows the WildFly console at the time of error.
>>>
>>> The class that cannot be defined is
>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
>>> [2]
>>>
>>> I suspect that this is some type of race condition that we are hitting
>>> with deployment of three persistence units [3] concurrently from three
>>> threads.  The persistence units have "hibernate.ejb.use_class_enhancer"
>>> set to true.  This might have something to do with the same appliation
>>> class being enhanced concurrently from three threads.
>>>
>>> The test case [4] is verifying that enhanced application classes can be
>>> used.
>>>
>>> I'm not exactly sure why the SFSBHibernateSessionFactory class is being
>>> enhanced.  I thought we only enhanced the entity classes
>>> (SFSBHibernateSessionFactory references the Employee entity class but is
>>> not an entity class).
>>>
>>> Scott
>>>
>>> [1] https://gist.github.com/scottmarlow/c56cfe07f2ea514354aa
>>>
>>> [2]
>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
>>>
>>> [3]
>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/persistence.xml
>>>
>>> [4]
>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java
>>> _______________________________________________
>>> 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

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

From steve at hibernate.org  Thu Jul  9 09:35:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 09 Jul 2015 13:35:33 +0000
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <20150708211225.GH35306@Nineveh.lan>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
Message-ID: <CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>

Too late now.  I am off for some hiking / camping with my fianc?.

If someone could do me a favor and take the blog post from staging (or
better yet, the post from Github release) and make a post on production and
finish announcing the release (email, g+, etc) I would really appreciate it.

On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik <hardy at hibernate.org> wrote:

> > As I said, I had trouble writing this blog in the new asciidoctor
> stuff.  I
> > had some trouble getting ruby etal set up locally.  Sanne had mentioned
> > that I could just push to staging branch and CI would automatically build
> > it for me and I could check it that way.  Well the CI job clearly saw my
> > change and initiated a build[1].  The staging build succeeded, but my
> post
> > was never displayed on the staging.in.relation.to site.
>
> I just did two test builds and in both cases the changes were visible
> directly
> after the CI build finished. I would say try again and if you see the same
> problem
> again we take a closer look.
>
> --Hardy
>

From emmanuel at hibernate.org  Thu Jul  9 12:16:29 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 9 Jul 2015 18:16:29 +0200
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
Message-ID: <122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>

I?ll do this.


> On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Too late now.  I am off for some hiking / camping with my fianc?.
> 
> If someone could do me a favor and take the blog post from staging (or
> better yet, the post from Github release) and make a post on production and
> finish announcing the release (email, g+, etc) I would really appreciate it.
> 
> On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik <hardy at hibernate.org> wrote:
> 
>>> As I said, I had trouble writing this blog in the new asciidoctor
>> stuff.  I
>>> had some trouble getting ruby etal set up locally.  Sanne had mentioned
>>> that I could just push to staging branch and CI would automatically build
>>> it for me and I could check it that way.  Well the CI job clearly saw my
>>> change and initiated a build[1].  The staging build succeeded, but my
>> post
>>> was never displayed on the staging.in.relation.to site.
>> 
>> I just did two test builds and in both cases the changes were visible
>> directly
>> after the CI build finished. I would say try again and if you see the same
>> problem
>> again we take a closer look.
>> 
>> --Hardy
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From dreborier at gmail.com  Thu Jul  9 12:24:50 2015
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 9 Jul 2015 17:24:50 +0100
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
Message-ID: <CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>

I have just modified the post, need only to push.
Emmanuel can you just take care of mails, g+ etc?


On 9 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> I?ll do this.
>
>
> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > Too late now.  I am off for some hiking / camping with my fianc?.
> >
> > If someone could do me a favor and take the blog post from staging (or
> > better yet, the post from Github release) and make a post on production
> and
> > finish announcing the release (email, g+, etc) I would really appreciate
> it.
> >
> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> >
> >>> As I said, I had trouble writing this blog in the new asciidoctor
> >> stuff.  I
> >>> had some trouble getting ruby etal set up locally.  Sanne had mentioned
> >>> that I could just push to staging branch and CI would automatically
> build
> >>> it for me and I could check it that way.  Well the CI job clearly saw
> my
> >>> change and initiated a build[1].  The staging build succeeded, but my
> >> post
> >>> was never displayed on the staging.in.relation.to site.
> >>
> >> I just did two test builds and in both cases the changes were visible
> >> directly
> >> after the CI build finished. I would say try again and if you see the
> same
> >> problem
> >> again we take a closer look.
> >>
> >> --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 emmanuel at hibernate.org  Thu Jul  9 12:39:26 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 9 Jul 2015 18:39:26 +0200
Subject: [hibernate-dev] Hibernate ORM 5.0 CR2
Message-ID: <D6472C24-9B2B-4653-9A5F-35AB76553F7D@hibernate.org>

Hibernate ORM 5.0 CR2 is out. Go download it at http://hibernate.org/orm/downloads/ :)

We found a rather nasty bug in classloading and modular environments.
We also took the opportunity to improve a few things around 2nd level cache performance and bytecode enhancement.

Read more at http://in.relation.to/2015/07/09/hibernate-orm-500-cr2-release/

Emmanuel

From sanne at hibernate.org  Thu Jul  9 18:29:45 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 9 Jul 2015 23:29:45 +0100
Subject: [hibernate-dev] Strange issues with -snapshot dependencies
Message-ID: <CAFm4XO3OqMSJPiFcYOt5rOqkjcnKqpwPPDsG0eZrwyHi_B_UJA@mail.gmail.com>

I'm attempting to debug a subtle issue which I can only reproduce
occasionally; to do so, I've been adding some improved logging to a
module A, which is then used by our integration tests in module B
deploying on WildFly via Arquillian.

While polishing the log commits I've also made a change in this module
A which might resolve the issue.

I'm now running the integration tests B multiple times from command
line, via Maven from within the source directory of B. I did of course
"mvn clean install" the whole project first, which rebuilds module A
and all of its dependencies.

The really weird thing:
 = rarely, the test fails, and there is no track of the logs I'm needing.
 = sometimes, the test is successful and I have all logs as expected
(but they are useless).
 = rarely, the test is successful and these logs are missing.

I've been running in circles since a couple of hours, but I *never*
could get the combination of
 (have the logs) && (test fails)

The logger is set at DEBUG level for all of org.hibernate.search, and
when I say the logs are missing I am referring to the new couple of
log statements I just added exclusively: all other logs which
org.hibernate.search normally produces are logged all the time.

I'm starting to wonder if actually sometimes Maven runs my integration
tests using a previous SNAPSHOT build, which would be missing both the
logs and the fix, and in those cases it could either fail or not (as
it wasn't always reproduced).

Anyone else ever seen such an issue?

I now blasted all my Search SNAPSHOT jars from the local repository
and am running the tests in loop since 30 minutes and it's never
failed.. but not comfortable with this.

Also: I'm fighting what seems to be a timing issue, I wouldn't exclude
that the additional logs actually prevent me to trigger the failure -
but I have no explanation on why those logs sometimes are simply
missing from the logfiles: they are certainly triggered.

Thanks,
Sanne

From sanne at hibernate.org  Thu Jul  9 18:42:00 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 9 Jul 2015 23:42:00 +0100
Subject: [hibernate-dev] Strange issues with -snapshot dependencies
In-Reply-To: <CAFm4XO3OqMSJPiFcYOt5rOqkjcnKqpwPPDsG0eZrwyHi_B_UJA@mail.gmail.com>
References: <CAFm4XO3OqMSJPiFcYOt5rOqkjcnKqpwPPDsG0eZrwyHi_B_UJA@mail.gmail.com>
Message-ID: <CAFm4XO2XcDg19mvDHamkdYL5s9A4X-FV5EcefJ56G_WMOZdaQw@mail.gmail.com>

The build just failed once again; the log messages *are missing*, and
my Maven cache was empty.

On 9 July 2015 at 23:29, Sanne Grinovero <sanne at hibernate.org> wrote:
> I'm attempting to debug a subtle issue which I can only reproduce
> occasionally; to do so, I've been adding some improved logging to a
> module A, which is then used by our integration tests in module B
> deploying on WildFly via Arquillian.
>
> While polishing the log commits I've also made a change in this module
> A which might resolve the issue.
>
> I'm now running the integration tests B multiple times from command
> line, via Maven from within the source directory of B. I did of course
> "mvn clean install" the whole project first, which rebuilds module A
> and all of its dependencies.
>
> The really weird thing:
>  = rarely, the test fails, and there is no track of the logs I'm needing.
>  = sometimes, the test is successful and I have all logs as expected
> (but they are useless).
>  = rarely, the test is successful and these logs are missing.
>
> I've been running in circles since a couple of hours, but I *never*
> could get the combination of
>  (have the logs) && (test fails)
>
> The logger is set at DEBUG level for all of org.hibernate.search, and
> when I say the logs are missing I am referring to the new couple of
> log statements I just added exclusively: all other logs which
> org.hibernate.search normally produces are logged all the time.
>
> I'm starting to wonder if actually sometimes Maven runs my integration
> tests using a previous SNAPSHOT build, which would be missing both the
> logs and the fix, and in those cases it could either fail or not (as
> it wasn't always reproduced).
>
> Anyone else ever seen such an issue?
>
> I now blasted all my Search SNAPSHOT jars from the local repository
> and am running the tests in loop since 30 minutes and it's never
> failed.. but not comfortable with this.
>
> Also: I'm fighting what seems to be a timing issue, I wouldn't exclude
> that the additional logs actually prevent me to trigger the failure -
> but I have no explanation on why those logs sometimes are simply
> missing from the logfiles: they are certainly triggered.
>
> Thanks,
> Sanne

From smarlow at redhat.com  Thu Jul  9 19:31:13 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 9 Jul 2015 19:31:13 -0400
Subject: [hibernate-dev] Strange issues with -snapshot dependencies
In-Reply-To: <CAFm4XO3OqMSJPiFcYOt5rOqkjcnKqpwPPDsG0eZrwyHi_B_UJA@mail.gmail.com>
References: <CAFm4XO3OqMSJPiFcYOt5rOqkjcnKqpwPPDsG0eZrwyHi_B_UJA@mail.gmail.com>
Message-ID: <559F0441.1050708@redhat.com>


> I'm starting to wonder if actually sometimes Maven runs my integration
> tests using a previous SNAPSHOT build, which would be missing both the
> logs and the fix, and in those cases it could either fail or not (as
> it wasn't always reproduced).
>
> Anyone else ever seen such an issue?
>

I worry about this problem happening but haven't experienced it.  If 
your building the SNAPSHOT build locally that you want to use, would it 
make sense to give it a unique name that wouldn't be found in the remote 
maven repository?  Something like:

hibernateTargetVersion = '5.0.1-SANNE-SNAPSHOT'

That might be a pita but at least you would have more confidence that 
its right.

Another approach would be to disassemble (jad or procyon-decompiler) one 
of the SNAPSHOT jar classes to see if your code changes are in it.

From sanne at hibernate.org  Fri Jul 10 10:58:03 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 10 Jul 2015 15:58:03 +0100
Subject: [hibernate-dev] Strange issues with -snapshot dependencies
In-Reply-To: <559F0441.1050708@redhat.com>
References: <CAFm4XO3OqMSJPiFcYOt5rOqkjcnKqpwPPDsG0eZrwyHi_B_UJA@mail.gmail.com>
	<559F0441.1050708@redhat.com>
Message-ID: <CAFm4XO2E+gJCO2+5d=24qa8Damvc_axqZKhM79Ji+KGA2ucoSA@mail.gmail.com>

Hi Scott, thanks for your suggestions.
It turns out it wasn't a Maven or caching problem: everything made
more sense in the morning. My issue was Arquillian not running the
tests on the correct deployments, which explains why the log messages
weren't being triggered as the configuration wouldn't match what I had
been debugging.

All good now..
Thanks,
Sanne

On 10 July 2015 at 00:31, Scott Marlow <smarlow at redhat.com> wrote:
>
>> I'm starting to wonder if actually sometimes Maven runs my integration
>> tests using a previous SNAPSHOT build, which would be missing both the
>> logs and the fix, and in those cases it could either fail or not (as
>> it wasn't always reproduced).
>>
>> Anyone else ever seen such an issue?
>>
>
> I worry about this problem happening but haven't experienced it.  If your
> building the SNAPSHOT build locally that you want to use, would it make
> sense to give it a unique name that wouldn't be found in the remote maven
> repository?  Something like:
>
> hibernateTargetVersion = '5.0.1-SANNE-SNAPSHOT'
>
> That might be a pita but at least you would have more confidence that its
> right.
>
> Another approach would be to disassemble (jad or procyon-decompiler) one of
> the SNAPSHOT jar classes to see if your code changes are in it.

From gbadner at redhat.com  Fri Jul 10 20:09:33 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 10 Jul 2015 20:09:33 -0400 (EDT)
Subject: [hibernate-dev] How should hibernate-entitymanager test classes be
	instrumented?
In-Reply-To: <489792973.17732815.1436572867912.JavaMail.zimbra@redhat.com>
Message-ID: <299624817.17734130.1436573373692.JavaMail.zimbra@redhat.com>

I'm looking into some bugs having to do with lazy properties using Entity Manager. 

There is a commit for a pull request that adds an instrument task to hibernate-entitymanager.gradle that uses the ant task: 

https://github.com/gbadner/hibernate-core/commit/ecacc18cd48b960b7e9b303b6a298d4e15448d22

Is this acceptable? Is there a different way this should be done?

Thanks,
Gail

From sanne at hibernate.org  Mon Jul 13 11:51:11 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 13 Jul 2015 16:51:11 +0100
Subject: [hibernate-dev] Hibernate Search 5.4.0.CR1 is now available!
Message-ID: <CAFm4XO2tmg2s7auayzPGxBBh_o0JR-wB-=Oc-N3KnzbzOxNsoA@mail.gmail.com>

Hello all,
we're now ready for Hibernate ORM 5, last chance to make sure it's all right!

Details on the blog: http://in.relation.to/2015/07/13/hibernate-search-54CR1/

Thanks,
Sanne

From smarlow at redhat.com  Mon Jul 13 17:39:14 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 13 Jul 2015 17:39:14 -0400
Subject: [hibernate-dev] Should
 hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl
 be the default for Hibernate 5?
Message-ID: <55A43002.1020203@redhat.com>

Or should WildFly perhaps use 
hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl 
as the default?

Scott

From steve at hibernate.org  Mon Jul 13 18:43:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 13 Jul 2015 22:43:21 +0000
Subject: [hibernate-dev] How should hibernate-entitymanager test classes
 be instrumented?
In-Reply-To: <299624817.17734130.1436573373692.JavaMail.zimbra@redhat.com>
References: <489792973.17732815.1436572867912.JavaMail.zimbra@redhat.com>
	<299624817.17734130.1436573373692.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9sDALC9y8NidgCfQHRCHFn0sYHqk5SOAOyxUPNWa8UV5g@mail.gmail.com>

No, that is not the correct way.  That would force all test classes to be
instrumented where we only need a few to be instrumented.

There are 2 options:

1) Move all the tests that require instrumentation into a new SourceSet and
then associate the instrument task with that SourceSet only.
2) Use an "enhancing classloader" and instrument the classes as they are
loaded *for just those tests*.  We do this already today.
 org.hibernate.jpa.test.instrument.InterceptFieldClassFileTransformerTest
is one such test already in hibernate-entitymanager, but it is only
partial.  If you want to go this route, I'd suggest looking
at org.hibernate.test.instrument.runtime.AbstractTransformingClassLoaderInstrumentTestCase.
Luis also recently added some tests for the new bytecode enhancement code
that follow this paradigm.


On Fri, Jul 10, 2015 at 7:10 PM Gail Badner <gbadner at redhat.com> wrote:

> I'm looking into some bugs having to do with lazy properties using Entity
> Manager.
>
> There is a commit for a pull request that adds an instrument task to
> hibernate-entitymanager.gradle that uses the ant task:
>
>
> https://github.com/gbadner/hibernate-core/commit/ecacc18cd48b960b7e9b303b6a298d4e15448d22
>
> Is this acceptable? Is there a different way this should be done?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jul 13 18:45:18 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 13 Jul 2015 22:45:18 +0000
Subject: [hibernate-dev] Should
 hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl
 be the default for Hibernate 5?
In-Reply-To: <55A43002.1020203@redhat.com>
References: <55A43002.1020203@redhat.com>
Message-ID: <CAFdSV9tcD+8yXda4ZNQkV1TLKTsiiCweOD9sZ+KuLK2BVeY3_Q@mail.gmail.com>

No.  And possibly.

This is one of those things similar to "use new id generator mappings".
For new development I think it probably makes sense for WildFly users to
expect JPA-compliant implicit naming.    The difficulty is how changing
that would affect existing applications.

On Mon, Jul 13, 2015 at 5:37 PM Scott Marlow <smarlow at redhat.com> wrote:

> Or should WildFly perhaps use
>
> hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl
> as the default?
>
> Scott
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Mon Jul 13 19:12:10 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 13 Jul 2015 19:12:10 -0400 (EDT)
Subject: [hibernate-dev] How should hibernate-entitymanager test classes
 be instrumented?
In-Reply-To: <CAFdSV9sDALC9y8NidgCfQHRCHFn0sYHqk5SOAOyxUPNWa8UV5g@mail.gmail.com>
References: <489792973.17732815.1436572867912.JavaMail.zimbra@redhat.com>
	<299624817.17734130.1436573373692.JavaMail.zimbra@redhat.com>
	<CAFdSV9sDALC9y8NidgCfQHRCHFn0sYHqk5SOAOyxUPNWa8UV5g@mail.gmail.com>
Message-ID: <1878150465.18711208.1436829130624.JavaMail.zimbra@redhat.com>

OK, got it.
Thanks!
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>, "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Monday, July 13, 2015 3:43:21 PM
> Subject: Re: [hibernate-dev] How should hibernate-entitymanager test classes be instrumented?
> 
> No, that is not the correct way.  That would force all test classes to be
> instrumented where we only need a few to be instrumented.
> 
> There are 2 options:
> 
> 1) Move all the tests that require instrumentation into a new SourceSet and
> then associate the instrument task with that SourceSet only.
> 2) Use an "enhancing classloader" and instrument the classes as they are
> loaded *for just those tests*.  We do this already today.
>  org.hibernate.jpa.test.instrument.InterceptFieldClassFileTransformerTest
> is one such test already in hibernate-entitymanager, but it is only
> partial.  If you want to go this route, I'd suggest looking
> at
> org.hibernate.test.instrument.runtime.AbstractTransformingClassLoaderInstrumentTestCase.
> Luis also recently added some tests for the new bytecode enhancement code
> that follow this paradigm.
> 
> 
> On Fri, Jul 10, 2015 at 7:10 PM Gail Badner <gbadner at redhat.com> wrote:
> 
> > I'm looking into some bugs having to do with lazy properties using Entity
> > Manager.
> >
> > There is a commit for a pull request that adds an instrument task to
> > hibernate-entitymanager.gradle that uses the ant task:
> >
> >
> > https://github.com/gbadner/hibernate-core/commit/ecacc18cd48b960b7e9b303b6a298d4e15448d22
> >
> > Is this acceptable? Is there a different way this should be done?
> >
> > Thanks,
> > Gail
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

From steve at hibernate.org  Mon Jul 13 20:22:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 14 Jul 2015 00:22:26 +0000
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
	<CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
	<1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>
	<CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>
Message-ID: <CAFdSV9vqURJiyc9Di=oMC1f+q-F7jx0MyfRjmthMOp7voiEqng@mail.gmail.com>

Now that 5.0 development is settling down, I think its time to go ahead and
start on this.  Should we start next week?  We never discussed a day.  I am
thinking Monday or Tuesday.  Does that work for everyone interested?

Ultimately the idea is for this meeting to address incoming HHH issues.
But I realize the first few meetings might very well focus on past issues.


On Thu, Apr 16, 2015 at 8:16 AM Steve Ebersole <steve at hibernate.org> wrote:

> Sometime after the next 5.0 release.  You know, after I have time to
> breathe :)
>
> On Wed, Apr 15, 2015 at 5:06 PM, Gail Badner <gbadner at redhat.com> wrote:
>
>> When will we start having these meetings?
>>
>> ----- Original Message -----
>> > From: "Sanne Grinovero" <sanne at hibernate.org>
>> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > Sent: Monday, March 23, 2015 2:17:40 PM
>> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>> >
>> > +1 it's a nice time to allow me to join occasionally as needed
>> >
>> > Sanne
>> >
>> > On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com> wrote:
>> > > 11am Seattle time would be ideal. Thanks!
>> > > Gail
>> > >
>> > > ----- Original Message -----
>> > >> From: "Brett Meyer" <brmeyer at redhat.com>
>> > >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > >> Sent: Monday, March 23, 2015 6:51:49 AM
>> > >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>> > >>
>> > >> Big +1 from me -- I'd be more than happy to be involved.
>> > >>
>> > >> ----- Original Message -----
>> > >> > From: "andrea boriero" <dreborier at gmail.com>
>> > >> > To: "Steve Ebersole" <steve at hibernate.org>
>> > >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > >> > Sent: Sunday, March 22, 2015 3:45:01 PM
>> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>> > >> >
>> > >> > for me at the moment it would be 6pm and it should be good.
>> > >> >
>> > >> > On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> > >> >
>> > >> > > Gail and I discussed Jira a little bit last week and how to best
>> > >> > > manage
>> > >> > > scheduling issues.
>> > >> > >
>> > >> > > We both agreed that a team get together, either weekly or
>> > >> > > every-other-week,
>> > >> > > to discuss new issues to triage them would be a great idea.
>> > >> > >
>> > >> > > One thing I absolutely do not want happening is just scheduling
>> issues
>> > >> > > as
>> > >> > > a
>> > >> > > means to come back and triage them later.  Scheduling an issue,
>> on a
>> > >> > > "real
>> > >> > > version" anyway, should mean something.  It should mean some
>> level of
>> > >> > > dedication to finish that task for that release.  In short,
>> unless you
>> > >> > > are
>> > >> > > volunteering to take on a task *yourself* for that release,
>> please do
>> > >> > > not
>> > >> > > schedule it for that release.
>> > >> > >
>> > >> > > As for the triage meeting, I would definitely like Gail and
>> Andrea
>> > >> > > involved.  Of course anyone is welcome.  The reason I mention
>> this is
>> > >> > > that
>> > >> > > Gail is usually left on early side of scheduling these.  So we
>> will
>> > >> > > find
>> > >> > > a
>> > >> > > time that works best for us 3 and go from there.  I recommend
>> that we
>> > >> > > leverage HipChat for these discussion.
>> > >> > >
>> > >> > > Andrea is coming to Austin for a few days starting Monday, so I
>> would
>> > >> > > like
>> > >> > > to start this triaging while he is here.  Gail, I am thinking
>> 1pm my
>> > >> > > time
>> > >> > > (11am yours) would be a good time.  Andrea, does that work for
>> you
>> > >> > > after
>> > >> > > Austin?
>> > >> > > _______________________________________________
>> > >> > > 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
>> > _______________________________________________
>> > 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 hardy at hibernate.org  Tue Jul 14 05:38:11 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 14 Jul 2015 11:38:11 +0200
Subject: [hibernate-dev] SOAP / XML-RPC from JIRA is going dark on the
 20th
In-Reply-To: <CAFdSV9v33pbv3xMKQShQS-D2-vEU_pMnbENcdygq795gFnCaqA@mail.gmail.com>
References: <F380C7F2-EBF9-4CFB-9D04-0F3EEE18D2E7@hibernate.org>
	<CAFdSV9v33pbv3xMKQShQS-D2-vEU_pMnbENcdygq795gFnCaqA@mail.gmail.com>
Message-ID: <20150714093811.GA61492@Nineveh.local>

On Wed, Jul 08, 2015 at 04:06:42PM +0000, Steve Ebersole wrote:
> I would assume part of that is the Atlassian Connector for IntelliJ that I
> use.  Which sucks because now I would have to use the non-community version
> of the IDE to use tasks stuff.
> 
> Out of curiosity, how does everyone else using IntelliJ connect it to Jira
> or do y'all not connect it at all?

I have the Atlassian Connector configured as well, but tend to not use it that much.
Most of the time I use the browser. I have a bunch of shell scripts which connect to
JIRA, but they are using curl + JSON request, so I should be fine there.

--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/20150714/017f2df2/attachment.bin 

From gbadner at redhat.com  Tue Jul 14 13:06:04 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 14 Jul 2015 13:06:04 -0400 (EDT)
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAFdSV9vqURJiyc9Di=oMC1f+q-F7jx0MyfRjmthMOp7voiEqng@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
	<CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
	<1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>
	<CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>
	<CAFdSV9vqURJiyc9Di=oMC1f+q-F7jx0MyfRjmthMOp7voiEqng@mail.gmail.com>
Message-ID: <65940533.19312116.1436893564714.JavaMail.zimbra@redhat.com>

Next week is fine. Monday or Tuesday work for me.

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, July 13, 2015 5:22:26 PM
> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> 
> Now that 5.0 development is settling down, I think its time to go ahead and
> start on this.  Should we start next week?  We never discussed a day.  I am
> thinking Monday or Tuesday.  Does that work for everyone interested?
> 
> Ultimately the idea is for this meeting to address incoming HHH issues.
> But I realize the first few meetings might very well focus on past issues.
> 
> 
> On Thu, Apr 16, 2015 at 8:16 AM Steve Ebersole <steve at hibernate.org> wrote:
> 
> > Sometime after the next 5.0 release.  You know, after I have time to
> > breathe :)
> >
> > On Wed, Apr 15, 2015 at 5:06 PM, Gail Badner <gbadner at redhat.com> wrote:
> >
> >> When will we start having these meetings?
> >>
> >> ----- Original Message -----
> >> > From: "Sanne Grinovero" <sanne at hibernate.org>
> >> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >> > Sent: Monday, March 23, 2015 2:17:40 PM
> >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >> >
> >> > +1 it's a nice time to allow me to join occasionally as needed
> >> >
> >> > Sanne
> >> >
> >> > On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com> wrote:
> >> > > 11am Seattle time would be ideal. Thanks!
> >> > > Gail
> >> > >
> >> > > ----- Original Message -----
> >> > >> From: "Brett Meyer" <brmeyer at redhat.com>
> >> > >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >> > >> Sent: Monday, March 23, 2015 6:51:49 AM
> >> > >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >> > >>
> >> > >> Big +1 from me -- I'd be more than happy to be involved.
> >> > >>
> >> > >> ----- Original Message -----
> >> > >> > From: "andrea boriero" <dreborier at gmail.com>
> >> > >> > To: "Steve Ebersole" <steve at hibernate.org>
> >> > >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >> > >> > Sent: Sunday, March 22, 2015 3:45:01 PM
> >> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >> > >> >
> >> > >> > for me at the moment it would be 6pm and it should be good.
> >> > >> >
> >> > >> > On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >> > >> >
> >> > >> > > Gail and I discussed Jira a little bit last week and how to best
> >> > >> > > manage
> >> > >> > > scheduling issues.
> >> > >> > >
> >> > >> > > We both agreed that a team get together, either weekly or
> >> > >> > > every-other-week,
> >> > >> > > to discuss new issues to triage them would be a great idea.
> >> > >> > >
> >> > >> > > One thing I absolutely do not want happening is just scheduling
> >> issues
> >> > >> > > as
> >> > >> > > a
> >> > >> > > means to come back and triage them later.  Scheduling an issue,
> >> on a
> >> > >> > > "real
> >> > >> > > version" anyway, should mean something.  It should mean some
> >> level of
> >> > >> > > dedication to finish that task for that release.  In short,
> >> unless you
> >> > >> > > are
> >> > >> > > volunteering to take on a task *yourself* for that release,
> >> please do
> >> > >> > > not
> >> > >> > > schedule it for that release.
> >> > >> > >
> >> > >> > > As for the triage meeting, I would definitely like Gail and
> >> Andrea
> >> > >> > > involved.  Of course anyone is welcome.  The reason I mention
> >> this is
> >> > >> > > that
> >> > >> > > Gail is usually left on early side of scheduling these.  So we
> >> will
> >> > >> > > find
> >> > >> > > a
> >> > >> > > time that works best for us 3 and go from there.  I recommend
> >> that we
> >> > >> > > leverage HipChat for these discussion.
> >> > >> > >
> >> > >> > > Andrea is coming to Austin for a few days starting Monday, so I
> >> would
> >> > >> > > like
> >> > >> > > to start this triaging while he is here.  Gail, I am thinking
> >> 1pm my
> >> > >> > > time
> >> > >> > > (11am yours) would be a good time.  Andrea, does that work for
> >> you
> >> > >> > > after
> >> > >> > > Austin?
> >> > >> > > _______________________________________________
> >> > >> > > 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
> >> > _______________________________________________
> >> > 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 dreborier at gmail.com  Tue Jul 14 13:32:28 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 14 Jul 2015 18:32:28 +0100
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <65940533.19312116.1436893564714.JavaMail.zimbra@redhat.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
	<CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
	<1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>
	<CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>
	<CAFdSV9vqURJiyc9Di=oMC1f+q-F7jx0MyfRjmthMOp7voiEqng@mail.gmail.com>
	<65940533.19312116.1436893564714.JavaMail.zimbra@redhat.com>
Message-ID: <CAL00eST5mDp8t8N=dB59wRE5so4kTzc=07pr+5UOaA7jk4kvBg@mail.gmail.com>

I have a problem on Monday but Tuesday is fine.

On 14 July 2015 at 18:06, Gail Badner <gbadner at redhat.com> wrote:

> Next week is fine. Monday or Tuesday work for me.
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "Gail Badner" <gbadner at redhat.com>
> > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <
> hibernate-dev at lists.jboss.org>
> > Sent: Monday, July 13, 2015 5:22:26 PM
> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >
> > Now that 5.0 development is settling down, I think its time to go ahead
> and
> > start on this.  Should we start next week?  We never discussed a day.  I
> am
> > thinking Monday or Tuesday.  Does that work for everyone interested?
> >
> > Ultimately the idea is for this meeting to address incoming HHH issues.
> > But I realize the first few meetings might very well focus on past
> issues.
> >
> >
> > On Thu, Apr 16, 2015 at 8:16 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> > > Sometime after the next 5.0 release.  You know, after I have time to
> > > breathe :)
> > >
> > > On Wed, Apr 15, 2015 at 5:06 PM, Gail Badner <gbadner at redhat.com>
> wrote:
> > >
> > >> When will we start having these meetings?
> > >>
> > >> ----- Original Message -----
> > >> > From: "Sanne Grinovero" <sanne at hibernate.org>
> > >> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >> > Sent: Monday, March 23, 2015 2:17:40 PM
> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >> >
> > >> > +1 it's a nice time to allow me to join occasionally as needed
> > >> >
> > >> > Sanne
> > >> >
> > >> > On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com> wrote:
> > >> > > 11am Seattle time would be ideal. Thanks!
> > >> > > Gail
> > >> > >
> > >> > > ----- Original Message -----
> > >> > >> From: "Brett Meyer" <brmeyer at redhat.com>
> > >> > >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >> > >> Sent: Monday, March 23, 2015 6:51:49 AM
> > >> > >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >> > >>
> > >> > >> Big +1 from me -- I'd be more than happy to be involved.
> > >> > >>
> > >> > >> ----- Original Message -----
> > >> > >> > From: "andrea boriero" <dreborier at gmail.com>
> > >> > >> > To: "Steve Ebersole" <steve at hibernate.org>
> > >> > >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >> > >> > Sent: Sunday, March 22, 2015 3:45:01 PM
> > >> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >> > >> >
> > >> > >> > for me at the moment it would be 6pm and it should be good.
> > >> > >> >
> > >> > >> > On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org
> >
> > >> wrote:
> > >> > >> >
> > >> > >> > > Gail and I discussed Jira a little bit last week and how to
> best
> > >> > >> > > manage
> > >> > >> > > scheduling issues.
> > >> > >> > >
> > >> > >> > > We both agreed that a team get together, either weekly or
> > >> > >> > > every-other-week,
> > >> > >> > > to discuss new issues to triage them would be a great idea.
> > >> > >> > >
> > >> > >> > > One thing I absolutely do not want happening is just
> scheduling
> > >> issues
> > >> > >> > > as
> > >> > >> > > a
> > >> > >> > > means to come back and triage them later.  Scheduling an
> issue,
> > >> on a
> > >> > >> > > "real
> > >> > >> > > version" anyway, should mean something.  It should mean some
> > >> level of
> > >> > >> > > dedication to finish that task for that release.  In short,
> > >> unless you
> > >> > >> > > are
> > >> > >> > > volunteering to take on a task *yourself* for that release,
> > >> please do
> > >> > >> > > not
> > >> > >> > > schedule it for that release.
> > >> > >> > >
> > >> > >> > > As for the triage meeting, I would definitely like Gail and
> > >> Andrea
> > >> > >> > > involved.  Of course anyone is welcome.  The reason I mention
> > >> this is
> > >> > >> > > that
> > >> > >> > > Gail is usually left on early side of scheduling these.  So
> we
> > >> will
> > >> > >> > > find
> > >> > >> > > a
> > >> > >> > > time that works best for us 3 and go from there.  I recommend
> > >> that we
> > >> > >> > > leverage HipChat for these discussion.
> > >> > >> > >
> > >> > >> > > Andrea is coming to Austin for a few days starting Monday,
> so I
> > >> would
> > >> > >> > > like
> > >> > >> > > to start this triaging while he is here.  Gail, I am thinking
> > >> 1pm my
> > >> > >> > > time
> > >> > >> > > (11am yours) would be a good time.  Andrea, does that work
> for
> > >> you
> > >> > >> > > after
> > >> > >> > > Austin?
> > >> > >> > > _______________________________________________
> > >> > >> > > 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
> > >> > _______________________________________________
> > >> > 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  Tue Jul 14 14:07:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 14 Jul 2015 18:07:16 +0000
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAL00eST5mDp8t8N=dB59wRE5so4kTzc=07pr+5UOaA7jk4kvBg@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
	<CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
	<1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>
	<CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>
	<CAFdSV9vqURJiyc9Di=oMC1f+q-F7jx0MyfRjmthMOp7voiEqng@mail.gmail.com>
	<65940533.19312116.1436893564714.JavaMail.zimbra@redhat.com>
	<CAL00eST5mDp8t8N=dB59wRE5so4kTzc=07pr+5UOaA7jk4kvBg@mail.gmail.com>
Message-ID: <CAFdSV9tk71A6ZT79i=3u05P0QZjRzgonDUULMEL15QqttMue=A@mail.gmail.com>

Ok, then lets plan on next Tuesday on HiptChat...

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Hibernate+ORM+Triage+Meeting&iso=20150721T13&p1=24


On Tue, Jul 14, 2015 at 12:32 PM andrea boriero <dreborier at gmail.com> wrote:

> I have a problem on Monday but Tuesday is fine.
>
> On 14 July 2015 at 18:06, Gail Badner <gbadner at redhat.com> wrote:
>
>> Next week is fine. Monday or Tuesday work for me.
>>
>> ----- Original Message -----
>> > From: "Steve Ebersole" <steve at hibernate.org>
>> > To: "Gail Badner" <gbadner at redhat.com>
>> > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <
>> hibernate-dev at lists.jboss.org>
>> > Sent: Monday, July 13, 2015 5:22:26 PM
>> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>> >
>> > Now that 5.0 development is settling down, I think its time to go ahead
>> and
>> > start on this.  Should we start next week?  We never discussed a day.
>> I am
>> > thinking Monday or Tuesday.  Does that work for everyone interested?
>> >
>> > Ultimately the idea is for this meeting to address incoming HHH issues.
>> > But I realize the first few meetings might very well focus on past
>> issues.
>> >
>> >
>> > On Thu, Apr 16, 2015 at 8:16 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> > > Sometime after the next 5.0 release.  You know, after I have time to
>> > > breathe :)
>> > >
>> > > On Wed, Apr 15, 2015 at 5:06 PM, Gail Badner <gbadner at redhat.com>
>> wrote:
>> > >
>> > >> When will we start having these meetings?
>> > >>
>> > >> ----- Original Message -----
>> > >> > From: "Sanne Grinovero" <sanne at hibernate.org>
>> > >> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > >> > Sent: Monday, March 23, 2015 2:17:40 PM
>> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>> > >> >
>> > >> > +1 it's a nice time to allow me to join occasionally as needed
>> > >> >
>> > >> > Sanne
>> > >> >
>> > >> > On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com> wrote:
>> > >> > > 11am Seattle time would be ideal. Thanks!
>> > >> > > Gail
>> > >> > >
>> > >> > > ----- Original Message -----
>> > >> > >> From: "Brett Meyer" <brmeyer at redhat.com>
>> > >> > >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > >> > >> Sent: Monday, March 23, 2015 6:51:49 AM
>> > >> > >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>> > >> > >>
>> > >> > >> Big +1 from me -- I'd be more than happy to be involved.
>> > >> > >>
>> > >> > >> ----- Original Message -----
>> > >> > >> > From: "andrea boriero" <dreborier at gmail.com>
>> > >> > >> > To: "Steve Ebersole" <steve at hibernate.org>
>> > >> > >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > >> > >> > Sent: Sunday, March 22, 2015 3:45:01 PM
>> > >> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>> > >> > >> >
>> > >> > >> > for me at the moment it would be 6pm and it should be good.
>> > >> > >> >
>> > >> > >> > On 21 March 2015 at 21:08, Steve Ebersole <
>> steve at hibernate.org>
>> > >> wrote:
>> > >> > >> >
>> > >> > >> > > Gail and I discussed Jira a little bit last week and how to
>> best
>> > >> > >> > > manage
>> > >> > >> > > scheduling issues.
>> > >> > >> > >
>> > >> > >> > > We both agreed that a team get together, either weekly or
>> > >> > >> > > every-other-week,
>> > >> > >> > > to discuss new issues to triage them would be a great idea.
>> > >> > >> > >
>> > >> > >> > > One thing I absolutely do not want happening is just
>> scheduling
>> > >> issues
>> > >> > >> > > as
>> > >> > >> > > a
>> > >> > >> > > means to come back and triage them later.  Scheduling an
>> issue,
>> > >> on a
>> > >> > >> > > "real
>> > >> > >> > > version" anyway, should mean something.  It should mean some
>> > >> level of
>> > >> > >> > > dedication to finish that task for that release.  In short,
>> > >> unless you
>> > >> > >> > > are
>> > >> > >> > > volunteering to take on a task *yourself* for that release,
>> > >> please do
>> > >> > >> > > not
>> > >> > >> > > schedule it for that release.
>> > >> > >> > >
>> > >> > >> > > As for the triage meeting, I would definitely like Gail and
>> > >> Andrea
>> > >> > >> > > involved.  Of course anyone is welcome.  The reason I
>> mention
>> > >> this is
>> > >> > >> > > that
>> > >> > >> > > Gail is usually left on early side of scheduling these.  So
>> we
>> > >> will
>> > >> > >> > > find
>> > >> > >> > > a
>> > >> > >> > > time that works best for us 3 and go from there.  I
>> recommend
>> > >> that we
>> > >> > >> > > leverage HipChat for these discussion.
>> > >> > >> > >
>> > >> > >> > > Andrea is coming to Austin for a few days starting Monday,
>> so I
>> > >> would
>> > >> > >> > > like
>> > >> > >> > > to start this triaging while he is here.  Gail, I am
>> thinking
>> > >> 1pm my
>> > >> > >> > > time
>> > >> > >> > > (11am yours) would be a good time.  Andrea, does that work
>> for
>> > >> you
>> > >> > >> > > after
>> > >> > >> > > Austin?
>> > >> > >> > > _______________________________________________
>> > >> > >> > > 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
>> > >> > _______________________________________________
>> > >> > 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 gbadner at redhat.com  Tue Jul 14 20:08:33 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 14 Jul 2015 20:08:33 -0400 (EDT)
Subject: [hibernate-dev] How should hibernate-entitymanager test classes
 be instrumented?
In-Reply-To: <1878150465.18711208.1436829130624.JavaMail.zimbra@redhat.com>
References: <489792973.17732815.1436572867912.JavaMail.zimbra@redhat.com>
	<299624817.17734130.1436573373692.JavaMail.zimbra@redhat.com>
	<CAFdSV9sDALC9y8NidgCfQHRCHFn0sYHqk5SOAOyxUPNWa8UV5g@mail.gmail.com>
	<1878150465.18711208.1436829130624.JavaMail.zimbra@redhat.com>
Message-ID: <1965585302.19493396.1436918913691.JavaMail.zimbra@redhat.com>

Actually, I'm confused.

The pull request [1] contains:

+task instrument(dependsOn: compileTestJava) << {
+    ant.taskdef(name: 'hibInstrument',
+            classname: 'org.hibernate.tool.instrument.javassist.InstrumentTask',
+            classpath: configurations.testCompile.asPath)
+    ant.hibInstrument(verbose: 'true'){
+        fileset(dir:"$buildDir/classes/test/org/hibernate/jpa/test/callbacks/"){
+            include(name: "EntityWithLazyProperty.class")
+        }
+    }
+    println("hibernate instrumentation")
+}
+
+test.dependsOn instrument

IIUC, only $buildDir/classes/test/org/hibernate/jpa/test/callbacks/EntityWithLazyProperty.class is instrumented (not all test classes).

Am I missing something (very possible).

Thanks,
Gail

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Monday, July 13, 2015 4:12:10 PM
> Subject: Re: [hibernate-dev] How should hibernate-entitymanager test classes be instrumented?
> 
> OK, got it.
> Thanks!
> Gail
> 
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "Gail Badner" <gbadner at redhat.com>, "Hibernate"
> > <hibernate-dev at lists.jboss.org>
> > Sent: Monday, July 13, 2015 3:43:21 PM
> > Subject: Re: [hibernate-dev] How should hibernate-entitymanager test
> > classes be instrumented?
> > 
> > No, that is not the correct way.  That would force all test classes to be
> > instrumented where we only need a few to be instrumented.
> > 
> > There are 2 options:
> > 
> > 1) Move all the tests that require instrumentation into a new SourceSet and
> > then associate the instrument task with that SourceSet only.
> > 2) Use an "enhancing classloader" and instrument the classes as they are
> > loaded *for just those tests*.  We do this already today.
> >  org.hibernate.jpa.test.instrument.InterceptFieldClassFileTransformerTest
> > is one such test already in hibernate-entitymanager, but it is only
> > partial.  If you want to go this route, I'd suggest looking
> > at
> > org.hibernate.test.instrument.runtime.AbstractTransformingClassLoaderInstrumentTestCase.
> > Luis also recently added some tests for the new bytecode enhancement code
> > that follow this paradigm.
> > 
> > 
> > On Fri, Jul 10, 2015 at 7:10 PM Gail Badner <gbadner at redhat.com> wrote:
> > 
> > > I'm looking into some bugs having to do with lazy properties using Entity
> > > Manager.
> > >
> > > There is a commit for a pull request that adds an instrument task to
> > > hibernate-entitymanager.gradle that uses the ant task:
> > >
> > >
> > > https://github.com/gbadner/hibernate-core/commit/ecacc18cd48b960b7e9b303b6a298d4e15448d22
> > >
> > > Is this acceptable? Is there a different way this should be done?
> > >
> > > Thanks,
> > > Gail
> > > _______________________________________________
> > > 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 Jul 15 07:35:25 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 15 Jul 2015 12:35:25 +0100
Subject: [hibernate-dev] Hibernate Search fails to generate anything
In-Reply-To: <CAM4O4P5uAbdeCMHY_HP+TRd3k+Er+nZuJPiSsr8gUMLvY2DYjw@mail.gmail.com>
References: <CAM4O4P5uAbdeCMHY_HP+TRd3k+Er+nZuJPiSsr8gUMLvY2DYjw@mail.gmail.com>
Message-ID: <CAFm4XO1JxR+GL5xUAda+wj4M-thiO-t-ww4Xz+Mp6mVBgKf8MQ@mail.gmail.com>

Hi Koen,
this is a classloader issue for which we'll need your help. It's a
very simple issue: Hibernate ORM needs to see the services exposed
from Hibernate Search when the SessionFactory is started, so that it
triggers the correct integrations.

My guess is that some metadata needs to be changed in the Hibernate
ORM plugin to allow loading from the Search module. Is that something
you could help Dmitry with?

thanks,
Sanne


On 6 July 2015 at 14:29, Dmitry Bocharov <bdshadow at gmail.com> wrote:
> Hello, everyone!
> I'd like to discuss with you the problem. I'm writing a hibernate-search
> eclipse plugin and currently I have a problem with generating indexes.
> I try to generate indexes in HSearchServiceProxy class
> <https://github.com/Sanne/org.jboss.tools.hibernate.search/blob/master/hsearchplugins/org.jboss.tools.hibernate.search.runtime.v_4_5/src/org/jboss/tools/hibernate/search/HSearchServiceProxy.java>.
> The code runs till the end fine. I was able to debug it. However, nothing
> is created.
>
> I have a user project. In hibernate.cfg.xml there is:
>
> *  <property
> name="hibernate.search.default.directory_provider">filesystem</property>*
> *  <property
> name="hibernate.search.default.indexBase">D:\Spring\HibernateWS\gen_indexes</property>*
>
> Also there is
> *        <dependency>*
> *  <groupId>org.hibernate</groupId>*
> *  <artifactId>hibernate-search-orm</artifactId>*
> *  <version>5.0.1.Final</version>*
> *  </dependency>*
> in the *pom.xml* in order to annotate entities to index them:
>
> *@Entity*
> *@Indexed*
> *public class Person implements java.io.Serializable {*
> * @Id*
> * @GeneratedValue*
> * private int id;*
> * @Field(analyze=Analyze.YES, store=Store.NO)*
> * private String login;*
>
> When i try to create indexes as a user - it works fine. However, when I try
> to do it from my plugin nothing happens. I debugged and found that the call
> stack is the following: MassIndexerImpl.startAndWait() ->
> FullTextSessionImpl.getSearchIntegrator() ->
> ContextHelper.getSearchintegratorBySFI(SessionFactoryImplementor sfi) ->
> SearchFactoryReference.getSearchIntegrator(). And here
> <https://github.com/hibernate/hibernate-search/blob/c06e4fe5fbc6b5a09195f40d760a093691f2c7f2/orm/src/main/java/org/hibernate/search/hcore/impl/SearchFactoryReference.java>
> it
> creates and exception in getSearchIntegrator() because
> this.extendedIntegrator returns null.
>
> As I understand plugin classloader is different from user classloader. So
> that can be a problem. In my plugin I have hibernate-core 4.3.1 (from
> jbosstolls-hibernate) and hibernate-search (5.0.1 as a fragment of this
> jbosstolls-hibernate plugin) in the classpath. I found that versions are
> compatible, so it's not a problem.
>
> So the only problem, as I think, are different classloaders.
>
> Koen Aers and Sanne Grinovero are in touch with the problem. So If anyone
> else has any thoughts, it would be great to see =)
>
> Thanks in advance!
> Dmitry
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Jul 15 09:58:07 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Jul 2015 13:58:07 +0000
Subject: [hibernate-dev] ORM Quicks Starts and Tutorials
Message-ID: <CAFdSV9uT64B8F1TwrJJ5XEgWk14e=CzcGcqeQzAqLNr8tjEAdA@mail.gmail.com>

A quick heads up that I just completed migrating the ORM quick start guides
from DocBook to Asciidoctor (HHH-9916).  Part of this was to upgrade the
versions of asciidoctorj and the asciidoctor-gradle-plugin used in the
build.  Let me know if y'all see anything awry.

As far as styling, we currently just use the Asciidoctor default styling
without any branding etc.  When I find some time I would like to look at
styling and branding these a bit better.  For the most part I like the
style, I would just like to see our logos, header imsages, etc integrated.

From steve at hibernate.org  Wed Jul 15 10:32:32 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Jul 2015 14:32:32 +0000
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
Message-ID: <CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>

FWIW, I just tried to use the new in.relation.to url in g+ post but it was
not accepted.  Google did not say anything specific about why it was not
accepted.


On Thu, Jul 9, 2015 at 11:25 AM andrea boriero <dreborier at gmail.com> wrote:

> I have just modified the post, need only to push.
> Emmanuel can you just take care of mails, g+ etc?
>
>
> On 9 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> I?ll do this.
>>
>>
>> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org> wrote:
>> >
>> > Too late now.  I am off for some hiking / camping with my fianc?.
>> >
>> > If someone could do me a favor and take the blog post from staging (or
>> > better yet, the post from Github release) and make a post on production
>> and
>> > finish announcing the release (email, g+, etc) I would really
>> appreciate it.
>> >
>> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>> >
>> >>> As I said, I had trouble writing this blog in the new asciidoctor
>> >> stuff.  I
>> >>> had some trouble getting ruby etal set up locally.  Sanne had
>> mentioned
>> >>> that I could just push to staging branch and CI would automatically
>> build
>> >>> it for me and I could check it that way.  Well the CI job clearly saw
>> my
>> >>> change and initiated a build[1].  The staging build succeeded, but my
>> >> post
>> >>> was never displayed on the staging.in.relation.to site.
>> >>
>> >> I just did two test builds and in both cases the changes were visible
>> >> directly
>> >> after the CI build finished. I would say try again and if you see the
>> same
>> >> problem
>> >> again we take a closer look.
>> >>
>> >> --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 sanne at hibernate.org  Wed Jul 15 11:38:24 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 15 Jul 2015 16:38:24 +0100
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
	<CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
Message-ID: <CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>

Could you elaborate please? You could not link to our domain?
On 15 Jul 2015 15:33, "Steve Ebersole" <steve at hibernate.org> wrote:

> FWIW, I just tried to use the new in.relation.to url in g+ post but it was
> not accepted.  Google did not say anything specific about why it was not
> accepted.
>
>
> On Thu, Jul 9, 2015 at 11:25 AM andrea boriero <dreborier at gmail.com>
> wrote:
>
> > I have just modified the post, need only to push.
> > Emmanuel can you just take care of mails, g+ etc?
> >
> >
> > On 9 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >
> >> I?ll do this.
> >>
> >>
> >> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org> wrote:
> >> >
> >> > Too late now.  I am off for some hiking / camping with my fianc?.
> >> >
> >> > If someone could do me a favor and take the blog post from staging (or
> >> > better yet, the post from Github release) and make a post on
> production
> >> and
> >> > finish announcing the release (email, g+, etc) I would really
> >> appreciate it.
> >> >
> >> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik <hardy at hibernate.org>
> >> wrote:
> >> >
> >> >>> As I said, I had trouble writing this blog in the new asciidoctor
> >> >> stuff.  I
> >> >>> had some trouble getting ruby etal set up locally.  Sanne had
> >> mentioned
> >> >>> that I could just push to staging branch and CI would automatically
> >> build
> >> >>> it for me and I could check it that way.  Well the CI job clearly
> saw
> >> my
> >> >>> change and initiated a build[1].  The staging build succeeded, but
> my
> >> >> post
> >> >>> was never displayed on the staging.in.relation.to site.
> >> >>
> >> >> I just did two test builds and in both cases the changes were visible
> >> >> directly
> >> >> after the CI build finished. I would say try again and if you see the
> >> same
> >> >> problem
> >> >> again we take a closer look.
> >> >>
> >> >> --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  Wed Jul 15 12:20:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Jul 2015 16:20:24 +0000
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
	<CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
	<CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>
Message-ID: <CAFdSV9uz4bRKz5fukrk452fOiMwAZvjm3UT2EjNY-1-hx7djqg@mail.gmail.com>

Gunnar mentioned having the same problem.  On the Hibernate.org g+ page, if
I try to add a post that contains a link to our in.relation.to domain, it
will not let me create the post.

On Wed, Jul 15, 2015 at 10:47 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Could you elaborate please? You could not link to our domain?
> On 15 Jul 2015 15:33, "Steve Ebersole" <steve at hibernate.org> wrote:
>
>> FWIW, I just tried to use the new in.relation.to url in g+ post but it
>> was
>> not accepted.  Google did not say anything specific about why it was not
>> accepted.
>>
>>
>> On Thu, Jul 9, 2015 at 11:25 AM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>> > I have just modified the post, need only to push.
>> > Emmanuel can you just take care of mails, g+ etc?
>> >
>> >
>> > On 9 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org>
>> wrote:
>> >
>> >> I?ll do this.
>> >>
>> >>
>> >> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >> >
>> >> > Too late now.  I am off for some hiking / camping with my fianc?.
>> >> >
>> >> > If someone could do me a favor and take the blog post from staging
>> (or
>> >> > better yet, the post from Github release) and make a post on
>> production
>> >> and
>> >> > finish announcing the release (email, g+, etc) I would really
>> >> appreciate it.
>> >> >
>> >> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik <hardy at hibernate.org>
>> >> wrote:
>> >> >
>> >> >>> As I said, I had trouble writing this blog in the new asciidoctor
>> >> >> stuff.  I
>> >> >>> had some trouble getting ruby etal set up locally.  Sanne had
>> >> mentioned
>> >> >>> that I could just push to staging branch and CI would automatically
>> >> build
>> >> >>> it for me and I could check it that way.  Well the CI job clearly
>> saw
>> >> my
>> >> >>> change and initiated a build[1].  The staging build succeeded, but
>> my
>> >> >> post
>> >> >>> was never displayed on the staging.in.relation.to site.
>> >> >>
>> >> >> I just did two test builds and in both cases the changes were
>> visible
>> >> >> directly
>> >> >> after the CI build finished. I would say try again and if you see
>> the
>> >> same
>> >> >> problem
>> >> >> again we take a closer look.
>> >> >>
>> >> >> --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 sanne at hibernate.org  Thu Jul 16 06:13:07 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 16 Jul 2015 11:13:07 +0100
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFdSV9uz4bRKz5fukrk452fOiMwAZvjm3UT2EjNY-1-hx7djqg@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
	<CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
	<CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>
	<CAFdSV9uz4bRKz5fukrk452fOiMwAZvjm3UT2EjNY-1-hx7djqg@mail.gmail.com>
Message-ID: <CAFm4XO27TA8EQv4u3=7BKJYL574Xc1XDFUcv-d48UMBZ9pVXXg@mail.gmail.com>

I had no problems have anyone post on g+ and link to in.relation.to:
https://plus.google.com/101574584265991227194/posts/AsM3PUHwLBX

Is there some limitation on the Hibernate.org g+ specifically?

On 15 July 2015 at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
> Gunnar mentioned having the same problem.  On the Hibernate.org g+ page, if
> I try to add a post that contains a link to our in.relation.to domain, it
> will not let me create the post.
>
> On Wed, Jul 15, 2015 at 10:47 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Could you elaborate please? You could not link to our domain?
>>
>> On 15 Jul 2015 15:33, "Steve Ebersole" <steve at hibernate.org> wrote:
>>>
>>> FWIW, I just tried to use the new in.relation.to url in g+ post but it
>>> was
>>> not accepted.  Google did not say anything specific about why it was not
>>> accepted.
>>>
>>>
>>> On Thu, Jul 9, 2015 at 11:25 AM andrea boriero <dreborier at gmail.com>
>>> wrote:
>>>
>>> > I have just modified the post, need only to push.
>>> > Emmanuel can you just take care of mails, g+ etc?
>>> >
>>> >
>>> > On 9 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org>
>>> > wrote:
>>> >
>>> >> I?ll do this.
>>> >>
>>> >>
>>> >> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org>
>>> >> > wrote:
>>> >> >
>>> >> > Too late now.  I am off for some hiking / camping with my fianc?.
>>> >> >
>>> >> > If someone could do me a favor and take the blog post from staging
>>> >> > (or
>>> >> > better yet, the post from Github release) and make a post on
>>> >> > production
>>> >> and
>>> >> > finish announcing the release (email, g+, etc) I would really
>>> >> appreciate it.
>>> >> >
>>> >> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik <hardy at hibernate.org>
>>> >> wrote:
>>> >> >
>>> >> >>> As I said, I had trouble writing this blog in the new asciidoctor
>>> >> >> stuff.  I
>>> >> >>> had some trouble getting ruby etal set up locally.  Sanne had
>>> >> mentioned
>>> >> >>> that I could just push to staging branch and CI would
>>> >> >>> automatically
>>> >> build
>>> >> >>> it for me and I could check it that way.  Well the CI job clearly
>>> >> >>> saw
>>> >> my
>>> >> >>> change and initiated a build[1].  The staging build succeeded, but
>>> >> >>> my
>>> >> >> post
>>> >> >>> was never displayed on the staging.in.relation.to site.
>>> >> >>
>>> >> >> I just did two test builds and in both cases the changes were
>>> >> >> visible
>>> >> >> directly
>>> >> >> after the CI build finished. I would say try again and if you see
>>> >> >> the
>>> >> same
>>> >> >> problem
>>> >> >> again we take a closer look.
>>> >> >>
>>> >> >> --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 gunnar at hibernate.org  Thu Jul 16 06:24:53 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 16 Jul 2015 12:24:53 +0200
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFm4XO27TA8EQv4u3=7BKJYL574Xc1XDFUcv-d48UMBZ9pVXXg@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
	<CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
	<CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>
	<CAFdSV9uz4bRKz5fukrk452fOiMwAZvjm3UT2EjNY-1-hx7djqg@mail.gmail.com>
	<CAFm4XO27TA8EQv4u3=7BKJYL574Xc1XDFUcv-d48UMBZ9pVXXg@mail.gmail.com>
Message-ID: <CADGJaX8GXfd1+Q7SHeAUjXUX1QSVRHj+ikLLT_vhgO0oPFmr2A@mail.gmail.com>

But his this a real "shared link"? This does not work for me with the CR2
post, also not on my personal account.

2015-07-16 12:13 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> I had no problems have anyone post on g+ and link to in.relation.to:
> https://plus.google.com/101574584265991227194/posts/AsM3PUHwLBX
>
> Is there some limitation on the Hibernate.org g+ specifically?
>
> On 15 July 2015 at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
> > Gunnar mentioned having the same problem.  On the Hibernate.org g+ page,
> if
> > I try to add a post that contains a link to our in.relation.to domain,
> it
> > will not let me create the post.
> >
> > On Wed, Jul 15, 2015 at 10:47 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> Could you elaborate please? You could not link to our domain?
> >>
> >> On 15 Jul 2015 15:33, "Steve Ebersole" <steve at hibernate.org> wrote:
> >>>
> >>> FWIW, I just tried to use the new in.relation.to url in g+ post but it
> >>> was
> >>> not accepted.  Google did not say anything specific about why it was
> not
> >>> accepted.
> >>>
> >>>
> >>> On Thu, Jul 9, 2015 at 11:25 AM andrea boriero <dreborier at gmail.com>
> >>> wrote:
> >>>
> >>> > I have just modified the post, need only to push.
> >>> > Emmanuel can you just take care of mails, g+ etc?
> >>> >
> >>> >
> >>> > On 9 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org>
> >>> > wrote:
> >>> >
> >>> >> I?ll do this.
> >>> >>
> >>> >>
> >>> >> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org>
> >>> >> > wrote:
> >>> >> >
> >>> >> > Too late now.  I am off for some hiking / camping with my fianc?.
> >>> >> >
> >>> >> > If someone could do me a favor and take the blog post from staging
> >>> >> > (or
> >>> >> > better yet, the post from Github release) and make a post on
> >>> >> > production
> >>> >> and
> >>> >> > finish announcing the release (email, g+, etc) I would really
> >>> >> appreciate it.
> >>> >> >
> >>> >> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik <
> hardy at hibernate.org>
> >>> >> wrote:
> >>> >> >
> >>> >> >>> As I said, I had trouble writing this blog in the new
> asciidoctor
> >>> >> >> stuff.  I
> >>> >> >>> had some trouble getting ruby etal set up locally.  Sanne had
> >>> >> mentioned
> >>> >> >>> that I could just push to staging branch and CI would
> >>> >> >>> automatically
> >>> >> build
> >>> >> >>> it for me and I could check it that way.  Well the CI job
> clearly
> >>> >> >>> saw
> >>> >> my
> >>> >> >>> change and initiated a build[1].  The staging build succeeded,
> but
> >>> >> >>> my
> >>> >> >> post
> >>> >> >>> was never displayed on the staging.in.relation.to site.
> >>> >> >>
> >>> >> >> I just did two test builds and in both cases the changes were
> >>> >> >> visible
> >>> >> >> directly
> >>> >> >> after the CI build finished. I would say try again and if you see
> >>> >> >> the
> >>> >> same
> >>> >> >> problem
> >>> >> >> again we take a closer look.
> >>> >> >>
> >>> >> >> --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
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Thu Jul 16 06:37:20 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 16 Jul 2015 11:37:20 +0100
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CADGJaX8GXfd1+Q7SHeAUjXUX1QSVRHj+ikLLT_vhgO0oPFmr2A@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
	<CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
	<CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>
	<CAFdSV9uz4bRKz5fukrk452fOiMwAZvjm3UT2EjNY-1-hx7djqg@mail.gmail.com>
	<CAFm4XO27TA8EQv4u3=7BKJYL574Xc1XDFUcv-d48UMBZ9pVXXg@mail.gmail.com>
	<CADGJaX8GXfd1+Q7SHeAUjXUX1QSVRHj+ikLLT_vhgO0oPFmr2A@mail.gmail.com>
Message-ID: <CAFm4XO0Gn52X7kB7pwfgkKQZWbD-VcuxeJmV0nKLstBSrp6DYw@mail.gmail.com>

Ah, that helps; I hadn't understood you were talking about the "share
link" feature.

I could reproduce the problem now; it seems one probable cause is the
in.relation.to website to contain invalid microdata. I wanted to
improve the microdata anyway so I'll have a look this evening.

Thanks,
Sanne


On 16 July 2015 at 11:24, Gunnar Morling <gunnar at hibernate.org> wrote:
> But his this a real "shared link"? This does not work for me with the CR2
> post, also not on my personal account.
>
> 2015-07-16 12:13 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> I had no problems have anyone post on g+ and link to in.relation.to:
>> https://plus.google.com/101574584265991227194/posts/AsM3PUHwLBX
>>
>> Is there some limitation on the Hibernate.org g+ specifically?
>>
>> On 15 July 2015 at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
>> > Gunnar mentioned having the same problem.  On the Hibernate.org g+ page,
>> > if
>> > I try to add a post that contains a link to our in.relation.to domain,
>> > it
>> > will not let me create the post.
>> >
>> > On Wed, Jul 15, 2015 at 10:47 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> Could you elaborate please? You could not link to our domain?
>> >>
>> >> On 15 Jul 2015 15:33, "Steve Ebersole" <steve at hibernate.org> wrote:
>> >>>
>> >>> FWIW, I just tried to use the new in.relation.to url in g+ post but it
>> >>> was
>> >>> not accepted.  Google did not say anything specific about why it was
>> >>> not
>> >>> accepted.
>> >>>
>> >>>
>> >>> On Thu, Jul 9, 2015 at 11:25 AM andrea boriero <dreborier at gmail.com>
>> >>> wrote:
>> >>>
>> >>> > I have just modified the post, need only to push.
>> >>> > Emmanuel can you just take care of mails, g+ etc?
>> >>> >
>> >>> >
>> >>> > On 9 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org>
>> >>> > wrote:
>> >>> >
>> >>> >> I?ll do this.
>> >>> >>
>> >>> >>
>> >>> >> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org>
>> >>> >> > wrote:
>> >>> >> >
>> >>> >> > Too late now.  I am off for some hiking / camping with my fianc?.
>> >>> >> >
>> >>> >> > If someone could do me a favor and take the blog post from
>> >>> >> > staging
>> >>> >> > (or
>> >>> >> > better yet, the post from Github release) and make a post on
>> >>> >> > production
>> >>> >> and
>> >>> >> > finish announcing the release (email, g+, etc) I would really
>> >>> >> appreciate it.
>> >>> >> >
>> >>> >> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik
>> >>> >> > <hardy at hibernate.org>
>> >>> >> wrote:
>> >>> >> >
>> >>> >> >>> As I said, I had trouble writing this blog in the new
>> >>> >> >>> asciidoctor
>> >>> >> >> stuff.  I
>> >>> >> >>> had some trouble getting ruby etal set up locally.  Sanne had
>> >>> >> mentioned
>> >>> >> >>> that I could just push to staging branch and CI would
>> >>> >> >>> automatically
>> >>> >> build
>> >>> >> >>> it for me and I could check it that way.  Well the CI job
>> >>> >> >>> clearly
>> >>> >> >>> saw
>> >>> >> my
>> >>> >> >>> change and initiated a build[1].  The staging build succeeded,
>> >>> >> >>> but
>> >>> >> >>> my
>> >>> >> >> post
>> >>> >> >>> was never displayed on the staging.in.relation.to site.
>> >>> >> >>
>> >>> >> >> I just did two test builds and in both cases the changes were
>> >>> >> >> visible
>> >>> >> >> directly
>> >>> >> >> after the CI build finished. I would say try again and if you
>> >>> >> >> see
>> >>> >> >> the
>> >>> >> same
>> >>> >> >> problem
>> >>> >> >> again we take a closer look.
>> >>> >> >>
>> >>> >> >> --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
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>


From sanne at hibernate.org  Thu Jul 16 18:35:15 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 16 Jul 2015 23:35:15 +0100
Subject: [hibernate-dev] Missing transaction hangs the testsuite
Message-ID: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>

I finally got to re-enable MariaDB and PostgreSQL based tests for
Hibernate Search - which has been running on H2 only for some months -
and had to debug a case of a single test hanging for a long time.

Essentially it would block - for hours - on the SessionFactory#close()
method, attempting to drop the database schema with the following
statement:
  > alter table AncientBook_alternativeTitles drop constraint
FKn8hhkmhof1mdgc4oi77ccq989

Dumping threads I would get a very similar stack trace on both
databases; initially I thought someone had copy/pasted a socket
handling bug from one JDBC driver to the other ;-)

The PostgreSQL testsuite hanging:

"main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable [0x00007f0f48956000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
- locked <0x00000007c11e3860> (a org.postgresql.core.v3.QueryExecutorImpl)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
at org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
at org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
at org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

The MariaDB testsuite hanging:

"main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable [0x00007f8ca5f5c000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
- locked <0x00000007c0baa518> (a com.mysql.jdbc.util.ReadAheadInputStream)
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
- locked <0x00000007c0baa850> (a java.lang.Object)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
- locked <0x00000007c0baa850> (a java.lang.Object)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
at org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
at org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
at org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

On Gail's suggestion I went looking for database level locks; I hadn't
thought of that as I assumed it would have timed out more aggressively
rather than have me wait for hours.
It turns out she was right and the reason for blocking was a simple
"count *" query being run as a post-test assertion, which we had
forgotten to wrap in an "open transaction & commit" statements pair.
The test assertion would be successful, but apparently it would hold
on the table lock beyond closing the Session and, then fail to drop
the database at the teardown of the test.

I'm wondering if this is expected, or if there's something in the new
transaction handling code which could be improved? It took me several
hours to figure this out; maybe I'm just not using ORM as frequently
as once :)
If it's this critical to have the transaction, maybe it should be mandatory?

And as a memo for next time, this is the query to figure out details
about locks on our testing db:
 > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid
= psa.pid where datname = 'testingdb';

Thanks,
Sanne

From steve at hibernate.org  Thu Jul 16 18:59:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 16 Jul 2015 22:59:23 +0000
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
Message-ID: <CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>

There is really nothing to improve.  What would you suggest as an
improvement?  I mean from a ORM perspective, we have an auto-commit
Connection (presumably) and run a query.  How on earth would we know to
expect that the database is holding locks for that?

As far as "requiring transactions" I have tried to fly that plane multiple
times in the past.  I think it is absolutely ridiculous to allow these
auto-commit use cases.  In fact I personally wanted to take it to the more
extreme case of always using JTA and simply mimicking "single resource
JTA transactions"
internally in the "JDBC transaction" case.  Gavin and I both did in fact.
But we got a lot of push back.

So I am not sure exactly what the improvement here might be.  What is it
you were thinking specifically?

On Thu, Jul 16, 2015 at 5:36 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> I finally got to re-enable MariaDB and PostgreSQL based tests for
> Hibernate Search - which has been running on H2 only for some months -
> and had to debug a case of a single test hanging for a long time.
>
> Essentially it would block - for hours - on the SessionFactory#close()
> method, attempting to drop the database schema with the following
> statement:
>   > alter table AncientBook_alternativeTitles drop constraint
> FKn8hhkmhof1mdgc4oi77ccq989
>
> Dumping threads I would get a very similar stack trace on both
> databases; initially I thought someone had copy/pasted a socket
> handling bug from one JDBC driver to the other ;-)
>
> The PostgreSQL testsuite hanging:
>
> "main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable
> [0x00007f0f48956000]
>    java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at
> org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
> at
> org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
> at
> org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
> at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
> at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
> at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
> - locked <0x00000007c11e3860> (a org.postgresql.core.v3.QueryExecutorImpl)
> at
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
> at
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
> at
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
> at
> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
> at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
> at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
> at
> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
> at
> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
> at
> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>
> The MariaDB testsuite hanging:
>
> "main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable
> [0x00007f8ca5f5c000]
>    java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> at
> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
> at
> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
> at
> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
> - locked <0x00000007c0baa518> (a com.mysql.jdbc.util.ReadAheadInputStream)
> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
> - locked <0x00000007c0baa850> (a java.lang.Object)
> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
> - locked <0x00000007c0baa850> (a java.lang.Object)
> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
> at
> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
> at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
> at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
> at
> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
> at
> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
> at
> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>
> On Gail's suggestion I went looking for database level locks; I hadn't
> thought of that as I assumed it would have timed out more aggressively
> rather than have me wait for hours.
> It turns out she was right and the reason for blocking was a simple
> "count *" query being run as a post-test assertion, which we had
> forgotten to wrap in an "open transaction & commit" statements pair.
> The test assertion would be successful, but apparently it would hold
> on the table lock beyond closing the Session and, then fail to drop
> the database at the teardown of the test.
>
> I'm wondering if this is expected, or if there's something in the new
> transaction handling code which could be improved? It took me several
> hours to figure this out; maybe I'm just not using ORM as frequently
> as once :)
> If it's this critical to have the transaction, maybe it should be
> mandatory?
>
> And as a memo for next time, this is the query to figure out details
> about locks on our testing db:
>  > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid
> = psa.pid where datname = 'testingdb';
>
> 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  Thu Jul 16 19:14:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 16 Jul 2015 23:14:41 +0000
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
	<CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>
Message-ID: <CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>

For what it is worth, I am running into the same problems on MySQL for the
ORM tests in terms of blocks on dropping tables.  PGSQL at least finishes,
although I run into 55 errors which I still need to triage.

On Thu, Jul 16, 2015 at 5:59 PM Steve Ebersole <steve at hibernate.org> wrote:

> There is really nothing to improve.  What would you suggest as an
> improvement?  I mean from a ORM perspective, we have an auto-commit
> Connection (presumably) and run a query.  How on earth would we know to
> expect that the database is holding locks for that?
>
> As far as "requiring transactions" I have tried to fly that plane multiple
> times in the past.  I think it is absolutely ridiculous to allow these
> auto-commit use cases.  In fact I personally wanted to take it to the more
> extreme case of always using JTA and simply mimicking "single resource JTA transactions"
> internally in the "JDBC transaction" case.  Gavin and I both did in fact.
> But we got a lot of push back.
>
> So I am not sure exactly what the improvement here might be.  What is it
> you were thinking specifically?
>
> On Thu, Jul 16, 2015 at 5:36 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> I finally got to re-enable MariaDB and PostgreSQL based tests for
>> Hibernate Search - which has been running on H2 only for some months -
>> and had to debug a case of a single test hanging for a long time.
>>
>> Essentially it would block - for hours - on the SessionFactory#close()
>> method, attempting to drop the database schema with the following
>> statement:
>>   > alter table AncientBook_alternativeTitles drop constraint
>> FKn8hhkmhof1mdgc4oi77ccq989
>>
>> Dumping threads I would get a very similar stack trace on both
>> databases; initially I thought someone had copy/pasted a socket
>> handling bug from one JDBC driver to the other ;-)
>>
>> The PostgreSQL testsuite hanging:
>>
>> "main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable
>> [0x00007f0f48956000]
>>    java.lang.Thread.State: RUNNABLE
>> at java.net.SocketInputStream.socketRead0(Native Method)
>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> at
>> org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
>> at
>> org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
>> at
>> org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
>> at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
>> - locked <0x00000007c11e3860> (a org.postgresql.core.v3.QueryExecutorImpl)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
>> at
>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>> at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>> at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>> at
>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>> at
>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>> at
>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>>
>> The MariaDB testsuite hanging:
>>
>> "main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable
>> [0x00007f8ca5f5c000]
>>    java.lang.Thread.State: RUNNABLE
>> at java.net.SocketInputStream.socketRead0(Native Method)
>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> at
>> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
>> at
>> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
>> at
>> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
>> - locked <0x00000007c0baa518> (a com.mysql.jdbc.util.ReadAheadInputStream)
>> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
>> - locked <0x00000007c0baa850> (a java.lang.Object)
>> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
>> - locked <0x00000007c0baa850> (a java.lang.Object)
>> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
>> at
>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>> at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>> at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>> at
>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>> at
>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>> at
>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>>
>> On Gail's suggestion I went looking for database level locks; I hadn't
>> thought of that as I assumed it would have timed out more aggressively
>> rather than have me wait for hours.
>> It turns out she was right and the reason for blocking was a simple
>> "count *" query being run as a post-test assertion, which we had
>> forgotten to wrap in an "open transaction & commit" statements pair.
>> The test assertion would be successful, but apparently it would hold
>> on the table lock beyond closing the Session and, then fail to drop
>> the database at the teardown of the test.
>>
>> I'm wondering if this is expected, or if there's something in the new
>> transaction handling code which could be improved? It took me several
>> hours to figure this out; maybe I'm just not using ORM as frequently
>> as once :)
>> If it's this critical to have the transaction, maybe it should be
>> mandatory?
>>
>> And as a memo for next time, this is the query to figure out details
>> about locks on our testing db:
>>  > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid
>> = psa.pid where datname = 'testingdb';
>>
>> 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  Fri Jul 17 04:51:32 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 17 Jul 2015 09:51:32 +0100
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
	<CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>
	<CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>
Message-ID: <CAFm4XO0Wb=cx0Od884aYR7cM_uFSSCMUFdXpLyeASnDriy=_Lw@mail.gmail.com>

Thanks Steve, I wasn't sure if I had found a problem.
Still, it looks like the Hibernate Search tests are not benefiting
from auto-commit, or I wouldn't have this problem right? Our testing
configuration properties have been the same for years and I'm just
re-enabling tests which haven't been run for a while, so I suspect
something changed in ORM.

I think I'd expect Hibernate ORM to automatically enable auto-commit
on operations not running within a transaction, to make sure all locks
are released when the Session is closed.

Thanks,
Sanne

On 17 July 2015 at 00:14, Steve Ebersole <steve at hibernate.org> wrote:
> For what it is worth, I am running into the same problems on MySQL for the
> ORM tests in terms of blocks on dropping tables.  PGSQL at least finishes,
> although I run into 55 errors which I still need to triage.
>
> On Thu, Jul 16, 2015 at 5:59 PM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> There is really nothing to improve.  What would you suggest as an
>> improvement?  I mean from a ORM perspective, we have an ato-commit
>> Connection (presumably) and run a query.  How on earth would we know to
>> expect that the database is holding locks for that?
>>
>> As far as "requiring transactions" I have tried to fly that plane multiple
>> times in the past.  I think it is absolutely ridiculous to allow these
>> auto-commit use cases.  In fact I personally wanted to take it to the more
>> extreme case of always using JTA and simply mimicking "single resource JTA
>> transactions" internally in the "JDBC transaction" case.  Gavin and I both
>> did in fact.  But we got a lot of push back.
>>
>> So I am not sure exactly what the improvement here might be.  What is it
>> you were thinking specifically?
>>
>> On Thu, Jul 16, 2015 at 5:36 PM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> I finally got to re-enable MariaDB and PostgreSQL based tests for
>>> Hibernate Search - which has been running on H2 only for some months -
>>> and had to debug a case of a single test hanging for a long time.
>>>
>>> Essentially it would block - for hours - on the SessionFactory#close()
>>> method, attempting to drop the database schema with the following
>>> statement:
>>>   > alter table AncientBook_alternativeTitles drop constraint
>>> FKn8hhkmhof1mdgc4oi77ccq989
>>>
>>> Dumping threads I would get a very similar stack trace on both
>>> databases; initially I thought someone had copy/pasted a socket
>>> handling bug from one JDBC driver to the other ;-)
>>>
>>> The PostgreSQL testsuite hanging:
>>>
>>> "main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable
>>> [0x00007f0f48956000]
>>>    java.lang.Thread.State: RUNNABLE
>>> at java.net.SocketInputStream.socketRead0(Native Method)
>>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>>> at
>>> org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
>>> at
>>> org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
>>> at
>>> org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
>>> at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
>>> at
>>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
>>> at
>>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
>>> - locked <0x00000007c11e3860> (a
>>> org.postgresql.core.v3.QueryExecutorImpl)
>>> at
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
>>> at
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
>>> at
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
>>> at
>>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>>> at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>>> at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>>> at
>>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>>> at
>>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>>> at
>>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>>>
>>> The MariaDB testsuite hanging:
>>>
>>> "main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable
>>> [0x00007f8ca5f5c000]
>>>    java.lang.Thread.State: RUNNABLE
>>> at java.net.SocketInputStream.socketRead0(Native Method)
>>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>>> at
>>> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
>>> at
>>> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
>>> at
>>> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
>>> - locked <0x00000007c0baa518> (a
>>> com.mysql.jdbc.util.ReadAheadInputStream)
>>> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
>>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
>>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
>>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
>>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
>>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
>>> - locked <0x00000007c0baa850> (a java.lang.Object)
>>> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
>>> - locked <0x00000007c0baa850> (a java.lang.Object)
>>> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
>>> at
>>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>>> at org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>>> at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>>> at
>>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>>> at
>>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>>> at
>>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>>>
>>> On Gail's suggestion I went looking for database level locks; I hadn't
>>> thought of that as I assumed it would have timed out more aggressively
>>> rather than have me wait for hours.
>>> It turns out she was right and the reason for blocking was a simple
>>> "count *" query being run as a post-test assertion, which we had
>>> forgotten to wrap in an "open transaction & commit" statements pair.
>>> The test assertion would be successful, but apparently it would hold
>>> on the table lock beyond closing the Session and, then fail to drop
>>> the database at the teardown of the test.
>>>
>>> I'm wondering if this is expected, or if there's something in the new
>>> transaction handling code which could be improved? It took me several
>>> hours to figure this out; maybe I'm just not using ORM as frequently
>>> as once :)
>>> If it's this critical to have the transaction, maybe it should be
>>> mandatory?
>>>
>>> And as a memo for next time, this is the query to figure out details
>>> about locks on our testing db:
>>>  > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid
>>> = psa.pid where datname = 'testingdb';
>>>
>>> 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  Fri Jul 17 05:03:59 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 17 Jul 2015 10:03:59 +0100
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFm4XO0Gn52X7kB7pwfgkKQZWbD-VcuxeJmV0nKLstBSrp6DYw@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
	<CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
	<CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>
	<CAFdSV9uz4bRKz5fukrk452fOiMwAZvjm3UT2EjNY-1-hx7djqg@mail.gmail.com>
	<CAFm4XO27TA8EQv4u3=7BKJYL574Xc1XDFUcv-d48UMBZ9pVXXg@mail.gmail.com>
	<CADGJaX8GXfd1+Q7SHeAUjXUX1QSVRHj+ikLLT_vhgO0oPFmr2A@mail.gmail.com>
	<CAFm4XO0Gn52X7kB7pwfgkKQZWbD-VcuxeJmV0nKLstBSrp6DYw@mail.gmail.com>
Message-ID: <CAFm4XO11J9ok7O10minu81+OPawv+U7Hwhscnsj00GAe+Gky4Q@mail.gmail.com>

G+ link sharing works now. Thanks Gunnar and Emmanuel for the quick
"meta fix" WEBSITE-380!

Cheers,
Sanne

On 16 July 2015 at 11:37, Sanne Grinovero <sanne at hibernate.org> wrote:
> Ah, that helps; I hadn't understood you were talking about the "share
> link" feature.
>
> I could reproduce the problem now; it seems one probable cause is the
> in.relation.to website to contain invalid microdata. I wanted to
> improve the microdata anyway so I'll have a look this evening.
>
> Thanks,
> Sanne
>
>
> On 16 July 2015 at 11:24, Gunnar Morling <gunnar at hibernate.org> wrote:
>> But his this a real "shared link"? This does not work for me with the CR2
>> post, also not on my personal account.
>>
>> 2015-07-16 12:13 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>> I had no problems have anyone post on g+ and link to in.relation.to:
>>> https://plus.google.com/101574584265991227194/posts/AsM3PUHwLBX
>>>
>>> Is there some limitation on the Hibernate.org g+ specifically?
>>>
>>> On 15 July 2015 at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
>>> > Gunnar mentioned having the same problem.  On the Hibernate.org g+ page,
>>> > if
>>> > I try to add a post that contains a link to our in.relation.to domain,
>>> > it
>>> > will not let me create the post.
>>> >
>>> > On Wed, Jul 15, 2015 at 10:47 AM Sanne Grinovero <sanne at hibernate.org>
>>> > wrote:
>>> >>
>>> >> Could you elaborate please? You could not link to our domain?
>>> >>
>>> >> On 15 Jul 2015 15:33, "Steve Ebersole" <steve at hibernate.org> wrote:
>>> >>>
>>> >>> FWIW, I just tried to use the new in.relation.to url in g+ post but it
>>> >>> was
>>> >>> not accepted.  Google did not say anything specific about why it was
>>> >>> not
>>> >>> accepted.
>>> >>>
>>> >>>
>>> >>> On Thu, Jul 9, 2015 at 11:25 AM andrea boriero <dreborier at gmail.com>
>>> >>> wrote:
>>> >>>
>>> >>> > I have just modified the post, need only to push.
>>> >>> > Emmanuel can you just take care of mails, g+ etc?
>>> >>> >
>>> >>> >
>>> >>> > On 9 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org>
>>> >>> > wrote:
>>> >>> >
>>> >>> >> I?ll do this.
>>> >>> >>
>>> >>> >>
>>> >>> >> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org>
>>> >>> >> > wrote:
>>> >>> >> >
>>> >>> >> > Too late now.  I am off for some hiking / camping with my fianc?.
>>> >>> >> >
>>> >>> >> > If someone could do me a favor and take the blog post from
>>> >>> >> > staging
>>> >>> >> > (or
>>> >>> >> > better yet, the post from Github release) and make a post on
>>> >>> >> > production
>>> >>> >> and
>>> >>> >> > finish announcing the release (email, g+, etc) I would really
>>> >>> >> appreciate it.
>>> >>> >> >
>>> >>> >> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik
>>> >>> >> > <hardy at hibernate.org>
>>> >>> >> wrote:
>>> >>> >> >
>>> >>> >> >>> As I said, I had trouble writing this blog in the new
>>> >>> >> >>> asciidoctor
>>> >>> >> >> stuff.  I
>>> >>> >> >>> had some trouble getting ruby etal set up locally.  Sanne had
>>> >>> >> mentioned
>>> >>> >> >>> that I could just push to staging branch and CI would
>>> >>> >> >>> automatically
>>> >>> >> build
>>> >>> >> >>> it for me and I could check it that way.  Well the CI job
>>> >>> >> >>> clearly
>>> >>> >> >>> saw
>>> >>> >> my
>>> >>> >> >>> change and initiated a build[1].  The staging build succeeded,
>>> >>> >> >>> but
>>> >>> >> >>> my
>>> >>> >> >> post
>>> >>> >> >>> was never displayed on the staging.in.relation.to site.
>>> >>> >> >>
>>> >>> >> >> I just did two test builds and in both cases the changes were
>>> >>> >> >> visible
>>> >>> >> >> directly
>>> >>> >> >> after the CI build finished. I would say try again and if you
>>> >>> >> >> see
>>> >>> >> >> the
>>> >>> >> same
>>> >>> >> >> problem
>>> >>> >> >> again we take a closer look.
>>> >>> >> >>
>>> >>> >> >> --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
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>


From gunnar at hibernate.org  Fri Jul 17 05:07:51 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 17 Jul 2015 11:07:51 +0200
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CAFm4XO11J9ok7O10minu81+OPawv+U7Hwhscnsj00GAe+Gky4Q@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
	<CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
	<CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>
	<CAFdSV9uz4bRKz5fukrk452fOiMwAZvjm3UT2EjNY-1-hx7djqg@mail.gmail.com>
	<CAFm4XO27TA8EQv4u3=7BKJYL574Xc1XDFUcv-d48UMBZ9pVXXg@mail.gmail.com>
	<CADGJaX8GXfd1+Q7SHeAUjXUX1QSVRHj+ikLLT_vhgO0oPFmr2A@mail.gmail.com>
	<CAFm4XO0Gn52X7kB7pwfgkKQZWbD-VcuxeJmV0nKLstBSrp6DYw@mail.gmail.com>
	<CAFm4XO11J9ok7O10minu81+OPawv+U7Hwhscnsj00GAe+Gky4Q@mail.gmail.com>
Message-ID: <CADGJaX-Jh65Q5s8E05SoPgN4C=pZaNdF-u33wEGieVRQ-Qp17w@mail.gmail.com>

Interesting, so they'd really block the link from being shared due to the
broken author meta-data.

2015-07-17 11:03 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> G+ link sharing works now. Thanks Gunnar and Emmanuel for the quick
> "meta fix" WEBSITE-380!
>
> Cheers,
> Sanne
>
> On 16 July 2015 at 11:37, Sanne Grinovero <sanne at hibernate.org> wrote:
> > Ah, that helps; I hadn't understood you were talking about the "share
> > link" feature.
> >
> > I could reproduce the problem now; it seems one probable cause is the
> > in.relation.to website to contain invalid microdata. I wanted to
> > improve the microdata anyway so I'll have a look this evening.
> >
> > Thanks,
> > Sanne
> >
> >
> > On 16 July 2015 at 11:24, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> But his this a real "shared link"? This does not work for me with the
> CR2
> >> post, also not on my personal account.
> >>
> >> 2015-07-16 12:13 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>>
> >>> I had no problems have anyone post on g+ and link to in.relation.to:
> >>> https://plus.google.com/101574584265991227194/posts/AsM3PUHwLBX
> >>>
> >>> Is there some limitation on the Hibernate.org g+ specifically?
> >>>
> >>> On 15 July 2015 at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
> >>> > Gunnar mentioned having the same problem.  On the Hibernate.org g+
> page,
> >>> > if
> >>> > I try to add a post that contains a link to our in.relation.to
> domain,
> >>> > it
> >>> > will not let me create the post.
> >>> >
> >>> > On Wed, Jul 15, 2015 at 10:47 AM Sanne Grinovero <
> sanne at hibernate.org>
> >>> > wrote:
> >>> >>
> >>> >> Could you elaborate please? You could not link to our domain?
> >>> >>
> >>> >> On 15 Jul 2015 15:33, "Steve Ebersole" <steve at hibernate.org> wrote:
> >>> >>>
> >>> >>> FWIW, I just tried to use the new in.relation.to url in g+ post
> but it
> >>> >>> was
> >>> >>> not accepted.  Google did not say anything specific about why it
> was
> >>> >>> not
> >>> >>> accepted.
> >>> >>>
> >>> >>>
> >>> >>> On Thu, Jul 9, 2015 at 11:25 AM andrea boriero <
> dreborier at gmail.com>
> >>> >>> wrote:
> >>> >>>
> >>> >>> > I have just modified the post, need only to push.
> >>> >>> > Emmanuel can you just take care of mails, g+ etc?
> >>> >>> >
> >>> >>> >
> >>> >>> > On 9 July 2015 at 17:16, Emmanuel Bernard <
> emmanuel at hibernate.org>
> >>> >>> > wrote:
> >>> >>> >
> >>> >>> >> I?ll do this.
> >>> >>> >>
> >>> >>> >>
> >>> >>> >> > On 09 Jul 2015, at 15:35, Steve Ebersole <steve at hibernate.org
> >
> >>> >>> >> > wrote:
> >>> >>> >> >
> >>> >>> >> > Too late now.  I am off for some hiking / camping with my
> fianc?.
> >>> >>> >> >
> >>> >>> >> > If someone could do me a favor and take the blog post from
> >>> >>> >> > staging
> >>> >>> >> > (or
> >>> >>> >> > better yet, the post from Github release) and make a post on
> >>> >>> >> > production
> >>> >>> >> and
> >>> >>> >> > finish announcing the release (email, g+, etc) I would really
> >>> >>> >> appreciate it.
> >>> >>> >> >
> >>> >>> >> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik
> >>> >>> >> > <hardy at hibernate.org>
> >>> >>> >> wrote:
> >>> >>> >> >
> >>> >>> >> >>> As I said, I had trouble writing this blog in the new
> >>> >>> >> >>> asciidoctor
> >>> >>> >> >> stuff.  I
> >>> >>> >> >>> had some trouble getting ruby etal set up locally.  Sanne
> had
> >>> >>> >> mentioned
> >>> >>> >> >>> that I could just push to staging branch and CI would
> >>> >>> >> >>> automatically
> >>> >>> >> build
> >>> >>> >> >>> it for me and I could check it that way.  Well the CI job
> >>> >>> >> >>> clearly
> >>> >>> >> >>> saw
> >>> >>> >> my
> >>> >>> >> >>> change and initiated a build[1].  The staging build
> succeeded,
> >>> >>> >> >>> but
> >>> >>> >> >>> my
> >>> >>> >> >> post
> >>> >>> >> >>> was never displayed on the staging.in.relation.to site.
> >>> >>> >> >>
> >>> >>> >> >> I just did two test builds and in both cases the changes were
> >>> >>> >> >> visible
> >>> >>> >> >> directly
> >>> >>> >> >> after the CI build finished. I would say try again and if you
> >>> >>> >> >> see
> >>> >>> >> >> the
> >>> >>> >> same
> >>> >>> >> >> problem
> >>> >>> >> >> again we take a closer look.
> >>> >>> >> >>
> >>> >>> >> >> --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
> >>>
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
>

From sanne at hibernate.org  Fri Jul 17 05:12:58 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 17 Jul 2015 10:12:58 +0100
Subject: [hibernate-dev] Second candidate release for Hibernate ORM 5.0
In-Reply-To: <CADGJaX-Jh65Q5s8E05SoPgN4C=pZaNdF-u33wEGieVRQ-Qp17w@mail.gmail.com>
References: <CAFdSV9sznZQky+WQBzOKbWs9DEpVwKLxJ565tuK=ht90NDvQOg@mail.gmail.com>
	<CAFdSV9tLrvKUOh0mkGVWgrNf8ejcNC4orDz8+Yyp7rQeNNimPg@mail.gmail.com>
	<20150708211225.GH35306@Nineveh.lan>
	<CAFdSV9tFJvr0HSx+g=PkPNS8szYkwgzpDJkFfqPzUuFnV0WF5Q@mail.gmail.com>
	<122BC20D-7A0D-4AEF-AA66-75080C9B365D@hibernate.org>
	<CAL00eSSKUfD19=b2aeYUvmfO=xyJf84rK8GXNdFiCQo+-p94uQ@mail.gmail.com>
	<CAFdSV9ujonmn-2W34jg6JpdE_C5aGdFESHrRHnAO1pCf8jyXzw@mail.gmail.com>
	<CAFm4XO0s7iqDwVNdeLDmW_YRtmqZ_xOe+-uT9F0WgV+hDRZmTQ@mail.gmail.com>
	<CAFdSV9uz4bRKz5fukrk452fOiMwAZvjm3UT2EjNY-1-hx7djqg@mail.gmail.com>
	<CAFm4XO27TA8EQv4u3=7BKJYL574Xc1XDFUcv-d48UMBZ9pVXXg@mail.gmail.com>
	<CADGJaX8GXfd1+Q7SHeAUjXUX1QSVRHj+ikLLT_vhgO0oPFmr2A@mail.gmail.com>
	<CAFm4XO0Gn52X7kB7pwfgkKQZWbD-VcuxeJmV0nKLstBSrp6DYw@mail.gmail.com>
	<CAFm4XO11J9ok7O10minu81+OPawv+U7Hwhscnsj00GAe+Gky4Q@mail.gmail.com>
	<CADGJaX-Jh65Q5s8E05SoPgN4C=pZaNdF-u33wEGieVRQ-Qp17w@mail.gmail.com>
Message-ID: <CAFm4XO2LUMbCSUimddiY_2V=ycS70o2V2ZW9KqSF3yOMCegF4g@mail.gmail.com>

On 17 July 2015 at 10:07, Gunnar Morling <gunnar at hibernate.org> wrote:
> Interesting, so they'd really block the link from being shared due to the
> broken author meta-data.

And worse: you get strongly penalized in SEO terms. Next we should add
valid microdata.

-- Sanne

>
> 2015-07-17 11:03 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> G+ link sharing works now. Thanks Gunnar and Emmanuel for the quick
>> "meta fix" WEBSITE-380!
>>
>> Cheers,
>> Sanne
>>
>> On 16 July 2015 at 11:37, Sanne Grinovero <sanne at hibernate.org> wrote:
>> > Ah, that helps; I hadn't understood you were talking about the "share
>> > link" feature.
>> >
>> > I could reproduce the problem now; it seems one probable cause is the
>> > in.relation.to website to contain invalid microdata. I wanted to
>> > improve the microdata anyway so I'll have a look this evening.
>> >
>> > Thanks,
>> > Sanne
>> >
>> >
>> > On 16 July 2015 at 11:24, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> But his this a real "shared link"? This does not work for me with the
>> >> CR2
>> >> post, also not on my personal account.
>> >>
>> >> 2015-07-16 12:13 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>>
>> >>> I had no problems have anyone post on g+ and link to in.relation.to:
>> >>> https://plus.google.com/101574584265991227194/posts/AsM3PUHwLBX
>> >>>
>> >>> Is there some limitation on the Hibernate.org g+ specifically?
>> >>>
>> >>> On 15 July 2015 at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
>> >>> > Gunnar mentioned having the same problem.  On the Hibernate.org g+
>> >>> > page,
>> >>> > if
>> >>> > I try to add a post that contains a link to our in.relation.to
>> >>> > domain,
>> >>> > it
>> >>> > will not let me create the post.
>> >>> >
>> >>> > On Wed, Jul 15, 2015 at 10:47 AM Sanne Grinovero
>> >>> > <sanne at hibernate.org>
>> >>> > wrote:
>> >>> >>
>> >>> >> Could you elaborate please? You could not link to our domain?
>> >>> >>
>> >>> >> On 15 Jul 2015 15:33, "Steve Ebersole" <steve at hibernate.org> wrote:
>> >>> >>>
>> >>> >>> FWIW, I just tried to use the new in.relation.to url in g+ post
>> >>> >>> but it
>> >>> >>> was
>> >>> >>> not accepted.  Google did not say anything specific about why it
>> >>> >>> was
>> >>> >>> not
>> >>> >>> accepted.
>> >>> >>>
>> >>> >>>
>> >>> >>> On Thu, Jul 9, 2015 at 11:25 AM andrea boriero
>> >>> >>> <dreborier at gmail.com>
>> >>> >>> wrote:
>> >>> >>>
>> >>> >>> > I have just modified the post, need only to push.
>> >>> >>> > Emmanuel can you just take care of mails, g+ etc?
>> >>> >>> >
>> >>> >>> >
>> >>> >>> > On 9 July 2015 at 17:16, Emmanuel Bernard
>> >>> >>> > <emmanuel at hibernate.org>
>> >>> >>> > wrote:
>> >>> >>> >
>> >>> >>> >> I?ll do this.
>> >>> >>> >>
>> >>> >>> >>
>> >>> >>> >> > On 09 Jul 2015, at 15:35, Steve Ebersole
>> >>> >>> >> > <steve at hibernate.org>
>> >>> >>> >> > wrote:
>> >>> >>> >> >
>> >>> >>> >> > Too late now.  I am off for some hiking / camping with my
>> >>> >>> >> > fianc?.
>> >>> >>> >> >
>> >>> >>> >> > If someone could do me a favor and take the blog post from
>> >>> >>> >> > staging
>> >>> >>> >> > (or
>> >>> >>> >> > better yet, the post from Github release) and make a post on
>> >>> >>> >> > production
>> >>> >>> >> and
>> >>> >>> >> > finish announcing the release (email, g+, etc) I would really
>> >>> >>> >> appreciate it.
>> >>> >>> >> >
>> >>> >>> >> > On Wed, Jul 8, 2015, 4:12 PM Hardy Ferentschik
>> >>> >>> >> > <hardy at hibernate.org>
>> >>> >>> >> wrote:
>> >>> >>> >> >
>> >>> >>> >> >>> As I said, I had trouble writing this blog in the new
>> >>> >>> >> >>> asciidoctor
>> >>> >>> >> >> stuff.  I
>> >>> >>> >> >>> had some trouble getting ruby etal set up locally.  Sanne
>> >>> >>> >> >>> had
>> >>> >>> >> mentioned
>> >>> >>> >> >>> that I could just push to staging branch and CI would
>> >>> >>> >> >>> automatically
>> >>> >>> >> build
>> >>> >>> >> >>> it for me and I could check it that way.  Well the CI job
>> >>> >>> >> >>> clearly
>> >>> >>> >> >>> saw
>> >>> >>> >> my
>> >>> >>> >> >>> change and initiated a build[1].  The staging build
>> >>> >>> >> >>> succeeded,
>> >>> >>> >> >>> but
>> >>> >>> >> >>> my
>> >>> >>> >> >> post
>> >>> >>> >> >>> was never displayed on the staging.in.relation.to site.
>> >>> >>> >> >>
>> >>> >>> >> >> I just did two test builds and in both cases the changes
>> >>> >>> >> >> were
>> >>> >>> >> >> visible
>> >>> >>> >> >> directly
>> >>> >>> >> >> after the CI build finished. I would say try again and if
>> >>> >>> >> >> you
>> >>> >>> >> >> see
>> >>> >>> >> >> the
>> >>> >>> >> same
>> >>> >>> >> >> problem
>> >>> >>> >> >> again we take a closer look.
>> >>> >>> >> >>
>> >>> >>> >> >> --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
>> >>>
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>
>


From gunnar at hibernate.org  Fri Jul 17 09:11:21 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 17 Jul 2015 15:11:21 +0200
Subject: [hibernate-dev] Naming strategies and collection element columns
Message-ID: <CADGJaX8OAvtXdB=S_827ZEaJ_kyACJ_jM6wWA1uxM7e9DLzZ1A@mail.gmail.com>

Steve,

There is one remaining itch I have wrt. upgrading OGM to ORM 5.

I have an entity GrandMother with an @ElementCollection "grandChildren" of
type GrandChild. The latter has a property "name" which used to be passed
as "grandChildren.collection&&element.name" to OGM's
NamingStrategy#propertyToColumnName(). We used to detect the
"collection&&element" pattern to determine the right column name fin OGM.

As of ORM 5, this is passed as "grandChildren.name" instead (due to
HHH-6005 [1]). Now I thought
ImplicitBasicColumnNameSource#isCollectionElement() would tell me whether
this is a collection element, but it returns false in this case.

Shouldn't it return true if the replacement magic for HHH-6005 has kicked
in Ejb3Column#redefineColumnName()?

Thanks,

--Gunnar

[1] https://hibernate.atlassian.net/browse/HHH-6005

From gunnar at hibernate.org  Fri Jul 17 10:46:23 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 17 Jul 2015 16:46:23 +0200
Subject: [hibernate-dev] Naming strategies and collection element columns
In-Reply-To: <CADGJaX8OAvtXdB=S_827ZEaJ_kyACJ_jM6wWA1uxM7e9DLzZ1A@mail.gmail.com>
References: <CADGJaX8OAvtXdB=S_827ZEaJ_kyACJ_jM6wWA1uxM7e9DLzZ1A@mail.gmail.com>
Message-ID: <CADGJaX-LuenDXGfYt42WVLeDhuKie7vrGnDBOqW=mK5ULeG71g@mail.gmail.com>

Turns out our ImplicitNamingStrategy's determineBasicColumnName() is
invoked twice at different places within Ejb3Column. Once the magic
HHH-6005 replacement takes place (in redefineColumnName()) and the other
time it doesn't (addColumnBinding()).

So we are once called with "grandChildren.name" and the other time
with "grandChildren.collection&&element.name". This seems not right, but
then the code in Ejb3Column is quite dense and I may well miss something.

Any ideas?


2015-07-17 15:11 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> Steve,
>
> There is one remaining itch I have wrt. upgrading OGM to ORM 5.
>
> I have an entity GrandMother with an @ElementCollection "grandChildren" of
> type GrandChild. The latter has a property "name" which used to be passed
> as "grandChildren.collection&&element.name" to OGM's
> NamingStrategy#propertyToColumnName(). We used to detect the
> "collection&&element" pattern to determine the right column name fin OGM.
>
> As of ORM 5, this is passed as "grandChildren.name" instead (due to
> HHH-6005 [1]). Now I thought
> ImplicitBasicColumnNameSource#isCollectionElement() would tell me whether
> this is a collection element, but it returns false in this case.
>
> Shouldn't it return true if the replacement magic for HHH-6005 has kicked
> in Ejb3Column#redefineColumnName()?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/HHH-6005
>
>

From mpaluch at paluch.biz  Fri Jul 17 11:16:58 2015
From: mpaluch at paluch.biz (Mark Paluch)
Date: Fri, 17 Jul 2015 15:16:58 +0000
Subject: [hibernate-dev] Proposal for a Redis module in Hibernate OGM
Message-ID: <CAE-fDMt69N=1zDNiq+p-0rtiTvEFJov2F-z-1PjR66US6ombZg@mail.gmail.com>

Hi there,

I created a Redis module for Hibernate OGM, based on OGM 4.2. Redis is a
Key-Value store supporting Lists, Hashes (Maps), Sorted Sets, ...

I took the Infinispan/CouchDB approach storing entities and associations as
JSON documents within Redis Hashes. A Map<Object, Map<Object, Object>>
corresponds with a Redis Hash.

The entity table maps to the Hash Id, the entity Id to the key of the hash
and the set of columns is enclosed within a JSON (currently). Supported
features are:

* Composite Id's
* Embedded associations
* External associations

and I guess many more, that I'm currently not aware of :-)

There are various ways (JSON, Java-serialized simulating Documents) how to
store data within Redis.
Another approach could be storing Tuples within Redis more native, since
they are in the end Maps, somehow. However, mapping tuples to Redis fit a
native storage but raises questions about Id's, limited data type support
(there is no equivalent for nested lists/maps). So the more native approach
would require distributing data amongst various data types, depending on
the supported features, and would require more IO's.

My impl can be used to interoperate with other clients from the C, Ruby,
Python, Node.js, ... worlds. The JSON is clean and does not look awkward on
the first look.

The current code can be found below
https://github.com/mp911de/hibernate-ogm/tree/redis. Most TCK tests pass,
only some 15 tests fail. Mostly due to enum and JTA support. Couldn't
figure out, how to fix it, so need your help to figure it out.

Hope, I made you hungry for the Redis OGM module. Let's start a discussion
based on my proposal for inclusion and let's see, where we end up.

Best regards, Mark

From steve at hibernate.org  Fri Jul 17 11:25:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Jul 2015 15:25:54 +0000
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFm4XO0Wb=cx0Od884aYR7cM_uFSSCMUFdXpLyeASnDriy=_Lw@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
	<CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>
	<CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>
	<CAFm4XO0Wb=cx0Od884aYR7cM_uFSSCMUFdXpLyeASnDriy=_Lw@mail.gmail.com>
Message-ID: <CAFdSV9vBu+xr=JJ+pbyjx+hfy4nyiE6p5sv6tEmmNZN7qa0w2A@mail.gmail.com>

It would seem that this is a regression with ORM, I agree.  However, we do
not know how recent of a regression.  And that is the problem.  We have no
idea how far back to look.  Because the ORM CI jobs against MySQL,
PostrgreSQL, Oracle, etc have not been running for many months.  IIRC even
when they were running on the old CI servers we had problems with those
jobs that were not looked at for some time.

As far as what you see, I am not convinced it is what you think it is in
terms of auto-commit for queries run outside of a transaction.  This part
has not changed in 5.0.  Assuming you are using the "built in Connection
pool", there is a setting that controls the auto-commit mode of the
connections we create (hibernate.connection.autocommit).  That setting has
always been there, and it has always defaulted to false.  This has not
changed.  In fact the same exact code is used in 4.3 and 5.0 for creating
these Connections:
org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.
The autoCommit value in there comes from the setting I just mentioned.  The
logical outcome is the same even before 4.3, just that it was done
differently.  So bottom line, if you are not seeing auto-commit on these
Connections now, you never were.  Now it is possible that their are some
ancillary changes that cause the lack of auto-commit to now be an issue
where it was not before.  So first, I'd need to know whether the Connection
here is auto-commit or is not.  From there we can start drilling down on
what might be a cause.  But keep in mind too, that with hangs and deadlocks
the process that hangs is often not the culprit; often it is the previous
process that is holding locks that is the culprit.

My case is actually different, at least on the surface.  Mine happens on
dropping tables after the test is complete (for MySQL anyway).  Which got
me to looking at schema export and friends and how they handle
connections.  They handle connections quite differently.  Again the same as
they used to, but I mean very different from how sessions manage
connections.  In schema export the connections are always set to
auto-commit mode at the start of processing.  Then they never do anything
with auto-commit afterwards.  I am not sure this is right.




On Fri, Jul 17, 2015 at 3:51 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Thanks Steve, I wasn't sure if I had found a problem.
> Still, it looks like the Hibernate Search tests are not benefiting
> from auto-commit, or I wouldn't have this problem right? Our testing
> configuration properties have been the same for years and I'm just
> re-enabling tests which haven't been run for a while, so I suspect
> something changed in ORM.
>
> I think I'd expect Hibernate ORM to automatically enable auto-commit
> on operations not running within a transaction, to make sure all locks
> are released when the Session is closed.
>
> Thanks,
> Sanne
>
> On 17 July 2015 at 00:14, Steve Ebersole <steve at hibernate.org> wrote:
> > For what it is worth, I am running into the same problems on MySQL for
> the
> > ORM tests in terms of blocks on dropping tables.  PGSQL at least
> finishes,
> > although I run into 55 errors which I still need to triage.
> >
> > On Thu, Jul 16, 2015 at 5:59 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> There is really nothing to improve.  What would you suggest as an
> >> improvement?  I mean from a ORM perspective, we have an ato-commit
> >> Connection (presumably) and run a query.  How on earth would we know to
> >> expect that the database is holding locks for that?
> >>
> >> As far as "requiring transactions" I have tried to fly that plane
> multiple
> >> times in the past.  I think it is absolutely ridiculous to allow these
> >> auto-commit use cases.  In fact I personally wanted to take it to the
> more
> >> extreme case of always using JTA and simply mimicking "single resource
> JTA
> >> transactions" internally in the "JDBC transaction" case.  Gavin and I
> both
> >> did in fact.  But we got a lot of push back.
> >>
> >> So I am not sure exactly what the improvement here might be.  What is it
> >> you were thinking specifically?
> >>
> >> On Thu, Jul 16, 2015 at 5:36 PM Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>>
> >>> I finally got to re-enable MariaDB and PostgreSQL based tests for
> >>> Hibernate Search - which has been running on H2 only for some months -
> >>> and had to debug a case of a single test hanging for a long time.
> >>>
> >>> Essentially it would block - for hours - on the SessionFactory#close()
> >>> method, attempting to drop the database schema with the following
> >>> statement:
> >>>   > alter table AncientBook_alternativeTitles drop constraint
> >>> FKn8hhkmhof1mdgc4oi77ccq989
> >>>
> >>> Dumping threads I would get a very similar stack trace on both
> >>> databases; initially I thought someone had copy/pasted a socket
> >>> handling bug from one JDBC driver to the other ;-)
> >>>
> >>> The PostgreSQL testsuite hanging:
> >>>
> >>> "main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable
> >>> [0x00007f0f48956000]
> >>>    java.lang.Thread.State: RUNNABLE
> >>> at java.net.SocketInputStream.socketRead0(Native Method)
> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> >>> at
> >>>
> org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
> >>> at
> >>>
> org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
> >>> at
> >>>
> org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
> >>> at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
> >>> at
> >>>
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
> >>> at
> >>>
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
> >>> - locked <0x00000007c11e3860> (a
> >>> org.postgresql.core.v3.QueryExecutorImpl)
> >>> at
> >>>
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
> >>> at
> >>>
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
> >>> at
> >>>
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
> >>> at
> >>>
> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
> >>> at
> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
> >>> at
> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
> >>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
> >>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
> >>> at
> >>>
> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
> >>> at
> >>>
> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
> >>> at
> >>>
> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> >>> at
> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> >>> at
> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> >>> at
> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> >>> at
> >>>
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> >>> at
> >>>
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> >>> at
> >>>
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> >>>
> >>> The MariaDB testsuite hanging:
> >>>
> >>> "main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable
> >>> [0x00007f8ca5f5c000]
> >>>    java.lang.Thread.State: RUNNABLE
> >>> at java.net.SocketInputStream.socketRead0(Native Method)
> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> >>> at
> >>>
> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
> >>> at
> >>>
> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
> >>> at
> >>>
> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
> >>> - locked <0x00000007c0baa518> (a
> >>> com.mysql.jdbc.util.ReadAheadInputStream)
> >>> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
> >>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
> >>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
> >>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
> >>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
> >>> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
> >>> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
> >>> at
> >>>
> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
> >>> at
> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
> >>> at
> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
> >>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
> >>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
> >>> at
> >>>
> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
> >>> at
> >>>
> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
> >>> at
> >>>
> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> >>> at
> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> >>> at
> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> >>> at
> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> >>> at
> >>>
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> >>> at
> >>>
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> >>> at
> >>>
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> >>>
> >>> On Gail's suggestion I went looking for database level locks; I hadn't
> >>> thought of that as I assumed it would have timed out more aggressively
> >>> rather than have me wait for hours.
> >>> It turns out she was right and the reason for blocking was a simple
> >>> "count *" query being run as a post-test assertion, which we had
> >>> forgotten to wrap in an "open transaction & commit" statements pair.
> >>> The test assertion would be successful, but apparently it would hold
> >>> on the table lock beyond closing the Session and, then fail to drop
> >>> the database at the teardown of the test.
> >>>
> >>> I'm wondering if this is expected, or if there's something in the new
> >>> transaction handling code which could be improved? It took me several
> >>> hours to figure this out; maybe I'm just not using ORM as frequently
> >>> as once :)
> >>> If it's this critical to have the transaction, maybe it should be
> >>> mandatory?
> >>>
> >>> And as a memo for next time, this is the query to figure out details
> >>> about locks on our testing db:
> >>>  > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid
> >>> = psa.pid where datname = 'testingdb';
> >>>
> >>> Thanks,
> >>> Sanne
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From koen.aers at gmail.com  Fri Jul 17 11:36:08 2015
From: koen.aers at gmail.com (Koen Aers)
Date: Fri, 17 Jul 2015 17:36:08 +0200
Subject: [hibernate-dev] Hibernate Search fails to generate anything
In-Reply-To: <CAFm4XO1JxR+GL5xUAda+wj4M-thiO-t-ww4Xz+Mp6mVBgKf8MQ@mail.gmail.com>
References: <CAM4O4P5uAbdeCMHY_HP+TRd3k+Er+nZuJPiSsr8gUMLvY2DYjw@mail.gmail.com>
	<CAFm4XO1JxR+GL5xUAda+wj4M-thiO-t-ww4Xz+Mp6mVBgKf8MQ@mail.gmail.com>
Message-ID: <5DAD3D7E-111D-4702-A7C8-105DFD493EEF@gmail.com>

Hey Sanne and Dmitry,

I am trying to wrap my head around this problem and I found that Hibernate ORM can see the Hibernate Search services. ?SearchFactoryReference? is instantiated while building the services. However, its ?initialize? method is never called. AFAICS this is the responsibility of ?HibernateSearchSessionFactoryObserver?. I will look further into it but feel free to give pointers if you know any.

Cheers,
Koen



> Op 15-jul.-2015, om 13:35 heeft Sanne Grinovero <sanne at hibernate.org> het volgende geschreven:
> 
> Hi Koen,
> this is a classloader issue for which we'll need your help. It's a
> very simple issue: Hibernate ORM needs to see the services exposed
> from Hibernate Search when the SessionFactory is started, so that it
> triggers the correct integrations.
> 
> My guess is that some metadata needs to be changed in the Hibernate
> ORM plugin to allow loading from the Search module. Is that something
> you could help Dmitry with?
> 
> thanks,
> Sanne
> 
> 
> On 6 July 2015 at 14:29, Dmitry Bocharov <bdshadow at gmail.com <mailto:bdshadow at gmail.com>> wrote:
>> Hello, everyone!
>> I'd like to discuss with you the problem. I'm writing a hibernate-search
>> eclipse plugin and currently I have a problem with generating indexes.
>> I try to generate indexes in HSearchServiceProxy class
>> <https://github.com/Sanne/org.jboss.tools.hibernate.search/blob/master/hsearchplugins/org.jboss.tools.hibernate.search.runtime.v_4_5/src/org/jboss/tools/hibernate/search/HSearchServiceProxy.java <https://github.com/Sanne/org.jboss.tools.hibernate.search/blob/master/hsearchplugins/org.jboss.tools.hibernate.search.runtime.v_4_5/src/org/jboss/tools/hibernate/search/HSearchServiceProxy.java>>.
>> The code runs till the end fine. I was able to debug it. However, nothing
>> is created.
>> 
>> I have a user project. In hibernate.cfg.xml there is:
>> 
>> *  <property
>> name="hibernate.search.default.directory_provider">filesystem</property>*
>> *  <property
>> name="hibernate.search.default.indexBase">D:\Spring\HibernateWS\gen_indexes</property>*
>> 
>> Also there is
>> *        <dependency>*
>> *  <groupId>org.hibernate</groupId>*
>> *  <artifactId>hibernate-search-orm</artifactId>*
>> *  <version>5.0.1.Final</version>*
>> *  </dependency>*
>> in the *pom.xml* in order to annotate entities to index them:
>> 
>> *@Entity*
>> *@Indexed*
>> *public class Person implements java.io.Serializable {*
>> * @Id*
>> * @GeneratedValue*
>> * private int id;*
>> * @Field(analyze=Analyze.YES, store=Store.NO)*
>> * private String login;*
>> 
>> When i try to create indexes as a user - it works fine. However, when I try
>> to do it from my plugin nothing happens. I debugged and found that the call
>> stack is the following: MassIndexerImpl.startAndWait() ->
>> FullTextSessionImpl.getSearchIntegrator() ->
>> ContextHelper.getSearchintegratorBySFI(SessionFactoryImplementor sfi) ->
>> SearchFactoryReference.getSearchIntegrator(). And here
>> <https://github.com/hibernate/hibernate-search/blob/c06e4fe5fbc6b5a09195f40d760a093691f2c7f2/orm/src/main/java/org/hibernate/search/hcore/impl/SearchFactoryReference.java <https://github.com/hibernate/hibernate-search/blob/c06e4fe5fbc6b5a09195f40d760a093691f2c7f2/orm/src/main/java/org/hibernate/search/hcore/impl/SearchFactoryReference.java>>
>> it
>> creates and exception in getSearchIntegrator() because
>> this.extendedIntegrator returns null.
>> 
>> As I understand plugin classloader is different from user classloader. So
>> that can be a problem. In my plugin I have hibernate-core 4.3.1 (from
>> jbosstolls-hibernate) and hibernate-search (5.0.1 as a fragment of this
>> jbosstolls-hibernate plugin) in the classpath. I found that versions are
>> compatible, so it's not a problem.
>> 
>> So the only problem, as I think, are different classloaders.
>> 
>> Koen Aers and Sanne Grinovero are in touch with the problem. So If anyone
>> else has any thoughts, it would be great to see =)
>> 
>> Thanks in advance!
>> Dmitry
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>

From sanne at hibernate.org  Fri Jul 17 12:00:34 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 17 Jul 2015 17:00:34 +0100
Subject: [hibernate-dev] Hibernate Search fails to generate anything
In-Reply-To: <5DAD3D7E-111D-4702-A7C8-105DFD493EEF@gmail.com>
References: <CAM4O4P5uAbdeCMHY_HP+TRd3k+Er+nZuJPiSsr8gUMLvY2DYjw@mail.gmail.com>
	<CAFm4XO1JxR+GL5xUAda+wj4M-thiO-t-ww4Xz+Mp6mVBgKf8MQ@mail.gmail.com>
	<5DAD3D7E-111D-4702-A7C8-105DFD493EEF@gmail.com>
Message-ID: <CAFm4XO2b9Thv4G12_vHqWaapPDjVWDw1sZO_6pGQLaMwG1LGLg@mail.gmail.com>

Hi Koen,
is it possible that it's initializing with the wrong version of Hibernate ORM ?

Dimitry below mentioned versions hibernate-core 4.3.1 and
hibernate-search 5.0.1; these are getting a bit old now but they work
fine together. Is it possible the jboss-tools plugin could use a
different hibernate-core version at runtime? Not all combinations are
valid.

Thanks,
Sanne

On 17 July 2015 at 16:36, Koen Aers <koen.aers at gmail.com> wrote:
> Hey Sanne and Dmitry,
>
> I am trying to wrap my head around this problem and I found that Hibernate
> ORM can see the Hibernate Search services. ?SearchFactoryReference? is
> instantiated while building the services. However, its ?initialize? method
> is never called. AFAICS this is the responsibility of
> ?HibernateSearchSessionFactoryObserver?. I will look further into it but
> feel free to give pointers if you know any.
>
> Cheers,
> Koen
>
>
>
> Op 15-jul.-2015, om 13:35 heeft Sanne Grinovero <sanne at hibernate.org> het
> volgende geschreven:
>
> Hi Koen,
> this is a classloader issue for which we'll need your help. It's a
> very simple issue: Hibernate ORM needs to see the services exposed
> from Hibernate Search when the SessionFactory is started, so that it
> triggers the correct integrations.
>
> My guess is that some metadata needs to be changed in the Hibernate
> ORM plugin to allow loading from the Search module. Is that something
> you could help Dmitry with?
>
> thanks,
> Sanne
>
>
> On 6 July 2015 at 14:29, Dmitry Bocharov <bdshadow at gmail.com> wrote:
>
> Hello, everyone!
> I'd like to discuss with you the problem. I'm writing a hibernate-search
> eclipse plugin and currently I have a problem with generating indexes.
> I try to generate indexes in HSearchServiceProxy class
> <https://github.com/Sanne/org.jboss.tools.hibernate.search/blob/master/hsearchplugins/org.jboss.tools.hibernate.search.runtime.v_4_5/src/org/jboss/tools/hibernate/search/HSearchServiceProxy.java>.
>
> The code runs till the end fine. I was able to debug it. However, nothing
> is created.
>
> I have a user project. In hibernate.cfg.xml there is:
>
> *  <property
> name="hibernate.search.default.directory_provider">filesystem</property>*
> *  <property
> name="hibernate.search.default.indexBase">D:\Spring\HibernateWS\gen_indexes</property>*
>
> Also there is
> *        <dependency>*
> *  <groupId>org.hibernate</groupId>*
> *  <artifactId>hibernate-search-orm</artifactId>*
> *  <version>5.0.1.Final</version>*
> *  </dependency>*
> in the *pom.xml* in order to annotate entities to index them:
>
> *@Entity*
> *@Indexed*
> *public class Person implements java.io.Serializable {*
> * @Id*
> * @GeneratedValue*
> * private int id;*
> * @Field(analyze=Analyze.YES, store=Store.NO)*
> * private String login;*
>
> When i try to create indexes as a user - it works fine. However, when I try
> to do it from my plugin nothing happens. I debugged and found that the call
> stack is the following: MassIndexerImpl.startAndWait() ->
> FullTextSessionImpl.getSearchIntegrator() ->
> ContextHelper.getSearchintegratorBySFI(SessionFactoryImplementor sfi) ->
> SearchFactoryReference.getSearchIntegrator(). And here
> <https://github.com/hibernate/hibernate-search/blob/c06e4fe5fbc6b5a09195f40d760a093691f2c7f2/orm/src/main/java/org/hibernate/search/hcore/impl/SearchFactoryReference.java>
> it
> creates and exception in getSearchIntegrator() because
> this.extendedIntegrator returns null.
>
> As I understand plugin classloader is different from user classloader. So
> that can be a problem. In my plugin I have hibernate-core 4.3.1 (from
> jbosstolls-hibernate) and hibernate-search (5.0.1 as a fragment of this
> jbosstolls-hibernate plugin) in the classpath. I found that versions are
> compatible, so it's not a problem.
>
> So the only problem, as I think, are different classloaders.
>
> Koen Aers and Sanne Grinovero are in touch with the problem. So If anyone
> else has any thoughts, it would be great to see =)
>
> Thanks in advance!
> Dmitry
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>


From sanne at hibernate.org  Fri Jul 17 12:11:36 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 17 Jul 2015 17:11:36 +0100
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFdSV9vBu+xr=JJ+pbyjx+hfy4nyiE6p5sv6tEmmNZN7qa0w2A@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
	<CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>
	<CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>
	<CAFm4XO0Wb=cx0Od884aYR7cM_uFSSCMUFdXpLyeASnDriy=_Lw@mail.gmail.com>
	<CAFdSV9vBu+xr=JJ+pbyjx+hfy4nyiE6p5sv6tEmmNZN7qa0w2A@mail.gmail.com>
Message-ID: <CAFm4XO0Zw=cXMk30XBERmKLpx3GzrReVrpVH4-BkQBnQ3SmDxg@mail.gmail.com>

On 17 July 2015 at 16:25, Steve Ebersole <steve at hibernate.org> wrote:
> It would seem that this is a regression with ORM, I agree.  However, we do
> not know how recent of a regression.  And that is the problem.  We have no
> idea how far back to look.  Because the ORM CI jobs against MySQL,
> PostrgreSQL, Oracle, etc have not been running for many months.  IIRC even
> when they were running on the old CI servers we had problems with those jobs
> that were not looked at for some time.

Sure, same problem here: not run these tests for months, and you're
right I could do a quick check on a slightly older branch which is
using ORM 4.3 and I have the same problem.

> As far as what you see, I am not convinced it is what you think it is in
> terms of auto-commit for queries run outside of a transaction.  This part
> has not changed in 5.0.  Assuming you are using the "built in Connection
> pool", there is a setting that controls the auto-commit mode of the
> connections we create (hibernate.connection.autocommit).  That setting has
> always been there, and it has always defaulted to false.  This has not
> changed.  In fact the same exact code is used in 4.3 and 5.0 for creating
> these Connections:
> org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.  The
> autoCommit value in there comes from the setting I just mentioned.  The
> logical outcome is the same even before 4.3, just that it was done
> differently.  So bottom line, if you are not seeing auto-commit on these
> Connections now, you never were.  Now it is possible that their are some
> ancillary changes that cause the lack of auto-commit to now be an issue
> where it was not before.  So first, I'd need to know whether the Connection
> here is auto-commit or is not.  From there we can start drilling down on
> what might be a cause.  But keep in mind too, that with hangs and deadlocks
> the process that hangs is often not the culprit; often it is the previous
> process that is holding locks that is the culprit.

I understand, but in this specific case I can reproduce the issue by
running a single test.
Also that psql SQL I shared clearly shows which statement is causing it to hang,
and I could fix the test by just wrapping that statement in a transaction.

>
> My case is actually different, at least on the surface.  Mine happens on
> dropping tables after the test is complete (for MySQL anyway).  Which got me
> to looking at schema export and friends and how they handle connections.
> They handle connections quite differently.  Again the same as they used to,
> but I mean very different from how sessions manage connections.  In schema
> export the connections are always set to auto-commit mode at the start of
> processing.  Then they never do anything with auto-commit afterwards.  I am
> not sure this is right.

Actually it sounds like you're having the same problem. I debugged the
PosgreSQL tests first, but I had the same on MySQL (as in the
stacktrace I shared),
and the test also hangs on schema drop.
The problem is that the schema can't be dropped because a previous
statement - from a session which is now correctly closed - is still
holding locks.

Thanks,
Sanne

>
>
>
>
> On Fri, Jul 17, 2015 at 3:51 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Thanks Steve, I wasn't sure if I had found a problem.
>> Still, it looks like the Hibernate Search tests are not benefiting
>> from auto-commit, or I wouldn't have this problem right? Our testing
>> configuration properties have been the same for years and I'm just
>> re-enabling tests which haven't been run for a while, so I suspect
>> something changed in ORM.
>>
>> I think I'd expect Hibernate ORM to automatically enable auto-commit
>> on operations not running within a transaction, to make sure all locks
>> are released when the Session is closed.
>>
>> Thanks,
>> Sanne
>>
>> On 17 July 2015 at 00:14, Steve Ebersole <steve at hibernate.org> wrote:
>> > For what it is worth, I am running into the same problems on MySQL for
>> > the
>> > ORM tests in terms of blocks on dropping tables.  PGSQL at least
>> > finishes,
>> > although I run into 55 errors which I still need to triage.
>> >
>> > On Thu, Jul 16, 2015 at 5:59 PM Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >>
>> >> There is really nothing to improve.  What would you suggest as an
>> >> improvement?  I mean from a ORM perspective, we have an ato-commit
>> >> Connection (presumably) and run a query.  How on earth would we know to
>> >> expect that the database is holding locks for that?
>> >>
>> >> As far as "requiring transactions" I have tried to fly that plane
>> >> multiple
>> >> times in the past.  I think it is absolutely ridiculous to allow these
>> >> auto-commit use cases.  In fact I personally wanted to take it to the
>> >> more
>> >> extreme case of always using JTA and simply mimicking "single resource
>> >> JTA
>> >> transactions" internally in the "JDBC transaction" case.  Gavin and I
>> >> both
>> >> did in fact.  But we got a lot of push back.
>> >>
>> >> So I am not sure exactly what the improvement here might be.  What is
>> >> it
>> >> you were thinking specifically?
>> >>
>> >> On Thu, Jul 16, 2015 at 5:36 PM Sanne Grinovero <sanne at hibernate.org>
>>
>> >> wrote:
>> >>>
>> >>> I finally got to re-enable MariaDB and PostgreSQL based tests for
>> >>> Hibernate Search - which has been running on H2 only for some months -
>> >>> and had to debug a case of a single test hanging for a long time.
>> >>>
>> >>> Essentially it would block - for hours - on the SessionFactory#close()
>> >>> method, attempting to drop the database schema with the following
>> >>> statement:
>> >>>   > alter table AncientBook_alternativeTitles drop constraint
>> >>> FKn8hhkmhof1mdgc4oi77ccq989
>> >>>
>> >>> Dumping threads I would get a very similar stack trace on both
>> >>> databases; initially I thought someone had copy/pasted a socket
>> >>> handling bug from one JDBC driver to the other ;-)
>> >>>
>> >>> The PostgreSQL testsuite hanging:
>> >>>
>> >>> "main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable
>> >>> [0x00007f0f48956000]
>> >>>    java.lang.Thread.State: RUNNABLE
>> >>> at java.net.SocketInputStream.socketRead0(Native Method)
>> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> >>> at
>> >>>
>> >>> org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
>> >>> at
>> >>>
>> >>> org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
>> >>> at
>> >>>
>> >>> org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
>> >>> at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
>> >>> at
>> >>>
>> >>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
>> >>> at
>> >>>
>> >>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
>> >>> - locked <0x00000007c11e3860> (a
>> >>> org.postgresql.core.v3.QueryExecutorImpl)
>> >>> at
>> >>>
>> >>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
>> >>> at
>> >>>
>> >>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
>> >>> at
>> >>>
>> >>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
>> >>> at
>> >>>
>> >>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>> >>> at
>> >>> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>> >>> at
>> >>> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>> >>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>> >>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>> >>> at
>> >>>
>> >>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>> >>> at
>> >>>
>> >>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>> >>> at
>> >>>
>> >>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>> >>>
>> >>> The MariaDB testsuite hanging:
>> >>>
>> >>> "main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable
>> >>> [0x00007f8ca5f5c000]
>> >>>    java.lang.Thread.State: RUNNABLE
>> >>> at java.net.SocketInputStream.socketRead0(Native Method)
>> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> >>> at
>> >>>
>> >>> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
>> >>> at
>> >>>
>> >>> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
>> >>> at
>> >>>
>> >>> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
>> >>> - locked <0x00000007c0baa518> (a
>> >>> com.mysql.jdbc.util.ReadAheadInputStream)
>> >>> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
>> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
>> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
>> >>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
>> >>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
>> >>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
>> >>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
>> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
>> >>> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
>> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
>> >>> at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
>> >>> at
>> >>>
>> >>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>> >>> at
>> >>> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>> >>> at
>> >>> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>> >>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>> >>> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>> >>> at
>> >>>
>> >>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>> >>> at
>> >>>
>> >>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>> >>> at
>> >>>
>> >>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>> >>> at
>> >>>
>> >>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>> >>>
>> >>> On Gail's suggestion I went looking for database level locks; I hadn't
>> >>> thought of that as I assumed it would have timed out more aggressively
>> >>> rather than have me wait for hours.
>> >>> It turns out she was right and the reason for blocking was a simple
>> >>> "count *" query being run as a post-test assertion, which we had
>> >>> forgotten to wrap in an "open transaction & commit" statements pair.
>> >>> The test assertion would be successful, but apparently it would hold
>> >>> on the table lock beyond closing the Session and, then fail to drop
>> >>> the database at the teardown of the test.
>> >>>
>> >>> I'm wondering if this is expected, or if there's something in the new
>> >>> transaction handling code which could be improved? It took me several
>> >>> hours to figure this out; maybe I'm just not using ORM as frequently
>> >>> as once :)
>> >>> If it's this critical to have the transaction, maybe it should be
>> >>> mandatory?
>> >>>
>> >>> And as a memo for next time, this is the query to figure out details
>> >>> about locks on our testing db:
>> >>>  > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid
>> >>> = psa.pid where datname = 'testingdb';
>> >>>
>> >>> 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  Fri Jul 17 12:14:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Jul 2015 16:14:55 +0000
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFm4XO0Zw=cXMk30XBERmKLpx3GzrReVrpVH4-BkQBnQ3SmDxg@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
	<CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>
	<CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>
	<CAFm4XO0Wb=cx0Od884aYR7cM_uFSSCMUFdXpLyeASnDriy=_Lw@mail.gmail.com>
	<CAFdSV9vBu+xr=JJ+pbyjx+hfy4nyiE6p5sv6tEmmNZN7qa0w2A@mail.gmail.com>
	<CAFm4XO0Zw=cXMk30XBERmKLpx3GzrReVrpVH4-BkQBnQ3SmDxg@mail.gmail.com>
Message-ID: <CAFdSV9sBrFeRncS-uokLW+_7eNmymRMNpJs-jLVh4vKkevhWDg@mail.gmail.com>

Process != test.  Process here == connection.  You have multiple.

On Fri, Jul 17, 2015, 11:12 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 17 July 2015 at 16:25, Steve Ebersole <steve at hibernate.org> wrote:
> > It would seem that this is a regression with ORM, I agree.  However, we
> do
> > not know how recent of a regression.  And that is the problem.  We have
> no
> > idea how far back to look.  Because the ORM CI jobs against MySQL,
> > PostrgreSQL, Oracle, etc have not been running for many months.  IIRC
> even
> > when they were running on the old CI servers we had problems with those
> jobs
> > that were not looked at for some time.
>
> Sure, same problem here: not run these tests for months, and you're
> right I could do a quick check on a slightly older branch which is
> using ORM 4.3 and I have the same problem.
>
> > As far as what you see, I am not convinced it is what you think it is in
> > terms of auto-commit for queries run outside of a transaction.  This part
> > has not changed in 5.0.  Assuming you are using the "built in Connection
> > pool", there is a setting that controls the auto-commit mode of the
> > connections we create (hibernate.connection.autocommit).  That setting
> has
> > always been there, and it has always defaulted to false.  This has not
> > changed.  In fact the same exact code is used in 4.3 and 5.0 for creating
> > these Connections:
> > org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.
> The
> > autoCommit value in there comes from the setting I just mentioned.  The
> > logical outcome is the same even before 4.3, just that it was done
> > differently.  So bottom line, if you are not seeing auto-commit on these
> > Connections now, you never were.  Now it is possible that their are some
> > ancillary changes that cause the lack of auto-commit to now be an issue
> > where it was not before.  So first, I'd need to know whether the
> Connection
> > here is auto-commit or is not.  From there we can start drilling down on
> > what might be a cause.  But keep in mind too, that with hangs and
> deadlocks
> > the process that hangs is often not the culprit; often it is the previous
> > process that is holding locks that is the culprit.
>
> I understand, but in this specific case I can reproduce the issue by
> running a single test.
> Also that psql SQL I shared clearly shows which statement is causing it to
> hang,
> and I could fix the test by just wrapping that statement in a transaction.
>
> >
> > My case is actually different, at least on the surface.  Mine happens on
> > dropping tables after the test is complete (for MySQL anyway).  Which
> got me
> > to looking at schema export and friends and how they handle connections.
> > They handle connections quite differently.  Again the same as they used
> to,
> > but I mean very different from how sessions manage connections.  In
> schema
> > export the connections are always set to auto-commit mode at the start of
> > processing.  Then they never do anything with auto-commit afterwards.  I
> am
> > not sure this is right.
>
> Actually it sounds like you're having the same problem. I debugged the
> PosgreSQL tests first, but I had the same on MySQL (as in the
> stacktrace I shared),
> and the test also hangs on schema drop.
> The problem is that the schema can't be dropped because a previous
> statement - from a session which is now correctly closed - is still
> holding locks.
>
> Thanks,
> Sanne
>
> >
> >
> >
> >
> > On Fri, Jul 17, 2015 at 3:51 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Thanks Steve, I wasn't sure if I had found a problem.
> >> Still, it looks like the Hibernate Search tests are not benefiting
> >> from auto-commit, or I wouldn't have this problem right? Our testing
> >> configuration properties have been the same for years and I'm just
> >> re-enabling tests which haven't been run for a while, so I suspect
> >> something changed in ORM.
> >>
> >> I think I'd expect Hibernate ORM to automatically enable auto-commit
> >> on operations not running within a transaction, to make sure all locks
> >> are released when the Session is closed.
> >>
> >> Thanks,
> >> Sanne
> >>
> >> On 17 July 2015 at 00:14, Steve Ebersole <steve at hibernate.org> wrote:
> >> > For what it is worth, I am running into the same problems on MySQL for
> >> > the
> >> > ORM tests in terms of blocks on dropping tables.  PGSQL at least
> >> > finishes,
> >> > although I run into 55 errors which I still need to triage.
> >> >
> >> > On Thu, Jul 16, 2015 at 5:59 PM Steve Ebersole <steve at hibernate.org>
> >> > wrote:
> >> >>
> >> >> There is really nothing to improve.  What would you suggest as an
> >> >> improvement?  I mean from a ORM perspective, we have an ato-commit
> >> >> Connection (presumably) and run a query.  How on earth would we know
> to
> >> >> expect that the database is holding locks for that?
> >> >>
> >> >> As far as "requiring transactions" I have tried to fly that plane
> >> >> multiple
> >> >> times in the past.  I think it is absolutely ridiculous to allow
> these
> >> >> auto-commit use cases.  In fact I personally wanted to take it to the
> >> >> more
> >> >> extreme case of always using JTA and simply mimicking "single
> resource
> >> >> JTA
> >> >> transactions" internally in the "JDBC transaction" case.  Gavin and I
> >> >> both
> >> >> did in fact.  But we got a lot of push back.
> >> >>
> >> >> So I am not sure exactly what the improvement here might be.  What is
> >> >> it
> >> >> you were thinking specifically?
> >> >>
> >> >> On Thu, Jul 16, 2015 at 5:36 PM Sanne Grinovero <sanne at hibernate.org
> >
> >>
> >> >> wrote:
> >> >>>
> >> >>> I finally got to re-enable MariaDB and PostgreSQL based tests for
> >> >>> Hibernate Search - which has been running on H2 only for some
> months -
> >> >>> and had to debug a case of a single test hanging for a long time.
> >> >>>
> >> >>> Essentially it would block - for hours - on the
> SessionFactory#close()
> >> >>> method, attempting to drop the database schema with the following
> >> >>> statement:
> >> >>>   > alter table AncientBook_alternativeTitles drop constraint
> >> >>> FKn8hhkmhof1mdgc4oi77ccq989
> >> >>>
> >> >>> Dumping threads I would get a very similar stack trace on both
> >> >>> databases; initially I thought someone had copy/pasted a socket
> >> >>> handling bug from one JDBC driver to the other ;-)
> >> >>>
> >> >>> The PostgreSQL testsuite hanging:
> >> >>>
> >> >>> "main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable
> >> >>> [0x00007f0f48956000]
> >> >>>    java.lang.Thread.State: RUNNABLE
> >> >>> at java.net.SocketInputStream.socketRead0(Native Method)
> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> >> >>> at
> >> >>>
> >> >>>
> org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
> >> >>> at
> >> >>>
> >> >>>
> org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
> >> >>> at
> >> >>>
> >> >>>
> org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
> >> >>> at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
> >> >>> at
> >> >>>
> >> >>>
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
> >> >>> at
> >> >>>
> >> >>>
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
> >> >>> - locked <0x00000007c11e3860> (a
> >> >>> org.postgresql.core.v3.QueryExecutorImpl)
> >> >>> at
> >> >>>
> >> >>>
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
> >> >>> at
> >> >>>
> >> >>>
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
> >> >>> at
> >> >>>
> >> >>>
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
> >> >>> at
> >> >>>
> >> >>>
> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
> >> >>> at
> >> >>>
> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
> >> >>> at
> >> >>>
> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
> >> >>> at
> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
> >> >>> at
> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
> >> >>> at
> >> >>>
> >> >>>
> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
> >> >>> at
> >> >>>
> >> >>>
> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
> >> >>> at
> >> >>>
> >> >>>
> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
> >> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> >> >>>
> >> >>> The MariaDB testsuite hanging:
> >> >>>
> >> >>> "main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable
> >> >>> [0x00007f8ca5f5c000]
> >> >>>    java.lang.Thread.State: RUNNABLE
> >> >>> at java.net.SocketInputStream.socketRead0(Native Method)
> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
> >> >>> at
> >> >>>
> >> >>>
> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
> >> >>> at
> >> >>>
> >> >>>
> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
> >> >>> at
> >> >>>
> >> >>>
> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
> >> >>> - locked <0x00000007c0baa518> (a
> >> >>> com.mysql.jdbc.util.ReadAheadInputStream)
> >> >>> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
> >> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
> >> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
> >> >>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
> >> >>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
> >> >>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
> >> >>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
> >> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
> >> >>> at
> com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
> >> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
> >> >>> at
> com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
> >> >>> at
> >> >>>
> >> >>>
> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
> >> >>> at
> >> >>>
> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
> >> >>> at
> >> >>>
> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
> >> >>> at
> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
> >> >>> at
> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
> >> >>> at
> >> >>>
> >> >>>
> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
> >> >>> at
> >> >>>
> >> >>>
> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
> >> >>> at
> >> >>>
> >> >>>
> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
> >> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> >> >>> at
> >> >>>
> >> >>>
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> >> >>>
> >> >>> On Gail's suggestion I went looking for database level locks; I
> hadn't
> >> >>> thought of that as I assumed it would have timed out more
> aggressively
> >> >>> rather than have me wait for hours.
> >> >>> It turns out she was right and the reason for blocking was a simple
> >> >>> "count *" query being run as a post-test assertion, which we had
> >> >>> forgotten to wrap in an "open transaction & commit" statements pair.
> >> >>> The test assertion would be successful, but apparently it would hold
> >> >>> on the table lock beyond closing the Session and, then fail to drop
> >> >>> the database at the teardown of the test.
> >> >>>
> >> >>> I'm wondering if this is expected, or if there's something in the
> new
> >> >>> transaction handling code which could be improved? It took me
> several
> >> >>> hours to figure this out; maybe I'm just not using ORM as frequently
> >> >>> as once :)
> >> >>> If it's this critical to have the transaction, maybe it should be
> >> >>> mandatory?
> >> >>>
> >> >>> And as a memo for next time, this is the query to figure out details
> >> >>> about locks on our testing db:
> >> >>>  > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON
> pl.pid
> >> >>> = psa.pid where datname = 'testingdb';
> >> >>>
> >> >>> 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  Fri Jul 17 14:33:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Jul 2015 18:33:36 +0000
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFdSV9sBrFeRncS-uokLW+_7eNmymRMNpJs-jLVh4vKkevhWDg@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
	<CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>
	<CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>
	<CAFm4XO0Wb=cx0Od884aYR7cM_uFSSCMUFdXpLyeASnDriy=_Lw@mail.gmail.com>
	<CAFdSV9vBu+xr=JJ+pbyjx+hfy4nyiE6p5sv6tEmmNZN7qa0w2A@mail.gmail.com>
	<CAFm4XO0Zw=cXMk30XBERmKLpx3GzrReVrpVH4-BkQBnQ3SmDxg@mail.gmail.com>
	<CAFdSV9sBrFeRncS-uokLW+_7eNmymRMNpJs-jLVh4vKkevhWDg@mail.gmail.com>
Message-ID: <CAFdSV9vp0u6SB1t7K2GB-Du4=Z-SkO0Z4LmYcsOT-vJ-3J3a9w@mail.gmail.com>

Here is something else interesting...

So at the point that the test hang against MySQL for me, I have:

MariaDB [(none)]> SHOW FULL processlist;
+-----+--------------------+-----------------+--------------------+---------+------+---------------------------------+--------------------------------+----------+
| Id  | User               | Host            | db                 | Command
| Time | State                           | Info                           |
Progress |
+-----+--------------------+-----------------+--------------------+---------+------+---------------------------------+--------------------------------+----------+
| 138 | root               | localhost       | NULL               | Query
|    0 | init                            | SHOW FULL processlist          |
   0.000 |
| 139 | hibernate_orm_test | localhost:52853 | hibernate_orm_test | Sleep
|   12 |                                 | NULL                           |
   0.000 |
| 140 | hibernate_orm_test | localhost:52854 | hibernate_orm_test | Query
|   12 | Waiting for table metadata lock | drop table if exists TheEntity |
   0.000 |
+-----+--------------------+-----------------+--------------------+---------+------+---------------------------------+--------------------------------+----------+

So we see 2 JDBC connections with process ids 139 and 140.  You can see 139
blocked waiting to be able to drop a table; specifically waiting on a lock
of some sort.

However, `SHOW OPEN TABLES;` shows no tables in use and no tables locked.

Unfortunately that is the extent of my "MySQL debugging skills".


On Fri, Jul 17, 2015 at 11:14 AM Steve Ebersole <steve at hibernate.org> wrote:

> Process != test.  Process here == connection.  You have multiple.
>
> On Fri, Jul 17, 2015, 11:12 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 17 July 2015 at 16:25, Steve Ebersole <steve at hibernate.org> wrote:
>> > It would seem that this is a regression with ORM, I agree.  However, we
>> do
>> > not know how recent of a regression.  And that is the problem.  We have
>> no
>> > idea how far back to look.  Because the ORM CI jobs against MySQL,
>> > PostrgreSQL, Oracle, etc have not been running for many months.  IIRC
>> even
>> > when they were running on the old CI servers we had problems with those
>> jobs
>> > that were not looked at for some time.
>>
>> Sure, same problem here: not run these tests for months, and you're
>> right I could do a quick check on a slightly older branch which is
>> using ORM 4.3 and I have the same problem.
>>
>> > As far as what you see, I am not convinced it is what you think it is in
>> > terms of auto-commit for queries run outside of a transaction.  This
>> part
>> > has not changed in 5.0.  Assuming you are using the "built in Connection
>> > pool", there is a setting that controls the auto-commit mode of the
>> > connections we create (hibernate.connection.autocommit).  That setting
>> has
>> > always been there, and it has always defaulted to false.  This has not
>> > changed.  In fact the same exact code is used in 4.3 and 5.0 for
>> creating
>> > these Connections:
>> > org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.
>> The
>> > autoCommit value in there comes from the setting I just mentioned.  The
>> > logical outcome is the same even before 4.3, just that it was done
>> > differently.  So bottom line, if you are not seeing auto-commit on these
>> > Connections now, you never were.  Now it is possible that their are some
>> > ancillary changes that cause the lack of auto-commit to now be an issue
>> > where it was not before.  So first, I'd need to know whether the
>> Connection
>> > here is auto-commit or is not.  From there we can start drilling down on
>> > what might be a cause.  But keep in mind too, that with hangs and
>> deadlocks
>> > the process that hangs is often not the culprit; often it is the
>> previous
>> > process that is holding locks that is the culprit.
>>
>> I understand, but in this specific case I can reproduce the issue by
>> running a single test.
>> Also that psql SQL I shared clearly shows which statement is causing it
>> to hang,
>> and I could fix the test by just wrapping that statement in a transaction.
>>
>> >
>> > My case is actually different, at least on the surface.  Mine happens on
>> > dropping tables after the test is complete (for MySQL anyway).  Which
>> got me
>> > to looking at schema export and friends and how they handle connections.
>> > They handle connections quite differently.  Again the same as they used
>> to,
>> > but I mean very different from how sessions manage connections.  In
>> schema
>> > export the connections are always set to auto-commit mode at the start
>> of
>> > processing.  Then they never do anything with auto-commit afterwards.
>> I am
>> > not sure this is right.
>>
>> Actually it sounds like you're having the same problem. I debugged the
>> PosgreSQL tests first, but I had the same on MySQL (as in the
>> stacktrace I shared),
>> and the test also hangs on schema drop.
>> The problem is that the schema can't be dropped because a previous
>> statement - from a session which is now correctly closed - is still
>> holding locks.
>>
>> Thanks,
>> Sanne
>>
>> >
>> >
>> >
>> >
>> > On Fri, Jul 17, 2015 at 3:51 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> >>
>> >> Thanks Steve, I wasn't sure if I had found a problem.
>> >> Still, it looks like the Hibernate Search tests are not benefiting
>> >> from auto-commit, or I wouldn't have this problem right? Our testing
>> >> configuration properties have been the same for years and I'm just
>> >> re-enabling tests which haven't been run for a while, so I suspect
>> >> something changed in ORM.
>> >>
>> >> I think I'd expect Hibernate ORM to automatically enable auto-commit
>> >> on operations not running within a transaction, to make sure all locks
>> >> are released when the Session is closed.
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> On 17 July 2015 at 00:14, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > For what it is worth, I am running into the same problems on MySQL
>> for
>> >> > the
>> >> > ORM tests in terms of blocks on dropping tables.  PGSQL at least
>> >> > finishes,
>> >> > although I run into 55 errors which I still need to triage.
>> >> >
>> >> > On Thu, Jul 16, 2015 at 5:59 PM Steve Ebersole <steve at hibernate.org>
>> >> > wrote:
>> >> >>
>> >> >> There is really nothing to improve.  What would you suggest as an
>> >> >> improvement?  I mean from a ORM perspective, we have an ato-commit
>> >> >> Connection (presumably) and run a query.  How on earth would we
>> know to
>> >> >> expect that the database is holding locks for that?
>> >> >>
>> >> >> As far as "requiring transactions" I have tried to fly that plane
>> >> >> multiple
>> >> >> times in the past.  I think it is absolutely ridiculous to allow
>> these
>> >> >> auto-commit use cases.  In fact I personally wanted to take it to
>> the
>> >> >> more
>> >> >> extreme case of always using JTA and simply mimicking "single
>> resource
>> >> >> JTA
>> >> >> transactions" internally in the "JDBC transaction" case.  Gavin and
>> I
>> >> >> both
>> >> >> did in fact.  But we got a lot of push back.
>> >> >>
>> >> >> So I am not sure exactly what the improvement here might be.  What
>> is
>> >> >> it
>> >> >> you were thinking specifically?
>> >> >>
>> >> >> On Thu, Jul 16, 2015 at 5:36 PM Sanne Grinovero <
>> sanne at hibernate.org>
>> >>
>> >> >> wrote:
>> >> >>>
>> >> >>> I finally got to re-enable MariaDB and PostgreSQL based tests for
>> >> >>> Hibernate Search - which has been running on H2 only for some
>> months -
>> >> >>> and had to debug a case of a single test hanging for a long time.
>> >> >>>
>> >> >>> Essentially it would block - for hours - on the
>> SessionFactory#close()
>> >> >>> method, attempting to drop the database schema with the following
>> >> >>> statement:
>> >> >>>   > alter table AncientBook_alternativeTitles drop constraint
>> >> >>> FKn8hhkmhof1mdgc4oi77ccq989
>> >> >>>
>> >> >>> Dumping threads I would get a very similar stack trace on both
>> >> >>> databases; initially I thought someone had copy/pasted a socket
>> >> >>> handling bug from one JDBC driver to the other ;-)
>> >> >>>
>> >> >>> The PostgreSQL testsuite hanging:
>> >> >>>
>> >> >>> "main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable
>> >> >>> [0x00007f0f48956000]
>> >> >>>    java.lang.Thread.State: RUNNABLE
>> >> >>> at java.net.SocketInputStream.socketRead0(Native Method)
>> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
>> >> >>> at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
>> >> >>> - locked <0x00000007c11e3860> (a
>> >> >>> org.postgresql.core.v3.QueryExecutorImpl)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>> >> >>> at
>> >> >>>
>> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>> >> >>> at
>> >> >>>
>> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>> >> >>> at
>> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>> >> >>> at
>> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>> >> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>> >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>> >> >>>
>> >> >>> The MariaDB testsuite hanging:
>> >> >>>
>> >> >>> "main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable
>> >> >>> [0x00007f8ca5f5c000]
>> >> >>>    java.lang.Thread.State: RUNNABLE
>> >> >>> at java.net.SocketInputStream.socketRead0(Native Method)
>> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>> >> >>> at
>> >> >>>
>> >> >>>
>> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
>> >> >>> at
>> >> >>>
>> >> >>>
>> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
>> >> >>> at
>> >> >>>
>> >> >>>
>> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
>> >> >>> - locked <0x00000007c0baa518> (a
>> >> >>> com.mysql.jdbc.util.ReadAheadInputStream)
>> >> >>> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
>> >> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
>> >> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
>> >> >>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
>> >> >>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
>> >> >>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
>> >> >>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
>> >> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
>> >> >>> at
>> com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
>> >> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
>> >> >>> at
>> com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>> >> >>> at
>> >> >>>
>> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>> >> >>> at
>> >> >>>
>> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>> >> >>> at
>> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>> >> >>> at
>> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>> >> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>> >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>> >> >>> at
>> >> >>>
>> >> >>>
>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>> >> >>>
>> >> >>> On Gail's suggestion I went looking for database level locks; I
>> hadn't
>> >> >>> thought of that as I assumed it would have timed out more
>> aggressively
>> >> >>> rather than have me wait for hours.
>> >> >>> It turns out she was right and the reason for blocking was a simple
>> >> >>> "count *" query being run as a post-test assertion, which we had
>> >> >>> forgotten to wrap in an "open transaction & commit" statements
>> pair.
>> >> >>> The test assertion would be successful, but apparently it would
>> hold
>> >> >>> on the table lock beyond closing the Session and, then fail to drop
>> >> >>> the database at the teardown of the test.
>> >> >>>
>> >> >>> I'm wondering if this is expected, or if there's something in the
>> new
>> >> >>> transaction handling code which could be improved? It took me
>> several
>> >> >>> hours to figure this out; maybe I'm just not using ORM as
>> frequently
>> >> >>> as once :)
>> >> >>> If it's this critical to have the transaction, maybe it should be
>> >> >>> mandatory?
>> >> >>>
>> >> >>> And as a memo for next time, this is the query to figure out
>> details
>> >> >>> about locks on our testing db:
>> >> >>>  > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON
>> pl.pid
>> >> >>> = psa.pid where datname = 'testingdb';
>> >> >>>
>> >> >>> 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  Fri Jul 17 16:31:38 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Jul 2015 20:31:38 +0000
Subject: [hibernate-dev] UUID as id
Message-ID: <CAFdSV9u414QX6CGEOFtTM1+EehZ2vf6Z6spunuB8S6LqDaG+wg@mail.gmail.com>

This goes to the feature we just added in 5.0 of supporting "non standard"
types as identifiers.  Specifically UUID.

Sanne and I have been discussing the MySQL (MariaDB) tests hanging
recently.  Well on the ORM side this was caused by an overly optimistic
tests not properly handling transactions and connections on an exception.

The underlying exception however comes from this support running against
MySQL.  The UUID is treated as BINARY.  The test inserts a row, and then
deletes it by id.  The row is inserted no problem.  However the delete by
id fails.  Apparently MySQL is not liking comparisons using = based on
binary data.

The work around is to explicitly add @Column( length = 16 ).  This is
planned to be addressed later via org.hibernate.type.Type#dictatedSizes

Just a heads up if ya'll run into this.  I added a note to the migration
guide as well.

From steve at hibernate.org  Fri Jul 17 18:04:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Jul 2015 22:04:01 +0000
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFdSV9vp0u6SB1t7K2GB-Du4=Z-SkO0Z4LmYcsOT-vJ-3J3a9w@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
	<CAFdSV9v-SMcXx0xLP0X2oRAnfETj2Cs3q5-=_A7W273x2k+knA@mail.gmail.com>
	<CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>
	<CAFm4XO0Wb=cx0Od884aYR7cM_uFSSCMUFdXpLyeASnDriy=_Lw@mail.gmail.com>
	<CAFdSV9vBu+xr=JJ+pbyjx+hfy4nyiE6p5sv6tEmmNZN7qa0w2A@mail.gmail.com>
	<CAFm4XO0Zw=cXMk30XBERmKLpx3GzrReVrpVH4-BkQBnQ3SmDxg@mail.gmail.com>
	<CAFdSV9sBrFeRncS-uokLW+_7eNmymRMNpJs-jLVh4vKkevhWDg@mail.gmail.com>
	<CAFdSV9vp0u6SB1t7K2GB-Du4=Z-SkO0Z4LmYcsOT-vJ-3J3a9w@mail.gmail.com>
Message-ID: <CAFdSV9sPyAei_isU3sZDaCJscxapMmSxgDcG_dKTjWJNRh0pMg@mail.gmail.com>

So this is definitely not limited to 5.0.  This happens in 4.3 as well.  I
pointed 4.3 locally to my MariaDB instance and it is hanging.  In every
case I have seen so far, this is problems in the test code though.


On Fri, Jul 17, 2015 at 1:33 PM Steve Ebersole <steve at hibernate.org> wrote:

> Here is something else interesting...
>
> So at the point that the test hang against MySQL for me, I have:
>
> MariaDB [(none)]> SHOW FULL processlist;
>
> +-----+--------------------+-----------------+--------------------+---------+------+---------------------------------+--------------------------------+----------+
> | Id  | User               | Host            | db                 |
> Command | Time | State                           | Info
>       | Progress |
>
> +-----+--------------------+-----------------+--------------------+---------+------+---------------------------------+--------------------------------+----------+
> | 138 | root               | localhost       | NULL               | Query
>   |    0 | init                            | SHOW FULL processlist
>  |    0.000 |
> | 139 | hibernate_orm_test | localhost:52853 | hibernate_orm_test | Sleep
>   |   12 |                                 | NULL
> |    0.000 |
> | 140 | hibernate_orm_test | localhost:52854 | hibernate_orm_test | Query
>   |   12 | Waiting for table metadata lock | drop table if exists TheEntity
> |    0.000 |
>
> +-----+--------------------+-----------------+--------------------+---------+------+---------------------------------+--------------------------------+----------+
>
> So we see 2 JDBC connections with process ids 139 and 140.  You can see
> 139 blocked waiting to be able to drop a table; specifically waiting on a
> lock of some sort.
>
> However, `SHOW OPEN TABLES;` shows no tables in use and no tables locked.
>
> Unfortunately that is the extent of my "MySQL debugging skills".
>
>
> On Fri, Jul 17, 2015 at 11:14 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Process != test.  Process here == connection.  You have multiple.
>>
>> On Fri, Jul 17, 2015, 11:12 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> On 17 July 2015 at 16:25, Steve Ebersole <steve at hibernate.org> wrote:
>>> > It would seem that this is a regression with ORM, I agree.  However,
>>> we do
>>> > not know how recent of a regression.  And that is the problem.  We
>>> have no
>>> > idea how far back to look.  Because the ORM CI jobs against MySQL,
>>> > PostrgreSQL, Oracle, etc have not been running for many months.  IIRC
>>> even
>>> > when they were running on the old CI servers we had problems with
>>> those jobs
>>> > that were not looked at for some time.
>>>
>>> Sure, same problem here: not run these tests for months, and you're
>>> right I could do a quick check on a slightly older branch which is
>>> using ORM 4.3 and I have the same problem.
>>>
>>> > As far as what you see, I am not convinced it is what you think it is
>>> in
>>> > terms of auto-commit for queries run outside of a transaction.  This
>>> part
>>> > has not changed in 5.0.  Assuming you are using the "built in
>>> Connection
>>> > pool", there is a setting that controls the auto-commit mode of the
>>> > connections we create (hibernate.connection.autocommit).  That setting
>>> has
>>> > always been there, and it has always defaulted to false.  This has not
>>> > changed.  In fact the same exact code is used in 4.3 and 5.0 for
>>> creating
>>> > these Connections:
>>> >
>>> org.hibernate.engine.jdbc.connections.internal.BasicConnectionCreator.  The
>>> > autoCommit value in there comes from the setting I just mentioned.  The
>>> > logical outcome is the same even before 4.3, just that it was done
>>> > differently.  So bottom line, if you are not seeing auto-commit on
>>> these
>>> > Connections now, you never were.  Now it is possible that their are
>>> some
>>> > ancillary changes that cause the lack of auto-commit to now be an issue
>>> > where it was not before.  So first, I'd need to know whether the
>>> Connection
>>> > here is auto-commit or is not.  From there we can start drilling down
>>> on
>>> > what might be a cause.  But keep in mind too, that with hangs and
>>> deadlocks
>>> > the process that hangs is often not the culprit; often it is the
>>> previous
>>> > process that is holding locks that is the culprit.
>>>
>>> I understand, but in this specific case I can reproduce the issue by
>>> running a single test.
>>> Also that psql SQL I shared clearly shows which statement is causing it
>>> to hang,
>>> and I could fix the test by just wrapping that statement in a
>>> transaction.
>>>
>>> >
>>> > My case is actually different, at least on the surface.  Mine happens
>>> on
>>> > dropping tables after the test is complete (for MySQL anyway).  Which
>>> got me
>>> > to looking at schema export and friends and how they handle
>>> connections.
>>> > They handle connections quite differently.  Again the same as they
>>> used to,
>>> > but I mean very different from how sessions manage connections.  In
>>> schema
>>> > export the connections are always set to auto-commit mode at the start
>>> of
>>> > processing.  Then they never do anything with auto-commit afterwards.
>>> I am
>>> > not sure this is right.
>>>
>>> Actually it sounds like you're having the same problem. I debugged the
>>> PosgreSQL tests first, but I had the same on MySQL (as in the
>>> stacktrace I shared),
>>> and the test also hangs on schema drop.
>>> The problem is that the schema can't be dropped because a previous
>>> statement - from a session which is now correctly closed - is still
>>> holding locks.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> >
>>> >
>>> >
>>> >
>>> > On Fri, Jul 17, 2015 at 3:51 AM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>> >>
>>> >> Thanks Steve, I wasn't sure if I had found a problem.
>>> >> Still, it looks like the Hibernate Search tests are not benefiting
>>> >> from auto-commit, or I wouldn't have this problem right? Our testing
>>> >> configuration properties have been the same for years and I'm just
>>> >> re-enabling tests which haven't been run for a while, so I suspect
>>> >> something changed in ORM.
>>> >>
>>> >> I think I'd expect Hibernate ORM to automatically enable auto-commit
>>> >> on operations not running within a transaction, to make sure all locks
>>> >> are released when the Session is closed.
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >>
>>> >> On 17 July 2015 at 00:14, Steve Ebersole <steve at hibernate.org> wrote:
>>> >> > For what it is worth, I am running into the same problems on MySQL
>>> for
>>> >> > the
>>> >> > ORM tests in terms of blocks on dropping tables.  PGSQL at least
>>> >> > finishes,
>>> >> > although I run into 55 errors which I still need to triage.
>>> >> >
>>> >> > On Thu, Jul 16, 2015 at 5:59 PM Steve Ebersole <steve at hibernate.org
>>> >
>>> >> > wrote:
>>> >> >>
>>> >> >> There is really nothing to improve.  What would you suggest as an
>>> >> >> improvement?  I mean from a ORM perspective, we have an ato-commit
>>> >> >> Connection (presumably) and run a query.  How on earth would we
>>> know to
>>> >> >> expect that the database is holding locks for that?
>>> >> >>
>>> >> >> As far as "requiring transactions" I have tried to fly that plane
>>> >> >> multiple
>>> >> >> times in the past.  I think it is absolutely ridiculous to allow
>>> these
>>> >> >> auto-commit use cases.  In fact I personally wanted to take it to
>>> the
>>> >> >> more
>>> >> >> extreme case of always using JTA and simply mimicking "single
>>> resource
>>> >> >> JTA
>>> >> >> transactions" internally in the "JDBC transaction" case.  Gavin
>>> and I
>>> >> >> both
>>> >> >> did in fact.  But we got a lot of push back.
>>> >> >>
>>> >> >> So I am not sure exactly what the improvement here might be.  What
>>> is
>>> >> >> it
>>> >> >> you were thinking specifically?
>>> >> >>
>>> >> >> On Thu, Jul 16, 2015 at 5:36 PM Sanne Grinovero <
>>> sanne at hibernate.org>
>>> >>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> I finally got to re-enable MariaDB and PostgreSQL based tests for
>>> >> >>> Hibernate Search - which has been running on H2 only for some
>>> months -
>>> >> >>> and had to debug a case of a single test hanging for a long time.
>>> >> >>>
>>> >> >>> Essentially it would block - for hours - on the
>>> SessionFactory#close()
>>> >> >>> method, attempting to drop the database schema with the following
>>> >> >>> statement:
>>> >> >>>   > alter table AncientBook_alternativeTitles drop constraint
>>> >> >>> FKn8hhkmhof1mdgc4oi77ccq989
>>> >> >>>
>>> >> >>> Dumping threads I would get a very similar stack trace on both
>>> >> >>> databases; initially I thought someone had copy/pasted a socket
>>> >> >>> handling bug from one JDBC driver to the other ;-)
>>> >> >>>
>>> >> >>> The PostgreSQL testsuite hanging:
>>> >> >>>
>>> >> >>> "main" prio=10 tid=0x00007f0f40009000 nid=0x5f7c runnable
>>> >> >>> [0x00007f0f48956000]
>>> >> >>>    java.lang.Thread.State: RUNNABLE
>>> >> >>> at java.net.SocketInputStream.socketRead0(Native Method)
>>> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>>> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:145)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:114)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)
>>> >> >>> at org.postgresql.core.PGStream.ReceiveChar(PGStream.java:274)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1660)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
>>> >> >>> - locked <0x00000007c11e3860> (a
>>> >> >>> org.postgresql.core.v3.QueryExecutorImpl)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:500)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>>> >> >>> at
>>> >> >>>
>>> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>>> >> >>> at
>>> >> >>>
>>> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>>> >> >>> at
>>> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>>> >> >>> at
>>> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>>> >> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>>> >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>>> >> >>>
>>> >> >>> The MariaDB testsuite hanging:
>>> >> >>>
>>> >> >>> "main" prio=10 tid=0x00007f8ca0009000 nid=0x4043 runnable
>>> >> >>> [0x00007f8ca5f5c000]
>>> >> >>>    java.lang.Thread.State: RUNNABLE
>>> >> >>> at java.net.SocketInputStream.socketRead0(Native Method)
>>> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:152)
>>> >> >>> at java.net.SocketInputStream.read(SocketInputStream.java:122)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
>>> >> >>> - locked <0x00000007c0baa518> (a
>>> >> >>> com.mysql.jdbc.util.ReadAheadInputStream)
>>> >> >>> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2499)
>>> >> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2952)
>>> >> >>> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2941)
>>> >> >>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
>>> >> >>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
>>> >> >>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2113)
>>> >> >>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2562)
>>> >> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
>>> >> >>> at
>>> com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1664)
>>> >> >>> - locked <0x00000007c0baa850> (a java.lang.Object)
>>> >> >>> at
>>> com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1583)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.hibernate.tool.hbm2ddl.DatabaseExporter.export(DatabaseExporter.java:47)
>>> >> >>> at
>>> >> >>>
>>> org.hibernate.tool.hbm2ddl.SchemaExport.perform(SchemaExport.java:476)
>>> >> >>> at
>>> >> >>>
>>> org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:430)
>>> >> >>> at
>>> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:375)
>>> >> >>> at
>>> org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:371)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1069)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.hibernate.search.test.util.FullTextSessionBuilder.close(FullTextSessionBuilder.java:149)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.hibernate.search.test.util.FullTextSessionBuilder$1.evaluate(FullTextSessionBuilder.java:248)
>>> >> >>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>>> >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>>> >> >>> at
>>> >> >>>
>>> >> >>>
>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
>>> >> >>>
>>> >> >>> On Gail's suggestion I went looking for database level locks; I
>>> hadn't
>>> >> >>> thought of that as I assumed it would have timed out more
>>> aggressively
>>> >> >>> rather than have me wait for hours.
>>> >> >>> It turns out she was right and the reason for blocking was a
>>> simple
>>> >> >>> "count *" query being run as a post-test assertion, which we had
>>> >> >>> forgotten to wrap in an "open transaction & commit" statements
>>> pair.
>>> >> >>> The test assertion would be successful, but apparently it would
>>> hold
>>> >> >>> on the table lock beyond closing the Session and, then fail to
>>> drop
>>> >> >>> the database at the teardown of the test.
>>> >> >>>
>>> >> >>> I'm wondering if this is expected, or if there's something in the
>>> new
>>> >> >>> transaction handling code which could be improved? It took me
>>> several
>>> >> >>> hours to figure this out; maybe I'm just not using ORM as
>>> frequently
>>> >> >>> as once :)
>>> >> >>> If it's this critical to have the transaction, maybe it should be
>>> >> >>> mandatory?
>>> >> >>>
>>> >> >>> And as a memo for next time, this is the query to figure out
>>> details
>>> >> >>> about locks on our testing db:
>>> >> >>>  > SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON
>>> pl.pid
>>> >> >>> = psa.pid where datname = 'testingdb';
>>> >> >>>
>>> >> >>> 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  Fri Jul 17 19:49:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Jul 2015 23:49:04 +0000
Subject: [hibernate-dev] MariaDB on CI
Message-ID: <CAFdSV9vaAWQbE9HO0qz04FyTJ9dXPimS6VmWab+zA=Rz12NVFw@mail.gmail.com>

[18:45] <sebersole> whoa..
[18:45] <sebersole> sannegrinovero: we definitely need this for mariadb on
ci...
[18:46] <sebersole> sync_binlog=0 innodb_flush_log_at_trx_commit=0
innodb_doublewrite=0
[18:46] <sebersole> tests were much faster

These were suggested to me on the #mariadb list.  I added them to my local
/etc/my.cnf file and the tests were significantly faster.

From steve at hibernate.org  Sat Jul 18 14:09:35 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 18 Jul 2015 18:09:35 +0000
Subject: [hibernate-dev] HQLScrollFetchTest
Message-ID: <CAFdSV9sAYRNn-HRWvrcUYZrHfFnCuarBz9u50+4XL-AbWqtsdg@mail.gmail.com>

Gail, etal.

I have a lot of questions in regards to HQLScrollFetchTest:

1) First is the split between it and NoIdentityHQLScrollFetchTest.  I do
not fully understand why this split exists.  They test the same thing
(literally; NoIdentityHQLScrollFetchTest extends HQLScrollFetchTest and
just supplies a different mapping).  The mapping says something about
Sybase requiring the pk to be an IDENTITY in order for it to support
scrolling results.  But I could find no mention of that anywhere via google
search.

2) HQLScrollFetchTest#testScroll is skipped for a huge list of dialects.  I
only even started looking at this class because this test is failing when I
try to run it against MySQL/MariaDB (these are not listed for skipping).
But looking at the test, there is no expectation that this should ever work
for any database.  The reason being that we completely expect the user to
"properly order" the query results for scrolling queries with fetches.  The
test does not do that.  TBH, I do not know what Dialect this test would
actually pass against.

From sanne at hibernate.org  Sat Jul 18 16:36:50 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 18 Jul 2015 21:36:50 +0100
Subject: [hibernate-dev] MariaDB on CI
In-Reply-To: <CAFdSV9vaAWQbE9HO0qz04FyTJ9dXPimS6VmWab+zA=Rz12NVFw@mail.gmail.com>
References: <CAFdSV9vaAWQbE9HO0qz04FyTJ9dXPimS6VmWab+zA=Rz12NVFw@mail.gmail.com>
Message-ID: <CAFm4XO33Hf0fX2ckB_t1zpPt8oZdXPstmxB0EG4j+rphaQ-ruQ@mail.gmail.com>

Thanks, great suggestions!
I've applied these and some more.

The MariaDB configuration:
 - https://github.com/hibernate/ci.hibernate.org/blob/master/roles/mariadb-server/files/my.cnf

The PosgreSQL configuration files:
 - https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/pg_hba.conf
 - https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/postgresql.conf

Both are running with these settings now on each CI slave.
Sanne

On 18 July 2015 at 00:49, Steve Ebersole <steve at hibernate.org> wrote:
> [18:45] <sebersole> whoa..
> [18:45] <sebersole> sannegrinovero: we definitely need this for mariadb on
> ci...
> [18:46] <sebersole> sync_binlog=0 innodb_flush_log_at_trx_commit=0
> innodb_doublewrite=0
> [18:46] <sebersole> tests were much faster
>
> These were suggested to me on the #mariadb list.  I added them to my local
> /etc/my.cnf file and the tests were significantly faster.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Sun Jul 19 10:53:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 19 Jul 2015 14:53:52 +0000
Subject: [hibernate-dev] Enum mapping in hbm.xml
Message-ID: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>

This came up in getting the testsuite set up against MySQL.  When an enum
is defined in hbm.xml we do not inherently know whether to treat it as
ordinal or named.  We try a few different things to make this
determination, but ultimately if we do not have enough information up front
we prefer to defer the decision until later when we have access to some
form of JDBC metadata (generally nullSafeSet/nullSafeGet) to decide.

It seems there was initially a problem in that deference code that led
to HHH-8153[1].  However, the fix done for HHH-8153 is not enough.
Ultimately the problem is that the driver may not have the proper
information to answer java.sql.ParameterMetaData#getParameterType
correctly.  HHH-8153 handles the case where the driver flat out does not
support that call and throws an exception.  However MySQL illustrates
another case where the driver simply reports VARCHAR as the broadest
acceptable type.  In other words it is not looking at the underlying
datatypes in the database.  So even if the parameter is matched to the enum
column that we defined as numeric, the MySQL driver is still going to
return ParameterMetaData#getParameterType == VARCHAR.

I cannot say how many drivers implement this correctly.  H2 does this as we
expect it.  MySQL at least does not.

So the question becomes how we want to support enum types in hbm.xml.  For
illustration, this can be seen in the org.hibernate.test.enums.EnumTypeTest
added for HHH-8153.  The mapping is
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/resources/org/hibernate/test/enums/Person.hbm.xml.
Neither enum mapping works particularly "correctly", but the test failure
comes from the HairColor mapping.  We expect that to be an ordinal, we
create the table with its column being a numeric, but then the driver says
the parameter type is VARCHAR and we try to treat it as named.

For what it is worth, I had quite a long time ago added the parameter
needed to properly control this in hbm.xml.  The "proper" way to map these
would have been to use the "useNamed" type parameter:

<property name="gender" not-null="true">
    <type name="org.hibernate.type.EnumType">
        <param name="enumClass">org.hibernate.test.enums.Gender</param>
        <param name="useNamed">false</param>
    </type>
</property>
<property name="hairColor" not-null="true">
    <type name="org.hibernate.type.EnumType">
        <param name="enumClass">org.hibernate.test.enums.HairColor</param>
        <param name="useNamed">true</param>
    </type>
</property>

The rub is that to cater for legacy mappings, I do not "require" this, like
annotations do.  This would be a non-issue if I could, during
configuration, say that an enum is ordinal if "useNamed" is not set or is
set to false and that it is named if useNamed is set to true.  What is
missing/different is the not-set case.  At them moment that falls back to
the JDBC metadata approach discussed above.

What I propose is that we change this.  I am kind of torn as to the default
tbh.  I think JPA's default of ORDINAL is the wrong choice.  I think NAMED
is the better choice.  Well technically I think an independent mapping code
it best.  But strictly between ORDINAL/NAMED, I think NAMED is better.  So
if everyone agrees that we change this to definitively determine the enum
mapping up front, which style do we choose as the default.  Obviously the
big argument for choosing ORDINAL is consistency with annotations.


[1] https://hibernate.atlassian.net/browse/HHH-8153

From steve at hibernate.org  Sun Jul 19 11:02:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 19 Jul 2015 15:02:37 +0000
Subject: [hibernate-dev] Enum mapping in hbm.xml
In-Reply-To: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>
References: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>
Message-ID: <CAFdSV9tALY5wzKKfQNwgaEgBkXbJOJ5w9RfNRP1jmzsVm3+0cQ@mail.gmail.com>

I should have mentioned...  There is also this "type" parameter that
EnumType accepts.  I'd also look at that in terms of deciding defaults.  It
accepts JDBC type codes.  EnumType already knows which type codes
constitute ordinal types and named types.  So in psuedo code what I am
proposing is:

if ( useNamed != null ) {
    if ( useNamed == true ) {
        treatAsNamed();
    }
    else {
        treatAsOrdinal();
    }
}
else {
    if ( type != null ) {
        if ( isOrdinal(type) ) {
            treatAsOrdinal();
        }
        else if ( isNamed(type) ) {
            treatAsNamed();
        }
    }
    else {
        // todo : need to decide fallback...
       treatAsNamed();
    }
}
throw new SomePoignantException("blah blah blah");

The other thing to notice is that there is no more "waiting" in this
proposal.  No more deferring until the first nullSafeSet/nullSafeGet call.

On Sun, Jul 19, 2015 at 9:53 AM Steve Ebersole <steve at hibernate.org> wrote:

> This came up in getting the testsuite set up against MySQL.  When an enum
> is defined in hbm.xml we do not inherently know whether to treat it as
> ordinal or named.  We try a few different things to make this
> determination, but ultimately if we do not have enough information up front
> we prefer to defer the decision until later when we have access to some
> form of JDBC metadata (generally nullSafeSet/nullSafeGet) to decide.
>
> It seems there was initially a problem in that deference code that led
> to HHH-8153[1].  However, the fix done for HHH-8153 is not enough.
> Ultimately the problem is that the driver may not have the proper
> information to answer java.sql.ParameterMetaData#getParameterType
> correctly.  HHH-8153 handles the case where the driver flat out does not
> support that call and throws an exception.  However MySQL illustrates
> another case where the driver simply reports VARCHAR as the broadest
> acceptable type.  In other words it is not looking at the underlying
> datatypes in the database.  So even if the parameter is matched to the enum
> column that we defined as numeric, the MySQL driver is still going to
> return ParameterMetaData#getParameterType == VARCHAR.
>
> I cannot say how many drivers implement this correctly.  H2 does this as
> we expect it.  MySQL at least does not.
>
> So the question becomes how we want to support enum types in hbm.xml.  For
> illustration, this can be seen in the org.hibernate.test.enums.EnumTypeTest
> added for HHH-8153.  The mapping is
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/resources/org/hibernate/test/enums/Person.hbm.xml.
> Neither enum mapping works particularly "correctly", but the test failure
> comes from the HairColor mapping.  We expect that to be an ordinal, we
> create the table with its column being a numeric, but then the driver says
> the parameter type is VARCHAR and we try to treat it as named.
>
> For what it is worth, I had quite a long time ago added the parameter
> needed to properly control this in hbm.xml.  The "proper" way to map these
> would have been to use the "useNamed" type parameter:
>
> <property name="gender" not-null="true">
>     <type name="org.hibernate.type.EnumType">
>         <param name="enumClass">org.hibernate.test.enums.Gender</param>
>         <param name="useNamed">false</param>
>     </type>
> </property>
> <property name="hairColor" not-null="true">
>     <type name="org.hibernate.type.EnumType">
>         <param name="enumClass">org.hibernate.test.enums.HairColor</param>
>         <param name="useNamed">true</param>
>     </type>
> </property>
>
> The rub is that to cater for legacy mappings, I do not "require" this,
> like annotations do.  This would be a non-issue if I could, during
> configuration, say that an enum is ordinal if "useNamed" is not set or is
> set to false and that it is named if useNamed is set to true.  What is
> missing/different is the not-set case.  At them moment that falls back to
> the JDBC metadata approach discussed above.
>
> What I propose is that we change this.  I am kind of torn as to the
> default tbh.  I think JPA's default of ORDINAL is the wrong choice.  I
> think NAMED is the better choice.  Well technically I think an independent
> mapping code it best.  But strictly between ORDINAL/NAMED, I think NAMED is
> better.  So if everyone agrees that we change this to definitively
> determine the enum mapping up front, which style do we choose as the
> default.  Obviously the big argument for choosing ORDINAL is consistency
> with annotations.
>
>
> [1] https://hibernate.atlassian.net/browse/HHH-8153
>

From gunnar at hibernate.org  Mon Jul 20 01:32:05 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Jul 2015 07:32:05 +0200
Subject: [hibernate-dev] Naming strategies and collection element columns
In-Reply-To: <CADGJaX-LuenDXGfYt42WVLeDhuKie7vrGnDBOqW=mK5ULeG71g@mail.gmail.com>
References: <CADGJaX8OAvtXdB=S_827ZEaJ_kyACJ_jM6wWA1uxM7e9DLzZ1A@mail.gmail.com>
	<CADGJaX-LuenDXGfYt42WVLeDhuKie7vrGnDBOqW=mK5ULeG71g@mail.gmail.com>
Message-ID: <CADGJaX983zNmF4jYaSmQ_C55uvqm1c2ZwJ2S-K6C2AdyG73d1Q@mail.gmail.com>

Steve, any ideas regarding the invocation of determineBasicColumnName() for
collection elements?

Thanks,

--Gunnar


2015-07-17 16:46 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> Turns out our ImplicitNamingStrategy's determineBasicColumnName() is
> invoked twice at different places within Ejb3Column. Once the magic
> HHH-6005 replacement takes place (in redefineColumnName()) and the other
> time it doesn't (addColumnBinding()).
>
> So we are once called with "grandChildren.name" and the other time
> with "grandChildren.collection&&element.name". This seems not right, but
> then the code in Ejb3Column is quite dense and I may well miss something.
>
> Any ideas?
>
>
> 2015-07-17 15:11 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>
>> Steve,
>>
>> There is one remaining itch I have wrt. upgrading OGM to ORM 5.
>>
>> I have an entity GrandMother with an @ElementCollection "grandChildren"
>> of type GrandChild. The latter has a property "name" which used to be
>> passed as "grandChildren.collection&&element.name" to OGM's
>> NamingStrategy#propertyToColumnName(). We used to detect the
>> "collection&&element" pattern to determine the right column name fin OGM.
>>
>> As of ORM 5, this is passed as "grandChildren.name" instead (due to
>> HHH-6005 [1]). Now I thought
>> ImplicitBasicColumnNameSource#isCollectionElement() would tell me whether
>> this is a collection element, but it returns false in this case.
>>
>> Shouldn't it return true if the replacement magic for HHH-6005 has kicked
>> in Ejb3Column#redefineColumnName()?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-6005
>>
>>
>

From gunnar at hibernate.org  Mon Jul 20 02:50:20 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Jul 2015 08:50:20 +0200
Subject: [hibernate-dev] ORM - location of generated sources
Message-ID: <CADGJaX_E7YmB_BuP=e1OwYqbhSJasaffKU6dwChV+c++=0B4Rg@mail.gmail.com>

Hi,

The build for hibernate-core generates sources using Antlr which end up in
target/generated-src/antlr/main, e.g. GeneratedOrderByFragmentParser.java.

The weird thing is that the generated files are located right within this
directory, i.e.  there is *no* directory hierarchy resembling the package
structure. The files have package declarations such as
"org.hibernate.sql.ordering.antlr", though.

Apparently, this works in the Gradle build (no errors due to that), but in
my IDE I am getting tons of compile errors due to the mismatch of package
declaration and file location. Interestingly, the files also end up in the
right place in the hibernate-core.jar, so I assume that there is some Magic
in place at the Gradle level which deals with that stuff.

Does anyone know how to make it work in the IDE as well?

Thanks,

--Gunnar

From emmanuel at hibernate.org  Mon Jul 20 03:25:03 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 20 Jul 2015 09:25:03 +0200
Subject: [hibernate-dev] Enum mapping in hbm.xml
In-Reply-To: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>
References: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>
Message-ID: <B4FC230B-982E-41EC-AAF8-DCCC324D14B8@hibernate.org>


> On 19 Jul 2015, at 16:53, Steve Ebersole <steve at hibernate.org> wrote:
> 
> What I propose is that we change this.  I am kind of torn as to the default
> tbh.  I think JPA's default of ORDINAL is the wrong choice.  I think NAMED
> is the better choice.  Well technically I think an independent mapping code
> it best.  But strictly between ORDINAL/NAMED, I think NAMED is better.  So
> if everyone agrees that we change this to definitively determine the enum
> mapping up front, which style do we choose as the default.  Obviously the
> big argument for choosing ORDINAL is consistency with annotations.

Even if like you I prefer NAMED over ORDINAL, I would prefer consistency with annotations. If you feel strongly on the subject, I think the other way is fine too since:

* the recommendation is to be explicit
* hbm is already quite a different beast than annotations/orm.xml


From gunnar at hibernate.org  Mon Jul 20 04:29:42 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Jul 2015 10:29:42 +0200
Subject: [hibernate-dev] ORM - Download of DTD failed
Message-ID: <CADGJaX8m9=1Ukxuf27ctabp=SPL-jjKhuhJC2UWYmJTiMZHnkw@mail.gmail.com>

Hi,

I noticed an interesting failure of HibernateCacheTest from the
"hibernate-ehcache" module in a recent ORM CI build [1].

It failed to obtain hibernate-configuration-3.0.dtd from SourceForge (there
was some service outage at SF at this time). Apart from the fact that the
test uses the legacy URL (I'll fix that), I am wondering why the config
parser tried to obtain the DTD remotely in the first place. We have
LocalXmlResourceResolver in place which is there to prevent this. An indeed
if I debug the test locally, I don't get to the place where it would
download it from remote.

Anyone with an idea why that would happen on CI?

Thanks,

--Gunnar

[1]
http://ci.hibernate.org/job/hibernate-orm-master-h2/988/testReport/junit/org.hibernate.test.cache/HibernateCacheTest/classMethod/

From steve at hibernate.org  Mon Jul 20 08:13:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 20 Jul 2015 12:13:44 +0000
Subject: [hibernate-dev] ORM - Download of DTD failed
In-Reply-To: <CADGJaX8m9=1Ukxuf27ctabp=SPL-jjKhuhJC2UWYmJTiMZHnkw@mail.gmail.com>
References: <CADGJaX8m9=1Ukxuf27ctabp=SPL-jjKhuhJC2UWYmJTiMZHnkw@mail.gmail.com>
Message-ID: <CAFdSV9txOWqcrpT1KQG77noP+KFDRBrR-9-7FFCJMUJh7CY+sg@mail.gmail.com>

Pull again :)  I fixed this yesterday.  We were missing the SourceForge url
for local resolution of the CFG DTD

On Mon, Jul 20, 2015, 3:30 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> I noticed an interesting failure of HibernateCacheTest from the
> "hibernate-ehcache" module in a recent ORM CI build [1].
>
> It failed to obtain hibernate-configuration-3.0.dtd from SourceForge (there
> was some service outage at SF at this time). Apart from the fact that the
> test uses the legacy URL (I'll fix that), I am wondering why the config
> parser tried to obtain the DTD remotely in the first place. We have
> LocalXmlResourceResolver in place which is there to prevent this. An indeed
> if I debug the test locally, I don't get to the place where it would
> download it from remote.
>
> Anyone with an idea why that would happen on CI?
>
> Thanks,
>
> --Gunnar
>
> [1]
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/988/testReport/junit/org.hibernate.test.cache/HibernateCacheTest/classMethod/
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Jul 20 09:55:16 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Jul 2015 15:55:16 +0200
Subject: [hibernate-dev] ORM - Download of DTD failed
In-Reply-To: <CAFdSV9txOWqcrpT1KQG77noP+KFDRBrR-9-7FFCJMUJh7CY+sg@mail.gmail.com>
References: <CADGJaX8m9=1Ukxuf27ctabp=SPL-jjKhuhJC2UWYmJTiMZHnkw@mail.gmail.com>
	<CAFdSV9txOWqcrpT1KQG77noP+KFDRBrR-9-7FFCJMUJh7CY+sg@mail.gmail.com>
Message-ID: <CADGJaX9gHkYX1pzUejT7ZHi1Xh-ykb_9fwWrx=n2Br5NhVnEUQ@mail.gmail.com>

Ah yes; I had pulled, that's why I couldn't reproduce this issue locally :)
Thanks for fixing it!

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

> Pull again :)  I fixed this yesterday.  We were missing the SourceForge
> url for local resolution of the CFG DTD
>
> On Mon, Jul 20, 2015, 3:30 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Hi,
>>
>> I noticed an interesting failure of HibernateCacheTest from the
>> "hibernate-ehcache" module in a recent ORM CI build [1].
>>
>> It failed to obtain hibernate-configuration-3.0.dtd from SourceForge
>> (there
>> was some service outage at SF at this time). Apart from the fact that the
>> test uses the legacy URL (I'll fix that), I am wondering why the config
>> parser tried to obtain the DTD remotely in the first place. We have
>> LocalXmlResourceResolver in place which is there to prevent this. An
>> indeed
>> if I debug the test locally, I don't get to the place where it would
>> download it from remote.
>>
>> Anyone with an idea why that would happen on CI?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>>
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/988/testReport/junit/org.hibernate.test.cache/HibernateCacheTest/classMethod/
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Mon Jul 20 10:41:07 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 20 Jul 2015 14:41:07 +0000
Subject: [hibernate-dev] MariaDB on CI
In-Reply-To: <CAFm4XO33Hf0fX2ckB_t1zpPt8oZdXPstmxB0EG4j+rphaQ-ruQ@mail.gmail.com>
References: <CAFdSV9vaAWQbE9HO0qz04FyTJ9dXPimS6VmWab+zA=Rz12NVFw@mail.gmail.com>
	<CAFm4XO33Hf0fX2ckB_t1zpPt8oZdXPstmxB0EG4j+rphaQ-ruQ@mail.gmail.com>
Message-ID: <CAFdSV9twdX6qVom-B490HqH3--=Kt1pKGQrqg7ZgMU=1qQ6i7w@mail.gmail.com>

Sanne for MariaDB (and MySQL if we ever add it) we need to add at least one
more setting:

sql-mode="traditional"

We could probably get away with less ANSI compliant mode, but after days
playing with this I just want to cover my bases :)

On Sat, Jul 18, 2015 at 3:37 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Thanks, great suggestions!
> I've applied these and some more.
>
> The MariaDB configuration:
>  -
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/mariadb-server/files/my.cnf
>
> The PosgreSQL configuration files:
>  -
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/pg_hba.conf
>  -
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/postgresql.conf
>
> Both are running with these settings now on each CI slave.
> Sanne
>
> On 18 July 2015 at 00:49, Steve Ebersole <steve at hibernate.org> wrote:
> > [18:45] <sebersole> whoa..
> > [18:45] <sebersole> sannegrinovero: we definitely need this for mariadb
> on
> > ci...
> > [18:46] <sebersole> sync_binlog=0 innodb_flush_log_at_trx_commit=0
> > innodb_doublewrite=0
> > [18:46] <sebersole> tests were much faster
> >
> > These were suggested to me on the #mariadb list.  I added them to my
> local
> > /etc/my.cnf file and the tests were significantly faster.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jul 20 10:52:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 20 Jul 2015 14:52:44 +0000
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAFdSV9tk71A6ZT79i=3u05P0QZjRzgonDUULMEL15QqttMue=A@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
	<CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
	<1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>
	<CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>
	<CAFdSV9vqURJiyc9Di=oMC1f+q-F7jx0MyfRjmthMOp7voiEqng@mail.gmail.com>
	<65940533.19312116.1436893564714.JavaMail.zimbra@redhat.com>
	<CAL00eST5mDp8t8N=dB59wRE5so4kTzc=07pr+5UOaA7jk4kvBg@mail.gmail.com>
	<CAFdSV9tk71A6ZT79i=3u05P0QZjRzgonDUULMEL15QqttMue=A@mail.gmail.com>
Message-ID: <CAFdSV9uhExY=CcyKariXdQJh4nFe09F+=v7i=py4fX0k_kFo9Q@mail.gmail.com>

Does it make sense to have a dedicated meeting room?  I wonder if the main
hibernate-orm room is too chatty; if the discussion would just immediately
get lost.


On Tue, Jul 14, 2015 at 1:07 PM Steve Ebersole <steve at hibernate.org> wrote:

> Ok, then lets plan on next Tuesday on HiptChat...
>
>
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Hibernate+ORM+Triage+Meeting&iso=20150721T13&p1=24
>
>
> On Tue, Jul 14, 2015 at 12:32 PM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> I have a problem on Monday but Tuesday is fine.
>>
>> On 14 July 2015 at 18:06, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Next week is fine. Monday or Tuesday work for me.
>>>
>>> ----- Original Message -----
>>> > From: "Steve Ebersole" <steve at hibernate.org>
>>> > To: "Gail Badner" <gbadner at redhat.com>
>>> > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <
>>> hibernate-dev at lists.jboss.org>
>>> > Sent: Monday, July 13, 2015 5:22:26 PM
>>> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>>> >
>>> > Now that 5.0 development is settling down, I think its time to go
>>> ahead and
>>> > start on this.  Should we start next week?  We never discussed a day.
>>> I am
>>> > thinking Monday or Tuesday.  Does that work for everyone interested?
>>> >
>>> > Ultimately the idea is for this meeting to address incoming HHH issues.
>>> > But I realize the first few meetings might very well focus on past
>>> issues.
>>> >
>>> >
>>> > On Thu, Apr 16, 2015 at 8:16 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> >
>>> > > Sometime after the next 5.0 release.  You know, after I have time to
>>> > > breathe :)
>>> > >
>>> > > On Wed, Apr 15, 2015 at 5:06 PM, Gail Badner <gbadner at redhat.com>
>>> wrote:
>>> > >
>>> > >> When will we start having these meetings?
>>> > >>
>>> > >> ----- Original Message -----
>>> > >> > From: "Sanne Grinovero" <sanne at hibernate.org>
>>> > >> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>>> > >> > Sent: Monday, March 23, 2015 2:17:40 PM
>>> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>>> > >> >
>>> > >> > +1 it's a nice time to allow me to join occasionally as needed
>>> > >> >
>>> > >> > Sanne
>>> > >> >
>>> > >> > On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com>
>>> wrote:
>>> > >> > > 11am Seattle time would be ideal. Thanks!
>>> > >> > > Gail
>>> > >> > >
>>> > >> > > ----- Original Message -----
>>> > >> > >> From: "Brett Meyer" <brmeyer at redhat.com>
>>> > >> > >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>>> > >> > >> Sent: Monday, March 23, 2015 6:51:49 AM
>>> > >> > >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>>> > >> > >>
>>> > >> > >> Big +1 from me -- I'd be more than happy to be involved.
>>> > >> > >>
>>> > >> > >> ----- Original Message -----
>>> > >> > >> > From: "andrea boriero" <dreborier at gmail.com>
>>> > >> > >> > To: "Steve Ebersole" <steve at hibernate.org>
>>> > >> > >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>>> > >> > >> > Sent: Sunday, March 22, 2015 3:45:01 PM
>>> > >> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
>>> > >> > >> >
>>> > >> > >> > for me at the moment it would be 6pm and it should be good.
>>> > >> > >> >
>>> > >> > >> > On 21 March 2015 at 21:08, Steve Ebersole <
>>> steve at hibernate.org>
>>> > >> wrote:
>>> > >> > >> >
>>> > >> > >> > > Gail and I discussed Jira a little bit last week and how
>>> to best
>>> > >> > >> > > manage
>>> > >> > >> > > scheduling issues.
>>> > >> > >> > >
>>> > >> > >> > > We both agreed that a team get together, either weekly or
>>> > >> > >> > > every-other-week,
>>> > >> > >> > > to discuss new issues to triage them would be a great idea.
>>> > >> > >> > >
>>> > >> > >> > > One thing I absolutely do not want happening is just
>>> scheduling
>>> > >> issues
>>> > >> > >> > > as
>>> > >> > >> > > a
>>> > >> > >> > > means to come back and triage them later.  Scheduling an
>>> issue,
>>> > >> on a
>>> > >> > >> > > "real
>>> > >> > >> > > version" anyway, should mean something.  It should mean
>>> some
>>> > >> level of
>>> > >> > >> > > dedication to finish that task for that release.  In short,
>>> > >> unless you
>>> > >> > >> > > are
>>> > >> > >> > > volunteering to take on a task *yourself* for that release,
>>> > >> please do
>>> > >> > >> > > not
>>> > >> > >> > > schedule it for that release.
>>> > >> > >> > >
>>> > >> > >> > > As for the triage meeting, I would definitely like Gail and
>>> > >> Andrea
>>> > >> > >> > > involved.  Of course anyone is welcome.  The reason I
>>> mention
>>> > >> this is
>>> > >> > >> > > that
>>> > >> > >> > > Gail is usually left on early side of scheduling these.
>>> So we
>>> > >> will
>>> > >> > >> > > find
>>> > >> > >> > > a
>>> > >> > >> > > time that works best for us 3 and go from there.  I
>>> recommend
>>> > >> that we
>>> > >> > >> > > leverage HipChat for these discussion.
>>> > >> > >> > >
>>> > >> > >> > > Andrea is coming to Austin for a few days starting Monday,
>>> so I
>>> > >> would
>>> > >> > >> > > like
>>> > >> > >> > > to start this triaging while he is here.  Gail, I am
>>> thinking
>>> > >> 1pm my
>>> > >> > >> > > time
>>> > >> > >> > > (11am yours) would be a good time.  Andrea, does that work
>>> for
>>> > >> you
>>> > >> > >> > > after
>>> > >> > >> > > Austin?
>>> > >> > >> > > _______________________________________________
>>> > >> > >> > > 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
>>> > >> > _______________________________________________
>>> > >> > 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 dreborier at gmail.com  Mon Jul 20 11:22:51 2015
From: dreborier at gmail.com (andrea boriero)
Date: Mon, 20 Jul 2015 16:22:51 +0100
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAFdSV9uhExY=CcyKariXdQJh4nFe09F+=v7i=py4fX0k_kFo9Q@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
	<CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
	<1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>
	<CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>
	<CAFdSV9vqURJiyc9Di=oMC1f+q-F7jx0MyfRjmthMOp7voiEqng@mail.gmail.com>
	<65940533.19312116.1436893564714.JavaMail.zimbra@redhat.com>
	<CAL00eST5mDp8t8N=dB59wRE5so4kTzc=07pr+5UOaA7jk4kvBg@mail.gmail.com>
	<CAFdSV9tk71A6ZT79i=3u05P0QZjRzgonDUULMEL15QqttMue=A@mail.gmail.com>
	<CAFdSV9uhExY=CcyKariXdQJh4nFe09F+=v7i=py4fX0k_kFo9Q@mail.gmail.com>
Message-ID: <CAL00eSSvpsEjA=81TxrQuHRBLQ8s5MF=JTHvVT6fsJWtifAyJQ@mail.gmail.com>

+1 for a dedicated room

On 20 July 2015 at 15:52, Steve Ebersole <steve at hibernate.org> wrote:

> Does it make sense to have a dedicated meeting room?  I wonder if the main
> hibernate-orm room is too chatty; if the discussion would just immediately
> get lost.
>
>
> On Tue, Jul 14, 2015 at 1:07 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > Ok, then lets plan on next Tuesday on HiptChat...
> >
> >
> >
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Hibernate+ORM+Triage+Meeting&iso=20150721T13&p1=24
> >
> >
> > On Tue, Jul 14, 2015 at 12:32 PM andrea boriero <dreborier at gmail.com>
> > wrote:
> >
> >> I have a problem on Monday but Tuesday is fine.
> >>
> >> On 14 July 2015 at 18:06, Gail Badner <gbadner at redhat.com> wrote:
> >>
> >>> Next week is fine. Monday or Tuesday work for me.
> >>>
> >>> ----- Original Message -----
> >>> > From: "Steve Ebersole" <steve at hibernate.org>
> >>> > To: "Gail Badner" <gbadner at redhat.com>
> >>> > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <
> >>> hibernate-dev at lists.jboss.org>
> >>> > Sent: Monday, July 13, 2015 5:22:26 PM
> >>> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >>> >
> >>> > Now that 5.0 development is settling down, I think its time to go
> >>> ahead and
> >>> > start on this.  Should we start next week?  We never discussed a day.
> >>> I am
> >>> > thinking Monday or Tuesday.  Does that work for everyone interested?
> >>> >
> >>> > Ultimately the idea is for this meeting to address incoming HHH
> issues.
> >>> > But I realize the first few meetings might very well focus on past
> >>> issues.
> >>> >
> >>> >
> >>> > On Thu, Apr 16, 2015 at 8:16 AM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>> >
> >>> > > Sometime after the next 5.0 release.  You know, after I have time
> to
> >>> > > breathe :)
> >>> > >
> >>> > > On Wed, Apr 15, 2015 at 5:06 PM, Gail Badner <gbadner at redhat.com>
> >>> wrote:
> >>> > >
> >>> > >> When will we start having these meetings?
> >>> > >>
> >>> > >> ----- Original Message -----
> >>> > >> > From: "Sanne Grinovero" <sanne at hibernate.org>
> >>> > >> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >>> > >> > Sent: Monday, March 23, 2015 2:17:40 PM
> >>> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >>> > >> >
> >>> > >> > +1 it's a nice time to allow me to join occasionally as needed
> >>> > >> >
> >>> > >> > Sanne
> >>> > >> >
> >>> > >> > On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com>
> >>> wrote:
> >>> > >> > > 11am Seattle time would be ideal. Thanks!
> >>> > >> > > Gail
> >>> > >> > >
> >>> > >> > > ----- Original Message -----
> >>> > >> > >> From: "Brett Meyer" <brmeyer at redhat.com>
> >>> > >> > >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >>> > >> > >> Sent: Monday, March 23, 2015 6:51:49 AM
> >>> > >> > >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >>> > >> > >>
> >>> > >> > >> Big +1 from me -- I'd be more than happy to be involved.
> >>> > >> > >>
> >>> > >> > >> ----- Original Message -----
> >>> > >> > >> > From: "andrea boriero" <dreborier at gmail.com>
> >>> > >> > >> > To: "Steve Ebersole" <steve at hibernate.org>
> >>> > >> > >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >>> > >> > >> > Sent: Sunday, March 22, 2015 3:45:01 PM
> >>> > >> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >>> > >> > >> >
> >>> > >> > >> > for me at the moment it would be 6pm and it should be good.
> >>> > >> > >> >
> >>> > >> > >> > On 21 March 2015 at 21:08, Steve Ebersole <
> >>> steve at hibernate.org>
> >>> > >> wrote:
> >>> > >> > >> >
> >>> > >> > >> > > Gail and I discussed Jira a little bit last week and how
> >>> to best
> >>> > >> > >> > > manage
> >>> > >> > >> > > scheduling issues.
> >>> > >> > >> > >
> >>> > >> > >> > > We both agreed that a team get together, either weekly or
> >>> > >> > >> > > every-other-week,
> >>> > >> > >> > > to discuss new issues to triage them would be a great
> idea.
> >>> > >> > >> > >
> >>> > >> > >> > > One thing I absolutely do not want happening is just
> >>> scheduling
> >>> > >> issues
> >>> > >> > >> > > as
> >>> > >> > >> > > a
> >>> > >> > >> > > means to come back and triage them later.  Scheduling an
> >>> issue,
> >>> > >> on a
> >>> > >> > >> > > "real
> >>> > >> > >> > > version" anyway, should mean something.  It should mean
> >>> some
> >>> > >> level of
> >>> > >> > >> > > dedication to finish that task for that release.  In
> short,
> >>> > >> unless you
> >>> > >> > >> > > are
> >>> > >> > >> > > volunteering to take on a task *yourself* for that
> release,
> >>> > >> please do
> >>> > >> > >> > > not
> >>> > >> > >> > > schedule it for that release.
> >>> > >> > >> > >
> >>> > >> > >> > > As for the triage meeting, I would definitely like Gail
> and
> >>> > >> Andrea
> >>> > >> > >> > > involved.  Of course anyone is welcome.  The reason I
> >>> mention
> >>> > >> this is
> >>> > >> > >> > > that
> >>> > >> > >> > > Gail is usually left on early side of scheduling these.
> >>> So we
> >>> > >> will
> >>> > >> > >> > > find
> >>> > >> > >> > > a
> >>> > >> > >> > > time that works best for us 3 and go from there.  I
> >>> recommend
> >>> > >> that we
> >>> > >> > >> > > leverage HipChat for these discussion.
> >>> > >> > >> > >
> >>> > >> > >> > > Andrea is coming to Austin for a few days starting
> Monday,
> >>> so I
> >>> > >> would
> >>> > >> > >> > > like
> >>> > >> > >> > > to start this triaging while he is here.  Gail, I am
> >>> thinking
> >>> > >> 1pm my
> >>> > >> > >> > > time
> >>> > >> > >> > > (11am yours) would be a good time.  Andrea, does that
> work
> >>> for
> >>> > >> you
> >>> > >> > >> > > after
> >>> > >> > >> > > Austin?
> >>> > >> > >> > > _______________________________________________
> >>> > >> > >> > > 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
> >>> > >> > _______________________________________________
> >>> > >> > 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  Mon Jul 20 13:05:07 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 20 Jul 2015 17:05:07 +0000
Subject: [hibernate-dev] Enum mapping in hbm.xml
In-Reply-To: <B4FC230B-982E-41EC-AAF8-DCCC324D14B8@hibernate.org>
References: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>
	<B4FC230B-982E-41EC-AAF8-DCCC324D14B8@hibernate.org>
Message-ID: <CAFdSV9tC3oow1fgiqNVyqmU__UPTTZK2zBPv5ZkSgXCGdt41Tw@mail.gmail.com>

Well, first things first :)

Does anyone disagree with making this a requirement to be fully expressed
in the mapping?  In other words, does anyone disagree fully resolving the
"enum type" (ordinal/name)
in org.hibernate.type.EnumType#setParameterValues?

This would mean getting rid of the hooks in nullSafeSet/nullSafeGet as they
would be pointless.

As far as the default type, I don't feel that strongly.  Like I said, to me
neither is a really compelling way to map enums; names are only slightly
better that ordinals imo.  I am ok with the consistency aspect.


On Mon, Jul 20, 2015 at 2:25 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

>
> On 19 Jul 2015, at 16:53, Steve Ebersole <steve at hibernate.org> wrote:
>
> What I propose is that we change this.  I am kind of torn as to the default
> tbh.  I think JPA's default of ORDINAL is the wrong choice.  I think NAMED
> is the better choice.  Well technically I think an independent mapping code
> it best.  But strictly between ORDINAL/NAMED, I think NAMED is better.  So
> if everyone agrees that we change this to definitively determine the enum
> mapping up front, which style do we choose as the default.  Obviously the
> big argument for choosing ORDINAL is consistency with annotations.
>
>
> Even if like you I prefer NAMED over ORDINAL, I would prefer consistency
> with annotations. If you feel strongly on the subject, I think the other
> way is fine too since:
>
> * the recommendation is to be explicit
> * hbm is already quite a different beast than annotations/orm.xml
>
>

From steve at hibernate.org  Mon Jul 20 13:36:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 20 Jul 2015 17:36:30 +0000
Subject: [hibernate-dev] Enum mapping in hbm.xml
In-Reply-To: <CAFdSV9tC3oow1fgiqNVyqmU__UPTTZK2zBPv5ZkSgXCGdt41Tw@mail.gmail.com>
References: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>
	<B4FC230B-982E-41EC-AAF8-DCCC324D14B8@hibernate.org>
	<CAFdSV9tC3oow1fgiqNVyqmU__UPTTZK2zBPv5ZkSgXCGdt41Tw@mail.gmail.com>
Message-ID: <CAFdSV9vnn1g-2c3zzFNq5R--At9EpgwH39iRtOHHY5vtz9DuwQ@mail.gmail.com>

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

On Mon, Jul 20, 2015 at 12:05 PM Steve Ebersole <steve at hibernate.org> wrote:

> Well, first things first :)
>
> Does anyone disagree with making this a requirement to be fully expressed
> in the mapping?  In other words, does anyone disagree fully resolving the
> "enum type" (ordinal/name)
> in org.hibernate.type.EnumType#setParameterValues?
>
> This would mean getting rid of the hooks in nullSafeSet/nullSafeGet as
> they would be pointless.
>
> As far as the default type, I don't feel that strongly.  Like I said, to
> me neither is a really compelling way to map enums; names are only slightly
> better that ordinals imo.  I am ok with the consistency aspect.
>
>
> On Mon, Jul 20, 2015 at 2:25 AM Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>>
>> On 19 Jul 2015, at 16:53, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> What I propose is that we change this.  I am kind of torn as to the
>> default
>> tbh.  I think JPA's default of ORDINAL is the wrong choice.  I think NAMED
>> is the better choice.  Well technically I think an independent mapping
>> code
>> it best.  But strictly between ORDINAL/NAMED, I think NAMED is better.  So
>> if everyone agrees that we change this to definitively determine the enum
>> mapping up front, which style do we choose as the default.  Obviously the
>> big argument for choosing ORDINAL is consistency with annotations.
>>
>>
>> Even if like you I prefer NAMED over ORDINAL, I would prefer consistency
>> with annotations. If you feel strongly on the subject, I think the other
>> way is fine too since:
>>
>> * the recommendation is to be explicit
>> * hbm is already quite a different beast than annotations/orm.xml
>>
>>

From hardy at hibernate.org  Mon Jul 20 15:37:43 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 20 Jul 2015 21:37:43 +0200
Subject: [hibernate-dev] Enum mapping in hbm.xml
In-Reply-To: <CAFdSV9vnn1g-2c3zzFNq5R--At9EpgwH39iRtOHHY5vtz9DuwQ@mail.gmail.com>
References: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>
	<B4FC230B-982E-41EC-AAF8-DCCC324D14B8@hibernate.org>
	<CAFdSV9tC3oow1fgiqNVyqmU__UPTTZK2zBPv5ZkSgXCGdt41Tw@mail.gmail.com>
	<CAFdSV9vnn1g-2c3zzFNq5R--At9EpgwH39iRtOHHY5vtz9DuwQ@mail.gmail.com>
Message-ID: <20150720193743.GB88611@Nineveh.lan>

Hi,

On Mon, Jul 20, 2015 at 05:36:30PM +0000, Steve Ebersole wrote:
> > As far as the default type, I don't feel that strongly.  Like I said, to
> > me neither is a really compelling way to map enums; names are only slightly
> > better that ordinals imo.  I am ok with the consistency aspect.

+1 for consistency with annotations

--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/20150720/ed54e482/attachment.bin 

From gbadner at redhat.com  Mon Jul 20 17:06:28 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 20 Jul 2015 17:06:28 -0400 (EDT)
Subject: [hibernate-dev]
	org.hibernate.jpa.AvailableSettings.EVENT_LISTENER_PREFIX
In-Reply-To: <210707196.1055420.1437424416953.JavaMail.zimbra@redhat.com>
Message-ID: <918929776.1077196.1437426388563.JavaMail.zimbra@redhat.com>

AvailableSettings.EVENT_LISTENER_PREFIX is set to "hibernate.ejb.event". JpaIntegrator looks for ConfigurationService settings (which include properties) with that prefix, then strips off that prefix to determine the org.hibernate.event.spi.EventType. 

I see that org.hibernate.event.spi.EventType has non-JPA event types. I can see that it could be useful for an application to specify non-JPA listeners to access Hibernate extensions. Is this what is intended?

Since JPA already defines annotations and <entity-listener> XML descriptors to specify JPA entity listeners/callbacks, should Hibernate continue to allow JPA entity listeners/callbacks to be specified using a property with this prefix? 

In master, the only test I see that uses a property prefixed with "hibernate.ejb.event" is org.hibernate.jpa.test.packaging.PackagedEntityManagerTest. Also, I don't see any documentation for prefixing properties this way.

Should AvailableSettings.EVENT_LISTENER_PREFIX be deprecated?

Thanks,
Gail


From gbadner at redhat.com  Mon Jul 20 17:07:25 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 20 Jul 2015 17:07:25 -0400 (EDT)
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAL00eSSvpsEjA=81TxrQuHRBLQ8s5MF=JTHvVT6fsJWtifAyJQ@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>
	<CAFdSV9vqURJiyc9Di=oMC1f+q-F7jx0MyfRjmthMOp7voiEqng@mail.gmail.com>
	<65940533.19312116.1436893564714.JavaMail.zimbra@redhat.com>
	<CAL00eST5mDp8t8N=dB59wRE5so4kTzc=07pr+5UOaA7jk4kvBg@mail.gmail.com>
	<CAFdSV9tk71A6ZT79i=3u05P0QZjRzgonDUULMEL15QqttMue=A@mail.gmail.com>
	<CAFdSV9uhExY=CcyKariXdQJh4nFe09F+=v7i=py4fX0k_kFo9Q@mail.gmail.com>
	<CAL00eSSvpsEjA=81TxrQuHRBLQ8s5MF=JTHvVT6fsJWtifAyJQ@mail.gmail.com>
Message-ID: <943702257.1077529.1437426445901.JavaMail.zimbra@redhat.com>

+1

----- Original Message -----
> From: "andrea boriero" <dreborier at gmail.com>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, July 20, 2015 8:22:51 AM
> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> 
> +1 for a dedicated room
> 
> On 20 July 2015 at 15:52, Steve Ebersole <steve at hibernate.org> wrote:
> 
> > Does it make sense to have a dedicated meeting room?  I wonder if the main
> > hibernate-orm room is too chatty; if the discussion would just immediately
> > get lost.
> >
> >
> > On Tue, Jul 14, 2015 at 1:07 PM Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> > > Ok, then lets plan on next Tuesday on HiptChat...
> > >
> > >
> > >
> > http://www.timeanddate.com/worldclock/fixedtime.html?msg=Hibernate+ORM+Triage+Meeting&iso=20150721T13&p1=24
> > >
> > >
> > > On Tue, Jul 14, 2015 at 12:32 PM andrea boriero <dreborier at gmail.com>
> > > wrote:
> > >
> > >> I have a problem on Monday but Tuesday is fine.
> > >>
> > >> On 14 July 2015 at 18:06, Gail Badner <gbadner at redhat.com> wrote:
> > >>
> > >>> Next week is fine. Monday or Tuesday work for me.
> > >>>
> > >>> ----- Original Message -----
> > >>> > From: "Steve Ebersole" <steve at hibernate.org>
> > >>> > To: "Gail Badner" <gbadner at redhat.com>
> > >>> > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <
> > >>> hibernate-dev at lists.jboss.org>
> > >>> > Sent: Monday, July 13, 2015 5:22:26 PM
> > >>> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >>> >
> > >>> > Now that 5.0 development is settling down, I think its time to go
> > >>> ahead and
> > >>> > start on this.  Should we start next week?  We never discussed a day.
> > >>> I am
> > >>> > thinking Monday or Tuesday.  Does that work for everyone interested?
> > >>> >
> > >>> > Ultimately the idea is for this meeting to address incoming HHH
> > issues.
> > >>> > But I realize the first few meetings might very well focus on past
> > >>> issues.
> > >>> >
> > >>> >
> > >>> > On Thu, Apr 16, 2015 at 8:16 AM Steve Ebersole <steve at hibernate.org>
> > >>> wrote:
> > >>> >
> > >>> > > Sometime after the next 5.0 release.  You know, after I have time
> > to
> > >>> > > breathe :)
> > >>> > >
> > >>> > > On Wed, Apr 15, 2015 at 5:06 PM, Gail Badner <gbadner at redhat.com>
> > >>> wrote:
> > >>> > >
> > >>> > >> When will we start having these meetings?
> > >>> > >>
> > >>> > >> ----- Original Message -----
> > >>> > >> > From: "Sanne Grinovero" <sanne at hibernate.org>
> > >>> > >> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >>> > >> > Sent: Monday, March 23, 2015 2:17:40 PM
> > >>> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >>> > >> >
> > >>> > >> > +1 it's a nice time to allow me to join occasionally as needed
> > >>> > >> >
> > >>> > >> > Sanne
> > >>> > >> >
> > >>> > >> > On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com>
> > >>> wrote:
> > >>> > >> > > 11am Seattle time would be ideal. Thanks!
> > >>> > >> > > Gail
> > >>> > >> > >
> > >>> > >> > > ----- Original Message -----
> > >>> > >> > >> From: "Brett Meyer" <brmeyer at redhat.com>
> > >>> > >> > >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >>> > >> > >> Sent: Monday, March 23, 2015 6:51:49 AM
> > >>> > >> > >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >>> > >> > >>
> > >>> > >> > >> Big +1 from me -- I'd be more than happy to be involved.
> > >>> > >> > >>
> > >>> > >> > >> ----- Original Message -----
> > >>> > >> > >> > From: "andrea boriero" <dreborier at gmail.com>
> > >>> > >> > >> > To: "Steve Ebersole" <steve at hibernate.org>
> > >>> > >> > >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >>> > >> > >> > Sent: Sunday, March 22, 2015 3:45:01 PM
> > >>> > >> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >>> > >> > >> >
> > >>> > >> > >> > for me at the moment it would be 6pm and it should be good.
> > >>> > >> > >> >
> > >>> > >> > >> > On 21 March 2015 at 21:08, Steve Ebersole <
> > >>> steve at hibernate.org>
> > >>> > >> wrote:
> > >>> > >> > >> >
> > >>> > >> > >> > > Gail and I discussed Jira a little bit last week and how
> > >>> to best
> > >>> > >> > >> > > manage
> > >>> > >> > >> > > scheduling issues.
> > >>> > >> > >> > >
> > >>> > >> > >> > > We both agreed that a team get together, either weekly or
> > >>> > >> > >> > > every-other-week,
> > >>> > >> > >> > > to discuss new issues to triage them would be a great
> > idea.
> > >>> > >> > >> > >
> > >>> > >> > >> > > One thing I absolutely do not want happening is just
> > >>> scheduling
> > >>> > >> issues
> > >>> > >> > >> > > as
> > >>> > >> > >> > > a
> > >>> > >> > >> > > means to come back and triage them later.  Scheduling an
> > >>> issue,
> > >>> > >> on a
> > >>> > >> > >> > > "real
> > >>> > >> > >> > > version" anyway, should mean something.  It should mean
> > >>> some
> > >>> > >> level of
> > >>> > >> > >> > > dedication to finish that task for that release.  In
> > short,
> > >>> > >> unless you
> > >>> > >> > >> > > are
> > >>> > >> > >> > > volunteering to take on a task *yourself* for that
> > release,
> > >>> > >> please do
> > >>> > >> > >> > > not
> > >>> > >> > >> > > schedule it for that release.
> > >>> > >> > >> > >
> > >>> > >> > >> > > As for the triage meeting, I would definitely like Gail
> > and
> > >>> > >> Andrea
> > >>> > >> > >> > > involved.  Of course anyone is welcome.  The reason I
> > >>> mention
> > >>> > >> this is
> > >>> > >> > >> > > that
> > >>> > >> > >> > > Gail is usually left on early side of scheduling these.
> > >>> So we
> > >>> > >> will
> > >>> > >> > >> > > find
> > >>> > >> > >> > > a
> > >>> > >> > >> > > time that works best for us 3 and go from there.  I
> > >>> recommend
> > >>> > >> that we
> > >>> > >> > >> > > leverage HipChat for these discussion.
> > >>> > >> > >> > >
> > >>> > >> > >> > > Andrea is coming to Austin for a few days starting
> > Monday,
> > >>> so I
> > >>> > >> would
> > >>> > >> > >> > > like
> > >>> > >> > >> > > to start this triaging while he is here.  Gail, I am
> > >>> thinking
> > >>> > >> 1pm my
> > >>> > >> > >> > > time
> > >>> > >> > >> > > (11am yours) would be a good time.  Andrea, does that
> > work
> > >>> for
> > >>> > >> you
> > >>> > >> > >> > > after
> > >>> > >> > >> > > Austin?
> > >>> > >> > >> > > _______________________________________________
> > >>> > >> > >> > > 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
> > >>> > >> > _______________________________________________
> > >>> > >> > 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From steve at hibernate.org  Mon Jul 20 17:59:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 20 Jul 2015 21:59:00 +0000
Subject: [hibernate-dev]
	org.hibernate.jpa.AvailableSettings.EVENT_LISTENER_PREFIX
In-Reply-To: <918929776.1077196.1437426388563.JavaMail.zimbra@redhat.com>
References: <210707196.1055420.1437424416953.JavaMail.zimbra@redhat.com>
	<918929776.1077196.1437426388563.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9tZ3mj24574mv9RPVRggJZteGUn51u7ONTKC=JnL5U+SA@mail.gmail.com>

2 very different things.

AvailableSettings.EVENT_LISTENER_PREFIX identifies Hibernate event
listeners that the user wants incorporated into the
org.hibernate.event.service.spi.EventListenerRegistry.
It does not name JPA listeners/callbacks; that is done through JPA specific
means via annotations.

So no, AvailableSettings.EVENT_LISTENER_PREFIX should not be deprecated.
In fact I am not even sure why you are asking that.  So either I completely
missed your point, or you did not explain why you thought it should be
removed.  I guess maybe you are blurring the distinction between the 2
concepts of callbacks?


On Mon, Jul 20, 2015 at 4:07 PM Gail Badner <gbadner at redhat.com> wrote:

> AvailableSettings.EVENT_LISTENER_PREFIX is set to "hibernate.ejb.event".
> JpaIntegrator looks for ConfigurationService settings (which include
> properties) with that prefix, then strips off that prefix to determine the
> org.hibernate.event.spi.EventType.
>
> I see that org.hibernate.event.spi.EventType has non-JPA event types. I
> can see that it could be useful for an application to specify non-JPA
> listeners to access Hibernate extensions. Is this what is intended?
>
> Since JPA already defines annotations and <entity-listener> XML
> descriptors to specify JPA entity listeners/callbacks, should Hibernate
> continue to allow JPA entity listeners/callbacks to be specified using a
> property with this prefix?
>
> In master, the only test I see that uses a property prefixed with
> "hibernate.ejb.event" is
> org.hibernate.jpa.test.packaging.PackagedEntityManagerTest. Also, I don't
> see any documentation for prefixing properties this way.
>
> Should AvailableSettings.EVENT_LISTENER_PREFIX be deprecated?
>
> Thanks,
> Gail
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Tue Jul 21 00:31:37 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 21 Jul 2015 00:31:37 -0400 (EDT)
Subject: [hibernate-dev]
 org.hibernate.jpa.AvailableSettings.EVENT_LISTENER_PREFIX
In-Reply-To: <CAFdSV9tZ3mj24574mv9RPVRggJZteGUn51u7ONTKC=JnL5U+SA@mail.gmail.com>
References: <210707196.1055420.1437424416953.JavaMail.zimbra@redhat.com>
	<918929776.1077196.1437426388563.JavaMail.zimbra@redhat.com>
	<CAFdSV9tZ3mj24574mv9RPVRggJZteGUn51u7ONTKC=JnL5U+SA@mail.gmail.com>
Message-ID: <1891305494.1235153.1437453097665.JavaMail.zimbra@redhat.com>

Ah, OK. I see.
Thanks,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>, "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Monday, July 20, 2015 2:59:00 PM
> Subject: Re: [hibernate-dev] org.hibernate.jpa.AvailableSettings.EVENT_LISTENER_PREFIX
> 
> 2 very different things.
> 
> AvailableSettings.EVENT_LISTENER_PREFIX identifies Hibernate event
> listeners that the user wants incorporated into the
> org.hibernate.event.service.spi.EventListenerRegistry.
> It does not name JPA listeners/callbacks; that is done through JPA specific
> means via annotations.
> 
> So no, AvailableSettings.EVENT_LISTENER_PREFIX should not be deprecated.
> In fact I am not even sure why you are asking that.  So either I completely
> missed your point, or you did not explain why you thought it should be
> removed.  I guess maybe you are blurring the distinction between the 2
> concepts of callbacks?
> 
> 
> On Mon, Jul 20, 2015 at 4:07 PM Gail Badner <gbadner at redhat.com> wrote:
> 
> > AvailableSettings.EVENT_LISTENER_PREFIX is set to "hibernate.ejb.event".
> > JpaIntegrator looks for ConfigurationService settings (which include
> > properties) with that prefix, then strips off that prefix to determine the
> > org.hibernate.event.spi.EventType.
> >
> > I see that org.hibernate.event.spi.EventType has non-JPA event types. I
> > can see that it could be useful for an application to specify non-JPA
> > listeners to access Hibernate extensions. Is this what is intended?
> >
> > Since JPA already defines annotations and <entity-listener> XML
> > descriptors to specify JPA entity listeners/callbacks, should Hibernate
> > continue to allow JPA entity listeners/callbacks to be specified using a
> > property with this prefix?
> >
> > In master, the only test I see that uses a property prefixed with
> > "hibernate.ejb.event" is
> > org.hibernate.jpa.test.packaging.PackagedEntityManagerTest. Also, I don't
> > see any documentation for prefixing properties this way.
> >
> > Should AvailableSettings.EVENT_LISTENER_PREFIX be deprecated?
> >
> > Thanks,
> > Gail
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

From gbadner at redhat.com  Tue Jul 21 01:13:14 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 21 Jul 2015 01:13:14 -0400 (EDT)
Subject: [hibernate-dev] Enum mapping in hbm.xml
In-Reply-To: <20150720193743.GB88611@Nineveh.lan>
References: <CAFdSV9uX2ZSoeUwuYYDvMkXXtkfOz6Wo7HdN_YBw+FkgKV6Vmg@mail.gmail.com>
	<B4FC230B-982E-41EC-AAF8-DCCC324D14B8@hibernate.org>
	<CAFdSV9tC3oow1fgiqNVyqmU__UPTTZK2zBPv5ZkSgXCGdt41Tw@mail.gmail.com>
	<CAFdSV9vnn1g-2c3zzFNq5R--At9EpgwH39iRtOHHY5vtz9DuwQ@mail.gmail.com>
	<20150720193743.GB88611@Nineveh.lan>
Message-ID: <1465585473.1241880.1437455594710.JavaMail.zimbra@redhat.com>

+1 from me as well.
Gail

----- Original Message -----
> From: "Hardy Ferentschik" <hardy at hibernate.org>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, July 20, 2015 12:37:43 PM
> Subject: Re: [hibernate-dev] Enum mapping in hbm.xml
> 
> Hi,
> 
> On Mon, Jul 20, 2015 at 05:36:30PM +0000, Steve Ebersole wrote:
> > > As far as the default type, I don't feel that strongly.  Like I said, to
> > > me neither is a really compelling way to map enums; names are only
> > > slightly
> > > better that ordinals imo.  I am ok with the consistency aspect.
> 
> +1 for consistency with annotations
> 
> --Hardy
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Tue Jul 21 07:03:13 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 21 Jul 2015 13:03:13 +0200
Subject: [hibernate-dev] Proposal for a Redis module in Hibernate OGM
In-Reply-To: <CAE-fDMt69N=1zDNiq+p-0rtiTvEFJov2F-z-1PjR66US6ombZg@mail.gmail.com>
References: <CAE-fDMt69N=1zDNiq+p-0rtiTvEFJov2F-z-1PjR66US6ombZg@mail.gmail.com>
Message-ID: <CADGJaX-aCXp_=seKVKv=Fo1QoyPf0bf+RHYGP0xvS1js-dK5sQ@mail.gmail.com>

Hi Mark,

Many thanks for giving this a try; Your work looks impressive, it's very
advanced for an initial dialect contribution, covering many advanced cases
already. So kudos for that!

Please find some remarks and questions below.

Cheers,

--Gunnar


2015-07-17 17:16 GMT+02:00 Mark Paluch <mpaluch at paluch.biz>:

> Hi there,
>
> I created a Redis module for Hibernate OGM, based on OGM 4.2. Redis is a
> Key-Value store supporting Lists, Hashes (Maps), Sorted Sets, ...
>
> I took the Infinispan/CouchDB approach storing entities and associations as
> JSON documents within Redis Hashes. A Map<Object, Map<Object, Object>>
> corresponds with a Redis Hash.
>
> The entity table maps to the Hash Id, the entity Id to the key of the hash
> and the set of columns is enclosed within a JSON (currently). Supported
> features are:
>
> * Composite Id's
> * Embedded associations
> * External associations
>

* I saw you create a hash per entity type, using the ids as keys within
this hash and a JSON document modelling the properties of a given entity
instance.

Have you considered to store JSON documents on the "top-level" instead?
This would require to encode the table name into the key as well (similar
to as we do it for CouchDB): "Order:123" -> ... . The reason I am asking is
that I am wondering whether it may be a source of contention and/or whether
it may pose scaling issues if all entities of one type are stored within a
single hash.

Using JSON for the actual entity contents seems reasonable and a common
approach in the Redis world from what I've read, so +1 for doing this from
me. How would the "more native" approach look like you describe below?
Would we have to serialise everything ourselves into String/byte[]? If so,
I am not sure whether that's of much usefulness actually and I'd be
inclined to go the JSON route exclusively. As you say, it also works nicely
for hierarchical structures.

* The id is used as key and also part of the JSON value. Could it be
removed from the latter?

* Do you have any ideas how Redis-specific structures could be exposed
which do not map exactly to entities, e.g. Lists stored directly via some
key?

* Our option system could be used to expose specific settings such as TTL
for given entities

* Is there any form of transaction support in Redis we could leverage?

and I guess many more, that I'm currently not aware of :-)
>
> There are various ways (JSON, Java-serialized simulating Documents) how to
> store data within Redis.
> Another approach could be storing Tuples within Redis more native, since
> they are in the end Maps, somehow. However, mapping tuples to Redis fit a
> native storage but raises questions about Id's, limited data type support
> (there is no equivalent for nested lists/maps). So the more native approach
> would require distributing data amongst various data types, depending on
> the supported features, and would require more IO's.
>
> My impl can be used to interoperate with other clients from the C, Ruby,
> Python, Node.js, ... worlds. The JSON is clean and does not look awkward on
> the first look.
>
> The current code can be found below
> https://github.com/mp911de/hibernate-ogm/tree/redis. Most TCK tests pass,
> only some 15 tests fail. Mostly due to enum and JTA support. Couldn't
> figure out, how to fix it, so need your help to figure it out.
>

I'll take a closer look at your change asap. Could you create a pull
request from your branch against the upstream repo? Then we can have a
discussion right there.

Hope, I made you hungry for the Redis OGM module. Let's start a discussion
> based on my proposal for inclusion and let's see, where we end up.
>

Yep, it looks very promising and I think it'd be great to have support for
Redis in OGM :) We'll need your continued help though to make it happen and
evolve it in the future as Redis itself and OGM core advance.

Best regards, Mark
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mpaluch at paluch.biz  Tue Jul 21 08:14:06 2015
From: mpaluch at paluch.biz (Mark Paluch)
Date: Tue, 21 Jul 2015 12:14:06 +0000
Subject: [hibernate-dev] Proposal for a Redis module in Hibernate OGM
In-Reply-To: <CADGJaX-aCXp_=seKVKv=Fo1QoyPf0bf+RHYGP0xvS1js-dK5sQ@mail.gmail.com>
References: <CAE-fDMt69N=1zDNiq+p-0rtiTvEFJov2F-z-1PjR66US6ombZg@mail.gmail.com>
	<CADGJaX-aCXp_=seKVKv=Fo1QoyPf0bf+RHYGP0xvS1js-dK5sQ@mail.gmail.com>
Message-ID: <CAE-fDMv5XJS0_TKtjL7vAjVLE2v2ocQJ4GKC878abvG_NW3nTw@mail.gmail.com>

Hi Gunnar,

thanks for your helpful feedback. I will come up with a PR as soon as we
agree on the strategies issue - well, perhaps in a couple days. I can and
will support you and I can help you with support/maintenance for the Redis
module in the future. I will have to ask you in return on some specific
issues, such as why enum-ordinals cannot be mapped back.

> * I saw you create a hash per entity type, using the ids as keys within
this hash and a JSON document modelling the properties of a given entity
instance.
>
> Have you considered to store JSON documents on the "top-level" instead?
This would require to encode the table name into the key as well (similar
to as we do it for CouchDB): "Order:123" -> ... . The reason I am asking is
that I am wondering whether it may be a source of contention and/or whether
it may pose scaling issues if all entities of one type are stored within a
single hash.

Yes, I was thinking about that issue. I ended up with the hash per entity
type in the first place. This is not a final thing, but rather a draft.
Pulling the JSON strategy to the global level is a good idea and key
patterns like "Order:123" are a recommended way. The top-level approach
tackles also another issue: Redis can be operated as a cluster in terms of
sharding. The sharding is key-based. A top-level key encourages a nice
distribution amongst the cluster. Cluster support is not yet included in my
code. I wanted to check with you guys first, whether a Redis module could
be included in OGM.

> Using JSON for the actual entity contents seems reasonable and a common
approach in the Redis world from what I've read, so +1 for doing this from
me. How would the "more native" approach look like you describe below?
Would we have to serialise everything ourselves into String/byte[]? If so,
I am not sure whether that's of much usefulness actually and I'd be
inclined to go the JSON route exclusively. As you say, it also works nicely
for hierarchical structures.

My first idea on the more native approach was storing all basic data types
as key-value pairs. I noticed, that embedded properties are transported
with dot-notation, which comes handy. Converting the properties to String
is also a common Redis style and interoperability between different
systems/languages is encouraged hereby. I'm just not sure, how to deal with
external and embedded associations. Simulating associations by distributing
the lists to Redis lists with referencing other hashes looks like an
overkill to Redis. A lot of meta-data would have to be held. Feasible Yes,
sensible No. The ROM framework (https://github.com/josiahcarlson/rom/) goes
for this approach.

So if omitting associations in the more native approach is not a
deal-breaker, I'd vote to go this way as well. I'm also fine if we start
with just the JSON approach.

> * The id is used as key and also part of the JSON value. Could it be
removed from the latter?
Yes, this is due to the draft state

> * Do you have any ideas how Redis-specific structures could be exposed
which do not map exactly to entities, e.g. Lists stored directly via some
key?

Yes. Redis-backed Collections, Maps, Locks, Queues, Caching, and many more
are possible. I'm not sure, whether you want to have that features because
they do not look like they fit the Hibernate OGM concept. There are
implementations (Redisson: https://github.com/mrniko/redisson, Spring Data
Redis:
https://github.com/spring-projects/spring-data-redis/tree/master/src/main/java/org/springframework/data/redis/support/collections)
that cover the Redis-backed Collections etc.


> * Our option system could be used to expose specific settings such as TTL
for given entities
Great! Redis supports TTL's, I was not aware of that OGM feature

> * Is there any form of transaction support in Redis we could leverage?
Yes. Redis supports transactions with the MULTI/EXEC/DISCARD commands.
Transactions require a connection affinity and imply the use of multiple
connections. That's nothing bad per se, just a thing to be aware of.

Thanks and best regards, Mark


Gunnar Morling <gunnar at hibernate.org> schrieb am Di., 21. Juli 2015 um
13:03 Uhr:

> Hi Mark,
>
> Many thanks for giving this a try; Your work looks impressive, it's very
> advanced for an initial dialect contribution, covering many advanced cases
> already. So kudos for that!
>
> Please find some remarks and questions below.
>
> Cheers,
>
> --Gunnar
>
>
> 2015-07-17 17:16 GMT+02:00 Mark Paluch <mpaluch at paluch.biz>:
>
>> Hi there,
>>
>> I created a Redis module for Hibernate OGM, based on OGM 4.2. Redis is a
>> Key-Value store supporting Lists, Hashes (Maps), Sorted Sets, ...
>>
>> I took the Infinispan/CouchDB approach storing entities and associations
>> as
>> JSON documents within Redis Hashes. A Map<Object, Map<Object, Object>>
>> corresponds with a Redis Hash.
>>
>> The entity table maps to the Hash Id, the entity Id to the key of the hash
>> and the set of columns is enclosed within a JSON (currently). Supported
>> features are:
>>
>> * Composite Id's
>> * Embedded associations
>> * External associations
>>
>
> * I saw you create a hash per entity type, using the ids as keys within
> this hash and a JSON document modelling the properties of a given entity
> instance.
>
> Have you considered to store JSON documents on the "top-level" instead?
> This would require to encode the table name into the key as well (similar
> to as we do it for CouchDB): "Order:123" -> ... . The reason I am asking is
> that I am wondering whether it may be a source of contention and/or whether
> it may pose scaling issues if all entities of one type are stored within a
> single hash.
>
> Using JSON for the actual entity contents seems reasonable and a common
> approach in the Redis world from what I've read, so +1 for doing this from
> me. How would the "more native" approach look like you describe below?
> Would we have to serialise everything ourselves into String/byte[]? If so,
> I am not sure whether that's of much usefulness actually and I'd be
> inclined to go the JSON route exclusively. As you say, it also works nicely
> for hierarchical structures.
>
> * The id is used as key and also part of the JSON value. Could it be
> removed from the latter?
>
> * Do you have any ideas how Redis-specific structures could be exposed
> which do not map exactly to entities, e.g. Lists stored directly via some
> key?
>
> * Our option system could be used to expose specific settings such as TTL
> for given entities
>
> * Is there any form of transaction support in Redis we could leverage?
>
> and I guess many more, that I'm currently not aware of :-)
>>
>> There are various ways (JSON, Java-serialized simulating Documents) how to
>> store data within Redis.
>> Another approach could be storing Tuples within Redis more native, since
>> they are in the end Maps, somehow. However, mapping tuples to Redis fit a
>> native storage but raises questions about Id's, limited data type support
>> (there is no equivalent for nested lists/maps). So the more native
>> approach
>> would require distributing data amongst various data types, depending on
>> the supported features, and would require more IO's.
>>
>> My impl can be used to interoperate with other clients from the C, Ruby,
>> Python, Node.js, ... worlds. The JSON is clean and does not look awkward
>> on
>> the first look.
>>
>> The current code can be found below
>> https://github.com/mp911de/hibernate-ogm/tree/redis. Most TCK tests pass,
>> only some 15 tests fail. Mostly due to enum and JTA support. Couldn't
>> figure out, how to fix it, so need your help to figure it out.
>>
>
> I'll take a closer look at your change asap. Could you create a pull
> request from your branch against the upstream repo? Then we can have a
> discussion right there.
>
> Hope, I made you hungry for the Redis OGM module. Let's start a discussion
>> based on my proposal for inclusion and let's see, where we end up.
>>
>
> Yep, it looks very promising and I think it'd be great to have support for
> Redis in OGM :) We'll need your continued help though to make it happen and
> evolve it in the future as Redis itself and OGM core advance.
>
> Best regards, Mark
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From emmanuel at hibernate.org  Tue Jul 21 10:16:30 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 21 Jul 2015 16:16:30 +0200
Subject: [hibernate-dev] [OGM] IRC meeting
Message-ID: <A4B99077-8A48-43B8-8C11-6020C62DC203@hibernate.org>

We discussed our current plan and progress including:

* planned migration to an ORM 5 based version (PR review). When is ORM psot CR2 going to be release?
* Neo4J 2.2 migration
* batch fetching
* Redis and ElasticSearch contributions
* German word of honor
* Gunnar needing to find the next priority for him (gridtype, mapping, something else) let us know.

Meeting ended Tue Jul 21 14:13:19 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.html
Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.txt
Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.log.html

From gunnar at hibernate.org  Tue Jul 21 10:22:56 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 21 Jul 2015 16:22:56 +0200
Subject: [hibernate-dev] ORM 5 Final - Release date and what's needed for OGM
Message-ID: <CADGJaX8rPAP6moJah+0XUL=0BSN1a9HKC0FM+Rw0sJTS_rXzrQ@mail.gmail.com>

Steve, all,

What's the planned for release date for ORM 5 Final?

For OGM, we'd need at least one post-CR2 fix, HHH-9906 (apply auto-quoting
setting correctly, [1]). That's already on master and I think it's small
enough to fall under a slightly relaxed "Final = Retagged last CR" policy.

In addition, a fix for HHH-9923 (Avoid cast to MetadataBuildingOptionsImpl
in AnnotationMetadataSourceProcessorImpl#prepare(), [2]) would be great.
It's no blocker for OGM atm. but it'll allow us to actually plug in custom
MetadataBuilders down the road.

Finally there is the potential issue around element collection column
naming I brought up recently [3]; I think I've found a good enough
work-around on the OGM side, but I feel this may better be fixed in ORM. As
is, no blocker from my POV, but an answer on this subject would be nice :)

Thanks,

--Gunnar

[1] https://hibernate.atlassian.net/browse/HHH-9906
[2] https://hibernate.atlassian.net/browse/HHH-9923
[3] http://lists.jboss.org/pipermail/hibernate-dev/2015-July/013076.html

From steve at hibernate.org  Tue Jul 21 11:33:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 21 Jul 2015 15:33:37 +0000
Subject: [hibernate-dev] Naming strategies and collection element columns
In-Reply-To: <CADGJaX8OAvtXdB=S_827ZEaJ_kyACJ_jM6wWA1uxM7e9DLzZ1A@mail.gmail.com>
References: <CADGJaX8OAvtXdB=S_827ZEaJ_kyACJ_jM6wWA1uxM7e9DLzZ1A@mail.gmail.com>
Message-ID: <CAFdSV9s85hAAcP5Hczfc8thDEWxbAoBDm1L2ttrSJzEhNtF40w@mail.gmail.com>

In theory yes.  You are free to try and interpret all this lovely
annotation binding logic and make that do the right thing :)



On Fri, Jul 17, 2015 at 8:54 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Steve,
>
> There is one remaining itch I have wrt. upgrading OGM to ORM 5.
>
> I have an entity GrandMother with an @ElementCollection "grandChildren" of
> type GrandChild. The latter has a property "name" which used to be passed
> as "grandChildren.collection&&element.name" to OGM's
> NamingStrategy#propertyToColumnName(). We used to detect the
> "collection&&element" pattern to determine the right column name fin OGM.
>
> As of ORM 5, this is passed as "grandChildren.name" instead (due to
> HHH-6005 [1]). Now I thought
> ImplicitBasicColumnNameSource#isCollectionElement() would tell me whether
> this is a collection element, but it returns false in this case.
>
> Shouldn't it return true if the replacement magic for HHH-6005 has kicked
> in Ejb3Column#redefineColumnName()?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/HHH-6005
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jul 21 12:41:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 21 Jul 2015 16:41:44 +0000
Subject: [hibernate-dev] Another Jira feature removal
Message-ID: <CAFdSV9spkVf8Hyn=OcoQu9fccw7KqfCYknY1fY=rgbGGVf414Q@mail.gmail.com>

Public announcement service
According to our logs, a Cloud Connector integration with another product
is active on your instance. These connectors are no longer supported and
will be removed from JIRA on 27 July. Please refer to the below link for
migration details.

More information
<https://confluence.atlassian.com/display/JIRAKB/Cloud+connectors+removal+in+JIRA+Cloud>


I do not know what Cloud Connector we use.  I looked at the link, but we do
not use any of those...  maybe our old Fisheye intg is still active?

From steve at hibernate.org  Tue Jul 21 13:35:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 21 Jul 2015 17:35:31 +0000
Subject: [hibernate-dev] ORM - location of generated sources
In-Reply-To: <CADGJaX_E7YmB_BuP=e1OwYqbhSJasaffKU6dwChV+c++=0B4Rg@mail.gmail.com>
References: <CADGJaX_E7YmB_BuP=e1OwYqbhSJasaffKU6dwChV+c++=0B4Rg@mail.gmail.com>
Message-ID: <CAFdSV9tyR4abvDrHCD8-X9aXRnOYiAqhJTM8hk4-fF0zba_1=g@mail.gmail.com>

As far as I know there is no way to control this at the moment:
https://discuss.gradle.org/t/antlr-plugin-should-preserve-package-structure/10153

For me it ends up in the right place even in terms of the compiled classes,
not just the jar.

On Mon, Jul 20, 2015 at 1:50 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> The build for hibernate-core generates sources using Antlr which end up in
> target/generated-src/antlr/main, e.g. GeneratedOrderByFragmentParser.java.
>
> The weird thing is that the generated files are located right within this
> directory, i.e.  there is *no* directory hierarchy resembling the package
> structure. The files have package declarations such as
> "org.hibernate.sql.ordering.antlr", though.
>
> Apparently, this works in the Gradle build (no errors due to that), but in
> my IDE I am getting tons of compile errors due to the mismatch of package
> declaration and file location. Interestingly, the files also end up in the
> right place in the hibernate-core.jar, so I assume that there is some Magic
> in place at the Gradle level which deals with that stuff.
>
> Does anyone know how to make it work in the IDE as well?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jul 21 14:01:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 21 Jul 2015 18:01:50 +0000
Subject: [hibernate-dev] ORM 5 Final - Release date and what's needed
	for OGM
In-Reply-To: <CADGJaX8rPAP6moJah+0XUL=0BSN1a9HKC0FM+Rw0sJTS_rXzrQ@mail.gmail.com>
References: <CADGJaX8rPAP6moJah+0XUL=0BSN1a9HKC0FM+Rw0sJTS_rXzrQ@mail.gmail.com>
Message-ID: <CAFdSV9tc=kDseFbi5+zmdNcPgOtFj9D60zSJomMFkj=zLjcY7Q@mail.gmail.com>

As far as a date, I will see after today's triage meeting.

As far as what that release would be, I need to go back and look at all the
work committed against master so far since CR2 to see if anything warrants
another CR or if I feel comfortable cutting a Final based on those extras.

I have commented on HHH-9923.  Need some feedback.

And I commented on [3] earlier.

On Tue, Jul 21, 2015 at 9:23 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Steve, all,
>
> What's the planned for release date for ORM 5 Final?
>
> For OGM, we'd need at least one post-CR2 fix, HHH-9906 (apply auto-quoting
> setting correctly, [1]). That's already on master and I think it's small
> enough to fall under a slightly relaxed "Final = Retagged last CR" policy.
>
> In addition, a fix for HHH-9923 (Avoid cast to MetadataBuildingOptionsImpl
> in AnnotationMetadataSourceProcessorImpl#prepare(), [2]) would be great.
> It's no blocker for OGM atm. but it'll allow us to actually plug in custom
> MetadataBuilders down the road.
>
> Finally there is the potential issue around element collection column
> naming I brought up recently [3]; I think I've found a good enough
> work-around on the OGM side, but I feel this may better be fixed in ORM. As
> is, no blocker from my POV, but an answer on this subject would be nice :)
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/HHH-9906
> [2] https://hibernate.atlassian.net/browse/HHH-9923
> [3] http://lists.jboss.org/pipermail/hibernate-dev/2015-July/013076.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Tue Jul 21 15:47:13 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 21 Jul 2015 21:47:13 +0200
Subject: [hibernate-dev] ORM - Download of DTD failed
In-Reply-To: <CADGJaX9gHkYX1pzUejT7ZHi1Xh-ykb_9fwWrx=n2Br5NhVnEUQ@mail.gmail.com>
References: <CADGJaX8m9=1Ukxuf27ctabp=SPL-jjKhuhJC2UWYmJTiMZHnkw@mail.gmail.com>
	<CAFdSV9txOWqcrpT1KQG77noP+KFDRBrR-9-7FFCJMUJh7CY+sg@mail.gmail.com>
	<CADGJaX9gHkYX1pzUejT7ZHi1Xh-ykb_9fwWrx=n2Br5NhVnEUQ@mail.gmail.com>
Message-ID: <20150721194713.GF29353@Nineveh.lan>

Hi,

just attempted a full built of ORM and got this as part of the documentation build:

Error at xsl:import on line 4 of jar:file:/Users/hardy/.gradle/caches/modules-2/files-2.1/org.jboss.pressgang/pressgang-xslt-ns/3.0.0/d98c5f6ef7d69dd33a3ad45656f6640100e8fc82/pressgang-xslt-ns-3.0.0.jar!/xslt/org/jboss/pressgang/xhtml.xsl:
  Failure reading http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/chunk.xsl: Server returned HTTP response code: 503 for URL: http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/chunk.xsl
Error at xsl:if on line 14 of file:/Users/hardy/work/hibernate/git/core/orm/documentation/target/docbook/stage/devguide/xslt/org/hibernate/jdocbook/xslt/common-base.xsl:
  Variable img.src.path has not been declared
Error at xsl:value-of on line 15 of file:/Users/hardy/work/hibernate/git/core/orm/documentation/target/docbook/stage/devguide/xslt/org/hibernate/jdocbook/xslt/common-base.xsl:
  Variable img.src.path has not been declared
:documentation:renderDocBook_devguide_en-US_html FAILED

Looks like another problem with external dtd/xsl verification. Probably nothing we have direct control over. Just wanted to give the heads up.
AFAIK Sourceforge is still having problems after their major meltdown. I am still not able to upload the Validator release.

--Hardy 

On Mon, Jul 20, 2015 at 03:55:16PM +0200, Gunnar Morling wrote:
> Ah yes; I had pulled, that's why I couldn't reproduce this issue locally :)
> Thanks for fixing it!
> 
> 2015-07-20 14:13 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> 
> > Pull again :)  I fixed this yesterday.  We were missing the SourceForge
> > url for local resolution of the CFG DTD
> >
> > On Mon, Jul 20, 2015, 3:30 AM Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> >> Hi,
> >>
> >> I noticed an interesting failure of HibernateCacheTest from the
> >> "hibernate-ehcache" module in a recent ORM CI build [1].
> >>
> >> It failed to obtain hibernate-configuration-3.0.dtd from SourceForge
> >> (there
> >> was some service outage at SF at this time). Apart from the fact that the
> >> test uses the legacy URL (I'll fix that), I am wondering why the config
> >> parser tried to obtain the DTD remotely in the first place. We have
> >> LocalXmlResourceResolver in place which is there to prevent this. An
> >> indeed
> >> if I debug the test locally, I don't get to the place where it would
> >> download it from remote.
> >>
> >> Anyone with an idea why that would happen on CI?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> >> [1]
> >>
> >> http://ci.hibernate.org/job/hibernate-orm-master-h2/988/testReport/junit/org.hibernate.test.cache/HibernateCacheTest/classMethod/
> >> _______________________________________________
> >> 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
-------------- 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/20150721/c8fa3689/attachment.bin 

From sanne at hibernate.org  Tue Jul 21 19:02:17 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 22 Jul 2015 02:02:17 +0300
Subject: [hibernate-dev] MariaDB on CI
In-Reply-To: <CAFdSV9twdX6qVom-B490HqH3--=Kt1pKGQrqg7ZgMU=1qQ6i7w@mail.gmail.com>
References: <CAFdSV9vaAWQbE9HO0qz04FyTJ9dXPimS6VmWab+zA=Rz12NVFw@mail.gmail.com>
	<CAFm4XO33Hf0fX2ckB_t1zpPt8oZdXPstmxB0EG4j+rphaQ-ruQ@mail.gmail.com>
	<CAFdSV9twdX6qVom-B490HqH3--=Kt1pKGQrqg7ZgMU=1qQ6i7w@mail.gmail.com>
Message-ID: <CAFm4XO1mrw5wVKyvhAKED=qwrg_+kKFFj19yHnu_ut3+9UgcXA@mail.gmail.com>

On 20 July 2015 at 17:41, Steve Ebersole <steve at hibernate.org> wrote:
> Sanne for MariaDB (and MySQL if we ever add it) we need to add at least one
> more setting:
>
> sql-mode="traditional"

I've applied this change.

--Sanne

>
> We could probably get away with less ANSI compliant mode, but after days
> playing with this I just want to cover my bases :)
>
> On Sat, Jul 18, 2015 at 3:37 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Thanks, great suggestions!
>> I've applied these and some more.
>>
>> The MariaDB configuration:
>>  -
>> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/mariadb-server/files/my.cnf
>>
>> The PosgreSQL configuration files:
>>  -
>> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/pg_hba.conf
>>  -
>> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/postgresql.conf
>>
>> Both are running with these settings now on each CI slave.
>> Sanne
>>
>> On 18 July 2015 at 00:49, Steve Ebersole <steve at hibernate.org> wrote:
>> > [18:45] <sebersole> whoa..
>> > [18:45] <sebersole> sannegrinovero: we definitely need this for mariadb
>> > on
>> > ci...
>> > [18:46] <sebersole> sync_binlog=0 innodb_flush_log_at_trx_commit=0
>> > innodb_doublewrite=0
>> > [18:46] <sebersole> tests were much faster
>> >
>> > These were suggested to me on the #mariadb list.  I added them to my
>> > local
>> > /etc/my.cnf file and the tests were significantly faster.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Wed Jul 22 01:08:28 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 22 Jul 2015 01:08:28 -0400 (EDT)
Subject: [hibernate-dev]
	org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest
In-Reply-To: <409232269.1861332.1437541321515.JavaMail.zimbra@redhat.com>
Message-ID: <364013595.1863749.1437541708224.JavaMail.zimbra@redhat.com>

I think this is probably just a bug in the test, but I want to mention it in case there is a real bug here.

When I run the unit tests multiple times, sometimes I see WarehouseItem created with:

    create table WarehouseItem (
        id integer generated by default as identity,
        version integer not null,
        qtyInStock decimal(19,2),
        vendor_id integer,
        item_id integer,
        primary key (id)
    )

Sometimes WarehouseItem is created with:
    create table WarehouseItem (
        id integer generated by default as identity,
        version integer not null,
        qtyInStock decimal(19,2),
        ITEM_ID integer not null,
        VENDOR_ID integer not null,
        primary key (id)
    )

I started seeing this only recently (last couple of weeks or so). 

In the WarehouseItem class [1], the following join column names are specified: vendor_id, VENDOR_ID, item_id, ITEM_ID.

I'm sure that making the column names consistent (upper or lower) case would make the table DDL consistent. I want to make sure I don't mask a real bug by making this change.

Is this a bug in the test, or a bug in how column names are processed?

[1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/annotations/manytoone/referencedcolumnname/WarehouseItem.java


From gbadner at redhat.com  Wed Jul 22 01:17:10 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 22 Jul 2015 01:17:10 -0400 (EDT)
Subject: [hibernate-dev]
	org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest
In-Reply-To: <364013595.1863749.1437541708224.JavaMail.zimbra@redhat.com>
References: <364013595.1863749.1437541708224.JavaMail.zimbra@redhat.com>
Message-ID: <1329569774.1865719.1437542230959.JavaMail.zimbra@redhat.com>

BTW, I was not able to reproduce this by running the test repeatedly in Intellij. I saw the differences when comparing SQL/DDL from running the hibernate-core unit tests multiple times.

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Tuesday, July 21, 2015 10:08:28 PM
> Subject: [hibernate-dev]
> 	org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest
> 
> I think this is probably just a bug in the test, but I want to mention it in
> case there is a real bug here.
> 
> When I run the unit tests multiple times, sometimes I see WarehouseItem
> created with:
> 
>     create table WarehouseItem (
>         id integer generated by default as identity,
>         version integer not null,
>         qtyInStock decimal(19,2),
>         vendor_id integer,
>         item_id integer,
>         primary key (id)
>     )
> 
> Sometimes WarehouseItem is created with:
>     create table WarehouseItem (
>         id integer generated by default as identity,
>         version integer not null,
>         qtyInStock decimal(19,2),
>         ITEM_ID integer not null,
>         VENDOR_ID integer not null,
>         primary key (id)
>     )
> 
> I started seeing this only recently (last couple of weeks or so).
> 
> In the WarehouseItem class [1], the following join column names are
> specified: vendor_id, VENDOR_ID, item_id, ITEM_ID.
> 
> I'm sure that making the column names consistent (upper or lower) case would
> make the table DDL consistent. I want to make sure I don't mask a real bug
> by making this change.
> 
> Is this a bug in the test, or a bug in how column names are processed?
> 
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/annotations/manytoone/referencedcolumnname/WarehouseItem.java
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From sanne at hibernate.org  Wed Jul 22 02:47:56 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 22 Jul 2015 09:47:56 +0300
Subject: [hibernate-dev] [OGM] IRC meeting
In-Reply-To: <A4B99077-8A48-43B8-8C11-6020C62DC203@hibernate.org>
References: <A4B99077-8A48-43B8-8C11-6020C62DC203@hibernate.org>
Message-ID: <CAFm4XO1tKQnCeBNZ9y6u8Wgy2DKZUQPCaxXjnraqe8duQ0X57Q@mail.gmail.com>

Hi all,
thanks for the log, and sorry for the silence: it's very hard to find
a minute of the day in which the wi-fi actually works here.

I'd be happy to work on the ES backend, but it was my impression that
the Infinispan / hot rod one was an higher strategical priority?
Playing with ES would be a nice choice for me as I need to familiarize
with it for Hibernate Search too.

I'll send a separate email to start some brainstorming on the Hot Rod
dialect, I'm afraid it will need some exploring.

Thanks,
Sanne



On 21 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> We discussed our current plan and progress including:
>
> * planned migration to an ORM 5 based version (PR review). When is ORM psot CR2 going to be release?
> * Neo4J 2.2 migration
> * batch fetching
> * Redis and ElasticSearch contributions
> * German word of honor
> * Gunnar needing to find the next priority for him (gridtype, mapping, something else) let us know.
>
> Meeting ended Tue Jul 21 14:13:19 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
> Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.html
> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.txt
> Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.log.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Jul 22 02:54:32 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 22 Jul 2015 08:54:32 +0200
Subject: [hibernate-dev] [OGM] IRC meeting
In-Reply-To: <CAFm4XO1tKQnCeBNZ9y6u8Wgy2DKZUQPCaxXjnraqe8duQ0X57Q@mail.gmail.com>
References: <A4B99077-8A48-43B8-8C11-6020C62DC203@hibernate.org>
	<CAFm4XO1tKQnCeBNZ9y6u8Wgy2DKZUQPCaxXjnraqe8duQ0X57Q@mail.gmail.com>
Message-ID: <CADGJaX_LgNuAR8pnYq57V2n=rB8AHu5NVJPiAzJwo78BFetvvQ@mail.gmail.com>

2015-07-22 8:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi all,
> thanks for the log, and sorry for the silence: it's very hard to find
> a minute of the day in which the wi-fi actually works here.
>

Yeah, I can imagine it's a tough challenge to get connection on the sunny
beaches of Crete ;)

I'd be happy to work on the ES backend, but it was my impression that
> the Infinispan / hot rod one was an higher strategical priority?
> Playing with ES would be a nice choice for me as I need to familiarize
> with it for Hibernate Search too.
>

+1 for doing ISPN remote with highest prio. My hope still is you could take
a look at this PR (it's rather small) in parallel. I don't think you really
need to "work" on the ES backend, just give the contributor some feedback.
I also plan to give a look at it, in order to get acquainted with ES.

I'll send a separate email to start some brainstorming on the Hot Rod
> dialect, I'm afraid it will need some exploring.
>

+1 Looking forward to that.

Thanks,
> Sanne
>
>
>
> On 21 July 2015 at 17:16, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > We discussed our current plan and progress including:
> >
> > * planned migration to an ORM 5 based version (PR review). When is ORM
> psot CR2 going to be release?
> > * Neo4J 2.2 migration
> > * batch fetching
> > * Redis and ElasticSearch contributions
> > * German word of honor
> > * Gunnar needing to find the next priority for him (gridtype, mapping,
> something else) let us know.
> >
> > Meeting ended Tue Jul 21 14:13:19 2015 UTC.  Information about MeetBot
> at http://wiki.debian.org/MeetBot . (v 0.1.4)
> > Minutes:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.html
> > Minutes (text):
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.txt
> > Log:
> http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-07-21-13.02.log.html
> > _______________________________________________
> > 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 gunnar at hibernate.org  Wed Jul 22 03:24:58 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 22 Jul 2015 09:24:58 +0200
Subject: [hibernate-dev] ORM - Download of DTD failed
In-Reply-To: <20150721194713.GF29353@Nineveh.lan>
References: <CADGJaX8m9=1Ukxuf27ctabp=SPL-jjKhuhJC2UWYmJTiMZHnkw@mail.gmail.com>
	<CAFdSV9txOWqcrpT1KQG77noP+KFDRBrR-9-7FFCJMUJh7CY+sg@mail.gmail.com>
	<CADGJaX9gHkYX1pzUejT7ZHi1Xh-ykb_9fwWrx=n2Br5NhVnEUQ@mail.gmail.com>
	<20150721194713.GF29353@Nineveh.lan>
Message-ID: <CADGJaX_r=_PLyO_w4397zSE-T1bXC+Ua-17Owg_BimSF6fLNMA@mail.gmail.com>

Indeed this XSL file includes another one from SourceForge. I've filed
https://github.com/pressgang/pressgang-tools/issues/3 to replace it with a
local copy. Not sure how that stuff works internally, probably one would
have to unpack the DockBook dependency and refer to its XSL files locally.


2015-07-21 21:47 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:

> Hi,
>
> just attempted a full built of ORM and got this as part of the
> documentation build:
>
> Error at xsl:import on line 4 of
> jar:file:/Users/hardy/.gradle/caches/modules-2/files-2.1/org.jboss.pressgang/pressgang-xslt-ns/3.0.0/d98c5f6ef7d69dd33a3ad45656f6640100e8fc82/pressgang-xslt-ns-3.0.0.jar!/xslt/org/jboss/pressgang/xhtml.xsl:
>   Failure reading
> http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/chunk.xsl: Server
> returned HTTP response code: 503 for URL:
> http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/chunk.xsl
> Error at xsl:if on line 14 of
> file:/Users/hardy/work/hibernate/git/core/orm/documentation/target/docbook/stage/devguide/xslt/org/hibernate/jdocbook/xslt/common-base.xsl:
>   Variable img.src.path has not been declared
> Error at xsl:value-of on line 15 of
> file:/Users/hardy/work/hibernate/git/core/orm/documentation/target/docbook/stage/devguide/xslt/org/hibernate/jdocbook/xslt/common-base.xsl:
>   Variable img.src.path has not been declared
> :documentation:renderDocBook_devguide_en-US_html FAILED
>
> Looks like another problem with external dtd/xsl verification. Probably
> nothing we have direct control over. Just wanted to give the heads up.
> AFAIK Sourceforge is still having problems after their major meltdown. I
> am still not able to upload the Validator release.
>
> --Hardy
>
> On Mon, Jul 20, 2015 at 03:55:16PM +0200, Gunnar Morling wrote:
> > Ah yes; I had pulled, that's why I couldn't reproduce this issue locally
> :)
> > Thanks for fixing it!
> >
> > 2015-07-20 14:13 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >
> > > Pull again :)  I fixed this yesterday.  We were missing the SourceForge
> > > url for local resolution of the CFG DTD
> > >
> > > On Mon, Jul 20, 2015, 3:30 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> > >
> > >> Hi,
> > >>
> > >> I noticed an interesting failure of HibernateCacheTest from the
> > >> "hibernate-ehcache" module in a recent ORM CI build [1].
> > >>
> > >> It failed to obtain hibernate-configuration-3.0.dtd from SourceForge
> > >> (there
> > >> was some service outage at SF at this time). Apart from the fact that
> the
> > >> test uses the legacy URL (I'll fix that), I am wondering why the
> config
> > >> parser tried to obtain the DTD remotely in the first place. We have
> > >> LocalXmlResourceResolver in place which is there to prevent this. An
> > >> indeed
> > >> if I debug the test locally, I don't get to the place where it would
> > >> download it from remote.
> > >>
> > >> Anyone with an idea why that would happen on CI?
> > >>
> > >> Thanks,
> > >>
> > >> --Gunnar
> > >>
> > >> [1]
> > >>
> > >>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/988/testReport/junit/org.hibernate.test.cache/HibernateCacheTest/classMethod/
> > >> _______________________________________________
> > >> 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 gunnar at hibernate.org  Wed Jul 22 03:34:14 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 22 Jul 2015 09:34:14 +0200
Subject: [hibernate-dev] ORM - location of generated sources
In-Reply-To: <CAFdSV9tyR4abvDrHCD8-X9aXRnOYiAqhJTM8hk4-fF0zba_1=g@mail.gmail.com>
References: <CADGJaX_E7YmB_BuP=e1OwYqbhSJasaffKU6dwChV+c++=0B4Rg@mail.gmail.com>
	<CAFdSV9tyR4abvDrHCD8-X9aXRnOYiAqhJTM8hk4-fF0zba_1=g@mail.gmail.com>
Message-ID: <CADGJaX_ki041Yg3aYxTes5YZx9T+3g4f8+YM=Ye+icKV1OQeVw@mail.gmail.com>

Ok, thanks for pointing to that issue.

Would be very interesting to know why/how it still works on the class level
for Gradle. Actually, Java does not mandate the nested directory structure
where a package is represented by a folder (the spec vaguely mentions
alternatives such as a DB-based source repository, or one also could use
"com.example.mypackage" as folder name), but of course the compiler must
support such alternative representations. Not sure how they make that
happen in Gradle ;)

2015-07-21 19:35 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> As far as I know there is no way to control this at the moment:
> https://discuss.gradle.org/t/antlr-plugin-should-preserve-package-structure/10153
>
> For me it ends up in the right place even in terms of the compiled
> classes, not just the jar.
>
> On Mon, Jul 20, 2015 at 1:50 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi,
>>
>> The build for hibernate-core generates sources using Antlr which end up in
>> target/generated-src/antlr/main, e.g. GeneratedOrderByFragmentParser.java.
>>
>> The weird thing is that the generated files are located right within this
>> directory, i.e.  there is *no* directory hierarchy resembling the package
>> structure. The files have package declarations such as
>> "org.hibernate.sql.ordering.antlr", though.
>>
>> Apparently, this works in the Gradle build (no errors due to that), but in
>> my IDE I am getting tons of compile errors due to the mismatch of package
>> declaration and file location. Interestingly, the files also end up in the
>> right place in the hibernate-core.jar, so I assume that there is some
>> Magic
>> in place at the Gradle level which deals with that stuff.
>>
>> Does anyone know how to make it work in the IDE as well?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From emmanuel at hibernate.org  Wed Jul 22 04:40:37 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 22 Jul 2015 10:40:37 +0200
Subject: [hibernate-dev]
	org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest
In-Reply-To: <364013595.1863749.1437541708224.JavaMail.zimbra@redhat.com>
References: <364013595.1863749.1437541708224.JavaMail.zimbra@redhat.com>
Message-ID: <2D47DDD6-9E68-4670-8975-42E51F472866@hibernate.org>

I?d say it?s fair to ask the user to use consistent column naming so that would be a bug in the test.

> On 22 Jul 2015, at 07:08, Gail Badner <gbadner at redhat.com> wrote:
> 
> I think this is probably just a bug in the test, but I want to mention it in case there is a real bug here.
> 
> When I run the unit tests multiple times, sometimes I see WarehouseItem created with:
> 
>    create table WarehouseItem (
>        id integer generated by default as identity,
>        version integer not null,
>        qtyInStock decimal(19,2),
>        vendor_id integer,
>        item_id integer,
>        primary key (id)
>    )
> 
> Sometimes WarehouseItem is created with:
>    create table WarehouseItem (
>        id integer generated by default as identity,
>        version integer not null,
>        qtyInStock decimal(19,2),
>        ITEM_ID integer not null,
>        VENDOR_ID integer not null,
>        primary key (id)
>    )
> 
> I started seeing this only recently (last couple of weeks or so). 
> 
> In the WarehouseItem class [1], the following join column names are specified: vendor_id, VENDOR_ID, item_id, ITEM_ID.
> 
> I'm sure that making the column names consistent (upper or lower) case would make the table DDL consistent. I want to make sure I don't mask a real bug by making this change.
> 
> Is this a bug in the test, or a bug in how column names are processed?
> 
> [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/annotations/manytoone/referencedcolumnname/WarehouseItem.java
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Wed Jul 22 04:41:12 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 22 Jul 2015 10:41:12 +0200
Subject: [hibernate-dev] Proposal for a Redis module in Hibernate OGM
In-Reply-To: <CAE-fDMv5XJS0_TKtjL7vAjVLE2v2ocQJ4GKC878abvG_NW3nTw@mail.gmail.com>
References: <CAE-fDMt69N=1zDNiq+p-0rtiTvEFJov2F-z-1PjR66US6ombZg@mail.gmail.com>
	<CADGJaX-aCXp_=seKVKv=Fo1QoyPf0bf+RHYGP0xvS1js-dK5sQ@mail.gmail.com>
	<CAE-fDMv5XJS0_TKtjL7vAjVLE2v2ocQJ4GKC878abvG_NW3nTw@mail.gmail.com>
Message-ID: <CADGJaX8AnrBzEKDLA655_shFA-5uQXY_DDgyTcbp36bpf2JAUQ@mail.gmail.com>

2015-07-21 14:14 GMT+02:00 Mark Paluch <mpaluch at paluch.biz>:

> Hi Gunnar,
>
> thanks for your helpful feedback. I will come up with a PR as soon as we
> agree on the strategies issue - well, perhaps in a couple days. I can and
> will support you and I can help you with support/maintenance for the Redis
> module in the future.
>

That's great to hear. We are no Redis experts, so the help of one is needed
to make this fly :)


> I will have to ask you in return on some specific issues, such as why
> enum-ordinals cannot be mapped back.
>

Sure, absolutely. I will take a look at the enum thingy.


> > * I saw you create a hash per entity type, using the ids as keys within
> this hash and a JSON document modelling the properties of a given entity
> instance.
> >
> > Have you considered to store JSON documents on the "top-level" instead?
> This would require to encode the table name into the key as well (similar
> to as we do it for CouchDB): "Order:123" -> ... . The reason I am asking is
> that I am wondering whether it may be a source of contention and/or whether
> it may pose scaling issues if all entities of one type are stored within a
> single hash.
>
> Yes, I was thinking about that issue. I ended up with the hash per entity
> type in the first place. This is not a final thing, but rather a draft.
> Pulling the JSON strategy to the global level is a good idea and key
> patterns like "Order:123" are a recommended way. The top-level approach
> tackles also another issue: Redis can be operated as a cluster in terms of
> sharding. The sharding is key-based. A top-level key encourages a nice
> distribution amongst the cluster. Cluster support is not yet included in my
> code. I wanted to check with you guys first, whether a Redis module could
> be included in OGM.
>

Yes, clustering was part of my concern with the original approach. The
top-level approach would help with that.

>
> > Using JSON for the actual entity contents seems reasonable and a common
> approach in the Redis world from what I've read, so +1 for doing this from
> me. How would the "more native" approach look like you describe below?
> Would we have to serialise everything ourselves into String/byte[]? If so,
> I am not sure whether that's of much usefulness actually and I'd be
> inclined to go the JSON route exclusively. As you say, it also works nicely
> for hierarchical structures.
>
> My first idea on the more native approach was storing all basic data types
> as key-value pairs. I noticed, that embedded properties are transported
> with dot-notation, which comes handy. Converting the properties to String
> is also a common Redis style and interoperability between different
> systems/languages is encouraged hereby.
>

Are there conventions for mapping more complex types such as Date for
instance? You'd need custom GridTypes to map everything into String (we
have String-mapping implementations for some types such as Date and Long,
but not for all of them).


> I'm just not sure, how to deal with external and embedded associations.
> Simulating associations by distributing the lists to Redis lists with
> referencing other hashes looks like an overkill to Redis. A lot of
> meta-data would have to be held. Feasible Yes, sensible No. The ROM
> framework (https://github.com/josiahcarlson/rom/) goes for this approach.
>
> So if omitting associations in the more native approach is not a
> deal-breaker, I'd vote to go this way as well.
>

Not supporting associations at all in that mode seems like a heavy
limitation to me. I am not sure what you mean by "lot of meta-data would
have to be held"; Where, in the driver, or in the dialect? OGM engine
should give you all you need, I suggest to check out the Infinispan/Ehcache
backends and follow the same approach.


> I'm also fine if we start with just the JSON approach.
>

+1 Let's start from there and let things evolve.

>
> > * The id is used as key and also part of the JSON value. Could it be
> removed from the latter?
> Yes, this is due to the draft state
>
> > * Do you have any ideas how Redis-specific structures could be exposed
> which do not map exactly to entities, e.g. Lists stored directly via some
> key?
>
> Yes. Redis-backed Collections, Maps, Locks, Queues, Caching, and many more
> are possible. I'm not sure, whether you want to have that features because
> they do not look like they fit the Hibernate OGM concept. There are
> implementations (Redisson: https://github.com/mrniko/redisson, Spring
> Data Redis:
> https://github.com/spring-projects/spring-data-redis/tree/master/src/main/java/org/springframework/data/redis/support/collections)
> that cover the Redis-backed Collections etc.
>

People will use Redis for the powers of its specific features, so I think
they should be accessible in one way or the other. Not everything can be
mapped to/exposed through JPA in a sensible way. I guess one needs to look
at it on a case-by-case basis, maybe it makes sense to somehow expose the
native API for certain advanced cases.

>
> > * Our option system could be used to expose specific settings such as
> TTL for given entities
> Great! Redis supports TTL's, I was not aware of that OGM feature
>

OGM does not directly support this, but it provides an extensible option
system which dialects can leverage to let the user configure specific
settings and apply these when talking to the datastore. E.g. one could
imagine something like this:

@TTL(value=7, unit=TimeUnit.DAY)
@Entity
class LogRecord { ... }

@TTL would be a Redis-backend specific setting based on said option system,
and the Redis backend would apply this setting when writing tuples of the
LogRecord entity. You can find examples with @ReadPreference/@WriteConcern
in the MongoDB backend. Of course that's not required for a first version,
but would make for a nice addition in later iterations.


>
> > * Is there any form of transaction support in Redis we could leverage?
> Yes. Redis supports transactions with the MULTI/EXEC/DISCARD commands.
> Transactions require a connection affinity and imply the use of multiple
> connections. That's nothing bad per se, just a thing to be aware of.
>

Ah, that's interesting. So it should be possible to link this with the
JPA/JTA transaction APIs?


>
> Thanks and best regards, Mark
>
>
> Gunnar Morling <gunnar at hibernate.org> schrieb am Di., 21. Juli 2015 um
> 13:03 Uhr:
>
>> Hi Mark,
>>
>> Many thanks for giving this a try; Your work looks impressive, it's very
>> advanced for an initial dialect contribution, covering many advanced cases
>> already. So kudos for that!
>>
>> Please find some remarks and questions below.
>>
>> Cheers,
>>
>> --Gunnar
>>
>>
>> 2015-07-17 17:16 GMT+02:00 Mark Paluch <mpaluch at paluch.biz>:
>>
>>> Hi there,
>>>
>>> I created a Redis module for Hibernate OGM, based on OGM 4.2. Redis is a
>>> Key-Value store supporting Lists, Hashes (Maps), Sorted Sets, ...
>>>
>>> I took the Infinispan/CouchDB approach storing entities and associations
>>> as
>>> JSON documents within Redis Hashes. A Map<Object, Map<Object, Object>>
>>> corresponds with a Redis Hash.
>>>
>>> The entity table maps to the Hash Id, the entity Id to the key of the
>>> hash
>>> and the set of columns is enclosed within a JSON (currently). Supported
>>> features are:
>>>
>>> * Composite Id's
>>> * Embedded associations
>>> * External associations
>>>
>>
>> * I saw you create a hash per entity type, using the ids as keys within
>> this hash and a JSON document modelling the properties of a given entity
>> instance.
>>
>> Have you considered to store JSON documents on the "top-level" instead?
>> This would require to encode the table name into the key as well (similar
>> to as we do it for CouchDB): "Order:123" -> ... . The reason I am asking is
>> that I am wondering whether it may be a source of contention and/or whether
>> it may pose scaling issues if all entities of one type are stored within a
>> single hash.
>>
>> Using JSON for the actual entity contents seems reasonable and a common
>> approach in the Redis world from what I've read, so +1 for doing this from
>> me. How would the "more native" approach look like you describe below?
>> Would we have to serialise everything ourselves into String/byte[]? If so,
>> I am not sure whether that's of much usefulness actually and I'd be
>> inclined to go the JSON route exclusively. As you say, it also works nicely
>> for hierarchical structures.
>>
>> * The id is used as key and also part of the JSON value. Could it be
>> removed from the latter?
>>
>> * Do you have any ideas how Redis-specific structures could be exposed
>> which do not map exactly to entities, e.g. Lists stored directly via some
>> key?
>>
>> * Our option system could be used to expose specific settings such as TTL
>> for given entities
>>
>> * Is there any form of transaction support in Redis we could leverage?
>>
>> and I guess many more, that I'm currently not aware of :-)
>>>
>>> There are various ways (JSON, Java-serialized simulating Documents) how
>>> to
>>> store data within Redis.
>>> Another approach could be storing Tuples within Redis more native, since
>>> they are in the end Maps, somehow. However, mapping tuples to Redis fit a
>>> native storage but raises questions about Id's, limited data type support
>>> (there is no equivalent for nested lists/maps). So the more native
>>> approach
>>> would require distributing data amongst various data types, depending on
>>> the supported features, and would require more IO's.
>>>
>>> My impl can be used to interoperate with other clients from the C, Ruby,
>>> Python, Node.js, ... worlds. The JSON is clean and does not look awkward
>>> on
>>> the first look.
>>>
>>> The current code can be found below
>>> https://github.com/mp911de/hibernate-ogm/tree/redis. Most TCK tests
>>> pass,
>>> only some 15 tests fail. Mostly due to enum and JTA support. Couldn't
>>> figure out, how to fix it, so need your help to figure it out.
>>>
>>
>> I'll take a closer look at your change asap. Could you create a pull
>> request from your branch against the upstream repo? Then we can have a
>> discussion right there.
>>
>> Hope, I made you hungry for the Redis OGM module. Let's start a discussion
>>> based on my proposal for inclusion and let's see, where we end up.
>>>
>>
>> Yep, it looks very promising and I think it'd be great to have support
>> for Redis in OGM :) We'll need your continued help though to make it happen
>> and evolve it in the future as Redis itself and OGM core advance.
>>
>> Best regards, Mark
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From mpaluch at paluch.biz  Wed Jul 22 09:55:16 2015
From: mpaluch at paluch.biz (Mark Paluch)
Date: Wed, 22 Jul 2015 13:55:16 +0000
Subject: [hibernate-dev] Proposal for a Redis module in Hibernate OGM
In-Reply-To: <CADGJaX8AnrBzEKDLA655_shFA-5uQXY_DDgyTcbp36bpf2JAUQ@mail.gmail.com>
References: <CAE-fDMt69N=1zDNiq+p-0rtiTvEFJov2F-z-1PjR66US6ombZg@mail.gmail.com>
	<CADGJaX-aCXp_=seKVKv=Fo1QoyPf0bf+RHYGP0xvS1js-dK5sQ@mail.gmail.com>
	<CAE-fDMv5XJS0_TKtjL7vAjVLE2v2ocQJ4GKC878abvG_NW3nTw@mail.gmail.com>
	<CADGJaX8AnrBzEKDLA655_shFA-5uQXY_DDgyTcbp36bpf2JAUQ@mail.gmail.com>
Message-ID: <CAE-fDMt2DUeONuhyCYiE19GBCbbZtf5MyHp=1mDLmbP7O74Bxg@mail.gmail.com>

Hi,
I fixed the enum thing. It was a mismatch between int and long. D'oh!

> Are there conventions for mapping more complex types such as Date for
instance?
No (at least I don't know any), so we should go as we need it.

> TTL
Implemented.

> Transactions: Ah, that's interesting. So it should be possible to link
this with the JPA/JTA transaction APIs?

Redis transactions work a bit different (was not aware of that, as I told
you about transactions). Redis transactions are more batch than
transactions. Redis transactions work very nice when writing, but there's a
reading issue. Reads are queued until the transaction is submitted. So the
read will come back with a result only if the transaction is confirmed with
`EXEC`. I'm pretty sure, this can be a deal-breaker for using transactions
in the JTA way.

I submitted a PR https://github.com/hibernate/hibernate-ogm/pull/560 and
started to work on the docs. Let's start a discussion based on the PR :-)

Best regards, viele Gr??e, Mark


Gunnar Morling <gunnar at hibernate.org> schrieb am Mi., 22. Juli 2015 um
10:41 Uhr:

> 2015-07-21 14:14 GMT+02:00 Mark Paluch <mpaluch at paluch.biz>:
>
>> Hi Gunnar,
>>
>> thanks for your helpful feedback. I will come up with a PR as soon as we
>> agree on the strategies issue - well, perhaps in a couple days. I can and
>> will support you and I can help you with support/maintenance for the Redis
>> module in the future.
>>
>
> That's great to hear. We are no Redis experts, so the help of one is
> needed to make this fly :)
>
>
>> I will have to ask you in return on some specific issues, such as why
>> enum-ordinals cannot be mapped back.
>>
>
> Sure, absolutely. I will take a look at the enum thingy.
>
>
>> > * I saw you create a hash per entity type, using the ids as keys within
>> this hash and a JSON document modelling the properties of a given entity
>> instance.
>> >
>> > Have you considered to store JSON documents on the "top-level" instead?
>> This would require to encode the table name into the key as well (similar
>> to as we do it for CouchDB): "Order:123" -> ... . The reason I am asking is
>> that I am wondering whether it may be a source of contention and/or whether
>> it may pose scaling issues if all entities of one type are stored within a
>> single hash.
>>
>> Yes, I was thinking about that issue. I ended up with the hash per entity
>> type in the first place. This is not a final thing, but rather a draft.
>> Pulling the JSON strategy to the global level is a good idea and key
>> patterns like "Order:123" are a recommended way. The top-level approach
>> tackles also another issue: Redis can be operated as a cluster in terms of
>> sharding. The sharding is key-based. A top-level key encourages a nice
>> distribution amongst the cluster. Cluster support is not yet included in my
>> code. I wanted to check with you guys first, whether a Redis module could
>> be included in OGM.
>>
>
> Yes, clustering was part of my concern with the original approach. The
> top-level approach would help with that.
>
>>
>> > Using JSON for the actual entity contents seems reasonable and a common
>> approach in the Redis world from what I've read, so +1 for doing this from
>> me. How would the "more native" approach look like you describe below?
>> Would we have to serialise everything ourselves into String/byte[]? If so,
>> I am not sure whether that's of much usefulness actually and I'd be
>> inclined to go the JSON route exclusively. As you say, it also works nicely
>> for hierarchical structures.
>>
>> My first idea on the more native approach was storing all basic data
>> types as key-value pairs. I noticed, that embedded properties are
>> transported with dot-notation, which comes handy. Converting the properties
>> to String is also a common Redis style and interoperability between
>> different systems/languages is encouraged hereby.
>>
>
> Are there conventions for mapping more complex types such as Date for
> instance? You'd need custom GridTypes to map everything into String (we
> have String-mapping implementations for some types such as Date and Long,
> but not for all of them).
>
>
>> I'm just not sure, how to deal with external and embedded associations.
>> Simulating associations by distributing the lists to Redis lists with
>> referencing other hashes looks like an overkill to Redis. A lot of
>> meta-data would have to be held. Feasible Yes, sensible No. The ROM
>> framework (https://github.com/josiahcarlson/rom/) goes for this
>> approach.
>>
>> So if omitting associations in the more native approach is not a
>> deal-breaker, I'd vote to go this way as well.
>>
>
> Not supporting associations at all in that mode seems like a heavy
> limitation to me. I am not sure what you mean by "lot of meta-data would
> have to be held"; Where, in the driver, or in the dialect? OGM engine
> should give you all you need, I suggest to check out the Infinispan/Ehcache
> backends and follow the same approach.
>
>
>> I'm also fine if we start with just the JSON approach.
>>
>
> +1 Let's start from there and let things evolve.
>
>>
>> > * The id is used as key and also part of the JSON value. Could it be
>> removed from the latter?
>> Yes, this is due to the draft state
>>
>> > * Do you have any ideas how Redis-specific structures could be exposed
>> which do not map exactly to entities, e.g. Lists stored directly via some
>> key?
>>
>> Yes. Redis-backed Collections, Maps, Locks, Queues, Caching, and many
>> more are possible. I'm not sure, whether you want to have that
>> features because they do not look like they fit the Hibernate OGM concept.
>> There are implementations (Redisson: https://github.com/mrniko/redisson,
>> Spring Data Redis:
>> https://github.com/spring-projects/spring-data-redis/tree/master/src/main/java/org/springframework/data/redis/support/collections)
>> that cover the Redis-backed Collections etc.
>>
>
> People will use Redis for the powers of its specific features, so I think
> they should be accessible in one way or the other. Not everything can be
> mapped to/exposed through JPA in a sensible way. I guess one needs to look
> at it on a case-by-case basis, maybe it makes sense to somehow expose the
> native API for certain advanced cases.
>
>>
>> > * Our option system could be used to expose specific settings such as
>> TTL for given entities
>> Great! Redis supports TTL's, I was not aware of that OGM feature
>>
>
> OGM does not directly support this, but it provides an extensible option
> system which dialects can leverage to let the user configure specific
> settings and apply these when talking to the datastore. E.g. one could
> imagine something like this:
>
> @TTL(value=7, unit=TimeUnit.DAY)
> @Entity
> class LogRecord { ... }
>
> @TTL would be a Redis-backend specific setting based on said option
> system, and the Redis backend would apply this setting when writing tuples
> of the LogRecord entity. You can find examples with
> @ReadPreference/@WriteConcern in the MongoDB backend. Of course that's not
> required for a first version, but would make for a nice addition in later
> iterations.
>
>
>>
>> > * Is there any form of transaction support in Redis we could leverage?
>> Yes. Redis supports transactions with the MULTI/EXEC/DISCARD commands.
>> Transactions require a connection affinity and imply the use of multiple
>> connections. That's nothing bad per se, just a thing to be aware of.
>>
>
> Ah, that's interesting. So it should be possible to link this with the
> JPA/JTA transaction APIs?
>
>
>>
>> Thanks and best regards, Mark
>>
>>
>> Gunnar Morling <gunnar at hibernate.org> schrieb am Di., 21. Juli 2015 um
>> 13:03 Uhr:
>>
>>> Hi Mark,
>>>
>>> Many thanks for giving this a try; Your work looks impressive, it's very
>>> advanced for an initial dialect contribution, covering many advanced cases
>>> already. So kudos for that!
>>>
>>> Please find some remarks and questions below.
>>>
>>> Cheers,
>>>
>>> --Gunnar
>>>
>>>
>>> 2015-07-17 17:16 GMT+02:00 Mark Paluch <mpaluch at paluch.biz>:
>>>
>>>> Hi there,
>>>>
>>>> I created a Redis module for Hibernate OGM, based on OGM 4.2. Redis is a
>>>> Key-Value store supporting Lists, Hashes (Maps), Sorted Sets, ...
>>>>
>>>> I took the Infinispan/CouchDB approach storing entities and
>>>> associations as
>>>> JSON documents within Redis Hashes. A Map<Object, Map<Object, Object>>
>>>> corresponds with a Redis Hash.
>>>>
>>>> The entity table maps to the Hash Id, the entity Id to the key of the
>>>> hash
>>>> and the set of columns is enclosed within a JSON (currently). Supported
>>>> features are:
>>>>
>>>> * Composite Id's
>>>> * Embedded associations
>>>> * External associations
>>>>
>>>
>>> * I saw you create a hash per entity type, using the ids as keys within
>>> this hash and a JSON document modelling the properties of a given entity
>>> instance.
>>>
>>> Have you considered to store JSON documents on the "top-level" instead?
>>> This would require to encode the table name into the key as well (similar
>>> to as we do it for CouchDB): "Order:123" -> ... . The reason I am asking is
>>> that I am wondering whether it may be a source of contention and/or whether
>>> it may pose scaling issues if all entities of one type are stored within a
>>> single hash.
>>>
>>> Using JSON for the actual entity contents seems reasonable and a common
>>> approach in the Redis world from what I've read, so +1 for doing this from
>>> me. How would the "more native" approach look like you describe below?
>>> Would we have to serialise everything ourselves into String/byte[]? If so,
>>> I am not sure whether that's of much usefulness actually and I'd be
>>> inclined to go the JSON route exclusively. As you say, it also works nicely
>>> for hierarchical structures.
>>>
>>> * The id is used as key and also part of the JSON value. Could it be
>>> removed from the latter?
>>>
>>> * Do you have any ideas how Redis-specific structures could be exposed
>>> which do not map exactly to entities, e.g. Lists stored directly via some
>>> key?
>>>
>>> * Our option system could be used to expose specific settings such as
>>> TTL for given entities
>>>
>>> * Is there any form of transaction support in Redis we could leverage?
>>>
>>> and I guess many more, that I'm currently not aware of :-)
>>>>
>>>> There are various ways (JSON, Java-serialized simulating Documents) how
>>>> to
>>>> store data within Redis.
>>>> Another approach could be storing Tuples within Redis more native, since
>>>> they are in the end Maps, somehow. However, mapping tuples to Redis fit
>>>> a
>>>> native storage but raises questions about Id's, limited data type
>>>> support
>>>> (there is no equivalent for nested lists/maps). So the more native
>>>> approach
>>>> would require distributing data amongst various data types, depending on
>>>> the supported features, and would require more IO's.
>>>>
>>>> My impl can be used to interoperate with other clients from the C, Ruby,
>>>> Python, Node.js, ... worlds. The JSON is clean and does not look
>>>> awkward on
>>>> the first look.
>>>>
>>>> The current code can be found below
>>>> https://github.com/mp911de/hibernate-ogm/tree/redis. Most TCK tests
>>>> pass,
>>>> only some 15 tests fail. Mostly due to enum and JTA support. Couldn't
>>>> figure out, how to fix it, so need your help to figure it out.
>>>>
>>>
>>> I'll take a closer look at your change asap. Could you create a pull
>>> request from your branch against the upstream repo? Then we can have a
>>> discussion right there.
>>>
>>> Hope, I made you hungry for the Redis OGM module. Let's start a
>>>> discussion
>>>> based on my proposal for inclusion and let's see, where we end up.
>>>>
>>>
>>> Yep, it looks very promising and I think it'd be great to have support
>>> for Redis in OGM :) We'll need your continued help though to make it happen
>>> and evolve it in the future as Redis itself and OGM core advance.
>>>
>>> Best regards, Mark
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>

From steve at hibernate.org  Wed Jul 22 15:18:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Jul 2015 19:18:16 +0000
Subject: [hibernate-dev] MySQL versus MariaDB
Message-ID: <CAFdSV9toQYAhQYobojXipYOr_CCqTwZjs3B35m58hCL3MY6wiQ@mail.gmail.com>

As I have developed the matrix tests against MariaDB I have had in the back
of my head whether we might want to develop a Dialect for MariaDB.  As I
understand it, MariaDB does strive to remain compatible with MySQL but it
does offer some enhancements.  And it might have some minor deviations.
Today I think I found one such deviation, in their respective support for
casting decimal/floating-point values.  I came across this because of some
failed tests.

There are quite a few resolved issues in Jira wrt MySQL and casting.  So I
have to assume these tests work on MySQL which tells me there is a
deviation in their behavior...

The tests in question (more or less) do: "select ... cast( x as big_decimal
) ...".  We understand big_decimal as java.sql.Types#NUMERIC for which the
MySQL Dialect says to use "decimal" for casting purposes.

On MariaDB at least "decimal" (no precision) leads to a data trunction.  We
are expecting a value like "12.399999618530273" but get back "12.0".
Because for MariaDB DECIMAL is equivalent to DECIMAL(10,0).

So as it is, for this minor case at least the MySQL dialects work against
MySQL databases (we assume) but fail against MariaDB databases.

The other difficulty with a dialect specific for MariaDB is
auto-detection.  The MariaDB JDBC drivers report the underlying database as
mysql.

From gbadner at redhat.com  Wed Jul 22 15:50:44 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 22 Jul 2015 15:50:44 -0400 (EDT)
Subject: [hibernate-dev]
 org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest
In-Reply-To: <2D47DDD6-9E68-4670-8975-42E51F472866@hibernate.org>
References: <364013595.1863749.1437541708224.JavaMail.zimbra@redhat.com>
	<2D47DDD6-9E68-4670-8975-42E51F472866@hibernate.org>
Message-ID: <463989177.2422911.1437594644675.JavaMail.zimbra@redhat.com>

This is a hibernate-core unit test has been around for a long time (at least 2010) and I haven't see the column names changing like this until recently.

----- Original Message -----
> From: "Emmanuel Bernard" <emmanuel at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, July 22, 2015 1:40:37 AM
> Subject: Re: [hibernate-dev]
> org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest
> 
> I?d say it?s fair to ask the user to use consistent column naming so that
> would be a bug in the test.
> 
> > On 22 Jul 2015, at 07:08, Gail Badner <gbadner at redhat.com> wrote:
> > 
> > I think this is probably just a bug in the test, but I want to mention it
> > in case there is a real bug here.
> > 
> > When I run the unit tests multiple times, sometimes I see WarehouseItem
> > created with:
> > 
> >    create table WarehouseItem (
> >        id integer generated by default as identity,
> >        version integer not null,
> >        qtyInStock decimal(19,2),
> >        vendor_id integer,
> >        item_id integer,
> >        primary key (id)
> >    )
> > 
> > Sometimes WarehouseItem is created with:
> >    create table WarehouseItem (
> >        id integer generated by default as identity,
> >        version integer not null,
> >        qtyInStock decimal(19,2),
> >        ITEM_ID integer not null,
> >        VENDOR_ID integer not null,
> >        primary key (id)
> >    )
> > 
> > I started seeing this only recently (last couple of weeks or so).
> > 
> > In the WarehouseItem class [1], the following join column names are
> > specified: vendor_id, VENDOR_ID, item_id, ITEM_ID.
> > 
> > I'm sure that making the column names consistent (upper or lower) case
> > would make the table DDL consistent. I want to make sure I don't mask a
> > real bug by making this change.
> > 
> > Is this a bug in the test, or a bug in how column names are processed?
> > 
> > [1]
> > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/test/annotations/manytoone/referencedcolumnname/WarehouseItem.java
> > 
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 


From steve at hibernate.org  Wed Jul 22 15:51:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Jul 2015 19:51:31 +0000
Subject: [hibernate-dev] MySQL versus MariaDB
In-Reply-To: <CAFdSV9toQYAhQYobojXipYOr_CCqTwZjs3B35m58hCL3MY6wiQ@mail.gmail.com>
References: <CAFdSV9toQYAhQYobojXipYOr_CCqTwZjs3B35m58hCL3MY6wiQ@mail.gmail.com>
Message-ID: <CAFdSV9tu_skmNuSL4XbbR-qzDgbmo+yusanGeox3tftSDXm85g@mail.gmail.com>

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

On Wed, Jul 22, 2015 at 2:18 PM Steve Ebersole <steve at hibernate.org> wrote:

> As I have developed the matrix tests against MariaDB I have had in the
> back of my head whether we might want to develop a Dialect for MariaDB.  As
> I understand it, MariaDB does strive to remain compatible with MySQL but it
> does offer some enhancements.  And it might have some minor deviations.
> Today I think I found one such deviation, in their respective support for
> casting decimal/floating-point values.  I came across this because of some
> failed tests.
>
> There are quite a few resolved issues in Jira wrt MySQL and casting.  So I
> have to assume these tests work on MySQL which tells me there is a
> deviation in their behavior...
>
> The tests in question (more or less) do: "select ... cast( x as
> big_decimal ) ...".  We understand big_decimal as java.sql.Types#NUMERIC
> for which the MySQL Dialect says to use "decimal" for casting purposes.
>
> On MariaDB at least "decimal" (no precision) leads to a data trunction.
> We are expecting a value like "12.399999618530273" but get back "12.0".
> Because for MariaDB DECIMAL is equivalent to DECIMAL(10,0).
>
> So as it is, for this minor case at least the MySQL dialects work against
> MySQL databases (we assume) but fail against MariaDB databases.
>
> The other difficulty with a dialect specific for MariaDB is
> auto-detection.  The MariaDB JDBC drivers report the underlying database as
> mysql.
>

From gbadner at redhat.com  Wed Jul 22 21:47:06 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 22 Jul 2015 21:47:06 -0400 (EDT)
Subject: [hibernate-dev] HQLScrollFetchTest
In-Reply-To: <CAFdSV9sAYRNn-HRWvrcUYZrHfFnCuarBz9u50+4XL-AbWqtsdg@mail.gmail.com>
References: <CAFdSV9sAYRNn-HRWvrcUYZrHfFnCuarBz9u50+4XL-AbWqtsdg@mail.gmail.com>
Message-ID: <136768490.2536090.1437616026269.JavaMail.zimbra@redhat.com>

See replies below...

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Saturday, July 18, 2015 11:09:35 AM
> Subject: [hibernate-dev] HQLScrollFetchTest
> 
> Gail, etal.
> 
> I have a lot of questions in regards to HQLScrollFetchTest:
> 
> 1) First is the split between it and NoIdentityHQLScrollFetchTest.  I do
> not fully understand why this split exists.  They test the same thing
> (literally; NoIdentityHQLScrollFetchTest extends HQLScrollFetchTest and
> just supplies a different mapping).  The mapping says something about
> Sybase requiring the pk to be an IDENTITY in order for it to support
> scrolling results.  But I could find no mention of that anywhere via google
> search.

IIUC, NoIdentityHQLScrollFetchTest was created just to the same test methods using dialects that don't support IDENTITY columns.

The mapping doesn't say that the PK needs to be an IDENTITY for sybase, it says it has to have an "identifier column":
	<!-- A numeric id must be the <id> field.  Some databases (Sybase, etc.)
        require identifier columns in order to support scrollable results. -->

I don't think there is any reason that the test needs to use an IDENTITY column. Using <generator class="increment" /> should make the test work with all dialects so there would be no need to NoIdentityHQLScrollFetchTest. I've tried running HQLScrollFetchTest using class="increment" with SybaseASE15Dialect and it works just fine.

> 2) HQLScrollFetchTest#testScroll is skipped for a huge list of dialects.  I
> only even started looking at this class because this test is failing when I
> try to run it against MySQL/MariaDB (these are not listed for skipping).
> But looking at the test, there is no expectation that this should ever work
> for any database.  The reason being that we completely expect the user to
> "properly order" the query results for scrolling queries with fetches.  The
> test does not do that.  TBH, I do not know what Dialect this test would
> actually pass against.

I see that you added "order by p.name asc, c.name asc", and I see what you mean about testScroll without ordering the data. I don't know why there would be a test that doesn't order the data properly.

I've tried changing the mapping for HQLScrollFetchTest to use "increment" generator, removed the @SkipDialect annotations, and tested with sybase, SQLServer, Oracle, and DB2. They all pass now. 

AbstractHANADialect and TeradataDialect do not support IDENTITY columns. They should also work with "increment generator, but I have not tested them.

I created HHH-9970 to remove NoIdentityHQLScrollFetchTest and to change HQLScrollFetchTest to work with all dialects (AFAICT).

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

From steve at hibernate.org  Thu Jul 23 10:41:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 23 Jul 2015 14:41:55 +0000
Subject: [hibernate-dev] MariaDB on CI
In-Reply-To: <CAFm4XO1mrw5wVKyvhAKED=qwrg_+kKFFj19yHnu_ut3+9UgcXA@mail.gmail.com>
References: <CAFdSV9vaAWQbE9HO0qz04FyTJ9dXPimS6VmWab+zA=Rz12NVFw@mail.gmail.com>
	<CAFm4XO33Hf0fX2ckB_t1zpPt8oZdXPstmxB0EG4j+rphaQ-ruQ@mail.gmail.com>
	<CAFdSV9twdX6qVom-B490HqH3--=Kt1pKGQrqg7ZgMU=1qQ6i7w@mail.gmail.com>
	<CAFm4XO1mrw5wVKyvhAKED=qwrg_+kKFFj19yHnu_ut3+9UgcXA@mail.gmail.com>
Message-ID: <CAFdSV9vvsqCofzaSVLgzPdB465Hu2LgQhX=Pn6W_fXpE=E+ZhA@mail.gmail.com>

Another change is to make sure our test user has create/drop privileges on
all databases, and to be able to create/drop databases:

grant create, drop on *.* to 'hibernate_orm_test'@'localhost';

We will need similar for the other databases too.



On Tue, Jul 21, 2015 at 6:02 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 20 July 2015 at 17:41, Steve Ebersole <steve at hibernate.org> wrote:
> > Sanne for MariaDB (and MySQL if we ever add it) we need to add at least
> one
> > more setting:
> >
> > sql-mode="traditional"
>
> I've applied this change.
>
> --Sanne
>
> >
> > We could probably get away with less ANSI compliant mode, but after days
> > playing with this I just want to cover my bases :)
> >
> > On Sat, Jul 18, 2015 at 3:37 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Thanks, great suggestions!
> >> I've applied these and some more.
> >>
> >> The MariaDB configuration:
> >>  -
> >>
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/mariadb-server/files/my.cnf
> >>
> >> The PosgreSQL configuration files:
> >>  -
> >>
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/pg_hba.conf
> >>  -
> >>
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/postgresql.conf
> >>
> >> Both are running with these settings now on each CI slave.
> >> Sanne
> >>
> >> On 18 July 2015 at 00:49, Steve Ebersole <steve at hibernate.org> wrote:
> >> > [18:45] <sebersole> whoa..
> >> > [18:45] <sebersole> sannegrinovero: we definitely need this for
> mariadb
> >> > on
> >> > ci...
> >> > [18:46] <sebersole> sync_binlog=0 innodb_flush_log_at_trx_commit=0
> >> > innodb_doublewrite=0
> >> > [18:46] <sebersole> tests were much faster
> >> >
> >> > These were suggested to me on the #mariadb list.  I added them to my
> >> > local
> >> > /etc/my.cnf file and the tests were significantly faster.
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Thu Jul 23 11:20:41 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 23 Jul 2015 17:20:41 +0200
Subject: [hibernate-dev] Reminder: Testing on WildFly 10 requires Java 8
Message-ID: <CADGJaX9Xe-9p-LV+0koEuEfcc4rr0wBQEc6iPE4GESOPBt9LEw@mail.gmail.com>

Hi,

A quick reminder for those projects that wish to run integration tests on
WildFly 10: This requires the build to run on Java 8.

Preferably, this should be enforced e.g. through the Maven enforcer plug-in
or similar. Running tests on WF 10 on an older JDK fails. The cause is a
bit tough to find (JBoss modules refuses to load the WF 10 modules which
happens very early, so there is no entry in server.log).

Of course our own projects still can target earlier Java versions, it's
only WF integration tests which are affected by this.

Cheers,

--Gunnar

From emmanuel at hibernate.org  Fri Jul 24 03:56:24 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 24 Jul 2015 09:56:24 +0200
Subject: [hibernate-dev] [OGM] GridDialect facets
Message-ID: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>

I have been adding a facet to GridDialect and found it surprisingly hard:

* I was not sure which non datastore dialects was supposed to implement the facet nor really how to find these non datastore dialects. I am talking about GridDialectLogger, ForwardingGridDialect and InvokedOperationsLoggingDialect. I am sure there are more of these non datastore dialects but I haven?t found them.
* Adding one method, to a facet means having to go to a lot of places to write all these logging and delegating logics. Changing a method sig a least gives you the help of the compiler but not for adding them.
* Find how consumers of the facet are supposed to use them was not obvious to me. It seems a given consumer stores all the possible facets as class field and do a null check before using them.
* when I finally ran my tests everything exploded because each facet must have a MyFacetInitiator
* when I added the initiator, it still blew up at my face because each Initiator must be listed in the OgmIntegrator
* I?m also concerned about facet discoverability, I don?t think it?s trivial for a dialect implementor to get the list of facets easily, which will tend to bring minimal dialects without the advanced features.

I wonder if and / or how we should improve that state of affairs.

Emmanuel

From hardy at hibernate.org  Fri Jul 24 04:32:19 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 24 Jul 2015 10:32:19 +0200
Subject: [hibernate-dev] [OGM] GridDialect facets
In-Reply-To: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
References: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
Message-ID: <20150724083219.GB55673@Nineveh.lan>

On Fri, Jul 24, 2015 at 09:56:24AM +0200, Emmanuel Bernard wrote:

> I have been adding a facet to GridDialect and found it surprisingly hard:

What is a facet in this context. I've seen you guys using this term on IRC as well,
but I am not sure what you mean with it in relation to a GridDialect.

>  which non datastore dialects was supposed to implement the facet 

non datastore dialect? Is it not one dialect per datastore?

Just trying to understand what you guys are actually talking about ;-)

--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/20150724/e8bc12f2/attachment.bin 

From daltodavide at gmail.com  Fri Jul 24 04:59:09 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 24 Jul 2015 09:59:09 +0100
Subject: [hibernate-dev] [OGM] GridDialect facets
In-Reply-To: <20150724083219.GB55673@Nineveh.lan>
References: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
	<20150724083219.GB55673@Nineveh.lan>
Message-ID: <CANoTJYNKdP3mu437VM4Nh9kJjeemQtvEgj-1qi+FOLJ9ektqqA@mail.gmail.com>

>> I have been adding a facet to GridDialect and found it surprisingly hard:
>
> What is a facet in this context.

Facet are additional interfaces that can be used on a GridDialect to add
features to it, like support for optimistic locking, batching or native id
generation.

> non datastore dialect? Is it not one dialect per datastore?

Emmanuel is talking about some decorator classes the we use in different
scenarios. They will delegate the operations to the datastore dialect but
will execute some additional logic
before/after. For example, the GridDialectLogger will add some log before
delegating the operations to selected dialect.

> * I?m also concerned about facet discoverability, I don?t think it?s
trivial for a dialect implementor to get the list of facets easily, which
will tend to bring minimal dialects without the advanced features.

Right, we could create an empty interface to flag them.






On Fri, Jul 24, 2015 at 9:32 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> On Fri, Jul 24, 2015 at 09:56:24AM +0200, Emmanuel Bernard wrote:
>
> > I have been adding a facet to GridDialect and found it surprisingly hard:
>
> What is a facet in this context. I've seen you guys using this term on IRC
> as well,
> but I am not sure what you mean with it in relation to a GridDialect.
>
> >  which non datastore dialects was supposed to implement the facet
>
> non datastore dialect? Is it not one dialect per datastore?
>
> Just trying to understand what you guys are actually talking about ;-)
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri Jul 24 05:01:43 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 24 Jul 2015 11:01:43 +0200
Subject: [hibernate-dev] [OGM] GridDialect facets
In-Reply-To: <20150724083219.GB55673@Nineveh.lan>
References: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
	<20150724083219.GB55673@Nineveh.lan>
Message-ID: <CADGJaX_8GzyqvWg61poXSwkqLeiVo8L262cGhpaE8-YpCD_PuQ@mail.gmail.com>

2015-07-24 10:32 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:

> On Fri, Jul 24, 2015 at 09:56:24AM +0200, Emmanuel Bernard wrote:
>
> > I have been adding a facet to GridDialect and found it surprisingly hard:
>
> What is a facet in this context. I've seen you guys using this term on IRC
> as well,
> but I am not sure what you mean with it in relation to a GridDialect.
>

It's our way to model different (optional) capabilities of data stores.

The main contract is GridDialect which offers the basic functionality each
store needs to support (getTuple(), insertOrUpdateAssocation() and so on).
Then there are several sub-types of it (e.g. QueryableGridDialect,
OptimisticLockingAwareGridDialect etc.) which allow a dialect to expose
advanced (or more efficient) functionality. Depending on which capabilities
a store exposes that way, engine will make use of it.

>  which non datastore dialects was supposed to implement the facet
>
> non datastore dialect? Is it not one dialect per datastore?
>

Davide's answer says it :)

Just trying to understand what you guys are actually talking about ;-)
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri Jul 24 05:38:49 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 24 Jul 2015 11:38:49 +0200
Subject: [hibernate-dev] [OGM] GridDialect facets
In-Reply-To: <CANoTJYNKdP3mu437VM4Nh9kJjeemQtvEgj-1qi+FOLJ9ektqqA@mail.gmail.com>
References: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
	<20150724083219.GB55673@Nineveh.lan>
	<CANoTJYNKdP3mu437VM4Nh9kJjeemQtvEgj-1qi+FOLJ9ektqqA@mail.gmail.com>
Message-ID: <CADGJaX-LpF_KZBq+4niTNB55W3NupjJGHneoK+HxjaCohmLjVw@mail.gmail.com>

> Right, we could create an empty interface to flag them.

They all extend GridDialect already. Is there any easier way for an dialect
provider to learn about all the facets than inspecting the type hierarchy
of GridDialect?


2015-07-24 10:59 GMT+02:00 Davide D'Alto <daltodavide at gmail.com>:

> >> I have been adding a facet to GridDialect and found it surprisingly
> hard:
> >
> > What is a facet in this context.
>
> Facet are additional interfaces that can be used on a GridDialect to add
> features to it, like support for optimistic locking, batching or native id
> generation.
>
> > non datastore dialect? Is it not one dialect per datastore?
>
> Emmanuel is talking about some decorator classes the we use in different
> scenarios. They will delegate the operations to the datastore dialect but
> will execute some additional logic
> before/after. For example, the GridDialectLogger will add some log before
> delegating the operations to selected dialect.
>
> > * I?m also concerned about facet discoverability, I don?t think it?s
> trivial for a dialect implementor to get the list of facets easily, which
> will tend to bring minimal dialects without the advanced features.
>
> Right, we could create an empty interface to flag them.
>
>
>
>
>
>
> On Fri, Jul 24, 2015 at 9:32 AM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
> > On Fri, Jul 24, 2015 at 09:56:24AM +0200, Emmanuel Bernard wrote:
> >
> > > I have been adding a facet to GridDialect and found it surprisingly
> hard:
> >
> > What is a facet in this context. I've seen you guys using this term on
> IRC
> > as well,
> > but I am not sure what you mean with it in relation to a GridDialect.
> >
> > >  which non datastore dialects was supposed to implement the facet
> >
> > non datastore dialect? Is it not one dialect per datastore?
> >
> > Just trying to understand what you guys are actually talking about ;-)
> >
> > --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  Fri Jul 24 08:05:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Jul 2015 12:05:28 +0000
Subject: [hibernate-dev] Next 5.0 release
Message-ID: <CAFdSV9vWi5T-rLFwV1pki_0+aqdSHg7JG0s1btzCjSYicC7_nA@mail.gmail.com>

I am feeling like so many changes to SPIs have piled up on master since CR2
that another CR is warranted.  Everyone ok with doing a CR3?

From gunnar at hibernate.org  Fri Jul 24 08:08:19 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 24 Jul 2015 14:08:19 +0200
Subject: [hibernate-dev] Next 5.0 release
In-Reply-To: <CAFdSV9vWi5T-rLFwV1pki_0+aqdSHg7JG0s1btzCjSYicC7_nA@mail.gmail.com>
References: <CAFdSV9vWi5T-rLFwV1pki_0+aqdSHg7JG0s1btzCjSYicC7_nA@mail.gmail.com>
Message-ID: <CADGJaX8UJub=EeBuuAGvwS7mLphdGyEKqoUast_5pL2=puq-qg@mail.gmail.com>

+1

When do you plan to do it, next Wednesday?


2015-07-24 14:05 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> I am feeling like so many changes to SPIs have piled up on master since CR2
> that another CR is warranted.  Everyone ok with doing a CR3?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jul 24 08:32:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Jul 2015 12:32:03 +0000
Subject: [hibernate-dev] Next 5.0 release
In-Reply-To: <CADGJaX8UJub=EeBuuAGvwS7mLphdGyEKqoUast_5pL2=puq-qg@mail.gmail.com>
References: <CAFdSV9vWi5T-rLFwV1pki_0+aqdSHg7JG0s1btzCjSYicC7_nA@mail.gmail.com>
	<CADGJaX8UJub=EeBuuAGvwS7mLphdGyEKqoUast_5pL2=puq-qg@mail.gmail.com>
Message-ID: <CAFdSV9t-g27GBUz_FfbKBNDEcqtSyMK1cX=QOdF7eVorfXUk6Q@mail.gmail.com>

Well there is still a lot of issues scheduled for `5.0.0+`.  Those would
all need to be resolved.  And there are a few others like Radim is asking
for some changes to the caching SPI.

On Fri, Jul 24, 2015 at 7:08 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> +1
>
> When do you plan to do it, next Wednesday?
>
>
> 2015-07-24 14:05 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> I am feeling like so many changes to SPIs have piled up on master since
>> CR2
>> that another CR is warranted.  Everyone ok with doing a CR3?
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Fri Jul 24 08:32:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Jul 2015 12:32:52 +0000
Subject: [hibernate-dev] Next 5.0 release
In-Reply-To: <CAFdSV9t-g27GBUz_FfbKBNDEcqtSyMK1cX=QOdF7eVorfXUk6Q@mail.gmail.com>
References: <CAFdSV9vWi5T-rLFwV1pki_0+aqdSHg7JG0s1btzCjSYicC7_nA@mail.gmail.com>
	<CADGJaX8UJub=EeBuuAGvwS7mLphdGyEKqoUast_5pL2=puq-qg@mail.gmail.com>
	<CAFdSV9t-g27GBUz_FfbKBNDEcqtSyMK1cX=QOdF7eVorfXUk6Q@mail.gmail.com>
Message-ID: <CAFdSV9tVd4JrBiQAVoWcc1J5pn14k2HEH-L3YTyCVijS=WGWMA@mail.gmail.com>

Clarification... the issues scheduled for 5.0.0+ all need to be resolved
*or* moved from 5.0.0+

On Fri, Jul 24, 2015 at 7:32 AM Steve Ebersole <steve at hibernate.org> wrote:

> Well there is still a lot of issues scheduled for `5.0.0+`.  Those would
> all need to be resolved.  And there are a few others like Radim is asking
> for some changes to the caching SPI.
>
> On Fri, Jul 24, 2015 at 7:08 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> +1
>>
>> When do you plan to do it, next Wednesday?
>>
>>
>> 2015-07-24 14:05 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> I am feeling like so many changes to SPIs have piled up on master since
>>> CR2
>>> that another CR is warranted.  Everyone ok with doing a CR3?
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From hardy at hibernate.org  Fri Jul 24 09:34:51 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 24 Jul 2015 15:34:51 +0200
Subject: [hibernate-dev] [OGM] GridDialect facets
In-Reply-To: <CADGJaX_8GzyqvWg61poXSwkqLeiVo8L262cGhpaE8-YpCD_PuQ@mail.gmail.com>
References: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
	<20150724083219.GB55673@Nineveh.lan>
	<CADGJaX_8GzyqvWg61poXSwkqLeiVo8L262cGhpaE8-YpCD_PuQ@mail.gmail.com>
Message-ID: <20150724133451.GC55673@Nineveh.lan>

On Fri, Jul 24, 2015 at 11:01:43AM +0200, Gunnar Morling wrote:
> > > I have been adding a facet to GridDialect and found it surprisingly hard:
> >
> > What is a facet in this context. I've seen you guys using this term on IRC
> > as well,
> > but I am not sure what you mean with it in relation to a GridDialect.
> >
> 
> It's our way to model different (optional) capabilities of data stores.
> 
> The main contract is GridDialect which offers the basic functionality each
> store needs to support (getTuple(), insertOrUpdateAssocation() and so on).
> Then there are several sub-types of it (e.g. QueryableGridDialect,
> OptimisticLockingAwareGridDialect etc.) which allow a dialect to expose
> advanced (or more efficient) functionality. Depending on which capabilities
> a store exposes that way, engine will make use of it.

Got it, thanks. 

> >  which non datastore dialects was supposed to implement the facet
> >
> > non datastore dialect? Is it not one dialect per datastore?
> >
> 
> Davide's answer says it :)

+1 Thanks both of you. Always helps to understand the lingo.

--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/20150724/310243b0/attachment.bin 

From daltodavide at gmail.com  Fri Jul 24 10:16:51 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 24 Jul 2015 15:16:51 +0100
Subject: [hibernate-dev] [OGM] GridDialect facets
In-Reply-To: <20150724133451.GC55673@Nineveh.lan>
References: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
	<20150724083219.GB55673@Nineveh.lan>
	<CADGJaX_8GzyqvWg61poXSwkqLeiVo8L262cGhpaE8-YpCD_PuQ@mail.gmail.com>
	<20150724133451.GC55673@Nineveh.lan>
Message-ID: <CANoTJYMLAyNDEj=ew_qWw0b535NDQRR_Ba1Fa4HRux51Ouv=9g@mail.gmail.com>

>> Right, we could create an empty interface to flag them.

> They all extend GridDialect already. Is there any easier way for an
dialect provider to learn about all the facets than inspecting the type
hierarchy of GridDialect?

I guess the point is to distinguish between the main datastore dialect, the
decorators and the optional facets. You cannot do that looking only at the
hierarchy.



On Fri, Jul 24, 2015 at 2:34 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> On Fri, Jul 24, 2015 at 11:01:43AM +0200, Gunnar Morling wrote:
> > > > I have been adding a facet to GridDialect and found it surprisingly
> hard:
> > >
> > > What is a facet in this context. I've seen you guys using this term on
> IRC
> > > as well,
> > > but I am not sure what you mean with it in relation to a GridDialect.
> > >
> >
> > It's our way to model different (optional) capabilities of data stores.
> >
> > The main contract is GridDialect which offers the basic functionality
> each
> > store needs to support (getTuple(), insertOrUpdateAssocation() and so
> on).
> > Then there are several sub-types of it (e.g. QueryableGridDialect,
> > OptimisticLockingAwareGridDialect etc.) which allow a dialect to expose
> > advanced (or more efficient) functionality. Depending on which
> capabilities
> > a store exposes that way, engine will make use of it.
>
> Got it, thanks.
>
> > >  which non datastore dialects was supposed to implement the facet
> > >
> > > non datastore dialect? Is it not one dialect per datastore?
> > >
> >
> > Davide's answer says it :)
>
> +1 Thanks both of you. Always helps to understand the lingo.
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jul 24 10:48:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Jul 2015 14:48:54 +0000
Subject: [hibernate-dev] database names and identifier length
Message-ID: <CAFdSV9u7dAKpXg+UbuWwpLO8CSaoDio_S9E5UkaM4hn+GWgyag@mail.gmail.com>

Do we want to consider automatically applying known database limits on
various identifier lengths?  This is trickier to implement than it might
sound.  And it would definitely need to wait for the reworking of
annotation binding.  But in general I wonder if y'all see this as a
desirable feature.  And if so, should that be just for implicit names?  Or
explicit names as well?

From manderse at redhat.com  Fri Jul 24 14:42:46 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 24 Jul 2015 20:42:46 +0200
Subject: [hibernate-dev] database names and identifier length
In-Reply-To: <CAFdSV9u7dAKpXg+UbuWwpLO8CSaoDio_S9E5UkaM4hn+GWgyag@mail.gmail.com>
References: <CAFdSV9u7dAKpXg+UbuWwpLO8CSaoDio_S9E5UkaM4hn+GWgyag@mail.gmail.com>
Message-ID: <17D9FBCA-A2AB-4B68-9BD4-CC178D5A75B1@redhat.com>

On 24 Jul 2015, at 16:48, Steve Ebersole wrote:

> Do we want to consider automatically applying known database limits on
> various identifier lengths?  This is trickier to implement than it 
> might
> sound.  And it would definitely need to wait for the reworking of
> annotation binding.  But in general I wonder if y'all see this as a
> desirable feature.  And if so, should that be just for implicit names? 
>  Or
> explicit names as well?

I could see it be valuable for easier cross db testing, but all users 
custom queries
would be easily broken unless you have something very deterministic.

If we do it think I as a user would prefer at least get a warning or be 
able to turn on "strict" mode
to catch issues where  I did not realise 
"MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED".

/max
http://about.me/maxandersen

From gbadner at redhat.com  Fri Jul 24 16:57:07 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 24 Jul 2015 16:57:07 -0400 (EDT)
Subject: [hibernate-dev] Preparing to release 4.2.20.Final and 4.3.11.Final
Message-ID: <1811350402.3648340.1437771427083.JavaMail.zimbra@redhat.com>

I am starting with the 4.2.20.Final release now. After I finish that, I may still push a few fixes before starting the release for 4.3.11.Final.

Please don't push push to 4.2 or 4.3 branches.

Thanks!
Gail

From gbadner at redhat.com  Sat Jul 25 00:11:41 2015
From: gbadner at redhat.com (Gail Badner)
Date: Sat, 25 Jul 2015 00:11:41 -0400 (EDT)
Subject: [hibernate-dev] 4.2.20.Final and SourceForge problems;
 delaying 4.3.11.Final until next week
In-Reply-To: <2029733878.11998.1437797198677.JavaMail.zimbra@redhat.com>
Message-ID: <959868370.12220.1437797501442.JavaMail.zimbra@redhat.com>

I am finished with the 4.2.20.Final release, except for uploading distributions due to problems at SourceForge. Artifacts have been successfully uploaded to nexus.

I will wait until Monday to send out an announcement in the hopes that I can upload the distributions to SourceForge by then.

There are a couple more bugfixes I'd like to get into 4.3.11.Final, so I am delaying that release until Wednesday, July 29.

Regards,
Gail

From steve at hibernate.org  Sat Jul 25 11:24:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 25 Jul 2015 15:24:27 +0000
Subject: [hibernate-dev] in.relation.to local building, Fedora 22
Message-ID: <CAFdSV9vvQru4fcXX63gV0TAcBP872DSobeO=mbyNp6dZ08E5MA@mail.gmail.com>

[sebersole at t540 in.relation.to] $ rake check
rake aborted!
Don't know how to build task 'check'

^^ expected?  `rake setup` finished successfully.  This next step failed
for me.

From steve at hibernate.org  Sat Jul 25 11:28:51 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 25 Jul 2015 15:28:51 +0000
Subject: [hibernate-dev] in.relation.to local building, Fedora 22
In-Reply-To: <CAFdSV9vvQru4fcXX63gV0TAcBP872DSobeO=mbyNp6dZ08E5MA@mail.gmail.com>
References: <CAFdSV9vvQru4fcXX63gV0TAcBP872DSobeO=mbyNp6dZ08E5MA@mail.gmail.com>
Message-ID: <CAFdSV9vDiMcBA7SrZkaTVu2HYnkYZgek1rif6ROXMvX=Fd6WsA@mail.gmail.com>

FWIW the check command failed, but then `rake preview` seems to run fine (I
can view the site locally).  I guess the severity of this depends on what
check is meant to do...

On Sat, Jul 25, 2015 at 10:24 AM Steve Ebersole <steve at hibernate.org> wrote:

> [sebersole at t540 in.relation.to] $ rake check
> rake aborted!
> Don't know how to build task 'check'
>
> ^^ expected?  `rake setup` finished successfully.  This next step failed
> for me.
>

From steve at hibernate.org  Sat Jul 25 11:43:02 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 25 Jul 2015 15:43:02 +0000
Subject: [hibernate-dev] ORM documentation translations
Message-ID: <CAFdSV9uU_c_nGB7ChzOHUZmKdXVGWOJdK9Rr8Vx+ZFCVS=WxxQ@mail.gmail.com>

Worth keeping these around anymore?  They are woefully out of date.

From steve at hibernate.org  Sat Jul 25 11:43:02 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 25 Jul 2015 15:43:02 +0000
Subject: [hibernate-dev] ORM documentation translations
Message-ID: <CAFdSV9uU_c_nGB7ChzOHUZmKdXVGWOJdK9Rr8Vx+ZFCVS=WxxQ@mail.gmail.com>

Worth keeping these around anymore?  They are woefully out of date.

From sanne at hibernate.org  Sat Jul 25 14:14:13 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 25 Jul 2015 21:14:13 +0300
Subject: [hibernate-dev] Next 5.0 release
In-Reply-To: <CAFdSV9tVd4JrBiQAVoWcc1J5pn14k2HEH-L3YTyCVijS=WGWMA@mail.gmail.com>
References: <CAFdSV9vWi5T-rLFwV1pki_0+aqdSHg7JG0s1btzCjSYicC7_nA@mail.gmail.com>
	<CADGJaX8UJub=EeBuuAGvwS7mLphdGyEKqoUast_5pL2=puq-qg@mail.gmail.com>
	<CAFdSV9t-g27GBUz_FfbKBNDEcqtSyMK1cX=QOdF7eVorfXUk6Q@mail.gmail.com>
	<CAFdSV9tVd4JrBiQAVoWcc1J5pn14k2HEH-L3YTyCVijS=WGWMA@mail.gmail.com>
Message-ID: <CAFm4XO0WDs96xfmsanyb0RLTUcKGmbqsSqBtLcUEdtcaEp9JOQ@mail.gmail.com>

+1
 On 24 Jul 2015 15:54, "Steve Ebersole" <steve at hibernate.org> wrote:

> Clarification... the issues scheduled for 5.0.0+ all need to be resolved
> *or* moved from 5.0.0+
>
> On Fri, Jul 24, 2015 at 7:32 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > Well there is still a lot of issues scheduled for `5.0.0+`.  Those would
> > all need to be resolved.  And there are a few others like Radim is asking
> > for some changes to the caching SPI.
> >
> > On Fri, Jul 24, 2015 at 7:08 AM Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> >
> >> +1
> >>
> >> When do you plan to do it, next Wednesday?
> >>
> >>
> >> 2015-07-24 14:05 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >>
> >>> I am feeling like so many changes to SPIs have piled up on master since
> >>> CR2
> >>> that another CR is warranted.  Everyone ok with doing a CR3?
> >>>
> >> _______________________________________________
> >>> 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  Sat Jul 25 14:23:03 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 25 Jul 2015 21:23:03 +0300
Subject: [hibernate-dev] database names and identifier length
In-Reply-To: <17D9FBCA-A2AB-4B68-9BD4-CC178D5A75B1@redhat.com>
References: <CAFdSV9u7dAKpXg+UbuWwpLO8CSaoDio_S9E5UkaM4hn+GWgyag@mail.gmail.com>
	<17D9FBCA-A2AB-4B68-9BD4-CC178D5A75B1@redhat.com>
Message-ID: <CAFm4XO29XT4h4BcYqGEy5cNsca8q65kv4pHAif3kiLd2iSKGsw@mail.gmail.com>

Hi Max, could you make an example please?
Looks like you are interpreting Steve's email in a different way than me.
On 24 Jul 2015 21:43, "Max Rydahl Andersen" <manderse at redhat.com> wrote:

> On 24 Jul 2015, at 16:48, Steve Ebersole wrote:
>
> > Do we want to consider automatically applying known database limits on
> > various identifier lengths?  This is trickier to implement than it
> > might
> > sound.  And it would definitely need to wait for the reworking of
> > annotation binding.  But in general I wonder if y'all see this as a
> > desirable feature.  And if so, should that be just for implicit names?
> >  Or
> > explicit names as well?
>
> I could see it be valuable for easier cross db testing, but all users
> custom queries
> would be easily broken unless you have something very deterministic.
>
> If we do it think I as a user would prefer at least get a warning or be
> able to turn on "strict" mode
> to catch issues where  I did not realise
> "MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED".
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Jul 25 15:18:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 25 Jul 2015 19:18:04 +0000
Subject: [hibernate-dev] database names and identifier length
In-Reply-To: <CAFm4XO29XT4h4BcYqGEy5cNsca8q65kv4pHAif3kiLd2iSKGsw@mail.gmail.com>
References: <CAFdSV9u7dAKpXg+UbuWwpLO8CSaoDio_S9E5UkaM4hn+GWgyag@mail.gmail.com>
	<17D9FBCA-A2AB-4B68-9BD4-CC178D5A75B1@redhat.com>
	<CAFm4XO29XT4h4BcYqGEy5cNsca8q65kv4pHAif3kiLd2iSKGsw@mail.gmail.com>
Message-ID: <CAFdSV9sf4wRgOzVX-CdFDyT70ZL_fTdp=kS5roZQeKvomLSQ-Q@mail.gmail.com>

He is talking about native (sql) queries.  If a user defines a native query
using his example column name MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED,
then when we replace that because they deploy on to "database product X"
which limits identifier lengths to 10... he worries that the users query
now fails.  But of course he glosses over the fact that the app would not
work on "database product X" with or without this change because "database
product X" simply would not support a column named
MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED (from say a mapping).

I think in general the idea of trying to combine native sql queries and
database portability is just asking for trouble.

On Sat, Jul 25, 2015 at 1:23 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Max, could you make an example please?
> Looks like you are interpreting Steve's email in a different way than me.
> On 24 Jul 2015 21:43, "Max Rydahl Andersen" <manderse at redhat.com> wrote:
>
>> On 24 Jul 2015, at 16:48, Steve Ebersole wrote:
>>
>> > Do we want to consider automatically applying known database limits on
>> > various identifier lengths?  This is trickier to implement than it
>> > might
>> > sound.  And it would definitely need to wait for the reworking of
>> > annotation binding.  But in general I wonder if y'all see this as a
>> > desirable feature.  And if so, should that be just for implicit names?
>> >  Or
>> > explicit names as well?
>>
>> I could see it be valuable for easier cross db testing, but all users
>> custom queries
>> would be easily broken unless you have something very deterministic.
>>
>> If we do it think I as a user would prefer at least get a warning or be
>> able to turn on "strict" mode
>> to catch issues where  I did not realise
>> "MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED".
>>
>> /max
>> http://about.me/maxandersen
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Sun Jul 26 03:19:27 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 26 Jul 2015 10:19:27 +0300
Subject: [hibernate-dev] database names and identifier length
In-Reply-To: <CAFdSV9sf4wRgOzVX-CdFDyT70ZL_fTdp=kS5roZQeKvomLSQ-Q@mail.gmail.com>
References: <CAFdSV9u7dAKpXg+UbuWwpLO8CSaoDio_S9E5UkaM4hn+GWgyag@mail.gmail.com>
	<17D9FBCA-A2AB-4B68-9BD4-CC178D5A75B1@redhat.com>
	<CAFm4XO29XT4h4BcYqGEy5cNsca8q65kv4pHAif3kiLd2iSKGsw@mail.gmail.com>
	<CAFdSV9sf4wRgOzVX-CdFDyT70ZL_fTdp=kS5roZQeKvomLSQ-Q@mail.gmail.com>
Message-ID: <CAFm4XO2U+OBTC+9V89VQ1dUJc9S-21wrpwxFMUPb7LXiFL63jQ@mail.gmail.com>

Thanks, got it now. Yes I think that would have value; my impression
is that taking care of such things is a general expectations among
users.
In case it had to truncate[shorten?] identifier names we'd also need
to make sure that doesn't introduce ambiguities with other column
names, and - as a user - I'd expect a warning to be logged.

Thanks,
Sanne


On 25 July 2015 at 22:18, Steve Ebersole <steve at hibernate.org> wrote:
> He is talking about native (sql) queries.  If a user defines a native query
> using his example column name
> MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED, then when we replace that
> because they deploy on to "database product X" which limits identifier
> lengths to 10... he worries that the users query now fails.  But of course
> he glosses over the fact that the app would not work on "database product X"
> with or without this change because "database product X" simply would not
> support a column named MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED
> (from say a mapping).
>
> I think in general the idea of trying to combine native sql queries and
> database portability is just asking for trouble.
>
> On Sat, Jul 25, 2015 at 1:23 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Max, could you make an example please?
>> Looks like you are interpreting Steve's email in a different way than me.
>>
>> On 24 Jul 2015 21:43, "Max Rydahl Andersen" <manderse at redhat.com> wrote:
>>>
>>> On 24 Jul 2015, at 16:48, Steve Ebersole wrote:
>>>
>>> > Do we want to consider automatically applying known database limits on
>>> > various identifier lengths?  This is trickier to implement than it
>>> > might
>>> > sound.  And it would definitely need to wait for the reworking of
>>> > annotation binding.  But in general I wonder if y'all see this as a
>>> > desirable feature.  And if so, should that be just for implicit names?
>>> >  Or
>>> > explicit names as well?
>>>
>>> I could see it be valuable for easier cross db testing, but all users
>>> custom queries
>>> would be easily broken unless you have something very deterministic.
>>>
>>> If we do it think I as a user would prefer at least get a warning or be
>>> able to turn on "strict" mode
>>> to catch issues where  I did not realise
>>> "MY_SUPER_AWESOME_COLUMN_NAME_CANT_ALWAYS_BE_USED".
>>>
>>> /max
>>> http://about.me/maxandersen
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Sun Jul 26 04:03:42 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 26 Jul 2015 11:03:42 +0300
Subject: [hibernate-dev] MySQL versus MariaDB
In-Reply-To: <CAFdSV9tu_skmNuSL4XbbR-qzDgbmo+yusanGeox3tftSDXm85g@mail.gmail.com>
References: <CAFdSV9toQYAhQYobojXipYOr_CCqTwZjs3B35m58hCL3MY6wiQ@mail.gmail.com>
	<CAFdSV9tu_skmNuSL4XbbR-qzDgbmo+yusanGeox3tftSDXm85g@mail.gmail.com>
Message-ID: <CAFm4XO1ActOiDf8noXMG0YyxAREpatPbZO6eda3xSubDrh-D5A@mail.gmail.com>

Looks like we'll want to have both MariaDB and MySQL on ci.hibernate.org then:
 - https://hibernate.atlassian.net/browse/WEBSITE-383

On 22 July 2015 at 22:51, Steve Ebersole <steve at hibernate.org> wrote:
> https://hibernate.atlassian.net/browse/HHH-9969
>
> On Wed, Jul 22, 2015 at 2:18 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> As I have developed the matrix tests against MariaDB I have had in the
>> back of my head whether we might want to develop a Dialect for MariaDB.  As
>> I understand it, MariaDB does strive to remain compatible with MySQL but it
>> does offer some enhancements.  And it might have some minor deviations.
>> Today I think I found one such deviation, in their respective support for
>> casting decimal/floating-point values.  I came across this because of some
>> failed tests.
>>
>> There are quite a few resolved issues in Jira wrt MySQL and casting.  So I
>> have to assume these tests work on MySQL which tells me there is a
>> deviation in their behavior...
>>
>> The tests in question (more or less) do: "select ... cast( x as
>> big_decimal ) ...".  We understand big_decimal as java.sql.Types#NUMERIC
>> for which the MySQL Dialect says to use "decimal" for casting purposes.
>>
>> On MariaDB at least "decimal" (no precision) leads to a data trunction.
>> We are expecting a value like "12.399999618530273" but get back "12.0".
>> Because for MariaDB DECIMAL is equivalent to DECIMAL(10,0).
>>
>> So as it is, for this minor case at least the MySQL dialects work against
>> MySQL databases (we assume) but fail against MariaDB databases.
>>
>> The other difficulty with a dialect specific for MariaDB is
>> auto-detection.  The MariaDB JDBC drivers report the underlying database as
>> mysql.
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Sun Jul 26 04:11:03 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 26 Jul 2015 11:11:03 +0300
Subject: [hibernate-dev] MariaDB on CI
In-Reply-To: <CAFdSV9vvsqCofzaSVLgzPdB465Hu2LgQhX=Pn6W_fXpE=E+ZhA@mail.gmail.com>
References: <CAFdSV9vaAWQbE9HO0qz04FyTJ9dXPimS6VmWab+zA=Rz12NVFw@mail.gmail.com>
	<CAFm4XO33Hf0fX2ckB_t1zpPt8oZdXPstmxB0EG4j+rphaQ-ruQ@mail.gmail.com>
	<CAFdSV9twdX6qVom-B490HqH3--=Kt1pKGQrqg7ZgMU=1qQ6i7w@mail.gmail.com>
	<CAFm4XO1mrw5wVKyvhAKED=qwrg_+kKFFj19yHnu_ut3+9UgcXA@mail.gmail.com>
	<CAFdSV9vvsqCofzaSVLgzPdB465Hu2LgQhX=Pn6W_fXpE=E+ZhA@mail.gmail.com>
Message-ID: <CAFm4XO33m-tZs8YDXUu7htMH2wYc6kCRidO=jaa+t8rrh1XCew@mail.gmail.com>

On 23 July 2015 at 17:41, Steve Ebersole <steve at hibernate.org> wrote:
> Another change is to make sure our test user has create/drop privileges on
> all databases, and to be able to create/drop databases:
>
> grant create, drop on *.* to 'hibernate_orm_test'@'localhost';
>
> We will need similar for the other databases too.

That limitation was actually intentional.

I think most users will have Hibernate connect via a
limited-privileged user, so you don't think there would be value in us
actually testing using the more limited privileges?

I'm ok to change it, but - unless it's too inconvenient to get current
tests reliable - I'd prefer to create a second user for when test
infrastructure code need to create/drop databases. Why are you needing
this?

-- Sanne

>
>
>
> On Tue, Jul 21, 2015 at 6:02 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 20 July 2015 at 17:41, Steve Ebersole <steve at hibernate.org> wrote:
>> > Sanne for MariaDB (and MySQL if we ever add it) we need to add at least
>> > one
>> > more setting:
>> >
>> > sql-mode="traditional"
>>
>> I've applied this change.
>>
>> --Sanne
>>
>> >
>> > We could probably get away with less ANSI compliant mode, but after days
>> > playing with this I just want to cover my bases :)
>> >
>> > On Sat, Jul 18, 2015 at 3:37 PM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> Thanks, great suggestions!
>> >> I've applied these and some more.
>> >>
>> >> The MariaDB configuration:
>> >>  -
>> >>
>> >> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/mariadb-server/files/my.cnf
>> >>
>> >> The PosgreSQL configuration files:
>> >>  -
>> >>
>> >> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/pg_hba.conf
>> >>  -
>> >>
>> >> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/postgresql.conf
>> >>
>> >> Both are running with these settings now on each CI slave.
>> >> Sanne
>> >>
>> >> On 18 July 2015 at 00:49, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > [18:45] <sebersole> whoa..
>> >> > [18:45] <sebersole> sannegrinovero: we definitely need this for
>> >> > mariadb
>> >> > on
>> >> > ci...
>> >> > [18:46] <sebersole> sync_binlog=0 innodb_flush_log_at_trx_commit=0
>> >> > innodb_doublewrite=0
>> >> > [18:46] <sebersole> tests were much faster
>> >> >
>> >> > These were suggested to me on the #mariadb list.  I added them to my
>> >> > local
>> >> > /etc/my.cnf file and the tests were significantly faster.
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Sun Jul 26 15:12:16 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Sun, 26 Jul 2015 21:12:16 +0200
Subject: [hibernate-dev] 4.2.20.Final and SourceForge problems;
 delaying 4.3.11.Final until next week
In-Reply-To: <959868370.12220.1437797501442.JavaMail.zimbra@redhat.com>
References: <2029733878.11998.1437797198677.JavaMail.zimbra@redhat.com>
	<959868370.12220.1437797501442.JavaMail.zimbra@redhat.com>
Message-ID: <20150726191216.GA75369@Nineveh.lan>

Hi,

On Sat, Jul 25, 2015 at 12:11:41AM -0400, Gail Badner wrote:
> I am finished with the 4.2.20.Final release, except for uploading distributions due to problems at SourceForge.

FYI, I am having the same issue. I am waiting for a week now to upload the Validator release.
Initially, there were even no buttons to create folders or upload anything. Now they are back, but
don't work (I've just tried again). ssh upload does not work either. 

SourceForge had some major outage, but seems unable to full recover. I am not sure how much longer
we should wait. Right now I am drawn between these options

* announce the release mentioning that the artifacts will be uploaded if and when SourceForge works again
* upload the artifacts to GitHub and link to there
* keep waiting

--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/20150726/aa410a13/attachment-0001.bin 

From hardy at hibernate.org  Sun Jul 26 15:13:55 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Sun, 26 Jul 2015 21:13:55 +0200
Subject: [hibernate-dev] in.relation.to local building, Fedora 22
In-Reply-To: <CAFdSV9vDiMcBA7SrZkaTVu2HYnkYZgek1rif6ROXMvX=Fd6WsA@mail.gmail.com>
References: <CAFdSV9vvQru4fcXX63gV0TAcBP872DSobeO=mbyNp6dZ08E5MA@mail.gmail.com>
	<CAFdSV9vDiMcBA7SrZkaTVu2HYnkYZgek1rif6ROXMvX=Fd6WsA@mail.gmail.com>
Message-ID: <20150726191355.GB75369@Nineveh.lan>

On Sat, Jul 25, 2015 at 03:28:51PM +0000, Steve Ebersole wrote:
> FWIW the check command failed, but then `rake preview` seems to run fine (I
> can view the site locally).

The 'check' task is obsolete. It really only verified bundler and rake were installed.
I am in the process of updating the readme and will remove the mention of the 'check' task
at the same time.

--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/20150726/8ab514fb/attachment.bin 

From gunnar at hibernate.org  Mon Jul 27 04:14:19 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 27 Jul 2015 10:14:19 +0200
Subject: [hibernate-dev] [OGM] GridDialect facets
In-Reply-To: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
References: <F082B97D-FE2D-4F15-9E69-EDEE3804D726@hibernate.org>
Message-ID: <CADGJaX_9BSaght0jWo08pTTnKbLLO9rTn5P_y7ECFLODYzn9rQ@mail.gmail.com>

2015-07-24 9:56 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I have been adding a facet to GridDialect and found it surprisingly hard:
>
> * I was not sure which non datastore dialects was supposed to implement
> the facet nor really how to find these non datastore dialects. I am talking
> about GridDialectLogger, ForwardingGridDialect and
> InvokedOperationsLoggingDialect. I am sure there are more of these non
> datastore dialects but I haven?t found them.
>

If there are better ideas for this I am all for it. So far I didn't find
one (but then I didn't put much time into thinking about it as it didn't
occur as a huge issue to me so far).

* ForwardingGridDialect is the base for all dialects wishing to apply some
decorating logic (logging, batch aggregation etc.) prior to delegating to
the underlying dialect, so I don't think it'll go away.
* GridDialectLogger: I am no big fan of this either. Maybe we can drop it
once we implemented logging of actual datastore interactions in the
dialects?
* InvokedOperationsLoggingDialect: Used in tests for asserting invoked
dialect operations; It's very useful for that. I initially hoped the
compensation SPI could be re-used for that, but there we only collect
mutating methods, i.e. no calls to getTuple() etc. It could be implemented
generically w/ a proxy, there should be no harm to that as it's test-only

* Adding one method, to a facet means having to go to a lot of places to
> write all these logging and delegating logics. Changing a method sig a
> least gives you the help of the compiler but not for adding them.
>

When adding a new facet, the first step would be to add it to
ForwardingGridDialect. Then you'd have to decide to which of the auxiliary
dialect decorators you need to add it (e.g. for logging, batching).


> * Find how consumers of the facet are supposed to use them was not obvious
> to me. It seems a given consumer stores all the possible facets as class
> field and do a null check before using them.
>

Yes, that's the usage pattern. Alternative would be to rely on getting the
dialect only + instanceof, but the current one seems nicer to me. Again, if
there a better ideas, let's change it. Maybe some unwrap() or as() method
on an internal GridDialect extension, GridDialectImplementor?


> * when I finally ran my tests everything exploded because each facet must
> have a MyFacetInitiator
> * when I added the initiator, it still blew up at my face because each
> Initiator must be listed in the OgmIntegrator
>

Ok, but that's standard service registry business. Not sure whether there
is a way around it.


> * I?m also concerned about facet discoverability, I don?t think it?s
> trivial for a dialect implementor to get the list of facets easily, which
> will tend to bring minimal dialects without the advanced features.
>

I think they are apparent in the type hierarchy. We could start some grid
dialect developer guide and describe all the optional facets there.

I wonder if and / or how we should improve that state of affairs.
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Jul 27 09:38:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 27 Jul 2015 13:38:59 +0000
Subject: [hibernate-dev] ORM Documentation
Message-ID: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>

I have been putting a lot of TLC into the ORM documentation this weekend
getting ready for 5.0 to go Final.  To that end I have put together a
proposal for these changes, it is attached.  I'd like to get some
feedback.  Thanks

From steve at hibernate.org  Mon Jul 27 11:02:56 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 27 Jul 2015 15:02:56 +0000
Subject: [hibernate-dev] MariaDB on CI
In-Reply-To: <CAFm4XO33m-tZs8YDXUu7htMH2wYc6kCRidO=jaa+t8rrh1XCew@mail.gmail.com>
References: <CAFdSV9vaAWQbE9HO0qz04FyTJ9dXPimS6VmWab+zA=Rz12NVFw@mail.gmail.com>
	<CAFm4XO33Hf0fX2ckB_t1zpPt8oZdXPstmxB0EG4j+rphaQ-ruQ@mail.gmail.com>
	<CAFdSV9twdX6qVom-B490HqH3--=Kt1pKGQrqg7ZgMU=1qQ6i7w@mail.gmail.com>
	<CAFm4XO1mrw5wVKyvhAKED=qwrg_+kKFFj19yHnu_ut3+9UgcXA@mail.gmail.com>
	<CAFdSV9vvsqCofzaSVLgzPdB465Hu2LgQhX=Pn6W_fXpE=E+ZhA@mail.gmail.com>
	<CAFm4XO33m-tZs8YDXUu7htMH2wYc6kCRidO=jaa+t8rrh1XCew@mail.gmail.com>
Message-ID: <CAFdSV9uS5DdcHEqNcFk8=-hwf=e1_-bnWdXV4Onzyj+via-h7g@mail.gmail.com>

Well the problem is that we have a few multi-catalog/schema tests: tests
that specifically test referring to objects from multiple
catalogs/schemas.  And on top of that we have schema export tests that test
being able to create catalogs and schemas.

So we have a few options.  We can pre-determine all the needed catalogs and
schemas and make sure we set those up in the database server ahead of time.


But that still leaves problems with the schema-export tests for creating
namespaces.  That is a feature we need to be able to test.  Some databases
simply won't be able to support this (Oracle).  We could do something
similar in terms of allowing a determinate set of catalogs/schemas to be
created.  A few databases actually allow specifying which catalogs/schemas
can be created (by what users); so we could explore that as well.  Another
option is to define 2 users for Hibernate ORM tests: one with normal privs
and one with elevated privs.


On Sun, Jul 26, 2015 at 3:11 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 23 July 2015 at 17:41, Steve Ebersole <steve at hibernate.org> wrote:
> > Another change is to make sure our test user has create/drop privileges
> on
> > all databases, and to be able to create/drop databases:
> >
> > grant create, drop on *.* to 'hibernate_orm_test'@'localhost';
> >
> > We will need similar for the other databases too.
>
> That limitation was actually intentional.
>
> I think most users will have Hibernate connect via a
> limited-privileged user, so you don't think there would be value in us
> actually testing using the more limited privileges?
>
> I'm ok to change it, but - unless it's too inconvenient to get current
> tests reliable - I'd prefer to create a second user for when test
> infrastructure code need to create/drop databases. Why are you needing
> this?
>
> -- Sanne
>
> >
> >
> >
> > On Tue, Jul 21, 2015 at 6:02 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> On 20 July 2015 at 17:41, Steve Ebersole <steve at hibernate.org> wrote:
> >> > Sanne for MariaDB (and MySQL if we ever add it) we need to add at
> least
> >> > one
> >> > more setting:
> >> >
> >> > sql-mode="traditional"
> >>
> >> I've applied this change.
> >>
> >> --Sanne
> >>
> >> >
> >> > We could probably get away with less ANSI compliant mode, but after
> days
> >> > playing with this I just want to cover my bases :)
> >> >
> >> > On Sat, Jul 18, 2015 at 3:37 PM Sanne Grinovero <sanne at hibernate.org>
> >> > wrote:
> >> >>
> >> >> Thanks, great suggestions!
> >> >> I've applied these and some more.
> >> >>
> >> >> The MariaDB configuration:
> >> >>  -
> >> >>
> >> >>
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/mariadb-server/files/my.cnf
> >> >>
> >> >> The PosgreSQL configuration files:
> >> >>  -
> >> >>
> >> >>
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/pg_hba.conf
> >> >>  -
> >> >>
> >> >>
> https://github.com/hibernate/ci.hibernate.org/blob/master/roles/postgres-server/files/postgresql.conf
> >> >>
> >> >> Both are running with these settings now on each CI slave.
> >> >> Sanne
> >> >>
> >> >> On 18 July 2015 at 00:49, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> >> > [18:45] <sebersole> whoa..
> >> >> > [18:45] <sebersole> sannegrinovero: we definitely need this for
> >> >> > mariadb
> >> >> > on
> >> >> > ci...
> >> >> > [18:46] <sebersole> sync_binlog=0 innodb_flush_log_at_trx_commit=0
> >> >> > innodb_doublewrite=0
> >> >> > [18:46] <sebersole> tests were much faster
> >> >> >
> >> >> > These were suggested to me on the #mariadb list.  I added them to
> my
> >> >> > local
> >> >> > /etc/my.cnf file and the tests were significantly faster.
> >> >> > _______________________________________________
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jul 27 11:47:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 27 Jul 2015 15:47:06 +0000
Subject: [hibernate-dev] ORM Documentation
In-Reply-To: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
References: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
Message-ID: <CAFdSV9u1mmcdeHTMDqQyi0p_FY8QJZ0-L5VvEaiQwEVOq4FcjA@mail.gmail.com>

Forgot our list strips attachments :)

https://github.com/hibernate/hibernate-orm/wiki/Documentation-proposal


On Mon, Jul 27, 2015 at 8:38 AM Steve Ebersole <steve at hibernate.org> wrote:

> I have been putting a lot of TLC into the ORM documentation this weekend
> getting ready for 5.0 to go Final.  To that end I have put together a
> proposal for these changes, it is attached.  I'd like to get some
> feedback.  Thanks
>

From sanne at hibernate.org  Mon Jul 27 12:36:30 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 27 Jul 2015 19:36:30 +0300
Subject: [hibernate-dev] ORM Documentation
In-Reply-To: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
References: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
Message-ID: <CAFm4XO0oSks8ME74=hMj2e4F2g5fFdiEh2VSsfcYmGgmjRz2pA@mail.gmail.com>

I didn't receive an attachment. AFAIK the mailing list drops them?
On 27 Jul 2015 14:39, "Steve Ebersole" <steve at hibernate.org> wrote:

> I have been putting a lot of TLC into the ORM documentation this weekend
> getting ready for 5.0 to go Final.  To that end I have put together a
> proposal for these changes, it is attached.  I'd like to get some
> feedback.  Thanks
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jul 27 18:10:08 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 27 Jul 2015 22:10:08 +0000
Subject: [hibernate-dev] ORM Documentation
In-Reply-To: <CAFm4XO0oSks8ME74=hMj2e4F2g5fFdiEh2VSsfcYmGgmjRz2pA@mail.gmail.com>
References: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
	<CAFm4XO0oSks8ME74=hMj2e4F2g5fFdiEh2VSsfcYmGgmjRz2pA@mail.gmail.com>
Message-ID: <CAFdSV9uckVaAyyYZvScH9dAXs_0EEhWaGqKh=5B7QtnroPyeqA@mail.gmail.com>

Sanne, yep thats why I sent the second email with a link ;)

Anyway..  I just pushed some initial work on the manual.  Its not complete
yet.  And I still need to start on the mapping guide.  Let me know any
thoughts y'all have.


On Mon, Jul 27, 2015 at 2:31 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> I didn't receive an attachment. AFAIK the mailing list drops them?
> On 27 Jul 2015 14:39, "Steve Ebersole" <steve at hibernate.org> wrote:
>
>> I have been putting a lot of TLC into the ORM documentation this weekend
>> getting ready for 5.0 to go Final.  To that end I have put together a
>> proposal for these changes, it is attached.  I'd like to get some
>> feedback.  Thanks
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From emmanuel at hibernate.org  Tue Jul 28 03:39:07 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 28 Jul 2015 09:39:07 +0200
Subject: [hibernate-dev] Hosting of binaries
Message-ID: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>

As some of you know Sourceforge has had a severe distributed file system corruption and they have been working on it for a full week. You can read their blog for regular updates http://sourceforge.net/blog/
The concrete issue for us is that we cannot upload new files: Hibernate Validator and Hibernate ORM are now pending a release.

There are 4 options on the table

Be patient::
SourceForge will eventually reopen upload, I imagine it might take form one to two weeks.
Their binary hosting support is relatively correct and all of our download statistics are there.

Move to download.jboss.org::
JBoss has a facility to host binaries. WildFly amongst other uses it. We can ask them if they are happy with it.
It is not connected to the rest of the forum/CMS infra, it?s a simple file upload AFAIK so easily scriptable.
They also offer statistics but how needs to be investigated.

Move to GitHub::
GitHub has a binary upload facility. I could only find a web based approach (can it be done programmatically?).
They don?t seem to have any statistics service, which is a big negative point.
Also I don?t trust GitHub anymore for their binary hosting. They had a version in the past that they scrapped with barely no notice. I?m not exactly willing to give them my trust again.

Move to BinTray::
Binary hosting is their life and blood. People seem happy with them. It seems however that the statistics require a paying package instead of the free oss tier.

I think we should try in the following order:

1. Be patient with Sourceforge (but for how long?)
2. go for download.jboss.org and before that ask around for the process and stability of the infrastructure
3. explore Bintray
4. GitHub (did I say that I no longer trust their binary hosting support?)

From sanne at hibernate.org  Tue Jul 28 03:58:06 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 28 Jul 2015 10:58:06 +0300
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
Message-ID: <CAFm4XO2XfHSid3FWpG3ctHrnPb-_pecK76cDHDgRQC6XUCEj8A@mail.gmail.com>

+1, same order of preference.

I'd add that when SourceForge was recently in the news because of
their ethical mistakes, I thought we should move.. but that seems to
have calmed down so my preference would be to stay there still for
historical reasons: good for users to have a stable home for the long
term.

We don't need to keep releases on hold right? I'd say release stuff as
usual, and archive the tarballs for deferred uploads to SF, even if it
takes a month to fix that's not a blocking issue for us, as long as we
have Maven repositories.

JBoss.org's mirror system sounds tempting. Since both are scriptable,
we could upload to both (not to SF for the moment), and slowly
deprecate SF? To keep stability in the long term, we'd need to move to
a system in which we own the URL (should be listed as hibernate.org).

Sanne

On 28 July 2015 at 10:39, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> As some of you know Sourceforge has had a severe distributed file system corruption and they have been working on it for a full week. You can read their blog for regular updates http://sourceforge.net/blog/
> The concrete issue for us is that we cannot upload new files: Hibernate Validator and Hibernate ORM are now pending a release.
>
> There are 4 options on the table
>
> Be patient::
> SourceForge will eventually reopen upload, I imagine it might take form one to two weeks.
> Their binary hosting support is relatively correct and all of our download statistics are there.
>
> Move to download.jboss.org::
> JBoss has a facility to host binaries. WildFly amongst other uses it. We can ask them if they are happy with it.
> It is not connected to the rest of the forum/CMS infra, it?s a simple file upload AFAIK so easily scriptable.
> They also offer statistics but how needs to be investigated.
>
> Move to GitHub::
> GitHub has a binary upload facility. I could only find a web based approach (can it be done programmatically?).
> They don?t seem to have any statistics service, which is a big negative point.
> Also I don?t trust GitHub anymore for their binary hosting. They had a version in the past that they scrapped with barely no notice. I?m not exactly willing to give them my trust again.
>
> Move to BinTray::
> Binary hosting is their life and blood. People seem happy with them. It seems however that the statistics require a paying package instead of the free oss tier.
>
> I think we should try in the following order:
>
> 1. Be patient with Sourceforge (but for how long?)
> 2. go for download.jboss.org and before that ask around for the process and stability of the infrastructure
> 3. explore Bintray
> 4. GitHub (did I say that I no longer trust their binary hosting support?)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From hardy at hibernate.org  Tue Jul 28 04:04:37 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 28 Jul 2015 10:04:37 +0200
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
Message-ID: <20150728080437.GB22458@Nineveh.lan>

Hi,

> 1. Be patient with Sourceforge (but for how long?)

+1, question is whether we go ahead with the releases and just mention
on the blog that binary package will be available (one day) in the future.
At least we can go on with things. 

> 2. go for download.jboss.org and before that ask around for the process and stability of the infrastructure

+1 I liked the idea of having the binary releases where the source is aka on GitHub, but as you say,
there are no statistics, the whole things seems to be purely web UI driven and there might be no guarantee
on whether this will work in the future. 

Maybe we could already reach out to the people in charge of download.jboss.org to find out

#a can we even use their service
#b how does it work (simple scp upload!?)

If we ever go down the jboss.org path, do we want to migrate the existing binary releases from SourceForge?

--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/20150728/5800f7fe/attachment.bin 

From emmanuel at hibernate.org  Tue Jul 28 04:24:36 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 28 Jul 2015 10:24:36 +0200
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <20150728080437.GB22458@Nineveh.lan>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<20150728080437.GB22458@Nineveh.lan>
Message-ID: <D8198511-F29F-481B-818F-333D2E4A0F7C@hibernate.org>


> On 28 Jul 2015, at 10:04, Hardy Ferentschik <hardy at hibernate.org> wrote:
> 
> Maybe we could already reach out to the people in charge of download.jboss.org to find out

> 
> #a can we even use their service
> #b how does it work (simple scp upload!?)

Can someone lead that exchange. With me dropping subjects and going on PTO end of the week, I?m not the best candidate.

> 
> If we ever go down the jboss.org path, do we want to migrate the existing binary releases from SourceForge?

I think we should migrate them for backup purposes regardless of any move we do.

From emmanuel at hibernate.org  Tue Jul 28 04:25:01 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 28 Jul 2015 10:25:01 +0200
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <D8198511-F29F-481B-818F-333D2E4A0F7C@hibernate.org>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<20150728080437.GB22458@Nineveh.lan>
	<D8198511-F29F-481B-818F-333D2E4A0F7C@hibernate.org>
Message-ID: <CBD02FAC-7C0A-4B2E-9C84-DC2BA22BC5DE@hibernate.org>


> On 28 Jul 2015, at 10:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> 
>> If we ever go down the jboss.org <http://jboss.org/> path, do we want to migrate the existing binary releases from SourceForge?
> 
> I think we should migrate them for backup purposes regardless of any move we do.

s/migrate/copy/

From gunnar at hibernate.org  Tue Jul 28 04:27:59 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 28 Jul 2015 10:27:59 +0200
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
Message-ID: <CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>

Your proposed order seems good. I'd exclude GitHub if it's not scriptable
(UI only) as this will hinder releases from the CI server.

2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> As some of you know Sourceforge has had a severe distributed file system
> corruption and they have been working on it for a full week. You can read
> their blog for regular updates http://sourceforge.net/blog/
> The concrete issue for us is that we cannot upload new files: Hibernate
> Validator and Hibernate ORM are now pending a release.
>
> There are 4 options on the table
>
> Be patient::
> SourceForge will eventually reopen upload, I imagine it might take form
> one to two weeks.
> Their binary hosting support is relatively correct and all of our download
> statistics are there.
>
> Move to download.jboss.org::
> JBoss has a facility to host binaries. WildFly amongst other uses it. We
> can ask them if they are happy with it.
> It is not connected to the rest of the forum/CMS infra, it?s a simple file
> upload AFAIK so easily scriptable.
> They also offer statistics but how needs to be investigated.
>
> Move to GitHub::
> GitHub has a binary upload facility. I could only find a web based
> approach (can it be done programmatically?).
> They don?t seem to have any statistics service, which is a big negative
> point.
> Also I don?t trust GitHub anymore for their binary hosting. They had a
> version in the past that they scrapped with barely no notice. I?m not
> exactly willing to give them my trust again.
>
> Move to BinTray::
> Binary hosting is their life and blood. People seem happy with them. It
> seems however that the statistics require a paying package instead of the
> free oss tier.
>
> I think we should try in the following order:
>
> 1. Be patient with Sourceforge (but for how long?)
> 2. go for download.jboss.org and before that ask around for the process
> and stability of the infrastructure
> 3. explore Bintray
> 4. GitHub (did I say that I no longer trust their binary hosting support?)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Tue Jul 28 08:38:22 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 28 Jul 2015 08:38:22 -0400
Subject: [hibernate-dev] Next 5.0 release
In-Reply-To: <CAFdSV9vWi5T-rLFwV1pki_0+aqdSHg7JG0s1btzCjSYicC7_nA@mail.gmail.com>
References: <CAFdSV9vWi5T-rLFwV1pki_0+aqdSHg7JG0s1btzCjSYicC7_nA@mail.gmail.com>
Message-ID: <55B777BE.3040107@redhat.com>

On 07/24/2015 08:05 AM, Steve Ebersole wrote:
> I am feeling like so many changes to SPIs have piled up on master since CR2
> that another CR is warranted.  Everyone ok with doing a CR3?

Yes, CR3 sounds good.  I ran the EE TCK last night with the 5.0.1 ORM 
snapshot and we are passing the JPA tests.  As we discussed yesterday, 
we will do the same testing again tonight (with the latest snapshot).

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

From sanne at hibernate.org  Tue Jul 28 10:07:37 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 28 Jul 2015 17:07:37 +0300
Subject: [hibernate-dev] [OGM] Thoughts for the Infinispan / Hot Rod dialect
Message-ID: <CAFm4XO2Vr99679RM-TABOefB41WpWNjrShnG9X2R2_mdynrYCw@mail.gmail.com>

Hi all,
with Infinispan in embedded mode we used AtomicMaps and
FineGrainedAtomicMaps as an alternative way to map attributes and
relations.

In particular the relations are interesting because in SQL world one
would run a query on junction tables, and on Infinispan embedded
queries would only be an option on Hibernate Search / Infinispan Query
annotated attributes, and also the AtomicMaps allow us to only load
the section of relevant data (like on a RDBMs).
The difference between the two kinds of AtomicMaps is in the locking
level, each similar to the same kind of locking we'd normally have.

On Hot Rod, AtomicMaps are not available so we opened (a long time
ago) a feature request to implement them for Hot Rod - at least Java
clients. Still, we don't have transactions in this case either so the
locking benefits are also unavailable.

I think that in the case of Hot Rod clients we should not use
AtomicMaps, but rather resort to a protobuf schema generation, and
essentially use the more traditional "query on jointables" approach.
Hot Rod nowadays supports queries, and they can be indexed or non
indexed so we could enable indexing on the ad-hoc tables we build for
relations mapping, have the user "opt in" for additional indexes, and
still allow some level of querying for the fields which have not been
indexed; of course w/o join operations.

We can generate an appropriate schema and upload it to Hot Rod
automatically; that sounds like a great usability improvement for all
Java clients dealing with Infinispan/remote, as its schema ads quite
some stuff to the learning curve.
Still, this automatic generation is a new and challenging field; some notes:
 - protobuf schemas are generational -> more effective if you can
generate the new one based on the existing one
 - there's a Java encoder by Adrian here:
https://github.com/infinispan/protostream
 - Typically one would need to assign a stable sequence id to each field
 - previous points will likely want us to dump the output resource
somewhere, maybe even persist on Infinispan?

On a very different topic, we also typically require from a
GridDialect implementor to provide sequence generation capability. I
don't see a solution for that over Hot Rod, it doesn't currently have
any safe incremental id, but when I asked today I was told that
Infinispan 8 might have it; Tristan pointed out you can upload a
script and have it run on the server, which in turn has access to the
transactions API so this should be possible but doesn't look too easy.

Finally, we'll need using the distributed remote iterator for
GridDialect#forEachTuple.

So my conclusion is that to support Hot Rod we'd be better off to make
a completely different GridDialect than the one for Infinispan
embedded, as I can hardly see some shared code.

Would you agree on try basing the approach on a brand new dialect and
on protobuf schema generation? In terms of features, we can implement
them all except:
 - transactions & locks
 - join queries

Thanks,
Sanne

From steve at hibernate.org  Tue Jul 28 13:51:39 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Jul 2015 17:51:39 +0000
Subject: [hibernate-dev] ORM Documentation
In-Reply-To: <CAFdSV9uckVaAyyYZvScH9dAXs_0EEhWaGqKh=5B7QtnroPyeqA@mail.gmail.com>
References: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
	<CAFm4XO0oSks8ME74=hMj2e4F2g5fFdiEh2VSsfcYmGgmjRz2pA@mail.gmail.com>
	<CAFdSV9uckVaAyyYZvScH9dAXs_0EEhWaGqKh=5B7QtnroPyeqA@mail.gmail.com>
Message-ID: <CAFdSV9tYiX-kVSdC85aCcDx8wzYhJeDuekwXi2YBjBjgREk3Gw@mail.gmail.com>

So tentatively I have the following docs:

1) "User Manual" - mostly done
2) "Domain Model Mapping Guide" - work in progress, but progressing nicely.
3) "Integrations Guide" - atm this will be just the devguide with the
Service+Registry chapter; but I'd like to circle back and pick up other
topics later.

This leaves some open points of discussion.  From the proposal itself:

1) What do we cover in "batching"?
2) "additionalmodules"?  I am inclined to simply drop that one, so unless I
here differently that is what will happen.

Emmanuel replied (on irc maybe?  I forget where) that he thought topics
such as "Performance Monitoring" and "Best Practices" ought to be separate
documents.

He also suggested a chapter on bootstrapping.  I totally agree.  I
essentially copied the topical guides on bootstrapping as a chapter in the
User Guide.  But that brings up an interesting point as to the distinction
between topical guides and documentation.  When should something go where?
I almost like to look at the topical guides as a wiki.  I don't think
anyone is thrilled with the SBS "wiki" we have access to.  I look at this
as an asciidoctor-based alternative.  Of course between SBS, GitHub wiki,
topical guides... gets to be a lot of places to look.  Initially the idea
of the topical guides was to break down the massive documentation into more
easily digestible chunks.  But that never gained traction.  Should they
just go away?


On Mon, Jul 27, 2015 at 5:10 PM Steve Ebersole <steve at hibernate.org> wrote:

> Sanne, yep thats why I sent the second email with a link ;)
>
> Anyway..  I just pushed some initial work on the manual.  Its not complete
> yet.  And I still need to start on the mapping guide.  Let me know any
> thoughts y'all have.
>
>
> On Mon, Jul 27, 2015 at 2:31 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> I didn't receive an attachment. AFAIK the mailing list drops them?
>> On 27 Jul 2015 14:39, "Steve Ebersole" <steve at hibernate.org> wrote:
>>
>>> I have been putting a lot of TLC into the ORM documentation this weekend
>>> getting ready for 5.0 to go Final.  To that end I have put together a
>>> proposal for these changes, it is attached.  I'd like to get some
>>> feedback.  Thanks
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From davide at hibernate.org  Wed Jul 29 05:35:07 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 29 Jul 2015 10:35:07 +0100
Subject: [hibernate-dev] [OGM] Thoughts for the Infinispan / Hot Rod
	dialect
In-Reply-To: <CAFm4XO2Vr99679RM-TABOefB41WpWNjrShnG9X2R2_mdynrYCw@mail.gmail.com>
References: <CAFm4XO2Vr99679RM-TABOefB41WpWNjrShnG9X2R2_mdynrYCw@mail.gmail.com>
Message-ID: <CANoTJYNRgN27aMGAG4OSH=rjJAri_n=23ntM9J_A8o9dUM42LA@mail.gmail.com>

> I think that in the case of Hot Rod clients we should not use
> AtomicMaps

Out of curiosity, what about the grouping API?
We asked the Infinispan team to add some methods to it because we might use
them
to implement the dialect over HotRod. These methods are still missing in
the HotRod protocol, though;
as far as I know.

> Would you agree on try basing the approach on a brand new dialect

I'm fine having a separate dialect.

> and on protobuf schema generation?

What kind of information do you need to generate the schema?
Is it something that you can do using the information we provide via the
interface SchemaDefiner (and BaseSchemaDefiner) at startup?

Cheers,
Davide



On Tue, Jul 28, 2015 at 3:07 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi all,
> with Infinispan in embedded mode we used AtomicMaps and
> FineGrainedAtomicMaps as an alternative way to map attributes and
> relations.
>
> In particular the relations are interesting because in SQL world one
> would run a query on junction tables, and on Infinispan embedded
> queries would only be an option on Hibernate Search / Infinispan Query
> annotated attributes, and also the AtomicMaps allow us to only load
> the section of relevant data (like on a RDBMs).
> The difference between the two kinds of AtomicMaps is in the locking
> level, each similar to the same kind of locking we'd normally have.
>
> On Hot Rod, AtomicMaps are not available so we opened (a long time
> ago) a feature request to implement them for Hot Rod - at least Java
> clients. Still, we don't have transactions in this case either so the
> locking benefits are also unavailable.
>
> I think that in the case of Hot Rod clients we should not use
> AtomicMaps, but rather resort to a protobuf schema generation, and
> essentially use the more traditional "query on jointables" approach.
> Hot Rod nowadays supports queries, and they can be indexed or non
> indexed so we could enable indexing on the ad-hoc tables we build for
> relations mapping, have the user "opt in" for additional indexes, and
> still allow some level of querying for the fields which have not been
> indexed; of course w/o join operations.
>
> We can generate an appropriate schema and upload it to Hot Rod
> automatically; that sounds like a great usability improvement for all
> Java clients dealing with Infinispan/remote, as its schema ads quite
> some stuff to the learning curve.
> Still, this automatic generation is a new and challenging field; some
> notes:
>  - protobuf schemas are generational -> more effective if you can
> generate the new one based on the existing one
>  - there's a Java encoder by Adrian here:
> https://github.com/infinispan/protostream
>  - Typically one would need to assign a stable sequence id to each field
>  - previous points will likely want us to dump the output resource
> somewhere, maybe even persist on Infinispan?
>
> On a very different topic, we also typically require from a
> GridDialect implementor to provide sequence generation capability. I
> don't see a solution for that over Hot Rod, it doesn't currently have
> any safe incremental id, but when I asked today I was told that
> Infinispan 8 might have it; Tristan pointed out you can upload a
> script and have it run on the server, which in turn has access to the
> transactions API so this should be possible but doesn't look too easy.
>
> Finally, we'll need using the distributed remote iterator for
> GridDialect#forEachTuple.
>
> So my conclusion is that to support Hot Rod we'd be better off to make
> a completely different GridDialect than the one for Infinispan
> embedded, as I can hardly see some shared code.
>
> Would you agree on try basing the approach on a brand new dialect and
> on protobuf schema generation? In terms of features, we can implement
> them all except:
>  - transactions & locks
>  - join queries
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Jul 29 06:12:49 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 29 Jul 2015 12:12:49 +0200
Subject: [hibernate-dev] [OGM] Thoughts for the Infinispan / Hot Rod
	dialect
In-Reply-To: <CAFm4XO2Vr99679RM-TABOefB41WpWNjrShnG9X2R2_mdynrYCw@mail.gmail.com>
References: <CAFm4XO2Vr99679RM-TABOefB41WpWNjrShnG9X2R2_mdynrYCw@mail.gmail.com>
Message-ID: <CADGJaX-rF1cissSzHq59e7qbPg8A6wXnbUnQrRY3Vj4Aa_qsuA@mail.gmail.com>

2015-07-28 16:07 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi all,
> with Infinispan in embedded mode we used AtomicMaps and
> FineGrainedAtomicMaps as an alternative way to map attributes and
> relations.
>
> In particular the relations are interesting because in SQL world one
> would run a query on junction tables, and on Infinispan embedded
> queries would only be an option on Hibernate Search / Infinispan Query
> annotated attributes, and also the AtomicMaps allow us to only load
> the section of relevant data (like on a RDBMs).
> The difference between the two kinds of AtomicMaps is in the locking
> level, each similar to the same kind of locking we'd normally have.
>
> On Hot Rod, AtomicMaps are not available so we opened (a long time
> ago) a feature request to implement them for Hot Rod - at least Java
> clients. Still, we don't have transactions in this case either so the
> locking benefits are also unavailable.
>
> I think that in the case of Hot Rod clients we should not use
> AtomicMaps, but rather resort to a protobuf schema generation, and
> essentially use the more traditional "query on jointables" approach.
>

The alternative would be to use RemoteCache directly and store the tuple
representations of entities/associations, right? But then, IIUC, queries
would not work?


> Hot Rod nowadays supports queries, and they can be indexed or non
> indexed so we could enable indexing on the ad-hoc tables we build for
> relations mapping, have the user "opt in" for additional indexes, and
> still allow some level of querying for the fields which have not been
> indexed; of course w/o join operations.
>
> We can generate an appropriate schema and upload it to Hot Rod
> automatically; that sounds like a great usability improvement for all
> Java clients dealing with Infinispan/remote, as its schema ads quite
> some stuff to the learning curve.
> Still, this automatic generation is a new and challenging field; some
> notes:
>  - protobuf schemas are generational -> more effective if you can
> generate the new one based on the existing one
>  - there's a Java encoder by Adrian here:
> https://github.com/infinispan/protostream
>  - Typically one would need to assign a stable sequence id to each field
>  - previous points will likely want us to dump the output resource
> somewhere, maybe even persist on Infinispan?
>

That, or one does it via a build step (e.g. through an annotation
processor) so the user manages the schemas as part of their application?

>
> On a very different topic, we also typically require from a
> GridDialect implementor to provide sequence generation capability. I
> don't see a solution for that over Hot Rod, it doesn't currently have
> any safe incremental id, but when I asked today I was told that
> Infinispan 8 might have it; Tristan pointed out you can upload a
> script and have it run on the server, which in turn has access to the
> transactions API so this should be possible but doesn't look too easy.
>

Wouldn't a table-like strategy work? I.e. a sequence field which the
application itself manages? It's not perfect but it's what we use for other
stores without native sequences.

Finally, we'll need using the distributed remote iterator for
> GridDialect#forEachTuple.
>
> So my conclusion is that to support Hot Rod we'd be better off to make
> a completely different GridDialect than the one for Infinispan
> embedded, as I can hardly see some shared code.
>

+1

Would you agree on try basing the approach on a brand new dialect and
> on protobuf schema generation?


All the protobuf business sounds a bit scary. Is this the way ISPN remote
is used in practice? If so, I guess there is no way around it. What about
the REST interface btw.? When using that, we may be able to share code with
the CouchDB (and soon Redis) backends.


> In terms of features, we can implement
> them all except:
>  - transactions & locks
>  - join queries
>

Sounds good, although the lack of TX hurts. It again may lead to situations
where parts of a flush cycle have been applied when coming to an error,
leaving the user with the task of cleaning up the potential mess.

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  Wed Jul 29 06:14:27 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Jul 2015 11:14:27 +0100
Subject: [hibernate-dev] [OGM] Thoughts for the Infinispan / Hot Rod
	dialect
In-Reply-To: <CANoTJYNRgN27aMGAG4OSH=rjJAri_n=23ntM9J_A8o9dUM42LA@mail.gmail.com>
References: <CAFm4XO2Vr99679RM-TABOefB41WpWNjrShnG9X2R2_mdynrYCw@mail.gmail.com>
	<CANoTJYNRgN27aMGAG4OSH=rjJAri_n=23ntM9J_A8o9dUM42LA@mail.gmail.com>
Message-ID: <CAFm4XO043qgfFpJCZL4_xz-pf2O0onPm1V-2FmY1tn42ksRUWw@mail.gmail.com>

On 29 July 2015 at 10:35, Davide D'Alto <davide at hibernate.org> wrote:
>> I think that in the case of Hot Rod clients we should not use
>> AtomicMaps
>
> Out of curiosity, what about the grouping API?
> We asked the Infinispan team to add some methods to it because we might use
> them
> to implement the dialect over HotRod. These methods are still missing in
> the HotRod protocol, though;
> as far as I know.

Right, essentially my proposal is to avoid the grouping API.
 - It's not implemented yet
 - Doesn't give us the same locking semantics which we liked for
embedded mode (no transactions)
 - If it can query we don't strictly need it anymore

>
>> Would you agree on try basing the approach on a brand new dialect
>
> I'm fine having a separate dialect.
>
>> and on protobuf schema generation?
>
> What kind of information do you need to generate the schema?

All attributes and types, and types of relations. Shouldn't be very
different than a RDBMs schema.

> Is it something that you can do using the information we provide via the
> interface SchemaDefiner (and BaseSchemaDefiner) at startup?

I expect so. But when we define the Protobuf templates, these are not
just applied to Infinispan but the persisters should also hold on
them, as they will need to use the same protobuf encoded messages on
each CRUD.

Thanks,
Sanne

From sanne at hibernate.org  Wed Jul 29 06:29:51 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Jul 2015 11:29:51 +0100
Subject: [hibernate-dev] [OGM] Thoughts for the Infinispan / Hot Rod
	dialect
In-Reply-To: <CADGJaX-rF1cissSzHq59e7qbPg8A6wXnbUnQrRY3Vj4Aa_qsuA@mail.gmail.com>
References: <CAFm4XO2Vr99679RM-TABOefB41WpWNjrShnG9X2R2_mdynrYCw@mail.gmail.com>
	<CADGJaX-rF1cissSzHq59e7qbPg8A6wXnbUnQrRY3Vj4Aa_qsuA@mail.gmail.com>
Message-ID: <CAFm4XO176c-X=jiV1at0eDXVNqhXcyib2vQRoEp6hTSbbXUZLg@mail.gmail.com>

On 29 July 2015 at 11:12, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
> 2015-07-28 16:07 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Hi all,
>> with Infinispan in embedded mode we used AtomicMaps and
>> FineGrainedAtomicMaps as an alternative way to map attributes and
>> relations.
>>
>> In particular the relations are interesting because in SQL world one
>> would run a query on junction tables, and on Infinispan embedded
>> queries would only be an option on Hibernate Search / Infinispan Query
>> annotated attributes, and also the AtomicMaps allow us to only load
>> the section of relevant data (like on a RDBMs).
>> The difference between the two kinds of AtomicMaps is in the locking
>> level, each similar to the same kind of locking we'd normally have.
>>
>> On Hot Rod, AtomicMaps are not available so we opened (a long time
>> ago) a feature request to implement them for Hot Rod - at least Java
>> clients. Still, we don't have transactions in this case either so the
>> locking benefits are also unavailable.
>>
>> I think that in the case of Hot Rod clients we should not use
>> AtomicMaps, but rather resort to a protobuf schema generation, and
>> essentially use the more traditional "query on jointables" approach.
>
>
> The alternative would be to use RemoteCache directly and store the tuple
> representations of entities/associations, right? But then, IIUC, queries
> would not work?

Queries would not work, but also you'd not have relations.
Finally, you'd also not be storing attributes of a single entity but
you'd be essentially serializing the entity in a blob whose encoding
is highly dependant on the OGM version, the Infinispan version, etc..
storing "as is" in a RemoteCache would introduce several drawbacks
which we've been able to avoid so far.

>
>>
>> Hot Rod nowadays supports queries, and they can be indexed or non
>> indexed so we could enable indexing on the ad-hoc tables we build for
>> relations mapping, have the user "opt in" for additional indexes, and
>> still allow some level of querying for the fields which have not been
>> indexed; of course w/o join operations.
>>
>> We can generate an appropriate schema and upload it to Hot Rod
>> automatically; that sounds like a great usability improvement for all
>> Java clients dealing with Infinispan/remote, as its schema ads quite
>> some stuff to the learning curve.
>> Still, this automatic generation is a new and challenging field; some
>> notes:
>>  - protobuf schemas are generational -> more effective if you can
>> generate the new one based on the existing one
>>  - there's a Java encoder by Adrian here:
>> https://github.com/infinispan/protostream
>>  - Typically one would need to assign a stable sequence id to each field
>>  - previous points will likely want us to dump the output resource
>> somewhere, maybe even persist on Infinispan?
>
>
> That, or one does it via a build step (e.g. through an annotation processor)
> so the user manages the schemas as part of their application?

That's similar to Adrian's approach, he built an helper to map Java
pojos to Hot Rod.
It would make annotations mandatory on each field though, as you need
for example to allocate an id to each attribute and keep it stable.
We might want to reuse that, but AFAIK its not fully fit for ORM's use
case, for example no relations other than embedding.

>>
>>
>> On a very different topic, we also typically require from a
>> GridDialect implementor to provide sequence generation capability. I
>> don't see a solution for that over Hot Rod, it doesn't currently have
>> any safe incremental id, but when I asked today I was told that
>> Infinispan 8 might have it; Tristan pointed out you can upload a
>> script and have it run on the server, which in turn has access to the
>> transactions API so this should be possible but doesn't look too easy.
>
>
> Wouldn't a table-like strategy work? I.e. a sequence field which the
> application itself manages? It's not perfect but it's what we use for other
> stores without native sequences.

I really don't see how you can guarantee that two application
instances don't get the same number; you'd need either transactions,
or locks or atomic operations and you have none of these.
In fact, I was planning to ask you about the javadoc comment I've
found on GridDialect.supportsSequences() .. I doubt that's a reusable
approach beyond the specific semantics of Neo4J?

Needless to say, not giving a *strong* guarantee of uniqueness on the
primary key would be a critical issue.

>
>> Finally, we'll need using the distributed remote iterator for
>> GridDialect#forEachTuple.
>>
>> So my conclusion is that to support Hot Rod we'd be better off to make
>> a completely different GridDialect than the one for Infinispan
>> embedded, as I can hardly see some shared code.
>
>
> +1
>
>> Would you agree on try basing the approach on a brand new dialect and
>> on protobuf schema generation?
>
>
> All the protobuf business sounds a bit scary. Is this the way ISPN remote is
> used in practice? If so, I guess there is no way around it. What about the
> REST interface btw.? When using that, we may be able to share code with the
> CouchDB (and soon Redis) backends.

It's an interesting idea as we could represent all entities as JSON
documents, but you have no query capabilities over REST.
Mapping many-to-many relations becomes tricky as you also don't have
atomic operations.. I guess we could have data loss on a concurrent
write of junction tables? Or would you map all relations as nested
keys in the same document of the owning entity?

>
>>
>> In terms of features, we can implement
>> them all except:
>>  - transactions & locks
>>  - join queries
>
>
> Sounds good, although the lack of TX hurts. It again may lead to situations
> where parts of a flush cycle have been applied when coming to an error,
> leaving the user with the task of cleaning up the potential mess.

Right but you have no TX in any option based on Hot Rod. I'm trying to
brainstorm what's our best mapping option, *given* you have no TX &
co.
That might change in future, but it has been "in the planning" since 5
years so we'd better assume it's not going to happen.

-- Sanne

From sanne at hibernate.org  Wed Jul 29 07:26:03 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Jul 2015 12:26:03 +0100
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new
 mapping annotations ?
Message-ID: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>

You might remember that running a full-text Query on a field always
required some specific care;
since the beginning of Hibernate Search the user had to make sure the
field was not tokenized, or tokenized but generating a single token.

This was a "soft requirement": if you didn't know, you'd get
inconsistent results but no error would be shown - after all, a Lucene
was typically schema-less.

With Lucene 5, if you didn't map your field specifically for the
sorting purpose, you'll get a runtime exception at query time. By
"specifically for sorting" the requirement is that the *single token*
needs to be stored as a DocValue.

DocValues are useful for other purposes too; for example they are a
more efficient strategy to store our "id" field and I hope we'll soon
use that transparently. It's also a better replacement for all those
use cases which previously would rely on a FieldCache (which by the
way was used by the sorting code under the hood). For example, we
recently migrated the Spatial indexing to use DocValues, and we now
support serializing and writing of DocValues.

What we don't have is a way for end user to explicitly single out
which fields they want to be "DocValue encoded", and this really needs
to be added now as the workaround we have to be able to run Sort
operations without it is killing our performance.

How should such annotations look like?

I don't like to expose such low-level details when for most people
it's just about sorting. Still, being useful for other reasons having
a "@Sortable" (or similar) named annotation would be limiting.
DocValues themselves - as a concept - are fine but even in the Lucene
history the exact name changed several times; wondering if we should
stick to the (current) technical term or abstract a bit from it.

I'm not sure if this should be extending the @Field annotation as
there are special restrictions implied in terms of analysis: are we
going to enforce a specific type of tokenizer, or simply take the
analysis option away?

Any nice suggestion of how this could looke like? This would become a
highly used public API.

The good news is that we'll be able to validate sort definitions.

Thanks,
Sanne

From steve at hibernate.org  Wed Jul 29 11:06:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Jul 2015 15:06:52 +0000
Subject: [hibernate-dev] started release
Message-ID: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>

per $subject

From steve at hibernate.org  Wed Jul 29 11:37:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Jul 2015 15:37:55 +0000
Subject: [hibernate-dev] started release
In-Reply-To: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
Message-ID: <CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>

The release is done minus announcing and SF upload.  Also I decided to not
upload the docs yet since they are still incomplete and i still have work
to do there prior to Final.


On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole <steve at hibernate.org> wrote:

> per $subject
>

From sanne at hibernate.org  Wed Jul 29 11:55:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Jul 2015 16:55:01 +0100
Subject: [hibernate-dev] started release
In-Reply-To: <CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
	<CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
Message-ID: <CAFm4XO0bBeMUjMuLBSYZGDrCFNDSapk6utuWn-6pwYwowhQM-g@mail.gmail.com>

Thanks Steve,
just tested Hibernate Search with it and it's all working fine.

On 29 July 2015 at 16:37, Steve Ebersole <steve at hibernate.org> wrote:
> The release is done minus announcing and SF upload.  Also I decided to not
> upload the docs yet since they are still incomplete and i still have work
> to do there prior to Final.
>
>
> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> per $subject
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Wed Jul 29 15:02:08 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 29 Jul 2015 15:02:08 -0400
Subject: [hibernate-dev] started release
In-Reply-To: <CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
	<CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
Message-ID: <55B92330.5070706@redhat.com>

I missed a WildFly second level query cache failure yesterday in my 
testing http://pastebin.com/kg3YhxxL

Test steps:

  - creates an entity

  - queries for the entity

  - verify that the query cache hit count is zero.

  - query again for the entity

  - verify that the query cache hit count is one (this fails as the 
query cache hit count is still zero)

The failing test code is at 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255

And is called from 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229

This hurts my WF10 upgrade to ORM 5.0.0.CR3 
https://github.com/wildfly/wildfly/pull/7842

On 07/29/2015 11:37 AM, Steve Ebersole wrote:
> The release is done minus announcing and SF upload.  Also I decided to not
> upload the docs yet since they are still incomplete and i still have work
> to do there prior to Final.
>
>
> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> per $subject
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Jul 29 16:47:07 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Jul 2015 21:47:07 +0100
Subject: [hibernate-dev] started release
In-Reply-To: <55B92330.5070706@redhat.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
	<CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
	<55B92330.5070706@redhat.com>
Message-ID: <CAFm4XO2OBu0-v=wDs3CU5_2yC6E3ZKiwxMzW8A22BwoUu7NReg@mail.gmail.com>

Hi Scott,
do you think you could merge those tests in Hibernate ORM?

Thanks,
Sanne

On 29 July 2015 at 20:02, Scott Marlow <smarlow at redhat.com> wrote:
> I missed a WildFly second level query cache failure yesterday in my
> testing http://pastebin.com/kg3YhxxL
>
> Test steps:
>
>   - creates an entity
>
>   - queries for the entity
>
>   - verify that the query cache hit count is zero.
>
>   - query again for the entity
>
>   - verify that the query cache hit count is one (this fails as the
> query cache hit count is still zero)
>
> The failing test code is at
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255
>
> And is called from
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229
>
> This hurts my WF10 upgrade to ORM 5.0.0.CR3
> https://github.com/wildfly/wildfly/pull/7842
>
> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>> The release is done minus announcing and SF upload.  Also I decided to not
>> upload the docs yet since they are still incomplete and i still have work
>> to do there prior to Final.
>>
>>
>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> per $subject
>>>
>> _______________________________________________
>> 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  Wed Jul 29 16:50:37 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 29 Jul 2015 16:50:37 -0400
Subject: [hibernate-dev] started release
In-Reply-To: <CAFm4XO2OBu0-v=wDs3CU5_2yC6E3ZKiwxMzW8A22BwoUu7NReg@mail.gmail.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
	<CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
	<55B92330.5070706@redhat.com>
	<CAFm4XO2OBu0-v=wDs3CU5_2yC6E3ZKiwxMzW8A22BwoUu7NReg@mail.gmail.com>
Message-ID: <55B93C9D.4040909@redhat.com>

Hi Sanne,

Good idea. I'm not sure exactly what about the test is failing.  ORM 
currently doesn't have all of the same components as WildFly, so tests 
don't always translate (e.g. ORM doesn't have a EJB container).  We need 
to understand the cause and then maybe we can talk about an ORM test.

Scott

On 07/29/2015 04:47 PM, Sanne Grinovero wrote:
> Hi Scott,
> do you think you could merge those tests in Hibernate ORM?
>
> Thanks,
> Sanne
>
> On 29 July 2015 at 20:02, Scott Marlow <smarlow at redhat.com> wrote:
>> I missed a WildFly second level query cache failure yesterday in my
>> testing http://pastebin.com/kg3YhxxL
>>
>> Test steps:
>>
>>    - creates an entity
>>
>>    - queries for the entity
>>
>>    - verify that the query cache hit count is zero.
>>
>>    - query again for the entity
>>
>>    - verify that the query cache hit count is one (this fails as the
>> query cache hit count is still zero)
>>
>> The failing test code is at
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255
>>
>> And is called from
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229
>>
>> This hurts my WF10 upgrade to ORM 5.0.0.CR3
>> https://github.com/wildfly/wildfly/pull/7842
>>
>> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>>> The release is done minus announcing and SF upload.  Also I decided to not
>>> upload the docs yet since they are still incomplete and i still have work
>>> to do there prior to Final.
>>>
>>>
>>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> per $subject
>>>>
>>> _______________________________________________
>>> 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 rvansa at redhat.com  Thu Jul 30 02:34:38 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 30 Jul 2015 08:34:38 +0200
Subject: [hibernate-dev] started release
In-Reply-To: <55B92330.5070706@redhat.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>	<CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
	<55B92330.5070706@redhat.com>
Message-ID: <55B9C57E.1040603@redhat.com>

I think that the failure is caused by HHH-7898 fix. The put is executed 
only after the current transaction is finished (as synchronization), 
until then the query is cached only for the current session and 
therefore not reflected in statistics.

Radim

On 07/29/2015 09:02 PM, Scott Marlow wrote:
> I missed a WildFly second level query cache failure yesterday in my
> testing http://pastebin.com/kg3YhxxL
>
> Test steps:
>
>    - creates an entity
>
>    - queries for the entity
>
>    - verify that the query cache hit count is zero.
>
>    - query again for the entity
>
>    - verify that the query cache hit count is one (this fails as the
> query cache hit count is still zero)
>
> The failing test code is at
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255
>
> And is called from
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229
>
> This hurts my WF10 upgrade to ORM 5.0.0.CR3
> https://github.com/wildfly/wildfly/pull/7842
>
> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>> The release is done minus announcing and SF upload.  Also I decided to not
>> upload the docs yet since they are still incomplete and i still have work
>> to do there prior to Final.
>>
>>
>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> per $subject
>>>
>> _______________________________________________
>> 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 emmanuel at hibernate.org  Thu Jul 30 03:11:24 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 30 Jul 2015 09:11:24 +0200
Subject: [hibernate-dev] ORM Documentation
In-Reply-To: <CAFdSV9tYiX-kVSdC85aCcDx8wzYhJeDuekwXi2YBjBjgREk3Gw@mail.gmail.com>
References: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
	<CAFm4XO0oSks8ME74=hMj2e4F2g5fFdiEh2VSsfcYmGgmjRz2pA@mail.gmail.com>
	<CAFdSV9uckVaAyyYZvScH9dAXs_0EEhWaGqKh=5B7QtnroPyeqA@mail.gmail.com>
	<CAFdSV9tYiX-kVSdC85aCcDx8wzYhJeDuekwXi2YBjBjgREk3Gw@mail.gmail.com>
Message-ID: <D37C8ED8-FFAE-4DFC-ABA9-51655690D1EB@hibernate.org>

I think topical guides never got traction because the work on doc was down to zero. I would not give up hope on them :)

> On 28 Jul 2015, at 19:51, Steve Ebersole <steve at hibernate.org> wrote:
> 
> So tentatively I have the following docs:
> 
> 1) "User Manual" - mostly done
> 2) "Domain Model Mapping Guide" - work in progress, but progressing nicely.
> 3) "Integrations Guide" - atm this will be just the devguide with the
> Service+Registry chapter; but I'd like to circle back and pick up other
> topics later.
> 
> This leaves some open points of discussion.  From the proposal itself:
> 
> 1) What do we cover in "batching"?
> 2) "additionalmodules"?  I am inclined to simply drop that one, so unless I
> here differently that is what will happen.
> 
> Emmanuel replied (on irc maybe?  I forget where) that he thought topics
> such as "Performance Monitoring" and "Best Practices" ought to be separate
> documents.
> 
> He also suggested a chapter on bootstrapping.  I totally agree.  I
> essentially copied the topical guides on bootstrapping as a chapter in the
> User Guide.  But that brings up an interesting point as to the distinction
> between topical guides and documentation.  When should something go where?
> I almost like to look at the topical guides as a wiki.  I don't think
> anyone is thrilled with the SBS "wiki" we have access to.  I look at this
> as an asciidoctor-based alternative.  Of course between SBS, GitHub wiki,
> topical guides... gets to be a lot of places to look.  Initially the idea
> of the topical guides was to break down the massive documentation into more
> easily digestible chunks.  But that never gained traction.  Should they
> just go away?
> 
> 
> On Mon, Jul 27, 2015 at 5:10 PM Steve Ebersole <steve at hibernate.org> wrote:
> 
>> Sanne, yep thats why I sent the second email with a link ;)
>> 
>> Anyway..  I just pushed some initial work on the manual.  Its not complete
>> yet.  And I still need to start on the mapping guide.  Let me know any
>> thoughts y'all have.
>> 
>> 
>> On Mon, Jul 27, 2015 at 2:31 PM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> 
>>> I didn't receive an attachment. AFAIK the mailing list drops them?
>>> On 27 Jul 2015 14:39, "Steve Ebersole" <steve at hibernate.org> wrote:
>>> 
>>>> I have been putting a lot of TLC into the ORM documentation this weekend
>>>> getting ready for 5.0 to go Final.  To that end I have put together a
>>>> proposal for these changes, it is attached.  I'd like to get some
>>>> feedback.  Thanks
>>>> 
>>>> _______________________________________________
>>>> 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 emmanuel at hibernate.org  Thu Jul 30 03:13:42 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 30 Jul 2015 09:13:42 +0200
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
Message-ID: <7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>

For info, SourceForge hopes to restore ssh access (the last service they will activate) August 3rd.
http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/

> On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Your proposed order seems good. I'd exclude GitHub if it's not scriptable (UI only) as this will hinder releases from the CI server.
> 
> 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>>:
> As some of you know Sourceforge has had a severe distributed file system corruption and they have been working on it for a full week. You can read their blog for regular updates http://sourceforge.net/blog/ <http://sourceforge.net/blog/>
> The concrete issue for us is that we cannot upload new files: Hibernate Validator and Hibernate ORM are now pending a release.
> 
> There are 4 options on the table
> 
> Be patient::
> SourceForge will eventually reopen upload, I imagine it might take form one to two weeks.
> Their binary hosting support is relatively correct and all of our download statistics are there.
> 
> Move to download.jboss.org <http://download.jboss.org/>::
> JBoss has a facility to host binaries. WildFly amongst other uses it. We can ask them if they are happy with it.
> It is not connected to the rest of the forum/CMS infra, it?s a simple file upload AFAIK so easily scriptable.
> They also offer statistics but how needs to be investigated.
> 
> Move to GitHub::
> GitHub has a binary upload facility. I could only find a web based approach (can it be done programmatically?).
> They don?t seem to have any statistics service, which is a big negative point.
> Also I don?t trust GitHub anymore for their binary hosting. They had a version in the past that they scrapped with barely no notice. I?m not exactly willing to give them my trust again.
> 
> Move to BinTray::
> Binary hosting is their life and blood. People seem happy with them. It seems however that the statistics require a paying package instead of the free oss tier.
> 
> I think we should try in the following order:
> 
> 1. Be patient with Sourceforge (but for how long?)
> 2. go for download.jboss.org <http://download.jboss.org/> and before that ask around for the process and stability of the infrastructure
> 3. explore Bintray
> 4. GitHub (did I say that I no longer trust their binary hosting support?)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>


From hardy at hibernate.org  Thu Jul 30 09:05:13 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 30 Jul 2015 15:05:13 +0200
Subject: [hibernate-dev] Hibernate Validator 5.2.1.Final released
Message-ID: <20150730130513.GA80151@Nineveh.lan>

Hi,

Hibernate Validator 5.2.1.Final was just released. Most important
new feature is Java 8 support, but there is more - http://in.relation.to/2015/07/30/hibernate-validator-521-final/

All artifacts are available in the Maven repositories (JBoss and Maven Central), but distribution
bundle upload is still pending while SourceForge struggles to recover from its storage fault.

Enjoy!


From smarlow at redhat.com  Thu Jul 30 09:27:02 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 30 Jul 2015 09:27:02 -0400
Subject: [hibernate-dev] started release
In-Reply-To: <55B9C57E.1040603@redhat.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
	<CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
	<55B92330.5070706@redhat.com> <55B9C57E.1040603@redhat.com>
Message-ID: <55BA2626.3010806@redhat.com>



On 07/30/2015 02:34 AM, Radim Vansa wrote:
> I think that the failure is caused by HHH-7898 fix. The put is executed
> only after the current transaction is finished (as synchronization),
> until then the query is cached only for the current session and
> therefore not reflected in statistics.

Aren't the statistics at the SF level?

>
> Radim
>
> On 07/29/2015 09:02 PM, Scott Marlow wrote:
>> I missed a WildFly second level query cache failure yesterday in my
>> testing http://pastebin.com/kg3YhxxL
>>
>> Test steps:
>>
>>     - creates an entity
>>
>>     - queries for the entity
>>
>>     - verify that the query cache hit count is zero.
>>
>>     - query again for the entity
>>
>>     - verify that the query cache hit count is one (this fails as the
>> query cache hit count is still zero)
>>
>> The failing test code is at
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255
>>
>> And is called from
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229
>>
>> This hurts my WF10 upgrade to ORM 5.0.0.CR3
>> https://github.com/wildfly/wildfly/pull/7842
>>
>> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>>> The release is done minus announcing and SF upload.  Also I decided to not
>>> upload the docs yet since they are still incomplete and i still have work
>>> to do there prior to Final.
>>>
>>>
>>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> per $subject
>>>>
>>> _______________________________________________
>>> 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 rvansa at redhat.com  Thu Jul 30 09:36:47 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 30 Jul 2015 15:36:47 +0200
Subject: [hibernate-dev] started release
In-Reply-To: <55BA2626.3010806@redhat.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
	<CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
	<55B92330.5070706@redhat.com> <55B9C57E.1040603@redhat.com>
	<55BA2626.3010806@redhat.com>
Message-ID: <55BA286F.7080308@redhat.com>

On 07/30/2015 03:27 PM, Scott Marlow wrote:
>
>
> On 07/30/2015 02:34 AM, Radim Vansa wrote:
>> I think that the failure is caused by HHH-7898 fix. The put is executed
>> only after the current transaction is finished (as synchronization),
>> until then the query is cached only for the current session and
>> therefore not reflected in statistics.
>
> Aren't the statistics at the SF level?

Hmm, you're right. Could you send me a trace log for this test to check 
what's happening, rather than guess?

Radim

>
>>
>> Radim
>>
>> On 07/29/2015 09:02 PM, Scott Marlow wrote:
>>> I missed a WildFly second level query cache failure yesterday in my
>>> testing http://pastebin.com/kg3YhxxL
>>>
>>> Test steps:
>>>
>>>     - creates an entity
>>>
>>>     - queries for the entity
>>>
>>>     - verify that the query cache hit count is zero.
>>>
>>>     - query again for the entity
>>>
>>>     - verify that the query cache hit count is one (this fails as the
>>> query cache hit count is still zero)
>>>
>>> The failing test code is at
>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255 
>>>
>>>
>>> And is called from
>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229 
>>>
>>>
>>> This hurts my WF10 upgrade to ORM 5.0.0.CR3
>>> https://github.com/wildfly/wildfly/pull/7842
>>>
>>> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>>>> The release is done minus announcing and SF upload.  Also I decided 
>>>> to not
>>>> upload the docs yet since they are still incomplete and i still 
>>>> have work
>>>> to do there prior to Final.
>>>>
>>>>
>>>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole 
>>>> <steve at hibernate.org> wrote:
>>>>
>>>>> per $subject
>>>>>
>>>> _______________________________________________
>>>> 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 smarlow at redhat.com  Thu Jul 30 09:44:21 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 30 Jul 2015 09:44:21 -0400
Subject: [hibernate-dev] started release
In-Reply-To: <55BA286F.7080308@redhat.com>
References: <CAFdSV9sizm92JBufkiiGJx0rv2OaJwi344BK4ZJaoyuPhhTxHw@mail.gmail.com>
	<CAFdSV9vcBqg8tHv-=xwe4nSK46AVvokb4Bj_hvteKfYbTZa6BQ@mail.gmail.com>
	<55B92330.5070706@redhat.com> <55B9C57E.1040603@redhat.com>
	<55BA2626.3010806@redhat.com> <55BA286F.7080308@redhat.com>
Message-ID: <55BA2A35.1040709@redhat.com>

On 07/30/2015 09:36 AM, Radim Vansa wrote:
> On 07/30/2015 03:27 PM, Scott Marlow wrote:
>>
>>
>> On 07/30/2015 02:34 AM, Radim Vansa wrote:
>>> I think that the failure is caused by HHH-7898 fix. The put is executed
>>> only after the current transaction is finished (as synchronization),
>>> until then the query is cached only for the current session and
>>> therefore not reflected in statistics.
>>
>> Aren't the statistics at the SF level?
>
> Hmm, you're right. Could you send me a trace log for this test to check
> what's happening, rather than guess?

Easily done.  I'll enable TRACE logging for org.hibernate + 
org.infinispan unless you want a little less?

I'll also include org.jboss.as.jpa TRACE logging so we have logging of 
each EntityManager invocation.  May as well include JTA trace also, so 
we know when the TX starts/ends.


>
> Radim
>
>>
>>>
>>> Radim
>>>
>>> On 07/29/2015 09:02 PM, Scott Marlow wrote:
>>>> I missed a WildFly second level query cache failure yesterday in my
>>>> testing http://pastebin.com/kg3YhxxL
>>>>
>>>> Test steps:
>>>>
>>>>     - creates an entity
>>>>
>>>>     - queries for the entity
>>>>
>>>>     - verify that the query cache hit count is zero.
>>>>
>>>>     - query again for the entity
>>>>
>>>>     - verify that the query cache hit count is one (this fails as the
>>>> query cache hit count is still zero)
>>>>
>>>> The failing test code is at
>>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255
>>>>
>>>>
>>>> And is called from
>>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229
>>>>
>>>>
>>>> This hurts my WF10 upgrade to ORM 5.0.0.CR3
>>>> https://github.com/wildfly/wildfly/pull/7842
>>>>
>>>> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>>>>> The release is done minus announcing and SF upload.  Also I decided
>>>>> to not
>>>>> upload the docs yet since they are still incomplete and i still
>>>>> have work
>>>>> to do there prior to Final.
>>>>>
>>>>>
>>>>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole
>>>>> <steve at hibernate.org> wrote:
>>>>>
>>>>>> per $subject
>>>>>>
>>>>> _______________________________________________
>>>>> 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 Jul 30 12:20:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 30 Jul 2015 16:20:20 +0000
Subject: [hibernate-dev] Third candidate release for ORM 5.0
Message-ID: <CAFdSV9tKaaGk14CZWxZY5SzE=pHpyF2mTSxz8opDrwu9yx0x9g@mail.gmail.com>

http://in.relation.to/2015/07/30/hibernate-orm-500-cr3-release/

From steve at hibernate.org  Thu Jul 30 22:00:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 31 Jul 2015 02:00:16 +0000
Subject: [hibernate-dev] JmxService
Message-ID: <CAFdSV9sByMeE7EYs4_Mq9c=BgnDPW8SjKg8unyNz6bApq=MJmg@mail.gmail.com>

Anyone using the JmxService?

From steve at hibernate.org  Fri Jul 31 14:37:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 31 Jul 2015 18:37:29 +0000
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
	<7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
Message-ID: <CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>

FWIW the SourceForge upload UI seems to be restored.



On Thu, Jul 30, 2015 at 2:14 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> For info, SourceForge hopes to restore ssh access (the last service they
> will activate) August 3rd.
>
> http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/
>
> > On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > Your proposed order seems good. I'd exclude GitHub if it's not
> scriptable (UI only) as this will hinder releases from the CI server.
> >
> > 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
> <mailto:emmanuel at hibernate.org>>:
> > As some of you know Sourceforge has had a severe distributed file system
> corruption and they have been working on it for a full week. You can read
> their blog for regular updates http://sourceforge.net/blog/ <
> http://sourceforge.net/blog/>
> > The concrete issue for us is that we cannot upload new files: Hibernate
> Validator and Hibernate ORM are now pending a release.
> >
> > There are 4 options on the table
> >
> > Be patient::
> > SourceForge will eventually reopen upload, I imagine it might take form
> one to two weeks.
> > Their binary hosting support is relatively correct and all of our
> download statistics are there.
> >
> > Move to download.jboss.org <http://download.jboss.org/>::
> > JBoss has a facility to host binaries. WildFly amongst other uses it. We
> can ask them if they are happy with it.
> > It is not connected to the rest of the forum/CMS infra, it?s a simple
> file upload AFAIK so easily scriptable.
> > They also offer statistics but how needs to be investigated.
> >
> > Move to GitHub::
> > GitHub has a binary upload facility. I could only find a web based
> approach (can it be done programmatically?).
> > They don?t seem to have any statistics service, which is a big negative
> point.
> > Also I don?t trust GitHub anymore for their binary hosting. They had a
> version in the past that they scrapped with barely no notice. I?m not
> exactly willing to give them my trust again.
> >
> > Move to BinTray::
> > Binary hosting is their life and blood. People seem happy with them. It
> seems however that the statistics require a paying package instead of the
> free oss tier.
> >
> > I think we should try in the following order:
> >
> > 1. Be patient with Sourceforge (but for how long?)
> > 2. go for download.jboss.org <http://download.jboss.org/> and before
> that ask around for the process and stability of the infrastructure
> > 3. explore Bintray
> > 4. GitHub (did I say that I no longer trust their binary hosting
> support?)
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev <
> 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