Re: [hibernate-dev] Patch to ORM 4.2

[Gail Badner]

I agree this is clearly a bug, doesn't change any contracts, and is easily 
fixed.

I went ahead and cherry-picked it. I had to make a very minor fix because 
SimpleValue.columns is type List (not List).

I've pushed the fix to 4.2 to be fixed in 4.2.16.

Thanks Andrea!

Gail

- Original Message -
> From: "Steve Ebersole" 
> To: "andrea boriero" 
> Cc: "Hibernate Dev" 
> Sent: Thursday, September 18, 2014 7:52:37 AM
> Subject: Re: [hibernate-dev] Patch to ORM 4.2
> 
> Generally speaking we do not port changes to the 4.2 branch anymore.
>  However this one is a pretty obvious bug.  I would say that as long as no
> public contracts were changed, to go ahead and port it.  But I would
> check/coordinate with Gail.
> 
> Gail, wdyt?
> 
> On Thu, Sep 18, 2014 at 9:44 AM, andrea boriero 
> wrote:
> 
> > I have applied the patch for the jira
> >  https://hibernate.atlassian.net/browse/HHH-9369 to the following
> > branches:
> > - master
> > - 4.3
> >
> > do I have to apply it also to 4.2?
> >
> > Thanks,
> >
> > Andrea
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release 4.3.7 and 4.2.16

[Gail Badner]

Please do not push anything to 4.2 and 4.3 branches until they are released.
Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 4.3.7.Final and 4.2.16.Final Released

[Gail Badner]

I've finished with the releases, including uploading everthing. I'm having 
trouble setting up the weblog entry in in.relation.to for some reason. I'll 
blog about the releases tomorrow.
Regards,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 4.3.7.Final and 4.2.15.Final Released

[Gail Badner]

For details, see: 
http://in.relation.to/Bloggers/HibernateORM437FinalAnd4216FinalReleased

These were actually released on October 30. The announcement has been delayed 
because the server hosting the blog is having critical hardware problems and I 
was not able to post my entry until today. If you have problems with that link, 
please try again later. 

Gail Badner
Red Hat, Hibernate ORM
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM master - 5.0

[Gail Badner]

Forgot to CC hibernate-dev mailing list...

- Original Message -
> From: "Gail Badner" 
> To: "Steve Ebersole" 
> Sent: Tuesday, November 18, 2014 9:28:02 AM
> Subject: Re: [hibernate-dev] Hibernate ORM master - 5.0
> 
> You mention possibly for 5.1: "Override EAGER fetching with LAZY (fetch
> profiles, HQL, etc) refer to HHH-8558 and HHH-8559?
> 
> - Original Message -
> > From: "Steve Ebersole" 
> > To: "hibernate-dev" 
> > Sent: Thursday, October 30, 2014 8:44:23 AM
> > Subject: [hibernate-dev] Hibernate ORM master - 5.0
> > 
> > It was decided that the massive work for 5.0 including metamodel and all
> > the other changes was just taking too long, and that we'd split that work
> > up into a number of intermediate versions.  I wanted to highlight the
> > proposed breakdown and solidify the roadmaps.  The preliminary breakdown is
> > as follows:
> > 
> > 
> >- 5.0
> >   - Java 6 or 7 (?)
> >   - EE 7 (JPA 2.1)
> >   - Wildfly 9
> >   - Timeline : Spring 2015
> >   - Required development
> >  - Transition to new bootstrapping APIs
> >  - MetadataSources, contributors, builders, etc for building
> > SessionFactory
> > - Keep Configuration as a migration aid, but align its
> > processing and assumptions to follow new APIs
> > - New naming strategy approach (implicit and physical split)
> >  - Pick "important" features from  metamodel work based on new
> >  bootstrapping API
> > - automatic quoting of identifiers that are keywords
> > - ???
> >  - Performance improvements
> >  - Cachng SPI changes based on feedback from Ehcahce and Infinispan
> > - EntityKey proposal
> > - Explore unifying entry keys for actual cache provider, cache
> > SPI (CacheKey) and persistence-context (EntityKey)
> > - Infinispan improvements, especially in local mode.  Will
> > require integrating a new Infinispan version and possible
> > changes to
> > hibernate-infinispan
> > - ???
> >  - OGM integration
> > - "after persisters built" hook
> >- others?
> > - Java 8 type support
> > - Date/Time
> > - Optional
> >  - Java 9 type support
> > - Money/Currency
> >  - Optional development (as time, resources allow)
> >  - Discriminator based multitenancy
> >  - JAXB instead of dom4j.
> >  - extended orm.xml xsd, deprecating hbm.xml format
> >  - Jandex usage
> >  - JdbcSession
> >  - Hibernate Spatial integration (depends on level of dependence on
> >  metamodel)
> >   - 5.1
> >   - Java 6 or 7 (?)
> >   - EE 7 (JPA 2.1)
> >   - Widfly 9, or 10
> >   - Timeline : TBD (Fall 2016?)
> >   - Required development
> >  - slips from 5.0
> >  - new HQL parser
> > - Antlr 3 or 4?
> > - unified SQL generation? or limit to HQL parsing?
> >  - Optional development (as time, resources allow)
> >  - extend JPA criteria API with support for constructs from
> >  Hibernate's legacy criteria API
> >  - extend JPA criteria API with fluent support
> >   - Possibly - Override EAGER fetching with LAZY (fetch profiles, HQL,
> >   etc)
> >- 5.2
> >   - (if needed)
> >   - Java 6 or 7 (?)
> >   - EE 7 (JPA 2.1)
> >   - Widfly 9, or 10
> >   - Required development
> >  - splits from 5.1
> >   - 6.0
> >   - SE and EE support levels TBD, but at least SE 8
> >   - Required development
> >  - metamodel
> > 
> > 
> > One additional consideration... I have been told (have not verified the
> > details yet myself) that Hibernate ORM will currently not run in Java 8 at
> > least in part because dom4j will not work in Java 8 (maybe just the version
> > we use?  again, have not verified details yet).  If running 5.x versions of
> > Hibernate in Java 8 is important to anyone, we might need to increase the
> > priority of moving to JAXB over dom4j.
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] MySQL fractional second precision (HHH-9444)

[Gail Badner]

MySQL support for fractional seconds in temporal values is documented in [1]:

Prior to MySQL 5.6.4, when storing a value into a column of any temporal data 
type, fractional part is discarded (truncated). When a column is defined as 
TIMESTAMP(N), N indicates display width rather than fractional seconds. 

MySQL 5.6.4 and up allows enabling fractional second support by defining a 
column like: TIME(n), DATETIME(n), TIMESTAMP(n), where 0 <= n <= 6. A value of 
0 indicates no fractional seconds. For compatibiliby with previous MySQL 
versions, if no value for n is provided, then 0 is the default. This is 
inconsistent with standard SQL, which has a default of 6. In addition, 
inserting a temporal value in a column will result in rounding if the column is 
defined with fewer fractional digits than the value.

Starting from MySQL 5.6.4, there are also differences in functions that involve 
temporal values. MySQL functions like NOW(), CURTIME(), SYSDATE(), or 
UTC_TIMESTAMP() can optionally take an argument for fractional seconds 
precision as in NOW(n), CURTIME(n), SYSDATE(n), or UTC_TIMESTAMP(n), where 0 <= 
n <= 6. For compatibiliby with previous MySQL versions, if no value for n is 
provided, then 0 is the default. 

I'm working on a new dialect to support fractional seconds. Since the support 
for fractional seconds began in MySQL 5.6.4 it kind of complicates naming. I 
assume MySQL5InnoDBDialect needs to be extended for the InnoDB engine. 

Is "MySQL564InnoDBDialect" too ugly? 

Is there any need to have a new dialect for other (non-InnoDB) MySQL engines 
(e.g., MySQL564DBDialect that extends MySQL5Dialect)?

IIUC, to be consistent with the SQL standard the default for the temporal types 
in the new dialect(s) should be:
registerColumnType( Types.TIMESTAMP, "datetime(6)" );
registerColumnType( Types.TIME, "time(6)" );

Is there a need the new dialect(s) to allow an application to define the number 
of fractional seconds to anything other than 6? If so, would it work to also 
add the following?
registerColumnType( Types.TIMESTAMP, 6, "datetime($l)" );
registerColumnType( Types.TIME, 6, "time($l)" );

Also, IMO, Hibernate should render NOW(), CURTIME(), SYSDATE(), UTC_TIMESTAMP() 
as NOW(6), CURTIME(6), SYSDATE(6), or UTC_TIMESTAMP(6), respectively, unless an 
argument is specifically provided.

As far as I can tell, Hibernate does not use MySQL's TIMESTAMP column type, so 
I don't think anything needs to be done to support fractional seconds for that 
type, or am I missing something here?

Comments?

Thanks,
Gail

[1] http://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html
[2] https://hibernate.atlassian.net/browse/HHH-9444
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] MySQL fractional second precision (HHH-8401, HHH-9444)

[Gail Badner]

To clarify, HHH-8401 is to support MySQL fractional seconds; HHH-9444 is to fix 
test failures due MySQL's new support for fractional seconds.

- Original Message -
> From: "Gail Badner" 
> To: "Hibernate Dev" 
> Sent: Tuesday, November 18, 2014 1:59:26 PM
> Subject: MySQL fractional second precision (HHH-9444)
> 
> MySQL support for fractional seconds in temporal values is documented in [1]:
> 
> Prior to MySQL 5.6.4, when storing a value into a column of any temporal data
> type, fractional part is discarded (truncated). When a column is defined as
> TIMESTAMP(N), N indicates display width rather than fractional seconds.
> 
> MySQL 5.6.4 and up allows enabling fractional second support by defining a
> column like: TIME(n), DATETIME(n), TIMESTAMP(n), where 0 <= n <= 6. A value
> of 0 indicates no fractional seconds. For compatibiliby with previous MySQL
> versions, if no value for n is provided, then 0 is the default. This is
> inconsistent with standard SQL, which has a default of 6. In addition,
> inserting a temporal value in a column will result in rounding if the column
> is defined with fewer fractional digits than the value.
> 
> Starting from MySQL 5.6.4, there are also differences in functions that
> involve temporal values. MySQL functions like NOW(), CURTIME(), SYSDATE(),
> or UTC_TIMESTAMP() can optionally take an argument for fractional seconds
> precision as in NOW(n), CURTIME(n), SYSDATE(n), or UTC_TIMESTAMP(n), where 0
> <= n <= 6. For compatibiliby with previous MySQL versions, if no value for n
> is provided, then 0 is the default.
> 
> I'm working on a new dialect to support fractional seconds. Since the support
> for fractional seconds began in MySQL 5.6.4 it kind of complicates naming. I
> assume MySQL5InnoDBDialect needs to be extended for the InnoDB engine.
> 
> Is "MySQL564InnoDBDialect" too ugly?
> 
> Is there any need to have a new dialect for other (non-InnoDB) MySQL engines
> (e.g., MySQL564DBDialect that extends MySQL5Dialect)?
> 
> IIUC, to be consistent with the SQL standard the default for the temporal
> types in the new dialect(s) should be:
>   registerColumnType( Types.TIMESTAMP, "datetime(6)" );
>   registerColumnType( Types.TIME, "time(6)" );
> 
> Is there a need the new dialect(s) to allow an application to define the
> number of fractional seconds to anything other than 6? If so, would it work
> to also add the following?
>   registerColumnType( Types.TIMESTAMP, 6, "datetime($l)" );
>   registerColumnType( Types.TIME, 6, "time($l)" );
> 
> Also, IMO, Hibernate should render NOW(), CURTIME(), SYSDATE(),
> UTC_TIMESTAMP() as NOW(6), CURTIME(6), SYSDATE(6), or UTC_TIMESTAMP(6),
> respectively, unless an argument is specifically provided.
> 
> As far as I can tell, Hibernate does not use MySQL's TIMESTAMP column type,
> so I don't think anything needs to be done to support fractional seconds for
> that type, or am I missing something here?
>   
> Comments?
> 
> Thanks,
> Gail
> 
> [1] http://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html
> [2] https://hibernate.atlassian.net/browse/HHH-9444
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM master

[Gail Badner]

Only metamodel-related code was merged from the old metamodel branch into 
master, so there is definitely unmerged work still in metamodel-old. I would 
keep it around until things get sorted out.

- Original Message -
> From: "Steve Ebersole" 
> To: "hibernate-dev" 
> Sent: Wednesday, October 29, 2014 4:00:38 AM
> Subject: Re: [hibernate-dev] ORM master
> 
> FYI, does anyone need metamodel-old anymore?  Can I just delete that one
> upstream?
> 
> On Wed, Oct 29, 2014 at 6:00 AM, Steve Ebersole  wrote:
> 
> > Ok, all done now.  So at this point:
> >
> > 1) upstream/metamodel-old is the "metamodel" code as of the point before
> > when we merged it to master
> > 2) upstream/metamodel is the current state of metamodel work
> > 3) upstream/master is currently the same as 4.3.  It is the base from
> > which I will start the discussed simplified 5.0 development
> >
> >
> >
> > On Wed, Oct 29, 2014 at 5:22 AM, Steve Ebersole 
> > wrote:
> >
> >> I just noticed that the old metamodel branch was still around upstream.
> >> So far I have:
> >>
> >> 1) moved upstream/metamodel -> upstream/metamodel-old
> >> 2) deleted upstream/metamodel
> >> 3) moved upstream/master -> upstream/metamodel
> >>
> >> I'll wait a few minutes still before deleting master and re-priming it
> >> from 4.3
> >>
> >>
> >> On Wed, Oct 29, 2014 at 4:13 AM, Steve Ebersole 
> >> wrote:
> >>
> >>> Per the face to face discussion yesterday (I'll send out more details
> >>> later) I am working on branching master off to a new "metamodel" dev
> >>> branch
> >>> and priming a "new master" from 4.3 (the basic idea being to start work
> >>> on
> >>> a more targeted 5.0).
> >>>
> >>> Part of this is of course a massive change to the state of master
> >>> upstream. If anyone needs me to wait before starting this please let me
> >>> know immediately.  Thanks.
> >>>
> >>
> >>
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Mapping defaults for @OneToOne

[Gail Badner]

I'm a bit confused by the mapping defaults for @OneToOne defined in JPA 2.1.

Sections 2.10.1 and 2.10.3.1 (Bidirectional and Unidirectional OneToOne 
Relationships) says, "The foreign key column has the same type as the primary 
key of table B and there is a unique key constraint on it." 

Section 11.1.41 (OneToOne Annotation) says that, by default, optional=true, 
which translates into nullable foreign key column(s).

IIUC, the default mapping is not supported by many (all?) databases, because a 
constraint violation exception will be thrown if a column has a unique key 
constraint and there is more than one null value for that column.

Currently, Hibernate does not create a unique key unless @OneToOne( 
optional=false ) is defined. I believe Hibernate is doing the right thing here, 
but it is not consistent with the spec.

Is the spec wrong in this case, or am I missing something? Please let me know...

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

Re: [hibernate-dev] Mapping defaults for @OneToOne

[Gail Badner]

In both of the following cases, Hibernate creates a unique key constraint:

1) 
2) 

The documentation is clear that setting unique="true" indicates that a unique 
key constraint should be created. 

I only see mappings for  in the 
documentation.

Is the combination in 2) valid (unique="true" not-null="false")?

- Original Message -
> From: "Gail Badner" 
> To: "hibernate-dev" 
> Sent: Tuesday, December 2, 2014 9:34:24 PM
> Subject: [hibernate-dev] Mapping defaults for @OneToOne
> 
> I'm a bit confused by the mapping defaults for @OneToOne defined in JPA 2.1.
> 
> Sections 2.10.1 and 2.10.3.1 (Bidirectional and Unidirectional OneToOne
> Relationships) says, "The foreign key column has the same type as the
> primary key of table B and there is a unique key constraint on it."
> 
> Section 11.1.41 (OneToOne Annotation) says that, by default, optional=true,
> which translates into nullable foreign key column(s).
> 
> IIUC, the default mapping is not supported by many (all?) databases, because
> a constraint violation exception will be thrown if a column has a unique key
> constraint and there is more than one null value for that column.
> 
> Currently, Hibernate does not create a unique key unless @OneToOne(
> optional=false ) is defined. I believe Hibernate is doing the right thing
> here, but it is not consistent with the spec.
> 
> Is the spec wrong in this case, or am I missing something? Please let me
> know...
> 
> Thanks,
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release 4.3.8 and 4.2.17

[Gail Badner]

I'm getting ready to release 4.3.8 and 4.2.17. Please do not push any new fixes 
until they are released.

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

Re: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17

[Gail Badner]

I've finished building and taggind for 4.2.17.Final. I'm getting some final 
fixes in for 4.3.8.Final, then I'll release that version. I'll finish these up 
on Tuesday.
Gail

- Original Message -
> From: "Gail Badner" 
> To: "hibernate-dev" 
> Sent: Monday, January 5, 2015 1:10:08 PM
> Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
> 
> I'm getting ready to release 4.3.8 and 4.2.17. Please do not push any new
> fixes until they are released.
> 
> Thanks!
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17

[Gail Badner]

Hi Peter,

It looks like your pull request changed tabs to spaces, so there are a lot of 
diffs. I can't tell what exactly you changed. Please recreate the pull request 
without changing tabs to spaces.

I'm sorry, this will not make it into 4.3.8. I'll consider it for 4.3.9.

Regards,
Gail

- Original Message -
> From: "Petar Tahchiev" 
> To: "Gail Badner" 
> Cc: "hibernate-dev" 
> Sent: Tuesday, January 6, 2015 12:47:11 AM
> Subject: Re: [hibernate-dev] Preparing to release 4.3.8 and 4.2.17
> 
> Any chance to get this included
> https://github.com/hibernate/hibernate-orm/pull/863 ?
> 
> 
> 2015-01-06 10:37 GMT+02:00 Gail Badner :
> 
> > I've finished building and taggind for 4.2.17.Final. I'm getting some
> > final fixes in for 4.3.8.Final, then I'll release that version. I'll finish
> > these up on Tuesday.
> > Gail
> >
> > - Original Message -
> > > From: "Gail Badner" 
> > > To: "hibernate-dev" 
> > > Sent: Monday, January 5, 2015 1:10:08 PM
> > > Subject: [hibernate-dev] Preparing to release  4.3.8 and  4.2.17
> > >
> > > I'm getting ready to release 4.3.8 and 4.2.17. Please do not push any new
> > > fixes until they are released.
> > >
> > > Thanks!
> > > Gail
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 
> 
> 
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 4.3.8.Final and 4.2.17.Final Released

[Gail Badner]

For details, see 
http://in.relation.to/Bloggers/HibernateORM438FinalAnd4217FinalReleased.

Gail Badner
Red Hat, Hibernate ORM
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Could UUID be one of the default strategy when AUTO is requested

[Gail Badner]

There are some jiras for using UUIDs (in general, not specifically for IDs) for 
using a single mapping that would work for different dialects:
- https://hibernate.atlassian.net/browse/HHH-9562
- https://hibernate.atlassian.net/browse/HHH-9574 

It seems that these are related...

- Original Message -
> From: "Gunnar Morling" 
> To: "Sanne Grinovero" 
> Cc: "Hibernate Dev" 
> Sent: Monday, January 19, 2015 8:15:42 AM
> Subject: Re: [hibernate-dev] Could UUID be one of the default strategy when 
> AUTO is requested
> 
> We discussed a while ago whether it should be pluggable how AUTO is
> resolved:
> https://lists.jboss.org/pipermail/hibernate-dev/2014-November/011948.html
> 
> I still think that's a good idea.
> 
> In the case of OGM, it may even be a bit more complex. For example with
> MongoDB the following should result in IDENTITY being used (which is mapped
> to store-assigned object ids) rather than UUID:
> 
> @Id
> @GeneratedValue(strategy = GenerationType.AUTO)
> @Type(type = "objectid")
> String id;
> 
> So the @Type would have to be taken into account as well for mapping AUTO.
> 
> > For String, I wonder if someone would argue that it should actually map
> to a string-encoded output of a sequence.. "1", "2" ...
> 
> I don't think you can use sequences with String (only numeric values), so
> anyone having this expectation would also be unhappy as of today.
> 
> --Gunnar
> 
> 
> 2015-01-19 15:58 GMT+01:00 Sanne Grinovero :
> 
> > On 19 January 2015 at 13:33, Emmanuel Bernard 
> > wrote:
> > > Hey,
> > >
> > > I am throwing an idea, let me know what you think.
> > > If the return type of the id property of an entity is either String or
> > UUID, could we automatically consider one fo the uuid strategy as the one
> > matching AUTO?
> >
> > +1
> > That seems spot-on for the UUID type.
> > For String, I wonder if someone would argue that it should actually
> > map to a string-encoded output of a sequence.. "1", "2" ...
> > I'd personally agree that this is horrible and it should default to
> > UUID, just wondering.
> >
> > Would this violate any spec?
> >
> > >
> > > It would be useful for Hibernate OGM but I am also thinking that it
> > makes equal sense to Hibernate ORM users.
> > >
> > > Thoughts? I’m sure there are incompatibilities I have not think of.
> > >
> > > Emmanuel
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[hibernate-dev] Hibernate ORM 4.2.18.Final released

[Gail Badner]

I am having problems creating a weblog entry on in.relation.to. I will send 
another announcement with details when that is resolved.

Gail Badner
Red Hat, Hibernate ORM
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] in.relation.to error when posting a new blog entry

[Gail Badner]

I ran into the same thing a couple of weeks ago when I deleted some spam 
comments before trying to create new weblog. I asked Sanne about this and he 
mentioned that he's seen this happen after deleting spam comments. He said it 
would require some clean up, but he didn't have time.

Sanne, I know you're very busy. Can you point one of us in the right direction 
to clean up what is necessary?

Thanks,
Gail
- Original Message -
> From: "Davide D'Alto" 
> To: "hibernate-dev" 
> Sent: Wednesday, February 11, 2015 7:42:52 AM
> Subject: [hibernate-dev] in.relation.to error when posting a new blog entry
> 
> Hi,
> I'm trying to create a new blog entry on in.relation.to
> but an exception occurs about the violation of an integrity constraint.
> 
> Any idea on how to solve the issue?
> 
> Thanks,
> Davide
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Enum object bound to SQLQuery

[Gail Badner]

Should enum objects be converted to the appropriate type when bound to a native 
query?

It looks like they are converted properly when bound using a Criteria or HQL 
Query, but not for a SQLQuery.

Attached is a patch for EnumTypeTest that shows that it works for Criteria and 
HQL queries, and fails for SQLQuery.

Is this a bug?

Thanks,
Gail___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] in.relation.to error when posting a new blog entry

[Gail Badner]

I can look into this tomorrow. Please let me know if someone is already working 
on this.
Thanks,
Gail

- Original Message -
> From: "Sanne Grinovero" 
> To: "Gail Badner" , "Davide D'Alto" 
> Cc: "hibernate-dev" , "Sanne Grinovero" 
> 
> Sent: Wednesday, February 11, 2015 10:57:55 PM
> Subject: Re: [hibernate-dev] in.relation.to error when posting a new blog 
> entry
> 
> Hi, sorry I forgot about this and I'm currently away so if someone could
> look at it that would be great.
> I suspect it's a broken foreign key on MySQL, hopefully the error message
> will have some details? Some table maintenance should do the trick.
> You'll have to ssh into in.relation.to and from there connect to the MySQL
> console. The connection details are in the datasource description deployed
> in the AS (I don't remember them but that's a good place to read the
> hostname and access credentials to the db).
> The firewall on the db server will not allow you to connect from your own
> place, so make sure you use the MySQL console from the in.relation.to
> server.
> An alternative might be to use the AWS dashboard, maybe it has some tools
> for db maintenance? I usually use the terminal myself.
> 
> Thanks
> Sanne
> 
> On Thu, 12 Feb 2015 02:36 Gail Badner  wrote:
> 
> > I ran into the same thing a couple of weeks ago when I deleted some spam
> > comments before trying to create new weblog. I asked Sanne about this and
> > he mentioned that he's seen this happen after deleting spam comments. He
> > said it would require some clean up, but he didn't have time.
> >
> > Sanne, I know you're very busy. Can you point one of us in the right
> > direction to clean up what is necessary?
> >
> > Thanks,
> > Gail
> > - Original Message -
> > > From: "Davide D'Alto" 
> > > To: "hibernate-dev" 
> > > Sent: Wednesday, February 11, 2015 7:42:52 AM
> > > Subject: [hibernate-dev] in.relation.to error when posting a new blog
> > entry
> > >
> > > Hi,
> > > I'm trying to create a new blog entry on in.relation.to
> > > but an exception occurs about the violation of an integrity constraint.
> > >
> > > Any idea on how to solve the issue?
> > >
> > > Thanks,
> > > Davide
> > >
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] in.relation.to error when posting a new blog entry

[Gail Badner]

Good questions. I'll wait for a reply...

- Original Message -
> From: "Hardy Ferentschik" 
> To: "Sanne Grinovero" 
> Cc: "Gail Badner" , "Davide D'Alto" 
> , "hibernate-dev"
> 
> Sent: Friday, February 13, 2015 1:53:21 AM
> Subject: Re: [hibernate-dev] in.relation.to error when posting a new blog 
> entry
> 
> On Thu, Feb 12, 2015 at 06:57:55AM +, Sanne Grinovero wrote:
> > I suspect it's a broken foreign key on MySQL, hopefully the error message
> > will have some details? Some table maintenance should do the trick.
> 
> Do you literally talk about the table maintenance commands like
> REPAIR TABLE
> (http://dev.mysql.com/doc/refman/5.1/en/table-maintenance-sql.html),
> or do you have something else in mind?
> 
> Is it not a bit dangerous to let the uninitiated work against the prod
> database?
> Is there at least a nightly or at least regular copy of the database which
> can be
> restored in case something goes wrong? And if so where is it and how do I get
> hold
> of it?
> 
> --Hardy
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Enum object bound to SQLQuery

[Gail Badner]

OK, so this is expected.
Thanks!
Gail

- Original Message -
> From: "Steve Ebersole" 
> To: "Emmanuel Bernard" 
> Cc: "Gail Badner" , "Hibernate Dev" 
> 
> Sent: Monday, February 16, 2015 11:55:54 AM
> Subject: Re: [hibernate-dev] Enum object bound to SQLQuery
> 
> Probably the difference is the idea of "auto determination" of a
> parameter's "expected" Type.  In HQL/JPQL and Criteria queries I have a lot
> of code in place to determine the expected type of a parameter based any
> "corresponding property reference".  In native SQL queries there is no such
> opportunity to perform this "auto determination".
> 
> On Mon, Feb 16, 2015 at 10:33 AM, Emmanuel Bernard 
> wrote:
> 
> > Do we do any other conversion in SQLQueries from the property type to the
> > SQL type? I don’t think we do.
> >
> > > On 13 Feb 2015, at 06:15, Gail Badner  wrote:
> > >
> > > Should enum objects be converted to the appropriate type when bound to a
> > native query?
> > >
> > > It looks like they are converted properly when bound using a Criteria or
> > HQL Query, but not for a SQLQuery.
> > >
> > > Attached is a patch for EnumTypeTest that shows that it works for
> > Criteria and HQL queries, and fails for SQLQuery.
> > >
> > > Is this a bug?
> > >
> > > Thanks,
> > > Gail___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 

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

Re: [hibernate-dev] ORM Team "triage" meeting

[Gail Badner]

11am Seattle time would be ideal. Thanks!
Gail

- Original Message -
> From: "Brett Meyer" 
> To: "hibernate-dev" 
> 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" 
> > To: "Steve Ebersole" 
> > Cc: "hibernate-dev" 
> > 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  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@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release 4.3.9.Final and 4.2.19.Final

[Gail Badner]

Please do not push any commits to 4.3 or 4.2 branches until I finish the 
releases.
Thanks!
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM Team "triage" meeting

[Gail Badner]

When will we start having these meetings?

- Original Message -
> From: "Sanne Grinovero" 
> To: "hibernate-dev" 
> 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  wrote:
> > 11am Seattle time would be ideal. Thanks!
> > Gail
> >
> > - Original Message -
> >> From: "Brett Meyer" 
> >> To: "hibernate-dev" 
> >> 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" 
> >> > To: "Steve Ebersole" 
> >> > Cc: "hibernate-dev" 
> >> > 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  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@lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Preparing to release 4.3.9.Final and 4.2.19.Final

[Gail Badner]

I've finished with the releases and have uploaded artifacts, release bundles, 
and docs for both releases.

I'll write up a blog later this evening with some details.

Thanks,
Gail

- Original Message -
> From: "Gail Badner" 
> To: "hibernate-dev" 
> Sent: Wednesday, April 15, 2015 2:13:48 PM
> Subject: [hibernate-dev] Preparing to release 4.3.9.Final and 4.2.19.Final
> 
> Please do not push any commits to 4.3 or 4.2 branches until I finish the
> releases.
> Thanks!
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate 4.3.9.Final and 4.2.19.Final Released

[Gail Badner]

For details, see: 
http://in.relation.to/Bloggers/HibernateORM439Final4218FinalAnd4219FinalReleased

Gail Badner
Red Hat, Hibernate ORM
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] hibernate.cache.default_cache_concurrency_strategy has no effect

[Gail Badner]

This mailing list is for discussing Hibernate development. Please open a JIRA 
issue at https://hibernate.atlassian.net/projects/HHH and attach your test.

Thanks,
Gail
- Original Message -
> From: "Mihalcea Vlad" 
> To: "Hibernate Dev" 
> Sent: Wednesday, April 29, 2015 7:01:11 AM
> Subject: [hibernate-dev] hibernate.cache.default_cache_concurrency_strategy   
> has no effect
> 
> Hi,
> Setting the "hibernate.cache.default_cache_concurrency_strategy" property
> doesn't have any effect.
> This setting is inspected in
> AnnotationBinder.prepareDefaultCacheConcurrencyStrategy method, but
> thatmethod is never called.
> 
> Here's a test to replicate the issue:
> https://github.com/vladmihalcea/hibernate-master-class/blob/master/core/src/test/java/com/vladmihalcea/hibernate/masterclass/laboratory/cache/CollectionCacheTest.java
> The only workaround is to manually declare the caching strategy on each
> entity:
> @Entity(name = "repository")
> @org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
> Vlad Mihalcea
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final

[Gail Badner]

I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.

I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 
7.1.0.Final:

1) 
https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
2) 
https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
(The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared 
duplicate 1b7e112994413559484e6873f019c5e2c557506b).

1) updated infinispan-configs.xml to use
http://www.w3.org/2001/XMLSchema-instance";
xmlns="urn:infinispan:config:7.0"
xsi:schemaLocation="urn:infinispan:config:7.0 
http://www.infinispan.org/schemas/infinispan-config-7.0.xsd";>

After 1) was cherry-picked, I was able to build and run tests successfully 
using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) 
using Infinispan 6.0.0.Final, there were lots of test failures due to problems 
configuring the cache:
Caused by: org.hibernate.cache.CacheException
Caused by: org.infinispan.commons.CacheConfigurationException
Caused by: javax.xml.stream.XMLStreamException

I've attached the output from test 
org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.

Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 
branch? Could an application have its own dependence on Infinispan 6.0.0.Final?

Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 
7.2.1.Final: 
https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87.
 After rebuilding,  
org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase 
fails. I've attached the output for that test as well. 

Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing 
some other commit that would fix the TimestampsRegionImplTestCase failure?

This commit (for HHH-9781) includes a change to use 
org.infinispan.commons.util.CloseableIterator, which does not appear to be in 
Infinispan 6.0.0.Final, so this would not be backward-compatible either.

Next I cherry-picked the commit for HHH-9776: 
https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5.
 TimestampsRegionImplTestCase still fails; there are no other failures.

Galder, HHH-9776 is still open. Is there more work to be done on that issue?

I've pushed this work to my fork for others to see: 
https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.

I've postponed creating a pull request and running the TCK until we resolve 
backward-compatibility requirements and the unit test failure. It's OK with me 
if someone wants to go ahead and run the TCK with what I have so far.

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

Re: [hibernate-dev] Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final

[Gail Badner]

Hi Galder,

I'm not thinking too well atm (it's 2am) and really need to get to sleep. 

If someone else wants to look it over, push, and get the standalone TCK 
started, please feel free. Otherwise, I will pick this up first thing tomorrow.

Thanks for the pull request!

Gail
- Original Message -
> From: "Galder Zamarreño" 
> To: "Gail Badner" 
> Cc: "Galder Zamarreno" , "Sanne Grinovero" 
> , "Scott Marlow"
> , "Hibernate Dev" 
> Sent: Monday, May 11, 2015 1:31:07 AM
> Subject: Re: Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final
> 
> Hi Gail,
> 
> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works
> fine with both Infinispan 7.x and 6.x:
> https://github.com/hibernate/hibernate-orm/pull/948
> 
> Cheers,
> 
> > On 11 May 2015, at 09:48, Galder Zamarreño  wrote:
> > 
> > Hi Gail,
> > 
> > Thanks for looking into this.
> > 
> > For the scope of WF, the XML part is irrelevant since WF does its own
> > configuration parsing, and hence there's no need to make any such changes
> > in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x
> > standalone, then yes, they need to adjust XML configuration.
> > 
> > The evict/clear issues that 7.2 brought up, and the incorrect element count
> > can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We
> > just need to apply the changes in a way that work regardless of whether
> > 6.0 or 7.2 is used.
> > 
> > I'll work on that today.
> > 
> > Cheers,
> > 
> >> On 11 May 2015, at 07:49, Gail Badner  wrote:
> >> 
> >> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
> >> 
> >> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use
> >> Infinispan 7.1.0.Final:
> >> 
> >> 1)
> >> https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
> >> 2)
> >> https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
> >> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26)
> >> appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
> >> 
> >> 1) updated infinispan-configs.xml to use
> >> http://www.w3.org/2001/XMLSchema-instance";
> >>   xmlns="urn:infinispan:config:7.0"
> >>   xsi:schemaLocation="urn:infinispan:config:7.0
> >>   http://www.infinispan.org/schemas/infinispan-config-7.0.xsd";>
> >> 
> >> After 1) was cherry-picked, I was able to build and run tests successfully
> >> using Infinispan 7.1.0.Final. When I tried running tests (without
> >> cleaning) using Infinispan 6.0.0.Final, there were lots of test failures
> >> due to problems configuring the cache:
> >>   Caused by: org.hibernate.cache.CacheException
> >>   Caused by: org.infinispan.commons.CacheConfigurationException
> >>   Caused by: javax.xml.stream.XMLStreamException
> >> 
> >> I've attached the output from test
> >> org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
> >> 
> >> Do we need to continue to support running Infinispan 6.0.0.Final in ORM
> >> 4.3 branch? Could an application have its own dependence on Infinispan
> >> 6.0.0.Final?
> >> 
> >> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to
> >> 7.2.1.Final:
> >> https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87.
> >> After rebuilding,
> >> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase
> >> fails. I've attached the output for that test as well.
> >> 
> >> Galder, HHH-9781 is still open. Is there more work to do on this? Am I
> >> missing some other commit that would fix the TimestampsRegionImplTestCase
> >> failure?
> >> 
> >> This commit (for HHH-9781) includes a change to use
> >> org.infinispan.commons.util.CloseableIterator, which does not appear to
> >> be in Infinispan 6.0.0.Final, so this would not be backward-compatible
> >> either.
> >> 
> >> Next I cherry-picked the commit for HHH-9776:
> >> https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5.
> >> TimestampsRegionImplTestCase still fails; there are no other failures.
> >> 
> >> Galder, HHH-9776 is still open. Is there more work to be done on that
> >> issue?
> >> 
> >> I've pushed this work to my fork for others to see:
> >> https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
> >> 
> >> I've postponed creating a pull request and running the TCK until we
> >> resolve backward-compatibility requirements and the unit test failure.
> >> It's OK with me if someone wants to go ahead and run the TCK with what I
> >> have so far.
> >> 
> >> Regards,
> >> Gail
> >> 
> > 
> > 
> > --
> > Galder Zamarreño
> > gal...@redhat.com
> > 
> > 
> > 
> > 
> 
> 
> --
> Galder Zamarreño
> gal...@redhat.com
> 
> 
> 
> 
> 

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

Re: [hibernate-dev] Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final

[Gail Badner]

Just to let you know, I'm working on the pull request. 

My plan is to:
- merge pull request (still need to review)
- re-build/test hibernate-infinispan using Infinispan 6.0.0.Final
- manually test hibernate-infinispan using Infinispan 7.2.1.Final [1]
- push commit and snapshot
- run standalone TCK using Hibernate 4.3 snapshot with Infinispan 6.0.0.Final
- run standalone TCK using Hibernate 4.3 snapshot with Infinispan 7.2.1.Final

If all goes well, release 4.3.10.Final. If not, I'll keep you posted.

[1] I'd like to change the gradle build so that hibernate-infinispan unit tests 
are executed twice; first time using Infinispan 6.0.0.Final; second time using 
7.2.1.Final. I haven't done much with gradle, so if someone can tell me quickly 
how to do this, I'll get the gradle build change into 4.3.10.Final; otherwise, 
I'll get that build change into 4.3.11.Final.

Thanks,
Gail

- Original Message -
> From: "Steve Ebersole" 
> To: "Sanne Grinovero" 
> Cc: "Galder Zamarreño" , "Scott Marlow" 
> , "Gail Badner" ,
> "Hibernate Dev" 
> Sent: Monday, May 11, 2015 9:14:37 AM
> Subject: Re: Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final
> 
> WRT 4.4, no! :)
> 
> On Mon, May 11, 2015 at 10:52 AM, Sanne Grinovero 
> wrote:
> 
> > On 11 May 2015 at 16:35, Galder Zamarreño  wrote:
> > >
> > >> On 11 May 2015, at 17:26, Sanne Grinovero  wrote:
> > >>
> > >> Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan
> > 7.2.1.Final ?
> > >> Was Infinispan 6 friendly to JDK 6 users?
> > >
> > > Yup, Infinispan 6 requires JDK 6, and Infinispan 7 requires JDK7.
> > >
> > > Also, on top of JDK changes, not sure it'd be a good idea to make a
> > dependency update of that magnitude in a bug fix release, since it'd change
> > the Infinispan version used, and you'd break all the standalone 4.3 users
> > that have tweaked Infinispan configuration, they'd have to move to the more
> > WF/AS-like XML configuration. Those using default would be fine since we
> > could tweak the default configuration.
> >
> > Ok, many good reasons :)
> >
> > But it's a worrying divergence between the catefory of users running
> > in WildFly and who doesn't. Also we'd want CI tests for both
> > Infinispan integrations, which is not trivial because of all the
> > changes in the Infinispan configuration format.
> >
> > Should this be a 4.4.0 release?
> >
> > Regarding the JDK, one could say that Java 7 is required when using
> > the Infinispan cache. This is something we'd need to document for
> > Hibernate ORM 5 anyway, might as well have it apply to a 4.4.
> >
> > Thanks,
> > Sanne
> >
> > >
> > > Cheers,
> > >
> > >>
> > >> On 11 May 2015 at 16:23, Galder Zamarreño  wrote:
> > >>>
> > >>>> On 11 May 2015, at 16:45, Scott Marlow  wrote:
> > >>>>
> > >>>> Do we need to have a Hibernate ORM continuous integration test setup
> > to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or
> > is ORM/Infinispan already tested as part of the Infinispan CI testing?
> > >>>
> > >>> In this particular case, as mentioned below, running ORM 4.3 testsuite
> > with Infinispan 7.2.1 would mostly fail because of XML changes. Again, this
> > does not affect WF, so it would not really help you much.
> > >>>
> > >>> We do have some tests in Infinispan CI to test integration with HB but
> > need some updates [1].
> > >>>
> > >>> Cheers,
> > >>>
> > >>> [1]
> > http://ci.infinispan.org/project.html?projectId=HibernateIntegration
> > >>>
> > >>>>
> > >>>> On 05/11/2015 04:31 AM, Galder Zamarreño wrote:
> > >>>>> Hi Gail,
> > >>>>>
> > >>>>> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it
> > works fine with both Infinispan 7.x and 6.x:
> > >>>>> https://github.com/hibernate/hibernate-orm/pull/948
> > >>>>>
> > >>>>> Cheers,
> > >>>>>
> > >>>>>> On 11 May 2015, at 09:48, Galder Zamarreño 
> > wrote:
> > >>>>>>
> > >>>>>> Hi Gail,
> > >>>>>>
> > >>>>>> Thanks for looking into this.
> >

Re: [hibernate-dev] Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final

[Gail Badner]

See below for status...

I could not figure out a way to re-run Hibernate tests using Infinispan 
7.2.1.Final without rebuilding source code. I tried `gradle --no-rebuild` but 
it didn't seem to work. When the source code is rebuilt, there are lots of 
failures.

Anyone have ideas how to do this?

- Original Message -
> From: "Gail Badner" 
> To: "Steve Ebersole" 
> Cc: "Hibernate Dev" , "Galder Zamarreño" 
> 
> Sent: Monday, May 11, 2015 1:23:04 PM
> Subject: Re: [hibernate-dev] Problems upgrading ORM 4.3 branch to use 
> Infinispan 7.2.1.Final
> 
> Just to let you know, I'm working on the pull request.
> 
> My plan is to:
> - merge pull request (done; also added updates to BulkOperationsTestCase for 
> testing HHH-9781)
> - re-build/test hibernate-infinispan using Infinispan 6.0.0.Final (done)
> - manually test hibernate-infinispan using Infinispan 7.2.1.Final [1] (could 
> not figure out how to do this)
> - push commit and snapshot (done)
> - run standalone TCK using Hibernate 4.3 snapshot with Infinispan 6.0.0.Final 
> (in progress)
> - run standalone TCK using Hibernate 4.3 snapshot with Infinispan 7.2.1.Final 
> (will work with Scott Marlow to do this Tuesday)
> 
> If all goes well, release 4.3.10.Final. If not, I'll keep you posted.
> 
> [1] I'd like to change the gradle build so that hibernate-infinispan unit
> tests are executed twice; first time using Infinispan 6.0.0.Final; second
> time using 7.2.1.Final. I haven't done much with gradle, so if someone can
> tell me quickly how to do this, I'll get the gradle build change into
> 4.3.10.Final; otherwise, I'll get that build change into 4.3.11.Final.
> 
> Thanks,
> Gail
> 
> - Original Message -
> > From: "Steve Ebersole" 
> > To: "Sanne Grinovero" 
> > Cc: "Galder Zamarreño" , "Scott Marlow"
> > , "Gail Badner" ,
> > "Hibernate Dev" 
> > Sent: Monday, May 11, 2015 9:14:37 AM
> > Subject: Re: Problems upgrading ORM 4.3 branch to use Infinispan
> > 7.2.1.Final
> > 
> > WRT 4.4, no! :)
> > 
> > On Mon, May 11, 2015 at 10:52 AM, Sanne Grinovero 
> > wrote:
> > 
> > > On 11 May 2015 at 16:35, Galder Zamarreño  wrote:
> > > >
> > > >> On 11 May 2015, at 17:26, Sanne Grinovero  wrote:
> > > >>
> > > >> Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan
> > > 7.2.1.Final ?
> > > >> Was Infinispan 6 friendly to JDK 6 users?
> > > >
> > > > Yup, Infinispan 6 requires JDK 6, and Infinispan 7 requires JDK7.
> > > >
> > > > Also, on top of JDK changes, not sure it'd be a good idea to make a
> > > dependency update of that magnitude in a bug fix release, since it'd
> > > change
> > > the Infinispan version used, and you'd break all the standalone 4.3 users
> > > that have tweaked Infinispan configuration, they'd have to move to the
> > > more
> > > WF/AS-like XML configuration. Those using default would be fine since we
> > > could tweak the default configuration.
> > >
> > > Ok, many good reasons :)
> > >
> > > But it's a worrying divergence between the catefory of users running
> > > in WildFly and who doesn't. Also we'd want CI tests for both
> > > Infinispan integrations, which is not trivial because of all the
> > > changes in the Infinispan configuration format.
> > >
> > > Should this be a 4.4.0 release?
> > >
> > > Regarding the JDK, one could say that Java 7 is required when using
> > > the Infinispan cache. This is something we'd need to document for
> > > Hibernate ORM 5 anyway, might as well have it apply to a 4.4.
> > >
> > > Thanks,
> > > Sanne
> > >
> > > >
> > > > Cheers,
> > > >
> > > >>
> > > >> On 11 May 2015 at 16:23, Galder Zamarreño  wrote:
> > > >>>
> > > >>>> On 11 May 2015, at 16:45, Scott Marlow  wrote:
> > > >>>>
> > > >>>> Do we need to have a Hibernate ORM continuous integration test setup
> > > to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or
> > > is ORM/Infinispan already tested as part of the Infinispan CI testing?
> > > >>>
> > > >>> In this particular case, as mentioned below, running ORM 4.3
> > > >>> testsuite
> > > with Infinispan

Re: [hibernate-dev] Another pull request for supporting Infinispan 7.2.1 in 4.3

[Gail Badner]

Adding hibernate-dev.

No, I did not have a chance to read up on what you suggested. I sounded like it 
had some limitations that would not work, but maybe I misunderstood. I'll look 
into it today.

The last couple of days have been very long. Sorry for the oversights.

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" 
> Cc: "Sanne Grinovero" , "Scott Marlow" 
> , "Galder Zamarreño"
> 
> Sent: Wednesday, May 13, 2015 5:33:24 AM
> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> 
> On May 13, 2015 7:32 AM, "Steve Ebersole"  wrote:
> >
> > 1) This really should be a hibernate-core discussion
> 
> I meant to say hibernate-dev...
> 
> > 2) I already suggested using forced version in Gradle and gave you a link
> on how that works.  Did you read it?  Did you try it?
> >
> > On May 13, 2015 2:04 AM, "Gail Badner"  wrote:
> >>
> >> Sanne, Scott, and I discussed how Hibernate should deal with supporting
> Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it would
> be sufficient to:
> >> - specify the Infinispan 7.2 configuration by using
> hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to switch if
> parsing failed);
> >> - run tests manually with Infinispan 7.2 for WildFly integration testing.
> >>
> >> I created another pull request:
> https://github.com/hibernate/hibernate-orm/pull/953
> >>
> >> My pull request incorporated some of Galder's changes from
> https://github.com/hibernate/hibernate-orm/pull/951.
> >>
> >> The main differences:
> >> - Hibernate will consider the 7.2 configuration as test code
> >> - the 7.2 configuration can be specified using
> -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> >>
> >> Currently, the only way to run hibernate-infinispan tests is to change
> infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice to be
> able to specify infinispanVersion as a environment variable, defaulting to
> 6.0.0.Final to avoid having to manually update libraries.gradle.
> >>
> >> Another consideration is that manually updating libraries.gradle forces
> a re-build using Infinispan 7.2.1 as a dependency.
> >>
> >> Since WildFly will use a hiberanate-infinispan jar build against
> Infinispan 6.0.0.Final (won't it???), I think it would be best if we could
> run unit tests without rebuilding with Infinispan 7.2.1, but using it as a
> run time dependency. I haven't been able to figure out how to do that
> though.
> >>
> >> Anyone have an idea how to do that, even manually?
> >>
> >> Thoughts on all this?
> >>
> >> Thanks,
> >> Gail
> 

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

Re: [hibernate-dev] Another pull request for supporting Infinispan 7.2.1 in 4.3

[Gail Badner]

As suggested by Sanne and Galder, I'll open a new Jira for the commit in my 
pull request and amend the comment to reflect the new Jira.

I'll see if I can get "forced version" in Gradle working in the next couple of 
hours. If not, I don't want to hold up releasing 4.3.10.Final for this. I can 
try to get those details worked out later.

I think that about wraps up what is needed for Hibernate 4.3 to support and 
test with Infinispan 7.2.1.Final.  Unless I hear otherwise, I plan to release 
4.3.10.Final later today, tomorrow at the latest.

Regards,
Gail

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" 
> Cc: "Sanne Grinovero" , "Scott Marlow" 
> , "Galder Zamarreño"
> , "Hibernate Dev" 
> Sent: Wednesday, May 13, 2015 9:57:24 AM
> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> 
> Not sure what limitations you mean.  All I said was that if you wanted to
> allow testing with both you would need to make this conditional and expose
> a property to control which to use.
> 
> On Wed, May 13, 2015 at 11:29 AM, Gail Badner  wrote:
> 
> > Adding hibernate-dev.
> >
> > No, I did not have a chance to read up on what you suggested. I sounded
> > like it had some limitations that would not work, but maybe I
> > misunderstood. I'll look into it today.
> >
> > The last couple of days have been very long. Sorry for the oversights.
> >
> > - Original Message -
> > > From: "Steve Ebersole" 
> > > To: "Gail Badner" 
> > > Cc: "Sanne Grinovero" , "Scott Marlow" <
> > smar...@redhat.com>, "Galder Zamarreño"
> > > 
> > > Sent: Wednesday, May 13, 2015 5:33:24 AM
> > > Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> > >
> > > On May 13, 2015 7:32 AM, "Steve Ebersole"  wrote:
> > > >
> > > > 1) This really should be a hibernate-core discussion
> > >
> > > I meant to say hibernate-dev...
> > >
> > > > 2) I already suggested using forced version in Gradle and gave you a
> > link
> > > on how that works.  Did you read it?  Did you try it?
> > > >
> > > > On May 13, 2015 2:04 AM, "Gail Badner"  wrote:
> > > >>
> > > >> Sanne, Scott, and I discussed how Hibernate should deal with
> > supporting
> > > Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it would
> > > be sufficient to:
> > > >> - specify the Infinispan 7.2 configuration by using
> > > hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to switch if
> > > parsing failed);
> > > >> - run tests manually with Infinispan 7.2 for WildFly integration
> > testing.
> > > >>
> > > >> I created another pull request:
> > > https://github.com/hibernate/hibernate-orm/pull/953
> > > >>
> > > >> My pull request incorporated some of Galder's changes from
> > > https://github.com/hibernate/hibernate-orm/pull/951.
> > > >>
> > > >> The main differences:
> > > >> - Hibernate will consider the 7.2 configuration as test code
> > > >> - the 7.2 configuration can be specified using
> > >
> > -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> > > >>
> > > >> Currently, the only way to run hibernate-infinispan tests is to change
> > > infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice to be
> > > able to specify infinispanVersion as a environment variable, defaulting
> > to
> > > 6.0.0.Final to avoid having to manually update libraries.gradle.
> > > >>
> > > >> Another consideration is that manually updating libraries.gradle
> > forces
> > > a re-build using Infinispan 7.2.1 as a dependency.
> > > >>
> > > >> Since WildFly will use a hiberanate-infinispan jar build against
> > > Infinispan 6.0.0.Final (won't it???), I think it would be best if we
> > could
> > > run unit tests without rebuilding with Infinispan 7.2.1, but using it as
> > a
> > > run time dependency. I haven't been able to figure out how to do that
> > > though.
> > > >>
> > > >> Anyone have an idea how to do that, even manually?
> > > >>
> > > >> Thoughts on all this?
> > > >>
> > > >> Thanks,
> > > >> Gail
> > >
> >
> 

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

Re: [hibernate-dev] Another pull request for supporting Infinispan 7.2.1 in 4.3

[Gail Badner]

I don't think I fully understand Gradle ResolutionStrategy. [1] 

I'm looking for something that could be used to change test runtime 
dependencies, without rebuilding the hibernate-infinspan jar. I'm not 
proficient enough with Gradle to know if ResolutionStrategy can be used for 
that, I'll have to look into it after 4.3.10.Final is released.

I did some experimenting though and found that by making the following change 
in libraries.gradle, I can test with a different version of Infinispan:

-infinispanVersion = '6.0.0.Final'
+infinispanVersion =  project.hasProperty( 'infinispanVersion' ) ? 
infinispanVersion : '6.0.0.Final'

I can force Hibernate to test using Infinispan 7.2.1.Final with the 7.2 test 
configuration using the command:
../gradlew test -PinfinispanVersion=7.2.1.Final 
-Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml

Unfortunately, it forces source/test code to be rebuilt using Infinispan 
7.2.1.Final. I would really like to be able to test using the 
hibernate-infinispan jar built using Infinispan 6.0.0.Final as a build 
dependency, because WildFly will be using the Hibernate 4.3.10.Final jar built 
with Infinispan 6.0.0.Final.

I'm going to move forward with releasing 4.3.10.Final and revisit this later.

Thanks everyone for your help on getting 4.3 to work with Infinispan 
7.2.1.Final. It is very much appreciated.

Gail

[1] 
http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html
 

- Original Message -
> From: "Scott Marlow" 
> To: "Gail Badner" , "Steve Ebersole" 
> Cc: "Sanne Grinovero" , "Galder Zamarreño" 
> , "Hibernate Dev"
> 
> Sent: Wednesday, May 13, 2015 11:56:04 AM
> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> 
> 
> On 05/13/2015 02:48 PM, Gail Badner wrote:
> > As suggested by Sanne and Galder, I'll open a new Jira for the commit in my
> > pull request and amend the comment to reflect the new Jira.
> >
> > I'll see if I can get "forced version" in Gradle working in the next couple
> > of hours. If not, I don't want to hold up releasing 4.3.10.Final for this.
> > I can try to get those details worked out later.
> >
> > I think that about wraps up what is needed for Hibernate 4.3 to support and
> > test with Infinispan 7.2.1.Final.  Unless I hear otherwise, I plan to
> > release 4.3.10.Final later today, tomorrow at the latest.
> 
> Awesome, thanks for all of the help Gail in syncing Hibernate up to
> Infinispan 7.2.1!  Thanks to Sanne, Galder & Steve as well.  Very much
> appreciated!
> 
> I'm not sure of what will be in Infinispan 8.0 but that could need more
> hibernate-infinispan changes as well.  I think that Infinispan 8.0 might
> find its way into WildFly 10.
> 
> >
> > Regards,
> > Gail
> >
> > - Original Message -
> >> From: "Steve Ebersole" 
> >> To: "Gail Badner" 
> >> Cc: "Sanne Grinovero" , "Scott Marlow"
> >> , "Galder Zamarreño"
> >> , "Hibernate Dev" 
> >> Sent: Wednesday, May 13, 2015 9:57:24 AM
> >> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> >>
> >> Not sure what limitations you mean.  All I said was that if you wanted to
> >> allow testing with both you would need to make this conditional and expose
> >> a property to control which to use.
> >>
> >> On Wed, May 13, 2015 at 11:29 AM, Gail Badner  wrote:
> >>
> >>> Adding hibernate-dev.
> >>>
> >>> No, I did not have a chance to read up on what you suggested. I sounded
> >>> like it had some limitations that would not work, but maybe I
> >>> misunderstood. I'll look into it today.
> >>>
> >>> The last couple of days have been very long. Sorry for the oversights.
> >>>
> >>> - Original Message -
> >>>> From: "Steve Ebersole" 
> >>>> To: "Gail Badner" 
> >>>> Cc: "Sanne Grinovero" , "Scott Marlow" <
> >>> smar...@redhat.com>, "Galder Zamarreño"
> >>>> 
> >>>> Sent: Wednesday, May 13, 2015 5:33:24 AM
> >>>> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> >>>>
> >>>> On May 13, 2015 7:32 AM, "Steve Ebersole"  wrote:
> >>>>>
> >>>>> 1) This really should be a hibernate-core discussion
> >>>>
> >&

Re: [hibernate-dev] Another pull request for supporting Infinispan 7.2.1 in 4.3

[Gail Badner]

Hi Steve,

Thanks for the explanation. That helps a lot. I'll see if I can get it working 
tomorrow morning.

I'll release 4.3.10.Final Thursday. After working 3 late nights in a row, I 
need to rest tonight.

Regards,
Gail

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" 
> Cc: "Scott Marlow" , "Sanne Grinovero" 
> , "Galder Zamarreño"
> , "Hibernate Dev" 
> Sent: Wednesday, May 13, 2015 7:03:19 PM
> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> 
> Well you have to realize that there are 3 classpaths involved here:
> 1) compiling the main sources (compile)
> 2) compiling the test sources (testCompile)
> 3) running the tests (testRuntime)
> 
> You can set each of those differently.  But instead what you do is to
> change all 3 to the same value.  Obviously if you ask Gradle to compile
> with a different Infinispan version by specifying it in compile
> Configuration it is going to recognize that and recompile the main
> sources.  That's a GoodThing(tm).  But really you are doing the wrong
> thing.  Really you just want to keep the same Infinispan version
> (6.whatever) for compile and testCompile.  You really just want variance in
> testRuntime.
> 
> The one concern with this is that Gradle willl then see a "version
> conflict".  It will see Infinispan 6 in the compile and testCompile (via
> compile) configurations, and Infinispan 7 in the testRuntime
> configuration.  I am not exactly sure what Gradle will do there.  But I do
> know that you can tell Gradle what to do there... by forcing the version.
> In fact ResolutionStrategy is all about these "version conflicts" and what
> to do.
> 
> So something like this in hibernate-infinispan.gradle:
> 
> if ( useInfinispan7ForTesting() ) {
> configurations {
> testRuntime {
> resolutionStrategy {
> force 'org.infinispan:infinispan-core:7.2.1.Final`
> }
> }
> }
> }
> 
> dependencies {
> compile( libraries.infinispan ) // 6, as before
> ...
> }
> 
> I actually think you can use force to force the version to use even if it
> is not a case of a version conflict.  That's what the above tries.  In
> testRuntime there really is not version conflict
> for 'org.infinispan:infinispan-core', but we ask Gradle to force
> the 'org.infinispan:infinispan-core' version to 7.2.1.Final.  That is my
> reading of how forced versions work based on the DSL guide.  I have not
> tried it myself, so I do not know how it works in practice.
> 
> 
> On Wed, May 13, 2015 at 7:43 PM, Gail Badner  wrote:
> 
> > I don't think I fully understand Gradle ResolutionStrategy. [1]
> >
> > I'm looking for something that could be used to change test runtime
> > dependencies, without rebuilding the hibernate-infinspan jar. I'm not
> > proficient enough with Gradle to know if ResolutionStrategy can be used for
> > that, I'll have to look into it after 4.3.10.Final is released.
> >
> > I did some experimenting though and found that by making the following
> > change in libraries.gradle, I can test with a different version of
> > Infinispan:
> >
> > -infinispanVersion = '6.0.0.Final'
> > +infinispanVersion =  project.hasProperty( 'infinispanVersion' ) ?
> > infinispanVersion : '6.0.0.Final'
> >
> > I can force Hibernate to test using Infinispan 7.2.1.Final with the 7.2
> > test configuration using the command:
> > ../gradlew test -PinfinispanVersion=7.2.1.Final
> > -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> >
> > Unfortunately, it forces source/test code to be rebuilt using Infinispan
> > 7.2.1.Final. I would really like to be able to test using the
> > hibernate-infinispan jar built using Infinispan 6.0.0.Final as a build
> > dependency, because WildFly will be using the Hibernate 4.3.10.Final jar
> > built with Infinispan 6.0.0.Final.
> >
> > I'm going to move forward with releasing 4.3.10.Final and revisit this
> > later.
> >
> > Thanks everyone for your help on getting 4.3 to work with Infinispan
> > 7.2.1.Final. It is very much appreciated.
> >
> > Gail
> >
> > [1]
> > http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html
> >
> > - Original Message -
> > > From: "Scott Marlow" 
> > > To: "Gail Badner" , "Steve Ebersole" <
> > st...@hibernate.org>
> > >

[hibernate-dev] Preparing to release 4.3.10.Final

[Gail Badner]

Please do not push any commits until after 4.3.10.Final is released.
Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 4.3.10.Final Released

[Gail Badner]

For details, see: http://in.relation.to/Bloggers/HibernateORM4310FinalReleased
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1

[Gail Badner]

Following Steve's suggestion using resolutionStrategy, I was able to build the 
hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit tests 
with 7.2.1.Final.

I'm sure there's a more elegant way to do this, so I've created a new jira 
(HHH-9802) and a pull request with the change I made: 
https://github.com/hibernate/hibernate-orm/pull/955 .

There were actually some unit test failures in InfinispanRegionFactoryTestCase 
using 7.2.1.Final due to java.lang.NoSuchMethodError. 

It happens in assertions like:

 assertEquals(5000, cacheCfg.eviction().maxEntries());

The problem is that 
org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() returns 
int in 6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is in 
the unit tests. I can probably workaround this in the unit test, but I was 
wondering if this could cause a problem if an application used this method 
directly. 

Galder, do you know if this is a concern?

I have instructions in the pull request for reproducing these failures.

I commented out the failing assertions locally to verify that nothing else 
causes the test to fail.

I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is 
defined as an int. That gets initialized based on a value set for on 
hibernate.cache.infinispan..eviction.max_entries. The only place I 
see TypeOverrides.getEvictionMaxEntries() used is in 
InfinispanRegionFactoryTestCase. Does this actually get used anywhere? Does the 
value find its way into a EvictionConfiguration.maxEntries field? If so, should 
be a long (instead of an int) in master?

I had a quick chat with Scott Marlow when I realized this was a potential 
problem and we agreed that it shouldn't block releasing Hibernate ORM 
4.3.10.Final. I have gone ahead and released 4.3.10.Final. 

I will check in on things Friday morning, but I have to leave by 10:30am and 
will be off the rest of the day. I can pick this up on Monday if need be.

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

Re: [hibernate-dev] Changelog file in Hibernate ORM

[Gail Badner]

Here is my 2 cents. 

I find it helpful that the changelog contains all jiras for all releases that 
feed into a particular version. It makes it clear when later branches were 
branched off. 

This is particularly helpful when we are maintaining multiple branches and 
commits are being backported to different branches.
 
My preference would be to truncate the changelogs to the point at which 4.2, 
4.3, and 5 branches diverge.

For master: include everything starting form 4.3.6.Final (the last version in 
master changelog that is also included in 4.3 changelog).

For 4.3: include everything starting from 4.1.5.SP1 (the last version in 4.3 
changelog that is also included in 4.2 changelog).

For 4.2: leave changelog.txt as is.

This helps me track down when things are amiss (e.g., for regressions). I know 
there are other ways to investigate things related to misplaced/forgotten 
commits, but the changelogs have been a good starting point for me.

Gail
 

- Original Message -
> From: "Hardy Ferentschik" 
> To: "Brett Meyer" 
> Cc: "Hibernate" 
> Sent: Thursday, May 28, 2015 1:42:05 AM
> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> 
> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > +1 from me.  Although, on the other hand, do we really need to keep
> > maintaining that to begin with?  I guess I never thought simply having
> > users go to the JIRA release notes was a big deal.  Just my $.02.
> 
> Same for me on both counts, the proposed handling of changelog.txt as well as
> Brett's comment regarding the usefulness of this file altogether.
> 
> --Hardy
> 
> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Changelog file in Hibernate ORM

[Gail Badner]

+1 to listing the the version prior to branching.

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" 
> Cc: "hibernate-dev" , "Hardy Ferentschik" 
> 
> Sent: Thursday, May 28, 2015 12:58:42 PM
> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> 
> I don't like the idea of a 5.0 change log having 4.x issues.  It kind of
> defeats the whole purpose.
> 
> As a compromise, I can see noting the last previous family release in the
> changlog.  Again using 5.0 as an example, make a note that 5.0 development
> started after 4.3.6
> On May 28, 2015 2:01 PM, "Gail Badner"  wrote:
> 
> > Here is my 2 cents.
> >
> > I find it helpful that the changelog contains all jiras for all releases
> > that feed into a particular version. It makes it clear when later branches
> > were branched off.
> >
> > This is particularly helpful when we are maintaining multiple branches and
> > commits are being backported to different branches.
> >
> > My preference would be to truncate the changelogs to the point at which
> > 4.2, 4.3, and 5 branches diverge.
> >
> > For master: include everything starting form 4.3.6.Final (the last version
> > in master changelog that is also included in 4.3 changelog).
> >
> > For 4.3: include everything starting from 4.1.5.SP1 (the last version in
> > 4.3 changelog that is also included in 4.2 changelog).
> >
> > For 4.2: leave changelog.txt as is.
> >
> > This helps me track down when things are amiss (e.g., for regressions). I
> > know there are other ways to investigate things related to
> > misplaced/forgotten commits, but the changelogs have been a good starting
> > point for me.
> >
> > Gail
> >
> >
> > - Original Message -
> > > From: "Hardy Ferentschik" 
> > > To: "Brett Meyer" 
> > > Cc: "Hibernate" 
> > > Sent: Thursday, May 28, 2015 1:42:05 AM
> > > Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> > >
> > > On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > > > +1 from me.  Although, on the other hand, do we really need to keep
> > > > maintaining that to begin with?  I guess I never thought simply having
> > > > users go to the JIRA release notes was a big deal.  Just my $.02.
> > >
> > > Same for me on both counts, the proposed handling of changelog.txt as
> > well as
> > > Brett's comment regarding the usefulness of this file altogether.
> > >
> > > --Hardy
> > >
> > >
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Changelog file in Hibernate ORM

[Gail Badner]

I would prefer retaining all bugs fixes that feed into EAP. 

The first Hibernate version used by EAP was roughly 3.2.4.sp1 (there were a few 
extra commits included in the version that got into EAP).

Are you planning to truncate the change logs for 3.2 or 3.3? If so, it would be 
helpful to me retain the bug fixes in those changelogs going back to at least 
3.2.4.sp1

FWIW, I'm fine with the changelog containing everything. I don't particularly 
care how large they get.

- Original Message -
> From: "andrea boriero" 
> To: "Sanne Grinovero" 
> Cc: "Hibernate Dev" 
> Sent: Friday, May 29, 2015 4:48:08 AM
> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> 
> I would mantain all 5.x in the same changelog file and may be the previous
> one.
> 
> On 29 May 2015 at 12:32, Sanne Grinovero  wrote:
> 
> > I wouldn't stay awake at night because of that :) maybe only if the
> > file gets huge?
> > It's useful for people migrating, but since I doubt someone would
> > migrate from pre-1.0 (at least without expecting to rewrite it all),
> > that's why I suggested to keep from 3.0 onwards.
> >
> > On 29 May 2015 at 12:16, Steve Ebersole  wrote:
> > > So it makes sense to you that the changelog for 5.0 includes entries for
> > pre
> > > 1.0?
> > >
> > > On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero 
> > > wrote:
> > >>
> > >> I'm +1 especially to keep the changelog.txt file both maintained and
> > >> included.
> > >>
> > >> About pruning older content: I'd keep the past few years at least, for
> > >> sake of who's finally upgrading.
> > >> Maybe since version 3.0 onwards? Or just keep it all :)
> > >>
> > >> On 29 May 2015 at 12:05, Steve Ebersole  wrote:
> > >> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You
> > want
> > >> > to
> > >> > keep a massive changelog.txt containing all history forever?
> > >> >
> > >> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero  > >
> > >> > wrote:
> > >> >>
> > >> >> On 29 May 2015 at 08:15, Emmanuel Bernard 
> > >> >> wrote:
> > >> >> >
> > >> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik 
> > >> >> >> wrote:
> > >> >> >>
> > >> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > >> >> >>> +1 from me.  Although, on the other hand, do we really need to
> > keep
> > >> >> >>> maintaining that to begin with?  I guess I never thought simply
> > >> >> >>> having users
> > >> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> > >> >> >>
> > >> >> >> Same for me on both counts, the proposed handling of changelog.txt
> > >> >> >> as
> > >> >> >> well as Brett's comment regarding the usefulness of this file
> > >> >> >> altogether.
> > >> >> >
> > >> >> > A more frequent than I thought usage of changelog vs JIRA is a mix
> > of
> > >> >> > Ctrl+F + quick scan to know what has changed in a library or know
> > >> >> > what is
> > >> >> > affecting me. JIRA is not the most intuitive UI in the universe.
> > With
> > >> >> > allt
> > >> >> > he bug statuses, the various intermediary releases to select etc,
> > >> >> > nothing
> > >> >> > beats changelog.txt.
> > >> >>
> > >> >> +1
> > >> >> - JIRA's UI is not too bad but let's remember that while we use it
> > >> >> since years, others might not feel comfortable with it
> > >> >> - many of those receiving our "dist" package might not have internet
> > >> >> access at all
> > >> >> - the dist packages is long term archived, like we include sources it
> > >> >> should contain a snapshot of all state. I like JIRA but who knows how
> > >> >> long it will be there?
> > >> >>
> > >> >> ___
> > >> >> hibernate-dev mailing list
> > >> >> hibernate-dev@lists.jboss.org
> > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >
> > >> >
> > >> ___
> > >> hibernate-dev mailing list
> > >> hibernate-dev@lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] How to run master unit test in Intellij with non-default DB

[Gail Badner]

For 4.3 and before, when running a unit test in Intellij using a non-default 
DB, I would simply add the JDBC jar as a module dependency and then add the 
hibernate-specific properties (e.g., for dialect, etc) as VM options in the 
Run/Debug configuration. 

This doesn't work for master because the added dependency is not getting picked 
up.

Is there some other way to do this without messing with build.gradle or 
libraries.gradle?

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

Re: [hibernate-dev] How to run master unit test in Intellij with non-default DB

[Gail Badner]

I imported the project as a Gradle project and the Run/Debug configuration is 
listed under "Gradle".

Gradle project: 
/home/gbadner/git/hibernate-orm-HHH-redo-again/hibernate-entitymanager

Tasks: cleanTest test

VM options: -Dhibernate.jdbc.use_get_generated_keys=false 
-Dhibernate.connection.password=... 
-Dhibernate41.dialect=org.hibernate.dialect.DB2Dialect 
-Dhibernate.jdbc.use_streams_for_binary=false 
-Dhibernate.connection.username=... 
-Dhibernate.connection.driver_class=com.ibm.db2.jcc.DB2Driver 
-Dhibernate.dialect=org.hibernate.dialect.DB2Dialect 
-Dhibernate.connection.url=... -Dhibernate.connection.schema=...
 
Script parameters: --tests org.hibernate.jpa.test.query.QueryTest

How do I add db2jcc4.jar as a dependency?

Thanks,
Gail

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" , "Hibernate Dev" 
> 
> Sent: Thursday, June 4, 2015 6:46:24 PM
> Subject: Re: [hibernate-dev] How to run master unit test in Intellij with 
> non-default DB
> 
> I would assume you are using the "Run with Gradle" stuff in IntelliJ rather
> than the normal "Run it in IntelliJ" stuff
> 
> On Thu, Jun 4, 2015 at 7:01 PM Gail Badner  wrote:
> 
> > For 4.3 and before, when running a unit test in Intellij using a
> > non-default DB, I would simply add the JDBC jar as a module dependency and
> > then add the hibernate-specific properties (e.g., for dialect, etc) as VM
> > options in the Run/Debug configuration.
> >
> > This doesn't work for master because the added dependency is not getting
> > picked up.
> >
> > Is there some other way to do this without messing with build.gradle or
> > libraries.gradle?
> >
> > Thanks,
> > Gail
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] TREAT operator and joined inheritance (HHH-9862)

[Gail Badner]

JPA 2.1 shows examples of using multiple downcasts in a restriction:

4.4.9 Downcasting

SELECT e FROM Employee e
WHERE TREAT(e AS Exempt).vacationDays > 10 
  OR TREAT(e AS Contractor).hours > 100

6.5.7 Downcasting

Example 3:
CriteriaQuery q = cb.createQuery(Employee.class);
Root e = q.from(Employee.class);
q.where(
   cb.or(cb.gt(cb.treat(e, Exempt.class).get(Exempt_.vacationDays),
   10),
   cb.gt(cb.treat(e, Contractor.class).get(Contractor_.hours),
   100)));

These don't work in Hibernate for joined inheritance because Hibernate uses an 
inner join for the downcasts.

I've added a FailureExpected test case for this: 
https://github.com/hibernate/hibernate-orm/commit/1ec76887825bebda4c02ea2bc1590d374aa4415b

IIUC, inner join is correct when TREAT is used in a JOIN clause. If TREAT is 
only used for restrictions in the WHERE clause, I *think* it should be an outer 
join. Is that correct?

HHH-9862 also mentions that Hibernate doesn't work properly when there are 
multiple select expressions using different downcasts, as in:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery query = cb.createQuery(Object[].class);
Root root = query.from(Pet.class);
query.multiselect(
root.get("id"),
root.get("name"),
cb.treat(root, Cat.class).get("felineProperty"),
cb.treat(root, Dog.class).get("canineProperty")
);

I don't think this should work, at least not with implicit joins. Is this valid?

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

Re: [hibernate-dev] TREAT operator and joined inheritance (HHH-9862)

[Gail Badner]

See below:

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" , "Hibernate Dev" 
> 
> Sent: Tuesday, June 16, 2015 11:00:49 AM
> Subject: Re: [hibernate-dev] TREAT operator and joined inheritance (HHH-9862)
> 
> As for the "multi-select" case you mention, JPA actually does not mention
> support for TREAT in select clauses.  In fact it explicitly lists support
> for TREAT in the from and where clause.  So because it explicitly mentions
> those, I'd say it implicitly excludes support for them in select clause.
> 
> 
> The use of the TREAT operator is supported for downcasting within path
> expressions in the FROM and
> WHERE clauses. ...
> 
>

Yes, I noticed this as well.
 
> So unfortunately there is no "properly" in this case because JPA does not
> define what is proper.  There is just what we deem to be appropriate.

We have some unit tests that have a single TREAT select expression on the root 
entity using HQL and CriteriaBuilder:

Using HQL (https://hibernate.atlassian.net/browse/HHH-8637): 
org.hibernate.test.jpa.ql.TreatKeywordTest.testFilteringDiscriminatorSubclasses
org.hibernate.test.jpa.ql.TreatKeywordTest.testFilteringJoinedSubclasses

Using CriteriaBuilder (https://hibernate.atlassian.net/browse/HHH-9549):
org.hibernate.jpa.test.criteria.TreatKeywordTest.treatRoot
org.hibernate.jpa.test.criteria.TreatKeywordTest.treatRootReturnSuperclass

As you can see, Hibernate supports one TREATed root entity in a SELECT clause 
(no projections). Should we limit Hibernate support to that use case?

> 
> There is a lot of difficulty in getting the inner/outer join right here.  The
> difficulty is knowing the context that the TREAT occurs in in the code that
> is building the join fragment.  Ultimately this is done
> in
> org.hibernate.persister.entity.AbstractEntityPersister#determineSubclassTableJoinType.
> But that method has no visibility into whether this is driven by a select
> or a where or a from or ...
> 
> And in fact I'd argue that its not just a question of select versus from.
> Its really more a question of how many other treats occur for that same
> "from element" and whether they are used in an conjunctive (AND) or
> disjunctive (OR) way.  But I am not convinced we'd ever be able to get the
> inner/outer join right in all these cases.  At the least the contextual
> info we'd need is well beyond what we have available to us given the
> current SQL generation engine here.  And even if we did have all the
> information available to us. I am not sure it is reasonable way to apply
> restrictions.
> 
> Maybe a slightly different way to look at this is better.  Rather that
> attempting to alter the outer join (which is what Hibernate would use for
> the subclasses) to be inner joins in certain cases, maybe we instead just
> use a type restriction.  Keeping in mind that by default Hibernate will
> want to render the joins for subclasses as outer joins, I think this is
> easiest to understand with some examples
> 
> 1) "select p.id, p.name from Pet p where treat(p as Cat).felineProperty =
> 'x' or treat(p as Dog).canineProperty = 'y'"
> So by default Hibernate would want to render SQL here like:
> select ...
> from Pet p
>left outer join Dog d on ...
>left outer join Cat c on ..
> where c.felineProperty = 'x'
>   or d.canineProperty = 'y'
> 
> which is actually perfect in this case.
> 
> 2) "select p.id, p.name from Pet p where treat(p as Cat).felineProperty =
> 'x' and treat(p as Dog).canineProperty = 'y'"
> Hibernate would render SQL like:
> from Pet p
>left outer join Dog d on ...
>left outer join Cat c on ..
> where c.felineProperty = 'x'
>   and d.canineProperty = 'y'
> 
> which again is actually perfect here.
> 
> As it turns out the original "alter join for treat" support was done to
> handle the case of a singular restriction:
> 
> 3) "select p.id, p.name from Pet p where treat(p as Cat).felineProperty <>
> 'x'"
> Hibernate would render SQL like:
> from Pet p
>left outer join Dog d on ...
>left outer join Cat c on ..
> where c.felineProperty <> 'x'
> 
> the problem here is that Dogs can also be returned.  In retrospect looking
> at all these cases I think it might have been better to instead render a
> restriction for the type into the where:
> 
> from Pet p
>left outer join Dog d on ...
>left outer join Cat c on ..
> where (  and c.felineProperty <> 'x' )
> 
> ( is the case statement that is used to restrict based
> on conc

Re: [hibernate-dev] Hibernate 4 Multi-tenancy Issue - No Entity Persisters Found

[Gail Badner]

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" 
> To: "amit shah" 
> Cc: "Hibernate" 
> 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  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  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 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
> >>
> >>  >> value="org.hibernate.jpa.HibernatePersistenceProvider"/> >> name="persistenceXmlLocation"
> >> value="/com/software/persistence/persistence.xml"/> >> name="jpaProperties">
> >> 
> >> 
> >>  >> value="false"/>
> >>  >> value="com.software.persistence.ExtendedOracle10gDialect"/>
> >> 
> >> 
> >>  >> value="com.software.persistence.OracleBatchBuilder"/>
> >> 
> >>  >>
> >> value="com.software.persistence.MultitenantIdentifierResolver"/>
> >>  >>   value-ref="multiTenantConnectionProvider" />
> >> 
> >>
> >> 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@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] How should hibernate-entitymanager test classes be instrumented?

[Gail Badner]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] How should hibernate-entitymanager test classes be instrumented?

[Gail Badner]

OK, got it.
Thanks!
Gail

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" , "Hibernate" 
> 
> 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  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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM Team "triage" meeting

[Gail Badner]

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

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" 
> Cc: "Sanne Grinovero" , "hibernate-dev" 
> 
> 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  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  wrote:
> >
> >> When will we start having these meetings?
> >>
> >> - Original Message -
> >> > From: "Sanne Grinovero" 
> >> > To: "hibernate-dev" 
> >> > 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  wrote:
> >> > > 11am Seattle time would be ideal. Thanks!
> >> > > Gail
> >> > >
> >> > > - Original Message -
> >> > >> From: "Brett Meyer" 
> >> > >> To: "hibernate-dev" 
> >> > >> 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" 
> >> > >> > To: "Steve Ebersole" 
> >> > >> > Cc: "hibernate-dev" 
> >> > >> > 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 
> >> 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
> >&

Re: [hibernate-dev] How should hibernate-entitymanager test classes be instrumented?

[Gail Badner]

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" 
> To: "Steve Ebersole" 
> Cc: "Hibernate" 
> 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" 
> > To: "Gail Badner" , "Hibernate"
> > 
> > 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  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@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] org.hibernate.jpa.AvailableSettings.EVENT_LISTENER_PREFIX

[Gail Badner]

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  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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM Team "triage" meeting

[Gail Badner]

+1

- Original Message -
> From: "andrea boriero" 
> To: "Steve Ebersole" 
> Cc: "hibernate-dev" 
> 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  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 
> > 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 
> > > wrote:
> > >
> > >> I have a problem on Monday but Tuesday is fine.
> > >>
> > >> On 14 July 2015 at 18:06, Gail Badner  wrote:
> > >>
> > >>> Next week is fine. Monday or Tuesday work for me.
> > >>>
> > >>> - Original Message -
> > >>> > From: "Steve Ebersole" 
> > >>> > To: "Gail Badner" 
> > >>> > Cc: "Sanne Grinovero" , "hibernate-dev" <
> > >>> hibernate-dev@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 
> > >>> 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 
> > >>> wrote:
> > >>> > >
> > >>> > >> When will we start having these meetings?
> > >>> > >>
> > >>> > >> - Original Message -
> > >>> > >> > From: "Sanne Grinovero" 
> > >>> > >> > To: "hibernate-dev" 
> > >>> > >> > 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 
> > >>> wrote:
> > >>> > >> > > 11am Seattle time would be ideal. Thanks!
> > >>> > >> > > Gail
> > >>> > >> > >
> > >>> > >> > > - Original Message -
> > >>> > >> > >> From: "Brett Meyer" 
> > >>> > >> > >> To: "hibernate-dev" 
> > >>> > >> > >> 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" 
> > >>> > >> > >> > To: "Steve Ebersole" 
> > >>> >

Re: [hibernate-dev] org.hibernate.jpa.AvailableSettings.EVENT_LISTENER_PREFIX

[Gail Badner]

Ah, OK. I see.
Thanks,
Gail

- Original Message -
> From: "Steve Ebersole" 
> To: "Gail Badner" , "Hibernate" 
> 
> 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  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  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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Enum mapping in hbm.xml

[Gail Badner]

+1 from me as well.
Gail

- Original Message -
> From: "Hardy Ferentschik" 
> To: "Steve Ebersole" 
> Cc: "Hibernate Dev" 
> 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 +, 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest

[Gail Badner]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest

[Gail Badner]

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" 
> To: "Hibernate Dev" 
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] org.hibernate.test.annotations.manytoone.referencedcolumnname.ManyToOneReferencedColumnNameTest

[Gail Badner]

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" 
> To: "Gail Badner" 
> Cc: "Hibernate Dev" 
> 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  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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 

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

Re: [hibernate-dev] HQLScrollFetchTest

[Gail Badner]

See replies below...

- Original Message -
> From: "Steve Ebersole" 
> To: "hibernate-dev" 
> 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":


I don't think there is any reason that the test needs to use an IDENTITY 
column. Using  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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release 4.2.20.Final and 4.3.11.Final

[Gail Badner]

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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] 4.2.20.Final and SourceForge problems; delaying 4.3.11.Final until next week

[Gail Badner]

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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.0 defaults

[Gail Badner]

I mentioned my concerns about hibernate.implicit_naming_strategy and
auto-quoting keywords when I was getting the standalone TCK working with
master.

Here are my thoughts...

On 08/03/2015 02:17 PM, Steve Ebersole wrote:

> 1) hibernate.implicit_naming_strategy - by default Hibernate uses its
> legacy implicit naming strategy which predates the clarifications made in
> JPA 2.0 by many years.  The question here is whether we want to change
this
> (now/ever) to use the JPA (2.0) compliant one?

IMO, the JPA annnotations should generate tables/columns/etc that are
JPA-compliant by default. If a developer is adding JPA annotations, I think
there is a pretty good likelihood they will be referring to Javadoc or
looking at the annnotations interface itself in an IDE. I think there would
be an expectation that the generated names due to the JPA annotations would
be consistent with what is documented. I think there is also an expectation
that the generated names would be portable.

Here are some examples of bugs I fixed in 4.2/4.3 where generated names
were not consistent with JPA2:
- HHH-9387 (generated table name for @ElementCollection uses entity class
name; should use entity name);
- HHH-9389 (generated join column for @ElementCollection uses entity class
name; should use entity name);
- HHH-9390 (generated foreign key column name for unidirectional
@ManyToMany uses owning entity primary table name; should use owning entity
name.

I agree that 4.2/4.3 was not the proper time to make those changes the
default because it would be a breaking fix that would affect existing
applications.

IMO, 5 is a good place to make JPA-compliant naming the default. It would
still be a breaking change. Existing applications would need to make
necessary changes to either the JPA annotations or to the database objects
themselves to become JPA-compliant (and portable).

>
> 2) hibernate.auto_quote_keyword - by default we decided to have Hibernate
> automatically quote identifiers it thinks are key/reserved words in the
> underlying database.  We know at the moment this is a bit too aggressive
as
> it pulls in all of SQL:2003 defined keywords.  The question is whether we
> disable this by default?

I think it will take some time to get the keyword list right for each
dialect. I wouldn't be surprised if different versions of a DBMS would have
different keywords. This could complicate things as most dialects are used
for multiple versions of a DBMS.

If 5.0.0 is released with auto-quoting as a default, and a later 5.0.x
version excludes keywords, it will be a breaking change for applications
that were developed or migrated to an earlier 5.0 version.

Also, auto-quoting keywords (only) is not JPA-compliant.

I would be more comfortable if auto-quoting keywords is considered
experimental, and not the default behavior.


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

[hibernate-dev] Preparing to release 4.3.11.Final

[Gail Badner]

Please don't push anything to 4.3 branch until I'm finished with the
release.
Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Finished with 4.3.11.Final release

[Gail Badner]

I will blog and send out announcements on Thursday.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 4.2.20.Final and 4.3.11.Final Released

[Gail Badner]

For details, see
http://in.relation.to/2015/08/07/hibernate-orm-4220-final-and-4311-final-released
.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Naming strategies 4.3 -> 5.0

[Gail Badner]

See below...

On Sat, Aug 15, 2015 at 7:25 AM, Steve Ebersole  wrote:

> I think I may have goofed when I implemented some of the
> ImplicitNamingStrategy rules in 5.0.
>
> During that transition, I wrote a bunch of unit test in 4.3 to serve as a
> baseline to make sure I got the logic/rules right as I developed 5.0.  But
> I think I may have set up those initial 4.3 tests improperly.
> Specifically, there are a few meant to test Hibernate's legacy naming
> behavior, aka its non-JPA-compliant naming.
>
> I think I got confused by the whole concept of NamingStrategy and
> NamingStrategyDelegate and NamingStrategyDelegator that had gotten added to
> 4.3.
>
> So on 4.3, what is the proper way to specify Hibernate should use
> JPA-compliant implicit naming?  What is the proper way to specify that it
> should use its legacy naming?
>

This is well-documented at:
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#configuration-namingstrategy

There are also some properties that are available for use with Entity
Manager (only documented in
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#configuration-misc-properties
):
- hibernate.ejb.naming_strategy
-hibernate.ejb.naming_strategy_delegator


>
> The issue came to light via HHH-9908.  Consider a mapping like:
>
> @Entity
> @Table(name = "ptx")
> public class Ptx {
>
> @Id
> private Integer id;
>
> @ManyToMany
> private List inputs1;
>
> }
>

>
> Assuming that Inputs defines its primary table as "input", the
> JPA-compliant naming would be "ptx_input".  That is what happens on 4.3
> using EJB3NamingStrategy.  It is actually also what happens on master using
> ImplicitNamingStrategyJpaCompliantImpl.
>
> However, the "legacy" part I cannot figure out.  Unless I misremember, back
> in the day we used to interpret these based on the attribute name, rather
> than the associated table name.  So here we'd have "ptx_inputs1".  That is
> in fact what ImprovedNamingStrategy does on 4.3.  But I
> believe ImprovedNamingStrategy is not the default on 4.3.  Again, between
> NamingStrategy and NamingStrategyDelegate and NamingStrategyDelegator it is
> VERY hard to understand what it going on, so maybe I just missed
> something.  Anyway, on 4.3 setting no naming strategy forces this to behave
> in a JPA-compliant way, meaning the implicit name here is "ptx_input" when
> I do not specify anything for NamingStrategy(Delegat(e/or)).  So either
> that got screwed up in 4.2/4.3 (whenever those new indirections where
> added) or I simply misremember what we used to do here.
>

Are you talking about the generated table name, or the foreign key name? I
see that the test case attached to HHH-9908 uses Spring. Do you have a test
case for this that does not use Spring?

HHH-9390 fixed a bug when generating the default foreign key name in a
unidirectional many-to-many that refers to the owner.

Ih JSR 388, 2.10.5.2 Unidirectional ManyToMany Relationships:

"Entity A is mapped to a table named A.
Entity B is mapped to a table named B.
There is a join table that is named A_B (owner name first). This join table
has two foreign key columns. One foreign key column refers to table A and
has the same type as the primary key of table A. The name of this foreign
key column is formed as the concatenation of the following: the name of
entity A; " _"; the name of the primary key column in table A. The other
foreign key column refers to table B and has the same type as the primary
key of table B. The name of this foreign key column is formed as the
concatenation of the following: the name of the relationship property or
field of entity A; " _ "; the name of the primary key column in table B"

The legacy behavior differed for the first FK:
"The name of this foreign key column is formed as the concatenation of the
following: the name of entity A; " _"; the name of the primary key column
in table A."

The legacy behavior was to use the table name (not the entity name).

The JPA-compliant behavior is provided by
ImprovedNamingStrategyDelegator#jpaNamingStrategyDelegate,
which, by default, is of type JpaNamingStrategyDelegate. It will properly
use the entity name.

This difference is illustrated in
org.hibernate.test.annotations.manytomany.defaults.DefaultNamingManyToManyTest#testUnidirOwnerEntityNamePrimaryTableOverride
and extended by ImprovedManyToManyDefaultsTestFor (this was done before you
mentioned your strong dislike for testing using inheritance...):

As far as I know, collection table naming and the other FK (that references
the associated entity) were unchanged by my fixes.

Also, the spec wrt the join table name and FKs for bidirectional
many-to-many is different from unidirectional. I did not find any problems
with how Hibernate was generating the join table or FKs for bidirectional
many-to-many.

If there is a specific case that doesn't look right, please create a test
case that reproduces it and I'll take a look.

[hibernate-dev] Compile error in hibernate-infinispan

[Gail Badner]

I just pulled from master and tried building but got:

/home/gbadner/git/hibernate-orm-HHH-redo-again/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/util/Caches.java:307:
error:  is not
abstract and does not override abstract method remove() in Iterator
return new CloseableIterator() {
   ^
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Integrator Causes Flush When Using JPA Transactions Around Queries

[Gail Badner]

This mailing list is for hibernate developers to discuss Hibernate
development. Please use the user forum for help:
https://forum.hibernate.org/.



On Wed, Aug 26, 2015 at 9:38 PM, Wolfgang Wedemeyer 
wrote:

> Greetings Hibernate Developers!
>
> I'm working on an Integrator for Hibernate (background on Integrators:
> https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch14.html#objectstate-decl-security
> <
> https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch14.html#objectstate-decl-security>)
> that by using listeners is supposed to take my data from how it's stored in
> the DB and convert it into a different form for processing at runtime. This
> works great when saving the data using .persist() however there's an odd
> behavior involving transactions. It appears that since the Integrator does
> a modification on the entity in question it gets marked as "dirty" and upon
> committing this odd transaction, it bypasses my event listeners and writes
> the value back in the wrong format! How can I write my Integrator to behave
> correctly in this case so that I can "undo" the conversion that has
> happened with my entities at runtime and not flush the wrong value out?
>
> I have further details including quickstart tutorial code that uncovered
> the issue for me posted on Stack Overflow:
> http://stackoverflow.com/questions/31671824/hibernate-integrator-causes-flush-when-using-jpa-transactions-around-queries
> <
> http://stackoverflow.com/questions/31671824/hibernate-integrator-causes-flush-when-using-jpa-transactions-around-queries
> >
> but have yet to receive any responses. Feel free to reply there or send me
> a response back to this email if you can be of assistance.
>
> Thanks,
> Wolfgang
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 4.2 and 4.3 branches

[Gail Badner]

Just a gentle reminder that, in keeping with our project's guidelines[1],
the 4.2 and 4.3 branches will no longer be actively maintained now that 5.0
has gone Final.

I plan to do 1 more 4.3 release (4.3.12)  [2]. That will be last 4.3
release.

Applications using Hibernate ORM 4.3 should be migrated to use Hibernate
ORM 5.0, and bugs reported on 4.3 branch will need to be reproduced on 5.0
branch to be considered for fixing in 5.0 branch.

[1]
https://github.com/hibernate/hibernate-orm/wiki/Development-and-Version-Family-Branches
[2] https://hibernate.atlassian.net/projects/HHH/versions/20952
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-3555

[Gail Badner]

I've created a new pull request for HHH-3555. [1]

A new pull request was needed because there have been lots of changes in
master since the original pull request [2] was created.

I would like to get this pushed to master and, if possible, to 5.0 branch.

There are some questions in the pull request I need answered before moving
forward.

Could someone familiar with Envers please take a look at [1] when you have
a chance.

Thanks!
Gail

[1] https://github.com/hibernate/hibernate-orm/pull/1079
[2] https://github.com/hibernate/hibernate-orm/pull/847
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Multi-level Fetch Joins

[Gail Badner]

Is the only JPA-compliant way to do a multi-level fetch join to use entity
graphs?

JPA 2.1 does not support fetch joins using an alias at all. JSR 338,
4.4.5.3 Fetch Joins says,

"It is not permitted to specify an identification variable for the objects
referenced by the right side of the FETCH JOIN clause, and hence references
to the implicitly fetched entities or elements cannot appear elsewhere in
the query. "

(I know that HQL supports using an alias for nested fetch joins. [1][2])

Also in JSR 338, 4.4.5.3 Fetch Joins is:

fetch_join ::= [ LEFT [OUTER] | INNER ] JOIN FETCH
join_association_path_expression

If I understand correctly, the definition of
join_association_path_expression does not allow for join fetching a nested
association using a path, as in:

select c from Cat c join fetch c.father join fetch c.father.mother <= not
supported by JPA or HQL

(There is an open Jira for supporting nested join fetches using HQL:
HHH-8206. [3])

Is there a JPA 2.0-compliant way to do this (without entity graphs)?

Thanks,
Gail

[1]
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#queryhql-joins
[2]
https://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#d5e1869
[3] https://hibernate.atlassian.net/browse/HHH-8206
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-3555

[Gail Badner]

Hi Adam and Felix,

There have also been some changes to existing methods. In some cases, the
arguments don't seem to be passed correctly.

I don't want to risk breaking things in Hibernate 5, so please answer my
questions in the pull request:
https://github.com/hibernate/hibernate-orm/pull/1079.
.
Thanks,
Gail

On Tue, Sep 15, 2015 at 5:24 AM, Adam Warski  wrote:

> Hello,
>
> thanks a lot for taking the time to migrate that PR!
> I’m really out-of-touch with the current changes in Hibernate, however
> there are no changes to the existing public interface (only method
> additions), and if the tests pass, it’s safe to merge.
>
> There’s definitely a lot of value in having only -to-one relations working
> alone, so I think -to-maby support may be safely left for later.
>
> Adam
>
>
> On 11 Sep 2015, at 20:48, Gail Badner  wrote:
>
> I've created a new pull request for HHH-3555. [1]
>
> A new pull request was needed because there have been lots of changes in
> master since the original pull request [2] was created.
>
> I would like to get this pushed to master and, if possible, to 5.0 branch.
>
> There are some questions in the pull request I need answered before moving
> forward.
>
> Could someone familiar with Envers please take a look at [1] when you have
> a chance.
>
> Thanks!
> Gail
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1079
> [2] https://github.com/hibernate/hibernate-orm/pull/847
>
>
> --
> Adam Warski
>
> http://twitter.com/#!/adamwarski
> http://www.softwaremill.com
> http://www.warski.org
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 4.2.21.Final Released

[Gail Badner]

http://in.relation.to/2015/10/23/hibernate-orm-4221-final-released/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] hibernate-core and hibernate-infinspan failures

[Gail Badner]

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

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

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

[1] http://ci.hibernate.org/job/hibernate-orm-5.0-h2/11/testReport/
[2] http://pastebin.com/LHppW5jm
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Which dialect for Enterprise DB Postgres Plus Advanced Server 9.4?

[Gail Badner]

I see that StandardDatabaseInfoDialectResolver selects PostgresPlusDialect
for database named "EnterpriseDB". Is that still correct for Enterprise DB
Postgres Plus Advanced Server 9.4, or should PostgreSQL94Dialect be used?

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

Re: [hibernate-dev] The HHH-9764 issue

[Gail Badner]

This is something that got broken in 4.3 when we moved to using load plans.
I agree this needs to be fixed. I will get to this later this week.

On Mon, Dec 7, 2015 at 12:18 AM, Vlad Mihalcea 
wrote:

> Hi,
>
> Someone on Twitter pointed out this issue:
> https://hibernate.atlassian.net/browse/HHH-9764
> I managed to add a test case using the Hibernate ORM Test Templates and the
> issue is replicated.
>
> The question is whether we should run the version check when loading
> entities from the database. This issue is caused by initializing a
> collection that contains a previously loaded entity which has changed in
> between.
>
> I also think we shouldn't raise the exception in this case because the
> client might not modify the data anyway.
>
> Vlad
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [ORM] Synchronization on AbstractLoadPlanBasedLoader

[Gail Badner]

Looks like this is related to HHH-8679 and HHH-8939:

IIRC, the code in AbstractLoadPlanBasedLoader was copied from Loader.

Here's the commit that removed the comment you mention from Loader#
wrapResultSetIfEnabled and added a synchronized block to
retreiveColumnNameToIndexCache (HHH-8679):
https://github.com/hibernate/hibernate-orm/commit/71d5a746e331d805f336585f72723d46e746adf4

Here's the commit that removed the synchronized block from
Loader#retreiveColumnNameToIndexCache(HHH-8939):
https://github.com/hibernate/hibernate-orm/commit/af5804a49cc8a93a61733def6e1df779d6a2e02e

It looks like we didn't make the same changes when we moved to load plans.

On Tue, Dec 15, 2015 at 4:49 AM, Steve Ebersole  wrote:

> I did not add those comments; they were just in some code I copied over
> into that class.
>
> On Tue, Dec 15, 2015, 4:02 AM Sanne Grinovero  wrote:
>
> > On 15 December 2015 at 01:46, Steve Ebersole 
> wrote:
> > > It's very possible that code comments may no longer be pertinent.
> >
> > Right, that's what I'm trying to figure out. Do you remember which
> > possible deadlock it might have referred to?
> >
> > >
> > > On Mon, Dec 14, 2015 at 10:26 AM Sanne Grinovero 
> > > wrote:
> > >>
> > >> Hi all,
> > >> while reviewing an improvement by Stale about reducing
> > >> synchronization, I'm having the impression that the synchronization
> > >> could be completely removed.
> > >>
> > >> But there's a comment warning me against that, so for sake of safety
> > >> I'm merging the improvement without risking going too far:
> > >>
> > >>  // synchronized to avoid multi-thread access issues; defined as
> > >> method synch to avoid
> > >>  // potential deadlock issues due to nature of code.
> > >>
> > >> I tried to figure what "potential deadlock" it's referring to, but I'm
> > >> having the impression the comment might be outdated. So I've reduced
> > >> the contention to the only include the code block about which I'm not
> > >> confident.
> > >> By looking into git history, it seems the comment isn't related to any
> > >> specific fix but was included already when this class was first
> > >> created.
> > >>
> > >> Would someone be able to point out what is the issue this is
> protecting
> > >> against?
> > >>
> > >> That should allow us to provide an even better patch, although I'll
> > >> apply the safe one for now so to at least have the benefits already
> > >> when wrapping of result-sets is disabled.
> > >>
> > >> thanks,
> > >> Sanne
> > >> ___
> > >> hibernate-dev mailing list
> > >> hibernate-dev@lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release 5.0.6

[Gail Badner]

Please do not push commits to 5.0 branch until after 5.0.6 is released.
Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.0.6.Final Released

[Gail Badner]

http://in.relation.to/2015/12/16/hibernate-orm-506-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Trouble announcing Hibernate ORM 5.0.6.Final

[Gail Badner]

I could not announce on twitter @hibernate_dev or on Google+. Could someone
please add those announcements please?

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

Re: [hibernate-dev] Trouble announcing Hibernate ORM 5.0.6.Final

[Gail Badner]

I had no problem logging onto @hibernate. I saw Vlad's tweet there already,
so didn't explicitly send a tweet from there.

Thanks for mentioning about the version number. I edited the blog to
explicitly state the version number.

On Thu, Dec 17, 2015 at 12:37 AM, Sanne Grinovero 
wrote:

> Thanks for the release Gail!
> I did the Twitter announce; I'll leave the G+ task to someone familiar
> with that.
>
> (BTW we us twitter @Hibernate, not @hibernate-dev for announcements)
> Did you have any issue with doing these?
>
> Regarding the blog: it would be nice to mention which version was released
> ;)
>
> Thanks,
> Sanne
>
> On 17 December 2015 at 06:02, Gail Badner  wrote:
> > I could not announce on twitter @hibernate_dev or on Google+. Could
> someone
> > please add those announcements please?
> >
> > Thanks,
> > Gail
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-5855 bug report and a possible fix

[Gail Badner]

Hi Vlad,

I've spend quite a bit of time on this one and already have a fix. I just
have some tests to add to confirm. I will look into what you suggest, but
please check with me first if you see that an issue is assigned to me.

Thanks,
Gail

On Wed, Dec 23, 2015 at 4:13 AM, Vlad Mihalcea 
wrote:

> Hi guys
>
> I decided to spend some time to investigate the infamous HHH-5855 (
> https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
> report.
>
> One of the first thing that I noticed is that Sets are fine, while this bug
> only replicates with bidirectional Bags.
>
> After some hours of debugging and logging (since debugging triggers
> collection initialization), I found the culprit.
>
> In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
> target, Type[] types, SessionImplementor session, Object owner, Map
> copyCache) method, when copying the cached entity state (which contains the
> newly added child entity along with its identifier) onto the original
> collection:
>
> copied[i] = types[i].replace( original[i], target[i], session, owner,
> copyCache );
>
> inside the org.hibernate.type.CollectionType.replace(Object[] original,
> Object[] target, Type[] types, SessionImplementor session, Object owner,
> Map copyCache)  method there is this check:
>
> if ( !Hibernate.isInitialized( original ) ) {
>return target;
> }
>
>
> For Sets, the collection is always initialized because of this line inside
> the add() method of the org.hibernate.collection.internal.PersistentSet:
>
> final Boolean exists = isOperationQueueEnabled() ?
> readElementExistence( value ) : null;
>
> Because of the the readElementExistence( value ) call the Set is always
> initialized and upon triggering the flush, the newly added Entity being
> already managed it will be left alone.
>
> For PersistentList the aforementioned check is false and the replace never
> occurs, hence the transient entity lingers in the persistence context and
> the flush will trigger another insert, so we get duplicates.
>
> To make the Bag behave like the Set, all we need to do is to change the add
> method like this:
>
> public boolean add(Object object) {
>initialize(false);
>if ( !isOperationQueueEnabled() ) {
>   write();
>   return bag.add( object );
>}
>else {
>   queueOperation( new SimpleAdd( object ) );
>   return true;
>}
> }
>
> but then four tests will fail:
>
> org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
> java.lang.AssertionError at MasterDetailTest.java:1068
>
> org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
> FAILED
> org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364
>
> org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
> java.lang.AssertionError at VersionTest.java:118
>
> org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
> java.lang.AssertionError at VersionTest.java:79
>
> 3 of them fail because we expect the List not to be initialized and
> the UnionSubclassTest  fails
> for a doubtful reason (we attempt to delete an entity which is still
> referenced).
>
> Basically, such a change will finally fix this issue and the Sets and Lists
> will behave consistently. Since you know the reasons behind the difference
> in how Sets and Lists are initialized, we need to discuss if this change is
> appropriate or we should address this issue differently.
>
> I have a branch on my fork with a test that replicates this issue and that
> the proposed change manages to fix it:
>
> https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855
>
> Let me know what you think and let's discuss it further.
>
> Vlad
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-5855 bug report and a possible fix

[Gail Badner]

We really don't want to initialize a List when merging. Instead, we want to
do the same sort of replace on the values stored in the DelayedOperation
objects. That way, the collection will be initialized only when necessary.
The DelayedOperations are executed on flush. I'll should get a pull request
out for this today or tomorrow.

Vlad, If you are interested in digging into an issue that is assigned to
me, I'm happy to tell you my status and share what I know about it. I would
certainly welcome your help.

Thanks,
Gail

On Wed, Dec 23, 2015 at 10:51 AM, Gail Badner  wrote:

> Hi Vlad,
>
> I've spend quite a bit of time on this one and already have a fix. I just
> have some tests to add to confirm. I will look into what you suggest, but
> please check with me first if you see that an issue is assigned to me.
>
> Thanks,
> Gail
>
> On Wed, Dec 23, 2015 at 4:13 AM, Vlad Mihalcea 
> wrote:
>
>> Hi guys
>>
>> I decided to spend some time to investigate the infamous HHH-5855 (
>> https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
>> report.
>>
>> One of the first thing that I noticed is that Sets are fine, while this
>> bug
>> only replicates with bidirectional Bags.
>>
>> After some hours of debugging and logging (since debugging triggers
>> collection initialization), I found the culprit.
>>
>> In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
>> target, Type[] types, SessionImplementor session, Object owner, Map
>> copyCache) method, when copying the cached entity state (which contains
>> the
>> newly added child entity along with its identifier) onto the original
>> collection:
>>
>> copied[i] = types[i].replace( original[i], target[i], session, owner,
>> copyCache );
>>
>> inside the org.hibernate.type.CollectionType.replace(Object[] original,
>> Object[] target, Type[] types, SessionImplementor session, Object owner,
>> Map copyCache)  method there is this check:
>>
>> if ( !Hibernate.isInitialized( original ) ) {
>>return target;
>> }
>>
>>
>> For Sets, the collection is always initialized because of this line inside
>> the add() method of the org.hibernate.collection.internal.PersistentSet:
>>
>> final Boolean exists = isOperationQueueEnabled() ?
>> readElementExistence( value ) : null;
>>
>> Because of the the readElementExistence( value ) call the Set is always
>> initialized and upon triggering the flush, the newly added Entity being
>> already managed it will be left alone.
>>
>> For PersistentList the aforementioned check is false and the replace never
>> occurs, hence the transient entity lingers in the persistence context and
>> the flush will trigger another insert, so we get duplicates.
>>
>> To make the Bag behave like the Set, all we need to do is to change the
>> add
>> method like this:
>>
>> public boolean add(Object object) {
>>initialize(false);
>>if ( !isOperationQueueEnabled() ) {
>>   write();
>>   return bag.add( object );
>>}
>>else {
>>   queueOperation( new SimpleAdd( object ) );
>>   return true;
>>}
>> }
>>
>> but then four tests will fail:
>>
>> org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
>> java.lang.AssertionError at MasterDetailTest.java:1068
>>
>> org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
>> FAILED
>> org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364
>>
>> org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
>> java.lang.AssertionError at VersionTest.java:118
>>
>> org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
>> java.lang.AssertionError at VersionTest.java:79
>>
>> 3 of them fail because we expect the List not to be initialized and
>> the UnionSubclassTest  fails
>> for a doubtful reason (we attempt to delete an entity which is still
>> referenced).
>>
>> Basically, such a change will finally fix this issue and the Sets and
>> Lists
>> will behave consistently. Since you know the reasons behind the difference
>> in how Sets and Lists are initialized, we need to discuss if this change
>> is
>> appropriate or we should address this issue differently.
>>
>> I have a branch on my fork with a test that replicates this issue and that
>> the proposed change manages to fix it:
>>
>> https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855
>>
>> Let me know what you think and let's discuss it further.
>>
>> Vlad
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Oracle12cDialect identity support

[Gail Badner]

Oracle12cDialect was added in 5.0 by HHH-9044. Unfortunately there are
problems with the new identity support that Oracle12cDialect introduced
(HHH-9983). The fix for HHH-9983 involved SPI changes, so it was applied to
master for 5.1 (only).

A couple of weeks ago, Andrea found that identities seemed to work using
5.0 when running BulkManipulationTest using Oracle JDBC 12.1.0.1.0. At the
same time it failed for me in the same way as HHH-9983 using 12.1.0.2.0.
Then Andrea and I switched the JDBC versions (Andrea tried 12.1.0.1.0; I
tried 12.1.0.2.0) and we were both able to run BulkManipulationTest
successfully. This was very strange, especially since we were using the
same Oracle instance, each using a different user. I didn't see any
difference in how we were setting Hibernate properties. Several days later,
I tried Oracle JDBC 12.1.0.2.0 again, but BulkManipulationTest was failing
again in the same way as HHH-9983.

Does anyone know how to get Oracle12cDialect's identity support to work for
5.0 reliably? Is there some version of Oracle JDBC or DB configuration that
is required?

If so, please let me know. The rest of this email assumes it is not
possible. If I'm missing some configuration detail, then just ignore the
rest of this message.

When the unit tests are run using Oracle12cDialect on 5.0, there are many
failures:
* tests with entities explicitly mapped to use an identity fail; these
failures did not happen in 4.3 using Oracle10gDialect because these tests
where skipped (because Oracle10cDialect#supportsIdentityColumns returns
false)
* use @GeneratedValue with default strategy or use hbm mapping for ID
; these failures did not happen in 4.3 because
the native generator for Oracle10gDialect uses a sequence; the native
generator for Oracle12cDialect uses an identity.

Also, starting in 5.0, when using Oracle 12c, StandardDialectResolver will
automatically resolve to Oracle12cDialect if the dialect is not explicitly
mapped. Previously it would have resolved ot Oracle10gDialect.

I would be OK with changing the native generator in 5.0 from sequence to
identity if identities were working properly. I think it will cause
confusion when applications break. To get things working with 5.0,
applications will need to explicitly set the dialect to Oracle10gDialect,
extend Oracle12cDialect to disable identity support, or change ID mappings
to specify sequences.

Here are some alternatives to get things working.

Alternative A:
1) for 5.0 through 5.x override Dialect#getNativeIdentifierGeneratorClass
to return SequenceStyleGenerator.class; I suggest the change for 5.x
because I don't think it would be an acceptable to change the native
generator for Oracle12cDialect from using a sequence to using an identity
in  5.x;
2) for 5.0 only, remove support for identities;
3) for 6.0, if desireable, extend Oracle12gDialect (or whatever is current
at that time) to change the native generator to use an identity.

Alternative B:
1) for 5.0 through 5.x, leave Oracle12cDialect as is, and add a new dialect
with native generator that uses a sequence (i.e.,
Oracle12cNativeSequenceGeneratorDialect or something else that is not so
ugly);
2) for 5.0 through 5.x, change StandardDialectResolver to automatically
resolve to Oracle12cNativeSequenceGeneratorDialect for Oracle 12g server.

Alternative C:
1) for 5.0 through 5.x, change native generator for Oracle12cDialect to use
sequence; leave identity support as is (broken in 5.0; fixed in 5.1);
2) for 5.0 through 5.x, add a new dialect with native generator that uses
an identity (Oracle12cNativeIdentityGeneratorDialect or something else that
is not so ugly).
3) change StandardDialectResolver to automatically resolve to
Oracle12cDialect for Oracle 12g server.

I prefer alternative A. Alternatives B and C involve maintaining 2 dialects
for the same Oracle version; I would think that one of them would be
deprecated moving forward.

Thoughts?

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

Re: [hibernate-dev] Oracle12cDialect identity support

[Gail Badner]

Please see below...

On Sat, Dec 26, 2015 at 8:52 AM, Steve Ebersole  wrote:

> I'd prefer that IDENTITY never be the native generator any time we add a
> new Dialect.
>

+1


>  Native is a Hibernate-only concept and so we can really choose whatever
> we want for native generators.  Also native is an outdated concept,
> replaced by AUTO and SequenceStyleGenerator.  IMO we should never be
> choosing IDENTITY for identifier generation unless a user explicitly asks
> for it.
>

Just to make sure I understand, are you saying we should not be choosing
IDENTITY by default for *new* dialects only?


> So for the first piece, Oracle12cDialect should
> override getNativeIdentifierGeneratorClass to
> return SequenceStyleGenerator.  The Dialect implementation
> of getNativeIdentifierGeneratorClass really assumes databases which support
> IDENTITY but not SEQUENCE.
>

Thanks for clarifying that. I was wondering about that.


> Oracle12cDialect is the first case we have had where a database that
> historically supported SEQUENCES has added support for IDENTITY and we just
> did not account for that properly.  In fact, the "proper" solution would be
> to go into the base Oracle Dialect(s) and override
> getNativeIdentifierGeneratorClass to just always
> return SequenceStyleGenerator.  But doing that in SequenceStyleGenerator
> only is viable too.
>

Did you mean, "doing that in Oracle12cDialect only is viable too"?


>
> As for how to get IDENTITY generation to work consistently with Oracle,
> that I cannot say.  I asked Oscar (the reporter of HHH-9983) for find out
> the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
>  "Via JDBC" is the operative part.  All of the Oracle documentation and
> google hits at that time only discussed using IDENTITY via command told
> (SQLPlus, etc).  According to his findings we seem to have to correct.
>

I believe Oracle12cDialect identity support is working properly in master
now.

IIUC you are saying that the problem is porting that from 5.1 (master) to
> 5.0?  Due to an SPI change?  What exactly is the SPI that changed?  We did
> make lots of changes to "IdentityColumnSupport" (adding that as a
> first-class contract), but that is really just cosmetic grouping of stuff
> already available on Dialect.  So what change specifically stops you from
> porting those changes to 5.0?
>

I've looked over the changes again and I think the main problem is that the
refactoring done for HHH-10084 [1] will break custom dialects that override
the Dialect methods that are deprecated for 5.1. The deprecated Dialect
methods are no longer used; Hibernate obtains the identity support
information from Dialect#getIdentityColumnSupport only.

I've created a test to illustrate: [2].

Custom dialects will need to be modified to override
getIdentityColumnSupport() to work. Would this type of breaking change be
OK for 5.1 (I'm guessing no...). IMO, it is not OK to introduce this
breaking change in 5.0.

HHH-10084 ([1]) changed the deprecated Dialect methods to delegate to the
IdentityColumnSupport. It also extracted the overridden methods from
Dialect subclasses into dialect-specific IdentityColumnSupport classes.

If I backport HHH-9983 to 5.0, I think I would only backport part of
HHH-10084. I would change IdentityColumnSupportImpl methods to delegate to
the deprecated Dialect methods; I would not extract the overridden methods
into dialect-specific IdentityColumnSupport classes. That way, custom
dialects would not be broken.

What do others think about this breaking change in 5.1? If it's not
acceptable, then I propose making the same changes to master (backing out
of the changes where overridden methods are extracted into dialect-specific
IdentityColumnSupport). The extraction would be delayed until the
deprecated methods are removed (in 6.0?).

WDYT?

Thanks,
Gail

[1]
https://github.com/hibernate/hibernate-orm/commit/2731fe541a4b297e399d46357ad9eb5bbe2d2239
[2]
https://github.com/gbadner/hibernate-core/commit/c1510fce39351728a938cd33529cc39c57c2ca84


> On Thu, Dec 24, 2015 at 4:58 AM Emmanuel Bernard 
> wrote:
>
>> I think my preference would be to override in Oracle*Dialect
>> getNativeIdentifierGeneratorClass so that it always returns
>> SequenceStyleGenerator
>>
>> 1. it would be backward compatible with the logic we had for ever (with
>> the exception of 5.0 but I understand that it is not really reliable)
>> 2. I suppose sequences are still the preferred choices for Oracle DB DBAs.
>>
>> Emmanuel
>>
>> > On 24 Dec 2015, at 02:46, Gail Badner  wrote:
>> >
>> > Oracle12cDialect was added in 5.0 by HHH-9044. Unfortunately there are
>> > problems with the new identity support that Oracle12cDialect introdu

Re: [hibernate-dev] Oracle12cDialect identity support

[Gail Badner]

I was mistaken when I said that an IDENTITY ID will be created when using
@GeneratedValue or @GeneratedValue(strategy= GenerationType.AUTO). With
hibernate.id.new_generator_mappings set to true by default in 5.0 and 5.1,
a SequenceStyleGenerator will be used instead.

Currently, the default for "native" ID generator mapped in hbm.xml uses an
IDENTITY if the dialect supports an IDENTITY. This will be overridden in
Oracle12cDialect as we've been discussing.

On Tue, Jan 5, 2016 at 9:46 AM, Steve Ebersole  wrote:

>
>
> On Tue, Jan 5, 2016 at 12:42 AM Gail Badner  wrote:
>
>>
>>
>>>  Native is a Hibernate-only concept and so we can really choose
>>> whatever we want for native generators.  Also native is an outdated
>>> concept, replaced by AUTO and SequenceStyleGenerator.  IMO we should never
>>> be choosing IDENTITY for identifier generation unless a user explicitly
>>> asks for it.
>>>
>>
>> Just to make sure I understand, are you saying we should not be choosing
>> IDENTITY by default for *new* dialects only?
>>
>
> Well in an ideal world where we can time-travel and retroactively apply
> our gained 20/20 hindsight I would change that everywhere.  However we
> don't have that luxury :)  So, yes, I would do that just for new Dialects.
>
> So moving forward, any new Dialect should never chose {"native" ->
> IDENTITY} and should never chose {AUTO -> IDENTITY}.
>
>
>
>>
>>
>>> So for the first piece, Oracle12cDialect should
>>> override getNativeIdentifierGeneratorClass to
>>> return SequenceStyleGenerator.  The Dialect implementation
>>> of getNativeIdentifierGeneratorClass really assumes databases which support
>>> IDENTITY but not SEQUENCE.
>>>
>>
>> Thanks for clarifying that. I was wondering about that.
>>
>>
>>> Oracle12cDialect is the first case we have had where a database that
>>> historically supported SEQUENCES has added support for IDENTITY and we just
>>> did not account for that properly.  In fact, the "proper" solution would be
>>> to go into the base Oracle Dialect(s) and override
>>> getNativeIdentifierGeneratorClass to just always
>>> return SequenceStyleGenerator.  But doing that in SequenceStyleGenerator
>>> only is viable too.
>>>
>>
>> Did you mean, "doing that in Oracle12cDialect only is viable too"?
>>
>
> Yes.  Considering I typed that on my phone I am shocked that was my only
> typo :)
>
>
>>
>>>
>>> As for how to get IDENTITY generation to work consistently with Oracle,
>>> that I cannot say.  I asked Oscar (the reporter of HHH-9983) for find out
>>> the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
>>>  "Via JDBC" is the operative part.  All of the Oracle documentation and
>>> google hits at that time only discussed using IDENTITY via command told
>>> (SQLPlus, etc).  According to his findings we seem to have to correct.
>>>
>>
>> I believe Oracle12cDialect identity support is working properly in master
>> now.
>>
>> IIUC you are saying that the problem is porting that from 5.1 (master) to
>>> 5.0?  Due to an SPI change?  What exactly is the SPI that changed?  We did
>>> make lots of changes to "IdentityColumnSupport" (adding that as a
>>> first-class contract), but that is really just cosmetic grouping of stuff
>>> already available on Dialect.  So what change specifically stops you from
>>> porting those changes to 5.0?
>>>
>>
>> I've looked over the changes again and I think the main problem is that
>> the refactoring done for HHH-10084 [1] will break custom dialects that
>> override the Dialect methods that are deprecated for 5.1. The deprecated
>> Dialect methods are no longer used; Hibernate obtains the identity support
>> information from Dialect#getIdentityColumnSupport only.
>>
>
> Then the deprecated Dialect methods ought to be removed.  Leaving them
> only causes confusion
>
>
>>
>> I've created a test to illustrate: [2].
>>
>> Custom dialects will need to be modified to override
>> getIdentityColumnSupport() to work. Would this type of breaking change be
>> OK for 5.1 (I'm guessing no...). IMO, it is not OK to introduce this
>> breaking change in 5.0.
>>
>
> I am not sure what you are asking when you say "Would this type of
> breaking change be OK for 5.1"
>
>
>
>>
>> HHH-10084 ([1]) changed the deprecated Dialect methods to

Re: [hibernate-dev] HHH-5855 bug report and a possible fix

[Gail Badner]

I've created a pull request for HHH-5855. [1]

I ran into several bugs related to delayed operations, so this is a
work-in-progess. I wanted to create a pull request of what I have so far. I
will revisit it when I return to work 1/14/16. I plan to address the other
bugs separately.

Regards,
Gail

[1] https://github.com/hibernate/hibernate-orm/pull/1212

On Wed, Dec 23, 2015 at 12:05 PM, Vlad Mihalcea 
wrote:

> Hi Gail,
>
> I'm glad there is a development plan on this one . I've been following
> this issue for a couple of years and seen some recent comments which
> reminded me of it.
> Someone asked me on my blog if we can get it fixed, as it's causing
> problems when people are trying to merge back detached entities.
>
> If I can help you with anything, just let me know. Now that I've been also
> digging into it, I can at least assist you and test your PR on my fork too.
>
> Vlad
>
> On Wed, Dec 23, 2015 at 9:25 PM, Gail Badner  wrote:
>
>> We really don't want to initialize a List when merging. Instead, we want
>> to do the same sort of replace on the values stored in the DelayedOperation
>> objects. That way, the collection will be initialized only when necessary.
>> The DelayedOperations are executed on flush. I'll should get a pull request
>> out for this today or tomorrow.
>>
>> Vlad, If you are interested in digging into an issue that is assigned to
>> me, I'm happy to tell you my status and share what I know about it. I would
>> certainly welcome your help.
>>
>> Thanks,
>> Gail
>>
>> On Wed, Dec 23, 2015 at 10:51 AM, Gail Badner  wrote:
>>
>>> Hi Vlad,
>>>
>>> I've spend quite a bit of time on this one and already have a fix. I
>>> just have some tests to add to confirm. I will look into what you suggest,
>>> but please check with me first if you see that an issue is assigned to me.
>>>
>>> Thanks,
>>> Gail
>>>
>>> On Wed, Dec 23, 2015 at 4:13 AM, Vlad Mihalcea 
>>> wrote:
>>>
>>>> Hi guys
>>>>
>>>> I decided to spend some time to investigate the infamous HHH-5855 (
>>>> https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
>>>> report.
>>>>
>>>> One of the first thing that I noticed is that Sets are fine, while this
>>>> bug
>>>> only replicates with bidirectional Bags.
>>>>
>>>> After some hours of debugging and logging (since debugging triggers
>>>> collection initialization), I found the culprit.
>>>>
>>>> In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
>>>> target, Type[] types, SessionImplementor session, Object owner, Map
>>>> copyCache) method, when copying the cached entity state (which contains
>>>> the
>>>> newly added child entity along with its identifier) onto the original
>>>> collection:
>>>>
>>>> copied[i] = types[i].replace( original[i], target[i], session, owner,
>>>> copyCache );
>>>>
>>>> inside the org.hibernate.type.CollectionType.replace(Object[] original,
>>>> Object[] target, Type[] types, SessionImplementor session, Object owner,
>>>> Map copyCache)  method there is this check:
>>>>
>>>> if ( !Hibernate.isInitialized( original ) ) {
>>>>return target;
>>>> }
>>>>
>>>>
>>>> For Sets, the collection is always initialized because of this line
>>>> inside
>>>> the add() method of the org.hibernate.collection.internal.PersistentSet:
>>>>
>>>> final Boolean exists = isOperationQueueEnabled() ?
>>>> readElementExistence( value ) : null;
>>>>
>>>> Because of the the readElementExistence( value ) call the Set is always
>>>> initialized and upon triggering the flush, the newly added Entity being
>>>> already managed it will be left alone.
>>>>
>>>> For PersistentList the aforementioned check is false and the replace
>>>> never
>>>> occurs, hence the transient entity lingers in the persistence context
>>>> and
>>>> the flush will trigger another insert, so we get duplicates.
>>>>
>>>> To make the Bag behave like the Set, all we need to do is to change the
>>>> add
>>>> method like this:
>>>>
>>>> public boolean add(Object object) {
>>>>initialize(false);
>>>>if ( !isOperationQueueEnab

Re: [hibernate-dev] Oracle12cDialect identity support

[Gail Badner]

Just to bring everyone up-to-date, the following were fixed in Hibernate
ORM 5.0.7:
* HHH-10421: "native" ID generator for Oracle12cDialect changed to
SequenceStyleGenerator; this change make the "native" ID generator for
Oracle12cDialect consistent with earlier Oracle dialects;
* HHH-10422: fix identity IDs using Oracle12cDialect.

HHH-10421 includes deprecation of the following dialect methods in 5.0:
supportsIdentityColumns()
supportsInsertSelectIdentity()
hasDataTypeInIdentityColumn()
appendIdentitySelectToInsert(String insertString)
getIdentitySelectString(String table, String column, int type)
getIdentityColumnString(int type)
getIdentityInsertString()

These method are removed from master.

On Tue, Jan 5, 2016 at 6:52 PM, Gail Badner  wrote:

> I was mistaken when I said that an IDENTITY ID will be created when using
> @GeneratedValue or @GeneratedValue(strategy= GenerationType.AUTO). With
> hibernate.id.new_generator_mappings set to true by default in 5.0 and 5.1,
> a SequenceStyleGenerator will be used instead.
>
> Currently, the default for "native" ID generator mapped in hbm.xml uses an
> IDENTITY if the dialect supports an IDENTITY. This will be overridden in
> Oracle12cDialect as we've been discussing.
>
> On Tue, Jan 5, 2016 at 9:46 AM, Steve Ebersole 
> wrote:
>
>>
>>
>> On Tue, Jan 5, 2016 at 12:42 AM Gail Badner  wrote:
>>
>>>
>>>
>>>>  Native is a Hibernate-only concept and so we can really choose
>>>> whatever we want for native generators.  Also native is an outdated
>>>> concept, replaced by AUTO and SequenceStyleGenerator.  IMO we should never
>>>> be choosing IDENTITY for identifier generation unless a user explicitly
>>>> asks for it.
>>>>
>>>
>>> Just to make sure I understand, are you saying we should not be choosing
>>> IDENTITY by default for *new* dialects only?
>>>
>>
>> Well in an ideal world where we can time-travel and retroactively apply
>> our gained 20/20 hindsight I would change that everywhere.  However we
>> don't have that luxury :)  So, yes, I would do that just for new Dialects.
>>
>> So moving forward, any new Dialect should never chose {"native" ->
>> IDENTITY} and should never chose {AUTO -> IDENTITY}.
>>
>>
>>
>>>
>>>
>>>> So for the first piece, Oracle12cDialect should
>>>> override getNativeIdentifierGeneratorClass to
>>>> return SequenceStyleGenerator.  The Dialect implementation
>>>> of getNativeIdentifierGeneratorClass really assumes databases which support
>>>> IDENTITY but not SEQUENCE.
>>>>
>>>
>>> Thanks for clarifying that. I was wondering about that.
>>>
>>>
>>>> Oracle12cDialect is the first case we have had where a database that
>>>> historically supported SEQUENCES has added support for IDENTITY and we just
>>>> did not account for that properly.  In fact, the "proper" solution would be
>>>> to go into the base Oracle Dialect(s) and override
>>>> getNativeIdentifierGeneratorClass to just always
>>>> return SequenceStyleGenerator.  But doing that in SequenceStyleGenerator
>>>> only is viable too.
>>>>
>>>
>>> Did you mean, "doing that in Oracle12cDialect only is viable too"?
>>>
>>
>> Yes.  Considering I typed that on my phone I am shocked that was my only
>> typo :)
>>
>>
>>>
>>>>
>>>> As for how to get IDENTITY generation to work consistently with Oracle,
>>>> that I cannot say.  I asked Oscar (the reporter of HHH-9983) for find out
>>>> the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
>>>>  "Via JDBC" is the operative part.  All of the Oracle documentation and
>>>> google hits at that time only discussed using IDENTITY via command told
>>>> (SQLPlus, etc).  According to his findings we seem to have to correct.
>>>>
>>>
>>> I believe Oracle12cDialect identity support is working properly in
>>> master now.
>>>
>>> IIUC you are saying that the problem is porting that from 5.1 (master)
>>>> to 5.0?  Due to an SPI change?  What exactly is the SPI that changed?  We
>>>> did make lots of changes to "IdentityColumnSupport" (adding that as a
>>>> first-class contract), but that is really just cosmetic grouping of stuff
>>>> already available on Dialect.  So what change specifically stops you from
>>>> porting tho

[hibernate-dev] hbm mapping files and EntityManager

[Gail Badner]

By default, hbm mapping files are detected when building Hibernate
EntityManager.

Is that expected?

I see that it is possible to override this behavior by setting
hibernate.archive.autodetection="".

I was surprised by the default. I would have thought that an application
using EntityManager would need to explicitly opt-in to use hbm files.

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

Re: [hibernate-dev] hbm mapping files and EntityManager

[Gail Badner]

I see what happened. In 4.2, when exclude-unlisted-classes is true, hbm
files are not detected. [1]

This got broken in 4.3 and is still broken in 5.0. [2]

I've created HHH-10461 to fix this.

[1]
https://github.com/hibernate/hibernate-orm/blob/4.2/hibernate-entitymanager/src/main/java/org/hibernate/ejb/Ejb3Configuration.java#L829
[2]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/boot/archive/scan/internal/StandardScanOptions.java#L23

On Tue, Jan 19, 2016 at 7:18 AM, Steve Ebersole  wrote:

> I am fairly certain this what Hibernate has always done.
>
> On Mon, Jan 18, 2016 at 8:44 PM Gail Badner  wrote:
>
>> By default, hbm mapping files are detected when building Hibernate
>> EntityManager.
>>
>> Is that expected?
>>
>> I see that it is possible to override this behavior by setting
>> hibernate.archive.autodetection="".
>>
>> I was surprised by the default. I would have thought that an application
>> using EntityManager would need to explicitly opt-in to use hbm files.
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Statements issued for unidirectional one-to-many with @JoinColumn

[Gail Badner]

Hi Gunnar,

Can you try using this pull request for HHH-9979 [1] to see if the extra
updates go away?

This pull request is already closed because I am going to use new
OperationContext functionality to fix HHH-9979. I know this pull request
does get rid of some updates, and the future one will as well.

Thanks,
Gail

[1] https://github.com/hibernate/hibernate-orm/pull/1067


On Thu, Jan 21, 2016 at 3:25 AM, Gunnar Morling 
wrote:

> Steve, all,
>
> I have a model with two entities, Parent and Child, and an
> unidirectional one-to-many association from the former to the latter.
>
> Via @JoinColumn on the association it is ensured that the Parent FK is
> stored in the Child table, i.e. without a separate join table. When
> inserting a Parent and several Child entities, I see the following
> statements:
>
> INSERT INTO parent (id, name) VALUES (?,?)
>
> INSERT INTO child (id, childname) VALUES (?,?)
> INSERT INTO child (id, childname) values (?,?)
>
> UPDATE CHILD SET Parent_id=? WHERE id=?
> UPDATE CHILD SET Parent_id=? WHERE id=?
>
> Why is it that the FK is propagated through separate updates instead
> of doing it as part of the Child insert?
>
> Thanks,
>
> --Gunnar
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Statements issued for unidirectional one-to-many with @JoinColumn

[Gail Badner]

Actually, that pull request will only affect merging transient entities.
Are you seeing the extra updates when merging?

On Thu, Jan 21, 2016 at 1:09 PM, Gail Badner  wrote:

> Hi Gunnar,
>
> Can you try using this pull request for HHH-9979 [1] to see if the extra
> updates go away?
>
> This pull request is already closed because I am going to use new
> OperationContext functionality to fix HHH-9979. I know this pull request
> does get rid of some updates, and the future one will as well.
>
> Thanks,
> Gail
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1067
>
>
> On Thu, Jan 21, 2016 at 3:25 AM, Gunnar Morling 
> wrote:
>
>> Steve, all,
>>
>> I have a model with two entities, Parent and Child, and an
>> unidirectional one-to-many association from the former to the latter.
>>
>> Via @JoinColumn on the association it is ensured that the Parent FK is
>> stored in the Child table, i.e. without a separate join table. When
>> inserting a Parent and several Child entities, I see the following
>> statements:
>>
>> INSERT INTO parent (id, name) VALUES (?,?)
>>
>> INSERT INTO child (id, childname) VALUES (?,?)
>> INSERT INTO child (id, childname) values (?,?)
>>
>> UPDATE CHILD SET Parent_id=? WHERE id=?
>> UPDATE CHILD SET Parent_id=? WHERE id=?
>>
>> Why is it that the FK is propagated through separate updates instead
>> of doing it as part of the Child insert?
>>
>> Thanks,
>>
>> --Gunnar
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] User guide test failure

[Gail Badner]

Hi,

I just pulled and ran tests. I'm seeing the following test failing:

org.hibernate.userguide.hql.HQLTest > test_hql_between_predicate_example_2
FAILED
java.lang.AssertionError at HQLTest.java:1897

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

Re: [hibernate-dev] User guide test failure

[Gail Badner]

Hi Vlad,

It works now.

Thanks!
Gail

On Fri, Feb 5, 2016 at 2:36 AM, Vlad Mihalcea 
wrote:

> Hi,
>
> I committed a fix. The issue was due to time zones, so the result set
> varies between 1 and 2 because the entities were added with a LocalDateTime.
> I'll check it on Jenkins too. Let me know if it works now.
>
> Vlad
>
> On Fri, Feb 5, 2016 at 11:44 AM, Gail Badner  wrote:
>
>> Hi,
>>
>> I just pulled and ran tests. I'm seeing the following test failing:
>>
>> org.hibernate.userguide.hql.HQLTest > test_hql_between_predicate_example_2
>> FAILED
>> java.lang.AssertionError at HQLTest.java:1897
>>
>> Regards,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-10478 : OperationContext

[Gail Badner]

I've created a gist with an overview of the design:
https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a new
section tomorrow about possible shortcomings.

Here is my POC:
https://github.com/hibernate/hibernate-orm/compare/master...gbadner:HHH-10478-OperationContext
. Although no tests fail, the approach may be too simple to model what is
necessary.

At this point the POC is squashed down to 1 commit:
https://github.com/hibernate/hibernate-orm/commit/3d0e2378cb998788b3205afb1e15c443c5ba77e8

Have a look and feel free to comment.

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

Re: [hibernate-dev] HHH-10478 : OperationContext

[Gail Badner]

The POC [1] assumes that we only need a single OperationContext for each
type of operation. OperationContextManager has a Map of OperationContext by
OperationContextType. Each OperationContext object is lazily created on the
first occurence of the corresponding type of operation.

Currently, when an operation is initiated (e.g., by Session.merge( entity
)), OperationContextManager [2] does the following:
- calls ManageableOperationContext#beforeOperation, which puts the
OperationContext "in progress";
- executes the operation, which performs cascades according to mappings;
- calls ManageableOperationContext#afterOperation, which puts the
OperationContext in an invalid state that is "not in progress".

When an operation cascades to other entities, the same OperationContext is
used.

Obviously, OperationContextManager needs to know if an operation is
"top-level" (meaning that the operation is on the original entity, and not
cascaded). In the POC, if the relevant OperationContext is not in progress
at the time that an opeation is initiated, then OperationContextManager
assumes that the operation is top-level. If the OperationContext is "in
progress", then OperationContextManager assumes that this is a cascaded
operation.

I am not sure this is always correct. Can anyone think of a case where this
could break down?

In the POC, the following EventSource methods that contain an argument for
the operation cache has been deprecated and is no longer used because the
contents of that argument has been moved into an OperationContext:

public void merge(String entityName, Object object, Map copiedAlready)
public void persist(String entityName, Object object, Map createdAlready)
public void persistOnFlush(String entityName, Object object, Map
copiedAlready)
public void refresh(String entityName, Object object, Map refreshedAlready)
public void delete(String entityName, Object child, boolean
isCascadeDeleteEnabled, Set transientEntities)

Before the POC, it was the above methods that indicated that it was not
top-level. If it turns out that having a single OperationContext is not
valid, then there needs to be some other way to determine if the operation
was top-level.

I had originally planned to use PersistenceContext#getCascadeLevel == 0 to
indicate an operation was at the top-level, but I found that won't work for
some operations. For example, the cascade level for a top-level delete can
be > 1 when deleting orphans due to merge or save-or-update operations.
Another example is that cascade level is not 0 on top-level save-or-update
while flushing.

I have some ideas to work around this, but I didn't want to get too far
down that path if it wasn't an issue.

Thanks,
Gail

[1]
https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java
[2]
https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java#L132


On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner  wrote:

> I've created a gist with an overview of the design:
> https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a new
> section tomorrow about possible shortcomings.
>
> Here is my POC:
> https://github.com/hibernate/hibernate-orm/compare/master...gbadner:HHH-10478-OperationContext
> . Although no tests fail, the approach may be too simple to model what is
> necessary.
>
> At this point the POC is squashed down to 1 commit:
> https://github.com/hibernate/hibernate-orm/commit/3d0e2378cb998788b3205afb1e15c443c5ba77e8
>
> Have a look and feel free to comment.
>
> Thanks,
> Gail
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-10500 and multiple associations using the same foreign key column

[Gail Badner]

For joined inheritance, such as:

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@Table(name = "task_base")
public class TaskBase { ... }

@Entity
@Table(name = "task")
public class Task extends TaskBase { ... }

Does JPA allow mapping a one-to-many association with the foreign key
column in a superclass table (task_base)? For example:

@Entity
public class Goal {
...
@OneToMany(targetEntity = TaskBase.class)
@JoinColumn(name = "goal_id", table = "task_base")
private Set tasks = new HashSet();
...
}

Currently, Hibernate throws: org.hibernate.cfg.NotYetImplementedException:
Collections having FK in secondary table.

As you can see. the foreign key is actually in the superclass table.

JPA 2.1 spec says this for the description of @JoinColumn( name="..." )
when used for a unidirectional one-to-many association:

"If the join is for a unidirectional OneToMany mapping using a foreign key
mapping strategy, the foreign key is in the table of the target entity."

Is "the table of the target entity" just a default that can be overridden
by the "table" attribute? If so, then this is a bug in Hibernate.

Another question, does JPA allow multiple associations to use the same
foreign key column? For example:

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@Table(name = "task_base")
public class TaskBase { ... }

@Entity
@Table(name = "task")
public class Task extends TaskBase { ... }

@Entity
@Table(name = "othertask")
public class OtherTask extends TaskBase { ... }

@Entity
public class Goal {
...
@OneToMany
@JoinColumn(name = "goal_id", table = "task_base")
private Set tasks = new HashSet();

@OneToMany
@JoinColumn(name = "goal_id", table = "task_base")
private Set otherTasks = new HashSet();
...
}

The above also fails with NotYetImplementedException for the same reason.

I've created a pull request with this test case. [1]

When I switched to use single table inheritance, there was no failure, but
when Goal.tasks is loaded, it contained both Task and OtherTask objects.

Is this an invalid use case or a Hibernate bug?

Thanks,
Gail

[1] https://github.com/hibernate/hibernate-orm/pull/1265
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-10500 and multiple associations using the same foreign key column

[Gail Badner]

Someone has been doing the following so that multiple associations with
entities within a joined inheritance hierarchy  share the same foreign key:
1) each association that shares the same foreign key uses @OneToMany(
targetEntity= ) so that the FK is in the superclass;
2) each association uses a filter to only include entities with a
particular discriminator value.

The SQL for loading each of these associations involves an outer join to
each subclass table, then the filter restricts to the particular entity
class of interest for the particular association.

I'm trying to figure out if there is a JPA-supported way that would not
involving outer joining all the subclass tables (e.g., using the
parameterized type of the collection as default for targetEntity along with
@JoinColumn(table="superclass_table") ).

Thanks,
Gail

On Tue, Feb 16, 2016 at 10:48 AM, Emmanuel Bernard 
wrote:

> There is a case about association shared in a inheritance case that I
> don't fully recollect.  I was against supporting as it did break OO when
> you thought about it - at least when I thought about it.
> But this case seems to be different. Does someone explicitly asks for that
> use case ?
>
> > On 13 févr. 2016, at 22:56, Gail Badner  wrote:
> >
> > For joined inheritance, such as:
> >
> > @Entity
> > @Inheritance(strategy = InheritanceType.JOINED)
> > @Table(name = "task_base")
> > public class TaskBase { ... }
> >
> > @Entity
> > @Table(name = "task")
> > public class Task extends TaskBase { ... }
> >
> > Does JPA allow mapping a one-to-many association with the foreign key
> > column in a superclass table (task_base)? For example:
> >
> > @Entity
> > public class Goal {
> >...
> >@OneToMany(targetEntity = TaskBase.class)
> >@JoinColumn(name = "goal_id", table = "task_base")
> >private Set tasks = new HashSet();
> >...
> > }
> >
> > Currently, Hibernate throws:
> org.hibernate.cfg.NotYetImplementedException:
> > Collections having FK in secondary table.
> >
> > As you can see. the foreign key is actually in the superclass table.
> >
> > JPA 2.1 spec says this for the description of @JoinColumn( name="..." )
> > when used for a unidirectional one-to-many association:
> >
> > "If the join is for a unidirectional OneToMany mapping using a foreign
> key
> > mapping strategy, the foreign key is in the table of the target entity."
> >
> > Is "the table of the target entity" just a default that can be overridden
> > by the "table" attribute? If so, then this is a bug in Hibernate.
> >
> > Another question, does JPA allow multiple associations to use the same
> > foreign key column? For example:
> >
> > @Entity
> > @Inheritance(strategy = InheritanceType.JOINED)
> > @Table(name = "task_base")
> > public class TaskBase { ... }
> >
> > @Entity
> > @Table(name = "task")
> > public class Task extends TaskBase { ... }
> >
> > @Entity
> > @Table(name = "othertask")
> > public class OtherTask extends TaskBase { ... }
> >
> > @Entity
> > public class Goal {
> >...
> >@OneToMany
> >@JoinColumn(name = "goal_id", table = "task_base")
> >private Set tasks = new HashSet();
> >
> >@OneToMany
> >@JoinColumn(name = "goal_id", table = "task_base")
> >private Set otherTasks = new HashSet();
> >...
> > }
> >
> > The above also fails with NotYetImplementedException for the same reason.
> >
> > I've created a pull request with this test case. [1]
> >
> > When I switched to use single table inheritance, there was no failure,
> but
> > when Goal.tasks is loaded, it contained both Task and OtherTask objects.
> >
> > Is this an invalid use case or a Hibernate bug?
> >
> > Thanks,
> > Gail
> >
> > [1] https://github.com/hibernate/hibernate-orm/pull/1265
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Unresolved issues for 5.0.8

[Gail Badner]

Hi,

I'd like to release 5.0.8.Final as soon as tomorrow.

I see the following unresolved issues scheduled for 5.0.8:
https://hibernate.atlassian.net/browse/HHH-10250
https://hibernate.atlassian.net/browse/HHH-9485

Would there be any problem if I moved those 2 to 5.0.9?

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

[hibernate-dev] Preparing to release Hibernate 5.0.8.Final

[Gail Badner]

I'm starting the release process. Please do not push any commits to 5.0
branch until 5.0.8.Final is released.

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

[hibernate-dev] Problem with symlink handling for documentation tasks (HHH-10512)

[Gail Badner]

I just uploaded the docs from release directory using `../gradlew
uploadDocumentation`.

The docs ended up being uploaded to https://docs.jboss.org/hibernate/5.0/,
instead of https://docs.jboss.org/hibernate/orm/5.0/.

Can someone help me get this uploaded to the proper location with the
correct symlinks? I'm confused about what was intended by HHH-10512.

After tagging and changing the version to 5.0.9-SNAPSHOT, I'll create a
Jira issue to fix this for 5.0.9. I'll check to see if it's similarly
broken in master.

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