From steve at hibernate.org  Sun Aug  2 14:48:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 02 Aug 2015 18:48:33 +0000
Subject: [hibernate-dev] Minor SPI *addition*
Message-ID: <CAFdSV9t=boviVX6yJW+D4eF3BF5pTkUhfu2=TCVYFxOXOR-yKg@mail.gmail.com>

I don't think this should require a new CR as it is an *addition* to an
SPI, but wanted to run it past everyone and get y'alls thoughts.  I ran
across the need for this while re-working the documentation.

Basically I needed a (easy) way to allow users to override the implicit
resolution for a built-in basic type.  So I added the following method to
MetadataBuilder:

applyBasicType(BasicType type, String... keys)

specifically passing in some keys, intending to allow overriding the keys
defined by BasicType.  To that end I did have to make one additional change
to add a new type, BasicTypeRegistration, to act as a tuple for the
BasicType+keys and MetadataBuildingOptions#getBasicTypeRegistrations to
return this type rather than "just" returning BasicType.

The specific use-case was to allow users to easy remap how UUID attributes
are handled (store as CHAR rather than BINARY).  But really it is useful
for altering any implicit attribute type mapping.

From sanne at hibernate.org  Mon Aug  3 05:49:56 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Aug 2015 10:49:56 +0100
Subject: [hibernate-dev] Hibernate Search branching and an update to 5.4.0.x
	work
Message-ID: <CAFm4XO3PsCxUWuuPiymKCsaYXsf1qk_dsYcdmNzk0q+KZ0xh0g@mail.gmail.com>

The Lucene 5 related work - which is now almost ready - is not meant
to be included in the 5.4 release, but we postponed the release of
5.4.0.Final a bit as we're waiting for a .Final of Hibernate ORM 5.

However there are a couple other pull requests which are open and
suited to be merged now, so we'll create a 5.4 branch as soon as those
are merged too, to then continue with the Lucene 5 work on master
(which will be called 5.5.0-SNAPSHOT).

Essentially we'll create the 5.4 maintenance branch and start working
on 5.5 before releasing 5.4.0.Final; also since we had quite some
improvements merged after 5.4.0.CR1, I think we could do a CR2 after
merging those last PRs.

Thanks,
Sanne

From steve at hibernate.org  Mon Aug  3 11:30:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 03 Aug 2015 15:30:59 +0000
Subject: [hibernate-dev] Embedded Composite Identifiers
Message-ID: <CAFdSV9ubYLq2XLQJaT8d6RZDmBnKcr4e6f_rf7cV61R-2Ai=jw@mail.gmail.com>

I am thinking we should start to soft-deprecate[1] the historical feature
of embedded composite identifiers.  This is the feature that allowed an
entity to define a composite identifier without any kind of "pk class"
(EmbeddedId/IdClass):

@Entity
public class MyEntity {
    @Id
    public Integer key1;
    @Id
    public Integer key2;
   ...
}

The you'd always have to instantiate the entity to deal with its
identifier.  For example, to load such an entity:

MyEntity id = new MyEntity(1,2);
MyEntity it = session.get( MyEntity.class, id );

 Between EmbeddedId and IdClass there are better alternatives to document.

Thoughts?

[1] - By "soft-deprecate" I mean remove discussion of it from the
documentation, and don't really push it.

From steve at hibernate.org  Mon Aug  3 11:36:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 03 Aug 2015 15:36:30 +0000
Subject: [hibernate-dev] Embedded Composite Identifiers
In-Reply-To: <CAFdSV9ubYLq2XLQJaT8d6RZDmBnKcr4e6f_rf7cV61R-2Ai=jw@mail.gmail.com>
References: <CAFdSV9ubYLq2XLQJaT8d6RZDmBnKcr4e6f_rf7cV61R-2Ai=jw@mail.gmail.com>
Message-ID: <CAFdSV9v5Jtrhjp+SGKoVvaS7O9A=0BM0wO2viE7k3vkzQTgE9Q@mail.gmail.com>

Here is what I proposes in the documentation in the section discussing
composite identifiers:


<note>
    <para>
        Technically a composite identifier can be made up of just a
single persistent attribute.
    </para>
    <para>
        The restriction that a composite identifier has to be
represented by a "primary key class" is
        a JPA restriction.  Hibernate does allow composite identifiers
to be defined without a
        "primary key class", but use of that modeling technique is
deprecated and not discussed here.
    </para>
</note>




On Mon, Aug 3, 2015 at 10:30 AM Steve Ebersole <steve at hibernate.org> wrote:

> I am thinking we should start to soft-deprecate[1] the historical feature
> of embedded composite identifiers.  This is the feature that allowed an
> entity to define a composite identifier without any kind of "pk class"
> (EmbeddedId/IdClass):
>
> @Entity
> public class MyEntity {
>     @Id
>     public Integer key1;
>     @Id
>     public Integer key2;
>    ...
> }
>
> The you'd always have to instantiate the entity to deal with its
> identifier.  For example, to load such an entity:
>
> MyEntity id = new MyEntity(1,2);
> MyEntity it = session.get( MyEntity.class, id );
>
>  Between EmbeddedId and IdClass there are better alternatives to document.
>
> Thoughts?
>
> [1] - By "soft-deprecate" I mean remove discussion of it from the
> documentation, and don't really push it.
>

From sanne at hibernate.org  Mon Aug  3 11:46:48 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Aug 2015 16:46:48 +0100
Subject: [hibernate-dev] Embedded Composite Identifiers
In-Reply-To: <CAFdSV9v5Jtrhjp+SGKoVvaS7O9A=0BM0wO2viE7k3vkzQTgE9Q@mail.gmail.com>
References: <CAFdSV9ubYLq2XLQJaT8d6RZDmBnKcr4e6f_rf7cV61R-2Ai=jw@mail.gmail.com>
	<CAFdSV9v5Jtrhjp+SGKoVvaS7O9A=0BM0wO2viE7k3vkzQTgE9Q@mail.gmail.com>
Message-ID: <CAFm4XO2Lr4ci+1i+iF_LEbauv+uYdPMciFeVWiWw8f62zaLFPw@mail.gmail.com>

I remember loving this feature.
Composite keys are very common in databases I worked with, while
loading by ids seems to be quite uncommon in my coding style as I
don't remember knowing how to do that, nor that this ignorance ever
bothered me :)

+1 anyway, that's just to give some perspective.

On 3 August 2015 at 16:36, Steve Ebersole <steve at hibernate.org> wrote:
> Here is what I proposes in the documentation in the section discussing
> composite identifiers:
>
>
> <note>
>     <para>
>         Technically a composite identifier can be made up of just a
> single persistent attribute.
>     </para>
>     <para>
>         The restriction that a composite identifier has to be
> represented by a "primary key class" is
>         a JPA restriction.  Hibernate does allow composite identifiers
> to be defined without a
>         "primary key class", but use of that modeling technique is
> deprecated and not discussed here.
>     </para>
> </note>
>
>
>
>
> On Mon, Aug 3, 2015 at 10:30 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> I am thinking we should start to soft-deprecate[1] the historical feature
>> of embedded composite identifiers.  This is the feature that allowed an
>> entity to define a composite identifier without any kind of "pk class"
>> (EmbeddedId/IdClass):
>>
>> @Entity
>> public class MyEntity {
>>     @Id
>>     public Integer key1;
>>     @Id
>>     public Integer key2;
>>    ...
>> }
>>
>> The you'd always have to instantiate the entity to deal with its
>> identifier.  For example, to load such an entity:
>>
>> MyEntity id = new MyEntity(1,2);
>> MyEntity it = session.get( MyEntity.class, id );
>>
>>  Between EmbeddedId and IdClass there are better alternatives to document.
>>
>> Thoughts?
>>
>> [1] - By "soft-deprecate" I mean remove discussion of it from the
>> documentation, and don't really push it.
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Aug  3 14:17:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 03 Aug 2015 18:17:50 +0000
Subject: [hibernate-dev] 5.0 defaults
Message-ID: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>

Scott has been asking about making some setting defaults consistent between
Hibernate and WildFly.  Most I think WildFly should just use the ORM
defaults.  But 3 in particular I thought we should all discuss and decide
on..

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?

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?

3) hibernate.id.new_generator_mappings - by default we currently still map
to the old identifier generators.  I personally also think it is time to
change this default.  There are some risks here though.

Take an example... Legacy JPA users would have gotten
MultipleHiLoPerTableGenerator
when they used table-generation.  The new mapping for table-generation
would be to use org.hibernate.id.enhanced.TableGenerator.  In theory the
enhanced TableGenerator could be made to mimic the same "hi lo" based
values using the correct optimizer (in *theory* because I have not tried
it).  If selecting the proper optimizer works this one might not be a
problem and there is no need for data migration.  But if it does not, we
really have no migration path for user to migrate data.

Another "difficulty" is that AUTO is mapped *very* differently.  AUTO used
to map to the idea of a "native" generator which would choose between
IDENTITY, SEQUENCE, etc.  The new mapping is to use the enhanced
SequenceStyleGenerator.  For dialects where the old mapping picked
IDENTITY, this is a very difficult migration point.  Granted they could
change all the needed id mappings to specify identity...

And of course we could also just say "this is a (painful) migration point"
and document the known migration issues for existing apps in the migration
guide.

From smarlow at redhat.com  Mon Aug  3 15:07:18 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 3 Aug 2015 15:07:18 -0400
Subject: [hibernate-dev] 5.0 defaults
In-Reply-To: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>
References: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>
Message-ID: <55BFBBE6.4020903@redhat.com>



On 08/03/2015 02:17 PM, Steve Ebersole wrote:
> Scott has been asking about making some setting defaults consistent between
> Hibernate and WildFly.  Most I think WildFly should just use the ORM
 > defaults.

If ORM 5.0 used the same defaults as the WildFly (JPA) deployer, then 
WildFly could stop setting them.

> But 3 in particular I thought we should all discuss and decide
> on..
>
> 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?

 From a few weeks ago on 
https://www.mail-archive.com/hibernate-dev at lists.jboss.org/msg12650.html:

"
Question: Should 
hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl 
be the default for Hibernate 5?

Answer:

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

Is the ORM default exactly the same as pre-5?  If not, is there a jira 
that explains the difference?

>
> 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?
>
> 3) hibernate.id.new_generator_mappings - by default we currently still map
> to the old identifier generators.  I personally also think it is time to
> change this default.  There are some risks here though.

WildFly has been defaulting hibernate.id.new_generator_mappings=true for 
the past four years but I don't think that makes this proposed change 
any easier for applications that aren't using WildFly EE (JPA) based 
deployments.

>
> Take an example... Legacy JPA users would have gotten
> MultipleHiLoPerTableGenerator
> when they used table-generation.  The new mapping for table-generation
> would be to use org.hibernate.id.enhanced.TableGenerator.  In theory the
> enhanced TableGenerator could be made to mimic the same "hi lo" based
> values using the correct optimizer (in *theory* because I have not tried
> it).  If selecting the proper optimizer works this one might not be a
> problem and there is no need for data migration.  But if it does not, we
> really have no migration path for user to migrate data.
>
> Another "difficulty" is that AUTO is mapped *very* differently.  AUTO used
> to map to the idea of a "native" generator which would choose between
> IDENTITY, SEQUENCE, etc.  The new mapping is to use the enhanced
> SequenceStyleGenerator.  For dialects where the old mapping picked
> IDENTITY, this is a very difficult migration point.  Granted they could
> change all the needed id mappings to specify identity...
>
> And of course we could also just say "this is a (painful) migration point"
> and document the known migration issues for existing apps in the migration
> guide.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Aug  3 16:00:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 03 Aug 2015 20:00:30 +0000
Subject: [hibernate-dev] 5.0 defaults
In-Reply-To: <55BFBBE6.4020903@redhat.com>
References: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>
	<55BFBBE6.4020903@redhat.com>
Message-ID: <CAFdSV9vaUjGSLquuEC9+8a0jjkAXPmvyEp7C98aetLKLQdE4fA@mail.gmail.com>

On Mon, Aug 3, 2015 at 2:07 PM Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 08/03/2015 02:17 PM, Steve Ebersole wrote:
> > Scott has been asking about making some setting defaults consistent
> between
> > Hibernate and WildFly.  Most I think WildFly should just use the ORM
>  > defaults.
>
> If ORM 5.0 used the same defaults as the WildFly (JPA) deployer, then
> WildFly could stop setting them.
>

This is such a non-argument.  We could of course say the inverse:

If WildFly used the same defaults as ORM then (obviously) WildFly could
stop setting them.  Not to mention Hibernate users would get a more
consistent experience across environments.

From smarlow at redhat.com  Mon Aug  3 16:22:30 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 3 Aug 2015 16:22:30 -0400
Subject: [hibernate-dev] 5.0 defaults
In-Reply-To: <CAFdSV9vaUjGSLquuEC9+8a0jjkAXPmvyEp7C98aetLKLQdE4fA@mail.gmail.com>
References: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>
	<55BFBBE6.4020903@redhat.com>
	<CAFdSV9vaUjGSLquuEC9+8a0jjkAXPmvyEp7C98aetLKLQdE4fA@mail.gmail.com>
Message-ID: <55BFCD86.8020006@redhat.com>



On 08/03/2015 04:00 PM, Steve Ebersole wrote:
> On Mon, Aug 3, 2015 at 2:07 PM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>
>
>     On 08/03/2015 02:17 PM, Steve Ebersole wrote:
>      > Scott has been asking about making some setting defaults
>     consistent between
>      > Hibernate and WildFly.  Most I think WildFly should just use the ORM
>       > defaults.
>
>     If ORM 5.0 used the same defaults as the WildFly (JPA) deployer, then
>     WildFly could stop setting them.
>
>
> This is such a non-argument. We could of course say the inverse:
>
> If WildFly used the same defaults as ORM then (obviously) WildFly could
> stop setting them.  Not to mention Hibernate users would get a more
> consistent experience across environments.

True.  Stating both sides, gives a little more information to others 
that are reading this discussion.  Your point being that changing either 
ORM or WildFly to use the others defaults, brings more consistency 
across environments.

From sanne at hibernate.org  Mon Aug  3 17:04:26 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Aug 2015 22:04:26 +0100
Subject: [hibernate-dev] New PostgreSQL users available on ci.hibernate.org
Message-ID: <CAFm4XO0UEt0o9JacM+9UH1G7Brm=iNhrFwS0jwFL27GYf+8VZQ@mail.gmail.com>

The postgres users as defined in Hibernate ORM's matrix configuration
are now setup on each slave for ci.hibernate.org.
  - https://github.com/hibernate/hibernate-orm/blob/master/databases/pgsql/resources/hibernate.properties

They have SUPERUSER privileges, so they can create/drop new databases
and do anything else these might need.

For restricted usage - like any testsuite which doesn't need such
privileges - we're keeping the previously defined users too.

https://github.com/hibernate/ci.hibernate.org/commit/2a4926bbd4dabf1767bfdac945d89bf606ba8614

Sanne

From sanne at hibernate.org  Mon Aug  3 17:29:56 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 3 Aug 2015 22:29:56 +0100
Subject: [hibernate-dev] [CI] Shutting down CouchDB
Message-ID: <CAFm4XO1=e6WJdOKp6qrckOP-ceKV4WMjWEOpK3WERxFKNmbauA@mail.gmail.com>

I've stopped and disabled CouchDB on each slave node as it looks like
it's conflicting with Byteman ports and making many testsuites fail.

We'll need to reconfigure it before enabling again:
 https://hibernate.atlassian.net/browse/WEBSITE-387

Sorry for the failure notices! If they are Byteman related, please
have the job run again.

Sanne

From steve at hibernate.org  Mon Aug  3 19:55:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 03 Aug 2015 23:55:03 +0000
Subject: [hibernate-dev] ORM Documentation
In-Reply-To: <D37C8ED8-FFAE-4DFC-ABA9-51655690D1EB@hibernate.org>
References: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
	<CAFm4XO0oSks8ME74=hMj2e4F2g5fFdiEh2VSsfcYmGgmjRz2pA@mail.gmail.com>
	<CAFdSV9uckVaAyyYZvScH9dAXs_0EEhWaGqKh=5B7QtnroPyeqA@mail.gmail.com>
	<CAFdSV9tYiX-kVSdC85aCcDx8wzYhJeDuekwXi2YBjBjgREk3Gw@mail.gmail.com>
	<D37C8ED8-FFAE-4DFC-ABA9-51655690D1EB@hibernate.org>
Message-ID: <CAFdSV9spL=-wbLj1Zw1BkTw5M42PSjknSrCt1vfKi0TdvH6K7g@mail.gmail.com>

So the documentation is getting along.  If people could start looking it
over that would be great.  If people are willing to pick up remaining
topics, even better!

So the 2 old docs (manual and devguide) are now 3 much more focused docs:

1) Hibernate User Guide - much of the information from the old manual with
lots of TLC and updates.

a) Chapters I think are in good shape: Architecture,
DomainModel, Bootstrap, PersistenceContext, Database_Access, Transactions,
JNDI, Portability.
b) Chapters that need some work: Locking, Fetching, Caching, Events,
Multi_Tenancy, OSGi, Envers.
c) Chapters that either still need writing or new major work: Batching,
HQL, Criteria, Native Queries

This stuff is in documentation/src/main/docbook/manual, although I expect
to rename manual to userGuide to better align.  To build it, run `gradle
renderDocBook_manual` and look in
documentation/target/docbook/publish/manual.


2) Hibernate Domain Model Mapping Guide - IMO mapping is such a massive
topic it deserves its own guide.  And this is it :)  I have put A LOT of
work into this content, but there is still tons to do.

a) Chapters I think are in good shape: Data_Categorizations,
Basic_Types, Composition, Identifiers
b) Chapters that need some work: Collections,
c) Chapters that either still need writing or new major work: Entity,
Natural_Id, Associations, Secondary_Tables, Attribute_Access,
Mapping_Overrides, Generated_attributes,
"read/write
fragments", Naming_Strategies, SQL_Identifier_Quoting,
Database_Constraints, Auxiliary_DB_Objects

This content is in documentation/src/main/docbook/mapping.  To build it,
run `gradle renderDocBook_mapping` and look in
documentation/target/docbook/publish/mapping.


3) Hibernate Integrations Guide - This is intended to document all the
major integration points with Hibernate.  So far it is just a chapter on
Service+Registry.  I have started keeping a list of topics to cover in
Hibernate_Integrations.xml.
Feel free to add your favorites!


On Thu, Jul 30, 2015 at 2:11 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> I think topical guides never got traction because the work on doc was down
> to zero. I would not give up hope on them :)
>
> > On 28 Jul 2015, at 19:51, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > So tentatively I have the following docs:
> >
> > 1) "User Manual" - mostly done
> > 2) "Domain Model Mapping Guide" - work in progress, but progressing
> nicely.
> > 3) "Integrations Guide" - atm this will be just the devguide with the
> > Service+Registry chapter; but I'd like to circle back and pick up other
> > topics later.
> >
> > This leaves some open points of discussion.  From the proposal itself:
> >
> > 1) What do we cover in "batching"?
> > 2) "additionalmodules"?  I am inclined to simply drop that one, so
> unless I
> > here differently that is what will happen.
> >
> > Emmanuel replied (on irc maybe?  I forget where) that he thought topics
> > such as "Performance Monitoring" and "Best Practices" ought to be
> separate
> > documents.
> >
> > He also suggested a chapter on bootstrapping.  I totally agree.  I
> > essentially copied the topical guides on bootstrapping as a chapter in
> the
> > User Guide.  But that brings up an interesting point as to the
> distinction
> > between topical guides and documentation.  When should something go
> where?
> > I almost like to look at the topical guides as a wiki.  I don't think
> > anyone is thrilled with the SBS "wiki" we have access to.  I look at this
> > as an asciidoctor-based alternative.  Of course between SBS, GitHub wiki,
> > topical guides... gets to be a lot of places to look.  Initially the idea
> > of the topical guides was to break down the massive documentation into
> more
> > easily digestible chunks.  But that never gained traction.  Should they
> > just go away?
> >
> >
> > On Mon, Jul 27, 2015 at 5:10 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Sanne, yep thats why I sent the second email with a link ;)
> >>
> >> Anyway..  I just pushed some initial work on the manual.  Its not
> complete
> >> yet.  And I still need to start on the mapping guide.  Let me know any
> >> thoughts y'all have.
> >>
> >>
> >> On Mon, Jul 27, 2015 at 2:31 PM Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>
> >>> I didn't receive an attachment. AFAIK the mailing list drops them?
> >>> On 27 Jul 2015 14:39, "Steve Ebersole" <steve at hibernate.org> wrote:
> >>>
> >>>> I have been putting a lot of TLC into the ORM documentation this
> weekend
> >>>> getting ready for 5.0 to go Final.  To that end I have put together a
> >>>> proposal for these changes, it is attached.  I'd like to get some
> >>>> feedback.  Thanks
> >>>>
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Mon Aug  3 20:15:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 04 Aug 2015 00:15:28 +0000
Subject: [hibernate-dev] ORM Documentation
In-Reply-To: <CAFdSV9spL=-wbLj1Zw1BkTw5M42PSjknSrCt1vfKi0TdvH6K7g@mail.gmail.com>
References: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
	<CAFm4XO0oSks8ME74=hMj2e4F2g5fFdiEh2VSsfcYmGgmjRz2pA@mail.gmail.com>
	<CAFdSV9uckVaAyyYZvScH9dAXs_0EEhWaGqKh=5B7QtnroPyeqA@mail.gmail.com>
	<CAFdSV9tYiX-kVSdC85aCcDx8wzYhJeDuekwXi2YBjBjgREk3Gw@mail.gmail.com>
	<D37C8ED8-FFAE-4DFC-ABA9-51655690D1EB@hibernate.org>
	<CAFdSV9spL=-wbLj1Zw1BkTw5M42PSjknSrCt1vfKi0TdvH6K7g@mail.gmail.com>
Message-ID: <CAFdSV9t+uWCVseDifqfqO-CN_m72uNeL06=mxY5uHGQvMHZhzQ@mail.gmail.com>

Well Identifiers in the mapping guide still needs some work.  I guess move
that into category (b).  TBH I do not know how much of "derived identities"
I will document this time around.  If someone more familiar/comfortable
with explaining that stuff wanted to take a shot I would not argue :)


On Mon, Aug 3, 2015 at 6:55 PM Steve Ebersole <steve at hibernate.org> wrote:

> So the documentation is getting along.  If people could start looking it
> over that would be great.  If people are willing to pick up remaining
> topics, even better!
>
> So the 2 old docs (manual and devguide) are now 3 much more focused docs:
>
> 1) Hibernate User Guide - much of the information from the old manual with
> lots of TLC and updates.
>
> a) Chapters I think are in good shape: Architecture,
> DomainModel, Bootstrap, PersistenceContext, Database_Access, Transactions,
> JNDI, Portability.
> b) Chapters that need some work: Locking, Fetching, Caching, Events,
> Multi_Tenancy, OSGi, Envers.
> c) Chapters that either still need writing or new major work: Batching,
> HQL, Criteria, Native Queries
>
> This stuff is in documentation/src/main/docbook/manual, although I expect
> to rename manual to userGuide to better align.  To build it, run `gradle
> renderDocBook_manual` and look in
> documentation/target/docbook/publish/manual.
>
>
> 2) Hibernate Domain Model Mapping Guide - IMO mapping is such a massive
> topic it deserves its own guide.  And this is it :)  I have put A LOT of
> work into this content, but there is still tons to do.
>
> a) Chapters I think are in good shape: Data_Categorizations,
> Basic_Types, Composition, Identifiers
> b) Chapters that need some work: Collections,
> c) Chapters that either still need writing or new major work: Entity, Natural_Id, Associations, Secondary_Tables, Attribute_Access, Mapping_Overrides, Generated_attributes,
> "read/write
> fragments", Naming_Strategies, SQL_Identifier_Quoting, Database_Constraints, Auxiliary_DB_Objects
>
> This content is in documentation/src/main/docbook/mapping.  To build it,
> run `gradle renderDocBook_mapping` and look in
> documentation/target/docbook/publish/mapping.
>
>
> 3) Hibernate Integrations Guide - This is intended to document all the
> major integration points with Hibernate.  So far it is just a chapter on
> Service+Registry.  I have started keeping a list of topics to cover in Hibernate_Integrations.xml.
> Feel free to add your favorites!
>
>
> On Thu, Jul 30, 2015 at 2:11 AM Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>> I think topical guides never got traction because the work on doc was
>> down to zero. I would not give up hope on them :)
>>
>> > On 28 Jul 2015, at 19:51, Steve Ebersole <steve at hibernate.org> wrote:
>> >
>> > So tentatively I have the following docs:
>> >
>> > 1) "User Manual" - mostly done
>> > 2) "Domain Model Mapping Guide" - work in progress, but progressing
>> nicely.
>> > 3) "Integrations Guide" - atm this will be just the devguide with the
>> > Service+Registry chapter; but I'd like to circle back and pick up other
>> > topics later.
>> >
>> > This leaves some open points of discussion.  From the proposal itself:
>> >
>> > 1) What do we cover in "batching"?
>> > 2) "additionalmodules"?  I am inclined to simply drop that one, so
>> unless I
>> > here differently that is what will happen.
>> >
>> > Emmanuel replied (on irc maybe?  I forget where) that he thought topics
>> > such as "Performance Monitoring" and "Best Practices" ought to be
>> separate
>> > documents.
>> >
>> > He also suggested a chapter on bootstrapping.  I totally agree.  I
>> > essentially copied the topical guides on bootstrapping as a chapter in
>> the
>> > User Guide.  But that brings up an interesting point as to the
>> distinction
>> > between topical guides and documentation.  When should something go
>> where?
>> > I almost like to look at the topical guides as a wiki.  I don't think
>> > anyone is thrilled with the SBS "wiki" we have access to.  I look at
>> this
>> > as an asciidoctor-based alternative.  Of course between SBS, GitHub
>> wiki,
>> > topical guides... gets to be a lot of places to look.  Initially the
>> idea
>> > of the topical guides was to break down the massive documentation into
>> more
>> > easily digestible chunks.  But that never gained traction.  Should they
>> > just go away?
>> >
>> >
>> > On Mon, Jul 27, 2015 at 5:10 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> Sanne, yep thats why I sent the second email with a link ;)
>> >>
>> >> Anyway..  I just pushed some initial work on the manual.  Its not
>> complete
>> >> yet.  And I still need to start on the mapping guide.  Let me know any
>> >> thoughts y'all have.
>> >>
>> >>
>> >> On Mon, Jul 27, 2015 at 2:31 PM Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >>
>> >>> I didn't receive an attachment. AFAIK the mailing list drops them?
>> >>> On 27 Jul 2015 14:39, "Steve Ebersole" <steve at hibernate.org> wrote:
>> >>>
>> >>>> I have been putting a lot of TLC into the ORM documentation this
>> weekend
>> >>>> getting ready for 5.0 to go Final.  To that end I have put together a
>> >>>> proposal for these changes, it is attached.  I'd like to get some
>> >>>> feedback.  Thanks
>> >>>>
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>
>> >>>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>

From gunnar at hibernate.org  Tue Aug  4 02:51:14 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 4 Aug 2015 08:51:14 +0200
Subject: [hibernate-dev] Embedded Composite Identifiers
In-Reply-To: <CAFm4XO2Lr4ci+1i+iF_LEbauv+uYdPMciFeVWiWw8f62zaLFPw@mail.gmail.com>
References: <CAFdSV9ubYLq2XLQJaT8d6RZDmBnKcr4e6f_rf7cV61R-2Ai=jw@mail.gmail.com>
	<CAFdSV9v5Jtrhjp+SGKoVvaS7O9A=0BM0wO2viE7k3vkzQTgE9Q@mail.gmail.com>
	<CAFm4XO2Lr4ci+1i+iF_LEbauv+uYdPMciFeVWiWw8f62zaLFPw@mail.gmail.com>
Message-ID: <CADGJaX-7JsauR+c6eFQb4N9NoiqXqQ5X_Q6nQgg-F1KO_gjbpw@mail.gmail.com>

FWIW, that's one of the mapping patterns I always found awkward, so +1 for
deprecating it from me.

What would be the strategy, though? Deprecate in 5 and remove in 6?

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

> I remember loving this feature.
> Composite keys are very common in databases I worked with, while
> loading by ids seems to be quite uncommon in my coding style as I
> don't remember knowing how to do that, nor that this ignorance ever
> bothered me :)
>
> +1 anyway, that's just to give some perspective.
>
> On 3 August 2015 at 16:36, Steve Ebersole <steve at hibernate.org> wrote:
> > Here is what I proposes in the documentation in the section discussing
> > composite identifiers:
> >
> >
> > <note>
> >     <para>
> >         Technically a composite identifier can be made up of just a
> > single persistent attribute.
> >     </para>
> >     <para>
> >         The restriction that a composite identifier has to be
> > represented by a "primary key class" is
> >         a JPA restriction.  Hibernate does allow composite identifiers
> > to be defined without a
> >         "primary key class", but use of that modeling technique is
> > deprecated and not discussed here.
> >     </para>
> > </note>
> >
> >
> >
> >
> > On Mon, Aug 3, 2015 at 10:30 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> I am thinking we should start to soft-deprecate[1] the historical
> feature
> >> of embedded composite identifiers.  This is the feature that allowed an
> >> entity to define a composite identifier without any kind of "pk class"
> >> (EmbeddedId/IdClass):
> >>
> >> @Entity
> >> public class MyEntity {
> >>     @Id
> >>     public Integer key1;
> >>     @Id
> >>     public Integer key2;
> >>    ...
> >> }
> >>
> >> The you'd always have to instantiate the entity to deal with its
> >> identifier.  For example, to load such an entity:
> >>
> >> MyEntity id = new MyEntity(1,2);
> >> MyEntity it = session.get( MyEntity.class, id );
> >>
> >>  Between EmbeddedId and IdClass there are better alternatives to
> document.
> >>
> >> Thoughts?
> >>
> >> [1] - By "soft-deprecate" I mean remove discussion of it from the
> >> documentation, and don't really push it.
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Tue Aug  4 02:51:30 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 3 Aug 2015 23:51:30 -0700
Subject: [hibernate-dev] 5.0 defaults
In-Reply-To: <55BFCD86.8020006@redhat.com>
References: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>
	<55BFBBE6.4020903@redhat.com>
	<CAFdSV9vaUjGSLquuEC9+8a0jjkAXPmvyEp7C98aetLKLQdE4fA@mail.gmail.com>
	<55BFCD86.8020006@redhat.com>
Message-ID: <CAFDzhiRuY_pvYt-oWGVyGgYWsPVqoC-Lcs8cYZCu-3787+ftcg@mail.gmail.com>

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

From steve at hibernate.org  Tue Aug  4 09:24:46 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 04 Aug 2015 13:24:46 +0000
Subject: [hibernate-dev] Embedded Composite Identifiers
In-Reply-To: <CADGJaX-7JsauR+c6eFQb4N9NoiqXqQ5X_Q6nQgg-F1KO_gjbpw@mail.gmail.com>
References: <CAFdSV9ubYLq2XLQJaT8d6RZDmBnKcr4e6f_rf7cV61R-2Ai=jw@mail.gmail.com>
	<CAFdSV9v5Jtrhjp+SGKoVvaS7O9A=0BM0wO2viE7k3vkzQTgE9Q@mail.gmail.com>
	<CAFm4XO2Lr4ci+1i+iF_LEbauv+uYdPMciFeVWiWw8f62zaLFPw@mail.gmail.com>
	<CADGJaX-7JsauR+c6eFQb4N9NoiqXqQ5X_Q6nQgg-F1KO_gjbpw@mail.gmail.com>
Message-ID: <CAFdSV9sq6MzU7P3TSUb_sp5RP48OB9wK-V6YuzmufsSdCBOCog@mail.gmail.com>

I more just mean from a documentation perspective.  I don't plan on
removing the feature itself so much.  Although I guess we can revisit that
when we rework annotation binding and finish up model binding in general

On Tue, Aug 4, 2015, 1:51 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> FWIW, that's one of the mapping patterns I always found awkward, so +1 for
> deprecating it from me.
>
> What would be the strategy, though? Deprecate in 5 and remove in 6?
>
> 2015-08-03 17:46 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> I remember loving this feature.
>> Composite keys are very common in databases I worked with, while
>> loading by ids seems to be quite uncommon in my coding style as I
>> don't remember knowing how to do that, nor that this ignorance ever
>> bothered me :)
>>
>> +1 anyway, that's just to give some perspective.
>>
>> On 3 August 2015 at 16:36, Steve Ebersole <steve at hibernate.org> wrote:
>> > Here is what I proposes in the documentation in the section discussing
>> > composite identifiers:
>> >
>> >
>> > <note>
>> >     <para>
>> >         Technically a composite identifier can be made up of just a
>> > single persistent attribute.
>> >     </para>
>> >     <para>
>> >         The restriction that a composite identifier has to be
>> > represented by a "primary key class" is
>> >         a JPA restriction.  Hibernate does allow composite identifiers
>> > to be defined without a
>> >         "primary key class", but use of that modeling technique is
>> > deprecated and not discussed here.
>> >     </para>
>> > </note>
>> >
>> >
>> >
>> >
>> > On Mon, Aug 3, 2015 at 10:30 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> I am thinking we should start to soft-deprecate[1] the historical
>> feature
>> >> of embedded composite identifiers.  This is the feature that allowed an
>> >> entity to define a composite identifier without any kind of "pk class"
>> >> (EmbeddedId/IdClass):
>> >>
>> >> @Entity
>> >> public class MyEntity {
>> >>     @Id
>> >>     public Integer key1;
>> >>     @Id
>> >>     public Integer key2;
>> >>    ...
>> >> }
>> >>
>> >> The you'd always have to instantiate the entity to deal with its
>> >> identifier.  For example, to load such an entity:
>> >>
>> >> MyEntity id = new MyEntity(1,2);
>> >> MyEntity it = session.get( MyEntity.class, id );
>> >>
>> >>  Between EmbeddedId and IdClass there are better alternatives to
>> document.
>> >>
>> >> Thoughts?
>> >>
>> >> [1] - By "soft-deprecate" I mean remove discussion of it from the
>> >> documentation, and don't really push it.
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Tue Aug  4 09:58:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 4 Aug 2015 14:58:01 +0100
Subject: [hibernate-dev] Released: Hibernate Search 5.4.0.CR2
Message-ID: <CAFm4XO21e7Ayr_7auFV+U-nHpVfyWPeW1bwaovbno3H1JkgsrA@mail.gmail.com>

Dear all,
a second candidate release of Hibernate Search 5.4 was just released.

More details here:
 - http://in.relation.to/2015/08/05/secondCR-for-hibernate-search-54/

Regards,
Sanne

From guillaume.smet at gmail.com  Tue Aug  4 10:11:53 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 4 Aug 2015 16:11:53 +0200
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
 new mapping annotations ?
In-Reply-To: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
Message-ID: <CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>

Hi Sanne,

On Wed, Jul 29, 2015 at 1:26 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I'm not sure if this should be extending the @Field annotation as
> there are special restrictions implied in terms of analysis: are we
> going to enforce a specific type of tokenizer, or simply take the
> analysis option away?
>

You can't remove the analysis option away: it's often used to normalize
sorting on strings (lowercase, remove accents, remove special characters
and so on).

FWIW, we use specific fields for sorting each time we need to sort on a
string as we don't want to tokenize the string (but not for numerics and
dates). Maybe @SortFields/@SortField annotations would be in order (I don't
like Sortable as I don't think it's a good idea to use these fields for
search).

-- 
Guillaume

From steve at hibernate.org  Tue Aug  4 10:29:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 04 Aug 2015 14:29:26 +0000
Subject: [hibernate-dev] 5.0 defaults
In-Reply-To: <CAFDzhiRuY_pvYt-oWGVyGgYWsPVqoC-Lcs8cYZCu-3787+ftcg@mail.gmail.com>
References: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>
	<55BFBBE6.4020903@redhat.com>
	<CAFdSV9vaUjGSLquuEC9+8a0jjkAXPmvyEp7C98aetLKLQdE4fA@mail.gmail.com>
	<55BFCD86.8020006@redhat.com>
	<CAFDzhiRuY_pvYt-oWGVyGgYWsPVqoC-Lcs8cYZCu-3787+ftcg@mail.gmail.com>
Message-ID: <CAFdSV9ueAOLjphPRSmP5aodUD9h1BGKTZOkdrqGRa2XLDPeK0A@mail.gmail.com>

On Tue, Aug 4, 2015 at 1:51 AM Gail Badner <gbadner at redhat.com> wrote:

>
> 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).
>

What the TCK wants has zero sway on what Hibernate should do *by default*.
Users reading the Javadoc/source is certainly a valid argument.

And I completely disagree about the "appropriate time" to change defaults.
In fact to me 3.5 would have been the best time to make this change, which
is the version of Hibernate that supported JPA 2.0, when these implicit
names become standardized.

And also "existing applications would need to make necessary changes to
either the JPA annotations or to the database objects" is just completely
wrong, in the same way it is wrong to assume that "JPA compliant
applications" suddenly need to "make necessary changes to either the JPA
annotations or to the database objects" just to use Hibernate as the
persistence provider.  You just stated the entire reason for this being a
pluggable strategy.

Hibernate does not have to be JPA compliant out of the box.  It just needs
to be able to operate in a JPA-compliant way.  So to me these arguments
that we should change the default <something> to the more JPA-compliant one
because we should be compliant ar e circular.  No.  We should chose
defaults we feel make sense.  As long as users (and the TCK is just a user
to me in this sense) wanting "strict JPA compliance" can achieve that, we
are good.

To be honest I *really* don't care strongly one way or the other. But I do
care about reasons/justifications.  Change just to change is not good.  I
do generally tend to lean towards the existing default in cases where there
is not a compelling reason to change; especially when the change affects
existing application's ability to upgrade.  "So that we can be more spec
compliant" is not an argument for me as to why we should change a setting
default.

Coming back to the idea of annotation javadoc/source.. Again I think thats
a great and valid argument.  However, keep in mind that what I don't want
is different defaults/expectations when someone uses annotations or orm.xml
or hbm.xml.  There should be a consistent experience for users in this
regard.  Also, in developing 5.0 another thing I noticed is that hbm.xml
and annotations/orm.xml bind implicit names differently; that is, different
ImplicitNamingStrategy methods get called for the same logical concept
between them.  But that's an inconsistency we need to deal with for now.




> 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.
>

As I mentioned above, I am tired of hearing this as an argument for setting
defaults :)  And here its not even true.  Show me where the spec says that
a provider cannot automatically quote SQL identifiers that are keywords...
I'll wait... ;)  Because it is simply not there.  You are confusing a
problem in the TCK run because of this feature being too aggressive at the
moment with being compliant or not with the spec.

Again, I am ok changing this default.  But I'd like some valid compelling
arguments for it.  Actually for this one I think I am convinced to disable
it by default.  But more so because of it being overly aggressive at the
moment.  Also, in a way it is nice to make users opt-in to such features.

From steve at hibernate.org  Tue Aug  4 11:29:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 04 Aug 2015 15:29:03 +0000
Subject: [hibernate-dev] 5.0 defaults
In-Reply-To: <CAFdSV9ueAOLjphPRSmP5aodUD9h1BGKTZOkdrqGRa2XLDPeK0A@mail.gmail.com>
References: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>
	<55BFBBE6.4020903@redhat.com>
	<CAFdSV9vaUjGSLquuEC9+8a0jjkAXPmvyEp7C98aetLKLQdE4fA@mail.gmail.com>
	<55BFCD86.8020006@redhat.com>
	<CAFDzhiRuY_pvYt-oWGVyGgYWsPVqoC-Lcs8cYZCu-3787+ftcg@mail.gmail.com>
	<CAFdSV9ueAOLjphPRSmP5aodUD9h1BGKTZOkdrqGRa2XLDPeK0A@mail.gmail.com>
Message-ID: <CAFdSV9vgcNDK1gRrQwOua4FvzQFqE+63TG2it1UwJYzg2Xb9dw@mail.gmail.com>

For what it is worth...

At the moment I am leaning towards changing the defaults for:
1) "use new id generator mappings" -> true
2) "auto quote keywords" -> false

As I mentioned, to me changing any of these defaults warrants a new CR (and
obviously documenting in the migration guide).  I plan on cutting that CR
tomorrow.


On Tue, Aug 4, 2015 at 9:29 AM Steve Ebersole <steve at hibernate.org> wrote:

> On Tue, Aug 4, 2015 at 1:51 AM Gail Badner <gbadner at redhat.com> wrote:
>
>>
>> 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).
>>
>
> What the TCK wants has zero sway on what Hibernate should do *by
> default*.  Users reading the Javadoc/source is certainly a valid argument.
>
> And I completely disagree about the "appropriate time" to change
> defaults.  In fact to me 3.5 would have been the best time to make this
> change, which is the version of Hibernate that supported JPA 2.0, when
> these implicit names become standardized.
>
> And also "existing applications would need to make necessary changes to
> either the JPA annotations or to the database objects" is just completely
> wrong, in the same way it is wrong to assume that "JPA compliant
> applications" suddenly need to "make necessary changes to either the JPA
> annotations or to the database objects" just to use Hibernate as the
> persistence provider.  You just stated the entire reason for this being a
> pluggable strategy.
>
> Hibernate does not have to be JPA compliant out of the box.  It just needs
> to be able to operate in a JPA-compliant way.  So to me these arguments
> that we should change the default <something> to the more JPA-compliant one
> because we should be compliant ar e circular.  No.  We should chose
> defaults we feel make sense.  As long as users (and the TCK is just a user
> to me in this sense) wanting "strict JPA compliance" can achieve that, we
> are good.
>
> To be honest I *really* don't care strongly one way or the other. But I do
> care about reasons/justifications.  Change just to change is not good.  I
> do generally tend to lean towards the existing default in cases where there
> is not a compelling reason to change; especially when the change affects
> existing application's ability to upgrade.  "So that we can be more spec
> compliant" is not an argument for me as to why we should change a setting
> default.
>
> Coming back to the idea of annotation javadoc/source.. Again I think thats
> a great and valid argument.  However, keep in mind that what I don't want
> is different defaults/expectations when someone uses annotations or orm.xml
> or hbm.xml.  There should be a consistent experience for users in this
> regard.  Also, in developing 5.0 another thing I noticed is that hbm.xml
> and annotations/orm.xml bind implicit names differently; that is, different
> ImplicitNamingStrategy methods get called for the same logical concept
> between them.  But that's an inconsistency we need to deal with for now.
>
>
>
>
> > 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.
>>
>
> As I mentioned above, I am tired of hearing this as an argument for
> setting defaults :)  And here its not even true.  Show me where the spec
> says that a provider cannot automatically quote SQL identifiers that are
> keywords... I'll wait... ;)  Because it is simply not there.  You are
> confusing a problem in the TCK run because of this feature being too
> aggressive at the moment with being compliant or not with the spec.
>
> Again, I am ok changing this default.  But I'd like some valid compelling
> arguments for it.  Actually for this one I think I am convinced to disable
> it by default.  But more so because of it being overly aggressive at the
> moment.  Also, in a way it is nice to make users opt-in to such features.
>
>

From sanne at hibernate.org  Tue Aug  4 12:00:14 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 4 Aug 2015 17:00:14 +0100
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
 new mapping annotations ?
In-Reply-To: <CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
	<CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
Message-ID: <CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>

Hi Guillaume,
thanks! great input. Some comments inline:

On 4 August 2015 at 15:11, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi Sanne,
>
> On Wed, Jul 29, 2015 at 1:26 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> I'm not sure if this should be extending the @Field annotation as
>> there are special restrictions implied in terms of analysis: are we
>> going to enforce a specific type of tokenizer, or simply take the
>> analysis option away?
>
>
> You can't remove the analysis option away: it's often used to normalize
> sorting on strings (lowercase, remove accents, remove special characters and
> so on).

Right we made this same example in a recent meeting we had on this same subject.
So that's what makes it tricky: we want to allow Analysis, but while
Lucene needs a strong guarantee that it will be unique, we can't
really verify for that unless we take away the liberty to use any
analyzer.
An alternative would be to wrap the Analyzer to monitor and verify it
to be "well-behaved" but I'm not sure if that's doable, or if the
performance would be negligible. I guess we'll just put it into user's
hands to make a sensible choice.. not that we've done better so far on
this aspect.

> FWIW, we use specific fields for sorting each time we need to sort on a
> string as we don't want to tokenize the string (but not for numerics and
> dates). Maybe @SortFields/@SortField annotations would be in order (I don't
> like Sortable as I don't think it's a good idea to use these fields for
> search).

I like that name proposal, and +1 to not encourage people to try reuse
the same field for sorting and indexing.

The next action for us is to verify what the performance impact is of
the current approach, which is based on the UninvertingReader from
lucene-misc. Gunnar pointed out that uninverting and loading into a
FieldCache is not very different than what Lucene has been doing so
far, so that might be a good strategy to allow migrating to Lucene 5
incrementally, and provide an incremental improvement in this area
rather than requiring the new mapping.

I'll soon merge this approach, and as usual I'm lacking on real-world
applications to benchmark so if you're interested in helping on that
that would be awesome; we just need to know that the new code won't be
significantly slower than the Lucene 4 based strategies for sorted
queries.

Thanks,
Sanne

From flemming.harms at gmail.com  Tue Aug  4 12:39:56 2015
From: flemming.harms at gmail.com (Flemming Harms)
Date: Tue, 4 Aug 2015 18:39:56 +0200
Subject: [hibernate-dev] [Hibernate Search] Database back end worker
Message-ID: <CAFP3+ykfZk77_VU2nByfFkaY43nA7KG06kbb4ZZ+dKVKJ3LBgA@mail.gmail.com>

Hey guys

I want to introduce myself and a new database back-end worker, me and
another guy have build for hibernate search. I already had some initial
talk with Sanne regarding if this could be interested to the hibernate
search project.

I have been working with Hibernate Search from some time and actually done
various small custom modification to search since 3.x, especial around
running in a cluster and indexing. To make a long story short when we
upgraded Hibernate search we thought it would be ideal to use a SQL
database as storage for lucene workers for 3 main reasons.

- The database was shared between the nodes
- The workers was persistent in case of a node crash.
- No master/slave


*In some way it?s very similar to the JMS back-end worker, where the user
also have to implement a MDB that process the workers. In our case they
will have to implement a job using something like quartz or a timer
service. *

*We are using JPA as persistence layer for the database, even it?s a fairly
simple entity we persistent, but it make sense for supporting various
databases and schema update out of the box. We have tried to make it?s as
easy as possible to set-up by minimizing the number of properties, and it?s
all configurable from the persistence.xml*

*The actually work can* be *find here
https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
<https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend>*



*So based on this introduction and the code, is this something you could
use? (of course with the modification it requires to follow the design,
style, docs etc for the search)*--

Kind regards
Flemming Harms

From davide at hibernate.org  Tue Aug  4 13:49:37 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 4 Aug 2015 18:49:37 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
Message-ID: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>

Hi,
I started to work on the creation of the bridges for the classes in the
java.time package.

I was wondering if we want to convert the values to long using the existing
approach we have now for java.util.Date.

In Hibernate Search a java.util.Date is converted into a long that
represents the number of milliseconds since January 1, 1970, 00:00:00 GMT
using getTime().

The same value can be obtain from a java.time.LocaDate via:

        long epochMilli = date.atStartOfDay( ZoneOffset.UTC
).toInstant().toEpochMilli();

LocalDate has a method that returns the same value expressed in number of
days:

        long epochDay = date.toEpochDay();


I would use the second approach

Davide

From gunnar at hibernate.org  Wed Aug  5 05:41:30 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 5 Aug 2015 11:41:30 +0200
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
 new mapping annotations ?
In-Reply-To: <CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
	<CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
	<CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>
Message-ID: <CADGJaX9+wnnhLuLim8AY=qS2bvPq_5r=pr-h99Q2dXZDOTOeMw@mail.gmail.com>

Hi,

I think a great solution for that would be to leverage "annotation
composition" as done e.g. in CDI and Bean Validation.

There would be an annotation @DocValuesField which will cause the creation
of a DocValues and which would expose attributes required for its
configuration:

    @DocValuesField(name="foo", ... )
    private String bar;

Besides using @DocValuesField itself directly, it would be usable as a
meta-annotation on "doc value annotation types":

    @DocValuesField
    public @interface SortField {

        @OverridesAttribute(name="name")
        String name();
    }

And then its usage:

    @SortField
    private String bar;


Of course such doc value annotation types (I think @SortField, @Facet and
@DocumentId could be modelled as that) would only expose those degrees of
freedom needed for a specific use case.

Most users would only use these more abstract, easy-to-use specific purpose
annotations. But others could use @DocValuesField directly to create custom
doc values or they could even create their own, domain-specific doc value
annotation type.

Cheers,

--Gunnar




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

> Hi Guillaume,
> thanks! great input. Some comments inline:
>
> On 4 August 2015 at 15:11, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> > Hi Sanne,
> >
> > On Wed, Jul 29, 2015 at 1:26 PM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> I'm not sure if this should be extending the @Field annotation as
> >> there are special restrictions implied in terms of analysis: are we
> >> going to enforce a specific type of tokenizer, or simply take the
> >> analysis option away?
> >
> >
> > You can't remove the analysis option away: it's often used to normalize
> > sorting on strings (lowercase, remove accents, remove special characters
> and
> > so on).
>
> Right we made this same example in a recent meeting we had on this same
> subject.
> So that's what makes it tricky: we want to allow Analysis, but while
> Lucene needs a strong guarantee that it will be unique, we can't
> really verify for that unless we take away the liberty to use any
> analyzer.
> An alternative would be to wrap the Analyzer to monitor and verify it
> to be "well-behaved" but I'm not sure if that's doable, or if the
> performance would be negligible. I guess we'll just put it into user's
> hands to make a sensible choice.. not that we've done better so far on
> this aspect.
>
> > FWIW, we use specific fields for sorting each time we need to sort on a
> > string as we don't want to tokenize the string (but not for numerics and
> > dates). Maybe @SortFields/@SortField annotations would be in order (I
> don't
> > like Sortable as I don't think it's a good idea to use these fields for
> > search).
>
> I like that name proposal, and +1 to not encourage people to try reuse
> the same field for sorting and indexing.
>
> The next action for us is to verify what the performance impact is of
> the current approach, which is based on the UninvertingReader from
> lucene-misc. Gunnar pointed out that uninverting and loading into a
> FieldCache is not very different than what Lucene has been doing so
> far, so that might be a good strategy to allow migrating to Lucene 5
> incrementally, and provide an incremental improvement in this area
> rather than requiring the new mapping.
>
> I'll soon merge this approach, and as usual I'm lacking on real-world
> applications to benchmark so if you're interested in helping on that
> that would be awesome; we just need to know that the new code won't be
> significantly slower than the Lucene 4 based strategies for sorted
> queries.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From martinbraun123 at aol.com  Wed Aug  5 05:57:25 2015
From: martinbraun123 at aol.com (Martin Braun)
Date: Wed, 5 Aug 2015 05:57:25 -0400
Subject: [hibernate-dev] [Hibernate Search] Database back end worker
In-Reply-To: <CAFP3+ykfZk77_VU2nByfFkaY43nA7KG06kbb4ZZ+dKVKJ3LBgA@mail.gmail.com>
References: <CAFP3+ykfZk77_VU2nByfFkaY43nA7KG06kbb4ZZ+dKVKJ3LBgA@mail.gmail.com>
Message-ID: <14efd4b452c-7fae-3686d@webprd-m59.mail.aol.com>

Hi,


Note: I am no core developer of Hibernate Search, but I am currently working on something
that looks quite similar to what you are doing :). One part of it is an updating mechanism based on triggers
that uses the database as a event-storage as well. It's not the exact same thing, but related.


https://github.com/Hotware/Hibernate-Search-JPA



The idea is quite nice, but after looking at the sourcecode I am wondering
how the different nodes are able to work together, because in
AbstractDatabaseHibernateSearchController you remove the entity
from the persistence context and I wasn't able to find code that would
make up for that.


Doesn't that mean that the other workers will not be able to read that entity?
Or will users of this need to implement their own synchronization mechanism between
the different nodes?


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




-----Original Message-----
From: Flemming Harms <flemming.harms at gmail.com>
To: Hibernate.org <hibernate-dev at lists.jboss.org>
Sent: Tue, Aug 4, 2015 6:40 pm
Subject: [hibernate-dev] [Hibernate Search] Database back end worker


Hey guys

I want to introduce myself and a new database back-end worker, me
and
another guy have build for hibernate search. I already had some initial
talk
with Sanne regarding if this could be interested to the hibernate
search
project.

I have been working with Hibernate Search from some time and actually
done
various small custom modification to search since 3.x, especial
around
running in a cluster and indexing. To make a long story short when
we
upgraded Hibernate search we thought it would be ideal to use a SQL
database
as storage for lucene workers for 3 main reasons.

- The database was shared
between the nodes
- The workers was persistent in case of a node crash.
- No
master/slave


*In some way it?s very similar to the JMS back-end worker, where
the user
also have to implement a MDB that process the workers. In our case
they
will have to implement a job using something like quartz or a
timer
service. *

*We are using JPA as persistence layer for the database, even
it?s a fairly
simple entity we persistent, but it make sense for supporting
various
databases and schema update out of the box. We have tried to make it?s
as
easy as possible to set-up by minimizing the number of properties, and
it?s
all configurable from the persistence.xml*

*The actually work can* be
*find
here
https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
<https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend>*



*So
based on this introduction and the code, is this something you could
use? (of
course with the modification it requires to follow the design,
style, docs etc
for the search)*--

Kind regards
Flemming
Harms
_______________________________________________
hibernate-dev mailing
list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
 


From gunnar at hibernate.org  Wed Aug  5 06:10:27 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 5 Aug 2015 12:10:27 +0200
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
Message-ID: <CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>

Hi,

What's the motivation for using a different representation in that case?

For the sake of consistency, I'd use milli seconds since 1970-01-01 across
the board. Otherwise it'll be more difficult to compare fields created from
properties of different date types.

--Gunnar


2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:

> Hi,
> I started to work on the creation of the bridges for the classes in the
> java.time package.
>
> I was wondering if we want to convert the values to long using the existing
> approach we have now for java.util.Date.
>
> In Hibernate Search a java.util.Date is converted into a long that
> represents the number of milliseconds since January 1, 1970, 00:00:00 GMT
> using getTime().
>
> The same value can be obtain from a java.time.LocaDate via:
>
>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
> ).toInstant().toEpochMilli();
>
> LocalDate has a method that returns the same value expressed in number of
> days:
>
>         long epochDay = date.toEpochDay();
>
>
> I would use the second approach
>
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Aug  5 06:41:40 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 5 Aug 2015 11:41:40 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
Message-ID: <CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>

Our current implementation converts Date in the long "distance from
epoch" to allow correct range-queries treating each Date as an instant
in time - allowing a universal sorting strategy. But a LocalDate is
not an instant-in-time.

A LocalDate is intentionally oblivious of the timezone; as the javadoc
states, it's useful for birthdays, i.e. symbolic occurrences and
potentially legal matters which don't fit into a universal sorting
model but rather with the local political scene - we would need the
combo {LocalDate, ZoneId} provided to be able to allow sorting across
different LocalDate - or simply assume that they are all referring to
the same Zone.

I think that if the user is using a LocalDate type, he's implicitly
hinting that the timezone is not relevant for the practical use
(possibly even wrong); the most faithful representation would be the
string form in ISO standard format or to encode the day,month,year as
independent fields? This last detail depends on how it would be more
efficient to store & query; probably the String format YYYYMMDD would
be the most efficient internal representation to allow also correct
sorting.

I wouldn't use NumericField(s) in this case, as they are more
effective only with larger ranges, while MM and DD are very short; not
sure if it's worth splitting the year as a NumericField either, as the
values will likely be strongly clustered in the same range of "recent
years" - although that might depend on the application but it doesn't
seem worth the complexity, so I'd index & store as a String YYYYMMDD.

-- Sanne


On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> What's the motivation for using a different representation in that case?
>
> For the sake of consistency, I'd use milli seconds since 1970-01-01 across
> the board. Otherwise it'll be more difficult to compare fields created from
> properties of different date types.
>
> --Gunnar
>
>
> 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>
>> Hi,
>> I started to work on the creation of the bridges for the classes in the
>> java.time package.
>>
>> I was wondering if we want to convert the values to long using the existing
>> approach we have now for java.util.Date.
>>
>> In Hibernate Search a java.util.Date is converted into a long that
>> represents the number of milliseconds since January 1, 1970, 00:00:00 GMT
>> using getTime().
>>
>> The same value can be obtain from a java.time.LocaDate via:
>>
>>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>> ).toInstant().toEpochMilli();
>>
>> LocalDate has a method that returns the same value expressed in number of
>> days:
>>
>>         long epochDay = date.toEpochDay();
>>
>>
>> I would use the second approach
>>
>> Davide
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From davide at hibernate.org  Wed Aug  5 09:29:18 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 5 Aug 2015 14:29:18 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
Message-ID: <CANoTJYMMqCMx+Cjd-AASU=0juiTde0byqkCu_fsfeU+nnwcu0g@mail.gmail.com>

> wouldn't use NumericField(s) in this case, as they are more
> effective only with larger ranges, while MM and DD are very short;


I'm ok with that, it just that the @DateBridge annotation allows to choose
the encoding
and it would sound strange not to enable this annotation for this type.




On Wed, Aug 5, 2015 at 11:41 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Our current implementation converts Date in the long "distance from
> epoch" to allow correct range-queries treating each Date as an instant
> in time - allowing a universal sorting strategy. But a LocalDate is
> not an instant-in-time.
>
> A LocalDate is intentionally oblivious of the timezone; as the javadoc
> states, it's useful for birthdays, i.e. symbolic occurrences and
> potentially legal matters which don't fit into a universal sorting
> model but rather with the local political scene - we would need the
> combo {LocalDate, ZoneId} provided to be able to allow sorting across
> different LocalDate - or simply assume that they are all referring to
> the same Zone.
>
> I think that if the user is using a LocalDate type, he's implicitly
> hinting that the timezone is not relevant for the practical use
> (possibly even wrong); the most faithful representation would be the
> string form in ISO standard format or to encode the day,month,year as
> independent fields? This last detail depends on how it would be more
> efficient to store & query; probably the String format YYYYMMDD would
> be the most efficient internal representation to allow also correct
> sorting.
>
> I wouldn't use NumericField(s) in this case, as they are more
> effective only with larger ranges, while MM and DD are very short; not
> sure if it's worth splitting the year as a NumericField either, as the
> values will likely be strongly clustered in the same range of "recent
> years" - although that might depend on the application but it doesn't
> seem worth the complexity, so I'd index & store as a String YYYYMMDD.
>
> -- Sanne
>
>
> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > What's the motivation for using a different representation in that case?
> >
> > For the sake of consistency, I'd use milli seconds since 1970-01-01
> across
> > the board. Otherwise it'll be more difficult to compare fields created
> from
> > properties of different date types.
> >
> > --Gunnar
> >
> >
> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
> >
> >> Hi,
> >> I started to work on the creation of the bridges for the classes in the
> >> java.time package.
> >>
> >> I was wondering if we want to convert the values to long using the
> existing
> >> approach we have now for java.util.Date.
> >>
> >> In Hibernate Search a java.util.Date is converted into a long that
> >> represents the number of milliseconds since January 1, 1970, 00:00:00
> GMT
> >> using getTime().
> >>
> >> The same value can be obtain from a java.time.LocaDate via:
> >>
> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
> >> ).toInstant().toEpochMilli();
> >>
> >> LocalDate has a method that returns the same value expressed in number
> of
> >> days:
> >>
> >>         long epochDay = date.toEpochDay();
> >>
> >>
> >> I would use the second approach
> >>
> >> Davide
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Aug  5 09:43:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 05 Aug 2015 13:43:33 +0000
Subject: [hibernate-dev] 5.0 defaults
In-Reply-To: <CAFdSV9vgcNDK1gRrQwOua4FvzQFqE+63TG2it1UwJYzg2Xb9dw@mail.gmail.com>
References: <CAFdSV9tLgNuSNGajB9QanDuDPwdXuP7m8e3G_YEXSqO5e_mPeg@mail.gmail.com>
	<55BFBBE6.4020903@redhat.com>
	<CAFdSV9vaUjGSLquuEC9+8a0jjkAXPmvyEp7C98aetLKLQdE4fA@mail.gmail.com>
	<55BFCD86.8020006@redhat.com>
	<CAFDzhiRuY_pvYt-oWGVyGgYWsPVqoC-Lcs8cYZCu-3787+ftcg@mail.gmail.com>
	<CAFdSV9ueAOLjphPRSmP5aodUD9h1BGKTZOkdrqGRa2XLDPeK0A@mail.gmail.com>
	<CAFdSV9vgcNDK1gRrQwOua4FvzQFqE+63TG2it1UwJYzg2Xb9dw@mail.gmail.com>
Message-ID: <CAFdSV9vgAkF=EJgtfQx9BEG-UBN_NDigAsuZhcK-_bS+Piyw+Q@mail.gmail.com>

Ok, I am changing my mind ImplicitNamingStratregy as well.  Gail's
"annotation javadoc" argument swayed me.  I have already changed the
defaults for keyword-auto-quoting (to false) and use-new-generator-mappings
(to true).  I will add a change for the default ImplicitNamingStratregy as
well for CR4.  Additionally I will add some "short naming" for the
Hibernate-provided ImplicitNamingStratregy impls.

I will leave strict-jpql-compliance as defaulting to false (support full
HQL syntax by default).

On Tue, Aug 4, 2015 at 10:29 AM Steve Ebersole <steve at hibernate.org> wrote:

> For what it is worth...
>
> At the moment I am leaning towards changing the defaults for:
> 1) "use new id generator mappings" -> true
> 2) "auto quote keywords" -> false
>
> As I mentioned, to me changing any of these defaults warrants a new CR
> (and obviously documenting in the migration guide).  I plan on cutting that
> CR tomorrow.
>
>
> On Tue, Aug 4, 2015 at 9:29 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> On Tue, Aug 4, 2015 at 1:51 AM Gail Badner <gbadner at redhat.com> wrote:
>>
>>>
>>> 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).
>>>
>>
>> What the TCK wants has zero sway on what Hibernate should do *by
>> default*.  Users reading the Javadoc/source is certainly a valid argument.
>>
>> And I completely disagree about the "appropriate time" to change
>> defaults.  In fact to me 3.5 would have been the best time to make this
>> change, which is the version of Hibernate that supported JPA 2.0, when
>> these implicit names become standardized.
>>
>> And also "existing applications would need to make necessary changes to
>> either the JPA annotations or to the database objects" is just completely
>> wrong, in the same way it is wrong to assume that "JPA compliant
>> applications" suddenly need to "make necessary changes to either the JPA
>> annotations or to the database objects" just to use Hibernate as the
>> persistence provider.  You just stated the entire reason for this being a
>> pluggable strategy.
>>
>> Hibernate does not have to be JPA compliant out of the box.  It just
>> needs to be able to operate in a JPA-compliant way.  So to me these
>> arguments that we should change the default <something> to the more
>> JPA-compliant one because we should be compliant ar e circular.  No.  We
>> should chose defaults we feel make sense.  As long as users (and the TCK is
>> just a user to me in this sense) wanting "strict JPA compliance" can
>> achieve that, we are good.
>>
>> To be honest I *really* don't care strongly one way or the other. But I
>> do care about reasons/justifications.  Change just to change is not good.
>> I do generally tend to lean towards the existing default in cases where
>> there is not a compelling reason to change; especially when the change
>> affects existing application's ability to upgrade.  "So that we can be more
>> spec compliant" is not an argument for me as to why we should change a
>> setting default.
>>
>> Coming back to the idea of annotation javadoc/source.. Again I think
>> thats a great and valid argument.  However, keep in mind that what I don't
>> want is different defaults/expectations when someone uses annotations or
>> orm.xml or hbm.xml.  There should be a consistent experience for users in
>> this regard.  Also, in developing 5.0 another thing I noticed is that
>> hbm.xml and annotations/orm.xml bind implicit names differently; that is,
>> different ImplicitNamingStrategy methods get called for the same logical
>> concept between them.  But that's an inconsistency we need to deal with for
>> now.
>>
>>
>>
>>
>> > 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.
>>>
>>
>> As I mentioned above, I am tired of hearing this as an argument for
>> setting defaults :)  And here its not even true.  Show me where the spec
>> says that a provider cannot automatically quote SQL identifiers that are
>> keywords... I'll wait... ;)  Because it is simply not there.  You are
>> confusing a problem in the TCK run because of this feature being too
>> aggressive at the moment with being compliant or not with the spec.
>>
>> Again, I am ok changing this default.  But I'd like some valid compelling
>> arguments for it.  Actually for this one I think I am convinced to disable
>> it by default.  But more so because of it being overly aggressive at the
>> moment.  Also, in a way it is nice to make users opt-in to such features.
>>
>>
>

From sanne at hibernate.org  Wed Aug  5 09:47:05 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 5 Aug 2015 14:47:05 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CANoTJYMMqCMx+Cjd-AASU=0juiTde0byqkCu_fsfeU+nnwcu0g@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CANoTJYMMqCMx+Cjd-AASU=0juiTde0byqkCu_fsfeU+nnwcu0g@mail.gmail.com>
Message-ID: <CAFm4XO2aM476RE7Ut=0P+2LORdyLaO3BvMqVKGn92Vn3CuYKJA@mail.gmail.com>

On 5 August 2015 at 14:29, Davide D'Alto <davide at hibernate.org> wrote:
>> wouldn't use NumericField(s) in this case, as they are more
>> effective only with larger ranges, while MM and DD are very short;
>
>
> I'm ok with that, it just that the @DateBridge annotation allows to choose
> the encoding
> and it would sound strange not to enable this annotation for this type.

Keep in mind that the Resolution attribute of @DateBridge provides
several choices which don't make sense with a LocalDate, as the value
object doesn't have a time or milliseconds range.

In some ways our @DateBridge was necessary to deal with the
limitations of Date, which was a very generic vessel.

What do you suggest we do if a user maps the following?

   @DateBridge(resolution=MILLISECOND)
   LocalDate birthday;

Thanks,
Sanne




> On Wed, Aug 5, 2015 at 11:41 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Our current implementation converts Date in the long "distance from
>> epoch" to allow correct range-queries treating each Date as an instant
>> in time - allowing a universal sorting strategy. But a LocalDate is
>> not an instant-in-time.
>>
>> A LocalDate is intentionally oblivious of the timezone; as the javadoc
>> states, it's useful for birthdays, i.e. symbolic occurrences and
>> potentially legal matters which don't fit into a universal sorting
>> model but rather with the local political scene - we would need the
>> combo {LocalDate, ZoneId} provided to be able to allow sorting across
>> different LocalDate - or simply assume that they are all referring to
>> the same Zone.
>>
>> I think that if the user is using a LocalDate type, he's implicitly
>> hinting that the timezone is not relevant for the practical use
>> (possibly even wrong); the most faithful representation would be the
>> string form in ISO standard format or to encode the day,month,year as
>> independent fields? This last detail depends on how it would be more
>> efficient to store & query; probably the String format YYYYMMDD would
>> be the most efficient internal representation to allow also correct
>> sorting.
>>
>> I wouldn't use NumericField(s) in this case, as they are more
>> effective only with larger ranges, while MM and DD are very short; not
>> sure if it's worth splitting the year as a NumericField either, as the
>> values will likely be strongly clustered in the same range of "recent
>> years" - although that might depend on the application but it doesn't
>> seem worth the complexity, so I'd index & store as a String YYYYMMDD.
>>
>> -- Sanne
>>
>>
>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Hi,
>> >
>> > What's the motivation for using a different representation in that case?
>> >
>> > For the sake of consistency, I'd use milli seconds since 1970-01-01
>> across
>> > the board. Otherwise it'll be more difficult to compare fields created
>> from
>> > properties of different date types.
>> >
>> > --Gunnar
>> >
>> >
>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>> >
>> >> Hi,
>> >> I started to work on the creation of the bridges for the classes in the
>> >> java.time package.
>> >>
>> >> I was wondering if we want to convert the values to long using the
>> existing
>> >> approach we have now for java.util.Date.
>> >>
>> >> In Hibernate Search a java.util.Date is converted into a long that
>> >> represents the number of milliseconds since January 1, 1970, 00:00:00
>> GMT
>> >> using getTime().
>> >>
>> >> The same value can be obtain from a java.time.LocaDate via:
>> >>
>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>> >> ).toInstant().toEpochMilli();
>> >>
>> >> LocalDate has a method that returns the same value expressed in number
>> of
>> >> days:
>> >>
>> >>         long epochDay = date.toEpochDay();
>> >>
>> >>
>> >> I would use the second approach
>> >>
>> >> Davide
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Aug  5 10:24:51 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 5 Aug 2015 16:24:51 +0200
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
Message-ID: <CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>

2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Our current implementation converts Date in the long "distance from
> epoch" to allow correct range-queries treating each Date as an instant
> in time - allowing a universal sorting strategy. But a LocalDate is
> not an instant-in-time.
>
> A LocalDate is intentionally oblivious of the timezone; as the javadoc
> states, it's useful for birthdays, i.e. symbolic occurrences and
> potentially legal matters which don't fit into a universal sorting
> model but rather with the local political scene - we would need the
> combo {LocalDate, ZoneId} provided to be able to allow sorting across
> different LocalDate - or simply assume that they are all referring to
> the same Zone.
>

Right, I had the latter in mind and would use UTC for that purpose.

>
> I think that if the user is using a LocalDate type, he's implicitly
> hinting that the timezone is not relevant for the practical use
> (possibly even wrong); the most faithful representation would be the
> string form in ISO standard format or to encode the day,month,year as
> independent fields? This last detail depends on how it would be more
> efficient to store & query; probably the String format YYYYMMDD would
> be the most efficient internal representation to allow also correct
> sorting.
>
> I wouldn't use NumericField(s) in this case, as they are more
> effective only with larger ranges, while MM and DD are very short; not
> sure if it's worth splitting the year as a NumericField either, as the
> values will likely be strongly clustered in the same range of "recent
> years" - although that might depend on the application but it doesn't
> seem worth the complexity, so I'd index & store as a String YYYYMMDD.
>

Agreed that this makes most sense, given the "symbolic" nature of LocalDate.

What would you do though in case of the following:

    @DateBridge
    LocalDate myDate;

encoding() defaults to NUMERIC, so would you a) raise an error, or b)
ignore encoding() for LocalDate and friends? Both seem not right to me. I
think there is nothing wrong with using NUMERIC encoding per-se for these
types. We may recommend STRING but if NUMERIC really is what a user wants I
would let them do so.

>
> -- Sanne
>
>
> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > What's the motivation for using a different representation in that case?
> >
> > For the sake of consistency, I'd use milli seconds since 1970-01-01
> across
> > the board. Otherwise it'll be more difficult to compare fields created
> from
> > properties of different date types.
> >
> > --Gunnar
> >
> >
> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
> >
> >> Hi,
> >> I started to work on the creation of the bridges for the classes in the
> >> java.time package.
> >>
> >> I was wondering if we want to convert the values to long using the
> existing
> >> approach we have now for java.util.Date.
> >>
> >> In Hibernate Search a java.util.Date is converted into a long that
> >> represents the number of milliseconds since January 1, 1970, 00:00:00
> GMT
> >> using getTime().
> >>
> >> The same value can be obtain from a java.time.LocaDate via:
> >>
> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
> >> ).toInstant().toEpochMilli();
> >>
> >> LocalDate has a method that returns the same value expressed in number
> of
> >> days:
> >>
> >>         long epochDay = date.toEpochDay();
> >>
> >>
> >> I would use the second approach
> >>
> >> Davide
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Wed Aug  5 10:37:41 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 5 Aug 2015 15:37:41 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
Message-ID: <CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>

> What would you do though in case of the following:
>
>   @DateBridge
>    LocalDate myDate;
>
> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
ignore encoding() for LocalDate and friends? Both seem not right to me. I
think there is nothing wrong with using NUMERIC encoding per-se for these
types. We may recommend STRING but if NUMERIC really is what a user wants I
would let them do so.

+1

> What do you suggest we do if a user maps the following?

>   @DateBridge(resolution=MILLISECOND)
>   LocalDate birthday;


Nothing really,
I would just consider a LocalDate the same as a LocalDateTime with time
00:00:000 (UTC time zone)

It is equivalent to:
LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );










On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

>
>
> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> Our current implementation converts Date in the long "distance from
>> epoch" to allow correct range-queries treating each Date as an instant
>> in time - allowing a universal sorting strategy. But a LocalDate is
>> not an instant-in-time.
>>
>> A LocalDate is intentionally oblivious of the timezone; as the javadoc
>> states, it's useful for birthdays, i.e. symbolic occurrences and
>> potentially legal matters which don't fit into a universal sorting
>> model but rather with the local political scene - we would need the
>> combo {LocalDate, ZoneId} provided to be able to allow sorting across
>> different LocalDate - or simply assume that they are all referring to
>> the same Zone.
>>
>
> Right, I had the latter in mind and would use UTC for that purpose.
>
>>
>> I think that if the user is using a LocalDate type, he's implicitly
>> hinting that the timezone is not relevant for the practical use
>> (possibly even wrong); the most faithful representation would be the
>> string form in ISO standard format or to encode the day,month,year as
>> independent fields? This last detail depends on how it would be more
>> efficient to store & query; probably the String format YYYYMMDD would
>> be the most efficient internal representation to allow also correct
>> sorting.
>>
>> I wouldn't use NumericField(s) in this case, as they are more
>> effective only with larger ranges, while MM and DD are very short; not
>> sure if it's worth splitting the year as a NumericField either, as the
>> values will likely be strongly clustered in the same range of "recent
>> years" - although that might depend on the application but it doesn't
>> seem worth the complexity, so I'd index & store as a String YYYYMMDD.
>>
>
> Agreed that this makes most sense, given the "symbolic" nature of
> LocalDate.
>
> What would you do though in case of the following:
>
>     @DateBridge
>     LocalDate myDate;
>
> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
> ignore encoding() for LocalDate and friends? Both seem not right to me. I
> think there is nothing wrong with using NUMERIC encoding per-se for these
> types. We may recommend STRING but if NUMERIC really is what a user wants I
> would let them do so.
>
>>
>> -- Sanne
>>
>>
>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Hi,
>> >
>> > What's the motivation for using a different representation in that case?
>> >
>> > For the sake of consistency, I'd use milli seconds since 1970-01-01
>> across
>> > the board. Otherwise it'll be more difficult to compare fields created
>> from
>> > properties of different date types.
>> >
>> > --Gunnar
>> >
>> >
>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>> >
>> >> Hi,
>> >> I started to work on the creation of the bridges for the classes in the
>> >> java.time package.
>> >>
>> >> I was wondering if we want to convert the values to long using the
>> existing
>> >> approach we have now for java.util.Date.
>> >>
>> >> In Hibernate Search a java.util.Date is converted into a long that
>> >> represents the number of milliseconds since January 1, 1970, 00:00:00
>> GMT
>> >> using getTime().
>> >>
>> >> The same value can be obtain from a java.time.LocaDate via:
>> >>
>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>> >> ).toInstant().toEpochMilli();
>> >>
>> >> LocalDate has a method that returns the same value expressed in number
>> of
>> >> days:
>> >>
>> >>         long epochDay = date.toEpochDay();
>> >>
>> >>
>> >> I would use the second approach
>> >>
>> >> Davide
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From davide at hibernate.org  Wed Aug  5 10:42:08 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 5 Aug 2015 15:42:08 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
Message-ID: <CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>

If a user select a resolution that does not make much sense we can log a
warning.

But I think this might make sense:

   @DateBridge(resolution=MONTH)
   LocalDate birthday;


On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org> wrote:

> > What would you do though in case of the following:
> >
> >   @DateBridge
> >    LocalDate myDate;
> >
> > encoding() defaults to NUMERIC, so would you a) raise an error, or b)
> ignore encoding() for LocalDate and friends? Both seem not right to me. I
> think there is nothing wrong with using NUMERIC encoding per-se for these
> types. We may recommend STRING but if NUMERIC really is what a user wants I
> would let them do so.
>
> +1
>
> > What do you suggest we do if a user maps the following?
>
> >   @DateBridge(resolution=MILLISECOND)
> >   LocalDate birthday;
>
>
> Nothing really,
> I would just consider a LocalDate the same as a LocalDateTime with time
> 00:00:000 (UTC time zone)
>
> It is equivalent to:
> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>>
>>
>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>>> Our current implementation converts Date in the long "distance from
>>> epoch" to allow correct range-queries treating each Date as an instant
>>> in time - allowing a universal sorting strategy. But a LocalDate is
>>> not an instant-in-time.
>>>
>>> A LocalDate is intentionally oblivious of the timezone; as the javadoc
>>> states, it's useful for birthdays, i.e. symbolic occurrences and
>>> potentially legal matters which don't fit into a universal sorting
>>> model but rather with the local political scene - we would need the
>>> combo {LocalDate, ZoneId} provided to be able to allow sorting across
>>> different LocalDate - or simply assume that they are all referring to
>>> the same Zone.
>>>
>>
>> Right, I had the latter in mind and would use UTC for that purpose.
>>
>>>
>>> I think that if the user is using a LocalDate type, he's implicitly
>>> hinting that the timezone is not relevant for the practical use
>>> (possibly even wrong); the most faithful representation would be the
>>> string form in ISO standard format or to encode the day,month,year as
>>> independent fields? This last detail depends on how it would be more
>>> efficient to store & query; probably the String format YYYYMMDD would
>>> be the most efficient internal representation to allow also correct
>>> sorting.
>>>
>>> I wouldn't use NumericField(s) in this case, as they are more
>>> effective only with larger ranges, while MM and DD are very short; not
>>> sure if it's worth splitting the year as a NumericField either, as the
>>> values will likely be strongly clustered in the same range of "recent
>>> years" - although that might depend on the application but it doesn't
>>> seem worth the complexity, so I'd index & store as a String YYYYMMDD.
>>>
>>
>> Agreed that this makes most sense, given the "symbolic" nature of
>> LocalDate.
>>
>> What would you do though in case of the following:
>>
>>     @DateBridge
>>     LocalDate myDate;
>>
>> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
>> ignore encoding() for LocalDate and friends? Both seem not right to me. I
>> think there is nothing wrong with using NUMERIC encoding per-se for these
>> types. We may recommend STRING but if NUMERIC really is what a user wants I
>> would let them do so.
>>
>>>
>>> -- Sanne
>>>
>>>
>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> > Hi,
>>> >
>>> > What's the motivation for using a different representation in that
>>> case?
>>> >
>>> > For the sake of consistency, I'd use milli seconds since 1970-01-01
>>> across
>>> > the board. Otherwise it'll be more difficult to compare fields created
>>> from
>>> > properties of different date types.
>>> >
>>> > --Gunnar
>>> >
>>> >
>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>>> >
>>> >> Hi,
>>> >> I started to work on the creation of the bridges for the classes in
>>> the
>>> >> java.time package.
>>> >>
>>> >> I was wondering if we want to convert the values to long using the
>>> existing
>>> >> approach we have now for java.util.Date.
>>> >>
>>> >> In Hibernate Search a java.util.Date is converted into a long that
>>> >> represents the number of milliseconds since January 1, 1970, 00:00:00
>>> GMT
>>> >> using getTime().
>>> >>
>>> >> The same value can be obtain from a java.time.LocaDate via:
>>> >>
>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>>> >> ).toInstant().toEpochMilli();
>>> >>
>>> >> LocalDate has a method that returns the same value expressed in
>>> number of
>>> >> days:
>>> >>
>>> >>         long epochDay = date.toEpochDay();
>>> >>
>>> >>
>>> >> I would use the second approach
>>> >>
>>> >> Davide
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From sanne at hibernate.org  Wed Aug  5 11:10:07 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 5 Aug 2015 16:10:07 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
Message-ID: <CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>

Inline:

On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org> wrote:
> If a user select a resolution that does not make much sense we can log a
> warning.

+1 And update the javadoc to mention that some resolution values don't apply

> But I think this might make sense:
>
>    @DateBridge(resolution=MONTH)
>    LocalDate birthday;

Ok but how often do you think that will be used?
Sorry playing devil's advocate here, as I'd like us to consider not
applying DateBridge on the new types as it doesn't seem to add much
practical value.

I agree it's worth a shot, but while going ahead keep in mind that
maybe simplifying that is the more elegant solution.

> On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org> wrote:
>
>> > What would you do though in case of the following:
>> >
>> >   @DateBridge
>> >    LocalDate myDate;
>> >
>> > encoding() defaults to NUMERIC, so would you a) raise an error, or b)
>> ignore encoding() for LocalDate and friends? Both seem not right to me. I
>> think there is nothing wrong with using NUMERIC encoding per-se for these
>> types. We may recommend STRING but if NUMERIC really is what a user wants I
>> would let them do so.

I'm all for letting the users have the last word, but this is one of
those cases in which you don't know if they explicitly want that or
simply went with the defaults.

Not a big problem as of course the important thing of defaults is that
"they work" but I'd really prefer the default to try be the most
appropriate encoding, which is not numeric in this case.

Proposal: use numeric but still - rather than taking the milliseconds
from epoch, take the resulting number from YYYYMMDD ? It might even be
the most efficient encoding, as you don't have the drawback of
clustering which we would have with a numeric encoding working on the
individual fields, and doesn't have the bloat of string encoding.

>>
>> +1
>>
>> > What do you suggest we do if a user maps the following?
>>
>> >   @DateBridge(resolution=MILLISECOND)
>> >   LocalDate birthday;
>>
>>
>> Nothing really,
>> I would just consider a LocalDate the same as a LocalDateTime with time
>> 00:00:000 (UTC time zone)

Ok that works but why write all those zeros in the index, when you can
just write the date. I realize storage is cheap, but still we need to
be careful as the index size affects performance ;-)

Sanne

>>
>> It is equivalent to:
>> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>>
>>>
>>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>>> Our current implementation converts Date in the long "distance from
>>>> epoch" to allow correct range-queries treating each Date as an instant
>>>> in time - allowing a universal sorting strategy. But a LocalDate is
>>>> not an instant-in-time.
>>>>
>>>> A LocalDate is intentionally oblivious of the timezone; as the javadoc
>>>> states, it's useful for birthdays, i.e. symbolic occurrences and
>>>> potentially legal matters which don't fit into a universal sorting
>>>> model but rather with the local political scene - we would need the
>>>> combo {LocalDate, ZoneId} provided to be able to allow sorting across
>>>> different LocalDate - or simply assume that they are all referring to
>>>> the same Zone.
>>>>
>>>
>>> Right, I had the latter in mind and would use UTC for that purpose.
>>>
>>>>
>>>> I think that if the user is using a LocalDate type, he's implicitly
>>>> hinting that the timezone is not relevant for the practical use
>>>> (possibly even wrong); the most faithful representation would be the
>>>> string form in ISO standard format or to encode the day,month,year as
>>>> independent fields? This last detail depends on how it would be more
>>>> efficient to store & query; probably the String format YYYYMMDD would
>>>> be the most efficient internal representation to allow also correct
>>>> sorting.
>>>>
>>>> I wouldn't use NumericField(s) in this case, as they are more
>>>> effective only with larger ranges, while MM and DD are very short; not
>>>> sure if it's worth splitting the year as a NumericField either, as the
>>>> values will likely be strongly clustered in the same range of "recent
>>>> years" - although that might depend on the application but it doesn't
>>>> seem worth the complexity, so I'd index & store as a String YYYYMMDD.
>>>>
>>>
>>> Agreed that this makes most sense, given the "symbolic" nature of
>>> LocalDate.
>>>
>>> What would you do though in case of the following:
>>>
>>>     @DateBridge
>>>     LocalDate myDate;
>>>
>>> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
>>> ignore encoding() for LocalDate and friends? Both seem not right to me. I
>>> think there is nothing wrong with using NUMERIC encoding per-se for these
>>> types. We may recommend STRING but if NUMERIC really is what a user wants I
>>> would let them do so.
>>>
>>>>
>>>> -- Sanne
>>>>
>>>>
>>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> > Hi,
>>>> >
>>>> > What's the motivation for using a different representation in that
>>>> case?
>>>> >
>>>> > For the sake of consistency, I'd use milli seconds since 1970-01-01
>>>> across
>>>> > the board. Otherwise it'll be more difficult to compare fields created
>>>> from
>>>> > properties of different date types.
>>>> >
>>>> > --Gunnar
>>>> >
>>>> >
>>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>>>> >
>>>> >> Hi,
>>>> >> I started to work on the creation of the bridges for the classes in
>>>> the
>>>> >> java.time package.
>>>> >>
>>>> >> I was wondering if we want to convert the values to long using the
>>>> existing
>>>> >> approach we have now for java.util.Date.
>>>> >>
>>>> >> In Hibernate Search a java.util.Date is converted into a long that
>>>> >> represents the number of milliseconds since January 1, 1970, 00:00:00
>>>> GMT
>>>> >> using getTime().
>>>> >>
>>>> >> The same value can be obtain from a java.time.LocaDate via:
>>>> >>
>>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>>>> >> ).toInstant().toEpochMilli();
>>>> >>
>>>> >> LocalDate has a method that returns the same value expressed in
>>>> number of
>>>> >> days:
>>>> >>
>>>> >>         long epochDay = date.toEpochDay();
>>>> >>
>>>> >>
>>>> >> I would use the second approach
>>>> >>
>>>> >> Davide
>>>> >> _______________________________________________
>>>> >> hibernate-dev mailing list
>>>> >> hibernate-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >>
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Aug  5 11:27:24 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 5 Aug 2015 17:27:24 +0200
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
Message-ID: <CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>

> as I'd like us to consider not
applying DateBridge on the new types as it doesn't seem to add much
practical value.

Ok, that may make sense for types such as LocalDate. But there are types in
the new API which - unlike LocalDate - do describe an exact instant on the
time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for
sure to support both encodings, NUMERIC and STRING (similar to
Date/Calendar so far) and thus apply @DateBridge.

Question is whether/how to index/persist TZ information, for Calendar it
seems not been persisted in the index so far?


2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Inline:
>
> On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org> wrote:
> > If a user select a resolution that does not make much sense we can log a
> > warning.
>
> +1 And update the javadoc to mention that some resolution values don't
> apply
>
> > But I think this might make sense:
> >
> >    @DateBridge(resolution=MONTH)
> >    LocalDate birthday;
>
> Ok but how often do you think that will be used?
> Sorry playing devil's advocate here, as I'd like us to consider not
> applying DateBridge on the new types as it doesn't seem to add much
> practical value.
>
> I agree it's worth a shot, but while going ahead keep in mind that
> maybe simplifying that is the more elegant solution.
>
> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org>
> wrote:
> >
> >> > What would you do though in case of the following:
> >> >
> >> >   @DateBridge
> >> >    LocalDate myDate;
> >> >
> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or b)
> >> ignore encoding() for LocalDate and friends? Both seem not right to me.
> I
> >> think there is nothing wrong with using NUMERIC encoding per-se for
> these
> >> types. We may recommend STRING but if NUMERIC really is what a user
> wants I
> >> would let them do so.
>
> I'm all for letting the users have the last word, but this is one of
> those cases in which you don't know if they explicitly want that or
> simply went with the defaults.
>
> Not a big problem as of course the important thing of defaults is that
> "they work" but I'd really prefer the default to try be the most
> appropriate encoding, which is not numeric in this case.
>
> Proposal: use numeric but still - rather than taking the milliseconds
> from epoch, take the resulting number from YYYYMMDD ? It might even be
> the most efficient encoding, as you don't have the drawback of
> clustering which we would have with a numeric encoding working on the
> individual fields, and doesn't have the bloat of string encoding.
>
> >>
> >> +1
> >>
> >> > What do you suggest we do if a user maps the following?
> >>
> >> >   @DateBridge(resolution=MILLISECOND)
> >> >   LocalDate birthday;
> >>
> >>
> >> Nothing really,
> >> I would just consider a LocalDate the same as a LocalDateTime with time
> >> 00:00:000 (UTC time zone)
>
> Ok that works but why write all those zeros in the index, when you can
> just write the date. I realize storage is cheap, but still we need to
> be careful as the index size affects performance ;-)
>
> Sanne
>
> >>
> >> It is equivalent to:
> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >>
> >>>
> >>>
> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>>
> >>>> Our current implementation converts Date in the long "distance from
> >>>> epoch" to allow correct range-queries treating each Date as an instant
> >>>> in time - allowing a universal sorting strategy. But a LocalDate is
> >>>> not an instant-in-time.
> >>>>
> >>>> A LocalDate is intentionally oblivious of the timezone; as the javadoc
> >>>> states, it's useful for birthdays, i.e. symbolic occurrences and
> >>>> potentially legal matters which don't fit into a universal sorting
> >>>> model but rather with the local political scene - we would need the
> >>>> combo {LocalDate, ZoneId} provided to be able to allow sorting across
> >>>> different LocalDate - or simply assume that they are all referring to
> >>>> the same Zone.
> >>>>
> >>>
> >>> Right, I had the latter in mind and would use UTC for that purpose.
> >>>
> >>>>
> >>>> I think that if the user is using a LocalDate type, he's implicitly
> >>>> hinting that the timezone is not relevant for the practical use
> >>>> (possibly even wrong); the most faithful representation would be the
> >>>> string form in ISO standard format or to encode the day,month,year as
> >>>> independent fields? This last detail depends on how it would be more
> >>>> efficient to store & query; probably the String format YYYYMMDD would
> >>>> be the most efficient internal representation to allow also correct
> >>>> sorting.
> >>>>
> >>>> I wouldn't use NumericField(s) in this case, as they are more
> >>>> effective only with larger ranges, while MM and DD are very short; not
> >>>> sure if it's worth splitting the year as a NumericField either, as the
> >>>> values will likely be strongly clustered in the same range of "recent
> >>>> years" - although that might depend on the application but it doesn't
> >>>> seem worth the complexity, so I'd index & store as a String YYYYMMDD.
> >>>>
> >>>
> >>> Agreed that this makes most sense, given the "symbolic" nature of
> >>> LocalDate.
> >>>
> >>> What would you do though in case of the following:
> >>>
> >>>     @DateBridge
> >>>     LocalDate myDate;
> >>>
> >>> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
> >>> ignore encoding() for LocalDate and friends? Both seem not right to
> me. I
> >>> think there is nothing wrong with using NUMERIC encoding per-se for
> these
> >>> types. We may recommend STRING but if NUMERIC really is what a user
> wants I
> >>> would let them do so.
> >>>
> >>>>
> >>>> -- Sanne
> >>>>
> >>>>
> >>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>>> > Hi,
> >>>> >
> >>>> > What's the motivation for using a different representation in that
> >>>> case?
> >>>> >
> >>>> > For the sake of consistency, I'd use milli seconds since 1970-01-01
> >>>> across
> >>>> > the board. Otherwise it'll be more difficult to compare fields
> created
> >>>> from
> >>>> > properties of different date types.
> >>>> >
> >>>> > --Gunnar
> >>>> >
> >>>> >
> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
> >>>> >
> >>>> >> Hi,
> >>>> >> I started to work on the creation of the bridges for the classes in
> >>>> the
> >>>> >> java.time package.
> >>>> >>
> >>>> >> I was wondering if we want to convert the values to long using the
> >>>> existing
> >>>> >> approach we have now for java.util.Date.
> >>>> >>
> >>>> >> In Hibernate Search a java.util.Date is converted into a long that
> >>>> >> represents the number of milliseconds since January 1, 1970,
> 00:00:00
> >>>> GMT
> >>>> >> using getTime().
> >>>> >>
> >>>> >> The same value can be obtain from a java.time.LocaDate via:
> >>>> >>
> >>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
> >>>> >> ).toInstant().toEpochMilli();
> >>>> >>
> >>>> >> LocalDate has a method that returns the same value expressed in
> >>>> number of
> >>>> >> days:
> >>>> >>
> >>>> >>         long epochDay = date.toEpochDay();
> >>>> >>
> >>>> >>
> >>>> >> I would use the second approach
> >>>> >>
> >>>> >> Davide
> >>>> >> _______________________________________________
> >>>> >> hibernate-dev mailing list
> >>>> >> hibernate-dev at lists.jboss.org
> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>> >>
> >>>> > _______________________________________________
> >>>> > hibernate-dev mailing list
> >>>> > hibernate-dev at lists.jboss.org
> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> >>>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Aug  5 12:00:40 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 5 Aug 2015 17:00:40 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
Message-ID: <CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>

On 5 August 2015 at 16:27, Gunnar Morling <gunnar at hibernate.org> wrote:
>> as I'd like us to consider not
> applying DateBridge on the new types as it doesn't seem to add much
> practical value.
>
> Ok, that may make sense for types such as LocalDate. But there are types in
> the new API which - unlike LocalDate - do describe an exact instant on the
> time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for
> sure to support both encodings, NUMERIC and STRING (similar to Date/Calendar
> so far) and thus apply @DateBridge.

+1

> Question is whether/how to index/persist TZ information, for Calendar it
> seems not been persisted in the index so far?

It's encoding the Calendar's time as distance from epoch, which is a
neutral encoding so you don't need the TZ.

For the old style Date/Calendar types we always assumed the value was
a point-in-time, unless explicitly opting in for an alternative
encoding.
For example for the "birthday use case" a reasonable setting would
have been String encoding with resolution=DAY, although passing in a
Date instance having the right value (as in right timezone) would have
been user's responsibility.. we simply take the long it's storing and
index that with the requested resolution.

Sanne

>
>
> 2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Inline:
>>
>> On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org> wrote:
>> > If a user select a resolution that does not make much sense we can log a
>> > warning.
>>
>> +1 And update the javadoc to mention that some resolution values don't
>> apply
>>
>> > But I think this might make sense:
>> >
>> >    @DateBridge(resolution=MONTH)
>> >    LocalDate birthday;
>>
>> Ok but how often do you think that will be used?
>> Sorry playing devil's advocate here, as I'd like us to consider not
>> applying DateBridge on the new types as it doesn't seem to add much
>> practical value.
>>
>> I agree it's worth a shot, but while going ahead keep in mind that
>> maybe simplifying that is the more elegant solution.
>>
>> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org>
>> > wrote:
>> >
>> >> > What would you do though in case of the following:
>> >> >
>> >> >   @DateBridge
>> >> >    LocalDate myDate;
>> >> >
>> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or b)
>> >> ignore encoding() for LocalDate and friends? Both seem not right to me.
>> >> I
>> >> think there is nothing wrong with using NUMERIC encoding per-se for
>> >> these
>> >> types. We may recommend STRING but if NUMERIC really is what a user
>> >> wants I
>> >> would let them do so.
>>
>> I'm all for letting the users have the last word, but this is one of
>> those cases in which you don't know if they explicitly want that or
>> simply went with the defaults.
>>
>> Not a big problem as of course the important thing of defaults is that
>> "they work" but I'd really prefer the default to try be the most
>> appropriate encoding, which is not numeric in this case.
>>
>> Proposal: use numeric but still - rather than taking the milliseconds
>> from epoch, take the resulting number from YYYYMMDD ? It might even be
>> the most efficient encoding, as you don't have the drawback of
>> clustering which we would have with a numeric encoding working on the
>> individual fields, and doesn't have the bloat of string encoding.
>>
>> >>
>> >> +1
>> >>
>> >> > What do you suggest we do if a user maps the following?
>> >>
>> >> >   @DateBridge(resolution=MILLISECOND)
>> >> >   LocalDate birthday;
>> >>
>> >>
>> >> Nothing really,
>> >> I would just consider a LocalDate the same as a LocalDateTime with time
>> >> 00:00:000 (UTC time zone)
>>
>> Ok that works but why write all those zeros in the index, when you can
>> just write the date. I realize storage is cheap, but still we need to
>> be careful as the index size affects performance ;-)
>>
>> Sanne
>>
>> >>
>> >> It is equivalent to:
>> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >>
>> >>>
>> >>>
>> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>>
>> >>>> Our current implementation converts Date in the long "distance from
>> >>>> epoch" to allow correct range-queries treating each Date as an
>> >>>> instant
>> >>>> in time - allowing a universal sorting strategy. But a LocalDate is
>> >>>> not an instant-in-time.
>> >>>>
>> >>>> A LocalDate is intentionally oblivious of the timezone; as the
>> >>>> javadoc
>> >>>> states, it's useful for birthdays, i.e. symbolic occurrences and
>> >>>> potentially legal matters which don't fit into a universal sorting
>> >>>> model but rather with the local political scene - we would need the
>> >>>> combo {LocalDate, ZoneId} provided to be able to allow sorting across
>> >>>> different LocalDate - or simply assume that they are all referring to
>> >>>> the same Zone.
>> >>>>
>> >>>
>> >>> Right, I had the latter in mind and would use UTC for that purpose.
>> >>>
>> >>>>
>> >>>> I think that if the user is using a LocalDate type, he's implicitly
>> >>>> hinting that the timezone is not relevant for the practical use
>> >>>> (possibly even wrong); the most faithful representation would be the
>> >>>> string form in ISO standard format or to encode the day,month,year as
>> >>>> independent fields? This last detail depends on how it would be more
>> >>>> efficient to store & query; probably the String format YYYYMMDD would
>> >>>> be the most efficient internal representation to allow also correct
>> >>>> sorting.
>> >>>>
>> >>>> I wouldn't use NumericField(s) in this case, as they are more
>> >>>> effective only with larger ranges, while MM and DD are very short;
>> >>>> not
>> >>>> sure if it's worth splitting the year as a NumericField either, as
>> >>>> the
>> >>>> values will likely be strongly clustered in the same range of "recent
>> >>>> years" - although that might depend on the application but it doesn't
>> >>>> seem worth the complexity, so I'd index & store as a String YYYYMMDD.
>> >>>>
>> >>>
>> >>> Agreed that this makes most sense, given the "symbolic" nature of
>> >>> LocalDate.
>> >>>
>> >>> What would you do though in case of the following:
>> >>>
>> >>>     @DateBridge
>> >>>     LocalDate myDate;
>> >>>
>> >>> encoding() defaults to NUMERIC, so would you a) raise an error, or b)
>> >>> ignore encoding() for LocalDate and friends? Both seem not right to
>> >>> me. I
>> >>> think there is nothing wrong with using NUMERIC encoding per-se for
>> >>> these
>> >>> types. We may recommend STRING but if NUMERIC really is what a user
>> >>> wants I
>> >>> would let them do so.
>> >>>
>> >>>>
>> >>>> -- Sanne
>> >>>>
>> >>>>
>> >>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org>
>> >>>> wrote:
>> >>>> > Hi,
>> >>>> >
>> >>>> > What's the motivation for using a different representation in that
>> >>>> case?
>> >>>> >
>> >>>> > For the sake of consistency, I'd use milli seconds since 1970-01-01
>> >>>> across
>> >>>> > the board. Otherwise it'll be more difficult to compare fields
>> >>>> > created
>> >>>> from
>> >>>> > properties of different date types.
>> >>>> >
>> >>>> > --Gunnar
>> >>>> >
>> >>>> >
>> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>> >>>> >
>> >>>> >> Hi,
>> >>>> >> I started to work on the creation of the bridges for the classes
>> >>>> >> in
>> >>>> the
>> >>>> >> java.time package.
>> >>>> >>
>> >>>> >> I was wondering if we want to convert the values to long using the
>> >>>> existing
>> >>>> >> approach we have now for java.util.Date.
>> >>>> >>
>> >>>> >> In Hibernate Search a java.util.Date is converted into a long that
>> >>>> >> represents the number of milliseconds since January 1, 1970,
>> >>>> >> 00:00:00
>> >>>> GMT
>> >>>> >> using getTime().
>> >>>> >>
>> >>>> >> The same value can be obtain from a java.time.LocaDate via:
>> >>>> >>
>> >>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>> >>>> >> ).toInstant().toEpochMilli();
>> >>>> >>
>> >>>> >> LocalDate has a method that returns the same value expressed in
>> >>>> number of
>> >>>> >> days:
>> >>>> >>
>> >>>> >>         long epochDay = date.toEpochDay();
>> >>>> >>
>> >>>> >>
>> >>>> >> I would use the second approach
>> >>>> >>
>> >>>> >> Davide
>> >>>> >> _______________________________________________
>> >>>> >> hibernate-dev mailing list
>> >>>> >> hibernate-dev at lists.jboss.org
>> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>> >>
>> >>>> > _______________________________________________
>> >>>> > hibernate-dev mailing list
>> >>>> > hibernate-dev at lists.jboss.org
>> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>
>> >>>
>> >>>
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From davide at hibernate.org  Wed Aug  5 12:22:50 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 5 Aug 2015 17:22:50 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
Message-ID: <CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>

> Proposal: use numeric but still - rather than taking the milliseconds
> from epoch, take the resulting number from YYYYMMDD ?

I don't think I understand what you mean with "the resulting number from
YYYYMMDD".
Wouldn't be similar to get the number of days from epoch?

But basically, you are saying that I can use different numeric encoding for
different types. Isn't it?
So, for example:

java.util.Date, java.util.Calendar  and java.time.Instant,
java.time.LocalDateTime will use number of miliseconds from epoch
java.time.LocalDate: number of days from epoch
java.time.LocalTime: number of nanos in a day

> Ok that works but why write all those zeros in the index, when you can
> just write the date. I realize storage is cheap, but still we need to
> be careful as the index size affects performance ;-)

I don't think we need to store the 0s.
If I know the type of the field I already know the the time is 0.
Am I missing something?


On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 5 August 2015 at 16:27, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> as I'd like us to consider not
> > applying DateBridge on the new types as it doesn't seem to add much
> > practical value.
> >
> > Ok, that may make sense for types such as LocalDate. But there are types
> in
> > the new API which - unlike LocalDate - do describe an exact instant on
> the
> > time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for
> > sure to support both encodings, NUMERIC and STRING (similar to
> Date/Calendar
> > so far) and thus apply @DateBridge.
>
> +1
>
> > Question is whether/how to index/persist TZ information, for Calendar it
> > seems not been persisted in the index so far?
>
> It's encoding the Calendar's time as distance from epoch, which is a
> neutral encoding so you don't need the TZ.
>
> For the old style Date/Calendar types we always assumed the value was
> a point-in-time, unless explicitly opting in for an alternative
> encoding.
> For example for the "birthday use case" a reasonable setting would
> have been String encoding with resolution=DAY, although passing in a
> Date instance having the right value (as in right timezone) would have
> been user's responsibility.. we simply take the long it's storing and
> index that with the requested resolution.
>
> Sanne
>
> >
> >
> > 2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> Inline:
> >>
> >> On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org> wrote:
> >> > If a user select a resolution that does not make much sense we can
> log a
> >> > warning.
> >>
> >> +1 And update the javadoc to mention that some resolution values don't
> >> apply
> >>
> >> > But I think this might make sense:
> >> >
> >> >    @DateBridge(resolution=MONTH)
> >> >    LocalDate birthday;
> >>
> >> Ok but how often do you think that will be used?
> >> Sorry playing devil's advocate here, as I'd like us to consider not
> >> applying DateBridge on the new types as it doesn't seem to add much
> >> practical value.
> >>
> >> I agree it's worth a shot, but while going ahead keep in mind that
> >> maybe simplifying that is the more elegant solution.
> >>
> >> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org>
> >> > wrote:
> >> >
> >> >> > What would you do though in case of the following:
> >> >> >
> >> >> >   @DateBridge
> >> >> >    LocalDate myDate;
> >> >> >
> >> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or
> b)
> >> >> ignore encoding() for LocalDate and friends? Both seem not right to
> me.
> >> >> I
> >> >> think there is nothing wrong with using NUMERIC encoding per-se for
> >> >> these
> >> >> types. We may recommend STRING but if NUMERIC really is what a user
> >> >> wants I
> >> >> would let them do so.
> >>
> >> I'm all for letting the users have the last word, but this is one of
> >> those cases in which you don't know if they explicitly want that or
> >> simply went with the defaults.
> >>
> >> Not a big problem as of course the important thing of defaults is that
> >> "they work" but I'd really prefer the default to try be the most
> >> appropriate encoding, which is not numeric in this case.
> >>
> >> Proposal: use numeric but still - rather than taking the milliseconds
> >> from epoch, take the resulting number from YYYYMMDD ? It might even be
> >> the most efficient encoding, as you don't have the drawback of
> >> clustering which we would have with a numeric encoding working on the
> >> individual fields, and doesn't have the bloat of string encoding.
> >>
> >> >>
> >> >> +1
> >> >>
> >> >> > What do you suggest we do if a user maps the following?
> >> >>
> >> >> >   @DateBridge(resolution=MILLISECOND)
> >> >> >   LocalDate birthday;
> >> >>
> >> >>
> >> >> Nothing really,
> >> >> I would just consider a LocalDate the same as a LocalDateTime with
> time
> >> >> 00:00:000 (UTC time zone)
> >>
> >> Ok that works but why write all those zeros in the index, when you can
> >> just write the date. I realize storage is cheap, but still we need to
> >> be careful as the index size affects performance ;-)
> >>
> >> Sanne
> >>
> >> >>
> >> >> It is equivalent to:
> >> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org
> >
> >> >> wrote:
> >> >>
> >> >>>
> >> >>>
> >> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>>
> >> >>>> Our current implementation converts Date in the long "distance from
> >> >>>> epoch" to allow correct range-queries treating each Date as an
> >> >>>> instant
> >> >>>> in time - allowing a universal sorting strategy. But a LocalDate is
> >> >>>> not an instant-in-time.
> >> >>>>
> >> >>>> A LocalDate is intentionally oblivious of the timezone; as the
> >> >>>> javadoc
> >> >>>> states, it's useful for birthdays, i.e. symbolic occurrences and
> >> >>>> potentially legal matters which don't fit into a universal sorting
> >> >>>> model but rather with the local political scene - we would need the
> >> >>>> combo {LocalDate, ZoneId} provided to be able to allow sorting
> across
> >> >>>> different LocalDate - or simply assume that they are all referring
> to
> >> >>>> the same Zone.
> >> >>>>
> >> >>>
> >> >>> Right, I had the latter in mind and would use UTC for that purpose.
> >> >>>
> >> >>>>
> >> >>>> I think that if the user is using a LocalDate type, he's implicitly
> >> >>>> hinting that the timezone is not relevant for the practical use
> >> >>>> (possibly even wrong); the most faithful representation would be
> the
> >> >>>> string form in ISO standard format or to encode the day,month,year
> as
> >> >>>> independent fields? This last detail depends on how it would be
> more
> >> >>>> efficient to store & query; probably the String format YYYYMMDD
> would
> >> >>>> be the most efficient internal representation to allow also correct
> >> >>>> sorting.
> >> >>>>
> >> >>>> I wouldn't use NumericField(s) in this case, as they are more
> >> >>>> effective only with larger ranges, while MM and DD are very short;
> >> >>>> not
> >> >>>> sure if it's worth splitting the year as a NumericField either, as
> >> >>>> the
> >> >>>> values will likely be strongly clustered in the same range of
> "recent
> >> >>>> years" - although that might depend on the application but it
> doesn't
> >> >>>> seem worth the complexity, so I'd index & store as a String
> YYYYMMDD.
> >> >>>>
> >> >>>
> >> >>> Agreed that this makes most sense, given the "symbolic" nature of
> >> >>> LocalDate.
> >> >>>
> >> >>> What would you do though in case of the following:
> >> >>>
> >> >>>     @DateBridge
> >> >>>     LocalDate myDate;
> >> >>>
> >> >>> encoding() defaults to NUMERIC, so would you a) raise an error, or
> b)
> >> >>> ignore encoding() for LocalDate and friends? Both seem not right to
> >> >>> me. I
> >> >>> think there is nothing wrong with using NUMERIC encoding per-se for
> >> >>> these
> >> >>> types. We may recommend STRING but if NUMERIC really is what a user
> >> >>> wants I
> >> >>> would let them do so.
> >> >>>
> >> >>>>
> >> >>>> -- Sanne
> >> >>>>
> >> >>>>
> >> >>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org>
> >> >>>> wrote:
> >> >>>> > Hi,
> >> >>>> >
> >> >>>> > What's the motivation for using a different representation in
> that
> >> >>>> case?
> >> >>>> >
> >> >>>> > For the sake of consistency, I'd use milli seconds since
> 1970-01-01
> >> >>>> across
> >> >>>> > the board. Otherwise it'll be more difficult to compare fields
> >> >>>> > created
> >> >>>> from
> >> >>>> > properties of different date types.
> >> >>>> >
> >> >>>> > --Gunnar
> >> >>>> >
> >> >>>> >
> >> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
> >> >>>> >
> >> >>>> >> Hi,
> >> >>>> >> I started to work on the creation of the bridges for the classes
> >> >>>> >> in
> >> >>>> the
> >> >>>> >> java.time package.
> >> >>>> >>
> >> >>>> >> I was wondering if we want to convert the values to long using
> the
> >> >>>> existing
> >> >>>> >> approach we have now for java.util.Date.
> >> >>>> >>
> >> >>>> >> In Hibernate Search a java.util.Date is converted into a long
> that
> >> >>>> >> represents the number of milliseconds since January 1, 1970,
> >> >>>> >> 00:00:00
> >> >>>> GMT
> >> >>>> >> using getTime().
> >> >>>> >>
> >> >>>> >> The same value can be obtain from a java.time.LocaDate via:
> >> >>>> >>
> >> >>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
> >> >>>> >> ).toInstant().toEpochMilli();
> >> >>>> >>
> >> >>>> >> LocalDate has a method that returns the same value expressed in
> >> >>>> number of
> >> >>>> >> days:
> >> >>>> >>
> >> >>>> >>         long epochDay = date.toEpochDay();
> >> >>>> >>
> >> >>>> >>
> >> >>>> >> I would use the second approach
> >> >>>> >>
> >> >>>> >> Davide
> >> >>>> >> _______________________________________________
> >> >>>> >> hibernate-dev mailing list
> >> >>>> >> hibernate-dev at lists.jboss.org
> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>>> >>
> >> >>>> > _______________________________________________
> >> >>>> > hibernate-dev mailing list
> >> >>>> > hibernate-dev at lists.jboss.org
> >> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Aug  5 12:40:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 5 Aug 2015 17:40:16 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
References: <CANoTJYMk4G5KY2rOA9WZXn-sEmRy1GyAWxGGzSvdY4k2Y6uJEQ@mail.gmail.com>
	<CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
	<CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
Message-ID: <CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>

On 5 August 2015 at 17:22, Davide D'Alto <davide at hibernate.org> wrote:
>> Proposal: use numeric but still - rather than taking the milliseconds
>> from epoch, take the resulting number from YYYYMMDD ?
>
> I don't think I understand what you mean with "the resulting number from
> YYYYMMDD".
> Wouldn't be similar to get the number of days from epoch?

No because epoch is a specific moment *with a timezone*. If you take a
calendar date "here", and take the moment in time which represents
your beginning of the calendar date, the distance from epoch is not a
whole number and you'd have to apply rounding which is timezone
specific.

By simply encoding the number in the above format, you'd encode today
as the number "20150805".
That's a whole number which avoids the timezone relativity and can be
efficiently encoded in numeric form, and provides the expected sorting
properties.

>
> But basically, you are saying that I can use different numeric encoding for
> different types. Isn't it?

Yes, you definitely need different encodings depending on the type and
the used options.

> So, for example:
>
> java.util.Date, java.util.Calendar  and java.time.Instant,
> java.time.LocalDateTime will use number of miliseconds from epoch
> java.time.LocalDate: number of days from epoch

Except this one ^ I agree with the others.

> java.time.LocalTime: number of nanos in a day

Conceptually, yes.. but we don't have "nanoseconds" as an option of
org.hibernate.search.annotations.Resolution. Should we add it?
We would not be able to apply that Resolution on old fashioned
Date/Calendar, so that would need a warning or even an exception when
applied to old style value types.

>> Ok that works but why write all those zeros in the index, when you can
>> just write the date. I realize storage is cheap, but still we need to
>> be careful as the index size affects performance ;-)
>
> I don't think we need to store the 0s.
> If I know the type of the field I already know the the time is 0.

Exactly

> Am I missing something?

I probably just misunderstood your proposal, since previously you
mentioned: "I would just consider a LocalDate the same as a
LocalDateTime with time 00:00:000 (UTC time zone)".
If you have to write the days only you don't need to convert to a time first.
This misunderstanding might be related with the fact that you were
planning to encode as distance from epoch.. see my first comment on
this same email.
Since you don't want to look at distance from epoch for this case, the
time component really is irrelevant and LocalDate has all the
information you need.. simpler ;)

Sanne


>
>
> On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> On 5 August 2015 at 16:27, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> as I'd like us to consider not
>> > applying DateBridge on the new types as it doesn't seem to add much
>> > practical value.
>> >
>> > Ok, that may make sense for types such as LocalDate. But there are types
>> in
>> > the new API which - unlike LocalDate - do describe an exact instant on
>> the
>> > time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for
>> > sure to support both encodings, NUMERIC and STRING (similar to
>> Date/Calendar
>> > so far) and thus apply @DateBridge.
>>
>> +1
>>
>> > Question is whether/how to index/persist TZ information, for Calendar it
>> > seems not been persisted in the index so far?
>>
>> It's encoding the Calendar's time as distance from epoch, which is a
>> neutral encoding so you don't need the TZ.
>>
>> For the old style Date/Calendar types we always assumed the value was
>> a point-in-time, unless explicitly opting in for an alternative
>> encoding.
>> For example for the "birthday use case" a reasonable setting would
>> have been String encoding with resolution=DAY, although passing in a
>> Date instance having the right value (as in right timezone) would have
>> been user's responsibility.. we simply take the long it's storing and
>> index that with the requested resolution.
>>
>> Sanne
>>
>> >
>> >
>> > 2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> Inline:
>> >>
>> >> On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org> wrote:
>> >> > If a user select a resolution that does not make much sense we can
>> log a
>> >> > warning.
>> >>
>> >> +1 And update the javadoc to mention that some resolution values don't
>> >> apply
>> >>
>> >> > But I think this might make sense:
>> >> >
>> >> >    @DateBridge(resolution=MONTH)
>> >> >    LocalDate birthday;
>> >>
>> >> Ok but how often do you think that will be used?
>> >> Sorry playing devil's advocate here, as I'd like us to consider not
>> >> applying DateBridge on the new types as it doesn't seem to add much
>> >> practical value.
>> >>
>> >> I agree it's worth a shot, but while going ahead keep in mind that
>> >> maybe simplifying that is the more elegant solution.
>> >>
>> >> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org>
>> >> > wrote:
>> >> >
>> >> >> > What would you do though in case of the following:
>> >> >> >
>> >> >> >   @DateBridge
>> >> >> >    LocalDate myDate;
>> >> >> >
>> >> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or
>> b)
>> >> >> ignore encoding() for LocalDate and friends? Both seem not right to
>> me.
>> >> >> I
>> >> >> think there is nothing wrong with using NUMERIC encoding per-se for
>> >> >> these
>> >> >> types. We may recommend STRING but if NUMERIC really is what a user
>> >> >> wants I
>> >> >> would let them do so.
>> >>
>> >> I'm all for letting the users have the last word, but this is one of
>> >> those cases in which you don't know if they explicitly want that or
>> >> simply went with the defaults.
>> >>
>> >> Not a big problem as of course the important thing of defaults is that
>> >> "they work" but I'd really prefer the default to try be the most
>> >> appropriate encoding, which is not numeric in this case.
>> >>
>> >> Proposal: use numeric but still - rather than taking the milliseconds
>> >> from epoch, take the resulting number from YYYYMMDD ? It might even be
>> >> the most efficient encoding, as you don't have the drawback of
>> >> clustering which we would have with a numeric encoding working on the
>> >> individual fields, and doesn't have the bloat of string encoding.
>> >>
>> >> >>
>> >> >> +1
>> >> >>
>> >> >> > What do you suggest we do if a user maps the following?
>> >> >>
>> >> >> >   @DateBridge(resolution=MILLISECOND)
>> >> >> >   LocalDate birthday;
>> >> >>
>> >> >>
>> >> >> Nothing really,
>> >> >> I would just consider a LocalDate the same as a LocalDateTime with
>> time
>> >> >> 00:00:000 (UTC time zone)
>> >>
>> >> Ok that works but why write all those zeros in the index, when you can
>> >> just write the date. I realize storage is cheap, but still we need to
>> >> be careful as the index size affects performance ;-)
>> >>
>> >> Sanne
>> >>
>> >> >>
>> >> >> It is equivalent to:
>> >> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org
>> >
>> >> >> wrote:
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> >>>
>> >> >>>> Our current implementation converts Date in the long "distance from
>> >> >>>> epoch" to allow correct range-queries treating each Date as an
>> >> >>>> instant
>> >> >>>> in time - allowing a universal sorting strategy. But a LocalDate is
>> >> >>>> not an instant-in-time.
>> >> >>>>
>> >> >>>> A LocalDate is intentionally oblivious of the timezone; as the
>> >> >>>> javadoc
>> >> >>>> states, it's useful for birthdays, i.e. symbolic occurrences and
>> >> >>>> potentially legal matters which don't fit into a universal sorting
>> >> >>>> model but rather with the local political scene - we would need the
>> >> >>>> combo {LocalDate, ZoneId} provided to be able to allow sorting
>> across
>> >> >>>> different LocalDate - or simply assume that they are all referring
>> to
>> >> >>>> the same Zone.
>> >> >>>>
>> >> >>>
>> >> >>> Right, I had the latter in mind and would use UTC for that purpose.
>> >> >>>
>> >> >>>>
>> >> >>>> I think that if the user is using a LocalDate type, he's implicitly
>> >> >>>> hinting that the timezone is not relevant for the practical use
>> >> >>>> (possibly even wrong); the most faithful representation would be
>> the
>> >> >>>> string form in ISO standard format or to encode the day,month,year
>> as
>> >> >>>> independent fields? This last detail depends on how it would be
>> more
>> >> >>>> efficient to store & query; probably the String format YYYYMMDD
>> would
>> >> >>>> be the most efficient internal representation to allow also correct
>> >> >>>> sorting.
>> >> >>>>
>> >> >>>> I wouldn't use NumericField(s) in this case, as they are more
>> >> >>>> effective only with larger ranges, while MM and DD are very short;
>> >> >>>> not
>> >> >>>> sure if it's worth splitting the year as a NumericField either, as
>> >> >>>> the
>> >> >>>> values will likely be strongly clustered in the same range of
>> "recent
>> >> >>>> years" - although that might depend on the application but it
>> doesn't
>> >> >>>> seem worth the complexity, so I'd index & store as a String
>> YYYYMMDD.
>> >> >>>>
>> >> >>>
>> >> >>> Agreed that this makes most sense, given the "symbolic" nature of
>> >> >>> LocalDate.
>> >> >>>
>> >> >>> What would you do though in case of the following:
>> >> >>>
>> >> >>>     @DateBridge
>> >> >>>     LocalDate myDate;
>> >> >>>
>> >> >>> encoding() defaults to NUMERIC, so would you a) raise an error, or
>> b)
>> >> >>> ignore encoding() for LocalDate and friends? Both seem not right to
>> >> >>> me. I
>> >> >>> think there is nothing wrong with using NUMERIC encoding per-se for
>> >> >>> these
>> >> >>> types. We may recommend STRING but if NUMERIC really is what a user
>> >> >>> wants I
>> >> >>> would let them do so.
>> >> >>>
>> >> >>>>
>> >> >>>> -- Sanne
>> >> >>>>
>> >> >>>>
>> >> >>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org>
>> >> >>>> wrote:
>> >> >>>> > Hi,
>> >> >>>> >
>> >> >>>> > What's the motivation for using a different representation in
>> that
>> >> >>>> case?
>> >> >>>> >
>> >> >>>> > For the sake of consistency, I'd use milli seconds since
>> 1970-01-01
>> >> >>>> across
>> >> >>>> > the board. Otherwise it'll be more difficult to compare fields
>> >> >>>> > created
>> >> >>>> from
>> >> >>>> > properties of different date types.
>> >> >>>> >
>> >> >>>> > --Gunnar
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>> >> >>>> >
>> >> >>>> >> Hi,
>> >> >>>> >> I started to work on the creation of the bridges for the classes
>> >> >>>> >> in
>> >> >>>> the
>> >> >>>> >> java.time package.
>> >> >>>> >>
>> >> >>>> >> I was wondering if we want to convert the values to long using
>> the
>> >> >>>> existing
>> >> >>>> >> approach we have now for java.util.Date.
>> >> >>>> >>
>> >> >>>> >> In Hibernate Search a java.util.Date is converted into a long
>> that
>> >> >>>> >> represents the number of milliseconds since January 1, 1970,
>> >> >>>> >> 00:00:00
>> >> >>>> GMT
>> >> >>>> >> using getTime().
>> >> >>>> >>
>> >> >>>> >> The same value can be obtain from a java.time.LocaDate via:
>> >> >>>> >>
>> >> >>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>> >> >>>> >> ).toInstant().toEpochMilli();
>> >> >>>> >>
>> >> >>>> >> LocalDate has a method that returns the same value expressed in
>> >> >>>> number of
>> >> >>>> >> days:
>> >> >>>> >>
>> >> >>>> >>         long epochDay = date.toEpochDay();
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >> I would use the second approach
>> >> >>>> >>
>> >> >>>> >> Davide
>> >> >>>> >> _______________________________________________
>> >> >>>> >> hibernate-dev mailing list
>> >> >>>> >> hibernate-dev at lists.jboss.org
>> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >>>> >>
>> >> >>>> > _______________________________________________
>> >> >>>> > hibernate-dev mailing list
>> >> >>>> > hibernate-dev at lists.jboss.org
>> >> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From flemming.harms at gmail.com  Wed Aug  5 15:05:57 2015
From: flemming.harms at gmail.com (Flemming Harms)
Date: Wed, 5 Aug 2015 21:05:57 +0200
Subject: [hibernate-dev] [Hibernate Search] Database back end worker
In-Reply-To: <14efd4b452c-7fae-3686d@webprd-m59.mail.aol.com>
References: <CAFP3+ykfZk77_VU2nByfFkaY43nA7KG06kbb4ZZ+dKVKJ3LBgA@mail.gmail.com>
	<14efd4b452c-7fae-3686d@webprd-m59.mail.aol.com>
Message-ID: <CAFP3+ymhTwU+T=o+cnsV6kHhh5cpL27HWh2S6AFQsxALYEXCQQ@mail.gmail.com>

Hi Martin

For this version the AbstractDatabaseHibernateSearchController is not able
to process Lucene workers simultaneously. When we build it our initial
requirement was only one node should process the workers at a time, but the
?master? was floating. We use Quartz to get this type of functionality and
it will synchronizing the execution between the nodes. But you could also
use an HA-singleton to dedicate a specific node to process the workers.

We had been playing with an idea where we stamp the LuceneDatabaseWork with
the known cluster nodes, and then the last node will remove it from the
database or a scheduled job can take care of it. The advance of this
solution is it will make Infinispan optional, and it can store the indexes
on each node instead in a shared cache.

Your idea and work look very nice. Pretty awesome feature to support
different JPA providers.

-- 
cheers
Flemming


2015-08-05 11:57 GMT+02:00 Martin Braun <martinbraun123 at aol.com>:

> Hi,
>
>
> Note: I am no core developer of Hibernate Search, but I am currently
> working on something
> that looks quite similar to what you are doing :). One part of it is an
> updating mechanism based on triggers
> that uses the database as a event-storage as well. It's not the exact same
> thing, but related.
>
>
> https://github.com/Hotware/Hibernate-Search-JPA
>
>
>
> The idea is quite nice, but after looking at the sourcecode I am wondering
> how the different nodes are able to work together, because in
> AbstractDatabaseHibernateSearchController you remove the entity
> from the persistence context and I wasn't able to find code that would
> make up for that.
>
>
> Doesn't that mean that the other workers will not be able to read that
> entity?
> Or will users of this need to implement their own synchronization
> mechanism between
> the different nodes?
>
>
> Martin Braun
> martinbraun123 at aol.com
> www.github.com/s4ke
>
>
>
>
> -----Original Message-----
> From: Flemming Harms <flemming.harms at gmail.com>
> To: Hibernate.org <hibernate-dev at lists.jboss.org>
> Sent: Tue, Aug 4, 2015 6:40 pm
> Subject: [hibernate-dev] [Hibernate Search] Database back end worker
>
>
> Hey guys
>
> I want to introduce myself and a new database back-end worker, me
> and
> another guy have build for hibernate search. I already had some initial
> talk
> with Sanne regarding if this could be interested to the hibernate
> search
> project.
>
> I have been working with Hibernate Search from some time and actually
> done
> various small custom modification to search since 3.x, especial
> around
> running in a cluster and indexing. To make a long story short when
> we
> upgraded Hibernate search we thought it would be ideal to use a SQL
> database
> as storage for lucene workers for 3 main reasons.
>
> - The database was shared
> between the nodes
> - The workers was persistent in case of a node crash.
> - No
> master/slave
>
>
> *In some way it?s very similar to the JMS back-end worker, where
> the user
> also have to implement a MDB that process the workers. In our case
> they
> will have to implement a job using something like quartz or a
> timer
> service. *
>
> *We are using JPA as persistence layer for the database, even
> it?s a fairly
> simple entity we persistent, but it make sense for supporting
> various
> databases and schema update out of the box. We have tried to make it?s
> as
> easy as possible to set-up by minimizing the number of properties, and
> it?s
> all configurable from the persistence.xml*
>
> *The actually work can* be
> *find
> here
> https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
> <https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend>*
>
>
>
> *So
> based on this introduction and the code, is this something you could
> use? (of
> course with the modification it requires to follow the design,
> style, docs etc
> for the search)*--
>
> Kind regards
> Flemming
> Harms
> _______________________________________________
> hibernate-dev mailing
> list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev




-- 

Kind regards / Med Venlig Hilsen
Flemming Harms

   -

https://twitter.com/fnharms
https://dk.linkedin.com/in/fharms

From steve at hibernate.org  Wed Aug  5 17:28:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 05 Aug 2015 21:28:29 +0000
Subject: [hibernate-dev] Fourth Candidate Release for ORM 5.0
Message-ID: <CAFdSV9uPs76wivV30nXYsJMJMgZgu3nWDp8=H92Jw-OrrguKcA@mail.gmail.com>

http://in.relation.to/2015/08/05/hibernate-orm-500-cr4-release/

Mainly changes in the defaults for some settings in prep for Final

From sanne at hibernate.org  Wed Aug  5 17:38:43 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 5 Aug 2015 22:38:43 +0100
Subject: [hibernate-dev] [Hibernate Search] Database back end worker
In-Reply-To: <CAFP3+ymhTwU+T=o+cnsV6kHhh5cpL27HWh2S6AFQsxALYEXCQQ@mail.gmail.com>
References: <CAFP3+ykfZk77_VU2nByfFkaY43nA7KG06kbb4ZZ+dKVKJ3LBgA@mail.gmail.com>
	<14efd4b452c-7fae-3686d@webprd-m59.mail.aol.com>
	<CAFP3+ymhTwU+T=o+cnsV6kHhh5cpL27HWh2S6AFQsxALYEXCQQ@mail.gmail.com>
Message-ID: <CAFm4XO2a0gKu2nrOG6_hynA7hXRa+L0xvM4x9GSqmO_wERKKEA@mail.gmail.com>

Hi Flemming,
welcome on this list!

I waited a bit to reply myself, as you already know I like the
proposal. Unfortunately many others are on holidays, so other feedback
might be slow.

Still I wouldn't let that slow you down and start the works for
merging it; I already anticipated over chat that this would come and
we all agree that the concept is useful!
I don't think others looked at the details yet, but if it comes to
concerns at that level, we can address smaller issues incrementally.
(I also didn't look at micro-details, as it's easier to comment on
those on a pull request).

I had the same question as Martin regarding clustering: with the
current implementation you expect something like the master/slave
configuration, or Infinispan to be used as storage, correct?
I also think it would be interesting to explore the approach further
to also - optionally - serve as a replacement for these, but that's
another feature which is easier to experiment with after the core
concept is merged.

In short, I would simply merge your backend as a new module in
Hibernate Search! Fork our repository, and send a pull request.

# Code layout / Modules

In terms of code structure, you might have noticed that the module
'hibernate-search-engine' (/engine in the source code) does not depend
on JPA nor Hibernate ORM; the reason is that other projects reuse the
core indexing strategy and the backends. Since it would be nice to
allow them to optionally use your backend, still not mandate a
dependency on ORM for those who don't, I think this should be a new
Maven module.

We already have
 /backends/jgroups
 /backends/jms

So we could add (name to be refined?) :
 /backends/relationaldb

Also, your integration tests probably should be moved together with
our other integration tests. They are currently running WildFly
10.0.0.Alpha6, but that shouldn't be a problem.

# Code Style

We use tabs ;-)
And also have various other "exotic" conventions regarding white-space
usage, right header files, etc..
We use CheckStyle to keep it tidy, it will give you lots of errors and
when there are many it's not very helpful; I would suggest to take the
formatting templates attached at the following link and use your IDE's
formatting capabilities, resort to checkstyle just for the final
validation:
 - http://hibernate.org/search/contribute/

# JDK

It looks like your extension requires Java 8; if you could convert it
to Java 7 that would be nice.

# Rebasing to latest

I'm afraid we're now aiming at Hibernate ORM 5, so some details might
need to be updated; probably just in the configuration area. We're
also in the process of upgrading to Apache Lucene 5, but that
shouldn't affect you at all.

# Some improvement ideas

While we should support the case in which Hibernate Search is not
being run as an extension of Hibernate ORM, that's likely the most
common one.
In that scenario I think it would be nice to be able to lookup the
existing ORM services so that users don't need to repeat for example
the datasource configuration.

We might also be able to reuse all of the SessionFactory, but I'm not
sure how to include your model without it potentially interfering with
the end user's model; I'd say let's start by sharing some services
from ORM and then see what kind of improvements we can build into ORM
for this use case; for example this might simplify some of the
TransactionManager configuration code I'm seeing in your repository.

Of course your existing configuration properties are useful too,
especially for the non-ORM case as we'll need be able to reuse the ORM
services.

Also, you might have noticed we are now able to optionally include the
backend operations in the same transaction. That's not the default, as
commonly people don't want that, but it would be very interesting to
evolve this backend to support that option too, you wouldn't even
require XA when storing the entity in the same database!
 - http://in.relation.to/2015/07/09/hibernate-search-jms-transaction/

I'd be happy to help with this, feel free to share non-working and/or
intermediate experimental branches when having questions or just
stuck.
Please start by creating a JIRA, you can leave the target version
undefined: we'll merge it when it's ready.

Thanks,
Sanne


On 5 August 2015 at 20:05, Flemming Harms <flemming.harms at gmail.com> wrote:
> Hi Martin
>
> For this version the AbstractDatabaseHibernateSearchController is not able
> to process Lucene workers simultaneously. When we build it our initial
> requirement was only one node should process the workers at a time, but the
> ?master? was floating. We use Quartz to get this type of functionality and
> it will synchronizing the execution between the nodes. But you could also
> use an HA-singleton to dedicate a specific node to process the workers.
>
> We had been playing with an idea where we stamp the LuceneDatabaseWork with
> the known cluster nodes, and then the last node will remove it from the
> database or a scheduled job can take care of it. The advance of this
> solution is it will make Infinispan optional, and it can store the indexes
> on each node instead in a shared cache.
>
> Your idea and work look very nice. Pretty awesome feature to support
> different JPA providers.
>
> --
> cheers
> Flemming
>
>
> 2015-08-05 11:57 GMT+02:00 Martin Braun <martinbraun123 at aol.com>:
>
>> Hi,
>>
>>
>> Note: I am no core developer of Hibernate Search, but I am currently
>> working on something
>> that looks quite similar to what you are doing :). One part of it is an
>> updating mechanism based on triggers
>> that uses the database as a event-storage as well. It's not the exact same
>> thing, but related.
>>
>>
>> https://github.com/Hotware/Hibernate-Search-JPA
>>
>>
>>
>> The idea is quite nice, but after looking at the sourcecode I am wondering
>> how the different nodes are able to work together, because in
>> AbstractDatabaseHibernateSearchController you remove the entity
>> from the persistence context and I wasn't able to find code that would
>> make up for that.
>>
>>
>> Doesn't that mean that the other workers will not be able to read that
>> entity?
>> Or will users of this need to implement their own synchronization
>> mechanism between
>> the different nodes?
>>
>>
>> Martin Braun
>> martinbraun123 at aol.com
>> www.github.com/s4ke
>>
>>
>>
>>
>> -----Original Message-----
>> From: Flemming Harms <flemming.harms at gmail.com>
>> To: Hibernate.org <hibernate-dev at lists.jboss.org>
>> Sent: Tue, Aug 4, 2015 6:40 pm
>> Subject: [hibernate-dev] [Hibernate Search] Database back end worker
>>
>>
>> Hey guys
>>
>> I want to introduce myself and a new database back-end worker, me
>> and
>> another guy have build for hibernate search. I already had some initial
>> talk
>> with Sanne regarding if this could be interested to the hibernate
>> search
>> project.
>>
>> I have been working with Hibernate Search from some time and actually
>> done
>> various small custom modification to search since 3.x, especial
>> around
>> running in a cluster and indexing. To make a long story short when
>> we
>> upgraded Hibernate search we thought it would be ideal to use a SQL
>> database
>> as storage for lucene workers for 3 main reasons.
>>
>> - The database was shared
>> between the nodes
>> - The workers was persistent in case of a node crash.
>> - No
>> master/slave
>>
>>
>> *In some way it?s very similar to the JMS back-end worker, where
>> the user
>> also have to implement a MDB that process the workers. In our case
>> they
>> will have to implement a job using something like quartz or a
>> timer
>> service. *
>>
>> *We are using JPA as persistence layer for the database, even
>> it?s a fairly
>> simple entity we persistent, but it make sense for supporting
>> various
>> databases and schema update out of the box. We have tried to make it?s
>> as
>> easy as possible to set-up by minimizing the number of properties, and
>> it?s
>> all configurable from the persistence.xml*
>>
>> *The actually work can* be
>> *find
>> here
>> https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
>> <https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend>*
>>
>>
>>
>> *So
>> based on this introduction and the code, is this something you could
>> use? (of
>> course with the modification it requires to follow the design,
>> style, docs etc
>> for the search)*--
>>
>> Kind regards
>> Flemming
>> Harms
>> _______________________________________________
>> hibernate-dev mailing
>> list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
>
> --
>
> Kind regards / Med Venlig Hilsen
> Flemming Harms
>
>    -
>
> https://twitter.com/fnharms
> https://dk.linkedin.com/in/fharms
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gbadner at redhat.com  Wed Aug  5 23:23:12 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 5 Aug 2015 20:23:12 -0700
Subject: [hibernate-dev] Preparing to release 4.3.11.Final
Message-ID: <CAFDzhiThv4wN77Rphj2dngYe18d=actcmiXfB-sYZPYzYOLM8Q@mail.gmail.com>

Please don't push anything to 4.3 branch until I'm finished with the
release.
Thanks,
Gail

From gbadner at redhat.com  Thu Aug  6 01:10:45 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 5 Aug 2015 22:10:45 -0700
Subject: [hibernate-dev] Finished with 4.3.11.Final release
Message-ID: <CAFDzhiRhcgtr9njwVe173PO0-jC_bNysFLPfgCALYDnezjevPw@mail.gmail.com>

I will blog and send out announcements on Thursday.

From sanne at hibernate.org  Fri Aug  7 08:14:27 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 7 Aug 2015 13:14:27 +0100
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
 new mapping annotations ?
In-Reply-To: <CADGJaX9+wnnhLuLim8AY=qS2bvPq_5r=pr-h99Q2dXZDOTOeMw@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
	<CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
	<CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>
	<CADGJaX9+wnnhLuLim8AY=qS2bvPq_5r=pr-h99Q2dXZDOTOeMw@mail.gmail.com>
Message-ID: <CAFm4XO3bC-j7r1i3HMJ==T9NFr-oYweYOSxEn3nxtY8KQU6qHg@mail.gmail.com>

A quick update on some more exploration on this:
it turns out sorting on a NumericField when this field is also using
an "indexNullAs" token gets the UninvertingReader approach to throw an
exception.
My two conclusions:
 - we need to move away from supporting those tokens in NumericField,
especially as stricter schema is coming in next gen Lucene
 - yet another reason to clearly separate fields meant for searching vs sorting

-- Sanne

On 5 August 2015 at 10:41, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> I think a great solution for that would be to leverage "annotation
> composition" as done e.g. in CDI and Bean Validation.
>
> There would be an annotation @DocValuesField which will cause the creation
> of a DocValues and which would expose attributes required for its
> configuration:
>
>     @DocValuesField(name="foo", ... )
>     private String bar;
>
> Besides using @DocValuesField itself directly, it would be usable as a
> meta-annotation on "doc value annotation types":
>
>     @DocValuesField
>     public @interface SortField {
>
>         @OverridesAttribute(name="name")
>         String name();
>     }
>
> And then its usage:
>
>     @SortField
>     private String bar;
>
>
> Of course such doc value annotation types (I think @SortField, @Facet and
> @DocumentId could be modelled as that) would only expose those degrees of
> freedom needed for a specific use case.
>
> Most users would only use these more abstract, easy-to-use specific purpose
> annotations. But others could use @DocValuesField directly to create custom
> doc values or they could even create their own, domain-specific doc value
> annotation type.
>
> Cheers,
>
> --Gunnar
>
>
>
>
> 2015-08-04 18:00 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Hi Guillaume,
>> thanks! great input. Some comments inline:
>>
>> On 4 August 2015 at 15:11, Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>> > Hi Sanne,
>> >
>> > On Wed, Jul 29, 2015 at 1:26 PM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> I'm not sure if this should be extending the @Field annotation as
>> >> there are special restrictions implied in terms of analysis: are we
>> >> going to enforce a specific type of tokenizer, or simply take the
>> >> analysis option away?
>> >
>> >
>> > You can't remove the analysis option away: it's often used to normalize
>> > sorting on strings (lowercase, remove accents, remove special characters
>> > and
>> > so on).
>>
>> Right we made this same example in a recent meeting we had on this same
>> subject.
>> So that's what makes it tricky: we want to allow Analysis, but while
>> Lucene needs a strong guarantee that it will be unique, we can't
>> really verify for that unless we take away the liberty to use any
>> analyzer.
>> An alternative would be to wrap the Analyzer to monitor and verify it
>> to be "well-behaved" but I'm not sure if that's doable, or if the
>> performance would be negligible. I guess we'll just put it into user's
>> hands to make a sensible choice.. not that we've done better so far on
>> this aspect.
>>
>> > FWIW, we use specific fields for sorting each time we need to sort on a
>> > string as we don't want to tokenize the string (but not for numerics and
>> > dates). Maybe @SortFields/@SortField annotations would be in order (I
>> > don't
>> > like Sortable as I don't think it's a good idea to use these fields for
>> > search).
>>
>> I like that name proposal, and +1 to not encourage people to try reuse
>> the same field for sorting and indexing.
>>
>> The next action for us is to verify what the performance impact is of
>> the current approach, which is based on the UninvertingReader from
>> lucene-misc. Gunnar pointed out that uninverting and loading into a
>> FieldCache is not very different than what Lucene has been doing so
>> far, so that might be a good strategy to allow migrating to Lucene 5
>> incrementally, and provide an incremental improvement in this area
>> rather than requiring the new mapping.
>>
>> I'll soon merge this approach, and as usual I'm lacking on real-world
>> applications to benchmark so if you're interested in helping on that
>> that would be awesome; we just need to know that the new code won't be
>> significantly slower than the Lucene 4 based strategies for sorted
>> queries.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gustavo at infinispan.org  Fri Aug  7 08:31:16 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Fri, 7 Aug 2015 13:31:16 +0100
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
 new mapping annotations ?
In-Reply-To: <CAFm4XO3bC-j7r1i3HMJ==T9NFr-oYweYOSxEn3nxtY8KQU6qHg@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
	<CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
	<CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>
	<CADGJaX9+wnnhLuLim8AY=qS2bvPq_5r=pr-h99Q2dXZDOTOeMw@mail.gmail.com>
	<CAFm4XO3bC-j7r1i3HMJ==T9NFr-oYweYOSxEn3nxtY8KQU6qHg@mail.gmail.com>
Message-ID: <CAH8Ud1H9fwzV-E4V3SKc_HrKXiPwPA=LkMpeWdwG-NJjLqhRyg@mail.gmail.com>

On Fri, Aug 7, 2015 at 1:14 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> A quick update on some more exploration on this:
> it turns out sorting on a NumericField when this field is also using
> an "indexNullAs" token gets the UninvertingReader approach to throw an
> exception.
> My two conclusions:
>  - we need to move away from supporting those tokens in NumericField,
> especially as stricter schema is coming in next gen Lucene
>  - yet another reason to clearly separate fields meant for searching vs
> sorting
>


One possible workaround is to enforce the indexNullAs value to match the
underlying field type, at the
moment it is always a string.

Another possibility is to model "null" as field not present in the lucene
document, instead of a marker token.

Gustavo

From steve at hibernate.org  Fri Aug  7 11:41:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 07 Aug 2015 15:41:09 +0000
Subject: [hibernate-dev] Default fetching
Message-ID: <CAFdSV9tJwfqnzGYdf6c+7xuQ8X7CNAm2QjNGBAb+hGnM99F8sQ@mail.gmail.com>

I thought we had discussed this once upon a time, but I could not find any
email.  In overhauling the documentation I ran across our long-standing
recommendation that all associations be defined in metadata as lazy.  JPA
of course came along said that for to-one associations the default should
eager.

Do we want to add a setting to allow folks to alter these defaults?  I know
that's tough in terms of portability between providers, but that is
ultimately the user's choice.

From smarlow at redhat.com  Fri Aug  7 12:30:35 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 7 Aug 2015 12:30:35 -0400
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
In-Reply-To: <54FF2F21.6000704@redhat.com>
References: <54FDE444.8060804@redhat.com>
	<CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>
	<54FF1756.4040400@redhat.com>
	<CAFdSV9u+5oeJANhWDBQu-QiMg1qY7SvvDaKmzpsyYjbcKT_-wQ@mail.gmail.com>
	<54FF2F21.6000704@redhat.com>
Message-ID: <55C4DD2B.60209@redhat.com>

https://github.com/wildfly/wildfly/pull/7909 uses the Narayana 
org.jboss.tm.listener.TransactionListenerRegistry to be notified when 
the transaction is associated/deassociated with the JTA transaction.

I think that Hibernate ORM could do something similar with the 
org.jboss.tm.listener.TransactionListenerRegistry to protect against 
clearing the persistence context from a non-application thread, while 
the application thread may be actively using the persistence context.

I think this approach is simpler than the thread id tracking.

On 03/10/2015 01:51 PM, Scott Marlow wrote:
>>
>> So what is this buying us?
>>
>
> The current Hibernate ORM thread id checking, does not properly handle
> the case when the application thread changes between calls to the
> Hibernate session.  The new approach does handle the application thread
> changing between session invocations and also covers a few other cases
> as well (like clearing the persistence context after the application may
> of added another entity after the background thread rolled back the
> transaction).
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Fri Aug  7 12:57:07 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 7 Aug 2015 12:57:07 -0400
Subject: [hibernate-dev] Default fetching
In-Reply-To: <CAFdSV9tJwfqnzGYdf6c+7xuQ8X7CNAm2QjNGBAb+hGnM99F8sQ@mail.gmail.com>
References: <CAFdSV9tJwfqnzGYdf6c+7xuQ8X7CNAm2QjNGBAb+hGnM99F8sQ@mail.gmail.com>
Message-ID: <55C4E363.5030607@redhat.com>


On 08/07/2015 11:41 AM, Steve Ebersole wrote:
> I thought we had discussed this once upon a time, but I could not find any
> email.  In overhauling the documentation I ran across our long-standing
> recommendation that all associations be defined in metadata as lazy.  JPA
> of course came along said that for to-one associations the default should
> eager.
>
> Do we want to add a setting to allow folks to alter these defaults?

Yes, I think users would like having the option to alter these defaults.

> I know
> that's tough in terms of portability between providers, but that is
> ultimately the user's choice.


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

From steve at hibernate.org  Fri Aug  7 14:41:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 07 Aug 2015 18:41:55 +0000
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
In-Reply-To: <55C4DD2B.60209@redhat.com>
References: <54FDE444.8060804@redhat.com>
	<CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>
	<54FF1756.4040400@redhat.com>
	<CAFdSV9u+5oeJANhWDBQu-QiMg1qY7SvvDaKmzpsyYjbcKT_-wQ@mail.gmail.com>
	<54FF2F21.6000704@redhat.com> <55C4DD2B.60209@redhat.com>
Message-ID: <CAFdSV9u4vtwN6tCh2sNf9f01KQdAX-SQ+eZqMJYi0bzxhP6otQ@mail.gmail.com>

Yeah, which is great when you can rely on impl-specific apis.

I'll consider this, but its not super high on my priority list.  I guess we
could implement some kind of way for the JtaPlatform to indicate the "type
of timeout tracking" to do and develop a new NarayanaJtaPltaform that does
this.


On Fri, Aug 7, 2015 at 11:30 AM Scott Marlow <smarlow at redhat.com> wrote:

> https://github.com/wildfly/wildfly/pull/7909 uses the Narayana
> org.jboss.tm.listener.TransactionListenerRegistry to be notified when
> the transaction is associated/deassociated with the JTA transaction.
>
> I think that Hibernate ORM could do something similar with the
> org.jboss.tm.listener.TransactionListenerRegistry to protect against
> clearing the persistence context from a non-application thread, while
> the application thread may be actively using the persistence context.
>
> I think this approach is simpler than the thread id tracking.
>
> On 03/10/2015 01:51 PM, Scott Marlow wrote:
> >>
> >> So what is this buying us?
> >>
> >
> > The current Hibernate ORM thread id checking, does not properly handle
> > the case when the application thread changes between calls to the
> > Hibernate session.  The new approach does handle the application thread
> > changing between session invocations and also covers a few other cases
> > as well (like clearing the persistence context after the application may
> > of added another entity after the background thread rolled back the
> > transaction).
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From gbadner at redhat.com  Fri Aug  7 17:15:54 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 7 Aug 2015 14:15:54 -0700
Subject: [hibernate-dev] Hibernate ORM 4.2.20.Final and 4.3.11.Final Released
Message-ID: <CAFDzhiRg9AcpZcyRb5vOY+WiS74ceKnHrfa4vecbCE0w1W+KGg@mail.gmail.com>

For details, see
http://in.relation.to/2015/08/07/hibernate-orm-4220-final-and-4311-final-released
.

From steve at hibernate.org  Fri Aug  7 19:41:15 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 07 Aug 2015 23:41:15 +0000
Subject: [hibernate-dev] Bytecode enhancement and field-access
Message-ID: <CAFdSV9tn+x25hBZd0+DMGxT3GGJzqj5oJ6T5iW_jrX0DoKd+mg@mail.gmail.com>

In working through the document overhaul I ran across the following passage
in the JPA specification:

<quote>
The persistent state of an entity is represented by instance variables,
which may correspond to JavaBeans properties. An instance variable must be
directly accessed only from within the methods of the entity by the entity
instance itself. Instance variables must not be accessed by clients of the
entity. The state of the entity is available to clients only through the
entity?s methods?i.e., accessor methods (getter/setter methods) or other
business methods.
</quote>

(from section "2.1 The Entity Class" in the JPA 2.1 specification).  Notice
that the spec explicitly calls out that even with field access the
expectation is that the application still access the state via methods.  In
other words our concept of "extended enhancement" is actually beyond the
spec.

From flemming.harms at gmail.com  Sun Aug  9 01:56:14 2015
From: flemming.harms at gmail.com (Flemming Harms)
Date: Sun, 9 Aug 2015 07:56:14 +0200
Subject: [hibernate-dev] [Hibernate Search] Database back end worker
In-Reply-To: <CAFm4XO2a0gKu2nrOG6_hynA7hXRa+L0xvM4x9GSqmO_wERKKEA@mail.gmail.com>
References: <CAFP3+ykfZk77_VU2nByfFkaY43nA7KG06kbb4ZZ+dKVKJ3LBgA@mail.gmail.com>
	<14efd4b452c-7fae-3686d@webprd-m59.mail.aol.com>
	<CAFP3+ymhTwU+T=o+cnsV6kHhh5cpL27HWh2S6AFQsxALYEXCQQ@mail.gmail.com>
	<CAFm4XO2a0gKu2nrOG6_hynA7hXRa+L0xvM4x9GSqmO_wERKKEA@mail.gmail.com>
Message-ID: <CAFP3+ykRUKDfFTCzb-8PXe1CWB0sa2O7FgM2e9TTsYswBG_gqQ@mail.gmail.com>

2015-08-05 23:38 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi Flemming,
> welcome on this list!
>
> I waited a bit to reply myself, as you already know I like the
> proposal. Unfortunately many others are on holidays, so other feedback
> might be slow.
>
> Still I wouldn't let that slow you down and start the works for
> merging it; I already anticipated over chat that this would come and
> we all agree that the concept is useful!
> I don't think others looked at the details yet, but if it comes to
> concerns at that level, we can address smaller issues incrementally.
> (I also didn't look at micro-details, as it's easier to comment on
> those on a pull request).
>
> I had the same question as Martin regarding clustering: with the
> current implementation you expect something like the master/slave
> configuration, or Infinispan to be used as storage, correct?
> I also think it would be interesting to explore the approach further
> to also - optionally - serve as a replacement for these, but that's
> another feature which is easier to experiment with after the core
> concept is merged.
>


> Yes that's correct. To start with it was written very specific to the use
> of Infinispan as directory.

And I agree on we should explore other cluster configuration and I have
some ideas how we can implement it.

> .
>

> In short, I would simply merge your backend as a new module in
> Hibernate Search! Fork our repository, and send a pull request.
>
> # Code layout / Modules
>
> In terms of code structure, you might have noticed that the module
> 'hibernate-search-engine' (/engine in the source code) does not depend
> on JPA nor Hibernate ORM; the reason is that other projects reuse the
> core indexing strategy and the backends. Since it would be nice to
> allow them to optionally use your backend, still not mandate a
> dependency on ORM for those who don't, I think this should be a new
> Maven module.
>
> We already have
>  /backends/jgroups
>  /backends/jms
>
> So we could add (name to be refined?) :
>  /backends/relationaldb
>
sure, no problem :)

>
> Also, your integration tests probably should be moved together with
> our other integration tests. They are currently running WildFly
> 10.0.0.Alpha6, but that shouldn't be a problem.
>
> # Code Style
>
> We use tabs ;-)
> And also have various other "exotic" conventions regarding white-space
> usage, right header files, etc..
> We use CheckStyle to keep it tidy, it will give you lots of errors and
> when there are many it's not very helpful; I would suggest to take the
> formatting templates attached at the following link and use your IDE's
> formatting capabilities, resort to checkstyle just for the final
> validation:
>  - http://hibernate.org/search/contribute/
>
> # JDK
>
> It looks like your extension requires Java 8; if you could convert it
> to Java 7 that would be nice.
>
Don't think it will be an issue. As far I remember we don't use any Java8
specific functionality

>
> # Rebasing to latest
>
> I'm afraid we're now aiming at Hibernate ORM 5, so some details might
> need to be updated; probably just in the configuration area. We're
> also in the process of upgrading to Apache Lucene 5, but that
> shouldn't affect you at all.
>
> # Some improvement ideas
>
> While we should support the case in which Hibernate Search is not
> being run as an extension of Hibernate ORM, that's likely the most
> common one.
> In that scenario I think it would be nice to be able to lookup the
> existing ORM services so that users don't need to repeat for example
> the datasource configuration.
>
> We might also be able to reuse all of the SessionFactory, but I'm not
> sure how to include your model without it potentially interfering with
> the end user's model; I'd say let's start by sharing some services
> from ORM and then see what kind of improvements we can build into ORM
> for this use case; for example this might simplify some of the
> TransactionManager configuration code I'm seeing in your repository.
>
> Of course your existing configuration properties are useful too,
> especially for the non-ORM case as we'll need be able to reuse the ORM
> services.
>
> Also, you might have noticed we are now able to optionally include the
> backend operations in the same transaction. That's not the default, as
> commonly people don't want that, but it would be very interesting to
> evolve this backend to support that option too, you wouldn't even
> require XA when storing the entity in the same database!
>  - http://in.relation.to/2015/07/09/hibernate-search-jms-transaction/
>
> Yes, it's very nice feature and fit perfectly with relationaldb

> I'd be happy to help with this, feel free to share non-working and/or
> intermediate experimental branches when having questions or just
> stuck.
> Please start by creating a JIRA, you can leave the target version
> undefined: we'll merge it when it's ready.
>
> For all the task you have listed can I create sub task to the JIRA, or how
do you track tasks?


> Thanks,
> Sanne
>
>
> On 5 August 2015 at 20:05, Flemming Harms <flemming.harms at gmail.com>
> wrote:
> > Hi Martin
> >
> > For this version the AbstractDatabaseHibernateSearchController is not
> able
> > to process Lucene workers simultaneously. When we build it our initial
> > requirement was only one node should process the workers at a time, but
> the
> > ?master? was floating. We use Quartz to get this type of functionality
> and
> > it will synchronizing the execution between the nodes. But you could also
> > use an HA-singleton to dedicate a specific node to process the workers.
> >
> > We had been playing with an idea where we stamp the LuceneDatabaseWork
> with
> > the known cluster nodes, and then the last node will remove it from the
> > database or a scheduled job can take care of it. The advance of this
> > solution is it will make Infinispan optional, and it can store the
> indexes
> > on each node instead in a shared cache.
> >
> > Your idea and work look very nice. Pretty awesome feature to support
> > different JPA providers.
> >
> > --
> > cheers
> > Flemming
> >
> >
> > 2015-08-05 11:57 GMT+02:00 Martin Braun <martinbraun123 at aol.com>:
> >
> >> Hi,
> >>
> >>
> >> Note: I am no core developer of Hibernate Search, but I am currently
> >> working on something
> >> that looks quite similar to what you are doing :). One part of it is an
> >> updating mechanism based on triggers
> >> that uses the database as a event-storage as well. It's not the exact
> same
> >> thing, but related.
> >>
> >>
> >> https://github.com/Hotware/Hibernate-Search-JPA
> >>
> >>
> >>
> >> The idea is quite nice, but after looking at the sourcecode I am
> wondering
> >> how the different nodes are able to work together, because in
> >> AbstractDatabaseHibernateSearchController you remove the entity
> >> from the persistence context and I wasn't able to find code that would
> >> make up for that.
> >>
> >>
> >> Doesn't that mean that the other workers will not be able to read that
> >> entity?
> >> Or will users of this need to implement their own synchronization
> >> mechanism between
> >> the different nodes?
> >>
> >>
> >> Martin Braun
> >> martinbraun123 at aol.com
> >> www.github.com/s4ke
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Flemming Harms <flemming.harms at gmail.com>
> >> To: Hibernate.org <hibernate-dev at lists.jboss.org>
> >> Sent: Tue, Aug 4, 2015 6:40 pm
> >> Subject: [hibernate-dev] [Hibernate Search] Database back end worker
> >>
> >>
> >> Hey guys
> >>
> >> I want to introduce myself and a new database back-end worker, me
> >> and
> >> another guy have build for hibernate search. I already had some initial
> >> talk
> >> with Sanne regarding if this could be interested to the hibernate
> >> search
> >> project.
> >>
> >> I have been working with Hibernate Search from some time and actually
> >> done
> >> various small custom modification to search since 3.x, especial
> >> around
> >> running in a cluster and indexing. To make a long story short when
> >> we
> >> upgraded Hibernate search we thought it would be ideal to use a SQL
> >> database
> >> as storage for lucene workers for 3 main reasons.
> >>
> >> - The database was shared
> >> between the nodes
> >> - The workers was persistent in case of a node crash.
> >> - No
> >> master/slave
> >>
> >>
> >> *In some way it?s very similar to the JMS back-end worker, where
> >> the user
> >> also have to implement a MDB that process the workers. In our case
> >> they
> >> will have to implement a job using something like quartz or a
> >> timer
> >> service. *
> >>
> >> *We are using JPA as persistence layer for the database, even
> >> it?s a fairly
> >> simple entity we persistent, but it make sense for supporting
> >> various
> >> databases and schema update out of the box. We have tried to make it?s
> >> as
> >> easy as possible to set-up by minimizing the number of properties, and
> >> it?s
> >> all configurable from the persistence.xml*
> >>
> >> *The actually work can* be
> >> *find
> >> here
> >> https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
> >> <https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
> >*
> >>
> >>
> >>
> >> *So
> >> based on this introduction and the code, is this something you could
> >> use? (of
> >> course with the modification it requires to follow the design,
> >> style, docs etc
> >> for the search)*--
> >>
> >> Kind regards
> >> Flemming
> >> Harms
> >> _______________________________________________
> >> hibernate-dev mailing
> >> list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> >
> >
> > --
> >
> > Kind regards / Med Venlig Hilsen
> > Flemming Harms
> >
> >    -
> >
> > https://twitter.com/fnharms
> > https://dk.linkedin.com/in/fharms
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>



-- 

Kind regards / Med Venlig Hilsen
Flemming Harms

   -

https://twitter.com/fnharms
https://dk.linkedin.com/in/fharms

From sanne at hibernate.org  Sun Aug  9 11:51:51 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 9 Aug 2015 16:51:51 +0100
Subject: [hibernate-dev] [Hibernate Search] Database back end worker
In-Reply-To: <CAFP3+ykRUKDfFTCzb-8PXe1CWB0sa2O7FgM2e9TTsYswBG_gqQ@mail.gmail.com>
References: <CAFP3+ykfZk77_VU2nByfFkaY43nA7KG06kbb4ZZ+dKVKJ3LBgA@mail.gmail.com>
	<14efd4b452c-7fae-3686d@webprd-m59.mail.aol.com>
	<CAFP3+ymhTwU+T=o+cnsV6kHhh5cpL27HWh2S6AFQsxALYEXCQQ@mail.gmail.com>
	<CAFm4XO2a0gKu2nrOG6_hynA7hXRa+L0xvM4x9GSqmO_wERKKEA@mail.gmail.com>
	<CAFP3+ykRUKDfFTCzb-8PXe1CWB0sa2O7FgM2e9TTsYswBG_gqQ@mail.gmail.com>
Message-ID: <CAFm4XO13sxa0KQ=rX5QKiyhYP50fdB1SJHML9dRk8cjZ-4g+Zw@mail.gmail.com>

Hi,
yes creating issues on JIRA is what we normally do, feel free to create them!

They don't have to be sub-stasks; we use subtasks when there are
several "blocker" steps which need to be accomplished to get a feature
and it's so large that it needs to be split.
In this case I'd make a single JIRA for the new feature - which gets
resolved when we'll merge it in its most essential form - and further
improvement ideas can be created now or as needed as independent
improvements.

Thanks!
Sanne

On 9 August 2015 at 06:56, Flemming Harms <flemming.harms at gmail.com> wrote:
>
>
> 2015-08-05 23:38 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Hi Flemming,
>> welcome on this list!
>>
>> I waited a bit to reply myself, as you already know I like the
>> proposal. Unfortunately many others are on holidays, so other feedback
>> might be slow.
>>
>> Still I wouldn't let that slow you down and start the works for
>> merging it; I already anticipated over chat that this would come and
>> we all agree that the concept is useful!
>> I don't think others looked at the details yet, but if it comes to
>> concerns at that level, we can address smaller issues incrementally.
>> (I also didn't look at micro-details, as it's easier to comment on
>> those on a pull request).
>>
>> I had the same question as Martin regarding clustering: with the
>> current implementation you expect something like the master/slave
>> configuration, or Infinispan to be used as storage, correct?
>> I also think it would be interesting to explore the approach further
>> to also - optionally - serve as a replacement for these, but that's
>> another feature which is easier to experiment with after the core
>> concept is merged.
>
>
>>
>> Yes that's correct. To start with it was written very specific to the use
>> of Infinispan as directory.
>
> And I agree on we should explore other cluster configuration and I have some
> ideas how we can implement it.
>>
>> .
>>
>>
>> In short, I would simply merge your backend as a new module in
>> Hibernate Search! Fork our repository, and send a pull request.
>>
>> # Code layout / Modules
>>
>> In terms of code structure, you might have noticed that the module
>> 'hibernate-search-engine' (/engine in the source code) does not depend
>> on JPA nor Hibernate ORM; the reason is that other projects reuse the
>> core indexing strategy and the backends. Since it would be nice to
>> allow them to optionally use your backend, still not mandate a
>> dependency on ORM for those who don't, I think this should be a new
>> Maven module.
>>
>> We already have
>>  /backends/jgroups
>>  /backends/jms
>>
>> So we could add (name to be refined?) :
>>  /backends/relationaldb
>
> sure, no problem :)
>>
>>
>> Also, your integration tests probably should be moved together with
>> our other integration tests. They are currently running WildFly
>> 10.0.0.Alpha6, but that shouldn't be a problem.
>>
>> # Code Style
>>
>> We use tabs ;-)
>> And also have various other "exotic" conventions regarding white-space
>> usage, right header files, etc..
>> We use CheckStyle to keep it tidy, it will give you lots of errors and
>> when there are many it's not very helpful; I would suggest to take the
>> formatting templates attached at the following link and use your IDE's
>> formatting capabilities, resort to checkstyle just for the final
>> validation:
>>  - http://hibernate.org/search/contribute/
>>
>> # JDK
>>
>> It looks like your extension requires Java 8; if you could convert it
>> to Java 7 that would be nice.
>
> Don't think it will be an issue. As far I remember we don't use any Java8
> specific functionality
>>
>>
>> # Rebasing to latest
>>
>> I'm afraid we're now aiming at Hibernate ORM 5, so some details might
>> need to be updated; probably just in the configuration area. We're
>> also in the process of upgrading to Apache Lucene 5, but that
>> shouldn't affect you at all.
>>
>> # Some improvement ideas
>>
>> While we should support the case in which Hibernate Search is not
>> being run as an extension of Hibernate ORM, that's likely the most
>> common one.
>> In that scenario I think it would be nice to be able to lookup the
>> existing ORM services so that users don't need to repeat for example
>> the datasource configuration.
>>
>> We might also be able to reuse all of the SessionFactory, but I'm not
>> sure how to include your model without it potentially interfering with
>> the end user's model; I'd say let's start by sharing some services
>> from ORM and then see what kind of improvements we can build into ORM
>> for this use case; for example this might simplify some of the
>> TransactionManager configuration code I'm seeing in your repository.
>>
>> Of course your existing configuration properties are useful too,
>> especially for the non-ORM case as we'll need be able to reuse the ORM
>> services.
>>
>> Also, you might have noticed we are now able to optionally include the
>> backend operations in the same transaction. That's not the default, as
>> commonly people don't want that, but it would be very interesting to
>> evolve this backend to support that option too, you wouldn't even
>> require XA when storing the entity in the same database!
>>  - http://in.relation.to/2015/07/09/hibernate-search-jms-transaction/
>>
> Yes, it's very nice feature and fit perfectly with relationaldb
>>
>> I'd be happy to help with this, feel free to share non-working and/or
>> intermediate experimental branches when having questions or just
>> stuck.
>> Please start by creating a JIRA, you can leave the target version
>> undefined: we'll merge it when it's ready.
>>
> For all the task you have listed can I create sub task to the JIRA, or how
> do you track tasks?
>
>>
>> Thanks,
>> Sanne
>>
>>
>> On 5 August 2015 at 20:05, Flemming Harms <flemming.harms at gmail.com>
>> wrote:
>> > Hi Martin
>> >
>> > For this version the AbstractDatabaseHibernateSearchController is not
>> > able
>> > to process Lucene workers simultaneously. When we build it our initial
>> > requirement was only one node should process the workers at a time, but
>> > the
>> > ?master? was floating. We use Quartz to get this type of functionality
>> > and
>> > it will synchronizing the execution between the nodes. But you could
>> > also
>> > use an HA-singleton to dedicate a specific node to process the workers.
>> >
>> > We had been playing with an idea where we stamp the LuceneDatabaseWork
>> > with
>> > the known cluster nodes, and then the last node will remove it from the
>> > database or a scheduled job can take care of it. The advance of this
>> > solution is it will make Infinispan optional, and it can store the
>> > indexes
>> > on each node instead in a shared cache.
>> >
>> > Your idea and work look very nice. Pretty awesome feature to support
>> > different JPA providers.
>> >
>> > --
>> > cheers
>> > Flemming
>> >
>> >
>> > 2015-08-05 11:57 GMT+02:00 Martin Braun <martinbraun123 at aol.com>:
>> >
>> >> Hi,
>> >>
>> >>
>> >> Note: I am no core developer of Hibernate Search, but I am currently
>> >> working on something
>> >> that looks quite similar to what you are doing :). One part of it is an
>> >> updating mechanism based on triggers
>> >> that uses the database as a event-storage as well. It's not the exact
>> >> same
>> >> thing, but related.
>> >>
>> >>
>> >> https://github.com/Hotware/Hibernate-Search-JPA
>> >>
>> >>
>> >>
>> >> The idea is quite nice, but after looking at the sourcecode I am
>> >> wondering
>> >> how the different nodes are able to work together, because in
>> >> AbstractDatabaseHibernateSearchController you remove the entity
>> >> from the persistence context and I wasn't able to find code that would
>> >> make up for that.
>> >>
>> >>
>> >> Doesn't that mean that the other workers will not be able to read that
>> >> entity?
>> >> Or will users of this need to implement their own synchronization
>> >> mechanism between
>> >> the different nodes?
>> >>
>> >>
>> >> Martin Braun
>> >> martinbraun123 at aol.com
>> >> www.github.com/s4ke
>> >>
>> >>
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Flemming Harms <flemming.harms at gmail.com>
>> >> To: Hibernate.org <hibernate-dev at lists.jboss.org>
>> >> Sent: Tue, Aug 4, 2015 6:40 pm
>> >> Subject: [hibernate-dev] [Hibernate Search] Database back end worker
>> >>
>> >>
>> >> Hey guys
>> >>
>> >> I want to introduce myself and a new database back-end worker, me
>> >> and
>> >> another guy have build for hibernate search. I already had some initial
>> >> talk
>> >> with Sanne regarding if this could be interested to the hibernate
>> >> search
>> >> project.
>> >>
>> >> I have been working with Hibernate Search from some time and actually
>> >> done
>> >> various small custom modification to search since 3.x, especial
>> >> around
>> >> running in a cluster and indexing. To make a long story short when
>> >> we
>> >> upgraded Hibernate search we thought it would be ideal to use a SQL
>> >> database
>> >> as storage for lucene workers for 3 main reasons.
>> >>
>> >> - The database was shared
>> >> between the nodes
>> >> - The workers was persistent in case of a node crash.
>> >> - No
>> >> master/slave
>> >>
>> >>
>> >> *In some way it?s very similar to the JMS back-end worker, where
>> >> the user
>> >> also have to implement a MDB that process the workers. In our case
>> >> they
>> >> will have to implement a job using something like quartz or a
>> >> timer
>> >> service. *
>> >>
>> >> *We are using JPA as persistence layer for the database, even
>> >> it?s a fairly
>> >> simple entity we persistent, but it make sense for supporting
>> >> various
>> >> databases and schema update out of the box. We have tried to make it?s
>> >> as
>> >> easy as possible to set-up by minimizing the number of properties, and
>> >> it?s
>> >> all configurable from the persistence.xml*
>> >>
>> >> *The actually work can* be
>> >> *find
>> >> here
>> >> https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
>> >>
>> >> <https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend>*
>> >>
>> >>
>> >>
>> >> *So
>> >> based on this introduction and the code, is this something you could
>> >> use? (of
>> >> course with the modification it requires to follow the design,
>> >> style, docs etc
>> >> for the search)*--
>> >>
>> >> Kind regards
>> >> Flemming
>> >> Harms
>> >> _______________________________________________
>> >> hibernate-dev mailing
>> >> list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Kind regards / Med Venlig Hilsen
>> > Flemming Harms
>> >
>> >    -
>> >
>> > https://twitter.com/fnharms
>> > https://dk.linkedin.com/in/fharms
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
>
> --
>
> Kind regards / Med Venlig Hilsen
> Flemming Harms
>
> https://twitter.com/fnharms
> https://dk.linkedin.com/in/fharms
>


From hardy at hibernate.org  Mon Aug 10 06:04:00 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 10 Aug 2015 12:04:00 +0200
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>
References: <CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
	<CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
	<CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>
Message-ID: <20150810100400.GA33812@Nineveh.local>

Hi,

sorry,  I am late to the game, but I here are some more thoughts on this.

I think the consensus so far is that 

# Date/time types which represent an instant in time are treated as usual.
  They can be string encoded (per default yyyyMMddHHmmssSSS) or numerically
  in which case the numeric long value equals the epoch time of the represented 
  date.
# Date/time types which do not represent an instant in time can also be
  encoded as string or number, but in the latter case the numeric representation 
  is given by interpreting the string representation as number.

So far so good. There are a couple of more things to think about. 

# Query time gets interesting and I think we need to improve the DSL in unison
  with adding support for these new types. Check out this example from DSLTest [1]

		query = monthQb
				.range()
					.onField( "estimatedCreation" )
						.ignoreFieldBridge()
					.andField( "justfortest" )
						.ignoreFieldBridge().ignoreAnalyzer()
					.from( DateTools.round( from, DateTools.Resolution.MINUTE ) )
					.to( DateTools.round( to, DateTools.Resolution.MINUTE ) )
						.excludeLimit()
					.createQuery();

If a date is numerically encoded you need to specify numbers for the from and to values. ATM,
we recommend to use the Lucene specific DateTools to get the numeric representation. With the support
ofthe new date types things will get confusing for the user. How does one "create" the numeric representation
of a LocalDate (and how does one know how it looks like in the first place and how it differs from the epoch time)?

We have been discussing before whether Hibernate Search needs to offer its own version of DateTools.
I think it would be time to do so and include helpers for the new date/time types. This also reduces the exposure 
to Lucene specific types.

Even better though would be, if we would be able to support directly the use of date types in the from and to clauses.
It would be the responsibility of the DSL to round the specified types to the appropriate level based on the field's
configuration/metadata. Even in this scenario though a Search specific DateTools might be necessary for the cases
where the date specified in to/from needs to be rounded differently than the field itself.

Last but not least, the documentation needs to be updated. At the moment, the docs are silent about all the complexity 
around dates. With the support of the new types, the docs needs to be more explicit and describe the subtleties at play.

--Hardy


On Wed, Aug 05, 2015 at 05:40:16PM +0100, Sanne Grinovero wrote:
> On 5 August 2015 at 17:22, Davide D'Alto <davide at hibernate.org> wrote:
> >> Proposal: use numeric but still - rather than taking the milliseconds
> >> from epoch, take the resulting number from YYYYMMDD ?
> >
> > I don't think I understand what you mean with "the resulting number from
> > YYYYMMDD".
> > Wouldn't be similar to get the number of days from epoch?
> 
> No because epoch is a specific moment *with a timezone*. If you take a
> calendar date "here", and take the moment in time which represents
> your beginning of the calendar date, the distance from epoch is not a
> whole number and you'd have to apply rounding which is timezone
> specific.
> 
> By simply encoding the number in the above format, you'd encode today
> as the number "20150805".
> That's a whole number which avoids the timezone relativity and can be
> efficiently encoded in numeric form, and provides the expected sorting
> properties.
> 
> >
> > But basically, you are saying that I can use different numeric encoding for
> > different types. Isn't it?
> 
> Yes, you definitely need different encodings depending on the type and
> the used options.
> 
> > So, for example:
> >
> > java.util.Date, java.util.Calendar  and java.time.Instant,
> > java.time.LocalDateTime will use number of miliseconds from epoch
> > java.time.LocalDate: number of days from epoch
> 
> Except this one ^ I agree with the others.
> 
> > java.time.LocalTime: number of nanos in a day
> 
> Conceptually, yes.. but we don't have "nanoseconds" as an option of
> org.hibernate.search.annotations.Resolution. Should we add it?
> We would not be able to apply that Resolution on old fashioned
> Date/Calendar, so that would need a warning or even an exception when
> applied to old style value types.
> 
> >> Ok that works but why write all those zeros in the index, when you can
> >> just write the date. I realize storage is cheap, but still we need to
> >> be careful as the index size affects performance ;-)
> >
> > I don't think we need to store the 0s.
> > If I know the type of the field I already know the the time is 0.
> 
> Exactly
> 
> > Am I missing something?
> 
> I probably just misunderstood your proposal, since previously you
> mentioned: "I would just consider a LocalDate the same as a
> LocalDateTime with time 00:00:000 (UTC time zone)".
> If you have to write the days only you don't need to convert to a time first.
> This misunderstanding might be related with the fact that you were
> planning to encode as distance from epoch.. see my first comment on
> this same email.
> Since you don't want to look at distance from epoch for this case, the
> time component really is irrelevant and LocalDate has all the
> information you need.. simpler ;)
> 
> Sanne
> 
> 
> >
> >
> > On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> >> On 5 August 2015 at 16:27, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> >> as I'd like us to consider not
> >> > applying DateBridge on the new types as it doesn't seem to add much
> >> > practical value.
> >> >
> >> > Ok, that may make sense for types such as LocalDate. But there are types
> >> in
> >> > the new API which - unlike LocalDate - do describe an exact instant on
> >> the
> >> > time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for
> >> > sure to support both encodings, NUMERIC and STRING (similar to
> >> Date/Calendar
> >> > so far) and thus apply @DateBridge.
> >>
> >> +1
> >>
> >> > Question is whether/how to index/persist TZ information, for Calendar it
> >> > seems not been persisted in the index so far?
> >>
> >> It's encoding the Calendar's time as distance from epoch, which is a
> >> neutral encoding so you don't need the TZ.
> >>
> >> For the old style Date/Calendar types we always assumed the value was
> >> a point-in-time, unless explicitly opting in for an alternative
> >> encoding.
> >> For example for the "birthday use case" a reasonable setting would
> >> have been String encoding with resolution=DAY, although passing in a
> >> Date instance having the right value (as in right timezone) would have
> >> been user's responsibility.. we simply take the long it's storing and
> >> index that with the requested resolution.
> >>
> >> Sanne
> >>
> >> >
> >> >
> >> > 2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> Inline:
> >> >>
> >> >> On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org> wrote:
> >> >> > If a user select a resolution that does not make much sense we can
> >> log a
> >> >> > warning.
> >> >>
> >> >> +1 And update the javadoc to mention that some resolution values don't
> >> >> apply
> >> >>
> >> >> > But I think this might make sense:
> >> >> >
> >> >> >    @DateBridge(resolution=MONTH)
> >> >> >    LocalDate birthday;
> >> >>
> >> >> Ok but how often do you think that will be used?
> >> >> Sorry playing devil's advocate here, as I'd like us to consider not
> >> >> applying DateBridge on the new types as it doesn't seem to add much
> >> >> practical value.
> >> >>
> >> >> I agree it's worth a shot, but while going ahead keep in mind that
> >> >> maybe simplifying that is the more elegant solution.
> >> >>
> >> >> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org>
> >> >> > wrote:
> >> >> >
> >> >> >> > What would you do though in case of the following:
> >> >> >> >
> >> >> >> >   @DateBridge
> >> >> >> >    LocalDate myDate;
> >> >> >> >
> >> >> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or
> >> b)
> >> >> >> ignore encoding() for LocalDate and friends? Both seem not right to
> >> me.
> >> >> >> I
> >> >> >> think there is nothing wrong with using NUMERIC encoding per-se for
> >> >> >> these
> >> >> >> types. We may recommend STRING but if NUMERIC really is what a user
> >> >> >> wants I
> >> >> >> would let them do so.
> >> >>
> >> >> I'm all for letting the users have the last word, but this is one of
> >> >> those cases in which you don't know if they explicitly want that or
> >> >> simply went with the defaults.
> >> >>
> >> >> Not a big problem as of course the important thing of defaults is that
> >> >> "they work" but I'd really prefer the default to try be the most
> >> >> appropriate encoding, which is not numeric in this case.
> >> >>
> >> >> Proposal: use numeric but still - rather than taking the milliseconds
> >> >> from epoch, take the resulting number from YYYYMMDD ? It might even be
> >> >> the most efficient encoding, as you don't have the drawback of
> >> >> clustering which we would have with a numeric encoding working on the
> >> >> individual fields, and doesn't have the bloat of string encoding.
> >> >>
> >> >> >>
> >> >> >> +1
> >> >> >>
> >> >> >> > What do you suggest we do if a user maps the following?
> >> >> >>
> >> >> >> >   @DateBridge(resolution=MILLISECOND)
> >> >> >> >   LocalDate birthday;
> >> >> >>
> >> >> >>
> >> >> >> Nothing really,
> >> >> >> I would just consider a LocalDate the same as a LocalDateTime with
> >> time
> >> >> >> 00:00:000 (UTC time zone)
> >> >>
> >> >> Ok that works but why write all those zeros in the index, when you can
> >> >> just write the date. I realize storage is cheap, but still we need to
> >> >> be careful as the index size affects performance ;-)
> >> >>
> >> >> Sanne
> >> >>
> >> >> >>
> >> >> >> It is equivalent to:
> >> >> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org
> >> >
> >> >> >> wrote:
> >> >> >>
> >> >> >>>
> >> >> >>>
> >> >> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >> >>>
> >> >> >>>> Our current implementation converts Date in the long "distance from
> >> >> >>>> epoch" to allow correct range-queries treating each Date as an
> >> >> >>>> instant
> >> >> >>>> in time - allowing a universal sorting strategy. But a LocalDate is
> >> >> >>>> not an instant-in-time.
> >> >> >>>>
> >> >> >>>> A LocalDate is intentionally oblivious of the timezone; as the
> >> >> >>>> javadoc
> >> >> >>>> states, it's useful for birthdays, i.e. symbolic occurrences and
> >> >> >>>> potentially legal matters which don't fit into a universal sorting
> >> >> >>>> model but rather with the local political scene - we would need the
> >> >> >>>> combo {LocalDate, ZoneId} provided to be able to allow sorting
> >> across
> >> >> >>>> different LocalDate - or simply assume that they are all referring
> >> to
> >> >> >>>> the same Zone.
> >> >> >>>>
> >> >> >>>
> >> >> >>> Right, I had the latter in mind and would use UTC for that purpose.
> >> >> >>>
> >> >> >>>>
> >> >> >>>> I think that if the user is using a LocalDate type, he's implicitly
> >> >> >>>> hinting that the timezone is not relevant for the practical use
> >> >> >>>> (possibly even wrong); the most faithful representation would be
> >> the
> >> >> >>>> string form in ISO standard format or to encode the day,month,year
> >> as
> >> >> >>>> independent fields? This last detail depends on how it would be
> >> more
> >> >> >>>> efficient to store & query; probably the String format YYYYMMDD
> >> would
> >> >> >>>> be the most efficient internal representation to allow also correct
> >> >> >>>> sorting.
> >> >> >>>>
> >> >> >>>> I wouldn't use NumericField(s) in this case, as they are more
> >> >> >>>> effective only with larger ranges, while MM and DD are very short;
> >> >> >>>> not
> >> >> >>>> sure if it's worth splitting the year as a NumericField either, as
> >> >> >>>> the
> >> >> >>>> values will likely be strongly clustered in the same range of
> >> "recent
> >> >> >>>> years" - although that might depend on the application but it
> >> doesn't
> >> >> >>>> seem worth the complexity, so I'd index & store as a String
> >> YYYYMMDD.
> >> >> >>>>
> >> >> >>>
> >> >> >>> Agreed that this makes most sense, given the "symbolic" nature of
> >> >> >>> LocalDate.
> >> >> >>>
> >> >> >>> What would you do though in case of the following:
> >> >> >>>
> >> >> >>>     @DateBridge
> >> >> >>>     LocalDate myDate;
> >> >> >>>
> >> >> >>> encoding() defaults to NUMERIC, so would you a) raise an error, or
> >> b)
> >> >> >>> ignore encoding() for LocalDate and friends? Both seem not right to
> >> >> >>> me. I
> >> >> >>> think there is nothing wrong with using NUMERIC encoding per-se for
> >> >> >>> these
> >> >> >>> types. We may recommend STRING but if NUMERIC really is what a user
> >> >> >>> wants I
> >> >> >>> would let them do so.
> >> >> >>>
> >> >> >>>>
> >> >> >>>> -- Sanne
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org>
> >> >> >>>> wrote:
> >> >> >>>> > Hi,
> >> >> >>>> >
> >> >> >>>> > What's the motivation for using a different representation in
> >> that
> >> >> >>>> case?
> >> >> >>>> >
> >> >> >>>> > For the sake of consistency, I'd use milli seconds since
> >> 1970-01-01
> >> >> >>>> across
> >> >> >>>> > the board. Otherwise it'll be more difficult to compare fields
> >> >> >>>> > created
> >> >> >>>> from
> >> >> >>>> > properties of different date types.
> >> >> >>>> >
> >> >> >>>> > --Gunnar
> >> >> >>>> >
> >> >> >>>> >
> >> >> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
> >> >> >>>> >
> >> >> >>>> >> Hi,
> >> >> >>>> >> I started to work on the creation of the bridges for the classes
> >> >> >>>> >> in
> >> >> >>>> the
> >> >> >>>> >> java.time package.
> >> >> >>>> >>
> >> >> >>>> >> I was wondering if we want to convert the values to long using
> >> the
> >> >> >>>> existing
> >> >> >>>> >> approach we have now for java.util.Date.
> >> >> >>>> >>
> >> >> >>>> >> In Hibernate Search a java.util.Date is converted into a long
> >> that
> >> >> >>>> >> represents the number of milliseconds since January 1, 1970,
> >> >> >>>> >> 00:00:00
> >> >> >>>> GMT
> >> >> >>>> >> using getTime().
> >> >> >>>> >>
> >> >> >>>> >> The same value can be obtain from a java.time.LocaDate via:
> >> >> >>>> >>
> >> >> >>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
> >> >> >>>> >> ).toInstant().toEpochMilli();
> >> >> >>>> >>
> >> >> >>>> >> LocalDate has a method that returns the same value expressed in
> >> >> >>>> number of
> >> >> >>>> >> days:
> >> >> >>>> >>
> >> >> >>>> >>         long epochDay = date.toEpochDay();
> >> >> >>>> >>
> >> >> >>>> >>
> >> >> >>>> >> I would use the second approach
> >> >> >>>> >>
> >> >> >>>> >> Davide
> >> >> >>>> >> _______________________________________________
> >> >> >>>> >> hibernate-dev mailing list
> >> >> >>>> >> hibernate-dev at lists.jboss.org
> >> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >>>> >>
> >> >> >>>> > _______________________________________________
> >> >> >>>> > hibernate-dev mailing list
> >> >> >>>> > hibernate-dev at lists.jboss.org
> >> >> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >>>>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> > _______________________________________________
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150810/c352df9b/attachment-0001.bin 

From sanne at hibernate.org  Mon Aug 10 06:37:11 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 10 Aug 2015 11:37:11 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <20150810100400.GA33812@Nineveh.local>
References: <CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
	<CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
	<CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>
	<20150810100400.GA33812@Nineveh.local>
Message-ID: <CAFm4XO3gtVGK-igyTbh8cAN5KNkXprgpC478rtsRg-pxVtm7Nw@mail.gmail.com>

On 10 August 2015 at 11:04, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> sorry,  I am late to the game, but I here are some more thoughts on this.
>
> I think the consensus so far is that
>
> # Date/time types which represent an instant in time are treated as usual.
>   They can be string encoded (per default yyyyMMddHHmmssSSS) or numerically
>   in which case the numeric long value equals the epoch time of the represented
>   date.

Correct that's the consensus so far. I'd like to challenge one more
detail though:
does it still make sense to allow string-encoded?

I think not, we did allow it primarily because a long time ago that
was the only way, then it became one of the options -but still the
default - and more recently it became the non-default way.

With these new types,backwards compatibility is a non-issue. So unless
someone makes a strong case for needing these as String in the index,
what about we drop some complexity?

Remember:
 - Hibernate Search is not an Objects/index mapper so we're not aiming
at creating any index schema possible, we're aiming at taking
advantage of the index for practical purposes ("I want it to be a
string in the index" is not a valid argument - use your own
fieldbridge in case)
 - With Projections we have to re-transform things back into their
Java original type, so how we encode things in the index is irrelevant
from a semantics point of view; I think the only valid challenge would
need to come from a performance or storage space perspective, in both
cases I'm pretty sure the numeric encoding would win.

> # Date/time types which do not represent an instant in time can also be
>   encoded as string or number, but in the latter case the numeric representation
>   is given by interpreting the string representation as number.
>
> So far so good. There are a couple of more things to think about.
>
> # Query time gets interesting and I think we need to improve the DSL in unison
>   with adding support for these new types. Check out this example from DSLTest [1]
>
>                 query = monthQb
>                                 .range()
>                                         .onField( "estimatedCreation" )
>                                                 .ignoreFieldBridge()
>                                         .andField( "justfortest" )
>                                                 .ignoreFieldBridge().ignoreAnalyzer()
>                                         .from( DateTools.round( from, DateTools.Resolution.MINUTE ) )
>                                         .to( DateTools.round( to, DateTools.Resolution.MINUTE ) )
>                                                 .excludeLimit()
>                                         .createQuery();
>
> If a date is numerically encoded you need to specify numbers for the from and to values. ATM,
> we recommend to use the Lucene specific DateTools to get the numeric representation. With the support
> ofthe new date types things will get confusing for the user. How does one "create" the numeric representation
> of a LocalDate (and how does one know how it looks like in the first place and how it differs from the epoch time)?

Great point, we should accept the user's domain type exclusively and
take the conversion burden from the user; especially since we know the
correct conversion strategy.

> We have been discussing before whether Hibernate Search needs to offer its own version of DateTools.
> I think it would be time to do so and include helpers for the new date/time types. This also reduces the exposure
> to Lucene specific types.

+1 to encapsulate it, but I don't expect people to need it at all in
the above case? But good for other more advanced needs.

>
> Even better though would be, if we would be able to support directly the use of date types in the from and to clauses.
> It would be the responsibility of the DSL to round the specified types to the appropriate level based on the field's
> configuration/metadata. Even in this scenario though a Search specific DateTools might be necessary for the cases
> where the date specified in to/from needs to be rounded differently than the field itself.

+1

> Last but not least, the documentation needs to be updated. At the moment, the docs are silent about all the complexity
> around dates. With the support of the new types, the docs needs to be more explicit and describe the subtleties at play.

+1 created HSEARCH-1958

Thanks,
Sanne


>
> --Hardy
>
>
> On Wed, Aug 05, 2015 at 05:40:16PM +0100, Sanne Grinovero wrote:
>> On 5 August 2015 at 17:22, Davide D'Alto <davide at hibernate.org> wrote:
>> >> Proposal: use numeric but still - rather than taking the milliseconds
>> >> from epoch, take the resulting number from YYYYMMDD ?
>> >
>> > I don't think I understand what you mean with "the resulting number from
>> > YYYYMMDD".
>> > Wouldn't be similar to get the number of days from epoch?
>>
>> No because epoch is a specific moment *with a timezone*. If you take a
>> calendar date "here", and take the moment in time which represents
>> your beginning of the calendar date, the distance from epoch is not a
>> whole number and you'd have to apply rounding which is timezone
>> specific.
>>
>> By simply encoding the number in the above format, you'd encode today
>> as the number "20150805".
>> That's a whole number which avoids the timezone relativity and can be
>> efficiently encoded in numeric form, and provides the expected sorting
>> properties.
>>
>> >
>> > But basically, you are saying that I can use different numeric encoding for
>> > different types. Isn't it?
>>
>> Yes, you definitely need different encodings depending on the type and
>> the used options.
>>
>> > So, for example:
>> >
>> > java.util.Date, java.util.Calendar  and java.time.Instant,
>> > java.time.LocalDateTime will use number of miliseconds from epoch
>> > java.time.LocalDate: number of days from epoch
>>
>> Except this one ^ I agree with the others.
>>
>> > java.time.LocalTime: number of nanos in a day
>>
>> Conceptually, yes.. but we don't have "nanoseconds" as an option of
>> org.hibernate.search.annotations.Resolution. Should we add it?
>> We would not be able to apply that Resolution on old fashioned
>> Date/Calendar, so that would need a warning or even an exception when
>> applied to old style value types.
>>
>> >> Ok that works but why write all those zeros in the index, when you can
>> >> just write the date. I realize storage is cheap, but still we need to
>> >> be careful as the index size affects performance ;-)
>> >
>> > I don't think we need to store the 0s.
>> > If I know the type of the field I already know the the time is 0.
>>
>> Exactly
>>
>> > Am I missing something?
>>
>> I probably just misunderstood your proposal, since previously you
>> mentioned: "I would just consider a LocalDate the same as a
>> LocalDateTime with time 00:00:000 (UTC time zone)".
>> If you have to write the days only you don't need to convert to a time first.
>> This misunderstanding might be related with the fact that you were
>> planning to encode as distance from epoch.. see my first comment on
>> this same email.
>> Since you don't want to look at distance from epoch for this case, the
>> time component really is irrelevant and LocalDate has all the
>> information you need.. simpler ;)
>>
>> Sanne
>>
>>
>> >
>> >
>> > On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >
>> >> On 5 August 2015 at 16:27, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> >> as I'd like us to consider not
>> >> > applying DateBridge on the new types as it doesn't seem to add much
>> >> > practical value.
>> >> >
>> >> > Ok, that may make sense for types such as LocalDate. But there are types
>> >> in
>> >> > the new API which - unlike LocalDate - do describe an exact instant on
>> >> the
>> >> > time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for
>> >> > sure to support both encodings, NUMERIC and STRING (similar to
>> >> Date/Calendar
>> >> > so far) and thus apply @DateBridge.
>> >>
>> >> +1
>> >>
>> >> > Question is whether/how to index/persist TZ information, for Calendar it
>> >> > seems not been persisted in the index so far?
>> >>
>> >> It's encoding the Calendar's time as distance from epoch, which is a
>> >> neutral encoding so you don't need the TZ.
>> >>
>> >> For the old style Date/Calendar types we always assumed the value was
>> >> a point-in-time, unless explicitly opting in for an alternative
>> >> encoding.
>> >> For example for the "birthday use case" a reasonable setting would
>> >> have been String encoding with resolution=DAY, although passing in a
>> >> Date instance having the right value (as in right timezone) would have
>> >> been user's responsibility.. we simply take the long it's storing and
>> >> index that with the requested resolution.
>> >>
>> >> Sanne
>> >>
>> >> >
>> >> >
>> >> > 2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> >>
>> >> >> Inline:
>> >> >>
>> >> >> On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org> wrote:
>> >> >> > If a user select a resolution that does not make much sense we can
>> >> log a
>> >> >> > warning.
>> >> >>
>> >> >> +1 And update the javadoc to mention that some resolution values don't
>> >> >> apply
>> >> >>
>> >> >> > But I think this might make sense:
>> >> >> >
>> >> >> >    @DateBridge(resolution=MONTH)
>> >> >> >    LocalDate birthday;
>> >> >>
>> >> >> Ok but how often do you think that will be used?
>> >> >> Sorry playing devil's advocate here, as I'd like us to consider not
>> >> >> applying DateBridge on the new types as it doesn't seem to add much
>> >> >> practical value.
>> >> >>
>> >> >> I agree it's worth a shot, but while going ahead keep in mind that
>> >> >> maybe simplifying that is the more elegant solution.
>> >> >>
>> >> >> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> > What would you do though in case of the following:
>> >> >> >> >
>> >> >> >> >   @DateBridge
>> >> >> >> >    LocalDate myDate;
>> >> >> >> >
>> >> >> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or
>> >> b)
>> >> >> >> ignore encoding() for LocalDate and friends? Both seem not right to
>> >> me.
>> >> >> >> I
>> >> >> >> think there is nothing wrong with using NUMERIC encoding per-se for
>> >> >> >> these
>> >> >> >> types. We may recommend STRING but if NUMERIC really is what a user
>> >> >> >> wants I
>> >> >> >> would let them do so.
>> >> >>
>> >> >> I'm all for letting the users have the last word, but this is one of
>> >> >> those cases in which you don't know if they explicitly want that or
>> >> >> simply went with the defaults.
>> >> >>
>> >> >> Not a big problem as of course the important thing of defaults is that
>> >> >> "they work" but I'd really prefer the default to try be the most
>> >> >> appropriate encoding, which is not numeric in this case.
>> >> >>
>> >> >> Proposal: use numeric but still - rather than taking the milliseconds
>> >> >> from epoch, take the resulting number from YYYYMMDD ? It might even be
>> >> >> the most efficient encoding, as you don't have the drawback of
>> >> >> clustering which we would have with a numeric encoding working on the
>> >> >> individual fields, and doesn't have the bloat of string encoding.
>> >> >>
>> >> >> >>
>> >> >> >> +1
>> >> >> >>
>> >> >> >> > What do you suggest we do if a user maps the following?
>> >> >> >>
>> >> >> >> >   @DateBridge(resolution=MILLISECOND)
>> >> >> >> >   LocalDate birthday;
>> >> >> >>
>> >> >> >>
>> >> >> >> Nothing really,
>> >> >> >> I would just consider a LocalDate the same as a LocalDateTime with
>> >> time
>> >> >> >> 00:00:000 (UTC time zone)
>> >> >>
>> >> >> Ok that works but why write all those zeros in the index, when you can
>> >> >> just write the date. I realize storage is cheap, but still we need to
>> >> >> be careful as the index size affects performance ;-)
>> >> >>
>> >> >> Sanne
>> >> >>
>> >> >> >>
>> >> >> >> It is equivalent to:
>> >> >> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org
>> >> >
>> >> >> >> wrote:
>> >> >> >>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> >> >>>
>> >> >> >>>> Our current implementation converts Date in the long "distance from
>> >> >> >>>> epoch" to allow correct range-queries treating each Date as an
>> >> >> >>>> instant
>> >> >> >>>> in time - allowing a universal sorting strategy. But a LocalDate is
>> >> >> >>>> not an instant-in-time.
>> >> >> >>>>
>> >> >> >>>> A LocalDate is intentionally oblivious of the timezone; as the
>> >> >> >>>> javadoc
>> >> >> >>>> states, it's useful for birthdays, i.e. symbolic occurrences and
>> >> >> >>>> potentially legal matters which don't fit into a universal sorting
>> >> >> >>>> model but rather with the local political scene - we would need the
>> >> >> >>>> combo {LocalDate, ZoneId} provided to be able to allow sorting
>> >> across
>> >> >> >>>> different LocalDate - or simply assume that they are all referring
>> >> to
>> >> >> >>>> the same Zone.
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>> Right, I had the latter in mind and would use UTC for that purpose.
>> >> >> >>>
>> >> >> >>>>
>> >> >> >>>> I think that if the user is using a LocalDate type, he's implicitly
>> >> >> >>>> hinting that the timezone is not relevant for the practical use
>> >> >> >>>> (possibly even wrong); the most faithful representation would be
>> >> the
>> >> >> >>>> string form in ISO standard format or to encode the day,month,year
>> >> as
>> >> >> >>>> independent fields? This last detail depends on how it would be
>> >> more
>> >> >> >>>> efficient to store & query; probably the String format YYYYMMDD
>> >> would
>> >> >> >>>> be the most efficient internal representation to allow also correct
>> >> >> >>>> sorting.
>> >> >> >>>>
>> >> >> >>>> I wouldn't use NumericField(s) in this case, as they are more
>> >> >> >>>> effective only with larger ranges, while MM and DD are very short;
>> >> >> >>>> not
>> >> >> >>>> sure if it's worth splitting the year as a NumericField either, as
>> >> >> >>>> the
>> >> >> >>>> values will likely be strongly clustered in the same range of
>> >> "recent
>> >> >> >>>> years" - although that might depend on the application but it
>> >> doesn't
>> >> >> >>>> seem worth the complexity, so I'd index & store as a String
>> >> YYYYMMDD.
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>> Agreed that this makes most sense, given the "symbolic" nature of
>> >> >> >>> LocalDate.
>> >> >> >>>
>> >> >> >>> What would you do though in case of the following:
>> >> >> >>>
>> >> >> >>>     @DateBridge
>> >> >> >>>     LocalDate myDate;
>> >> >> >>>
>> >> >> >>> encoding() defaults to NUMERIC, so would you a) raise an error, or
>> >> b)
>> >> >> >>> ignore encoding() for LocalDate and friends? Both seem not right to
>> >> >> >>> me. I
>> >> >> >>> think there is nothing wrong with using NUMERIC encoding per-se for
>> >> >> >>> these
>> >> >> >>> types. We may recommend STRING but if NUMERIC really is what a user
>> >> >> >>> wants I
>> >> >> >>> would let them do so.
>> >> >> >>>
>> >> >> >>>>
>> >> >> >>>> -- Sanne
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org>
>> >> >> >>>> wrote:
>> >> >> >>>> > Hi,
>> >> >> >>>> >
>> >> >> >>>> > What's the motivation for using a different representation in
>> >> that
>> >> >> >>>> case?
>> >> >> >>>> >
>> >> >> >>>> > For the sake of consistency, I'd use milli seconds since
>> >> 1970-01-01
>> >> >> >>>> across
>> >> >> >>>> > the board. Otherwise it'll be more difficult to compare fields
>> >> >> >>>> > created
>> >> >> >>>> from
>> >> >> >>>> > properties of different date types.
>> >> >> >>>> >
>> >> >> >>>> > --Gunnar
>> >> >> >>>> >
>> >> >> >>>> >
>> >> >> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>> >> >> >>>> >
>> >> >> >>>> >> Hi,
>> >> >> >>>> >> I started to work on the creation of the bridges for the classes
>> >> >> >>>> >> in
>> >> >> >>>> the
>> >> >> >>>> >> java.time package.
>> >> >> >>>> >>
>> >> >> >>>> >> I was wondering if we want to convert the values to long using
>> >> the
>> >> >> >>>> existing
>> >> >> >>>> >> approach we have now for java.util.Date.
>> >> >> >>>> >>
>> >> >> >>>> >> In Hibernate Search a java.util.Date is converted into a long
>> >> that
>> >> >> >>>> >> represents the number of milliseconds since January 1, 1970,
>> >> >> >>>> >> 00:00:00
>> >> >> >>>> GMT
>> >> >> >>>> >> using getTime().
>> >> >> >>>> >>
>> >> >> >>>> >> The same value can be obtain from a java.time.LocaDate via:
>> >> >> >>>> >>
>> >> >> >>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>> >> >> >>>> >> ).toInstant().toEpochMilli();
>> >> >> >>>> >>
>> >> >> >>>> >> LocalDate has a method that returns the same value expressed in
>> >> >> >>>> number of
>> >> >> >>>> >> days:
>> >> >> >>>> >>
>> >> >> >>>> >>         long epochDay = date.toEpochDay();
>> >> >> >>>> >>
>> >> >> >>>> >>
>> >> >> >>>> >> I would use the second approach
>> >> >> >>>> >>
>> >> >> >>>> >> Davide
>> >> >> >>>> >> _______________________________________________
>> >> >> >>>> >> hibernate-dev mailing list
>> >> >> >>>> >> hibernate-dev at lists.jboss.org
>> >> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >> >>>> >>
>> >> >> >>>> > _______________________________________________
>> >> >> >>>> > hibernate-dev mailing list
>> >> >> >>>> > hibernate-dev at lists.jboss.org
>> >> >> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> > _______________________________________________
>> >> >> > hibernate-dev mailing list
>> >> >> > hibernate-dev at lists.jboss.org
>> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >> _______________________________________________
>> >> >> hibernate-dev mailing list
>> >> >> hibernate-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> >
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Aug 10 07:16:03 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 10 Aug 2015 13:16:03 +0200
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CAFm4XO3gtVGK-igyTbh8cAN5KNkXprgpC478rtsRg-pxVtm7Nw@mail.gmail.com>
References: <CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
	<CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
	<CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>
	<20150810100400.GA33812@Nineveh.local>
	<CAFm4XO3gtVGK-igyTbh8cAN5KNkXprgpC478rtsRg-pxVtm7Nw@mail.gmail.com>
Message-ID: <CADGJaX8zzL5MHE5NPoiw_Sr856d1ZS6dYDpA4uJZvuNFgis5ew@mail.gmail.com>

> With these new types,backwards compatibility is a non-issue. So unless
> someone makes a strong case for needing these as String in the index,
> what about we drop some complexity?

ElasticSearch uses Strings for transferring dates in JSON structures
(see https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html).
So for that backend we'll need String-mapping field bridges (and we'd
even have to ignore/override/flag as error the user's setting for
numeric mapping).


2015-08-10 12:37 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> On 10 August 2015 at 11:04, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> Hi,
>>
>> sorry,  I am late to the game, but I here are some more thoughts on this.
>>
>> I think the consensus so far is that
>>
>> # Date/time types which represent an instant in time are treated as usual.
>>   They can be string encoded (per default yyyyMMddHHmmssSSS) or numerically
>>   in which case the numeric long value equals the epoch time of the represented
>>   date.
>
> Correct that's the consensus so far. I'd like to challenge one more
> detail though:
> does it still make sense to allow string-encoded?
>
> I think not, we did allow it primarily because a long time ago that
> was the only way, then it became one of the options -but still the
> default - and more recently it became the non-default way.
>
> With these new types,backwards compatibility is a non-issue. So unless
> someone makes a strong case for needing these as String in the index,
> what about we drop some complexity?
>
> Remember:
>  - Hibernate Search is not an Objects/index mapper so we're not aiming
> at creating any index schema possible, we're aiming at taking
> advantage of the index for practical purposes ("I want it to be a
> string in the index" is not a valid argument - use your own
> fieldbridge in case)
>  - With Projections we have to re-transform things back into their
> Java original type, so how we encode things in the index is irrelevant
> from a semantics point of view; I think the only valid challenge would
> need to come from a performance or storage space perspective, in both
> cases I'm pretty sure the numeric encoding would win.
>
>> # Date/time types which do not represent an instant in time can also be
>>   encoded as string or number, but in the latter case the numeric representation
>>   is given by interpreting the string representation as number.
>>
>> So far so good. There are a couple of more things to think about.
>>
>> # Query time gets interesting and I think we need to improve the DSL in unison
>>   with adding support for these new types. Check out this example from DSLTest [1]
>>
>>                 query = monthQb
>>                                 .range()
>>                                         .onField( "estimatedCreation" )
>>                                                 .ignoreFieldBridge()
>>                                         .andField( "justfortest" )
>>                                                 .ignoreFieldBridge().ignoreAnalyzer()
>>                                         .from( DateTools.round( from, DateTools.Resolution.MINUTE ) )
>>                                         .to( DateTools.round( to, DateTools.Resolution.MINUTE ) )
>>                                                 .excludeLimit()
>>                                         .createQuery();
>>
>> If a date is numerically encoded you need to specify numbers for the from and to values. ATM,
>> we recommend to use the Lucene specific DateTools to get the numeric representation. With the support
>> ofthe new date types things will get confusing for the user. How does one "create" the numeric representation
>> of a LocalDate (and how does one know how it looks like in the first place and how it differs from the epoch time)?
>
> Great point, we should accept the user's domain type exclusively and
> take the conversion burden from the user; especially since we know the
> correct conversion strategy.
>
>> We have been discussing before whether Hibernate Search needs to offer its own version of DateTools.
>> I think it would be time to do so and include helpers for the new date/time types. This also reduces the exposure
>> to Lucene specific types.
>
> +1 to encapsulate it, but I don't expect people to need it at all in
> the above case? But good for other more advanced needs.
>
>>
>> Even better though would be, if we would be able to support directly the use of date types in the from and to clauses.
>> It would be the responsibility of the DSL to round the specified types to the appropriate level based on the field's
>> configuration/metadata. Even in this scenario though a Search specific DateTools might be necessary for the cases
>> where the date specified in to/from needs to be rounded differently than the field itself.
>
> +1
>
>> Last but not least, the documentation needs to be updated. At the moment, the docs are silent about all the complexity
>> around dates. With the support of the new types, the docs needs to be more explicit and describe the subtleties at play.
>
> +1 created HSEARCH-1958
>
> Thanks,
> Sanne
>
>
>>
>> --Hardy
>>
>>
>> On Wed, Aug 05, 2015 at 05:40:16PM +0100, Sanne Grinovero wrote:
>>> On 5 August 2015 at 17:22, Davide D'Alto <davide at hibernate.org> wrote:
>>> >> Proposal: use numeric but still - rather than taking the milliseconds
>>> >> from epoch, take the resulting number from YYYYMMDD ?
>>> >
>>> > I don't think I understand what you mean with "the resulting number from
>>> > YYYYMMDD".
>>> > Wouldn't be similar to get the number of days from epoch?
>>>
>>> No because epoch is a specific moment *with a timezone*. If you take a
>>> calendar date "here", and take the moment in time which represents
>>> your beginning of the calendar date, the distance from epoch is not a
>>> whole number and you'd have to apply rounding which is timezone
>>> specific.
>>>
>>> By simply encoding the number in the above format, you'd encode today
>>> as the number "20150805".
>>> That's a whole number which avoids the timezone relativity and can be
>>> efficiently encoded in numeric form, and provides the expected sorting
>>> properties.
>>>
>>> >
>>> > But basically, you are saying that I can use different numeric encoding for
>>> > different types. Isn't it?
>>>
>>> Yes, you definitely need different encodings depending on the type and
>>> the used options.
>>>
>>> > So, for example:
>>> >
>>> > java.util.Date, java.util.Calendar  and java.time.Instant,
>>> > java.time.LocalDateTime will use number of miliseconds from epoch
>>> > java.time.LocalDate: number of days from epoch
>>>
>>> Except this one ^ I agree with the others.
>>>
>>> > java.time.LocalTime: number of nanos in a day
>>>
>>> Conceptually, yes.. but we don't have "nanoseconds" as an option of
>>> org.hibernate.search.annotations.Resolution. Should we add it?
>>> We would not be able to apply that Resolution on old fashioned
>>> Date/Calendar, so that would need a warning or even an exception when
>>> applied to old style value types.
>>>
>>> >> Ok that works but why write all those zeros in the index, when you can
>>> >> just write the date. I realize storage is cheap, but still we need to
>>> >> be careful as the index size affects performance ;-)
>>> >
>>> > I don't think we need to store the 0s.
>>> > If I know the type of the field I already know the the time is 0.
>>>
>>> Exactly
>>>
>>> > Am I missing something?
>>>
>>> I probably just misunderstood your proposal, since previously you
>>> mentioned: "I would just consider a LocalDate the same as a
>>> LocalDateTime with time 00:00:000 (UTC time zone)".
>>> If you have to write the days only you don't need to convert to a time first.
>>> This misunderstanding might be related with the fact that you were
>>> planning to encode as distance from epoch.. see my first comment on
>>> this same email.
>>> Since you don't want to look at distance from epoch for this case, the
>>> time component really is irrelevant and LocalDate has all the
>>> information you need.. simpler ;)
>>>
>>> Sanne
>>>
>>>
>>> >
>>> >
>>> > On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> >
>>> >> On 5 August 2015 at 16:27, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> >> >> as I'd like us to consider not
>>> >> > applying DateBridge on the new types as it doesn't seem to add much
>>> >> > practical value.
>>> >> >
>>> >> > Ok, that may make sense for types such as LocalDate. But there are types
>>> >> in
>>> >> > the new API which - unlike LocalDate - do describe an exact instant on
>>> >> the
>>> >> > time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for
>>> >> > sure to support both encodings, NUMERIC and STRING (similar to
>>> >> Date/Calendar
>>> >> > so far) and thus apply @DateBridge.
>>> >>
>>> >> +1
>>> >>
>>> >> > Question is whether/how to index/persist TZ information, for Calendar it
>>> >> > seems not been persisted in the index so far?
>>> >>
>>> >> It's encoding the Calendar's time as distance from epoch, which is a
>>> >> neutral encoding so you don't need the TZ.
>>> >>
>>> >> For the old style Date/Calendar types we always assumed the value was
>>> >> a point-in-time, unless explicitly opting in for an alternative
>>> >> encoding.
>>> >> For example for the "birthday use case" a reasonable setting would
>>> >> have been String encoding with resolution=DAY, although passing in a
>>> >> Date instance having the right value (as in right timezone) would have
>>> >> been user's responsibility.. we simply take the long it's storing and
>>> >> index that with the requested resolution.
>>> >>
>>> >> Sanne
>>> >>
>>> >> >
>>> >> >
>>> >> > 2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >> >>
>>> >> >> Inline:
>>> >> >>
>>> >> >> On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org> wrote:
>>> >> >> > If a user select a resolution that does not make much sense we can
>>> >> log a
>>> >> >> > warning.
>>> >> >>
>>> >> >> +1 And update the javadoc to mention that some resolution values don't
>>> >> >> apply
>>> >> >>
>>> >> >> > But I think this might make sense:
>>> >> >> >
>>> >> >> >    @DateBridge(resolution=MONTH)
>>> >> >> >    LocalDate birthday;
>>> >> >>
>>> >> >> Ok but how often do you think that will be used?
>>> >> >> Sorry playing devil's advocate here, as I'd like us to consider not
>>> >> >> applying DateBridge on the new types as it doesn't seem to add much
>>> >> >> practical value.
>>> >> >>
>>> >> >> I agree it's worth a shot, but while going ahead keep in mind that
>>> >> >> maybe simplifying that is the more elegant solution.
>>> >> >>
>>> >> >> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide at hibernate.org>
>>> >> >> > wrote:
>>> >> >> >
>>> >> >> >> > What would you do though in case of the following:
>>> >> >> >> >
>>> >> >> >> >   @DateBridge
>>> >> >> >> >    LocalDate myDate;
>>> >> >> >> >
>>> >> >> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or
>>> >> b)
>>> >> >> >> ignore encoding() for LocalDate and friends? Both seem not right to
>>> >> me.
>>> >> >> >> I
>>> >> >> >> think there is nothing wrong with using NUMERIC encoding per-se for
>>> >> >> >> these
>>> >> >> >> types. We may recommend STRING but if NUMERIC really is what a user
>>> >> >> >> wants I
>>> >> >> >> would let them do so.
>>> >> >>
>>> >> >> I'm all for letting the users have the last word, but this is one of
>>> >> >> those cases in which you don't know if they explicitly want that or
>>> >> >> simply went with the defaults.
>>> >> >>
>>> >> >> Not a big problem as of course the important thing of defaults is that
>>> >> >> "they work" but I'd really prefer the default to try be the most
>>> >> >> appropriate encoding, which is not numeric in this case.
>>> >> >>
>>> >> >> Proposal: use numeric but still - rather than taking the milliseconds
>>> >> >> from epoch, take the resulting number from YYYYMMDD ? It might even be
>>> >> >> the most efficient encoding, as you don't have the drawback of
>>> >> >> clustering which we would have with a numeric encoding working on the
>>> >> >> individual fields, and doesn't have the bloat of string encoding.
>>> >> >>
>>> >> >> >>
>>> >> >> >> +1
>>> >> >> >>
>>> >> >> >> > What do you suggest we do if a user maps the following?
>>> >> >> >>
>>> >> >> >> >   @DateBridge(resolution=MILLISECOND)
>>> >> >> >> >   LocalDate birthday;
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> Nothing really,
>>> >> >> >> I would just consider a LocalDate the same as a LocalDateTime with
>>> >> time
>>> >> >> >> 00:00:000 (UTC time zone)
>>> >> >>
>>> >> >> Ok that works but why write all those zeros in the index, when you can
>>> >> >> just write the date. I realize storage is cheap, but still we need to
>>> >> >> be careful as the index size affects performance ;-)
>>> >> >>
>>> >> >> Sanne
>>> >> >>
>>> >> >> >>
>>> >> >> >> It is equivalent to:
>>> >> >> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar at hibernate.org
>>> >> >
>>> >> >> >> wrote:
>>> >> >> >>
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >> >> >>>
>>> >> >> >>>> Our current implementation converts Date in the long "distance from
>>> >> >> >>>> epoch" to allow correct range-queries treating each Date as an
>>> >> >> >>>> instant
>>> >> >> >>>> in time - allowing a universal sorting strategy. But a LocalDate is
>>> >> >> >>>> not an instant-in-time.
>>> >> >> >>>>
>>> >> >> >>>> A LocalDate is intentionally oblivious of the timezone; as the
>>> >> >> >>>> javadoc
>>> >> >> >>>> states, it's useful for birthdays, i.e. symbolic occurrences and
>>> >> >> >>>> potentially legal matters which don't fit into a universal sorting
>>> >> >> >>>> model but rather with the local political scene - we would need the
>>> >> >> >>>> combo {LocalDate, ZoneId} provided to be able to allow sorting
>>> >> across
>>> >> >> >>>> different LocalDate - or simply assume that they are all referring
>>> >> to
>>> >> >> >>>> the same Zone.
>>> >> >> >>>>
>>> >> >> >>>
>>> >> >> >>> Right, I had the latter in mind and would use UTC for that purpose.
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>> I think that if the user is using a LocalDate type, he's implicitly
>>> >> >> >>>> hinting that the timezone is not relevant for the practical use
>>> >> >> >>>> (possibly even wrong); the most faithful representation would be
>>> >> the
>>> >> >> >>>> string form in ISO standard format or to encode the day,month,year
>>> >> as
>>> >> >> >>>> independent fields? This last detail depends on how it would be
>>> >> more
>>> >> >> >>>> efficient to store & query; probably the String format YYYYMMDD
>>> >> would
>>> >> >> >>>> be the most efficient internal representation to allow also correct
>>> >> >> >>>> sorting.
>>> >> >> >>>>
>>> >> >> >>>> I wouldn't use NumericField(s) in this case, as they are more
>>> >> >> >>>> effective only with larger ranges, while MM and DD are very short;
>>> >> >> >>>> not
>>> >> >> >>>> sure if it's worth splitting the year as a NumericField either, as
>>> >> >> >>>> the
>>> >> >> >>>> values will likely be strongly clustered in the same range of
>>> >> "recent
>>> >> >> >>>> years" - although that might depend on the application but it
>>> >> doesn't
>>> >> >> >>>> seem worth the complexity, so I'd index & store as a String
>>> >> YYYYMMDD.
>>> >> >> >>>>
>>> >> >> >>>
>>> >> >> >>> Agreed that this makes most sense, given the "symbolic" nature of
>>> >> >> >>> LocalDate.
>>> >> >> >>>
>>> >> >> >>> What would you do though in case of the following:
>>> >> >> >>>
>>> >> >> >>>     @DateBridge
>>> >> >> >>>     LocalDate myDate;
>>> >> >> >>>
>>> >> >> >>> encoding() defaults to NUMERIC, so would you a) raise an error, or
>>> >> b)
>>> >> >> >>> ignore encoding() for LocalDate and friends? Both seem not right to
>>> >> >> >>> me. I
>>> >> >> >>> think there is nothing wrong with using NUMERIC encoding per-se for
>>> >> >> >>> these
>>> >> >> >>> types. We may recommend STRING but if NUMERIC really is what a user
>>> >> >> >>> wants I
>>> >> >> >>> would let them do so.
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>> -- Sanne
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar at hibernate.org>
>>> >> >> >>>> wrote:
>>> >> >> >>>> > Hi,
>>> >> >> >>>> >
>>> >> >> >>>> > What's the motivation for using a different representation in
>>> >> that
>>> >> >> >>>> case?
>>> >> >> >>>> >
>>> >> >> >>>> > For the sake of consistency, I'd use milli seconds since
>>> >> 1970-01-01
>>> >> >> >>>> across
>>> >> >> >>>> > the board. Otherwise it'll be more difficult to compare fields
>>> >> >> >>>> > created
>>> >> >> >>>> from
>>> >> >> >>>> > properties of different date types.
>>> >> >> >>>> >
>>> >> >> >>>> > --Gunnar
>>> >> >> >>>> >
>>> >> >> >>>> >
>>> >> >> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
>>> >> >> >>>> >
>>> >> >> >>>> >> Hi,
>>> >> >> >>>> >> I started to work on the creation of the bridges for the classes
>>> >> >> >>>> >> in
>>> >> >> >>>> the
>>> >> >> >>>> >> java.time package.
>>> >> >> >>>> >>
>>> >> >> >>>> >> I was wondering if we want to convert the values to long using
>>> >> the
>>> >> >> >>>> existing
>>> >> >> >>>> >> approach we have now for java.util.Date.
>>> >> >> >>>> >>
>>> >> >> >>>> >> In Hibernate Search a java.util.Date is converted into a long
>>> >> that
>>> >> >> >>>> >> represents the number of milliseconds since January 1, 1970,
>>> >> >> >>>> >> 00:00:00
>>> >> >> >>>> GMT
>>> >> >> >>>> >> using getTime().
>>> >> >> >>>> >>
>>> >> >> >>>> >> The same value can be obtain from a java.time.LocaDate via:
>>> >> >> >>>> >>
>>> >> >> >>>> >>         long epochMilli = date.atStartOfDay( ZoneOffset.UTC
>>> >> >> >>>> >> ).toInstant().toEpochMilli();
>>> >> >> >>>> >>
>>> >> >> >>>> >> LocalDate has a method that returns the same value expressed in
>>> >> >> >>>> number of
>>> >> >> >>>> >> days:
>>> >> >> >>>> >>
>>> >> >> >>>> >>         long epochDay = date.toEpochDay();
>>> >> >> >>>> >>
>>> >> >> >>>> >>
>>> >> >> >>>> >> I would use the second approach
>>> >> >> >>>> >>
>>> >> >> >>>> >> Davide
>>> >> >> >>>> >> _______________________________________________
>>> >> >> >>>> >> hibernate-dev mailing list
>>> >> >> >>>> >> hibernate-dev at lists.jboss.org
>>> >> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> >> >>>> >>
>>> >> >> >>>> > _______________________________________________
>>> >> >> >>>> > hibernate-dev mailing list
>>> >> >> >>>> > hibernate-dev at lists.jboss.org
>>> >> >> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> >> >>>>
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>
>>> >> >> > _______________________________________________
>>> >> >> > hibernate-dev mailing list
>>> >> >> > hibernate-dev at lists.jboss.org
>>> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> >> _______________________________________________
>>> >> >> hibernate-dev mailing list
>>> >> >> hibernate-dev at lists.jboss.org
>>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> >
>>> >> >
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From daltodavide at gmail.com  Mon Aug 10 07:34:33 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 10 Aug 2015 12:34:33 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CAFm4XO3gtVGK-igyTbh8cAN5KNkXprgpC478rtsRg-pxVtm7Nw@mail.gmail.com>
References: <CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
	<CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
	<CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>
	<20150810100400.GA33812@Nineveh.local>
	<CAFm4XO3gtVGK-igyTbh8cAN5KNkXprgpC478rtsRg-pxVtm7Nw@mail.gmail.com>
Message-ID: <CANoTJYMTVi4j1_68KWtMwAdG_fB0343vNvm89cKHvXp-RJrq4Q@mail.gmail.com>

I'm not sure there is an easy way to convert Instant and DateTime to a
numeric value.
The problem is that the resolution for temporal types is nanoseconds, the
following datetime is valid:

year: -999.999.999
month: 12
day: 31
hour: 23
minute: 59
second: 59
nanos: 999.999.999

It gets more complicated when we need to store Offset or time zone.

> Great point, we should accept the user's domain type exclusively and
> take the conversion burden from the user; especially since we know the
> correct conversion strategy.

This is already supported (for certain types at least), you don't need to
round the dates to execute the queries.
I think the documentation is not up to date.

Davide

On Mon, Aug 10, 2015 at 11:37 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 10 August 2015 at 11:04, Hardy Ferentschik <hardy at hibernate.org> wrote:
> > Hi,
> >
> > sorry,  I am late to the game, but I here are some more thoughts on this.
> >
> > I think the consensus so far is that
> >
> > # Date/time types which represent an instant in time are treated as
> usual.
> >   They can be string encoded (per default yyyyMMddHHmmssSSS) or
> numerically
> >   in which case the numeric long value equals the epoch time of the
> represented
> >   date.
>
> Correct that's the consensus so far. I'd like to challenge one more
> detail though:
> does it still make sense to allow string-encoded?
>
> I think not, we did allow it primarily because a long time ago that
> was the only way, then it became one of the options -but still the
> default - and more recently it became the non-default way.
>
> With these new types,backwards compatibility is a non-issue. So unless
> someone makes a strong case for needing these as String in the index,
> what about we drop some complexity?
>
> Remember:
>  - Hibernate Search is not an Objects/index mapper so we're not aiming
> at creating any index schema possible, we're aiming at taking
> advantage of the index for practical purposes ("I want it to be a
> string in the index" is not a valid argument - use your own
> fieldbridge in case)
>  - With Projections we have to re-transform things back into their
> Java original type, so how we encode things in the index is irrelevant
> from a semantics point of view; I think the only valid challenge would
> need to come from a performance or storage space perspective, in both
> cases I'm pretty sure the numeric encoding would win.
>
> > # Date/time types which do not represent an instant in time can also be
> >   encoded as string or number, but in the latter case the numeric
> representation
> >   is given by interpreting the string representation as number.
> >
> > So far so good. There are a couple of more things to think about.
> >
> > # Query time gets interesting and I think we need to improve the DSL in
> unison
> >   with adding support for these new types. Check out this example from
> DSLTest [1]
> >
> >                 query = monthQb
> >                                 .range()
> >                                         .onField( "estimatedCreation" )
> >                                                 .ignoreFieldBridge()
> >                                         .andField( "justfortest" )
> >
>  .ignoreFieldBridge().ignoreAnalyzer()
> >                                         .from( DateTools.round( from,
> DateTools.Resolution.MINUTE ) )
> >                                         .to( DateTools.round( to,
> DateTools.Resolution.MINUTE ) )
> >                                                 .excludeLimit()
> >                                         .createQuery();
> >
> > If a date is numerically encoded you need to specify numbers for the
> from and to values. ATM,
> > we recommend to use the Lucene specific DateTools to get the numeric
> representation. With the support
> > ofthe new date types things will get confusing for the user. How does
> one "create" the numeric representation
> > of a LocalDate (and how does one know how it looks like in the first
> place and how it differs from the epoch time)?
>
> Great point, we should accept the user's domain type exclusively and
> take the conversion burden from the user; especially since we know the
> correct conversion strategy.
>
> > We have been discussing before whether Hibernate Search needs to offer
> its own version of DateTools.
> > I think it would be time to do so and include helpers for the new
> date/time types. This also reduces the exposure
> > to Lucene specific types.
>
> +1 to encapsulate it, but I don't expect people to need it at all in
> the above case? But good for other more advanced needs.
>
> >
> > Even better though would be, if we would be able to support directly the
> use of date types in the from and to clauses.
> > It would be the responsibility of the DSL to round the specified types
> to the appropriate level based on the field's
> > configuration/metadata. Even in this scenario though a Search specific
> DateTools might be necessary for the cases
> > where the date specified in to/from needs to be rounded differently than
> the field itself.
>
> +1
>
> > Last but not least, the documentation needs to be updated. At the
> moment, the docs are silent about all the complexity
> > around dates. With the support of the new types, the docs needs to be
> more explicit and describe the subtleties at play.
>
> +1 created HSEARCH-1958
>
> Thanks,
> Sanne
>
>
> >
> > --Hardy
> >
> >
> > On Wed, Aug 05, 2015 at 05:40:16PM +0100, Sanne Grinovero wrote:
> >> On 5 August 2015 at 17:22, Davide D'Alto <davide at hibernate.org> wrote:
> >> >> Proposal: use numeric but still - rather than taking the milliseconds
> >> >> from epoch, take the resulting number from YYYYMMDD ?
> >> >
> >> > I don't think I understand what you mean with "the resulting number
> from
> >> > YYYYMMDD".
> >> > Wouldn't be similar to get the number of days from epoch?
> >>
> >> No because epoch is a specific moment *with a timezone*. If you take a
> >> calendar date "here", and take the moment in time which represents
> >> your beginning of the calendar date, the distance from epoch is not a
> >> whole number and you'd have to apply rounding which is timezone
> >> specific.
> >>
> >> By simply encoding the number in the above format, you'd encode today
> >> as the number "20150805".
> >> That's a whole number which avoids the timezone relativity and can be
> >> efficiently encoded in numeric form, and provides the expected sorting
> >> properties.
> >>
> >> >
> >> > But basically, you are saying that I can use different numeric
> encoding for
> >> > different types. Isn't it?
> >>
> >> Yes, you definitely need different encodings depending on the type and
> >> the used options.
> >>
> >> > So, for example:
> >> >
> >> > java.util.Date, java.util.Calendar  and java.time.Instant,
> >> > java.time.LocalDateTime will use number of miliseconds from epoch
> >> > java.time.LocalDate: number of days from epoch
> >>
> >> Except this one ^ I agree with the others.
> >>
> >> > java.time.LocalTime: number of nanos in a day
> >>
> >> Conceptually, yes.. but we don't have "nanoseconds" as an option of
> >> org.hibernate.search.annotations.Resolution. Should we add it?
> >> We would not be able to apply that Resolution on old fashioned
> >> Date/Calendar, so that would need a warning or even an exception when
> >> applied to old style value types.
> >>
> >> >> Ok that works but why write all those zeros in the index, when you
> can
> >> >> just write the date. I realize storage is cheap, but still we need to
> >> >> be careful as the index size affects performance ;-)
> >> >
> >> > I don't think we need to store the 0s.
> >> > If I know the type of the field I already know the the time is 0.
> >>
> >> Exactly
> >>
> >> > Am I missing something?
> >>
> >> I probably just misunderstood your proposal, since previously you
> >> mentioned: "I would just consider a LocalDate the same as a
> >> LocalDateTime with time 00:00:000 (UTC time zone)".
> >> If you have to write the days only you don't need to convert to a time
> first.
> >> This misunderstanding might be related with the fact that you were
> >> planning to encode as distance from epoch.. see my first comment on
> >> this same email.
> >> Since you don't want to look at distance from epoch for this case, the
> >> time component really is irrelevant and LocalDate has all the
> >> information you need.. simpler ;)
> >>
> >> Sanne
> >>
> >>
> >> >
> >> >
> >> > On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >> >
> >> >> On 5 August 2015 at 16:27, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> >> >> as I'd like us to consider not
> >> >> > applying DateBridge on the new types as it doesn't seem to add much
> >> >> > practical value.
> >> >> >
> >> >> > Ok, that may make sense for types such as LocalDate. But there are
> types
> >> >> in
> >> >> > the new API which - unlike LocalDate - do describe an exact
> instant on
> >> >> the
> >> >> > time line (e.g. ZonedDateTime, Instant). For those IMO it makes
> sense for
> >> >> > sure to support both encodings, NUMERIC and STRING (similar to
> >> >> Date/Calendar
> >> >> > so far) and thus apply @DateBridge.
> >> >>
> >> >> +1
> >> >>
> >> >> > Question is whether/how to index/persist TZ information, for
> Calendar it
> >> >> > seems not been persisted in the index so far?
> >> >>
> >> >> It's encoding the Calendar's time as distance from epoch, which is a
> >> >> neutral encoding so you don't need the TZ.
> >> >>
> >> >> For the old style Date/Calendar types we always assumed the value was
> >> >> a point-in-time, unless explicitly opting in for an alternative
> >> >> encoding.
> >> >> For example for the "birthday use case" a reasonable setting would
> >> >> have been String encoding with resolution=DAY, although passing in a
> >> >> Date instance having the right value (as in right timezone) would
> have
> >> >> been user's responsibility.. we simply take the long it's storing and
> >> >> index that with the requested resolution.
> >> >>
> >> >> Sanne
> >> >>
> >> >> >
> >> >> >
> >> >> > 2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >> >>
> >> >> >> Inline:
> >> >> >>
> >> >> >> On 5 August 2015 at 15:42, Davide D'Alto <davide at hibernate.org>
> wrote:
> >> >> >> > If a user select a resolution that does not make much sense we
> can
> >> >> log a
> >> >> >> > warning.
> >> >> >>
> >> >> >> +1 And update the javadoc to mention that some resolution values
> don't
> >> >> >> apply
> >> >> >>
> >> >> >> > But I think this might make sense:
> >> >> >> >
> >> >> >> >    @DateBridge(resolution=MONTH)
> >> >> >> >    LocalDate birthday;
> >> >> >>
> >> >> >> Ok but how often do you think that will be used?
> >> >> >> Sorry playing devil's advocate here, as I'd like us to consider
> not
> >> >> >> applying DateBridge on the new types as it doesn't seem to add
> much
> >> >> >> practical value.
> >> >> >>
> >> >> >> I agree it's worth a shot, but while going ahead keep in mind that
> >> >> >> maybe simplifying that is the more elegant solution.
> >> >> >>
> >> >> >> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <
> davide at hibernate.org>
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> >> > What would you do though in case of the following:
> >> >> >> >> >
> >> >> >> >> >   @DateBridge
> >> >> >> >> >    LocalDate myDate;
> >> >> >> >> >
> >> >> >> >> > encoding() defaults to NUMERIC, so would you a) raise an
> error, or
> >> >> b)
> >> >> >> >> ignore encoding() for LocalDate and friends? Both seem not
> right to
> >> >> me.
> >> >> >> >> I
> >> >> >> >> think there is nothing wrong with using NUMERIC encoding
> per-se for
> >> >> >> >> these
> >> >> >> >> types. We may recommend STRING but if NUMERIC really is what a
> user
> >> >> >> >> wants I
> >> >> >> >> would let them do so.
> >> >> >>
> >> >> >> I'm all for letting the users have the last word, but this is one
> of
> >> >> >> those cases in which you don't know if they explicitly want that
> or
> >> >> >> simply went with the defaults.
> >> >> >>
> >> >> >> Not a big problem as of course the important thing of defaults is
> that
> >> >> >> "they work" but I'd really prefer the default to try be the most
> >> >> >> appropriate encoding, which is not numeric in this case.
> >> >> >>
> >> >> >> Proposal: use numeric but still - rather than taking the
> milliseconds
> >> >> >> from epoch, take the resulting number from YYYYMMDD ? It might
> even be
> >> >> >> the most efficient encoding, as you don't have the drawback of
> >> >> >> clustering which we would have with a numeric encoding working on
> the
> >> >> >> individual fields, and doesn't have the bloat of string encoding.
> >> >> >>
> >> >> >> >>
> >> >> >> >> +1
> >> >> >> >>
> >> >> >> >> > What do you suggest we do if a user maps the following?
> >> >> >> >>
> >> >> >> >> >   @DateBridge(resolution=MILLISECOND)
> >> >> >> >> >   LocalDate birthday;
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Nothing really,
> >> >> >> >> I would just consider a LocalDate the same as a LocalDateTime
> with
> >> >> time
> >> >> >> >> 00:00:000 (UTC time zone)
> >> >> >>
> >> >> >> Ok that works but why write all those zeros in the index, when
> you can
> >> >> >> just write the date. I realize storage is cheap, but still we
> need to
> >> >> >> be careful as the index size affects performance ;-)
> >> >> >>
> >> >> >> Sanne
> >> >> >>
> >> >> >> >>
> >> >> >> >> It is equivalent to:
> >> >> >> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <
> gunnar at hibernate.org
> >> >> >
> >> >> >> >> wrote:
> >> >> >> >>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <
> sanne at hibernate.org>:
> >> >> >> >>>
> >> >> >> >>>> Our current implementation converts Date in the long
> "distance from
> >> >> >> >>>> epoch" to allow correct range-queries treating each Date as
> an
> >> >> >> >>>> instant
> >> >> >> >>>> in time - allowing a universal sorting strategy. But a
> LocalDate is
> >> >> >> >>>> not an instant-in-time.
> >> >> >> >>>>
> >> >> >> >>>> A LocalDate is intentionally oblivious of the timezone; as
> the
> >> >> >> >>>> javadoc
> >> >> >> >>>> states, it's useful for birthdays, i.e. symbolic occurrences
> and
> >> >> >> >>>> potentially legal matters which don't fit into a universal
> sorting
> >> >> >> >>>> model but rather with the local political scene - we would
> need the
> >> >> >> >>>> combo {LocalDate, ZoneId} provided to be able to allow
> sorting
> >> >> across
> >> >> >> >>>> different LocalDate - or simply assume that they are all
> referring
> >> >> to
> >> >> >> >>>> the same Zone.
> >> >> >> >>>>
> >> >> >> >>>
> >> >> >> >>> Right, I had the latter in mind and would use UTC for that
> purpose.
> >> >> >> >>>
> >> >> >> >>>>
> >> >> >> >>>> I think that if the user is using a LocalDate type, he's
> implicitly
> >> >> >> >>>> hinting that the timezone is not relevant for the practical
> use
> >> >> >> >>>> (possibly even wrong); the most faithful representation
> would be
> >> >> the
> >> >> >> >>>> string form in ISO standard format or to encode the
> day,month,year
> >> >> as
> >> >> >> >>>> independent fields? This last detail depends on how it would
> be
> >> >> more
> >> >> >> >>>> efficient to store & query; probably the String format
> YYYYMMDD
> >> >> would
> >> >> >> >>>> be the most efficient internal representation to allow also
> correct
> >> >> >> >>>> sorting.
> >> >> >> >>>>
> >> >> >> >>>> I wouldn't use NumericField(s) in this case, as they are more
> >> >> >> >>>> effective only with larger ranges, while MM and DD are very
> short;
> >> >> >> >>>> not
> >> >> >> >>>> sure if it's worth splitting the year as a NumericField
> either, as
> >> >> >> >>>> the
> >> >> >> >>>> values will likely be strongly clustered in the same range of
> >> >> "recent
> >> >> >> >>>> years" - although that might depend on the application but it
> >> >> doesn't
> >> >> >> >>>> seem worth the complexity, so I'd index & store as a String
> >> >> YYYYMMDD.
> >> >> >> >>>>
> >> >> >> >>>
> >> >> >> >>> Agreed that this makes most sense, given the "symbolic"
> nature of
> >> >> >> >>> LocalDate.
> >> >> >> >>>
> >> >> >> >>> What would you do though in case of the following:
> >> >> >> >>>
> >> >> >> >>>     @DateBridge
> >> >> >> >>>     LocalDate myDate;
> >> >> >> >>>
> >> >> >> >>> encoding() defaults to NUMERIC, so would you a) raise an
> error, or
> >> >> b)
> >> >> >> >>> ignore encoding() for LocalDate and friends? Both seem not
> right to
> >> >> >> >>> me. I
> >> >> >> >>> think there is nothing wrong with using NUMERIC encoding
> per-se for
> >> >> >> >>> these
> >> >> >> >>> types. We may recommend STRING but if NUMERIC really is what
> a user
> >> >> >> >>> wants I
> >> >> >> >>> would let them do so.
> >> >> >> >>>
> >> >> >> >>>>
> >> >> >> >>>> -- Sanne
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>> On 5 August 2015 at 11:10, Gunnar Morling <
> gunnar at hibernate.org>
> >> >> >> >>>> wrote:
> >> >> >> >>>> > Hi,
> >> >> >> >>>> >
> >> >> >> >>>> > What's the motivation for using a different representation
> in
> >> >> that
> >> >> >> >>>> case?
> >> >> >> >>>> >
> >> >> >> >>>> > For the sake of consistency, I'd use milli seconds since
> >> >> 1970-01-01
> >> >> >> >>>> across
> >> >> >> >>>> > the board. Otherwise it'll be more difficult to compare
> fields
> >> >> >> >>>> > created
> >> >> >> >>>> from
> >> >> >> >>>> > properties of different date types.
> >> >> >> >>>> >
> >> >> >> >>>> > --Gunnar
> >> >> >> >>>> >
> >> >> >> >>>> >
> >> >> >> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <
> davide at hibernate.org>:
> >> >> >> >>>> >
> >> >> >> >>>> >> Hi,
> >> >> >> >>>> >> I started to work on the creation of the bridges for the
> classes
> >> >> >> >>>> >> in
> >> >> >> >>>> the
> >> >> >> >>>> >> java.time package.
> >> >> >> >>>> >>
> >> >> >> >>>> >> I was wondering if we want to convert the values to long
> using
> >> >> the
> >> >> >> >>>> existing
> >> >> >> >>>> >> approach we have now for java.util.Date.
> >> >> >> >>>> >>
> >> >> >> >>>> >> In Hibernate Search a java.util.Date is converted into a
> long
> >> >> that
> >> >> >> >>>> >> represents the number of milliseconds since January 1,
> 1970,
> >> >> >> >>>> >> 00:00:00
> >> >> >> >>>> GMT
> >> >> >> >>>> >> using getTime().
> >> >> >> >>>> >>
> >> >> >> >>>> >> The same value can be obtain from a java.time.LocaDate
> via:
> >> >> >> >>>> >>
> >> >> >> >>>> >>         long epochMilli = date.atStartOfDay(
> ZoneOffset.UTC
> >> >> >> >>>> >> ).toInstant().toEpochMilli();
> >> >> >> >>>> >>
> >> >> >> >>>> >> LocalDate has a method that returns the same value
> expressed in
> >> >> >> >>>> number of
> >> >> >> >>>> >> days:
> >> >> >> >>>> >>
> >> >> >> >>>> >>         long epochDay = date.toEpochDay();
> >> >> >> >>>> >>
> >> >> >> >>>> >>
> >> >> >> >>>> >> I would use the second approach
> >> >> >> >>>> >>
> >> >> >> >>>> >> Davide
> >> >> >> >>>> >> _______________________________________________
> >> >> >> >>>> >> hibernate-dev mailing list
> >> >> >> >>>> >> hibernate-dev at lists.jboss.org
> >> >> >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >> >>>> >>
> >> >> >> >>>> > _______________________________________________
> >> >> >> >>>> > hibernate-dev mailing list
> >> >> >> >>>> > hibernate-dev at lists.jboss.org
> >> >> >> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >> >>>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> > _______________________________________________
> >> >> >> > hibernate-dev mailing list
> >> >> >> > hibernate-dev at lists.jboss.org
> >> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >> _______________________________________________
> >> >> >> hibernate-dev mailing list
> >> >> >> hibernate-dev at lists.jboss.org
> >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >
> >> >> >
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Aug 10 07:36:58 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 10 Aug 2015 12:36:58 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CADGJaX8zzL5MHE5NPoiw_Sr856d1ZS6dYDpA4uJZvuNFgis5ew@mail.gmail.com>
References: <CADGJaX__EtS6TEnoA55c8=0vLNu-h0rQysqSrU_BWOJ1zSjp-A@mail.gmail.com>
	<CAFm4XO3Gwr-8md0PFSA8XkEV4yrCzS-mKByrN=Rbf6uCJbQ0gg@mail.gmail.com>
	<CADGJaX_4DSTGhsGA4MSDCXFZ4KzBKeRYHJ5ukuxPH0YXzJFxRA@mail.gmail.com>
	<CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
	<CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
	<CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>
	<20150810100400.GA33812@Nineveh.local>
	<CAFm4XO3gtVGK-igyTbh8cAN5KNkXprgpC478rtsRg-pxVtm7Nw@mail.gmail.com>
	<CADGJaX8zzL5MHE5NPoiw_Sr856d1ZS6dYDpA4uJZvuNFgis5ew@mail.gmail.com>
Message-ID: <CAFm4XO3rKLRVLAny0K7qoRuteqd0nYRffWgSukxDcXUqbhLHzA@mail.gmail.com>

On 10 August 2015 at 12:16, Gunnar Morling <gunnar at hibernate.org> wrote:
>> With these new types,backwards compatibility is a non-issue. So unless
>> someone makes a strong case for needing these as String in the index,
>> what about we drop some complexity?
>
> ElasticSearch uses Strings for transferring dates in JSON structures
> (see https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html).
> So for that backend we'll need String-mapping field bridges (and we'd
> even have to ignore/override/flag as error the user's setting for
> numeric mapping).

Ok that sounds like another good reason to not provide a user option
to choose the encoding type, and we'll make appropriate choices.

Sanne

From hardy at hibernate.org  Mon Aug 10 08:20:53 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 10 Aug 2015 14:20:53 +0200
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <CANoTJYMTVi4j1_68KWtMwAdG_fB0343vNvm89cKHvXp-RJrq4Q@mail.gmail.com>
References: <CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
	<CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
	<CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>
	<20150810100400.GA33812@Nineveh.local>
	<CAFm4XO3gtVGK-igyTbh8cAN5KNkXprgpC478rtsRg-pxVtm7Nw@mail.gmail.com>
	<CANoTJYMTVi4j1_68KWtMwAdG_fB0343vNvm89cKHvXp-RJrq4Q@mail.gmail.com>
Message-ID: <20150810122053.GB34710@Nineveh.local>

On Mon, Aug 10, 2015 at 12:34:33PM +0100, Davide D'Alto wrote:
> I'm not sure there is an easy way to convert Instant and DateTime to a
> numeric value.
> The problem is that the resolution for temporal types is nanoseconds, the
> following datetime is valid:
> 
> year: -999.999.999
> month: 12
> day: 31
> hour: 23
> minute: 59
> second: 59
> nanos: 999.999.999
> 
> It gets more complicated when we need to store Offset or time zone.

Why not just call Instant#toEpochMilli. I thought we agreed that for instant
based time we stick to epoch time. There might be a loss in resolution, but
I think this is fine in our case.

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

From smarlow at redhat.com  Mon Aug 10 09:40:26 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 10 Aug 2015 09:40:26 -0400
Subject: [hibernate-dev] new proposal for tx timeout handling using
 transaction DISASSOCIATING event notification...
In-Reply-To: <CAFdSV9u4vtwN6tCh2sNf9f01KQdAX-SQ+eZqMJYi0bzxhP6otQ@mail.gmail.com>
References: <54FDE444.8060804@redhat.com>
	<CAFdSV9umV82vr+6gAnGphnO6NhhqrHisWHYA63kw5VvGHss4Qw@mail.gmail.com>
	<54FF1756.4040400@redhat.com>
	<CAFdSV9u+5oeJANhWDBQu-QiMg1qY7SvvDaKmzpsyYjbcKT_-wQ@mail.gmail.com>
	<54FF2F21.6000704@redhat.com> <55C4DD2B.60209@redhat.com>
	<CAFdSV9u4vtwN6tCh2sNf9f01KQdAX-SQ+eZqMJYi0bzxhP6otQ@mail.gmail.com>
Message-ID: <55C8A9CA.3000202@redhat.com>



On 08/07/2015 02:41 PM, Steve Ebersole wrote:
> Yeah, which is great when you can rely on impl-specific apis.

Agreed.  I'm not sure of what we should do when ORM is running in 
environments that cannot rely on a NarayanaJtaPltaform.  Especially, 
when every call into Hibernate ORM is from a different thread (e.g. 
remote EJB invocations).

I think the below idea of deferring to the JtaPlatform to indicate the 
"type of timeout tracking" to do, is the best approach.

>
> I'll consider this, but its not super high on my priority list.  I guess
> we could implement some kind of way for the JtaPlatform to indicate the
> "type of timeout tracking" to do and develop a new NarayanaJtaPltaform
> that does this.

Is this more of an ORM 5.1 or 6.0 change?

>
>
> On Fri, Aug 7, 2015 at 11:30 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     https://github.com/wildfly/wildfly/pull/7909 uses the Narayana
>     org.jboss.tm.listener.TransactionListenerRegistry to be notified when
>     the transaction is associated/deassociated with the JTA transaction.
>
>     I think that Hibernate ORM could do something similar with the
>     org.jboss.tm.listener.TransactionListenerRegistry to protect against
>     clearing the persistence context from a non-application thread, while
>     the application thread may be actively using the persistence context.
>
>     I think this approach is simpler than the thread id tracking.
>
>     On 03/10/2015 01:51 PM, Scott Marlow wrote:
>      >>
>      >> So what is this buying us?
>      >>
>      >
>      > The current Hibernate ORM thread id checking, does not properly
>     handle
>      > the case when the application thread changes between calls to the
>      > Hibernate session.  The new approach does handle the application
>     thread
>      > changing between session invocations and also covers a few other
>     cases
>      > as well (like clearing the persistence context after the
>     application may
>      > of added another entity after the background thread rolled back the
>      > transaction).
>      > _______________________________________________
>      > hibernate-dev mailing list
>      > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >
>

From gunnar at hibernate.org  Mon Aug 10 12:10:41 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 10 Aug 2015 18:10:41 +0200
Subject: [hibernate-dev] [HSEARCH] Wanted: JavaDoc for
	ExtendedSearchIntegrator#getIndexedTypesPolymorphic()
Message-ID: <CADGJaX8A9bnVpWBfnRC098DcNk5L0RR6RCxU=ZjsyWDxRnq4fw@mail.gmail.com>

Hi,

Could someone give me a one-sentence definition of what's the method
named above is supposed to do? Its name gives me some ideas, but I'd
love to see a proper documentation of the intended behaviour there.

Thanks,

--Gunnar

From sanne at hibernate.org  Mon Aug 10 12:30:36 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 10 Aug 2015 17:30:36 +0100
Subject: [hibernate-dev] [HSEARCH] Wanted: JavaDoc for
	ExtendedSearchIntegrator#getIndexedTypesPolymorphic()
In-Reply-To: <CADGJaX8A9bnVpWBfnRC098DcNk5L0RR6RCxU=ZjsyWDxRnq4fw@mail.gmail.com>
References: <CADGJaX8A9bnVpWBfnRC098DcNk5L0RR6RCxU=ZjsyWDxRnq4fw@mail.gmail.com>
Message-ID: <CAFm4XO3F5j5An3hugGw4P3i-D4KeWjEtoTtKy269hR40qBNe=A@mail.gmail.com>

open a JIRA, assign it to me and I'll send a pull request ;)

On 10 August 2015 at 17:10, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> Could someone give me a one-sentence definition of what's the method
> named above is supposed to do? Its name gives me some ideas, but I'd
> love to see a proper documentation of the intended behaviour there.
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon Aug 10 16:32:44 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 10 Aug 2015 22:32:44 +0200
Subject: [hibernate-dev] [HSEARCH] Wanted: JavaDoc for
	ExtendedSearchIntegrator#getIndexedTypesPolymorphic()
In-Reply-To: <CAFm4XO3F5j5An3hugGw4P3i-D4KeWjEtoTtKy269hR40qBNe=A@mail.gmail.com>
References: <CADGJaX8A9bnVpWBfnRC098DcNk5L0RR6RCxU=ZjsyWDxRnq4fw@mail.gmail.com>
	<CAFm4XO3F5j5An3hugGw4P3i-D4KeWjEtoTtKy269hR40qBNe=A@mail.gmail.com>
Message-ID: <CADGJaX8tfsRtiaUeKYaVsuv3=3=_67vDDPzQ9qmqHyrsCh8DZw@mail.gmail.com>

Deal: https://hibernate.atlassian.net/browse/HSEARCH-1959

Feel free to merge the PR yourself ;)

Thanks!

2015-08-10 18:30 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> open a JIRA, assign it to me and I'll send a pull request ;)
>
> On 10 August 2015 at 17:10, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hi,
>>
>> Could someone give me a one-sentence definition of what's the method
>> named above is supposed to do? Its name gives me some ideas, but I'd
>> love to see a proper documentation of the intended behaviour there.
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Mon Aug 10 18:18:59 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 10 Aug 2015 23:18:59 +0100
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
 new mapping annotations ?
In-Reply-To: <CAH8Ud1H9fwzV-E4V3SKc_HrKXiPwPA=LkMpeWdwG-NJjLqhRyg@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
	<CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
	<CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>
	<CADGJaX9+wnnhLuLim8AY=qS2bvPq_5r=pr-h99Q2dXZDOTOeMw@mail.gmail.com>
	<CAFm4XO3bC-j7r1i3HMJ==T9NFr-oYweYOSxEn3nxtY8KQU6qHg@mail.gmail.com>
	<CAH8Ud1H9fwzV-E4V3SKc_HrKXiPwPA=LkMpeWdwG-NJjLqhRyg@mail.gmail.com>
Message-ID: <CAFm4XO3qGHaZde5+XBxp41P8dd_L4Wm32pYvOvxZRgfeJDikhQ@mail.gmail.com>

On 7 August 2015 at 13:31, Gustavo Fernandes <gustavo at infinispan.org> wrote:
> On Fri, Aug 7, 2015 at 1:14 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> A quick update on some more exploration on this:
>> it turns out sorting on a NumericField when this field is also using
>> an "indexNullAs" token gets the UninvertingReader approach to throw an
>> exception.
>> My two conclusions:
>>  - we need to move away from supporting those tokens in NumericField,
>> especially as stricter schema is coming in next gen Lucene
>>  - yet another reason to clearly separate fields meant for searching vs
>> sorting
>
>
> One possible workaround is to enforce the indexNullAs value to match the
> underlying field type, at the
> moment it is always a string.

Interesting idea, but the user would need to provide which "value"
he's ok to give up, as he would need to pick a number to be treated as
NaN.
Since the indexNullAs parameter requires a string, would we expect
people to write a number in there?

> Another possibility is to model "null" as field not present in the lucene
> document, instead of a marker token.

Thanks! I've run some tests with this and have a patch working based
on this idea; I was sceptical initially because of scoring, but it
seems it's doable without needing to score all documents on this
negation. I'll send a PR soon; basically with this approach the
indexNullAs attribute will be ignored, but it's ok I think as this
solution is better and there's no drawback (nor needing any user
configuration).

Sanne

From sanne at hibernate.org  Mon Aug 10 19:30:46 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 11 Aug 2015 00:30:46 +0100
Subject: [hibernate-dev] [HSEARCH] Wanted: JavaDoc for
	ExtendedSearchIntegrator#getIndexedTypesPolymorphic()
In-Reply-To: <CADGJaX8tfsRtiaUeKYaVsuv3=3=_67vDDPzQ9qmqHyrsCh8DZw@mail.gmail.com>
References: <CADGJaX8A9bnVpWBfnRC098DcNk5L0RR6RCxU=ZjsyWDxRnq4fw@mail.gmail.com>
	<CAFm4XO3F5j5An3hugGw4P3i-D4KeWjEtoTtKy269hR40qBNe=A@mail.gmail.com>
	<CADGJaX8tfsRtiaUeKYaVsuv3=3=_67vDDPzQ9qmqHyrsCh8DZw@mail.gmail.com>
Message-ID: <CAFm4XO2evTkZpcrtOFaR6RyXAqWs_Ty2j6jCYuz_v=z_GbA27Q@mail.gmail.com>

On 10 August 2015 at 21:32, Gunnar Morling <gunnar at hibernate.org> wrote:
> Deal: https://hibernate.atlassian.net/browse/HSEARCH-1959
>
> Feel free to merge the PR yourself ;)

Thanks, done! Had to add a test to figure out some corner cases...
will be useful when we'll move away from class type based
polymorphispm (free-form).

Cheers

>
> Thanks!
>
> 2015-08-10 18:30 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> open a JIRA, assign it to me and I'll send a pull request ;)
>>
>> On 10 August 2015 at 17:10, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> Hi,
>>>
>>> Could someone give me a one-sentence definition of what's the method
>>> named above is supposed to do? Its name gives me some ideas, but I'd
>>> love to see a proper documentation of the intended behaviour there.
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gustavo at infinispan.org  Tue Aug 11 04:14:52 2015
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Tue, 11 Aug 2015 09:14:52 +0100
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
	new mapping annotations ?
In-Reply-To: <CAFm4XO3qGHaZde5+XBxp41P8dd_L4Wm32pYvOvxZRgfeJDikhQ@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
	<CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
	<CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>
	<CADGJaX9+wnnhLuLim8AY=qS2bvPq_5r=pr-h99Q2dXZDOTOeMw@mail.gmail.com>
	<CAFm4XO3bC-j7r1i3HMJ==T9NFr-oYweYOSxEn3nxtY8KQU6qHg@mail.gmail.com>
	<CAH8Ud1H9fwzV-E4V3SKc_HrKXiPwPA=LkMpeWdwG-NJjLqhRyg@mail.gmail.com>
	<CAFm4XO3qGHaZde5+XBxp41P8dd_L4Wm32pYvOvxZRgfeJDikhQ@mail.gmail.com>
Message-ID: <12CD431E-57EF-45FC-B000-08575565D014@infinispan.org>


> On 10 Aug 2015, at 23:18, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> On 7 August 2015 at 13:31, Gustavo Fernandes <gustavo at infinispan.org <mailto:gustavo at infinispan.org>> wrote:
>> On Fri, Aug 7, 2015 at 1:14 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> 
>>> A quick update on some more exploration on this:
>>> it turns out sorting on a NumericField when this field is also using
>>> an "indexNullAs" token gets the UninvertingReader approach to throw an
>>> exception.
>>> My two conclusions:
>>> - we need to move away from supporting those tokens in NumericField,
>>> especially as stricter schema is coming in next gen Lucene
>>> - yet another reason to clearly separate fields meant for searching vs
>>> sorting
>> 
>> 
>> One possible workaround is to enforce the indexNullAs value to match the
>> underlying field type, at the
>> moment it is always a string.
> 
> Interesting idea, but the user would need to provide which "value"
> he's ok to give up, as he would need to pick a number to be treated as
> NaN.
> Since the indexNullAs parameter requires a string, would we expect
> people to write a number in there?


I?m not sure if uninverting a field containing a mix of string/numeric values will be supported again in Lucene. 
Maybe it will [1], maybe not, in the meantime, the indexNullAs would need at least to be parseable to a number by the
underlying field bridge. Many use cases allows for NaN to be a number itself without problems.

[1] https://issues.apache.org/jira/browse/SOLR-7521 <https://issues.apache.org/jira/browse/SOLR-7521>
> 
>> Another possibility is to model "null" as field not present in the lucene
>> document, instead of a marker token.
> 
> Thanks! I've run some tests with this and have a patch working based
> on this idea; I was sceptical initially because of scoring, but it
> seems it's doable without needing to score all documents on this
> negation. I'll send a PR soon; basically with this approach the
> indexNullAs attribute will be ignored, but it's ok I think as this
> solution is better and there's no drawback (nor needing any user
> configuration).
> 

+1

Gustavo


From gunnar at hibernate.org  Tue Aug 11 10:39:27 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 11 Aug 2015 16:39:27 +0200
Subject: [hibernate-dev] [Hibernate Search] Database back end worker
In-Reply-To: <CAFm4XO13sxa0KQ=rX5QKiyhYP50fdB1SJHML9dRk8cjZ-4g+Zw@mail.gmail.com>
References: <CAFP3+ykfZk77_VU2nByfFkaY43nA7KG06kbb4ZZ+dKVKJ3LBgA@mail.gmail.com>
	<14efd4b452c-7fae-3686d@webprd-m59.mail.aol.com>
	<CAFP3+ymhTwU+T=o+cnsV6kHhh5cpL27HWh2S6AFQsxALYEXCQQ@mail.gmail.com>
	<CAFm4XO2a0gKu2nrOG6_hynA7hXRa+L0xvM4x9GSqmO_wERKKEA@mail.gmail.com>
	<CAFP3+ykRUKDfFTCzb-8PXe1CWB0sa2O7FgM2e9TTsYswBG_gqQ@mail.gmail.com>
	<CAFm4XO13sxa0KQ=rX5QKiyhYP50fdB1SJHML9dRk8cjZ-4g+Zw@mail.gmail.com>
Message-ID: <CADGJaX_wGYheSEY_uvGtfEDV4Q684_TBxm_xs-Kxs9r92PYemg@mail.gmail.com>

+1 for the idea of the database-based backend. Seems very useful.

One idea for improvement may be to group on (entity-type,id) and only
select the latest LuceneDatabaseWork per id. That way you'd avoid
propagation of potentially outdated index updates.

2015-08-09 17:51 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> Hi,
> yes creating issues on JIRA is what we normally do, feel free to create them!
>
> They don't have to be sub-stasks; we use subtasks when there are
> several "blocker" steps which need to be accomplished to get a feature
> and it's so large that it needs to be split.
> In this case I'd make a single JIRA for the new feature - which gets
> resolved when we'll merge it in its most essential form - and further
> improvement ideas can be created now or as needed as independent
> improvements.
>
> Thanks!
> Sanne
>
> On 9 August 2015 at 06:56, Flemming Harms <flemming.harms at gmail.com> wrote:
>>
>>
>> 2015-08-05 23:38 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>>
>>> Hi Flemming,
>>> welcome on this list!
>>>
>>> I waited a bit to reply myself, as you already know I like the
>>> proposal. Unfortunately many others are on holidays, so other feedback
>>> might be slow.
>>>
>>> Still I wouldn't let that slow you down and start the works for
>>> merging it; I already anticipated over chat that this would come and
>>> we all agree that the concept is useful!
>>> I don't think others looked at the details yet, but if it comes to
>>> concerns at that level, we can address smaller issues incrementally.
>>> (I also didn't look at micro-details, as it's easier to comment on
>>> those on a pull request).
>>>
>>> I had the same question as Martin regarding clustering: with the
>>> current implementation you expect something like the master/slave
>>> configuration, or Infinispan to be used as storage, correct?
>>> I also think it would be interesting to explore the approach further
>>> to also - optionally - serve as a replacement for these, but that's
>>> another feature which is easier to experiment with after the core
>>> concept is merged.
>>
>>
>>>
>>> Yes that's correct. To start with it was written very specific to the use
>>> of Infinispan as directory.
>>
>> And I agree on we should explore other cluster configuration and I have some
>> ideas how we can implement it.
>>>
>>> .
>>>
>>>
>>> In short, I would simply merge your backend as a new module in
>>> Hibernate Search! Fork our repository, and send a pull request.
>>>
>>> # Code layout / Modules
>>>
>>> In terms of code structure, you might have noticed that the module
>>> 'hibernate-search-engine' (/engine in the source code) does not depend
>>> on JPA nor Hibernate ORM; the reason is that other projects reuse the
>>> core indexing strategy and the backends. Since it would be nice to
>>> allow them to optionally use your backend, still not mandate a
>>> dependency on ORM for those who don't, I think this should be a new
>>> Maven module.
>>>
>>> We already have
>>>  /backends/jgroups
>>>  /backends/jms
>>>
>>> So we could add (name to be refined?) :
>>>  /backends/relationaldb
>>
>> sure, no problem :)
>>>
>>>
>>> Also, your integration tests probably should be moved together with
>>> our other integration tests. They are currently running WildFly
>>> 10.0.0.Alpha6, but that shouldn't be a problem.
>>>
>>> # Code Style
>>>
>>> We use tabs ;-)
>>> And also have various other "exotic" conventions regarding white-space
>>> usage, right header files, etc..
>>> We use CheckStyle to keep it tidy, it will give you lots of errors and
>>> when there are many it's not very helpful; I would suggest to take the
>>> formatting templates attached at the following link and use your IDE's
>>> formatting capabilities, resort to checkstyle just for the final
>>> validation:
>>>  - http://hibernate.org/search/contribute/
>>>
>>> # JDK
>>>
>>> It looks like your extension requires Java 8; if you could convert it
>>> to Java 7 that would be nice.
>>
>> Don't think it will be an issue. As far I remember we don't use any Java8
>> specific functionality
>>>
>>>
>>> # Rebasing to latest
>>>
>>> I'm afraid we're now aiming at Hibernate ORM 5, so some details might
>>> need to be updated; probably just in the configuration area. We're
>>> also in the process of upgrading to Apache Lucene 5, but that
>>> shouldn't affect you at all.
>>>
>>> # Some improvement ideas
>>>
>>> While we should support the case in which Hibernate Search is not
>>> being run as an extension of Hibernate ORM, that's likely the most
>>> common one.
>>> In that scenario I think it would be nice to be able to lookup the
>>> existing ORM services so that users don't need to repeat for example
>>> the datasource configuration.
>>>
>>> We might also be able to reuse all of the SessionFactory, but I'm not
>>> sure how to include your model without it potentially interfering with
>>> the end user's model; I'd say let's start by sharing some services
>>> from ORM and then see what kind of improvements we can build into ORM
>>> for this use case; for example this might simplify some of the
>>> TransactionManager configuration code I'm seeing in your repository.
>>>
>>> Of course your existing configuration properties are useful too,
>>> especially for the non-ORM case as we'll need be able to reuse the ORM
>>> services.
>>>
>>> Also, you might have noticed we are now able to optionally include the
>>> backend operations in the same transaction. That's not the default, as
>>> commonly people don't want that, but it would be very interesting to
>>> evolve this backend to support that option too, you wouldn't even
>>> require XA when storing the entity in the same database!
>>>  - http://in.relation.to/2015/07/09/hibernate-search-jms-transaction/
>>>
>> Yes, it's very nice feature and fit perfectly with relationaldb
>>>
>>> I'd be happy to help with this, feel free to share non-working and/or
>>> intermediate experimental branches when having questions or just
>>> stuck.
>>> Please start by creating a JIRA, you can leave the target version
>>> undefined: we'll merge it when it's ready.
>>>
>> For all the task you have listed can I create sub task to the JIRA, or how
>> do you track tasks?
>>
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 5 August 2015 at 20:05, Flemming Harms <flemming.harms at gmail.com>
>>> wrote:
>>> > Hi Martin
>>> >
>>> > For this version the AbstractDatabaseHibernateSearchController is not
>>> > able
>>> > to process Lucene workers simultaneously. When we build it our initial
>>> > requirement was only one node should process the workers at a time, but
>>> > the
>>> > ?master? was floating. We use Quartz to get this type of functionality
>>> > and
>>> > it will synchronizing the execution between the nodes. But you could
>>> > also
>>> > use an HA-singleton to dedicate a specific node to process the workers.
>>> >
>>> > We had been playing with an idea where we stamp the LuceneDatabaseWork
>>> > with
>>> > the known cluster nodes, and then the last node will remove it from the
>>> > database or a scheduled job can take care of it. The advance of this
>>> > solution is it will make Infinispan optional, and it can store the
>>> > indexes
>>> > on each node instead in a shared cache.
>>> >
>>> > Your idea and work look very nice. Pretty awesome feature to support
>>> > different JPA providers.
>>> >
>>> > --
>>> > cheers
>>> > Flemming
>>> >
>>> >
>>> > 2015-08-05 11:57 GMT+02:00 Martin Braun <martinbraun123 at aol.com>:
>>> >
>>> >> Hi,
>>> >>
>>> >>
>>> >> Note: I am no core developer of Hibernate Search, but I am currently
>>> >> working on something
>>> >> that looks quite similar to what you are doing :). One part of it is an
>>> >> updating mechanism based on triggers
>>> >> that uses the database as a event-storage as well. It's not the exact
>>> >> same
>>> >> thing, but related.
>>> >>
>>> >>
>>> >> https://github.com/Hotware/Hibernate-Search-JPA
>>> >>
>>> >>
>>> >>
>>> >> The idea is quite nice, but after looking at the sourcecode I am
>>> >> wondering
>>> >> how the different nodes are able to work together, because in
>>> >> AbstractDatabaseHibernateSearchController you remove the entity
>>> >> from the persistence context and I wasn't able to find code that would
>>> >> make up for that.
>>> >>
>>> >>
>>> >> Doesn't that mean that the other workers will not be able to read that
>>> >> entity?
>>> >> Or will users of this need to implement their own synchronization
>>> >> mechanism between
>>> >> the different nodes?
>>> >>
>>> >>
>>> >> Martin Braun
>>> >> martinbraun123 at aol.com
>>> >> www.github.com/s4ke
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: Flemming Harms <flemming.harms at gmail.com>
>>> >> To: Hibernate.org <hibernate-dev at lists.jboss.org>
>>> >> Sent: Tue, Aug 4, 2015 6:40 pm
>>> >> Subject: [hibernate-dev] [Hibernate Search] Database back end worker
>>> >>
>>> >>
>>> >> Hey guys
>>> >>
>>> >> I want to introduce myself and a new database back-end worker, me
>>> >> and
>>> >> another guy have build for hibernate search. I already had some initial
>>> >> talk
>>> >> with Sanne regarding if this could be interested to the hibernate
>>> >> search
>>> >> project.
>>> >>
>>> >> I have been working with Hibernate Search from some time and actually
>>> >> done
>>> >> various small custom modification to search since 3.x, especial
>>> >> around
>>> >> running in a cluster and indexing. To make a long story short when
>>> >> we
>>> >> upgraded Hibernate search we thought it would be ideal to use a SQL
>>> >> database
>>> >> as storage for lucene workers for 3 main reasons.
>>> >>
>>> >> - The database was shared
>>> >> between the nodes
>>> >> - The workers was persistent in case of a node crash.
>>> >> - No
>>> >> master/slave
>>> >>
>>> >>
>>> >> *In some way it?s very similar to the JMS back-end worker, where
>>> >> the user
>>> >> also have to implement a MDB that process the workers. In our case
>>> >> they
>>> >> will have to implement a job using something like quartz or a
>>> >> timer
>>> >> service. *
>>> >>
>>> >> *We are using JPA as persistence layer for the database, even
>>> >> it?s a fairly
>>> >> simple entity we persistent, but it make sense for supporting
>>> >> various
>>> >> databases and schema update out of the box. We have tried to make it?s
>>> >> as
>>> >> easy as possible to set-up by minimizing the number of properties, and
>>> >> it?s
>>> >> all configurable from the persistence.xml*
>>> >>
>>> >> *The actually work can* be
>>> >> *find
>>> >> here
>>> >> https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
>>> >>
>>> >> <https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend>*
>>> >>
>>> >>
>>> >>
>>> >> *So
>>> >> based on this introduction and the code, is this something you could
>>> >> use? (of
>>> >> course with the modification it requires to follow the design,
>>> >> style, docs etc
>>> >> for the search)*--
>>> >>
>>> >> Kind regards
>>> >> Flemming
>>> >> Harms
>>> >> _______________________________________________
>>> >> hibernate-dev mailing
>>> >> list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > Kind regards / Med Venlig Hilsen
>>> > Flemming Harms
>>> >
>>> >    -
>>> >
>>> > https://twitter.com/fnharms
>>> > https://dk.linkedin.com/in/fharms
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>
>>
>> --
>>
>> Kind regards / Med Venlig Hilsen
>> Flemming Harms
>>
>> https://twitter.com/fnharms
>> https://dk.linkedin.com/in/fharms
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Tue Aug 11 12:05:27 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 11 Aug 2015 17:05:27 +0100
Subject: [hibernate-dev] Hibernate Search 5.5.0.Alpha1 now available
Message-ID: <CAFm4XO0oPxsawOkZoYoLWJ+wAn0-uJAcSfHEhhyGhCPjtcfMaw@mail.gmail.com>

The highlight is that it's using Apache Lucene 5.2.1 now.

As I mentioned on the blog post, it would be great if someone could
step up and help us by running some benchmarking and performance
comparisons:

 - http://in.relation.to/2015/08/11/Lucene5IsComing

Thanks,
Sanne

From daltodavide at gmail.com  Tue Aug 11 13:33:04 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Tue, 11 Aug 2015 18:33:04 +0100
Subject: [hibernate-dev] HSEARCH Java 8 Date Time
In-Reply-To: <20150810122053.GB34710@Nineveh.local>
References: <CANoTJYNZp92pCM-d7x+oxdWFHHPP8C-qG9_W01Jkmdg6EmsWAA@mail.gmail.com>
	<CANoTJYOZ46-AUR+BZ9SgYiHt4s465TNeFBXGy-XCb2TCUahGVw@mail.gmail.com>
	<CAFm4XO29sJiF1G_qYzfv4ujfLebwfwfmyXDs6X8HBk3u4UPqVg@mail.gmail.com>
	<CADGJaX_O_aJxmpDK=XAS71R+JDHkFS_U=8oBS9aF1uVHEwdBNw@mail.gmail.com>
	<CAFm4XO1UZLp35JJnqqnhKB5duv0gQGhaa3itg82CQWQMG2Z60w@mail.gmail.com>
	<CANoTJYPPmPhgCnu6phWRJT4BfbpR9dyPNLXTC2RUGjJSq=+mHg@mail.gmail.com>
	<CAFm4XO0yYQwfj6ZTszrv7yw2iY-wpVJc+RHMU-dMqKw86c4oOg@mail.gmail.com>
	<20150810100400.GA33812@Nineveh.local>
	<CAFm4XO3gtVGK-igyTbh8cAN5KNkXprgpC478rtsRg-pxVtm7Nw@mail.gmail.com>
	<CANoTJYMTVi4j1_68KWtMwAdG_fB0343vNvm89cKHvXp-RJrq4Q@mail.gmail.com>
	<20150810122053.GB34710@Nineveh.local>
Message-ID: <CANoTJYPAorHQUgdn++v3uWweCBKBz6TU-piXFv0m_tHnvQti3Q@mail.gmail.com>

I've sent a pull request:
https://github.com/hibernate/hibernate-search/pull/887



Davide

On Mon, Aug 10, 2015 at 1:20 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> On Mon, Aug 10, 2015 at 12:34:33PM +0100, Davide D'Alto wrote:
> > I'm not sure there is an easy way to convert Instant and DateTime to a
> > numeric value.
> > The problem is that the resolution for temporal types is nanoseconds, the
> > following datetime is valid:
> >
> > year: -999.999.999
> > month: 12
> > day: 31
> > hour: 23
> > minute: 59
> > second: 59
> > nanos: 999.999.999
> >
> > It gets more complicated when we need to store Offset or time zone.
>
> Why not just call Instant#toEpochMilli. I thought we agreed that for
> instant
> based time we stick to epoch time. There might be a loss in resolution, but
> I think this is fine in our case.
>
> --Hardy
>

From gunnar at hibernate.org  Wed Aug 12 10:30:21 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 12 Aug 2015 16:30:21 +0200
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
Message-ID: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>

Hibernate Search aficionados,

I am wondering what that's the rationale for offering the feature of
index sharing [1].

The ref guide says "there is really not much benefit in sharing
indexes". It complicates queries, as an additional filter on the type
field must be applied in case of targeting only one entity using a
shared index.

Should we consider to drop this feature in HS 6?

Thanks,

--Gunnar

[1] https://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#section-sharing-indexes

From martinbraun123 at aol.com  Wed Aug 12 11:43:13 2015
From: martinbraun123 at aol.com (Martin Braun)
Date: Wed, 12 Aug 2015 11:43:13 -0400
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
In-Reply-To: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
References: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
Message-ID: <14f229460b0-62a2-4f5bf@webprd-a84.mail.aol.com>

Hi,


I guess it's useful in some edge cases where the user wants to search
different entities with one query. As long as everything is in the same index
scoring is a lot easier (I don't know if it even works otherwise). I guess
that could be done by indexing a common supertype, but sometimes that's not possible.


I don't get the filtering out part though. Doesn't the query API take care of that?
If not, I think it should definitely be doing that (query for the actual class).


cheers,


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




-----Original Message-----
From: Gunnar Morling <gunnar at hibernate.org>
To: hibernate-dev <hibernate-dev at lists.jboss.org>
Sent: Wed, Aug 12, 2015 4:30 pm
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing


Hibernate Search aficionados,

I am wondering what that's the rationale for
offering the feature of
index sharing [1].

The ref guide says "there is
really not much benefit in sharing
indexes". It complicates queries, as an
additional filter on the type
field must be applied in case of targeting only
one entity using a
shared index.

Should we consider to drop this feature in
HS 6?

Thanks,

--Gunnar

[1]
https://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#section-sharing-indexes
_______________________________________________
hibernate-dev
mailing
list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

 

From sanne at hibernate.org  Wed Aug 12 11:46:12 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 12 Aug 2015 16:46:12 +0100
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
In-Reply-To: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
References: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
Message-ID: <CAFm4XO2_DqbX99zKONCXuHQ=fVHqjzOFn0HACgF8_KnyAnaSeA@mail.gmail.com>

That's an interesting proposal, as index sharing inherently implies
that fields on different types shall not have conflicting mapping
(i.e. don't reuse the same field name for a different type).

By default we don't share indexes across unrelated types, but also *by
default* subtypes are indexed in the same index as their parent - if
the parent is indexed as well.

The reason is to efficiently map a polymorphic domain: when people
search for type X, they implicitly also search for its subtypes as
these are valid candidates for the query.
Having them all in the same index makes for better result quality and
better search performance - as joining multiple IndexReaders to
perform a cross - index Query is generally a bad idea, as it's then
hard to accurately normalize statistics across different vector
spaces, and that's what defines the quality of the search result.
At least I believe that *generally* that would give you better
results, but that's why we give options, and also why sometimes people
might want multiple Domain objects to be stored in the same index:
they might be "subtypes" from a domain perspective even if they don't
technically use inheritance at the Java level: they might be different
types and yet be mapped to some common fields with (hopefully)
compatible indexing options.

If we were to drop index sharing, then I think it should be fair to
also not support multiple types as target for a query anymore; as I'm
assuming in this case you'd only share for subtypes of some common
parent, and you'd target that common parent exclusively to perform a
polymorphic query.

So that's the reasons for which it exists; there are some good reasons
to not allow it too: as you mention the filtering, but also the very
fact that the type information has to be stored in form of classname
(typename, in free-form).
I think the strongest reason to not allow it is to avoid the
inconsistent field mappings, but we could compensate for that with
better schema validation - something which seems is getting more
necessary anyway.

I didn't mean to kill the proposal :) just hoping it helps figure out
why someone might need it. Would be nice to think of alternatives out
of the box to avoid the filtering.

Sanne



On 12 August 2015 at 15:30, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hibernate Search aficionados,
>
> I am wondering what that's the rationale for offering the feature of
> index sharing [1].
>
> The ref guide says "there is really not much benefit in sharing
> indexes". It complicates queries, as an additional filter on the type
> field must be applied in case of targeting only one entity using a
> shared index.
>
> Should we consider to drop this feature in HS 6?
>
> Thanks,
>
> --Gunnar
>
> [1] https://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#section-sharing-indexes
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From ks at error.be  Wed Aug 12 16:21:59 2015
From: ks at error.be (Koen Serneels)
Date: Wed, 12 Aug 2015 22:21:59 +0200
Subject: [hibernate-dev] Hibernate5 migration
Message-ID: <009201d0d53c$8a9acfe0$9fd06fa0$@error.be>

Hi,

 

I'm migrating from Hibernate4 to 5(RC4). While doing so I'm stumbling on
some stuff that has been removed or moved.

 

- In Hibernate4 we modified mappings on-the-fly by overriding Spring's
LocalSessionFactoryBean#buildSessionFactory.

Doing so we could first access the getClassMapping on
org.hibernate.cfg.Configuration before letting the SF actually build.

However, in Hibernate5 the metadata access has been refactored and is no
longer part of the Configuration. Should we use MetadataContributor instead
for these purposes?

 

- Is there a way to register MetadataContributor dynamically? I see that it
is being loaded using Java's ServiceLoader.

However, I need some programmatic API access to enable or disable the
Contributor (for example based on Spring profiles).

 

- For JTA integration we were using
org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory, but
this class is no longer present. 

Also in org.hibernate.cfg.AvailableSettings the key that was used
(hibernate.transaction.factory_class) to configure the factory is also
removed. 

Is hibernate.transaction.coordinator_class the new key we should be using
instead with
org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordi
natorImpl as value for JTA? 

Do we need to configure anything special in case of resource local TX or is
JdbcResourceLocalTransactionCoordinatorImpl the default?

 

- generateDropSchemaScript and generateSchemaCreationScript have been
removed from Configuration. Is there a way to access this in another way?

 

Thanks

 

Koen.

 


From golovnin at gmx.net  Wed Aug 12 17:17:41 2015
From: golovnin at gmx.net (Andrej Golovnin)
Date: Wed, 12 Aug 2015 23:17:41 +0200
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
In-Reply-To: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
References: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
Message-ID: <63F329B2-6A03-49B9-9F3F-7CD83E38916B@gmx.net>

Hi Gunnar,

> Should we consider to drop this feature in HS 6?

-1, we use it, I think, in at least 3 places in our application.
Removing it would make our code more complicated.

Best regards,
Andrej Golovnin

From steve at hibernate.org  Wed Aug 12 22:23:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 13 Aug 2015 02:23:58 +0000
Subject: [hibernate-dev] Hibernate5 migration
In-Reply-To: <009201d0d53c$8a9acfe0$9fd06fa0$@error.be>
References: <009201d0d53c$8a9acfe0$9fd06fa0$@error.be>
Message-ID: <CAFdSV9sxCmUGz71whp0XB0UF_AbR2y-aPL4euWS0VZ3eg2xdsA@mail.gmail.com>

There is a migration guide:
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md.
It is still a work in progress as in its is not "prettified" yet (as 5.0 is
not final yet.  If things are missing please let us know.

Some answers inline...


- In Hibernate4 we modified mappings on-the-fly by overriding Spring's
> LocalSessionFactoryBean#buildSessionFactory.


> Doing so we could first access the getClassMapping on
> org.hibernate.cfg.Configuration before letting the SF actually build.
>
> However, in Hibernate5 the metadata access has been refactored and is no
> longer part of the Configuration. Should we use MetadataContributor instead
> for these purposes?
>


Depends what you are trying to achieve specifically.  What do you mean by
"modify"?  Do you mean literally that you want to modify (alter) the
existing "class mappings", or do you really mean that you want to add
additional mappings?


- Is there a way to register MetadataContributor dynamically? I see that it
> is being loaded using Java's ServiceLoader.
>
> However, I need some programmatic API access to enable or disable the
> Contributor (for example based on Spring profiles).
>

No there is not a way to register a MetadataContributor programatically.  I
really do not see the benefit of having that as a feature.  Maybe you need
to explain better?  But if a piece of code is able to determine whether or
not to register a MetadataContributor, it could simply contribute said
metadata, no?


- For JTA integration we were using
> org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory, but
> this class is no longer present.
>
> Also in org.hibernate.cfg.AvailableSettings the key that was used
> (hibernate.transaction.factory_class) to configure the factory is also
> removed.
>
> Is hibernate.transaction.coordinator_class the new key we should be using
> instead with
>
> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordi
> natorImpl as value for JTA?
>

Yes, but I would highly recommend using the short-name config values, e.g.:

hibernate.transaction.coordinator_class=jta

rather than:

hibernate.transaction.coordinator_class=org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl

Both do the same thing, the first form is just better (for many reasons).



> Do we need to configure anything special in case of resource local TX or is
> JdbcResourceLocalTransactionCoordinatorImpl the default?
>

I'm confused with this last piece in combination with the rest of the
questions here.  The rest of the block discusses JTA, but then here you are
asking about JDBC-based transactions.  Regardless, the default
TransactionCoordinator is in fact the JDBC one.


- generateDropSchemaScript and generateSchemaCreationScript have been
> removed from Configuration. Is there a way to access this in another way?
>

Again, depends on exactly what you hope to accomplish here.  Your main
options will be either:
1) grab the org.hibernate.tool.schema.spi.SchemaManagementTool from the
StandardServiceRegistry and use it to obtain the SchemaCreator
and SchemaDropper, passing them the Metadata.
2) Use the org.hibernate.tool.hbm2ddl.SchemaExport class

From ks at error.be  Thu Aug 13 00:48:33 2015
From: ks at error.be (Koen Serneels)
Date: Thu, 13 Aug 2015 06:48:33 +0200
Subject: [hibernate-dev] Hibernate5 migration
In-Reply-To: <CAFdSV9sxCmUGz71whp0XB0UF_AbR2y-aPL4euWS0VZ3eg2xdsA@mail.gmail.com>
References: <009201d0d53c$8a9acfe0$9fd06fa0$@error.be>
	<CAFdSV9sxCmUGz71whp0XB0UF_AbR2y-aPL4euWS0VZ3eg2xdsA@mail.gmail.com>
Message-ID: <00a201d0d583$4f5f1d90$ee1d58b0$@error.be>

Hi Steve,

 

Let me clarify the first two questions:

 

I?m looking for an entry point/hook in H5 for altering existing class mappings. For example; some of our entities are supposed to be immutable, but only in production mode.

When running our tests we are using that same model to setup data in an in-memory database. If the entities would be hardcoded immutable then we would be problematic to use them fully for manipulating setup data in our tests. So, in test mode we actually need the entities to be mutable instead.

To accomplish this we  are retrieving  the classMappings from the Configuration which gives us the PersistentClass meta-data. On  this which we can then toggle the mutable flag depending.

Since that functionality has now been refactored, I thought that MetadataContributor was the way to go in H5 as it lets me access InFlightMetadataCollector which gives access to getEntityBindingMap which allows to retrieved the PersistentClasses.

 

However, from the source code I understand that the MetadataContributor can only be configured using ServiceLoader. This means it will not be so straightforward/clean to enable or disable that said MetadataContributor dynamically. Now you suggest:  But if a piece of code is able to determine whether or not to register a MetadataContributor, it could simply contribute said metadata, no? yes, but this is probably where my understanding is falling short; I was under the impression that the MetadataContributor is *the* new way for contributing changes or additions to existing meta-data. If there is another (programmatic) way without having to register MetadataContributor, then by all means, but how/where?

 

On the JTA question:

 

My question has been answered, thanks, but just to clarify: when using JTA, we can configure the shorthand alias ?jta? for the coordinator as you state.

With the second part I meant; what if we are _not_ using JTA but are in local transaction mode, should we then also explicitly configure the coordinator (with short name ?jdbc? in that case) or will it be the default? Again you confirm that ?jdbc? is the default so when not using JTA no coordinator setting is required

 

For the last question:

 

Ok thanks for pointing that out. Is there an easy way to get hold of the org.hibernate.boot.Metadata which I need to pass to SchemaCreator/SchemaDropper?

I could also use SchemaExport directly from within code, but afaik it will rebuild the metadata which will probably take longer?

 

To give some background how I?m using this:  in some types of test we actually commit data to our in-memory database. In order to clear the database between tests, we simply drop and recreate the entire schema based on the DDL. This was the fastest solution with the least amount of impact. For the record: I?m aware there are other solutions for this, but not all of them are feasible. I?m leaving out the details here as it would go off topic ? at the moment I?m just looking for a way to migrate it to H5 keeping the same functionality we have been using (extract the create/drop DDL from a live SF as fast as possible)

 

Thanks,

 

Koen.

 

From: Steve Ebersole [mailto:steve at hibernate.org] 
Sent: donderdag 13 augustus 2015 4:24
To: Koen Serneels; hibernate-dev at lists.jboss.org
Subject: Re: [hibernate-dev] Hibernate5 migration

 

There is a migration guide: https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md.  It is still a work in progress as in its is not "prettified" yet (as 5.0 is not final yet.  If things are missing please let us know.

 

Some answers inline...

 

 

- In Hibernate4 we modified mappings on-the-fly by overriding Spring's
LocalSessionFactoryBean#buildSessionFactory.


Doing so we could first access the getClassMapping on
org.hibernate.cfg.Configuration before letting the SF actually build.

However, in Hibernate5 the metadata access has been refactored and is no
longer part of the Configuration. Should we use MetadataContributor instead
for these purposes?

 

 

Depends what you are trying to achieve specifically.  What do you mean by "modify"?  Do you mean literally that you want to modify (alter) the existing "class mappings", or do you really mean that you want to add additional mappings? 

 

 

- Is there a way to register MetadataContributor dynamically? I see that it
is being loaded using Java's ServiceLoader.

However, I need some programmatic API access to enable or disable the
Contributor (for example based on Spring profiles).

 

No there is not a way to register a MetadataContributor programatically.  I really do not see the benefit of having that as a feature.  Maybe you need to explain better?  But if a piece of code is able to determine whether or not to register a MetadataContributor, it could simply contribute said metadata, no?

 

 

- For JTA integration we were using
org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory, but
this class is no longer present.

Also in org.hibernate.cfg.AvailableSettings the key that was used
(hibernate.transaction.factory_class) to configure the factory is also
removed.

Is hibernate.transaction.coordinator_class the new key we should be using
instead with
org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordi
natorImpl as value for JTA?

 

Yes, but I would highly recommend using the short-name config values, e.g.:

 

hibernate.transaction.coordinator_class=jta

 

rather than:

 

hibernate.transaction.coordinator_class=org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl

 

Both do the same thing, the first form is just better (for many reasons).

 

 

Do we need to configure anything special in case of resource local TX or is
JdbcResourceLocalTransactionCoordinatorImpl the default?

 

I'm confused with this last piece in combination with the rest of the questions here.  The rest of the block discusses JTA, but then here you are asking about JDBC-based transactions.  Regardless, the default TransactionCoordinator is in fact the JDBC one.

 

 

- generateDropSchemaScript and generateSchemaCreationScript have been
removed from Configuration. Is there a way to access this in another way?

 

Again, depends on exactly what you hope to accomplish here.  Your main options will be either:
1) grab the org.hibernate.tool.schema.spi.SchemaManagementTool from the StandardServiceRegistry and use it to obtain the SchemaCreator and SchemaDropper, passing them the Metadata.

2) Use the org.hibernate.tool.hbm2ddl.SchemaExport class


From gunnar at hibernate.org  Thu Aug 13 03:33:38 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 13 Aug 2015 09:33:38 +0200
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
In-Reply-To: <CAFm4XO2_DqbX99zKONCXuHQ=fVHqjzOFn0HACgF8_KnyAnaSeA@mail.gmail.com>
References: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
	<CAFm4XO2_DqbX99zKONCXuHQ=fVHqjzOFn0HACgF8_KnyAnaSeA@mail.gmail.com>
Message-ID: <CADGJaX8yN_AT=_MicGPK9jWTH0jYWLGn2qjL63jhRwaVwRSUbQ@mail.gmail.com>

Hi,

2015-08-12 17:46 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> That's an interesting proposal, as index sharing inherently implies
> that fields on different types shall not have conflicting mapping
> (i.e. don't reuse the same field name for a different type).
>
> By default we don't share indexes across unrelated types, but also *by
> default* subtypes are indexed in the same index as their parent - if
> the parent is indexed as well.

Yes, I think that's the case where it makes sense. It'd make sense to
re-phrase the docs in that regard.

>
> The reason is to efficiently map a polymorphic domain: when people
> search for type X, they implicitly also search for its subtypes as
> these are valid candidates for the query.
> Having them all in the same index makes for better result quality and
> better search performance - as joining multiple IndexReaders to
> perform a cross - index Query is generally a bad idea, as it's then
> hard to accurately normalize statistics across different vector
> spaces, and that's what defines the quality of the search result.
> At least I believe that *generally* that would give you better
> results, but that's why we give options, and also why sometimes people
> might want multiple Domain objects to be stored in the same index:
> they might be "subtypes" from a domain perspective even if they don't
> technically use inheritance at the Java level: they might be different
> types and yet be mapped to some common fields with (hopefully)
> compatible indexing options.

Have you ever seen this as an actual requirement by someone?

>
> If we were to drop index sharing, then I think it should be fair to
> also not support multiple types as target for a query anymore; as I'm
> assuming in this case you'd only share for subtypes of some common
> parent, and you'd target that common parent exclusively to perform a
> polymorphic query.

Assuming we'd drop index sharing for unrelated types but would
continue to support it for the types of one inheritance hierarchy, one
still might want results only from a sub-set of the hierarchy's types.

>
> So that's the reasons for which it exists; there are some good reasons
> to not allow it too: as you mention the filtering, but also the very
> fact that the type information has to be stored in form of classname
> (typename, in free-form).

Interestingly, that's not so much an issue with ES. There you always
add a "type" discriminator.

> I think the strongest reason to not allow it is to avoid the
> inconsistent field mappings, but we could compensate for that with
> better schema validation - something which seems is getting more
> necessary anyway.

Yes, that' help. All in all, index sharing for inheritance hierarchies
makes sense to me, but I am doubtful about sharing between unrelated
types.

>
> I didn't mean to kill the proposal :) just hoping it helps figure out
> why someone might need it. Would be nice to think of alternatives out
> of the box to avoid the filtering.
>
> Sanne

--Gunnar

>
>
>
> On 12 August 2015 at 15:30, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Hibernate Search aficionados,
>>
>> I am wondering what that's the rationale for offering the feature of
>> index sharing [1].
>>
>> The ref guide says "there is really not much benefit in sharing
>> indexes". It complicates queries, as an additional filter on the type
>> field must be applied in case of targeting only one entity using a
>> shared index.
>>
>> Should we consider to drop this feature in HS 6?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1] https://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#section-sharing-indexes
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Thu Aug 13 03:35:29 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 13 Aug 2015 09:35:29 +0200
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
In-Reply-To: <63F329B2-6A03-49B9-9F3F-7CD83E38916B@gmx.net>
References: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
	<63F329B2-6A03-49B9-9F3F-7CD83E38916B@gmx.net>
Message-ID: <CADGJaX_ukkR1fjCnVg8pXbjVS_Gp1PNU0ppfeLQd-85rHeu4XA@mail.gmail.com>

Thanks for the feedback, Andrej!

What kind of sharing is this, the one between types of one inheritance
hierarchy we discussed or between unrelated types? In case of the
latter, what's the reason that you need this? Would be interested to
learn about the use case.

--Gunnar


2015-08-12 23:17 GMT+02:00 Andrej Golovnin <golovnin at gmx.net>:
> Hi Gunnar,
>
>> Should we consider to drop this feature in HS 6?
>
> -1, we use it, I think, in at least 3 places in our application.
> Removing it would make our code more complicated.
>
> Best regards,
> Andrej Golovnin

From sanne at hibernate.org  Thu Aug 13 08:26:46 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 13 Aug 2015 13:26:46 +0100
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
In-Reply-To: <CADGJaX8yN_AT=_MicGPK9jWTH0jYWLGn2qjL63jhRwaVwRSUbQ@mail.gmail.com>
References: <CADGJaX_zeGodrPCeVBh_6smEZ3z399p3R88zOQa-oTnymO_aBw@mail.gmail.com>
	<CAFm4XO2_DqbX99zKONCXuHQ=fVHqjzOFn0HACgF8_KnyAnaSeA@mail.gmail.com>
	<CADGJaX8yN_AT=_MicGPK9jWTH0jYWLGn2qjL63jhRwaVwRSUbQ@mail.gmail.com>
Message-ID: <CAFm4XO0UkOxVqa5RDXuWw+Pe=ODV=sSj0G7Ak5RfLFLAfQjhNg@mail.gmail.com>

On 13 August 2015 at 08:33, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> 2015-08-12 17:46 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> That's an interesting proposal, as index sharing inherently implies
>> that fields on different types shall not have conflicting mapping
>> (i.e. don't reuse the same field name for a different type).
>>
>> By default we don't share indexes across unrelated types, but also *by
>> default* subtypes are indexed in the same index as their parent - if
>> the parent is indexed as well.
>
> Yes, I think that's the case where it makes sense. It'd make sense to
> re-phrase the docs in that regard.
>
>>
>> The reason is to efficiently map a polymorphic domain: when people
>> search for type X, they implicitly also search for its subtypes as
>> these are valid candidates for the query.
>> Having them all in the same index makes for better result quality and
>> better search performance - as joining multiple IndexReaders to
>> perform a cross - index Query is generally a bad idea, as it's then
>> hard to accurately normalize statistics across different vector
>> spaces, and that's what defines the quality of the search result.
>> At least I believe that *generally* that would give you better
>> results, but that's why we give options, and also why sometimes people
>> might want multiple Domain objects to be stored in the same index:
>> they might be "subtypes" from a domain perspective even if they don't
>> technically use inheritance at the Java level: they might be different
>> types and yet be mapped to some common fields with (hopefully)
>> compatible indexing options.
>
> Have you ever seen this as an actual requirement by someone?

Yes, not least by myself :)
You might have various types which don't share a Java inheritance tree
but still have some common property. Could be a simple tagging system,
or just the classical example of "title" of a product.
Some people will have a Product parent class, some people might not
have love for expressing their model in a Java inheritance straight
jacket.. a real world large information system seldom follows the
Animal examples of text books.

Consider also that you might not want to *search* for these different
types, but still index them together. E.g. do some computation like
what's the most frequently used tag across various types, or implement
an auto-suggester field for a UI in which the exact target domain type
is yet to be filled in by some follow-up step.

So while I agree it doesn't seem a great idea to run a query which
could return multiple different (and unrelated - other than by
inheritance from Object), there are many other cases; even a
mixed-type search is not too hard to handle when using a Projection.

>> If we were to drop index sharing, then I think it should be fair to
>> also not support multiple types as target for a query anymore; as I'm
>> assuming in this case you'd only share for subtypes of some common
>> parent, and you'd target that common parent exclusively to perform a
>> polymorphic query.
>
> Assuming we'd drop index sharing for unrelated types but would
> continue to support it for the types of one inheritance hierarchy, one
> still might want results only from a sub-set of the hierarchy's types.
>
>>
>> So that's the reasons for which it exists; there are some good reasons
>> to not allow it too: as you mention the filtering, but also the very
>> fact that the type information has to be stored in form of classname
>> (typename, in free-form).
>
> Interestingly, that's not so much an issue with ES. There you always
> add a "type" discriminator.

Right, any discriminator is quite cheap with Lucene. Just trying to
think which benefits it would have, but it's clear I think we need to
stick with it.

>> I think the strongest reason to not allow it is to avoid the
>> inconsistent field mappings, but we could compensate for that with
>> better schema validation - something which seems is getting more
>> necessary anyway.
>
> Yes, that' help. All in all, index sharing for inheritance hierarchies
> makes sense to me, but I am doubtful about sharing between unrelated
> types.

I'll assume the above examples changed your mind ;)

Cheers,
Sanne

>
>>
>> I didn't mean to kill the proposal :) just hoping it helps figure out
>> why someone might need it. Would be nice to think of alternatives out
>> of the box to avoid the filtering.
>>
>> Sanne
>
> --Gunnar
>
>>
>>
>>
>> On 12 August 2015 at 15:30, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> Hibernate Search aficionados,
>>>
>>> I am wondering what that's the rationale for offering the feature of
>>> index sharing [1].
>>>
>>> The ref guide says "there is really not much benefit in sharing
>>> indexes". It complicates queries, as an additional filter on the type
>>> field must be applied in case of targeting only one entity using a
>>> shared index.
>>>
>>> Should we consider to drop this feature in HS 6?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1] https://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#section-sharing-indexes
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Aug 13 08:38:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 13 Aug 2015 12:38:58 +0000
Subject: [hibernate-dev] Hibernate5 migration
In-Reply-To: <00a201d0d583$4f5f1d90$ee1d58b0$@error.be>
References: <009201d0d53c$8a9acfe0$9fd06fa0$@error.be>
	<CAFdSV9sxCmUGz71whp0XB0UF_AbR2y-aPL4euWS0VZ3eg2xdsA@mail.gmail.com>
	<00a201d0d583$4f5f1d90$ee1d58b0$@error.be>
Message-ID: <CAFdSV9to6qN1OeD2yKJL-oinPRNETEPxP-LZ0rsm1ncOMRUP+Q@mail.gmail.com>

For a lot of your questions, I'd highly suggest reading [1] and [2].  They
are mostly the same content (asciidoc versus docbook).

[1] -
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
[2] -
http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#bootstrap-native




On Wed, Aug 12, 2015 at 11:58 PM Koen Serneels <ks at error.be> wrote:

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

From brmeyer at redhat.com  Thu Aug 13 10:32:07 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 13 Aug 2015 10:32:07 -0400 (EDT)
Subject: [hibernate-dev] 4.2.20.Final and SourceForge problems;
 delaying 4.3.11.Final until next week
In-Reply-To: <20150726191216.GA75369@Nineveh.lan>
References: <2029733878.11998.1437797198677.JavaMail.zimbra@redhat.com>
	<959868370.12220.1437797501442.JavaMail.zimbra@redhat.com>
	<20150726191216.GA75369@Nineveh.lan>
Message-ID: <55974093.10028149.1439476327324.JavaMail.zimbra@redhat.com>

Could we still consider an alternative to SourceForge for the binary distribution?  With all the crap they've been pulling, lately, in addition to the outages, I'd love to avoid it entirely...

----- Original Message -----
> From: "Hardy Ferentschik" <hardy at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Sunday, July 26, 2015 3:12:16 PM
> Subject: Re: [hibernate-dev] 4.2.20.Final and SourceForge problems; delaying 4.3.11.Final until next week
> 
> Hi,
> 
> On Sat, Jul 25, 2015 at 12:11:41AM -0400, Gail Badner wrote:
> > I am finished with the 4.2.20.Final release, except for uploading
> > distributions due to problems at SourceForge.
> 
> FYI, I am having the same issue. I am waiting for a week now to upload the
> Validator release.
> Initially, there were even no buttons to create folders or upload anything.
> Now they are back, but
> don't work (I've just tried again). ssh upload does not work either.
> 
> SourceForge had some major outage, but seems unable to full recover. I am not
> sure how much longer
> we should wait. Right now I am drawn between these options
> 
> * announce the release mentioning that the artifacts will be uploaded if and
> when SourceForge works again
> * upload the artifacts to GitHub and link to there
> * keep waiting
> 
> --Hardy
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From brmeyer at redhat.com  Thu Aug 13 10:50:21 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 13 Aug 2015 10:50:21 -0400 (EDT)
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
	<7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
	<CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>
Message-ID: <292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>

Sorry, late to this...

My vote would be to get rid of SourceForge entirely.  I can't stand their ethics, services, or downtime...

We use download.jboss.org for Artificer and haven't had any issues.  Fully supports SCP or SFTP -- I already have it scripted and would be more than happy to help put it together for Hibernate.  Plus, jboss.org/redhat.org now include Splunk for parsing the server logs -- getting download metrics is fairly straight-forward.

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <gunnar at hibernate.org>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Friday, July 31, 2015 2:37:29 PM
> Subject: Re: [hibernate-dev] Hosting of binaries
> 
> FWIW the SourceForge upload UI seems to be restored.
> 
> 
> 
> On Thu, Jul 30, 2015 at 2:14 AM Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> 
> > For info, SourceForge hopes to restore ssh access (the last service they
> > will activate) August 3rd.
> >
> > http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/
> >
> > > On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org> wrote:
> > >
> > > Your proposed order seems good. I'd exclude GitHub if it's not
> > scriptable (UI only) as this will hinder releases from the CI server.
> > >
> > > 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
> > <mailto:emmanuel at hibernate.org>>:
> > > As some of you know Sourceforge has had a severe distributed file system
> > corruption and they have been working on it for a full week. You can read
> > their blog for regular updates http://sourceforge.net/blog/ <
> > http://sourceforge.net/blog/>
> > > The concrete issue for us is that we cannot upload new files: Hibernate
> > Validator and Hibernate ORM are now pending a release.
> > >
> > > There are 4 options on the table
> > >
> > > Be patient::
> > > SourceForge will eventually reopen upload, I imagine it might take form
> > one to two weeks.
> > > Their binary hosting support is relatively correct and all of our
> > download statistics are there.
> > >
> > > Move to download.jboss.org <http://download.jboss.org/>::
> > > JBoss has a facility to host binaries. WildFly amongst other uses it. We
> > can ask them if they are happy with it.
> > > It is not connected to the rest of the forum/CMS infra, it?s a simple
> > file upload AFAIK so easily scriptable.
> > > They also offer statistics but how needs to be investigated.
> > >
> > > Move to GitHub::
> > > GitHub has a binary upload facility. I could only find a web based
> > approach (can it be done programmatically?).
> > > They don?t seem to have any statistics service, which is a big negative
> > point.
> > > Also I don?t trust GitHub anymore for their binary hosting. They had a
> > version in the past that they scrapped with barely no notice. I?m not
> > exactly willing to give them my trust again.
> > >
> > > Move to BinTray::
> > > Binary hosting is their life and blood. People seem happy with them. It
> > seems however that the statistics require a paying package instead of the
> > free oss tier.
> > >
> > > I think we should try in the following order:
> > >
> > > 1. Be patient with Sourceforge (but for how long?)
> > > 2. go for download.jboss.org <http://download.jboss.org/> and before
> > that ask around for the process and stability of the infrastructure
> > > 3. explore Bintray
> > > 4. GitHub (did I say that I no longer trust their binary hosting
> > support?)
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev <
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Thu Aug 13 11:03:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 13 Aug 2015 16:03:29 +0100
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
	<7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
	<CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>
	<292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO2AXbfCaeaQL0NQaP-gmRs+cS--hJNv+HShWKx1pTMF4Q@mail.gmail.com>

On 13 August 2015 at 15:50, Brett Meyer <brmeyer at redhat.com> wrote:
> Sorry, late to this...
>
> My vote would be to get rid of SourceForge entirely.  I can't stand their ethics, services, or downtime...
>
> We use download.jboss.org for Artificer and haven't had any issues.  Fully supports SCP or SFTP -- I already have it scripted and would be more than happy to help put it together for Hibernate.  Plus, jboss.org/redhat.org now include Splunk for parsing the server logs -- getting download metrics is fairly straight-forward.

That sounds quite nice!

But Hibernate has been at Sourceforce for a very long time though
(ever?) and if we were to move platform / location each time something
unpleasant happens that wouldn't be good for users; take the Google
Code initiative for example.. not long ago it looked like everyone was
going to move there, but it's dead already.

But you're right: Sourceforge has crossed several lines - including
the ethical one - so I'd not be against moving away, but if we all
agree on moving I'd like to see how we can put some form of
"redirect", or just maintain a long term notice, or simply keep
uploading to both places for longer.

If we move, I'd pick a new place which is going to be for sure stable
in the long term; my preference would be to something under the DNS
control of hibernate.org .. that might be download.jboss.org under the
hoods, but I'd prefer to expose it in a way which is under control by
the Hibernate group for the very long term. I'll ask the jboss.org
team if that's an option.

Sanne

>
> ----- Original Message -----
>> From: "Steve Ebersole" <steve at hibernate.org>
>> To: "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <gunnar at hibernate.org>
>> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
>> Sent: Friday, July 31, 2015 2:37:29 PM
>> Subject: Re: [hibernate-dev] Hosting of binaries
>>
>> FWIW the SourceForge upload UI seems to be restored.
>>
>>
>>
>> On Thu, Jul 30, 2015 at 2:14 AM Emmanuel Bernard <emmanuel at hibernate.org>
>> wrote:
>>
>> > For info, SourceForge hopes to restore ssh access (the last service they
>> > will activate) August 3rd.
>> >
>> > http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/
>> >
>> > > On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > >
>> > > Your proposed order seems good. I'd exclude GitHub if it's not
>> > scriptable (UI only) as this will hinder releases from the CI server.
>> > >
>> > > 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
>> > <mailto:emmanuel at hibernate.org>>:
>> > > As some of you know Sourceforge has had a severe distributed file system
>> > corruption and they have been working on it for a full week. You can read
>> > their blog for regular updates http://sourceforge.net/blog/ <
>> > http://sourceforge.net/blog/>
>> > > The concrete issue for us is that we cannot upload new files: Hibernate
>> > Validator and Hibernate ORM are now pending a release.
>> > >
>> > > There are 4 options on the table
>> > >
>> > > Be patient::
>> > > SourceForge will eventually reopen upload, I imagine it might take form
>> > one to two weeks.
>> > > Their binary hosting support is relatively correct and all of our
>> > download statistics are there.
>> > >
>> > > Move to download.jboss.org <http://download.jboss.org/>::
>> > > JBoss has a facility to host binaries. WildFly amongst other uses it. We
>> > can ask them if they are happy with it.
>> > > It is not connected to the rest of the forum/CMS infra, it?s a simple
>> > file upload AFAIK so easily scriptable.
>> > > They also offer statistics but how needs to be investigated.
>> > >
>> > > Move to GitHub::
>> > > GitHub has a binary upload facility. I could only find a web based
>> > approach (can it be done programmatically?).
>> > > They don?t seem to have any statistics service, which is a big negative
>> > point.
>> > > Also I don?t trust GitHub anymore for their binary hosting. They had a
>> > version in the past that they scrapped with barely no notice. I?m not
>> > exactly willing to give them my trust again.
>> > >
>> > > Move to BinTray::
>> > > Binary hosting is their life and blood. People seem happy with them. It
>> > seems however that the statistics require a paying package instead of the
>> > free oss tier.
>> > >
>> > > I think we should try in the following order:
>> > >
>> > > 1. Be patient with Sourceforge (but for how long?)
>> > > 2. go for download.jboss.org <http://download.jboss.org/> and before
>> > that ask around for the process and stability of the infrastructure
>> > > 3. explore Bintray
>> > > 4. GitHub (did I say that I no longer trust their binary hosting
>> > support?)
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev <
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Thu Aug 13 11:05:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 13 Aug 2015 15:05:23 +0000
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
	<7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
	<CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>
	<292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9sgeUAQybgWjVrbQcMHq+gNyiwHBbGMR95V6M=H4zis4Q@mail.gmail.com>

TBH SourceForge is generally the least of my worries when doing a release
nowadays.  Yes I have had trouble with it the last 2 releases due to their
outage, but honestly the JBoss Nexus has been a bigger pain-point more
often.  And blogging is getting there too.

Unless I am mistaken, distribution is the only thing we use the SF hosting
for at the moment.  I really have no idea what you mean wrt "their
ethics".  Can you elaborate?

The question is alternatives.  We discussed GitHub releases on another
thread, so I won't go back into that; I think we all agree that is not the
best idea.  Which leaves us BinTray and JBoss.

In general I think I'd prefer "well known" solutions.  If someone is
looking for a release, chances are they are going to one of these central
places (Maven Central, Bintray/JCenter, SourceForge).  The JBoss download
server is a bit niche, imo.  Granted this is partially education and/or
documentation to point people to the "right place".  But my current
thinking is starting to shift to covering all the right places.

For dependency-management artifacts, why not make sure we publish to all of
them?  Maven Central, JBoss Nexus, JCenter.  The thing that has killed my
last few release attempts has been JBoss Nexus (*transient* failures to
upload artifacts).  I'd *love* to cut that out of the release process.  Of
course it eventually needs to end up there.  So we'd have to consider
options for that to happen.  But ultimately I'd love to have a solution
that simply ensures the artifacts end up in all 3 (and possibly more)
places.

For release bundles, again JBoss server is a bit niche to me.  I'm ok with
making sure these end up there *as well* but I do not think it should be
the primary location.  To me that is SourceForge or BinTray.


On Thu, Aug 13, 2015 at 9:50 AM Brett Meyer <brmeyer at redhat.com> wrote:

> Sorry, late to this...
>
> My vote would be to get rid of SourceForge entirely.  I can't stand their
> ethics, services, or downtime...
>
> We use download.jboss.org for Artificer and haven't had any issues.
> Fully supports SCP or SFTP -- I already have it scripted and would be more
> than happy to help put it together for Hibernate.  Plus,
> jboss.org/redhat.org now include Splunk for parsing the server logs --
> getting download metrics is fairly straight-forward.
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <
> gunnar at hibernate.org>
> > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > Sent: Friday, July 31, 2015 2:37:29 PM
> > Subject: Re: [hibernate-dev] Hosting of binaries
> >
> > FWIW the SourceForge upload UI seems to be restored.
> >
> >
> >
> > On Thu, Jul 30, 2015 at 2:14 AM Emmanuel Bernard <emmanuel at hibernate.org
> >
> > wrote:
> >
> > > For info, SourceForge hopes to restore ssh access (the last service
> they
> > > will activate) August 3rd.
> > >
> > >
> http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/
> > >
> > > > On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> > > >
> > > > Your proposed order seems good. I'd exclude GitHub if it's not
> > > scriptable (UI only) as this will hinder releases from the CI server.
> > > >
> > > > 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
> > > <mailto:emmanuel at hibernate.org>>:
> > > > As some of you know Sourceforge has had a severe distributed file
> system
> > > corruption and they have been working on it for a full week. You can
> read
> > > their blog for regular updates http://sourceforge.net/blog/ <
> > > http://sourceforge.net/blog/>
> > > > The concrete issue for us is that we cannot upload new files:
> Hibernate
> > > Validator and Hibernate ORM are now pending a release.
> > > >
> > > > There are 4 options on the table
> > > >
> > > > Be patient::
> > > > SourceForge will eventually reopen upload, I imagine it might take
> form
> > > one to two weeks.
> > > > Their binary hosting support is relatively correct and all of our
> > > download statistics are there.
> > > >
> > > > Move to download.jboss.org <http://download.jboss.org/>::
> > > > JBoss has a facility to host binaries. WildFly amongst other uses
> it. We
> > > can ask them if they are happy with it.
> > > > It is not connected to the rest of the forum/CMS infra, it?s a simple
> > > file upload AFAIK so easily scriptable.
> > > > They also offer statistics but how needs to be investigated.
> > > >
> > > > Move to GitHub::
> > > > GitHub has a binary upload facility. I could only find a web based
> > > approach (can it be done programmatically?).
> > > > They don?t seem to have any statistics service, which is a big
> negative
> > > point.
> > > > Also I don?t trust GitHub anymore for their binary hosting. They had
> a
> > > version in the past that they scrapped with barely no notice. I?m not
> > > exactly willing to give them my trust again.
> > > >
> > > > Move to BinTray::
> > > > Binary hosting is their life and blood. People seem happy with them.
> It
> > > seems however that the statistics require a paying package instead of
> the
> > > free oss tier.
> > > >
> > > > I think we should try in the following order:
> > > >
> > > > 1. Be patient with Sourceforge (but for how long?)
> > > > 2. go for download.jboss.org <http://download.jboss.org/> and before
> > > that ask around for the process and stability of the infrastructure
> > > > 3. explore Bintray
> > > > 4. GitHub (did I say that I no longer trust their binary hosting
> > > support?)
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev <
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Aug 13 13:09:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 13 Aug 2015 17:09:11 +0000
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <CAFdSV9sgeUAQybgWjVrbQcMHq+gNyiwHBbGMR95V6M=H4zis4Q@mail.gmail.com>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
	<7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
	<CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>
	<292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>
	<CAFdSV9sgeUAQybgWjVrbQcMHq+gNyiwHBbGMR95V6M=H4zis4Q@mail.gmail.com>
Message-ID: <CAFdSV9uY4Ux2ETJhq1mrSbJXiDHKVWk1xhTMSxdmqncUdBBQaQ@mail.gmail.com>

So basically I think we should push both the artifacts and distros to
multiple places.  To me the real question is that of process.  How do we
get them to each place?  Given that we have had trouble with SF for distro
uploads and Nexus for artifact uploads, I'd prefer to not do those uploads
as part of the release tasks.

One thought was a CI job to do some of the uploads.  The release would
upload to the one we generally do not have trouble with (my guess is this
means bintray/jcenter and/or JBoss file server).  The CI job would perform
the rest.

Or maybe the CI job does all of the uploads.

Can CI jobs be parameterized?



On Thu, Aug 13, 2015 at 10:05 AM Steve Ebersole <steve at hibernate.org> wrote:

> TBH SourceForge is generally the least of my worries when doing a release
> nowadays.  Yes I have had trouble with it the last 2 releases due to their
> outage, but honestly the JBoss Nexus has been a bigger pain-point more
> often.  And blogging is getting there too.
>
> Unless I am mistaken, distribution is the only thing we use the SF hosting
> for at the moment.  I really have no idea what you mean wrt "their
> ethics".  Can you elaborate?
>
> The question is alternatives.  We discussed GitHub releases on another
> thread, so I won't go back into that; I think we all agree that is not the
> best idea.  Which leaves us BinTray and JBoss.
>
> In general I think I'd prefer "well known" solutions.  If someone is
> looking for a release, chances are they are going to one of these central
> places (Maven Central, Bintray/JCenter, SourceForge).  The JBoss download
> server is a bit niche, imo.  Granted this is partially education and/or
> documentation to point people to the "right place".  But my current
> thinking is starting to shift to covering all the right places.
>
> For dependency-management artifacts, why not make sure we publish to all
> of them?  Maven Central, JBoss Nexus, JCenter.  The thing that has killed
> my last few release attempts has been JBoss Nexus (*transient* failures to
> upload artifacts).  I'd *love* to cut that out of the release process.  Of
> course it eventually needs to end up there.  So we'd have to consider
> options for that to happen.  But ultimately I'd love to have a solution
> that simply ensures the artifacts end up in all 3 (and possibly more)
> places.
>
> For release bundles, again JBoss server is a bit niche to me.  I'm ok with
> making sure these end up there *as well* but I do not think it should be
> the primary location.  To me that is SourceForge or BinTray.
>
>
> On Thu, Aug 13, 2015 at 9:50 AM Brett Meyer <brmeyer at redhat.com> wrote:
>
>> Sorry, late to this...
>>
>> My vote would be to get rid of SourceForge entirely.  I can't stand their
>> ethics, services, or downtime...
>>
>> We use download.jboss.org for Artificer and haven't had any issues.
>> Fully supports SCP or SFTP -- I already have it scripted and would be more
>> than happy to help put it together for Hibernate.  Plus,
>> jboss.org/redhat.org now include Splunk for parsing the server logs --
>> getting download metrics is fairly straight-forward.
>>
>> ----- Original Message -----
>> > From: "Steve Ebersole" <steve at hibernate.org>
>> > To: "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <
>> gunnar at hibernate.org>
>> > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
>> > Sent: Friday, July 31, 2015 2:37:29 PM
>> > Subject: Re: [hibernate-dev] Hosting of binaries
>> >
>> > FWIW the SourceForge upload UI seems to be restored.
>> >
>> >
>> >
>> > On Thu, Jul 30, 2015 at 2:14 AM Emmanuel Bernard <
>> emmanuel at hibernate.org>
>> > wrote:
>> >
>> > > For info, SourceForge hopes to restore ssh access (the last service
>> they
>> > > will activate) August 3rd.
>> > >
>> > >
>> http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/
>> > >
>> > > > On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> > > >
>> > > > Your proposed order seems good. I'd exclude GitHub if it's not
>> > > scriptable (UI only) as this will hinder releases from the CI server.
>> > > >
>> > > > 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
>> > > <mailto:emmanuel at hibernate.org>>:
>> > > > As some of you know Sourceforge has had a severe distributed file
>> system
>> > > corruption and they have been working on it for a full week. You can
>> read
>> > > their blog for regular updates http://sourceforge.net/blog/ <
>> > > http://sourceforge.net/blog/>
>> > > > The concrete issue for us is that we cannot upload new files:
>> Hibernate
>> > > Validator and Hibernate ORM are now pending a release.
>> > > >
>> > > > There are 4 options on the table
>> > > >
>> > > > Be patient::
>> > > > SourceForge will eventually reopen upload, I imagine it might take
>> form
>> > > one to two weeks.
>> > > > Their binary hosting support is relatively correct and all of our
>> > > download statistics are there.
>> > > >
>> > > > Move to download.jboss.org <http://download.jboss.org/>::
>> > > > JBoss has a facility to host binaries. WildFly amongst other uses
>> it. We
>> > > can ask them if they are happy with it.
>> > > > It is not connected to the rest of the forum/CMS infra, it?s a
>> simple
>> > > file upload AFAIK so easily scriptable.
>> > > > They also offer statistics but how needs to be investigated.
>> > > >
>> > > > Move to GitHub::
>> > > > GitHub has a binary upload facility. I could only find a web based
>> > > approach (can it be done programmatically?).
>> > > > They don?t seem to have any statistics service, which is a big
>> negative
>> > > point.
>> > > > Also I don?t trust GitHub anymore for their binary hosting. They
>> had a
>> > > version in the past that they scrapped with barely no notice. I?m not
>> > > exactly willing to give them my trust again.
>> > > >
>> > > > Move to BinTray::
>> > > > Binary hosting is their life and blood. People seem happy with
>> them. It
>> > > seems however that the statistics require a paying package instead of
>> the
>> > > free oss tier.
>> > > >
>> > > > I think we should try in the following order:
>> > > >
>> > > > 1. Be patient with Sourceforge (but for how long?)
>> > > > 2. go for download.jboss.org <http://download.jboss.org/> and
>> before
>> > > that ask around for the process and stability of the infrastructure
>> > > > 3. explore Bintray
>> > > > 4. GitHub (did I say that I no longer trust their binary hosting
>> > > support?)
>> > > > _______________________________________________
>> > > > hibernate-dev mailing list
>> > > > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org
>> >
>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev <
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> > >
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Thu Aug 13 13:21:00 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 13 Aug 2015 18:21:00 +0100
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <CAFdSV9uY4Ux2ETJhq1mrSbJXiDHKVWk1xhTMSxdmqncUdBBQaQ@mail.gmail.com>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
	<7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
	<CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>
	<292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>
	<CAFdSV9sgeUAQybgWjVrbQcMHq+gNyiwHBbGMR95V6M=H4zis4Q@mail.gmail.com>
	<CAFdSV9uY4Ux2ETJhq1mrSbJXiDHKVWk1xhTMSxdmqncUdBBQaQ@mail.gmail.com>
Message-ID: <CAFm4XO2vws-VO4NOjBY=88Kuy44F8QT0WXEG4QCeqzGHq1dK_Q@mail.gmail.com>

On 13 August 2015 at 18:09, Steve Ebersole <steve at hibernate.org> wrote:
> So basically I think we should push both the artifacts and distros to
> multiple places.  To me the real question is that of process.  How do we
> get them to each place?  Given that we have had trouble with SF for distro
> uploads and Nexus for artifact uploads, I'd prefer to not do those uploads
> as part of the release tasks.
>
> One thought was a CI job to do some of the uploads.  The release would
> upload to the one we generally do not have trouble with (my guess is this
> means bintray/jcenter and/or JBoss file server).  The CI job would perform
> the rest.
>
> Or maybe the CI job does all of the uploads.
>
> Can CI jobs be parameterized?

Yes they can. Hibernate OGM releases are fully automated, except the blog post.

See this job configuration, it uses parameters:
 - http://ci.hibernate.org/view/OGM/job/hibernate-ogm-release/configure

It's not entirely maintenace free though.. you still have to watch it,
and when it goes wrong (for any of the usual reasons) it might be a
bit harder to workaround.

>
>
>
> On Thu, Aug 13, 2015 at 10:05 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> TBH SourceForge is generally the least of my worries when doing a release
>> nowadays.  Yes I have had trouble with it the last 2 releases due to their
>> outage, but honestly the JBoss Nexus has been a bigger pain-point more
>> often.  And blogging is getting there too.
>>
>> Unless I am mistaken, distribution is the only thing we use the SF hosting
>> for at the moment.  I really have no idea what you mean wrt "their
>> ethics".  Can you elaborate?
>>
>> The question is alternatives.  We discussed GitHub releases on another
>> thread, so I won't go back into that; I think we all agree that is not the
>> best idea.  Which leaves us BinTray and JBoss.
>>
>> In general I think I'd prefer "well known" solutions.  If someone is
>> looking for a release, chances are they are going to one of these central
>> places (Maven Central, Bintray/JCenter, SourceForge).  The JBoss download
>> server is a bit niche, imo.  Granted this is partially education and/or
>> documentation to point people to the "right place".  But my current
>> thinking is starting to shift to covering all the right places.
>>
>> For dependency-management artifacts, why not make sure we publish to all
>> of them?  Maven Central, JBoss Nexus, JCenter.  The thing that has killed
>> my last few release attempts has been JBoss Nexus (*transient* failures to
>> upload artifacts).  I'd *love* to cut that out of the release process.  Of
>> course it eventually needs to end up there.  So we'd have to consider
>> options for that to happen.  But ultimately I'd love to have a solution
>> that simply ensures the artifacts end up in all 3 (and possibly more)
>> places.
>>
>> For release bundles, again JBoss server is a bit niche to me.  I'm ok with
>> making sure these end up there *as well* but I do not think it should be
>> the primary location.  To me that is SourceForge or BinTray.
>>
>>
>> On Thu, Aug 13, 2015 at 9:50 AM Brett Meyer <brmeyer at redhat.com> wrote:
>>
>>> Sorry, late to this...
>>>
>>> My vote would be to get rid of SourceForge entirely.  I can't stand their
>>> ethics, services, or downtime...
>>>
>>> We use download.jboss.org for Artificer and haven't had any issues.
>>> Fully supports SCP or SFTP -- I already have it scripted and would be more
>>> than happy to help put it together for Hibernate.  Plus,
>>> jboss.org/redhat.org now include Splunk for parsing the server logs --
>>> getting download metrics is fairly straight-forward.
>>>
>>> ----- Original Message -----
>>> > From: "Steve Ebersole" <steve at hibernate.org>
>>> > To: "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <
>>> gunnar at hibernate.org>
>>> > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
>>> > Sent: Friday, July 31, 2015 2:37:29 PM
>>> > Subject: Re: [hibernate-dev] Hosting of binaries
>>> >
>>> > FWIW the SourceForge upload UI seems to be restored.
>>> >
>>> >
>>> >
>>> > On Thu, Jul 30, 2015 at 2:14 AM Emmanuel Bernard <
>>> emmanuel at hibernate.org>
>>> > wrote:
>>> >
>>> > > For info, SourceForge hopes to restore ssh access (the last service
>>> they
>>> > > will activate) August 3rd.
>>> > >
>>> > >
>>> http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/
>>> > >
>>> > > > On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>> > > >
>>> > > > Your proposed order seems good. I'd exclude GitHub if it's not
>>> > > scriptable (UI only) as this will hinder releases from the CI server.
>>> > > >
>>> > > > 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
>>> > > <mailto:emmanuel at hibernate.org>>:
>>> > > > As some of you know Sourceforge has had a severe distributed file
>>> system
>>> > > corruption and they have been working on it for a full week. You can
>>> read
>>> > > their blog for regular updates http://sourceforge.net/blog/ <
>>> > > http://sourceforge.net/blog/>
>>> > > > The concrete issue for us is that we cannot upload new files:
>>> Hibernate
>>> > > Validator and Hibernate ORM are now pending a release.
>>> > > >
>>> > > > There are 4 options on the table
>>> > > >
>>> > > > Be patient::
>>> > > > SourceForge will eventually reopen upload, I imagine it might take
>>> form
>>> > > one to two weeks.
>>> > > > Their binary hosting support is relatively correct and all of our
>>> > > download statistics are there.
>>> > > >
>>> > > > Move to download.jboss.org <http://download.jboss.org/>::
>>> > > > JBoss has a facility to host binaries. WildFly amongst other uses
>>> it. We
>>> > > can ask them if they are happy with it.
>>> > > > It is not connected to the rest of the forum/CMS infra, it?s a
>>> simple
>>> > > file upload AFAIK so easily scriptable.
>>> > > > They also offer statistics but how needs to be investigated.
>>> > > >
>>> > > > Move to GitHub::
>>> > > > GitHub has a binary upload facility. I could only find a web based
>>> > > approach (can it be done programmatically?).
>>> > > > They don?t seem to have any statistics service, which is a big
>>> negative
>>> > > point.
>>> > > > Also I don?t trust GitHub anymore for their binary hosting. They
>>> had a
>>> > > version in the past that they scrapped with barely no notice. I?m not
>>> > > exactly willing to give them my trust again.
>>> > > >
>>> > > > Move to BinTray::
>>> > > > Binary hosting is their life and blood. People seem happy with
>>> them. It
>>> > > seems however that the statistics require a paying package instead of
>>> the
>>> > > free oss tier.
>>> > > >
>>> > > > I think we should try in the following order:
>>> > > >
>>> > > > 1. Be patient with Sourceforge (but for how long?)
>>> > > > 2. go for download.jboss.org <http://download.jboss.org/> and
>>> before
>>> > > that ask around for the process and stability of the infrastructure
>>> > > > 3. explore Bintray
>>> > > > 4. GitHub (did I say that I no longer trust their binary hosting
>>> > > support?)
>>> > > > _______________________________________________
>>> > > > hibernate-dev mailing list
>>> > > > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org
>>> >
>>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev <
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>> > >
>>> > > _______________________________________________
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From brmeyer at redhat.com  Thu Aug 13 14:27:20 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 13 Aug 2015 14:27:20 -0400 (EDT)
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <CAFdSV9sgeUAQybgWjVrbQcMHq+gNyiwHBbGMR95V6M=H4zis4Q@mail.gmail.com>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
	<7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
	<CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>
	<292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>
	<CAFdSV9sgeUAQybgWjVrbQcMHq+gNyiwHBbGMR95V6M=H4zis4Q@mail.gmail.com>
Message-ID: <1921945687.10142157.1439490440731.JavaMail.zimbra@redhat.com>

> I really have no idea what you mean wrt "their ethics".  Can you elaborate? 

Wrapping binaries and including bloatware, ads posing as large Download buttons and leading to shady sites, parent company more interested in squeezing out profit through sketchy means, etc.  (Although, it sounds like the latter may be changing.  Supposedly the parent company recently dropped both SF and Slashdot.)

> For release bundles, again JBoss server is a bit niche to me.  I'm ok with
> making sure these end up there *as well* but I do not think it should be
> the primary location.  To me that is SourceForge or BinTray.

Fair point -- sounds reasonable.  I'd personally prefer BinTray, but doesn't matter that much.

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Thursday, August 13, 2015 11:05:23 AM
> Subject: Re: [hibernate-dev] Hosting of binaries
> 
> TBH SourceForge is generally the least of my worries when doing a release
> nowadays.  Yes I have had trouble with it the last 2 releases due to their
> outage, but honestly the JBoss Nexus has been a bigger pain-point more
> often.  And blogging is getting there too.
> 
> Unless I am mistaken, distribution is the only thing we use the SF hosting
> for at the moment.  I really have no idea what you mean wrt "their
> ethics".  Can you elaborate?
> 
> The question is alternatives.  We discussed GitHub releases on another
> thread, so I won't go back into that; I think we all agree that is not the
> best idea.  Which leaves us BinTray and JBoss.
> 
> In general I think I'd prefer "well known" solutions.  If someone is
> looking for a release, chances are they are going to one of these central
> places (Maven Central, Bintray/JCenter, SourceForge).  The JBoss download
> server is a bit niche, imo.  Granted this is partially education and/or
> documentation to point people to the "right place".  But my current
> thinking is starting to shift to covering all the right places.
> 
> For dependency-management artifacts, why not make sure we publish to all of
> them?  Maven Central, JBoss Nexus, JCenter.  The thing that has killed my
> last few release attempts has been JBoss Nexus (*transient* failures to
> upload artifacts).  I'd *love* to cut that out of the release process.  Of
> course it eventually needs to end up there.  So we'd have to consider
> options for that to happen.  But ultimately I'd love to have a solution
> that simply ensures the artifacts end up in all 3 (and possibly more)
> places.
> 
> For release bundles, again JBoss server is a bit niche to me.  I'm ok with
> making sure these end up there *as well* but I do not think it should be
> the primary location.  To me that is SourceForge or BinTray.
> 
> 
> On Thu, Aug 13, 2015 at 9:50 AM Brett Meyer <brmeyer at redhat.com> wrote:
> 
> > Sorry, late to this...
> >
> > My vote would be to get rid of SourceForge entirely.  I can't stand their
> > ethics, services, or downtime...
> >
> > We use download.jboss.org for Artificer and haven't had any issues.
> > Fully supports SCP or SFTP -- I already have it scripted and would be more
> > than happy to help put it together for Hibernate.  Plus,
> > jboss.org/redhat.org now include Splunk for parsing the server logs --
> > getting download metrics is fairly straight-forward.
> >
> > ----- Original Message -----
> > > From: "Steve Ebersole" <steve at hibernate.org>
> > > To: "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <
> > gunnar at hibernate.org>
> > > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > > Sent: Friday, July 31, 2015 2:37:29 PM
> > > Subject: Re: [hibernate-dev] Hosting of binaries
> > >
> > > FWIW the SourceForge upload UI seems to be restored.
> > >
> > >
> > >
> > > On Thu, Jul 30, 2015 at 2:14 AM Emmanuel Bernard <emmanuel at hibernate.org
> > >
> > > wrote:
> > >
> > > > For info, SourceForge hopes to restore ssh access (the last service
> > they
> > > > will activate) August 3rd.
> > > >
> > > >
> > http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/
> > > >
> > > > > On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> > > > >
> > > > > Your proposed order seems good. I'd exclude GitHub if it's not
> > > > scriptable (UI only) as this will hinder releases from the CI server.
> > > > >
> > > > > 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org
> > > > <mailto:emmanuel at hibernate.org>>:
> > > > > As some of you know Sourceforge has had a severe distributed file
> > system
> > > > corruption and they have been working on it for a full week. You can
> > read
> > > > their blog for regular updates http://sourceforge.net/blog/ <
> > > > http://sourceforge.net/blog/>
> > > > > The concrete issue for us is that we cannot upload new files:
> > Hibernate
> > > > Validator and Hibernate ORM are now pending a release.
> > > > >
> > > > > There are 4 options on the table
> > > > >
> > > > > Be patient::
> > > > > SourceForge will eventually reopen upload, I imagine it might take
> > form
> > > > one to two weeks.
> > > > > Their binary hosting support is relatively correct and all of our
> > > > download statistics are there.
> > > > >
> > > > > Move to download.jboss.org <http://download.jboss.org/>::
> > > > > JBoss has a facility to host binaries. WildFly amongst other uses
> > it. We
> > > > can ask them if they are happy with it.
> > > > > It is not connected to the rest of the forum/CMS infra, it?s a simple
> > > > file upload AFAIK so easily scriptable.
> > > > > They also offer statistics but how needs to be investigated.
> > > > >
> > > > > Move to GitHub::
> > > > > GitHub has a binary upload facility. I could only find a web based
> > > > approach (can it be done programmatically?).
> > > > > They don?t seem to have any statistics service, which is a big
> > negative
> > > > point.
> > > > > Also I don?t trust GitHub anymore for their binary hosting. They had
> > a
> > > > version in the past that they scrapped with barely no notice. I?m not
> > > > exactly willing to give them my trust again.
> > > > >
> > > > > Move to BinTray::
> > > > > Binary hosting is their life and blood. People seem happy with them.
> > It
> > > > seems however that the statistics require a paying package instead of
> > the
> > > > free oss tier.
> > > > >
> > > > > I think we should try in the following order:
> > > > >
> > > > > 1. Be patient with Sourceforge (but for how long?)
> > > > > 2. go for download.jboss.org <http://download.jboss.org/> and before
> > > > that ask around for the process and stability of the infrastructure
> > > > > 3. explore Bintray
> > > > > 4. GitHub (did I say that I no longer trust their binary hosting
> > > > support?)
> > > > > _______________________________________________
> > > > > hibernate-dev mailing list
> > > > > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev <
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> > > >
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 


From steve at hibernate.org  Fri Aug 14 06:07:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 14 Aug 2015 10:07:04 +0000
Subject: [hibernate-dev] ORM Documentation
In-Reply-To: <CAFdSV9t+uWCVseDifqfqO-CN_m72uNeL06=mxY5uHGQvMHZhzQ@mail.gmail.com>
References: <CAFdSV9vwMXhjs52YHA8fKGBVA=JOWGq0RQfp+C2_yAwzRhEaJw@mail.gmail.com>
	<CAFm4XO0oSks8ME74=hMj2e4F2g5fFdiEh2VSsfcYmGgmjRz2pA@mail.gmail.com>
	<CAFdSV9uckVaAyyYZvScH9dAXs_0EEhWaGqKh=5B7QtnroPyeqA@mail.gmail.com>
	<CAFdSV9tYiX-kVSdC85aCcDx8wzYhJeDuekwXi2YBjBjgREk3Gw@mail.gmail.com>
	<D37C8ED8-FFAE-4DFC-ABA9-51655690D1EB@hibernate.org>
	<CAFdSV9spL=-wbLj1Zw1BkTw5M42PSjknSrCt1vfKi0TdvH6K7g@mail.gmail.com>
	<CAFdSV9t+uWCVseDifqfqO-CN_m72uNeL06=mxY5uHGQvMHZhzQ@mail.gmail.com>
Message-ID: <CAFdSV9tgBriTpnmtgBqfnhxXzpTeb2os5d3mQ83fV0xYkskK+w@mail.gmail.com>

The one drawback to splitting out a mapping guide from the user guide (and
it is a big one) is the inability to link to discussions in the user guide,
and vice versa.  Instead I have to keep saying things like "For details see
XYZ in the <citetitle>Hibernate User Guide</citetitle>".  I would imagine,
as a user, that would get old after a while - not being able to just click
there.  Opinions?


On Mon, Aug 3, 2015 at 7:15 PM Steve Ebersole <steve at hibernate.org> wrote:

> Well Identifiers in the mapping guide still needs some work.  I guess move
> that into category (b).  TBH I do not know how much of "derived identities"
> I will document this time around.  If someone more familiar/comfortable
> with explaining that stuff wanted to take a shot I would not argue :)
>
>
> On Mon, Aug 3, 2015 at 6:55 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> So the documentation is getting along.  If people could start looking it
>> over that would be great.  If people are willing to pick up remaining
>> topics, even better!
>>
>> So the 2 old docs (manual and devguide) are now 3 much more focused docs:
>>
>> 1) Hibernate User Guide - much of the information from the old manual
>> with lots of TLC and updates.
>>
>> a) Chapters I think are in good shape: Architecture,
>> DomainModel, Bootstrap, PersistenceContext, Database_Access, Transactions,
>> JNDI, Portability.
>> b) Chapters that need some work: Locking, Fetching, Caching, Events,
>> Multi_Tenancy, OSGi, Envers.
>> c) Chapters that either still need writing or new major work: Batching,
>> HQL, Criteria, Native Queries
>>
>> This stuff is in documentation/src/main/docbook/manual, although I
>> expect to rename manual to userGuide to better align.  To build it, run
>> `gradle renderDocBook_manual` and look in
>> documentation/target/docbook/publish/manual.
>>
>>
>> 2) Hibernate Domain Model Mapping Guide - IMO mapping is such a massive
>> topic it deserves its own guide.  And this is it :)  I have put A LOT of
>> work into this content, but there is still tons to do.
>>
>> a) Chapters I think are in good shape: Data_Categorizations,
>> Basic_Types, Composition, Identifiers
>> b) Chapters that need some work: Collections,
>> c) Chapters that either still need writing or new major work: Entity, Natural_Id, Associations, Secondary_Tables, Attribute_Access, Mapping_Overrides, Generated_attributes,
>> "read/write
>> fragments", Naming_Strategies, SQL_Identifier_Quoting, Database_Constraints, Auxiliary_DB_Objects
>>
>> This content is in documentation/src/main/docbook/mapping.  To build it,
>> run `gradle renderDocBook_mapping` and look in
>> documentation/target/docbook/publish/mapping.
>>
>>
>> 3) Hibernate Integrations Guide - This is intended to document all the
>> major integration points with Hibernate.  So far it is just a chapter on
>> Service+Registry.  I have started keeping a list of topics to cover in Hibernate_Integrations.xml.
>> Feel free to add your favorites!
>>
>>
>> On Thu, Jul 30, 2015 at 2:11 AM Emmanuel Bernard <emmanuel at hibernate.org>
>> wrote:
>>
>>> I think topical guides never got traction because the work on doc was
>>> down to zero. I would not give up hope on them :)
>>>
>>> > On 28 Jul 2015, at 19:51, Steve Ebersole <steve at hibernate.org> wrote:
>>> >
>>> > So tentatively I have the following docs:
>>> >
>>> > 1) "User Manual" - mostly done
>>> > 2) "Domain Model Mapping Guide" - work in progress, but progressing
>>> nicely.
>>> > 3) "Integrations Guide" - atm this will be just the devguide with the
>>> > Service+Registry chapter; but I'd like to circle back and pick up other
>>> > topics later.
>>> >
>>> > This leaves some open points of discussion.  From the proposal itself:
>>> >
>>> > 1) What do we cover in "batching"?
>>> > 2) "additionalmodules"?  I am inclined to simply drop that one, so
>>> unless I
>>> > here differently that is what will happen.
>>> >
>>> > Emmanuel replied (on irc maybe?  I forget where) that he thought topics
>>> > such as "Performance Monitoring" and "Best Practices" ought to be
>>> separate
>>> > documents.
>>> >
>>> > He also suggested a chapter on bootstrapping.  I totally agree.  I
>>> > essentially copied the topical guides on bootstrapping as a chapter in
>>> the
>>> > User Guide.  But that brings up an interesting point as to the
>>> distinction
>>> > between topical guides and documentation.  When should something go
>>> where?
>>> > I almost like to look at the topical guides as a wiki.  I don't think
>>> > anyone is thrilled with the SBS "wiki" we have access to.  I look at
>>> this
>>> > as an asciidoctor-based alternative.  Of course between SBS, GitHub
>>> wiki,
>>> > topical guides... gets to be a lot of places to look.  Initially the
>>> idea
>>> > of the topical guides was to break down the massive documentation into
>>> more
>>> > easily digestible chunks.  But that never gained traction.  Should they
>>> > just go away?
>>> >
>>> >
>>> > On Mon, Jul 27, 2015 at 5:10 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> >
>>> >> Sanne, yep thats why I sent the second email with a link ;)
>>> >>
>>> >> Anyway..  I just pushed some initial work on the manual.  Its not
>>> complete
>>> >> yet.  And I still need to start on the mapping guide.  Let me know any
>>> >> thoughts y'all have.
>>> >>
>>> >>
>>> >> On Mon, Jul 27, 2015 at 2:31 PM Sanne Grinovero <sanne at hibernate.org>
>>> >> wrote:
>>> >>
>>> >>> I didn't receive an attachment. AFAIK the mailing list drops them?
>>> >>> On 27 Jul 2015 14:39, "Steve Ebersole" <steve at hibernate.org> wrote:
>>> >>>
>>> >>>> I have been putting a lot of TLC into the ORM documentation this
>>> weekend
>>> >>>> getting ready for 5.0 to go Final.  To that end I have put together
>>> a
>>> >>>> proposal for these changes, it is attached.  I'd like to get some
>>> >>>> feedback.  Thanks
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> hibernate-dev mailing list
>>> >>>> hibernate-dev at lists.jboss.org
>>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>>>
>>> >>>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>

From sanne at hibernate.org  Fri Aug 14 06:14:57 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 14 Aug 2015 11:14:57 +0100
Subject: [hibernate-dev] InfinispanTestingSetup
Message-ID: <CAFm4XO1YKt2Y1pYeAGQ3Q4z9Kia2vxhhs0i2ZcRkyFnUrpHK-w@mail.gmail.com>

Context is this IRC question:

<rvansa> [08:14:33] sannegrinovero: Hi, may I ask why have you
sometimes added InfinispanTestingSetup as @ClassRule and sometimes as
@Rule in HHH-10001?
[11:06] <jbossbot> [08:14:34] jira [HHH-10001] Make the testsuite
compatible with Infinispan 8 [Closed (Fixed) Task, Major, Sanne
Grinovero] https://hibernate.atlassian.net/browse/HHH-10001

Hi Radim,

I generally wanted to set it as test rule only as that gives a
stricter cleanup verification, but in some cases the excessive
isolation rules would have it fail: apparently some are relying on
previous tests.

That's something which should be cleaned up in the tests I guess but I
only wanted to workaround the API change in the Infinispan testsuite
without risking a semantic change of the tests.. I also didn't have a
good understanding of the purpose of those tests.

If you're interesting in cleaning that up, you should be able to try
changing the @ClassRule instances to @Rule instances and you'll see
the test fail.

Sanne

From steve at hibernate.org  Fri Aug 14 08:12:43 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 14 Aug 2015 12:12:43 +0000
Subject: [hibernate-dev] Hosting of binaries
In-Reply-To: <1921945687.10142157.1439490440731.JavaMail.zimbra@redhat.com>
References: <B0E16C70-982D-4D11-A1D5-EF688FE4A9A6@hibernate.org>
	<CADGJaX_GOsjMY1vD=115hu06jx-J69r2MqHk+vxZr4uv2z9keg@mail.gmail.com>
	<7E45E877-FD00-4C29-8D57-B2F6EDD19159@hibernate.org>
	<CAFdSV9taM1ZsLTVxP9UfjrwuGbq3Q1CyAUF4vD4zvLw8hLZBBg@mail.gmail.com>
	<292276043.10039071.1439477421510.JavaMail.zimbra@redhat.com>
	<CAFdSV9sgeUAQybgWjVrbQcMHq+gNyiwHBbGMR95V6M=H4zis4Q@mail.gmail.com>
	<1921945687.10142157.1439490440731.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9vSjandT-8eeBDv1Y5QMBNSE_0-m5+972pS8vch9+CNug@mail.gmail.com>

I played with BinTray some this morning, along with Sanne and Gunnar via
IRC.  Assuming we all think it is a good idea to have a presence on BinTray
(and that seems to be a consensus), the next question becomes what to
upload here[1].  Sanne and Gunnar and I tried to get our heads around
BinTray concepts (repos, packages, versions) and how to best apply them for
our needs.

In BinTray, you have "typed" repositories.  Specifically we'd be interested
in 'generic' and 'maven' types for release bundles ("SF bundles") and
dependency-management artifacts respectively.  They also offer rpm, docker,
virtual box, etc typed repos.

The concept of a package is a bit open-ended.  Initially I was unsure of
the correct granularity between BinTray repositories and packages, and
projects/artifacts.  However, the guide[2] on importing info from GitHub
has the proper alignment I think.  We'd have 1 maven repo, and 1 bundle
(generic) repo.  Within each we'd have a package for each project
(hibernate-orm, hibernate-search, etc).  And then versions under those.

Packages can easily be linked into JCenter, which is BinTray's top-level
maven repo.

The local repo and package give us a nice place to point people in release
notes, announcements, etc.  Inclusion in JCenter gives nice unified url
access for builds.

[1] - And also I think the question becomes, to some degree, what we
consider the authoritative source for these maven and bundle artifacts.
[2] -
https://bintray.com/docs/usermanual/uploads/uploads_importingfromgithub.html


On Thu, Aug 13, 2015 at 1:27 PM Brett Meyer <brmeyer at redhat.com> wrote:

> > I really have no idea what you mean wrt "their ethics".  Can you
> elaborate?
>
> Wrapping binaries and including bloatware, ads posing as large Download
> buttons and leading to shady sites, parent company more interested in
> squeezing out profit through sketchy means, etc.  (Although, it sounds like
> the latter may be changing.  Supposedly the parent company recently dropped
> both SF and Slashdot.)
>
> > For release bundles, again JBoss server is a bit niche to me.  I'm ok
> with
> > making sure these end up there *as well* but I do not think it should be
> > the primary location.  To me that is SourceForge or BinTray.
>
> Fair point -- sounds reasonable.  I'd personally prefer BinTray, but
> doesn't matter that much.
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "Brett Meyer" <brmeyer at redhat.com>, "Hibernate Dev" <
> hibernate-dev at lists.jboss.org>
> > Sent: Thursday, August 13, 2015 11:05:23 AM
> > Subject: Re: [hibernate-dev] Hosting of binaries
> >
> > TBH SourceForge is generally the least of my worries when doing a release
> > nowadays.  Yes I have had trouble with it the last 2 releases due to
> their
> > outage, but honestly the JBoss Nexus has been a bigger pain-point more
> > often.  And blogging is getting there too.
> >
> > Unless I am mistaken, distribution is the only thing we use the SF
> hosting
> > for at the moment.  I really have no idea what you mean wrt "their
> > ethics".  Can you elaborate?
> >
> > The question is alternatives.  We discussed GitHub releases on another
> > thread, so I won't go back into that; I think we all agree that is not
> the
> > best idea.  Which leaves us BinTray and JBoss.
> >
> > In general I think I'd prefer "well known" solutions.  If someone is
> > looking for a release, chances are they are going to one of these central
> > places (Maven Central, Bintray/JCenter, SourceForge).  The JBoss download
> > server is a bit niche, imo.  Granted this is partially education and/or
> > documentation to point people to the "right place".  But my current
> > thinking is starting to shift to covering all the right places.
> >
> > For dependency-management artifacts, why not make sure we publish to all
> of
> > them?  Maven Central, JBoss Nexus, JCenter.  The thing that has killed my
> > last few release attempts has been JBoss Nexus (*transient* failures to
> > upload artifacts).  I'd *love* to cut that out of the release process.
> Of
> > course it eventually needs to end up there.  So we'd have to consider
> > options for that to happen.  But ultimately I'd love to have a solution
> > that simply ensures the artifacts end up in all 3 (and possibly more)
> > places.
> >
> > For release bundles, again JBoss server is a bit niche to me.  I'm ok
> with
> > making sure these end up there *as well* but I do not think it should be
> > the primary location.  To me that is SourceForge or BinTray.
> >
> >
> > On Thu, Aug 13, 2015 at 9:50 AM Brett Meyer <brmeyer at redhat.com> wrote:
> >
> > > Sorry, late to this...
> > >
> > > My vote would be to get rid of SourceForge entirely.  I can't stand
> their
> > > ethics, services, or downtime...
> > >
> > > We use download.jboss.org for Artificer and haven't had any issues.
> > > Fully supports SCP or SFTP -- I already have it scripted and would be
> more
> > > than happy to help put it together for Hibernate.  Plus,
> > > jboss.org/redhat.org now include Splunk for parsing the server logs --
> > > getting download metrics is fairly straight-forward.
> > >
> > > ----- Original Message -----
> > > > From: "Steve Ebersole" <steve at hibernate.org>
> > > > To: "Emmanuel Bernard" <emmanuel at hibernate.org>, "Gunnar Morling" <
> > > gunnar at hibernate.org>
> > > > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > > > Sent: Friday, July 31, 2015 2:37:29 PM
> > > > Subject: Re: [hibernate-dev] Hosting of binaries
> > > >
> > > > FWIW the SourceForge upload UI seems to be restored.
> > > >
> > > >
> > > >
> > > > On Thu, Jul 30, 2015 at 2:14 AM Emmanuel Bernard <
> emmanuel at hibernate.org
> > > >
> > > > wrote:
> > > >
> > > > > For info, SourceForge hopes to restore ssh access (the last service
> > > they
> > > > > will activate) August 3rd.
> > > > >
> > > > >
> > >
> http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/
> > > > >
> > > > > > On 28 Jul 2015, at 10:27, Gunnar Morling <gunnar at hibernate.org>
> > > wrote:
> > > > > >
> > > > > > Your proposed order seems good. I'd exclude GitHub if it's not
> > > > > scriptable (UI only) as this will hinder releases from the CI
> server.
> > > > > >
> > > > > > 2015-07-28 9:39 GMT+02:00 Emmanuel Bernard <
> emmanuel at hibernate.org
> > > > > <mailto:emmanuel at hibernate.org>>:
> > > > > > As some of you know Sourceforge has had a severe distributed file
> > > system
> > > > > corruption and they have been working on it for a full week. You
> can
> > > read
> > > > > their blog for regular updates http://sourceforge.net/blog/ <
> > > > > http://sourceforge.net/blog/>
> > > > > > The concrete issue for us is that we cannot upload new files:
> > > Hibernate
> > > > > Validator and Hibernate ORM are now pending a release.
> > > > > >
> > > > > > There are 4 options on the table
> > > > > >
> > > > > > Be patient::
> > > > > > SourceForge will eventually reopen upload, I imagine it might
> take
> > > form
> > > > > one to two weeks.
> > > > > > Their binary hosting support is relatively correct and all of our
> > > > > download statistics are there.
> > > > > >
> > > > > > Move to download.jboss.org <http://download.jboss.org/>::
> > > > > > JBoss has a facility to host binaries. WildFly amongst other uses
> > > it. We
> > > > > can ask them if they are happy with it.
> > > > > > It is not connected to the rest of the forum/CMS infra, it?s a
> simple
> > > > > file upload AFAIK so easily scriptable.
> > > > > > They also offer statistics but how needs to be investigated.
> > > > > >
> > > > > > Move to GitHub::
> > > > > > GitHub has a binary upload facility. I could only find a web
> based
> > > > > approach (can it be done programmatically?).
> > > > > > They don?t seem to have any statistics service, which is a big
> > > negative
> > > > > point.
> > > > > > Also I don?t trust GitHub anymore for their binary hosting. They
> had
> > > a
> > > > > version in the past that they scrapped with barely no notice. I?m
> not
> > > > > exactly willing to give them my trust again.
> > > > > >
> > > > > > Move to BinTray::
> > > > > > Binary hosting is their life and blood. People seem happy with
> them.
> > > It
> > > > > seems however that the statistics require a paying package instead
> of
> > > the
> > > > > free oss tier.
> > > > > >
> > > > > > I think we should try in the following order:
> > > > > >
> > > > > > 1. Be patient with Sourceforge (but for how long?)
> > > > > > 2. go for download.jboss.org <http://download.jboss.org/> and
> before
> > > > > that ask around for the process and stability of the infrastructure
> > > > > > 3. explore Bintray
> > > > > > 4. GitHub (did I say that I no longer trust their binary hosting
> > > > > support?)
> > > > > > _______________________________________________
> > > > > > hibernate-dev mailing list
> > > > > > hibernate-dev at lists.jboss.org <mailto:
> hibernate-dev at lists.jboss.org>
> > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev <
> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> > > > >
> > > > > _______________________________________________
> > > > > hibernate-dev mailing list
> > > > > hibernate-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From steve at hibernate.org  Fri Aug 14 11:32:05 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 14 Aug 2015 15:32:05 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
Message-ID: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>

We've had a few discussions about this in the past.  As 5.0 is getting
close to Final (next week), its time to start contemplating our next major
tasks.  The consensus pick for that has been the idea of a "unified SQL
generation engine" along with a shared project for the semantic analysis of
HQL/JPQL (and recently it was decided to include JPA Criteria
interpretation here as well).

The central premise is this.  Take the roughly 6 or 7 different top-level
ways Hibernate generates SQL and combine that into one "engine" based on
the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria shared
project will be one producer of such semantic trees.  Others would include
persisters (for insert/update/delete requests) and loaders (for load
requests).

We have a lot of tasks for this overall goal still remaining.

We still have to finalize the design for the HQL/JPQL/Criteria to semantic
tree translator.  One option is to proceed with the Antlr 4 based approach
I started a PoC for.  John has been helping me some lately with that.  The
first task here is to come to a consensus whether Antlr 4 is the way we
want to proceed here.  We've been over the pros and cons before in detail.
In summary, there is a lot to love with Antlr 4.  Our grammar for HQL
recognition and semantic tree building is very simple and elegant imo.  The
drawback is clearly the lack of tree walking, meaning that we are
responsible for writing by hand our walker for the semantic tree.  In fact
multiple, since each consumer (orm, ogm, search) would need to write their
own.  And if we decide to build another AST while walking the semantic
tree, we'd end up having to hand-write yet another walker for those.

What I mean by that last part is that there are 2 ways we might choose to
deal with the semantic tree.  For the purpose of discussion, let's look at
the ORM case.  The first approach is to simply generate the SQL as we walk
the semantic tree; this would be a 2 phase interpretation approach (input
-> semantic tree -> SQL).  That works in many cases.  However it breaks
down in other cases.  This is exactly the approach our existing HQL
translator uses.  The other approach is to use a 3-phase translation (input
-> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to one
of the major problems.  One source "semantic" query will often correspond
to multiple SQL queries; that is hard to manage in the 2-phase approach.
And not to mention integrating things like follow-on fetches and other
enhancements we want to gain from this.  My vote is definitely for 3 or
more phases of interpretation.  The problem is that this is exactly where
Antlr 4 sort of falls down.

So first things first... we need to decide on Antlr 3 versus Antlr 4
(versus some other parser solution).

Next, on the ORM side (every "backend" can decide this individually) we
need to decide on the approach for semantic-tree to SQL translation, which
somewhat depends on the Antlr 3 versus Antlr 4 decision.

We really need to decide these things ASAP and get moving on them as soon
as ORM 5.0 is finished.

Also, this is a massive undertaking with huge gain potentials for not just
ORM.  As such we need to understand who will be working on this.  Sanne,
Gunnar... I know y'all have a vested interest and a desire to work on it.
John, I know the same is true for you.  Andrea?  Have you had a chance to
look over the poc and/or get more familiar with Antlr?

From steve at hibernate.org  Sat Aug 15 10:25:07 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 15 Aug 2015 14:25:07 +0000
Subject: [hibernate-dev] Naming strategies 4.3 -> 5.0
Message-ID: <CAFdSV9vwBLZJzW7m7rLkaxf7ycsAphX0uXKD_wZwY5rPXOqAbQ@mail.gmail.com>

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?

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<Input> 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.

From rvansa at redhat.com  Mon Aug 17 03:26:47 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 17 Aug 2015 09:26:47 +0200
Subject: [hibernate-dev] InfinispanTestingSetup
In-Reply-To: <CAFm4XO1YKt2Y1pYeAGQ3Q4z9Kia2vxhhs0i2ZcRkyFnUrpHK-w@mail.gmail.com>
References: <CAFm4XO1YKt2Y1pYeAGQ3Q4z9Kia2vxhhs0i2ZcRkyFnUrpHK-w@mail.gmail.com>
Message-ID: <55D18CB7.2030608@redhat.com>

OK, thanks for the info. I am truly trying to rewrite the refactor the 
testsuite as part of [1] so that we can run the tests against all 
concurrency strategy modes and cache configurations (I am working on 
tombstone-based 2LC implementation). Also, I hope I can speed up the 
testsuite (I see that some tests hang for 15 seconds due to some problem 
in JGroups).

Radim

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

On 08/14/2015 12:14 PM, Sanne Grinovero wrote:
> Context is this IRC question:
>
> <rvansa> [08:14:33] sannegrinovero: Hi, may I ask why have you
> sometimes added InfinispanTestingSetup as @ClassRule and sometimes as
> @Rule in HHH-10001?
> [11:06] <jbossbot> [08:14:34] jira [HHH-10001] Make the testsuite
> compatible with Infinispan 8 [Closed (Fixed) Task, Major, Sanne
> Grinovero] https://hibernate.atlassian.net/browse/HHH-10001
>
> Hi Radim,
>
> I generally wanted to set it as test rule only as that gives a
> stricter cleanup verification, but in some cases the excessive
> isolation rules would have it fail: apparently some are relying on
> previous tests.
>
> That's something which should be cleaned up in the tests I guess but I
> only wanted to workaround the API change in the Infinispan testsuite
> without risking a semantic change of the tests.. I also didn't have a
> good understanding of the purpose of those tests.
>
> If you're interesting in cleaning that up, you should be able to try
> changing the @ClassRule instances to @Rule instances and you'll see
> the test fail.
>
> Sanne


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


From sanne at hibernate.org  Mon Aug 17 07:37:55 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 17 Aug 2015 12:37:55 +0100
Subject: [hibernate-dev] InfinispanTestingSetup
In-Reply-To: <55D18CB7.2030608@redhat.com>
References: <CAFm4XO1YKt2Y1pYeAGQ3Q4z9Kia2vxhhs0i2ZcRkyFnUrpHK-w@mail.gmail.com>
	<55D18CB7.2030608@redhat.com>
Message-ID: <CAFm4XO3yPWR5Bk_+humkTMu2OkA8Sn1kMq2HVrRXs+oXNSrbVA@mail.gmail.com>

Great, I also thought tombstones would be essential to improve the
2lc. Are you going to bake that feature within Infinispan or as a
customization within the Hibernate code?

On 17 August 2015 at 08:26, Radim Vansa <rvansa at redhat.com> wrote:
> OK, thanks for the info. I am truly trying to rewrite the refactor the
> testsuite as part of [1] so that we can run the tests against all
> concurrency strategy modes and cache configurations (I am working on
> tombstone-based 2LC implementation). Also, I hope I can speed up the
> testsuite (I see that some tests hang for 15 seconds due to some problem in
> JGroups).
>
> Radim
>
> [1] https://hibernate.atlassian.net/browse/HHH-10030
>
>
> On 08/14/2015 12:14 PM, Sanne Grinovero wrote:
>>
>> Context is this IRC question:
>>
>> <rvansa> [08:14:33] sannegrinovero: Hi, may I ask why have you
>> sometimes added InfinispanTestingSetup as @ClassRule and sometimes as
>> @Rule in HHH-10001?
>> [11:06] <jbossbot> [08:14:34] jira [HHH-10001] Make the testsuite
>> compatible with Infinispan 8 [Closed (Fixed) Task, Major, Sanne
>> Grinovero] https://hibernate.atlassian.net/browse/HHH-10001
>>
>> Hi Radim,
>>
>> I generally wanted to set it as test rule only as that gives a
>> stricter cleanup verification, but in some cases the excessive
>> isolation rules would have it fail: apparently some are relying on
>> previous tests.
>>
>> That's something which should be cleaned up in the tests I guess but I
>> only wanted to workaround the API change in the Infinispan testsuite
>> without risking a semantic change of the tests.. I also didn't have a
>> good understanding of the purpose of those tests.
>>
>> If you're interesting in cleaning that up, you should be able to try
>> changing the @ClassRule instances to @Rule instances and you'll see
>> the test fail.
>>
>> Sanne
>
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>

From rvansa at redhat.com  Mon Aug 17 07:49:35 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 17 Aug 2015 13:49:35 +0200
Subject: [hibernate-dev] InfinispanTestingSetup
In-Reply-To: <CAFm4XO3yPWR5Bk_+humkTMu2OkA8Sn1kMq2HVrRXs+oXNSrbVA@mail.gmail.com>
References: <CAFm4XO1YKt2Y1pYeAGQ3Q4z9Kia2vxhhs0i2ZcRkyFnUrpHK-w@mail.gmail.com>
	<55D18CB7.2030608@redhat.com>
	<CAFm4XO3yPWR5Bk_+humkTMu2OkA8Sn1kMq2HVrRXs+oXNSrbVA@mail.gmail.com>
Message-ID: <55D1CA4F.5020009@redhat.com>

Right now I want to do that purely in Hibernate integration part, as I 
don't see why such user approach should not work - replacing remove(key) 
calls with put(key, tombstone singleton, expiration args). It's possible 
that I hit the wall somewhere and have to go down to Infinispan.

My general plan is to do stuff in Hibernate now, see what's needed and 
then we could discuss possible infinispan core enhancements (that would 
get rid of the custom interceptors I've written) on clustering meeting, 
when I'll see all the trouble in the big picture.

In my opinion, infinispan core is in need of user-managed versioning API 
(used internally for conditional commands, too) rather than tombstones 
alone. Functional API which is about to appear in 8.0 soon should give 
us the opportunity to emulate proper versioning (though, with tombstones 
for removal, too).

Radim

On 08/17/2015 01:37 PM, Sanne Grinovero wrote:
> Great, I also thought tombstones would be essential to improve the
> 2lc. Are you going to bake that feature within Infinispan or as a
> customization within the Hibernate code?
>
> On 17 August 2015 at 08:26, Radim Vansa <rvansa at redhat.com> wrote:
>> OK, thanks for the info. I am truly trying to rewrite the refactor the
>> testsuite as part of [1] so that we can run the tests against all
>> concurrency strategy modes and cache configurations (I am working on
>> tombstone-based 2LC implementation). Also, I hope I can speed up the
>> testsuite (I see that some tests hang for 15 seconds due to some problem in
>> JGroups).
>>
>> Radim
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-10030
>>
>>
>> On 08/14/2015 12:14 PM, Sanne Grinovero wrote:
>>> Context is this IRC question:
>>>
>>> <rvansa> [08:14:33] sannegrinovero: Hi, may I ask why have you
>>> sometimes added InfinispanTestingSetup as @ClassRule and sometimes as
>>> @Rule in HHH-10001?
>>> [11:06] <jbossbot> [08:14:34] jira [HHH-10001] Make the testsuite
>>> compatible with Infinispan 8 [Closed (Fixed) Task, Major, Sanne
>>> Grinovero] https://hibernate.atlassian.net/browse/HHH-10001
>>>
>>> Hi Radim,
>>>
>>> I generally wanted to set it as test rule only as that gives a
>>> stricter cleanup verification, but in some cases the excessive
>>> isolation rules would have it fail: apparently some are relying on
>>> previous tests.
>>>
>>> That's something which should be cleaned up in the tests I guess but I
>>> only wanted to workaround the API change in the Infinispan testsuite
>>> without risking a semantic change of the tests.. I also didn't have a
>>> good understanding of the purpose of those tests.
>>>
>>> If you're interesting in cleaning that up, you should be able to try
>>> changing the @ClassRule instances to @Rule instances and you'll see
>>> the test fail.
>>>
>>> Sanne
>>
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>


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


From sanne at hibernate.org  Mon Aug 17 08:03:19 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 17 Aug 2015 13:03:19 +0100
Subject: [hibernate-dev] InfinispanTestingSetup
In-Reply-To: <55D1CA4F.5020009@redhat.com>
References: <CAFm4XO1YKt2Y1pYeAGQ3Q4z9Kia2vxhhs0i2ZcRkyFnUrpHK-w@mail.gmail.com>
	<55D18CB7.2030608@redhat.com>
	<CAFm4XO3yPWR5Bk_+humkTMu2OkA8Sn1kMq2HVrRXs+oXNSrbVA@mail.gmail.com>
	<55D1CA4F.5020009@redhat.com>
Message-ID: <CAFm4XO3-v6-bfHU5HdnKotSWr94Uz73ji8GC+6RekX1cFRdktw@mail.gmail.com>

Sounds like a good plan, it always worked well for me to have
prototypes working first and then come the the Infinispan mailing list
with a concrete proposal.

+10 for the better conditional API.. I've always struggled with that,
you can find some references to the discussion by searching for "MVCC"
on the mailing list - even though it's not the appropriate term ;-)

On 17 August 2015 at 12:49, Radim Vansa <rvansa at redhat.com> wrote:
> Right now I want to do that purely in Hibernate integration part, as I don't
> see why such user approach should not work - replacing remove(key) calls
> with put(key, tombstone singleton, expiration args). It's possible that I
> hit the wall somewhere and have to go down to Infinispan.
>
> My general plan is to do stuff in Hibernate now, see what's needed and then
> we could discuss possible infinispan core enhancements (that would get rid
> of the custom interceptors I've written) on clustering meeting, when I'll
> see all the trouble in the big picture.
>
> In my opinion, infinispan core is in need of user-managed versioning API
> (used internally for conditional commands, too) rather than tombstones
> alone. Functional API which is about to appear in 8.0 soon should give us
> the opportunity to emulate proper versioning (though, with tombstones for
> removal, too).
>
> Radim
>
>
> On 08/17/2015 01:37 PM, Sanne Grinovero wrote:
>>
>> Great, I also thought tombstones would be essential to improve the
>> 2lc. Are you going to bake that feature within Infinispan or as a
>> customization within the Hibernate code?
>>
>> On 17 August 2015 at 08:26, Radim Vansa <rvansa at redhat.com> wrote:
>>>
>>> OK, thanks for the info. I am truly trying to rewrite the refactor the
>>> testsuite as part of [1] so that we can run the tests against all
>>> concurrency strategy modes and cache configurations (I am working on
>>> tombstone-based 2LC implementation). Also, I hope I can speed up the
>>> testsuite (I see that some tests hang for 15 seconds due to some problem
>>> in
>>> JGroups).
>>>
>>> Radim
>>>
>>> [1] https://hibernate.atlassian.net/browse/HHH-10030
>>>
>>>
>>> On 08/14/2015 12:14 PM, Sanne Grinovero wrote:
>>>>
>>>> Context is this IRC question:
>>>>
>>>> <rvansa> [08:14:33] sannegrinovero: Hi, may I ask why have you
>>>> sometimes added InfinispanTestingSetup as @ClassRule and sometimes as
>>>> @Rule in HHH-10001?
>>>> [11:06] <jbossbot> [08:14:34] jira [HHH-10001] Make the testsuite
>>>> compatible with Infinispan 8 [Closed (Fixed) Task, Major, Sanne
>>>> Grinovero] https://hibernate.atlassian.net/browse/HHH-10001
>>>>
>>>> Hi Radim,
>>>>
>>>> I generally wanted to set it as test rule only as that gives a
>>>> stricter cleanup verification, but in some cases the excessive
>>>> isolation rules would have it fail: apparently some are relying on
>>>> previous tests.
>>>>
>>>> That's something which should be cleaned up in the tests I guess but I
>>>> only wanted to workaround the API change in the Infinispan testsuite
>>>> without risking a semantic change of the tests.. I also didn't have a
>>>> good understanding of the purpose of those tests.
>>>>
>>>> If you're interesting in cleaning that up, you should be able to try
>>>> changing the @ClassRule instances to @Rule instances and you'll see
>>>> the test fail.
>>>>
>>>> Sanne
>>>
>>>
>>>
>>> --
>>> Radim Vansa <rvansa at redhat.com>
>>> JBoss Performance Team
>>>
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>

From gbadner at redhat.com  Mon Aug 17 17:57:02 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 17 Aug 2015 14:57:02 -0700
Subject: [hibernate-dev] Naming strategies 4.3 -> 5.0
In-Reply-To: <CAFdSV9vwBLZJzW7m7rLkaxf7ycsAphX0uXKD_wZwY5rPXOqAbQ@mail.gmail.com>
References: <CAFdSV9vwBLZJzW7m7rLkaxf7ycsAphX0uXKD_wZwY5rPXOqAbQ@mail.gmail.com>
Message-ID: <CAFDzhiSnwFgS6S=HSBF4-9F8ZUV9xqPxqgF756y8+_0Ez7jn9g@mail.gmail.com>

See below...

On Sat, Aug 15, 2015 at 7:25 AM, Steve Ebersole <steve at hibernate.org> 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<Input> 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 mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Aug 18 02:59:28 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 18 Aug 2015 08:59:28 +0200
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
 new mapping annotations ?
In-Reply-To: <CAFm4XO3qGHaZde5+XBxp41P8dd_L4Wm32pYvOvxZRgfeJDikhQ@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
	<CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
	<CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>
	<CADGJaX9+wnnhLuLim8AY=qS2bvPq_5r=pr-h99Q2dXZDOTOeMw@mail.gmail.com>
	<CAFm4XO3bC-j7r1i3HMJ==T9NFr-oYweYOSxEn3nxtY8KQU6qHg@mail.gmail.com>
	<CAH8Ud1H9fwzV-E4V3SKc_HrKXiPwPA=LkMpeWdwG-NJjLqhRyg@mail.gmail.com>
	<CAFm4XO3qGHaZde5+XBxp41P8dd_L4Wm32pYvOvxZRgfeJDikhQ@mail.gmail.com>
Message-ID: <CADGJaX-6iv_7nKAs1WNANp-q+uC67U6+99VC5qLVTkYQX2i9Aw@mail.gmail.com>

2015-08-11 0:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

>> One possible workaround is to enforce the indexNullAs value to match the
>> underlying field type, at the
>> moment it is always a string.
>
> Interesting idea, but the user would need to provide which "value"
> he's ok to give up, as he would need to pick a number to be treated as
> NaN.
> Since the indexNullAs parameter requires a string, would we expect
> people to write a number in there?

+1 for that idea.

It'd work very well in the ES case where null tokens are also expected
to be of the correct type, e.g. the number -1 for a numeric field.
Also leaving ES aside, I find it troubling that setting indexNullAs()
transparently alters the type of a field of a numeric property from
IntField etc. to a string field.

>
>> Another possibility is to model "null" as field not present in the lucene
>> document, instead of a marker token.
>
> Thanks! I've run some tests with this and have a patch working based
> on this idea; I was sceptical initially because of scoring, but it
> seems it's doable without needing to score all documents on this
> negation. I'll send a PR soon; basically with this approach the
> indexNullAs attribute will be ignored, but it's ok I think as this
> solution is better and there's no drawback (nor needing any user
> configuration).

Isn't that what's happening already atm.? If a value is null (and
indexNullAs() is *not* given), it will not be part of the index as per
my observations. But if it is null and indexNullAs() is given, that
token will be used. That seems like the right thing to do IMO. Esp. I
would not ignore indexNullAs() if given, apparently the user meant to
encode null in that case e.g. to use it in queries.

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

From dreborier at gmail.com  Tue Aug 18 05:22:31 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 18 Aug 2015 10:22:31 +0100
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
Message-ID: <CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>

yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a look at
your poc.

Apart some problems to fully understand the semantic model (due to my lack
of a complete knowledge of the domain problem),
I agree with you about the simplicity and elegance of  the grammar for
HQL recognition
and semantic model building.

What I don't like it's the necessity to build our own semantic model
walker/s in order to produce the final SQL.









On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org> wrote:

> We've had a few discussions about this in the past.  As 5.0 is getting
> close to Final (next week), its time to start contemplating our next major
> tasks.  The consensus pick for that has been the idea of a "unified SQL
> generation engine" along with a shared project for the semantic analysis of
> HQL/JPQL (and recently it was decided to include JPA Criteria
> interpretation here as well).
>
> The central premise is this.  Take the roughly 6 or 7 different top-level
> ways Hibernate generates SQL and combine that into one "engine" based on
> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria shared
> project will be one producer of such semantic trees.  Others would include
> persisters (for insert/update/delete requests) and loaders (for load
> requests).
>
> We have a lot of tasks for this overall goal still remaining.
>
> We still have to finalize the design for the HQL/JPQL/Criteria to semantic
> tree translator.  One option is to proceed with the Antlr 4 based approach
> I started a PoC for.  John has been helping me some lately with that.  The
> first task here is to come to a consensus whether Antlr 4 is the way we
> want to proceed here.  We've been over the pros and cons before in detail.
> In summary, there is a lot to love with Antlr 4.  Our grammar for HQL
> recognition and semantic tree building is very simple and elegant imo.  The
> drawback is clearly the lack of tree walking, meaning that we are
> responsible for writing by hand our walker for the semantic tree.  In fact
> multiple, since each consumer (orm, ogm, search) would need to write their
> own.  And if we decide to build another AST while walking the semantic
> tree, we'd end up having to hand-write yet another walker for those.
>
> What I mean by that last part is that there are 2 ways we might choose to
> deal with the semantic tree.  For the purpose of discussion, let's look at
> the ORM case.  The first approach is to simply generate the SQL as we walk
> the semantic tree; this would be a 2 phase interpretation approach (input
> -> semantic tree -> SQL).  That works in many cases.  However it breaks
> down in other cases.  This is exactly the approach our existing HQL
> translator uses.  The other approach is to use a 3-phase translation (input
> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to one
> of the major problems.  One source "semantic" query will often correspond
> to multiple SQL queries; that is hard to manage in the 2-phase approach.
> And not to mention integrating things like follow-on fetches and other
> enhancements we want to gain from this.  My vote is definitely for 3 or
> more phases of interpretation.  The problem is that this is exactly where
> Antlr 4 sort of falls down.
>
> So first things first... we need to decide on Antlr 3 versus Antlr 4
> (versus some other parser solution).
>
> Next, on the ORM side (every "backend" can decide this individually) we
> need to decide on the approach for semantic-tree to SQL translation, which
> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>
> We really need to decide these things ASAP and get moving on them as soon
> as ORM 5.0 is finished.
>
> Also, this is a massive undertaking with huge gain potentials for not just
> ORM.  As such we need to understand who will be working on this.  Sanne,
> Gunnar... I know y'all have a vested interest and a desire to work on it.
> John, I know the same is true for you.  Andrea?  Have you had a chance to
> look over the poc and/or get more familiar with Antlr?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Tue Aug 18 08:33:35 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 18 Aug 2015 14:33:35 +0200
Subject: [hibernate-dev] [Hibernate Search] DocValues and Sorting API ->
 new mapping annotations ?
In-Reply-To: <CADGJaX-6iv_7nKAs1WNANp-q+uC67U6+99VC5qLVTkYQX2i9Aw@mail.gmail.com>
References: <CAFm4XO09pbLdY0aWnG9-E-3B77v+_WDrk47m0-1WzC4xB1rJ3g@mail.gmail.com>
	<CALt0+o8RAKmRoEC+w9h4J=2f3u0CQ4ediQmQ+fu27ztDLRKb5w@mail.gmail.com>
	<CAFm4XO0qfu7oh2D5HDdqYmVYdF5Z6N-Dvvse8OsQ2xUqVs-z5w@mail.gmail.com>
	<CADGJaX9+wnnhLuLim8AY=qS2bvPq_5r=pr-h99Q2dXZDOTOeMw@mail.gmail.com>
	<CAFm4XO3bC-j7r1i3HMJ==T9NFr-oYweYOSxEn3nxtY8KQU6qHg@mail.gmail.com>
	<CAH8Ud1H9fwzV-E4V3SKc_HrKXiPwPA=LkMpeWdwG-NJjLqhRyg@mail.gmail.com>
	<CAFm4XO3qGHaZde5+XBxp41P8dd_L4Wm32pYvOvxZRgfeJDikhQ@mail.gmail.com>
	<CADGJaX-6iv_7nKAs1WNANp-q+uC67U6+99VC5qLVTkYQX2i9Aw@mail.gmail.com>
Message-ID: <20150818123335.GA19190@Nineveh.lan>

On Tue, Aug 18, 2015 at 08:59:28AM +0200, Gunnar Morling wrote:
> >> One possible workaround is to enforce the indexNullAs value to match the
> >> underlying field type, at the
> >> moment it is always a string.
> >
> > Interesting idea, but the user would need to provide which "value"
> > he's ok to give up, as he would need to pick a number to be treated as
> > NaN.
> > Since the indexNullAs parameter requires a string, would we expect
> > people to write a number in there?
> 
> +1 for that idea.

+1 as well

> Isn't that what's happening already atm.? If a value is null (and
> indexNullAs() is *not* given), it will not be part of the index as per
> my observations. But if it is null and indexNullAs() is given, that
> token will be used. That seems like the right thing to do IMO. Esp. I
> would not ignore indexNullAs() if given, apparently the user meant to
> encode null in that case e.g. to use it in queries.

Right, that the intended behavior. If it behaves differently right now
a regression has sneaked in.

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

From smarlow at redhat.com  Tue Aug 18 09:29:48 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 18 Aug 2015 09:29:48 -0400
Subject: [hibernate-dev] Hibernate 2lc settings in WildFly
Message-ID: <55D3334C.9060100@redhat.com>

I didn't know about 'immutable-entity', should that be listed in [1] for 
the WildFly standalone*.xml, so users can configure 'immutable-entity'?

[2] describes the possible Infinispan subsystem settings for [1].

Scott

[1] 
https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/subsystem-templates/infinispan.xml#L39

[2] 
https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd

From steve at hibernate.org  Tue Aug 18 12:25:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 18 Aug 2015 16:25:52 +0000
Subject: [hibernate-dev] Triage
Message-ID: <CAFdSV9vomK1tiDu=PDWybK0zDNWija+cUSs3g=sh2mbYtEVTFA@mail.gmail.com>

Sorry, I am not going to be able to make the meeting. But you guys meet if
you want to. I will make next weeks meeting.

From sanne at hibernate.org  Tue Aug 18 13:10:14 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 18 Aug 2015 18:10:14 +0100
Subject: [hibernate-dev] Hibernate 2lc settings in WildFly
In-Reply-To: <55D3334C.9060100@redhat.com>
References: <55D3334C.9060100@redhat.com>
Message-ID: <CAFm4XO3JY=qdx4Y32V6VLMOsPu3M+YF9ezG=9aRkO-PdjTUu6Q@mail.gmail.com>

I think such options should not be an aspect of the Cache
configuration but only a property of the Hibernate configuration.

Why should that be known to the Infinispan configuration?


On 18 August 2015 at 14:29, Scott Marlow <smarlow at redhat.com> wrote:
> I didn't know about 'immutable-entity', should that be listed in [1] for
> the WildFly standalone*.xml, so users can configure 'immutable-entity'?
>
> [2] describes the possible Infinispan subsystem settings for [1].
>
> Scott
>
> [1]
> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/subsystem-templates/infinispan.xml#L39
>
> [2]
> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Tue Aug 18 13:44:21 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 18 Aug 2015 13:44:21 -0400
Subject: [hibernate-dev] Hibernate 2lc settings in WildFly
In-Reply-To: <CAFm4XO3JY=qdx4Y32V6VLMOsPu3M+YF9ezG=9aRkO-PdjTUu6Q@mail.gmail.com>
References: <55D3334C.9060100@redhat.com>
	<CAFm4XO3JY=qdx4Y32V6VLMOsPu3M+YF9ezG=9aRkO-PdjTUu6Q@mail.gmail.com>
Message-ID: <55D36EF5.1030201@redhat.com>


On 08/18/2015 01:10 PM, Sanne Grinovero wrote:
> I think such options should not be an aspect of the Cache
> configuration but only a property of the Hibernate configuration.

The time to do that would of been about four years ago (now we have to 
be configuration compatible on the WildFly side at least).  Still, not 
all applications include Hibernate configuration settings but they do 
expect to use a second level cache.

If we were to remove the Hibernate section from [1], where would that 
configuration live and what code would deal with that?

>
> Why should that be known to the Infinispan configuration?

In WildFly, that happens to be where we start/stop Infinispan caches, 
which makes sense since that is where we also deal with clustering.

>
>
> On 18 August 2015 at 14:29, Scott Marlow <smarlow at redhat.com> wrote:
>> I didn't know about 'immutable-entity', should that be listed in [1] for
>> the WildFly standalone*.xml, so users can configure 'immutable-entity'?
>>
>> [2] describes the possible Infinispan subsystem settings for [1].
>>
>> Scott
>>
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/subsystem-templates/infinispan.xml#L39
>>
>> [2]
>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Tue Aug 18 14:25:45 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 18 Aug 2015 11:25:45 -0700
Subject: [hibernate-dev] Compile error in hibernate-infinispan
Message-ID: <CAFDzhiS8SV7=rHkv0ZXpN77LThs8CVKNribU_garUJUhBMCgvw@mail.gmail.com>

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: <anonymous org.hibernate.cache.infinispan.util.Caches$2$1> is not
abstract and does not override abstract method remove() in Iterator
                                return new CloseableIterator() {
                                                               ^

From sanne at hibernate.org  Tue Aug 18 15:23:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 18 Aug 2015 20:23:01 +0100
Subject: [hibernate-dev] OGM build job failed: javac bug!
Message-ID: <CAFm4XO0t3EkM9Zd-AKhwvwGpjS6eHwHiBJB3ZPNfFzBpag30AQ@mail.gmail.com>

I only noticed today that this job is failing:
 - http://ci.hibernate.org/job/hibernate-ogm-release/64/console

and so did the previous one (build 63).

The highlight in the logs seems to be

"An exception has occurred in the compiler (1.8.0_45). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you."
[followed by stacktraces]

Did someone already check that
 a) it didn't hose the release
 b) if there are duplicates, or we need reporting?

Thanks,
Sanne

From gunnar at hibernate.org  Wed Aug 19 01:55:44 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 19 Aug 2015 07:55:44 +0200
Subject: [hibernate-dev] OGM build job failed: javac bug!
In-Reply-To: <CAFm4XO0t3EkM9Zd-AKhwvwGpjS6eHwHiBJB3ZPNfFzBpag30AQ@mail.gmail.com>
References: <CAFm4XO0t3EkM9Zd-AKhwvwGpjS6eHwHiBJB3ZPNfFzBpag30AQ@mail.gmail.com>
Message-ID: <CADGJaX-j67tSHX3tWua0=+9SEnN+KxBshxvgp2Z33Sot6vk-aw@mail.gmail.com>

I will take a look. I remember seeing the specific bug before, maybe
it's gone already in the latest 1.8 release.

2015-08-18 21:23 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> I only noticed today that this job is failing:
>  - http://ci.hibernate.org/job/hibernate-ogm-release/64/console
>
> and so did the previous one (build 63).
>
> The highlight in the logs seems to be
>
> "An exception has occurred in the compiler (1.8.0_45). Please file a
> bug at the Java Developer Connection
> (http://java.sun.com/webapps/bugreport) after checking the Bug Parade
> for duplicates. Include your program and the following diagnostic in
> your report. Thank you."
> [followed by stacktraces]
>
> Did someone already check that
>  a) it didn't hose the release
>  b) if there are duplicates, or we need reporting?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Aug 19 03:15:48 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 19 Aug 2015 09:15:48 +0200
Subject: [hibernate-dev] OGM build job failed: javac bug!
In-Reply-To: <CADGJaX-j67tSHX3tWua0=+9SEnN+KxBshxvgp2Z33Sot6vk-aw@mail.gmail.com>
References: <CAFm4XO0t3EkM9Zd-AKhwvwGpjS6eHwHiBJB3ZPNfFzBpag30AQ@mail.gmail.com>
	<CADGJaX-j67tSHX3tWua0=+9SEnN+KxBshxvgp2Z33Sot6vk-aw@mail.gmail.com>
Message-ID: <CADGJaX98Zs9-s0PkhRiFy-h+9bf27fVX0u3dy_ZbZs-omZroTg@mail.gmail.com>

Ok, seems we are hitting a known issue in the Maven compiler plug-in
[1], where incremental compilation causes this error in the "deploy"
phase. I've worked around this by disabling Maven's incremental
compilation feature.

But I am now running into an issue during the upload to SourceForge:
"Host key verification failed". Has our public key changed? Or may
this still be an aftermath of the recent SF apocalypse?

Has anyone uploaded stuff to SF recently via sftp/scp successfully?

Thanks,

--Gunnar

[1] https://issues.apache.org/jira/browse/MCOMPILER-236



2015-08-19 7:55 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> I will take a look. I remember seeing the specific bug before, maybe
> it's gone already in the latest 1.8 release.
>
> 2015-08-18 21:23 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> I only noticed today that this job is failing:
>>  - http://ci.hibernate.org/job/hibernate-ogm-release/64/console
>>
>> and so did the previous one (build 63).
>>
>> The highlight in the logs seems to be
>>
>> "An exception has occurred in the compiler (1.8.0_45). Please file a
>> bug at the Java Developer Connection
>> (http://java.sun.com/webapps/bugreport) after checking the Bug Parade
>> for duplicates. Include your program and the following diagnostic in
>> your report. Thank you."
>> [followed by stacktraces]
>>
>> Did someone already check that
>>  a) it didn't hose the release
>>  b) if there are duplicates, or we need reporting?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From rvansa at redhat.com  Wed Aug 19 06:02:48 2015
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 19 Aug 2015 12:02:48 +0200
Subject: [hibernate-dev] Hibernate 2lc settings in WildFly
In-Reply-To: <55D36EF5.1030201@redhat.com>
References: <55D3334C.9060100@redhat.com>	<CAFm4XO3JY=qdx4Y32V6VLMOsPu3M+YF9ezG=9aRkO-PdjTUu6Q@mail.gmail.com>
	<55D36EF5.1030201@redhat.com>
Message-ID: <55D45448.4000001@redhat.com>

I think that it was my mistake to not make this 'immutable-entities' get 
its configuration from 'entities', when it's not declared explicitly. I 
believe that adding that cache configuration to WF configs is the 
easiest way to fix things; though, if users use their own configs, they 
won't be notified that something is missing in their standalone.xml - 
the same problem as with overridden infinispan configuration, though 
this shouldn't be that common and users should pay more attention if 
they do that.

AFAIK, there is no place but the default infinispan config where it is 
documented which caches need to be defined and what kind of config do 
they need. There is also no validation in the code. The defaults are 
just in the default config, not in the code, and therefore user can 
override all or nothing. Users can even think that all entities are 
stored in single cache (while each entity type has its own) .

I don't think that serializing Infinispan configuration into properties 
is the best way.

I plan to add some configuration sanity checks as part of HHH-10030, but 
I have not thought about any systematic approach, so I'd welcome any 
discussion.

Radim

On 08/18/2015 07:44 PM, Scott Marlow wrote:
> On 08/18/2015 01:10 PM, Sanne Grinovero wrote:
>> I think such options should not be an aspect of the Cache
>> configuration but only a property of the Hibernate configuration.
> The time to do that would of been about four years ago (now we have to
> be configuration compatible on the WildFly side at least).  Still, not
> all applications include Hibernate configuration settings but they do
> expect to use a second level cache.
>
> If we were to remove the Hibernate section from [1], where would that
> configuration live and what code would deal with that?
>
>> Why should that be known to the Infinispan configuration?
> In WildFly, that happens to be where we start/stop Infinispan caches,
> which makes sense since that is where we also deal with clustering.
>
>>
>> On 18 August 2015 at 14:29, Scott Marlow <smarlow at redhat.com> wrote:
>>> I didn't know about 'immutable-entity', should that be listed in [1] for
>>> the WildFly standalone*.xml, so users can configure 'immutable-entity'?
>>>
>>> [2] describes the possible Infinispan subsystem settings for [1].
>>>
>>> Scott
>>>
>>> [1]
>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/subsystem-templates/infinispan.xml#L39
>>>
>>> [2]
>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


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


From sanne at hibernate.org  Wed Aug 19 06:06:55 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 19 Aug 2015 11:06:55 +0100
Subject: [hibernate-dev] OGM build job failed: javac bug!
In-Reply-To: <CADGJaX98Zs9-s0PkhRiFy-h+9bf27fVX0u3dy_ZbZs-omZroTg@mail.gmail.com>
References: <CAFm4XO0t3EkM9Zd-AKhwvwGpjS6eHwHiBJB3ZPNfFzBpag30AQ@mail.gmail.com>
	<CADGJaX-j67tSHX3tWua0=+9SEnN+KxBshxvgp2Z33Sot6vk-aw@mail.gmail.com>
	<CADGJaX98Zs9-s0PkhRiFy-h+9bf27fVX0u3dy_ZbZs-omZroTg@mail.gmail.com>
Message-ID: <CAFm4XO1983q=xssgMrW+qo=K11DD=PO4pWgzveK9Kb2g=34OeA@mail.gmail.com>

On 19 August 2015 at 08:15, Gunnar Morling <gunnar at hibernate.org> wrote:
> Ok, seems we are hitting a known issue in the Maven compiler plug-in
> [1], where incremental compilation causes this error in the "deploy"
> phase. I've worked around this by disabling Maven's incremental
> compilation feature.
>
> But I am now running into an issue during the upload to SourceForge:
> "Host key verification failed". Has our public key changed? Or may
> this still be an aftermath of the recent SF apocalypse?

N.B. that error message doesn't mean that your private key is not
being accepted, it means that your side (the client) refused to talk
with the server as the server has a new signature, which needs us to
verify we want to go ahead (i.e. it's a safety feature at our side to
abort).

To avoid a man-in-the-middle attack in this case you should verify
that the new public key of SF is matching the one our client is
seeing; then you can delete the old one from our server and have it
accept the new key.

How is this key being managed now?
We could do the same I did for github:
 - https://github.com/hibernate/ci.hibernate.org/commit/5346bcd060fd3faa3e44b7120d6423fee9e4c26a#diff-19ba7b72f8e35d36fe169a8c44861214

Sanne

>
> Has anyone uploaded stuff to SF recently via sftp/scp successfully?
>
> Thanks,
>
> --Gunnar
>
> [1] https://issues.apache.org/jira/browse/MCOMPILER-236
>
>
>
> 2015-08-19 7:55 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>> I will take a look. I remember seeing the specific bug before, maybe
>> it's gone already in the latest 1.8 release.
>>
>> 2015-08-18 21:23 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>> I only noticed today that this job is failing:
>>>  - http://ci.hibernate.org/job/hibernate-ogm-release/64/console
>>>
>>> and so did the previous one (build 63).
>>>
>>> The highlight in the logs seems to be
>>>
>>> "An exception has occurred in the compiler (1.8.0_45). Please file a
>>> bug at the Java Developer Connection
>>> (http://java.sun.com/webapps/bugreport) after checking the Bug Parade
>>> for duplicates. Include your program and the following diagnostic in
>>> your report. Thank you."
>>> [followed by stacktraces]
>>>
>>> Did someone already check that
>>>  a) it didn't hose the release
>>>  b) if there are duplicates, or we need reporting?
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Aug 19 08:27:59 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 19 Aug 2015 13:27:59 +0100
Subject: [hibernate-dev] Compile error in hibernate-infinispan
In-Reply-To: <CAFDzhiS8SV7=rHkv0ZXpN77LThs8CVKNribU_garUJUhBMCgvw@mail.gmail.com>
References: <CAFDzhiS8SV7=rHkv0ZXpN77LThs8CVKNribU_garUJUhBMCgvw@mail.gmail.com>
Message-ID: <CAFm4XO1m1VGRPC7o7NvMOap=f4_6bLHenLcRn9cbt6dBXVp-2Q@mail.gmail.com>

Hi Gail,
I tried to build it as well but I couldn't reproduce the problem; how
are you building it to trigger the error? Could you confirm which
commit id you were building?

While I don't have compile issues, I do however see some test failures
after your last commit, and CI seems to agree:
 - http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2/1069/

Thanks,
Sanne

On 18 August 2015 at 19:25, Gail Badner <gbadner at redhat.com> wrote:
> 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: <anonymous org.hibernate.cache.infinispan.util.Caches$2$1> is not
> abstract and does not override abstract method remove() in Iterator
>                                 return new CloseableIterator() {
>                                                                ^
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From msimka at redhat.com  Wed Aug 19 09:47:02 2015
From: msimka at redhat.com (Martin Simka)
Date: Wed, 19 Aug 2015 09:47:02 -0400 (EDT)
Subject: [hibernate-dev] Missing transaction hangs the testsuite
In-Reply-To: <CAFdSV9sPyAei_isU3sZDaCJscxapMmSxgDcG_dKTjWJNRh0pMg@mail.gmail.com>
References: <CAFm4XO2OP+UidZYS8og8Pc3ku-GPCeMi0yt4V1wGAFvRbT7yTQ@mail.gmail.com>
	<CAFdSV9spvj5hf1WjVgsjZDJDWkYU30McA5TdsqpkBygdpdZ5PA@mail.gmail.com>
	<CAFm4XO0Wb=cx0Od884aYR7cM_uFSSCMUFdXpLyeASnDriy=_Lw@mail.gmail.com>
	<CAFdSV9vBu+xr=JJ+pbyjx+hfy4nyiE6p5sv6tEmmNZN7qa0w2A@mail.gmail.com>
	<CAFm4XO0Zw=cXMk30XBERmKLpx3GzrReVrpVH4-BkQBnQ3SmDxg@mail.gmail.com>
	<CAFdSV9sBrFeRncS-uokLW+_7eNmymRMNpJs-jLVh4vKkevhWDg@mail.gmail.com>
	<CAFdSV9vp0u6SB1t7K2GB-Du4=Z-SkO0Z4LmYcsOT-vJ-3J3a9w@mail.gmail.com>
	<CAFdSV9sPyAei_isU3sZDaCJscxapMmSxgDcG_dKTjWJNRh0pMg@mail.gmail.com>
Message-ID: <1998913286.11341979.1439992022266.JavaMail.zimbra@redhat.com>

I'm now trying to run database testsuite against various databases. So far I've been successful with hibernate-core and hibernate-entitymanager tests on MariaDB and PostgreSQL (I had to add transaction to few test cases). But I can't run hibernate-envers tests on MariaDB because a lot of tests hang when dropping tables after the test is complete. Tests don't hang when I enable hibernate.connection.autocommit=true in hibernate.properties. 

Is it good idea to enable autocommit in envers tests? 

Thanks, 
Martin


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

From dreborier at gmail.com  Wed Aug 19 10:04:35 2015
From: dreborier at gmail.com (andrea boriero)
Date: Wed, 19 Aug 2015 15:04:35 +0100
Subject: [hibernate-dev] Compile error in hibernate-infinispan
In-Reply-To: <CAFm4XO1m1VGRPC7o7NvMOap=f4_6bLHenLcRn9cbt6dBXVp-2Q@mail.gmail.com>
References: <CAFDzhiS8SV7=rHkv0ZXpN77LThs8CVKNribU_garUJUhBMCgvw@mail.gmail.com>
	<CAFm4XO1m1VGRPC7o7NvMOap=f4_6bLHenLcRn9cbt6dBXVp-2Q@mail.gmail.com>
Message-ID: <CAL00eSQ813AOAJSNS=793sG3Pp3tWwuN9rFFoGz+dBuzzOhrpw@mail.gmail.com>

I noticed the problem only when i run the build with  AVA6_HOME set

On 19 August 2015 at 13:27, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Gail,
> I tried to build it as well but I couldn't reproduce the problem; how
> are you building it to trigger the error? Could you confirm which
> commit id you were building?
>
> While I don't have compile issues, I do however see some test failures
> after your last commit, and CI seems to agree:
>  - http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2/1069/
>
> Thanks,
> Sanne
>
> On 18 August 2015 at 19:25, Gail Badner <gbadner at redhat.com> wrote:
> > 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: <anonymous org.hibernate.cache.infinispan.util.Caches$2$1> is not
> > abstract and does not override abstract method remove() in Iterator
> >                                 return new CloseableIterator() {
> >                                                                ^
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Aug 19 10:18:34 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 19 Aug 2015 15:18:34 +0100
Subject: [hibernate-dev] Compile error in hibernate-infinispan
In-Reply-To: <CAL00eSQ813AOAJSNS=793sG3Pp3tWwuN9rFFoGz+dBuzzOhrpw@mail.gmail.com>
References: <CAFDzhiS8SV7=rHkv0ZXpN77LThs8CVKNribU_garUJUhBMCgvw@mail.gmail.com>
	<CAFm4XO1m1VGRPC7o7NvMOap=f4_6bLHenLcRn9cbt6dBXVp-2Q@mail.gmail.com>
	<CAL00eSQ813AOAJSNS=793sG3Pp3tWwuN9rFFoGz+dBuzzOhrpw@mail.gmail.com>
Message-ID: <CAFm4XO2rXzs6Uuj-=0mXWF4FMrPnMap8jLG868g2zPYC01SeJA@mail.gmail.com>

On 19 August 2015 at 15:04, andrea boriero <dreborier at gmail.com> wrote:
> I noticed the problem only when i run the build with  AVA6_HOME set

Ah, great that might explain it!
CI isn't setting that (and I'm also not setting that locally).
Still, the hibernate-infinispan module is not compatible with Java6,
so could you patch the build to not apply that for this module?

Thanks,
Sanne

>
> On 19 August 2015 at 13:27, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Gail,
>> I tried to build it as well but I couldn't reproduce the problem; how
>> are you building it to trigger the error? Could you confirm which
>> commit id you were building?
>>
>> While I don't have compile issues, I do however see some test failures
>> after your last commit, and CI seems to agree:
>>  - http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2/1069/
>>
>> Thanks,
>> Sanne
>>
>> On 18 August 2015 at 19:25, Gail Badner <gbadner at redhat.com> wrote:
>> > 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: <anonymous org.hibernate.cache.infinispan.util.Caches$2$1> is not
>> > abstract and does not override abstract method remove() in Iterator
>> >                                 return new CloseableIterator() {
>> >                                                                ^
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Wed Aug 19 10:36:25 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 19 Aug 2015 14:36:25 +0000
Subject: [hibernate-dev] Compile error in hibernate-infinispan
In-Reply-To: <CAFm4XO2rXzs6Uuj-=0mXWF4FMrPnMap8jLG868g2zPYC01SeJA@mail.gmail.com>
References: <CAFDzhiS8SV7=rHkv0ZXpN77LThs8CVKNribU_garUJUhBMCgvw@mail.gmail.com>
	<CAFm4XO1m1VGRPC7o7NvMOap=f4_6bLHenLcRn9cbt6dBXVp-2Q@mail.gmail.com>
	<CAL00eSQ813AOAJSNS=793sG3Pp3tWwuN9rFFoGz+dBuzzOhrpw@mail.gmail.com>
	<CAFm4XO2rXzs6Uuj-=0mXWF4FMrPnMap8jLG868g2zPYC01SeJA@mail.gmail.com>
Message-ID: <CAFdSV9sgiwtUZwwwwHEE=kmRjOotH8poGo8OmK1=O9wn=5pVOA@mail.gmail.com>

I few things...

1) Remember that JAVA6_HOME really needs to point to a JDK 7 HOME.
2) We had a discussion on IRC wrt Infinispan 7 versus 8.  Infinispan 7 is
supposed to require at least Java 7; Infinispan 8 requires at least Java 8
3) hibernate-infinispan pulls in Infinispan 7 (yes, there is a CI job that
tests against Infinispan 8)

So all things told, assuming Java 7 is really used, I am not understanding
why hibernate-infinispan would not compile.  Unless hibernate-infinispan is
using some Java 7 specific API, but then why would AnimalSniffer not
complain?


On Wed, Aug 19, 2015 at 9:21 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 19 August 2015 at 15:04, andrea boriero <dreborier at gmail.com> wrote:
> > I noticed the problem only when i run the build with  AVA6_HOME set
>
> Ah, great that might explain it!
> CI isn't setting that (and I'm also not setting that locally).
> Still, the hibernate-infinispan module is not compatible with Java6,
> so could you patch the build to not apply that for this module?
>
> Thanks,
> Sanne
>
> >
> > On 19 August 2015 at 13:27, Sanne Grinovero <sanne at hibernate.org> wrote:
> >>
> >> Hi Gail,
> >> I tried to build it as well but I couldn't reproduce the problem; how
> >> are you building it to trigger the error? Could you confirm which
> >> commit id you were building?
> >>
> >> While I don't have compile issues, I do however see some test failures
> >> after your last commit, and CI seems to agree:
> >>  - http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2/1069/
> >>
> >> Thanks,
> >> Sanne
> >>
> >> On 18 August 2015 at 19:25, Gail Badner <gbadner at redhat.com> wrote:
> >> > 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: <anonymous org.hibernate.cache.infinispan.util.Caches$2$1> is
> not
> >> > abstract and does not override abstract method remove() in Iterator
> >> >                                 return new CloseableIterator() {
> >> >                                                                ^
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Aug 19 12:09:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 19 Aug 2015 16:09:44 +0000
Subject: [hibernate-dev] Naming strategies 4.3 -> 5.0
In-Reply-To: <CAFDzhiSnwFgS6S=HSBF4-9F8ZUV9xqPxqgF756y8+_0Ez7jn9g@mail.gmail.com>
References: <CAFdSV9vwBLZJzW7m7rLkaxf7ycsAphX0uXKD_wZwY5rPXOqAbQ@mail.gmail.com>
	<CAFDzhiSnwFgS6S=HSBF4-9F8ZUV9xqPxqgF756y8+_0Ez7jn9g@mail.gmail.com>
Message-ID: <CAFdSV9ssrEdPpz9y-QRJFmkgqv0sF_bjRgVTQqE_0fS_1ze0DQ@mail.gmail.com>

Yes, I am talking about the "collection table" name.  That is why I
mentioned @JoinTable.

Again, we correctly produce the  JPA-compliant name, as I said.  The issue
is that we do not seem to produce the correct (what I expected) legacy name.

In trying to verify what that legacy name should be.  Reading through the
delegation and delegators etc did not help me.  And even the doc did not
answer my question.  For the doc, from a user's perspective, I believe we
have 2 questions to answer:

1) How do I achieve JPA compatible implicit naming?
2) How do I achieve backwards-compatible naming (relative to Hibernate's
previous default behavior)?

I will make sure the new documentation covers those topics.

Anyway, I added a test that verifies the multitude of ways users might
specify a naming
strategy: org.hibernate.test.namingstrategy.collectionJoinTableNaming.CollectionJoinTableNamingTest.
I put this on 4.3 and master.

In my opinion I missed how @ManyToMany implicit table naming used to work.
I will correct that for today's Final.  It means a minor change to
the org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl
strategy.

On Mon, Aug 17, 2015 at 4:57 PM Gail Badner <gbadner at redhat.com> wrote:

> See below...
>
> On Sat, Aug 15, 2015 at 7:25 AM, Steve Ebersole <steve at hibernate.org>
> 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<Input> 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 mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Wed Aug 19 13:27:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 19 Aug 2015 17:27:16 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
Message-ID: <CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>

I agree.  Its my biggest hang up with regard to using Antlr 4.  Actually,
its my only hang up with Antlr 4, but its a huge one.

On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <dreborier at gmail.com> wrote:

> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a look at
> your poc.
>
> Apart some problems to fully understand the semantic model (due to my lack
> of a complete knowledge of the domain problem),
> I agree with you about the simplicity and elegance of  the grammar for
> HQL recognition and semantic model building.
>
> What I don't like it's the necessity to build our own semantic model
> walker/s in order to produce the final SQL.
>
>
>
>
>
>
>
>
>
> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org> wrote:
>
>> We've had a few discussions about this in the past.  As 5.0 is getting
>> close to Final (next week), its time to start contemplating our next major
>> tasks.  The consensus pick for that has been the idea of a "unified SQL
>> generation engine" along with a shared project for the semantic analysis
>> of
>> HQL/JPQL (and recently it was decided to include JPA Criteria
>> interpretation here as well).
>>
>> The central premise is this.  Take the roughly 6 or 7 different top-level
>> ways Hibernate generates SQL and combine that into one "engine" based on
>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria shared
>> project will be one producer of such semantic trees.  Others would include
>> persisters (for insert/update/delete requests) and loaders (for load
>> requests).
>>
>> We have a lot of tasks for this overall goal still remaining.
>>
>> We still have to finalize the design for the HQL/JPQL/Criteria to semantic
>> tree translator.  One option is to proceed with the Antlr 4 based approach
>> I started a PoC for.  John has been helping me some lately with that.  The
>> first task here is to come to a consensus whether Antlr 4 is the way we
>> want to proceed here.  We've been over the pros and cons before in detail.
>> In summary, there is a lot to love with Antlr 4.  Our grammar for HQL
>> recognition and semantic tree building is very simple and elegant imo.
>> The
>> drawback is clearly the lack of tree walking, meaning that we are
>> responsible for writing by hand our walker for the semantic tree.  In fact
>> multiple, since each consumer (orm, ogm, search) would need to write their
>> own.  And if we decide to build another AST while walking the semantic
>> tree, we'd end up having to hand-write yet another walker for those.
>>
>> What I mean by that last part is that there are 2 ways we might choose to
>> deal with the semantic tree.  For the purpose of discussion, let's look at
>> the ORM case.  The first approach is to simply generate the SQL as we walk
>> the semantic tree; this would be a 2 phase interpretation approach (input
>> -> semantic tree -> SQL).  That works in many cases.  However it breaks
>> down in other cases.  This is exactly the approach our existing HQL
>> translator uses.  The other approach is to use a 3-phase translation
>> (input
>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to
>> one
>> of the major problems.  One source "semantic" query will often correspond
>> to multiple SQL queries; that is hard to manage in the 2-phase approach.
>> And not to mention integrating things like follow-on fetches and other
>> enhancements we want to gain from this.  My vote is definitely for 3 or
>> more phases of interpretation.  The problem is that this is exactly where
>> Antlr 4 sort of falls down.
>>
>> So first things first... we need to decide on Antlr 3 versus Antlr 4
>> (versus some other parser solution).
>>
>> Next, on the ORM side (every "backend" can decide this individually) we
>> need to decide on the approach for semantic-tree to SQL translation, which
>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>>
>> We really need to decide these things ASAP and get moving on them as soon
>> as ORM 5.0 is finished.
>>
>> Also, this is a massive undertaking with huge gain potentials for not just
>> ORM.  As such we need to understand who will be working on this.  Sanne,
>> Gunnar... I know y'all have a vested interest and a desire to work on it.
>> John, I know the same is true for you.  Andrea?  Have you had a chance to
>> look over the poc and/or get more familiar with Antlr?
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Wed Aug 19 13:27:34 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 19 Aug 2015 17:27:34 +0000
Subject: [hibernate-dev] Compile error in hibernate-infinispan
In-Reply-To: <CAFdSV9sgiwtUZwwwwHEE=kmRjOotH8poGo8OmK1=O9wn=5pVOA@mail.gmail.com>
References: <CAFDzhiS8SV7=rHkv0ZXpN77LThs8CVKNribU_garUJUhBMCgvw@mail.gmail.com>
	<CAFm4XO1m1VGRPC7o7NvMOap=f4_6bLHenLcRn9cbt6dBXVp-2Q@mail.gmail.com>
	<CAL00eSQ813AOAJSNS=793sG3Pp3tWwuN9rFFoGz+dBuzzOhrpw@mail.gmail.com>
	<CAFm4XO2rXzs6Uuj-=0mXWF4FMrPnMap8jLG868g2zPYC01SeJA@mail.gmail.com>
	<CAFdSV9sgiwtUZwwwwHEE=kmRjOotH8poGo8OmK1=O9wn=5pVOA@mail.gmail.com>
Message-ID: <CAFdSV9vOB1Nwdb2XoV9CvRtg+imBG+VnMU_4EUWGbPg=2XxGeQ@mail.gmail.com>

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


On Wed, Aug 19, 2015 at 9:36 AM Steve Ebersole <steve at hibernate.org> wrote:

> I few things...
>
> 1) Remember that JAVA6_HOME really needs to point to a JDK 7 HOME.
> 2) We had a discussion on IRC wrt Infinispan 7 versus 8.  Infinispan 7 is
> supposed to require at least Java 7; Infinispan 8 requires at least Java 8
> 3) hibernate-infinispan pulls in Infinispan 7 (yes, there is a CI job that
> tests against Infinispan 8)
>
> So all things told, assuming Java 7 is really used, I am not understanding
> why hibernate-infinispan would not compile.  Unless hibernate-infinispan is
> using some Java 7 specific API, but then why would AnimalSniffer not
> complain?
>
>
> On Wed, Aug 19, 2015 at 9:21 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 19 August 2015 at 15:04, andrea boriero <dreborier at gmail.com> wrote:
>> > I noticed the problem only when i run the build with  AVA6_HOME set
>>
>> Ah, great that might explain it!
>> CI isn't setting that (and I'm also not setting that locally).
>> Still, the hibernate-infinispan module is not compatible with Java6,
>> so could you patch the build to not apply that for this module?
>>
>> Thanks,
>> Sanne
>>
>> >
>> > On 19 August 2015 at 13:27, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> >>
>> >> Hi Gail,
>> >> I tried to build it as well but I couldn't reproduce the problem; how
>> >> are you building it to trigger the error? Could you confirm which
>> >> commit id you were building?
>> >>
>> >> While I don't have compile issues, I do however see some test failures
>> >> after your last commit, and CI seems to agree:
>> >>  - http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2/1069/
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >> On 18 August 2015 at 19:25, Gail Badner <gbadner at redhat.com> wrote:
>> >> > 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: <anonymous org.hibernate.cache.infinispan.util.Caches$2$1> is
>> not
>> >> > abstract and does not override abstract method remove() in Iterator
>> >> >                                 return new CloseableIterator() {
>> >> >                                                                ^
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Aug 19 13:28:43 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 19 Aug 2015 17:28:43 +0000
Subject: [hibernate-dev] Compile error in hibernate-infinispan
In-Reply-To: <CAFdSV9vOB1Nwdb2XoV9CvRtg+imBG+VnMU_4EUWGbPg=2XxGeQ@mail.gmail.com>
References: <CAFDzhiS8SV7=rHkv0ZXpN77LThs8CVKNribU_garUJUhBMCgvw@mail.gmail.com>
	<CAFm4XO1m1VGRPC7o7NvMOap=f4_6bLHenLcRn9cbt6dBXVp-2Q@mail.gmail.com>
	<CAL00eSQ813AOAJSNS=793sG3Pp3tWwuN9rFFoGz+dBuzzOhrpw@mail.gmail.com>
	<CAFm4XO2rXzs6Uuj-=0mXWF4FMrPnMap8jLG868g2zPYC01SeJA@mail.gmail.com>
	<CAFdSV9sgiwtUZwwwwHEE=kmRjOotH8poGo8OmK1=O9wn=5pVOA@mail.gmail.com>
	<CAFdSV9vOB1Nwdb2XoV9CvRtg+imBG+VnMU_4EUWGbPg=2XxGeQ@mail.gmail.com>
Message-ID: <CAFdSV9tpmd7zmF6bDPjbecHJPs34g=LOZFHwtSWOU6CM7vOx4A@mail.gmail.com>

So the problem was that ultimately, compiled with Java 8, javac picks up
the default remove() impl from Iterator.  Pre-Java8 of course default
methods are not available.  I just added an impl of remove().

On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <steve at hibernate.org> wrote:

> https://hibernate.atlassian.net/browse/HHH-10040
>
>
> On Wed, Aug 19, 2015 at 9:36 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I few things...
>>
>> 1) Remember that JAVA6_HOME really needs to point to a JDK 7 HOME.
>> 2) We had a discussion on IRC wrt Infinispan 7 versus 8.  Infinispan 7 is
>> supposed to require at least Java 7; Infinispan 8 requires at least Java 8
>> 3) hibernate-infinispan pulls in Infinispan 7 (yes, there is a CI job
>> that tests against Infinispan 8)
>>
>> So all things told, assuming Java 7 is really used, I am not
>> understanding why hibernate-infinispan would not compile.  Unless
>> hibernate-infinispan is using some Java 7 specific API, but then why would
>> AnimalSniffer not complain?
>>
>>
>> On Wed, Aug 19, 2015 at 9:21 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> On 19 August 2015 at 15:04, andrea boriero <dreborier at gmail.com> wrote:
>>> > I noticed the problem only when i run the build with  AVA6_HOME set
>>>
>>> Ah, great that might explain it!
>>> CI isn't setting that (and I'm also not setting that locally).
>>> Still, the hibernate-infinispan module is not compatible with Java6,
>>> so could you patch the build to not apply that for this module?
>>>
>>> Thanks,
>>> Sanne
>>>
>>> >
>>> > On 19 August 2015 at 13:27, Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>> >>
>>> >> Hi Gail,
>>> >> I tried to build it as well but I couldn't reproduce the problem; how
>>> >> are you building it to trigger the error? Could you confirm which
>>> >> commit id you were building?
>>> >>
>>> >> While I don't have compile issues, I do however see some test failures
>>> >> after your last commit, and CI seems to agree:
>>> >>  - http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2/1069/
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >>
>>> >> On 18 August 2015 at 19:25, Gail Badner <gbadner at redhat.com> wrote:
>>> >> > 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: <anonymous org.hibernate.cache.infinispan.util.Caches$2$1>
>>> is not
>>> >> > abstract and does not override abstract method remove() in Iterator
>>> >> >                                 return new CloseableIterator() {
>>> >> >                                                                ^
>>> >> > _______________________________________________
>>> >> > hibernate-dev mailing list
>>> >> > hibernate-dev at lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From steve at hibernate.org  Wed Aug 19 14:34:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 19 Aug 2015 18:34:14 +0000
Subject: [hibernate-dev] ORM 5.0 Final - delayed
Message-ID: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>

I am going to delay releasing 5.0 Final until tomorrow at earliest.  The CI
server is having some massive trouble at the moment and I'd prefer to make
sure that we are getting clean builds there before I start the release.

From smarlow at redhat.com  Wed Aug 19 16:00:51 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 19 Aug 2015 16:00:51 -0400
Subject: [hibernate-dev] Hibernate 2lc settings in WildFly
In-Reply-To: <55D45448.4000001@redhat.com>
References: <55D3334C.9060100@redhat.com>
	<CAFm4XO3JY=qdx4Y32V6VLMOsPu3M+YF9ezG=9aRkO-PdjTUu6Q@mail.gmail.com>
	<55D36EF5.1030201@redhat.com> <55D45448.4000001@redhat.com>
Message-ID: <55D4E073.5030305@redhat.com>

Thanks Radim, I created https://issues.jboss.org/browse/WFLY-5137 for 
adding 'immutable-entities' to the WildFly standalone*.xml.  I included 
a copy of the proposed change in the jira.

Scott

On 08/19/2015 06:02 AM, Radim Vansa wrote:
> I think that it was my mistake to not make this 'immutable-entities' get
> its configuration from 'entities', when it's not declared explicitly. I
> believe that adding that cache configuration to WF configs is the
> easiest way to fix things; though, if users use their own configs, they
> won't be notified that something is missing in their standalone.xml -
> the same problem as with overridden infinispan configuration, though
> this shouldn't be that common and users should pay more attention if
> they do that.
>
> AFAIK, there is no place but the default infinispan config where it is
> documented which caches need to be defined and what kind of config do
> they need. There is also no validation in the code. The defaults are
> just in the default config, not in the code, and therefore user can
> override all or nothing. Users can even think that all entities are
> stored in single cache (while each entity type has its own) .
>
> I don't think that serializing Infinispan configuration into properties
> is the best way.
>
> I plan to add some configuration sanity checks as part of HHH-10030, but
> I have not thought about any systematic approach, so I'd welcome any
> discussion.
>
> Radim
>
> On 08/18/2015 07:44 PM, Scott Marlow wrote:
>> On 08/18/2015 01:10 PM, Sanne Grinovero wrote:
>>> I think such options should not be an aspect of the Cache
>>> configuration but only a property of the Hibernate configuration.
>> The time to do that would of been about four years ago (now we have to
>> be configuration compatible on the WildFly side at least).  Still, not
>> all applications include Hibernate configuration settings but they do
>> expect to use a second level cache.
>>
>> If we were to remove the Hibernate section from [1], where would that
>> configuration live and what code would deal with that?
>>
>>> Why should that be known to the Infinispan configuration?
>> In WildFly, that happens to be where we start/stop Infinispan caches,
>> which makes sense since that is where we also deal with clustering.
>>
>>>
>>> On 18 August 2015 at 14:29, Scott Marlow <smarlow at redhat.com> wrote:
>>>> I didn't know about 'immutable-entity', should that be listed in [1] for
>>>> the WildFly standalone*.xml, so users can configure 'immutable-entity'?
>>>>
>>>> [2] describes the possible Infinispan subsystem settings for [1].
>>>>
>>>> Scott
>>>>
>>>> [1]
>>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/subsystem-templates/infinispan.xml#L39
>>>>
>>>> [2]
>>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From davide at hibernate.org  Wed Aug 19 18:35:46 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 19 Aug 2015 23:35:46 +0100
Subject: [hibernate-dev] CI Jobs and Byteman
Message-ID: <CANoTJYN7VMTt3iSo8=QgvBw+wodK1WQfpEqKMRt+5sU5c_-vBA@mail.gmail.com>

Hi all,
it seems that the Hibernate Search tests using Byteman are having some
conflicts with some ports used by the NoSql dbs we installed to test OGM.

For now I just set up the Search jobs  to work on ci-slave-4 where I have
stopped the dbs.

Tomorrow I will try to figure out the process that are causing the problem,
or I will script this solution.

Anyway, I'm open to suggestion.

Cheers,
Davide

From steve at hibernate.org  Wed Aug 19 18:52:32 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 19 Aug 2015 22:52:32 +0000
Subject: [hibernate-dev] Hibernate.org layouts
Message-ID: <CAFdSV9uKOmgxPW4vvFLwtqS2i5JctPPCkMDYqHit5CM_yup3BA@mail.gmail.com>

In regards to WEBSITE-382
<https://hibernate.atlassian.net/browse/WEBSITE-382>[1], I would love to
get the "list" of version family specific doc page links into the left nav
ideally as another section there.  Anyone able to give me some pointers how
to hook into the left-hand nav links are managed?

I see 'bothcol.html.haml' defines 'leftcol.html.haml' and
'rightcol.html.haml' are defined.  But I have no idea if that is the right
place.  I have never even seen a right-hand column in use in the website.
And I have not found any specific 'leftcol.html.haml' or
'rightcol.html.haml' files.

[1] https://hibernate.atlassian.net/browse/WEBSITE-382

From gunnar at hibernate.org  Thu Aug 20 02:48:36 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 20 Aug 2015 08:48:36 +0200
Subject: [hibernate-dev] CI Jobs and Byteman
In-Reply-To: <CANoTJYN7VMTt3iSo8=QgvBw+wodK1WQfpEqKMRt+5sU5c_-vBA@mail.gmail.com>
References: <CANoTJYN7VMTt3iSo8=QgvBw+wodK1WQfpEqKMRt+5sU5c_-vBA@mail.gmail.com>
Message-ID: <CADGJaX9dwP6O-QynUPkkPjVpiX0DS0ZB0uKr+74+SW9e+akMxQ@mail.gmail.com>

Wouldn't a better approach be to either a) run the NoSQL store in
question on another port or b) configure Byteman to use another port?

Limiting the number of nodes where certain jobs can run contradicts
our previous efforts for scaling out the CI environment and improve
build job turn around times.

2015-08-20 0:35 GMT+02:00 Davide D'Alto <davide at hibernate.org>:
> Hi all,
> it seems that the Hibernate Search tests using Byteman are having some
> conflicts with some ports used by the NoSql dbs we installed to test OGM.
>
> For now I just set up the Search jobs  to work on ci-slave-4 where I have
> stopped the dbs.
>
> Tomorrow I will try to figure out the process that are causing the problem,
> or I will script this solution.
>
> Anyway, I'm open to suggestion.
>
> Cheers,
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Thu Aug 20 04:26:32 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 20 Aug 2015 10:26:32 +0200
Subject: [hibernate-dev] CI Jobs and Byteman
In-Reply-To: <CADGJaX9dwP6O-QynUPkkPjVpiX0DS0ZB0uKr+74+SW9e+akMxQ@mail.gmail.com>
References: <CANoTJYN7VMTt3iSo8=QgvBw+wodK1WQfpEqKMRt+5sU5c_-vBA@mail.gmail.com>
	<CADGJaX9dwP6O-QynUPkkPjVpiX0DS0ZB0uKr+74+SW9e+akMxQ@mail.gmail.com>
Message-ID: <20150820082632.GC19723@Nineveh.lan>

On Thu, Aug 20, 2015 at 08:48:36AM +0200, Gunnar Morling wrote:
> Wouldn't a better approach be to either a) run the NoSQL store in
> question on another port or b) configure Byteman to use another port?

I guess both options work, but given that ports are anyways configurable in 
the OGM build, a) might be the easier option

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

From sanne at hibernate.org  Thu Aug 20 04:44:44 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 20 Aug 2015 09:44:44 +0100
Subject: [hibernate-dev] CI Jobs and Byteman
In-Reply-To: <20150820082632.GC19723@Nineveh.lan>
References: <CANoTJYN7VMTt3iSo8=QgvBw+wodK1WQfpEqKMRt+5sU5c_-vBA@mail.gmail.com>
	<CADGJaX9dwP6O-QynUPkkPjVpiX0DS0ZB0uKr+74+SW9e+akMxQ@mail.gmail.com>
	<20150820082632.GC19723@Nineveh.lan>
Message-ID: <CAFm4XO2YkLDSUs_oGc-8msJBgDdCP-G9N9D+Ct_K_YqR8W+=fg@mail.gmail.com>

+1 for a) as many jobs use Byteman, including ORM, and on many branches.


On 20 August 2015 at 09:26, Hardy Ferentschik <hardy at hibernate.org> wrote:
> On Thu, Aug 20, 2015 at 08:48:36AM +0200, Gunnar Morling wrote:
>> Wouldn't a better approach be to either a) run the NoSQL store in
>> question on another port or b) configure Byteman to use another port?
>
> I guess both options work, but given that ports are anyways configurable in
> the OGM build, a) might be the easier option
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Thu Aug 20 05:13:27 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 20 Aug 2015 11:13:27 +0200
Subject: [hibernate-dev] Hibernate.org layouts
In-Reply-To: <CAFdSV9uKOmgxPW4vvFLwtqS2i5JctPPCkMDYqHit5CM_yup3BA@mail.gmail.com>
References: <CAFdSV9uKOmgxPW4vvFLwtqS2i5JctPPCkMDYqHit5CM_yup3BA@mail.gmail.com>
Message-ID: <20150820091327.GD19723@Nineveh.lan>

Hi,

I am not a great expert on the templating side either, but I can tell you how it
is put together atm.

The left hand menu items for the different projects (About, Downloads, Documentation, etc)
are actually generated from the site config. 

If you look into _config/site.yml, you see that each project defines a menu section which
is in itself split between intern and extern. The menu items specified in site.yml are
then displayed depending on the chosen project.

The place where this is happening is _layouts/project/project-frame.html.haml:

{code}
      %ul.nav.nav-list
        -# removes index.html and then replace download.html to download/
        - current_path = page.output_path.sub(/index\.html$/, "").sub(/\.html$/,"/")
        - project_description.menu.intern.each do |menu|
          -# active if path is a subpath of the menu item. The project home has to be treated differently as every path is a subpath of home
          - active = (menu.href == "/#{page.project}/" && menu.href == current_path) || (menu.href != "/#{page.project}/" && current_path.start_with?(menu.href))
          %li{:class => "#{(active ? "active" : "")}"}
            %a{:href => "#{relative("#{menu.href}")}"}
              %i{:class => "#{menu.css_class} menu-icon"}
              #{menu.name}
        %li.divider
        - project_description.menu.extern.each do |menu|
          %li
            %a{:href => "#{menu.href}"}
              %i{:class => "#{menu.css_class} menu-icon"}
              #{menu.name}
{code}

project_description.menu.intern.each will iterate over the intern links for a given project whereas 
project_description.menu.extern.each iterates the external links.

So far so good. Depending on how dynamic you want all this to work you have multiple options.

1) Work with the current approach and just define your different documentation links. If you work
   with the current structure you would get multiple Downloads links pointing to the different 
   doc versions. This is the simplest approach and does not require any template change at all
2) Create a sub hash orm:menu:intern:documentation:versions (just extending the nested structure
   we already have. YAML will automatically create the nested hashes out of this.) In the template 
   you would then need to handle the ORM case a bit different (eg by checking whether the current
   project is ORM). This way I could envision a single Download link which would point to the 
   current docs together with a little expander icon next to it which when clicked makes the
   other documentation links visible by expanding some sort of div. I think this would be visually 
   much more appealing. Obviously you need to deal with template changes as well as HTML + CSS changes 
   for getting the drop out menu right.
3) In the template check whether your current items is the ORM Download and if so, do whatever you want.
   This bypasses site.yml completely.

Personally I think 1) is a great way to get started verify the new approach and its navigation. Once all is 
working as it should I would look into 2) since I think it would be visually much more appealing. Maybe
Davide could help with the CSS/HTML part. I am pretty bad with this.

Anyways, hope this points you into the right direction.

--Hardy
 




On Wed, Aug 19, 2015 at 10:52:32PM +0000, Steve Ebersole wrote:
> In regards to WEBSITE-382
> <https://hibernate.atlassian.net/browse/WEBSITE-382>[1], I would love to
> get the "list" of version family specific doc page links into the left nav
> ideally as another section there.  Anyone able to give me some pointers how
> to hook into the left-hand nav links are managed?
> 
> I see 'bothcol.html.haml' defines 'leftcol.html.haml' and
> 'rightcol.html.haml' are defined.  But I have no idea if that is the right
> place.  I have never even seen a right-hand column in use in the website.
> And I have not found any specific 'leftcol.html.haml' or
> 'rightcol.html.haml' files.
> 
> [1] https://hibernate.atlassian.net/browse/WEBSITE-382
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150820/25cdc9f8/attachment-0001.bin 

From hardy at hibernate.org  Thu Aug 20 09:07:01 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 20 Aug 2015 15:07:01 +0200
Subject: [hibernate-dev] hibernate.org Awestruct within Docker
Message-ID: <20150820130701.GE19723@Nineveh.lan>

Hi all,

I just pushed some changes to the hibernate.org site. The changes allow you to run
the hibernate.org Awestruct environment within a Docker container while still being able to
make changes locally. The obvious benefit is that in case of environmental problems
due to native extension compilation etc, only one needs to sort this out and all others
can then benefit by using an updated images. 

So how do you do that? Check out http://hibernate.org/docker/README/. It comes down to
- You need a running Docker daemon
- Build the Docker image
  $ docker build -t hibernate/hibernate.org .
- Run the image
  $ docker run -t -i -p 4242:4242 -v <path to root dir of hibernate.org checkout>:/home/dev/hibernate.org hibernate/hibernate.org

Anyways, really the online docs should tell you everything. If not let me know and we iron
things out there.

What does that mean for you who still wants to run this locally? Nothing really.
The local setup still works, BUT I had to make some changes to the build file
(gems are not anymore stored relative to the checkout). To make sure all keeps working,
after an update, I recommend to make sure to have a CLEAN checkout.
The best way to do this is via 'git clean -fxd' (thanks Sanne for this one). Just make
sure to have no uncommitted changes.

Let me know if you like it in which case we can do the same for in.relation.to.

Happy awestructing
--hardy

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

From smarlow at redhat.com  Thu Aug 20 10:33:09 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 20 Aug 2015 10:33:09 -0400
Subject: [hibernate-dev] ORM 5.0 Final - delayed
In-Reply-To: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>
References: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>
Message-ID: <55D5E525.1050809@redhat.com>

Please let me know if you want me to do any testing before the release.

On 08/19/2015 02:34 PM, Steve Ebersole wrote:
> I am going to delay releasing 5.0 Final until tomorrow at earliest.  The CI
> server is having some massive trouble at the moment and I'd prefer to make
> sure that we are getting clean builds there before I start the release.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Thu Aug 20 11:16:23 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 20 Aug 2015 16:16:23 +0100
Subject: [hibernate-dev] CI Jobs and Byteman
In-Reply-To: <CAFm4XO2YkLDSUs_oGc-8msJBgDdCP-G9N9D+Ct_K_YqR8W+=fg@mail.gmail.com>
References: <CANoTJYN7VMTt3iSo8=QgvBw+wodK1WQfpEqKMRt+5sU5c_-vBA@mail.gmail.com>
	<CADGJaX9dwP6O-QynUPkkPjVpiX0DS0ZB0uKr+74+SW9e+akMxQ@mail.gmail.com>
	<20150820082632.GC19723@Nineveh.lan>
	<CAFm4XO2YkLDSUs_oGc-8msJBgDdCP-G9N9D+Ct_K_YqR8W+=fg@mail.gmail.com>
Message-ID: <CANoTJYPiHAn94jZNm1wbW=-4x1QFcWJVpXJejjzE7+xZqmGwtA@mail.gmail.com>

I've reconfigured all the jobs to works the same as before.
I've tried to replicate the issue with Byteman but it seems everything is
working well now.

Sanne, am I missing something about the way to run the build with search?


On Thu, Aug 20, 2015 at 9:44 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> +1 for a) as many jobs use Byteman, including ORM, and on many branches.
>
>
> On 20 August 2015 at 09:26, Hardy Ferentschik <hardy at hibernate.org> wrote:
> > On Thu, Aug 20, 2015 at 08:48:36AM +0200, Gunnar Morling wrote:
> >> Wouldn't a better approach be to either a) run the NoSQL store in
> >> question on another port or b) configure Byteman to use another port?
> >
> > I guess both options work, but given that ports are anyways configurable
> in
> > the OGM build, a) might be the easier option
> >
> > --Hardy
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Aug 20 11:57:43 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 20 Aug 2015 15:57:43 +0000
Subject: [hibernate-dev] hibernate.org Awestruct within Docker
In-Reply-To: <20150820130701.GE19723@Nineveh.lan>
References: <20150820130701.GE19723@Nineveh.lan>
Message-ID: <CAFdSV9s09GrDhvsvQi3i4jPJ2fFTXZ0uDzM2rgH9_T6nN7jjHQ@mail.gmail.com>

Hardy, this is awesome!  Thanks for getting this pushed upstream.  I am
about to work with this upstream today :)



On Thu, Aug 20, 2015 at 8:08 AM Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi all,
>
> I just pushed some changes to the hibernate.org site. The changes allow
> you to run
> the hibernate.org Awestruct environment within a Docker container while
> still being able to
> make changes locally. The obvious benefit is that in case of environmental
> problems
> due to native extension compilation etc, only one needs to sort this out
> and all others
> can then benefit by using an updated images.
>
> So how do you do that? Check out http://hibernate.org/docker/README/. It
> comes down to
> - You need a running Docker daemon
> - Build the Docker image
>   $ docker build -t hibernate/hibernate.org .
> - Run the image
>   $ docker run -t -i -p 4242:4242 -v <path to root dir of hibernate.org
> checkout>:/home/dev/hibernate.org hibernate/hibernate.org
>
> Anyways, really the online docs should tell you everything. If not let me
> know and we iron
> things out there.
>
> What does that mean for you who still wants to run this locally? Nothing
> really.
> The local setup still works, BUT I had to make some changes to the build
> file
> (gems are not anymore stored relative to the checkout). To make sure all
> keeps working,
> after an update, I recommend to make sure to have a CLEAN checkout.
> The best way to do this is via 'git clean -fxd' (thanks Sanne for this
> one). Just make
> sure to have no uncommitted changes.
>
> Let me know if you like it in which case we can do the same for
> in.relation.to.
>
> Happy awestructing
> --hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Aug 20 15:39:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 20 Aug 2015 19:39:55 +0000
Subject: [hibernate-dev] ORM 5.0 Final - delayed
In-Reply-To: <55D5E525.1050809@redhat.com>
References: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>
	<55D5E525.1050809@redhat.com>
Message-ID: <CAFdSV9taFM0EX-6fMdJ4npYzdkWdP5QO4A4kZ2rdafF2fg659w@mail.gmail.com>

I am having some majorly slow (and dropping) connection issues today.
Trying to work through those and then I'll start on the release.


On Thu, Aug 20, 2015 at 9:33 AM Scott Marlow <smarlow at redhat.com> wrote:

> Please let me know if you want me to do any testing before the release.
>
> On 08/19/2015 02:34 PM, Steve Ebersole wrote:
> > I am going to delay releasing 5.0 Final until tomorrow at earliest.  The
> CI
> > server is having some massive trouble at the moment and I'd prefer to
> make
> > sure that we are getting clean builds there before I start the release.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From steve at hibernate.org  Thu Aug 20 16:44:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 20 Aug 2015 20:44:26 +0000
Subject: [hibernate-dev] hibernate.org Awestruct within Docker
In-Reply-To: <CAFdSV9s09GrDhvsvQi3i4jPJ2fFTXZ0uDzM2rgH9_T6nN7jjHQ@mail.gmail.com>
References: <20150820130701.GE19723@Nineveh.lan>
	<CAFdSV9s09GrDhvsvQi3i4jPJ2fFTXZ0uDzM2rgH9_T6nN7jjHQ@mail.gmail.com>
Message-ID: <CAFdSV9vz5Erm+maQkVYt1nNGvkaJ14YbFo399wZgOdZqd=n_3w@mail.gmail.com>

Worked great for me locally from upstream!


On Thu, Aug 20, 2015 at 10:57 AM Steve Ebersole <steve at hibernate.org> wrote:

> Hardy, this is awesome!  Thanks for getting this pushed upstream.  I am
> about to work with this upstream today :)
>
>
>
> On Thu, Aug 20, 2015 at 8:08 AM Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
>> Hi all,
>>
>> I just pushed some changes to the hibernate.org site. The changes allow
>> you to run
>> the hibernate.org Awestruct environment within a Docker container while
>> still being able to
>> make changes locally. The obvious benefit is that in case of
>> environmental problems
>> due to native extension compilation etc, only one needs to sort this out
>> and all others
>> can then benefit by using an updated images.
>>
>> So how do you do that? Check out http://hibernate.org/docker/README/. It
>> comes down to
>> - You need a running Docker daemon
>> - Build the Docker image
>>   $ docker build -t hibernate/hibernate.org .
>> - Run the image
>>   $ docker run -t -i -p 4242:4242 -v <path to root dir of hibernate.org
>> checkout>:/home/dev/hibernate.org hibernate/hibernate.org
>>
>> Anyways, really the online docs should tell you everything. If not let me
>> know and we iron
>> things out there.
>>
>> What does that mean for you who still wants to run this locally? Nothing
>> really.
>> The local setup still works, BUT I had to make some changes to the build
>> file
>> (gems are not anymore stored relative to the checkout). To make sure all
>> keeps working,
>> after an update, I recommend to make sure to have a CLEAN checkout.
>> The best way to do this is via 'git clean -fxd' (thanks Sanne for this
>> one). Just make
>> sure to have no uncommitted changes.
>>
>> Let me know if you like it in which case we can do the same for
>> in.relation.to.
>>
>> Happy awestructing
>> --hardy
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Thu Aug 20 17:32:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 20 Aug 2015 21:32:29 +0000
Subject: [hibernate-dev] ORM 5.0 Final - delayed
In-Reply-To: <CAFdSV9taFM0EX-6fMdJ4npYzdkWdP5QO4A4kZ2rdafF2fg659w@mail.gmail.com>
References: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>
	<55D5E525.1050809@redhat.com>
	<CAFdSV9taFM0EX-6fMdJ4npYzdkWdP5QO4A4kZ2rdafF2fg659w@mail.gmail.com>
Message-ID: <CAFdSV9tCjC8y-q+Y8R3bpGyNZdtx_vXa=NyGr0JHa+grDEw6MQ@mail.gmail.com>

I was able to get the release done :)

The blog is very comprehensive and I will be announcing it soon.  But I did
want to point out a few things here first...

1) This is the first time we have published to BinTray.  For now I have
only published the release bundles.  There is a problem in the gradle piece
of this that I still need to track down.  It created the version, but did
not actually upload the zip/tgz files.
http://bintray.com/hibernate/bundles/hibernate-orm/5.0.0.Final
2) The Hibernate.org ORM doc page has been revamped to be version-specific
now.  See http://hibernate.org/orm/documentation/5.0/ versus
http://hibernate.org/orm/documentation/4.3 etc

On Thu, Aug 20, 2015 at 2:39 PM Steve Ebersole <steve at hibernate.org> wrote:

> I am having some majorly slow (and dropping) connection issues today.
> Trying to work through those and then I'll start on the release.
>
>
> On Thu, Aug 20, 2015 at 9:33 AM Scott Marlow <smarlow at redhat.com> wrote:
>
>> Please let me know if you want me to do any testing before the release.
>>
>> On 08/19/2015 02:34 PM, Steve Ebersole wrote:
>> > I am going to delay releasing 5.0 Final until tomorrow at earliest.
>> The CI
>> > server is having some massive trouble at the moment and I'd prefer to
>> make
>> > sure that we are getting clean builds there before I start the release.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>>
>

From steve at hibernate.org  Thu Aug 20 17:33:12 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 20 Aug 2015 21:33:12 +0000
Subject: [hibernate-dev] ORM 5.0 Final - delayed
In-Reply-To: <CAFdSV9tCjC8y-q+Y8R3bpGyNZdtx_vXa=NyGr0JHa+grDEw6MQ@mail.gmail.com>
References: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>
	<55D5E525.1050809@redhat.com>
	<CAFdSV9taFM0EX-6fMdJ4npYzdkWdP5QO4A4kZ2rdafF2fg659w@mail.gmail.com>
	<CAFdSV9tCjC8y-q+Y8R3bpGyNZdtx_vXa=NyGr0JHa+grDEw6MQ@mail.gmail.com>
Message-ID: <CAFdSV9uR76-4FTjfQ3duo_M=8k8Qosdhoe7WCv7eTmibiSeL6Q@mail.gmail.com>

Oh, and I created the 5.0 branch after releasing

On Thu, Aug 20, 2015 at 4:32 PM Steve Ebersole <steve at hibernate.org> wrote:

> I was able to get the release done :)
>
> The blog is very comprehensive and I will be announcing it soon.  But I
> did want to point out a few things here first...
>
> 1) This is the first time we have published to BinTray.  For now I have
> only published the release bundles.  There is a problem in the gradle piece
> of this that I still need to track down.  It created the version, but did
> not actually upload the zip/tgz files.
> http://bintray.com/hibernate/bundles/hibernate-orm/5.0.0.Final
> 2) The Hibernate.org ORM doc page has been revamped to be version-specific
> now.  See http://hibernate.org/orm/documentation/5.0/ versus
> http://hibernate.org/orm/documentation/4.3 etc
>
> On Thu, Aug 20, 2015 at 2:39 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I am having some majorly slow (and dropping) connection issues today.
>> Trying to work through those and then I'll start on the release.
>>
>>
>> On Thu, Aug 20, 2015 at 9:33 AM Scott Marlow <smarlow at redhat.com> wrote:
>>
>>> Please let me know if you want me to do any testing before the release.
>>>
>>> On 08/19/2015 02:34 PM, Steve Ebersole wrote:
>>> > I am going to delay releasing 5.0 Final until tomorrow at earliest.
>>> The CI
>>> > server is having some massive trouble at the moment and I'd prefer to
>>> make
>>> > sure that we are getting clean builds there before I start the release.
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>>
>>

From steve at hibernate.org  Thu Aug 20 18:31:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 20 Aug 2015 22:31:31 +0000
Subject: [hibernate-dev] Hibernate ORM 5.0.0 has gone Final!
Message-ID: <CAFdSV9tbW7yR0CU6MoUOJEeKk58m8AU9fFxvCzyvpxWyZ5k1bQ@mail.gmail.com>

Extra, extra, read all about it
http://in.relation.to/2015/08/20/hibernate-orm-500-final-release/

From brett at hibernate.org  Thu Aug 20 23:54:39 2015
From: brett at hibernate.org (Brett Meyer)
Date: Thu, 20 Aug 2015 23:54:39 -0400
Subject: [hibernate-dev] ORM 5.0 Final - delayed
In-Reply-To: <CAFdSV9uR76-4FTjfQ3duo_M=8k8Qosdhoe7WCv7eTmibiSeL6Q@mail.gmail.com>
References: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>	<55D5E525.1050809@redhat.com>	<CAFdSV9taFM0EX-6fMdJ4npYzdkWdP5QO4A4kZ2rdafF2fg659w@mail.gmail.com>	<CAFdSV9tCjC8y-q+Y8R3bpGyNZdtx_vXa=NyGr0JHa+grDEw6MQ@mail.gmail.com>
	<CAFdSV9uR76-4FTjfQ3duo_M=8k8Qosdhoe7WCv7eTmibiSeL6Q@mail.gmail.com>
Message-ID: <55D6A0FF.6010906@hibernate.org>

Steve, what's the current plan w/ respect to new development and 
bugfixes?  "5.0" == stable/5.0.x? Does master == 6.0?

Any thoughts on continuing to cherry-pick bugfixes to 4.3, when 
applicable?  Maybe that's more of a Gail question...

On 08/20/2015 05:33 PM, Steve Ebersole wrote:
> Oh, and I created the 5.0 branch after releasing
>
> On Thu, Aug 20, 2015 at 4:32 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> I was able to get the release done :)
>>
>> The blog is very comprehensive and I will be announcing it soon.  But I
>> did want to point out a few things here first...
>>
>> 1) This is the first time we have published to BinTray.  For now I have
>> only published the release bundles.  There is a problem in the gradle piece
>> of this that I still need to track down.  It created the version, but did
>> not actually upload the zip/tgz files.
>> http://bintray.com/hibernate/bundles/hibernate-orm/5.0.0.Final
>> 2) The Hibernate.org ORM doc page has been revamped to be version-specific
>> now.  See http://hibernate.org/orm/documentation/5.0/ versus
>> http://hibernate.org/orm/documentation/4.3 etc
>>
>> On Thu, Aug 20, 2015 at 2:39 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I am having some majorly slow (and dropping) connection issues today.
>>> Trying to work through those and then I'll start on the release.
>>>
>>>
>>> On Thu, Aug 20, 2015 at 9:33 AM Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>> Please let me know if you want me to do any testing before the release.
>>>>
>>>> On 08/19/2015 02:34 PM, Steve Ebersole wrote:
>>>>> I am going to delay releasing 5.0 Final until tomorrow at earliest.
>>>> The CI
>>>>> server is having some massive trouble at the moment and I'd prefer to
>>>> make
>>>>> sure that we are getting clean builds there before I start the release.
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Fri Aug 21 00:00:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 21 Aug 2015 04:00:33 +0000
Subject: [hibernate-dev] ORM 5.0 Final - delayed
In-Reply-To: <55D6A0FF.6010906@hibernate.org>
References: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>
	<55D5E525.1050809@redhat.com>
	<CAFdSV9taFM0EX-6fMdJ4npYzdkWdP5QO4A4kZ2rdafF2fg659w@mail.gmail.com>
	<CAFdSV9tCjC8y-q+Y8R3bpGyNZdtx_vXa=NyGr0JHa+grDEw6MQ@mail.gmail.com>
	<CAFdSV9uR76-4FTjfQ3duo_M=8k8Qosdhoe7WCv7eTmibiSeL6Q@mail.gmail.com>
	<55D6A0FF.6010906@hibernate.org>
Message-ID: <CAFdSV9tSkngVZhrbLm=PXK_ss_MqoEi_65KsbmQc1ibtioHXBw@mail.gmail.com>

Let's call master "5.1" for now.  Alot of that depends on the Antlr /
sql-gen question and time frames which I plan to start looking at again
next week or the following.  Depending on that, master might become 6.0.

The 5.0 branch definitely is meant to represent stable 5.0 dev.

I'd prefer to drop porting to any 4.x branch, but Gail should definitely
have a say in that.

On Thu, Aug 20, 2015, 10:55 PM Brett Meyer <brett at hibernate.org> wrote:

> Steve, what's the current plan w/ respect to new development and
> bugfixes?  "5.0" == stable/5.0.x? Does master == 6.0?
>
> Any thoughts on continuing to cherry-pick bugfixes to 4.3, when
> applicable?  Maybe that's more of a Gail question...
>
> On 08/20/2015 05:33 PM, Steve Ebersole wrote:
> > Oh, and I created the 5.0 branch after releasing
> >
> > On Thu, Aug 20, 2015 at 4:32 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> I was able to get the release done :)
> >>
> >> The blog is very comprehensive and I will be announcing it soon.  But I
> >> did want to point out a few things here first...
> >>
> >> 1) This is the first time we have published to BinTray.  For now I have
> >> only published the release bundles.  There is a problem in the gradle
> piece
> >> of this that I still need to track down.  It created the version, but
> did
> >> not actually upload the zip/tgz files.
> >> http://bintray.com/hibernate/bundles/hibernate-orm/5.0.0.Final
> >> 2) The Hibernate.org ORM doc page has been revamped to be
> version-specific
> >> now.  See http://hibernate.org/orm/documentation/5.0/ versus
> >> http://hibernate.org/orm/documentation/4.3 etc
> >>
> >> On Thu, Aug 20, 2015 at 2:39 PM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> I am having some majorly slow (and dropping) connection issues today.
> >>> Trying to work through those and then I'll start on the release.
> >>>
> >>>
> >>> On Thu, Aug 20, 2015 at 9:33 AM Scott Marlow <smarlow at redhat.com>
> wrote:
> >>>
> >>>> Please let me know if you want me to do any testing before the
> release.
> >>>>
> >>>> On 08/19/2015 02:34 PM, Steve Ebersole wrote:
> >>>>> I am going to delay releasing 5.0 Final until tomorrow at earliest.
> >>>> The CI
> >>>>> server is having some massive trouble at the moment and I'd prefer to
> >>>> make
> >>>>> sure that we are getting clean builds there before I start the
> release.
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Aug 21 11:14:58 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 21 Aug 2015 16:14:58 +0100
Subject: [hibernate-dev] Strange sequence effect with ORM 5
Message-ID: <CAFm4XO3i1PhQneuwngS-X+k5YQ=ytP3wyM6tuK3t_fgZXRbxxw@mail.gmail.com>

Hi all,
after upgrading Hibernate Search to Hibernate ORM 5.0.0.Final we
noticed a small change in behaviour in sequences.

In a single test we persist two entities of differnent types, Country
and Address, and both types have the id mapped as follows:

   @Id
   @GeneratedValue
   Long id;

Previously, when running on H2, the IDs assigned to these two entities
would be respectively 1 and 1.
When upgrading ORM from 5.0.0.CR3 to 5.0.0.Final, the assigned ids are
now 1 and 2.

Are sequences now being shared by default across unrelated entities?
Is this the new intended default?

Thanks,
Sanne

From steve at hibernate.org  Fri Aug 21 11:21:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 21 Aug 2015 15:21:58 +0000
Subject: [hibernate-dev] Strange sequence effect with ORM 5
In-Reply-To: <CAFm4XO3i1PhQneuwngS-X+k5YQ=ytP3wyM6tuK3t_fgZXRbxxw@mail.gmail.com>
References: <CAFm4XO3i1PhQneuwngS-X+k5YQ=ytP3wyM6tuK3t_fgZXRbxxw@mail.gmail.com>
Message-ID: <CAFdSV9uaR1J=kymGOO6cFTE9Q3vGJe9TwgkXQ9ytuscQKpBqUA@mail.gmail.com>

Please see the migration guide and/or blogs :)

Yes, we changed the default mapping for how id generators are mapped as
discussed extensively on the mail list last month or earlier this month.
Essentially we changed the default for
`hibernate.id.new_generator_mappings` from false to true for 5.0.  For H2,
the old mapping would have been an IDENTITY column.  The "new" mapping is
the SequenceStyleGenerator.



On Fri, Aug 21, 2015 at 10:16 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi all,
> after upgrading Hibernate Search to Hibernate ORM 5.0.0.Final we
> noticed a small change in behaviour in sequences.
>
> In a single test we persist two entities of differnent types, Country
> and Address, and both types have the id mapped as follows:
>
>    @Id
>    @GeneratedValue
>    Long id;
>
> Previously, when running on H2, the IDs assigned to these two entities
> would be respectively 1 and 1.
> When upgrading ORM from 5.0.0.CR3 to 5.0.0.Final, the assigned ids are
> now 1 and 2.
>
> Are sequences now being shared by default across unrelated entities?
> Is this the new intended default?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Aug 21 11:25:44 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 21 Aug 2015 16:25:44 +0100
Subject: [hibernate-dev] Strange sequence effect with ORM 5
In-Reply-To: <CAFdSV9uaR1J=kymGOO6cFTE9Q3vGJe9TwgkXQ9ytuscQKpBqUA@mail.gmail.com>
References: <CAFm4XO3i1PhQneuwngS-X+k5YQ=ytP3wyM6tuK3t_fgZXRbxxw@mail.gmail.com>
	<CAFdSV9uaR1J=kymGOO6cFTE9Q3vGJe9TwgkXQ9ytuscQKpBqUA@mail.gmail.com>
Message-ID: <CAFm4XO1RemzrM7NMzRT=MsCnX3i1R1NfvRnCmAzLuyzfMZN0hQ@mail.gmail.com>

Ok, thanks and sorry I missed this :)
I was aware that it would switch to sequences rather than identity,
but I missed that there would be a single Sequence shared among
types... I still find that a bit surprising as I would expect to
generally want different sequences for each type.

Thanks,
Sanne

On 21 August 2015 at 16:21, Steve Ebersole <steve at hibernate.org> wrote:
> Please see the migration guide and/or blogs :)
>
> Yes, we changed the default mapping for how id generators are mapped as
> discussed extensively on the mail list last month or earlier this month.
> Essentially we changed the default for `hibernate.id.new_generator_mappings`
> from false to true for 5.0.  For H2, the old mapping would have been an
> IDENTITY column.  The "new" mapping is the SequenceStyleGenerator.
>
>
>
> On Fri, Aug 21, 2015 at 10:16 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Hi all,
>> after upgrading Hibernate Search to Hibernate ORM 5.0.0.Final we
>> noticed a small change in behaviour in sequences.
>>
>> In a single test we persist two entities of differnent types, Country
>> and Address, and both types have the id mapped as follows:
>>
>>    @Id
>>    @GeneratedValue
>>    Long id;
>>
>> Previously, when running on H2, the IDs assigned to these two entities
>> would be respectively 1 and 1.
>> When upgrading ORM from 5.0.0.CR3 to 5.0.0.Final, the assigned ids are
>> now 1 and 2.
>>
>> Are sequences now being shared by default across unrelated entities?
>> Is this the new intended default?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Aug 21 11:30:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 21 Aug 2015 15:30:28 +0000
Subject: [hibernate-dev] Strange sequence effect with ORM 5
In-Reply-To: <CAFm4XO1RemzrM7NMzRT=MsCnX3i1R1NfvRnCmAzLuyzfMZN0hQ@mail.gmail.com>
References: <CAFm4XO3i1PhQneuwngS-X+k5YQ=ytP3wyM6tuK3t_fgZXRbxxw@mail.gmail.com>
	<CAFdSV9uaR1J=kymGOO6cFTE9Q3vGJe9TwgkXQ9ytuscQKpBqUA@mail.gmail.com>
	<CAFm4XO1RemzrM7NMzRT=MsCnX3i1R1NfvRnCmAzLuyzfMZN0hQ@mail.gmail.com>
Message-ID: <CAFdSV9vZ-F0RFCBLFqC1t0Yn30Vx8K=rsK7KA3GwhQFzX7F=jg@mail.gmail.com>

Well you can do that.  Thats just not historically how Hibernate worked.

Set `prefer_sequence_per_entity` to true

On Fri, Aug 21, 2015 at 10:26 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Ok, thanks and sorry I missed this :)
> I was aware that it would switch to sequences rather than identity,
> but I missed that there would be a single Sequence shared among
> types... I still find that a bit surprising as I would expect to
> generally want different sequences for each type.
>
> Thanks,
> Sanne
>
> On 21 August 2015 at 16:21, Steve Ebersole <steve at hibernate.org> wrote:
> > Please see the migration guide and/or blogs :)
> >
> > Yes, we changed the default mapping for how id generators are mapped as
> > discussed extensively on the mail list last month or earlier this month.
> > Essentially we changed the default for
> `hibernate.id.new_generator_mappings`
> > from false to true for 5.0.  For H2, the old mapping would have been an
> > IDENTITY column.  The "new" mapping is the SequenceStyleGenerator.
> >
> >
> >
> > On Fri, Aug 21, 2015 at 10:16 AM Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> Hi all,
> >> after upgrading Hibernate Search to Hibernate ORM 5.0.0.Final we
> >> noticed a small change in behaviour in sequences.
> >>
> >> In a single test we persist two entities of differnent types, Country
> >> and Address, and both types have the id mapped as follows:
> >>
> >>    @Id
> >>    @GeneratedValue
> >>    Long id;
> >>
> >> Previously, when running on H2, the IDs assigned to these two entities
> >> would be respectively 1 and 1.
> >> When upgrading ORM from 5.0.0.CR3 to 5.0.0.Final, the assigned ids are
> >> now 1 and 2.
> >>
> >> Are sequences now being shared by default across unrelated entities?
> >> Is this the new intended default?
> >>
> >> Thanks,
> >> Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Aug 21 11:31:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 21 Aug 2015 15:31:33 +0000
Subject: [hibernate-dev] Strange sequence effect with ORM 5
In-Reply-To: <CAFdSV9vZ-F0RFCBLFqC1t0Yn30Vx8K=rsK7KA3GwhQFzX7F=jg@mail.gmail.com>
References: <CAFm4XO3i1PhQneuwngS-X+k5YQ=ytP3wyM6tuK3t_fgZXRbxxw@mail.gmail.com>
	<CAFdSV9uaR1J=kymGOO6cFTE9Q3vGJe9TwgkXQ9ytuscQKpBqUA@mail.gmail.com>
	<CAFm4XO1RemzrM7NMzRT=MsCnX3i1R1NfvRnCmAzLuyzfMZN0hQ@mail.gmail.com>
	<CAFdSV9vZ-F0RFCBLFqC1t0Yn30Vx8K=rsK7KA3GwhQFzX7F=jg@mail.gmail.com>
Message-ID: <CAFdSV9uNPzRHJ59dkkC=SLeMKq95UP8mhAk0c7ZJzc3SkDsWEQ@mail.gmail.com>

Or, if you have *explicit* expectations you could, you know, explicitly
define them :)

On Fri, Aug 21, 2015 at 10:30 AM Steve Ebersole <steve at hibernate.org> wrote:

> Well you can do that.  Thats just not historically how Hibernate worked.
>
> Set `prefer_sequence_per_entity` to true
>
> On Fri, Aug 21, 2015 at 10:26 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Ok, thanks and sorry I missed this :)
>> I was aware that it would switch to sequences rather than identity,
>> but I missed that there would be a single Sequence shared among
>> types... I still find that a bit surprising as I would expect to
>> generally want different sequences for each type.
>>
>> Thanks,
>> Sanne
>>
>> On 21 August 2015 at 16:21, Steve Ebersole <steve at hibernate.org> wrote:
>> > Please see the migration guide and/or blogs :)
>> >
>> > Yes, we changed the default mapping for how id generators are mapped as
>> > discussed extensively on the mail list last month or earlier this month.
>> > Essentially we changed the default for
>> `hibernate.id.new_generator_mappings`
>> > from false to true for 5.0.  For H2, the old mapping would have been an
>> > IDENTITY column.  The "new" mapping is the SequenceStyleGenerator.
>> >
>> >
>> >
>> > On Fri, Aug 21, 2015 at 10:16 AM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> Hi all,
>> >> after upgrading Hibernate Search to Hibernate ORM 5.0.0.Final we
>> >> noticed a small change in behaviour in sequences.
>> >>
>> >> In a single test we persist two entities of differnent types, Country
>> >> and Address, and both types have the id mapped as follows:
>> >>
>> >>    @Id
>> >>    @GeneratedValue
>> >>    Long id;
>> >>
>> >> Previously, when running on H2, the IDs assigned to these two entities
>> >> would be respectively 1 and 1.
>> >> When upgrading ORM from 5.0.0.CR3 to 5.0.0.Final, the assigned ids are
>> >> now 1 and 2.
>> >>
>> >> Are sequences now being shared by default across unrelated entities?
>> >> Is this the new intended default?
>> >>
>> >> Thanks,
>> >> Sanne
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Fri Aug 21 11:54:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 21 Aug 2015 15:54:23 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
Message-ID: <CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>

http://www.antlr2.org/article/1170602723163/treewalkers.html

Not sure if y'all have seen this.  Its an old article advocating manual
tree walking (what we are facing here) over using generated tree walkers.



On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <steve at hibernate.org> wrote:

> I agree.  Its my biggest hang up with regard to using Antlr 4.  Actually,
> its my only hang up with Antlr 4, but its a huge one.
>
> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a look at
>> your poc.
>>
>> Apart some problems to fully understand the semantic model (due to my
>> lack of a complete knowledge of the domain problem),
>> I agree with you about the simplicity and elegance of  the grammar for
>> HQL recognition and semantic model building.
>>
>> What I don't like it's the necessity to build our own semantic model
>> walker/s in order to produce the final SQL.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> We've had a few discussions about this in the past.  As 5.0 is getting
>>> close to Final (next week), its time to start contemplating our next
>>> major
>>> tasks.  The consensus pick for that has been the idea of a "unified SQL
>>> generation engine" along with a shared project for the semantic analysis
>>> of
>>> HQL/JPQL (and recently it was decided to include JPA Criteria
>>> interpretation here as well).
>>>
>>> The central premise is this.  Take the roughly 6 or 7 different top-level
>>> ways Hibernate generates SQL and combine that into one "engine" based on
>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria shared
>>> project will be one producer of such semantic trees.  Others would
>>> include
>>> persisters (for insert/update/delete requests) and loaders (for load
>>> requests).
>>>
>>> We have a lot of tasks for this overall goal still remaining.
>>>
>>> We still have to finalize the design for the HQL/JPQL/Criteria to
>>> semantic
>>> tree translator.  One option is to proceed with the Antlr 4 based
>>> approach
>>> I started a PoC for.  John has been helping me some lately with that.
>>> The
>>> first task here is to come to a consensus whether Antlr 4 is the way we
>>> want to proceed here.  We've been over the pros and cons before in
>>> detail.
>>> In summary, there is a lot to love with Antlr 4.  Our grammar for HQL
>>> recognition and semantic tree building is very simple and elegant imo.
>>> The
>>> drawback is clearly the lack of tree walking, meaning that we are
>>> responsible for writing by hand our walker for the semantic tree.  In
>>> fact
>>> multiple, since each consumer (orm, ogm, search) would need to write
>>> their
>>> own.  And if we decide to build another AST while walking the semantic
>>> tree, we'd end up having to hand-write yet another walker for those.
>>>
>>> What I mean by that last part is that there are 2 ways we might choose to
>>> deal with the semantic tree.  For the purpose of discussion, let's look
>>> at
>>> the ORM case.  The first approach is to simply generate the SQL as we
>>> walk
>>> the semantic tree; this would be a 2 phase interpretation approach (input
>>> -> semantic tree -> SQL).  That works in many cases.  However it breaks
>>> down in other cases.  This is exactly the approach our existing HQL
>>> translator uses.  The other approach is to use a 3-phase translation
>>> (input
>>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to
>>> one
>>> of the major problems.  One source "semantic" query will often correspond
>>> to multiple SQL queries; that is hard to manage in the 2-phase approach.
>>> And not to mention integrating things like follow-on fetches and other
>>> enhancements we want to gain from this.  My vote is definitely for 3 or
>>> more phases of interpretation.  The problem is that this is exactly where
>>> Antlr 4 sort of falls down.
>>>
>>> So first things first... we need to decide on Antlr 3 versus Antlr 4
>>> (versus some other parser solution).
>>>
>>> Next, on the ORM side (every "backend" can decide this individually) we
>>> need to decide on the approach for semantic-tree to SQL translation,
>>> which
>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>>>
>>> We really need to decide these things ASAP and get moving on them as soon
>>> as ORM 5.0 is finished.
>>>
>>> Also, this is a massive undertaking with huge gain potentials for not
>>> just
>>> ORM.  As such we need to understand who will be working on this.  Sanne,
>>> Gunnar... I know y'all have a vested interest and a desire to work on it.
>>> John, I know the same is true for you.  Andrea?  Have you had a chance to
>>> look over the poc and/or get more familiar with Antlr?
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From dreborier at gmail.com  Fri Aug 21 12:58:51 2015
From: dreborier at gmail.com (andrea boriero)
Date: Fri, 21 Aug 2015 17:58:51 +0100
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
Message-ID: <CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>

I haven't seen it, I'm going to read it.

On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:

> http://www.antlr2.org/article/1170602723163/treewalkers.html
>
> Not sure if y'all have seen this.  Its an old article advocating manual
> tree walking (what we are facing here) over using generated tree walkers.
>
>
>
> On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I agree.  Its my biggest hang up with regard to using Antlr 4.  Actually,
>> its my only hang up with Antlr 4, but its a huge one.
>>
>> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a look
>>> at your poc.
>>>
>>> Apart some problems to fully understand the semantic model (due to my
>>> lack of a complete knowledge of the domain problem),
>>> I agree with you about the simplicity and elegance of  the grammar for
>>> HQL recognition and semantic model building.
>>>
>>> What I don't like it's the necessity to build our own semantic model
>>> walker/s in order to produce the final SQL.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> We've had a few discussions about this in the past.  As 5.0 is getting
>>>> close to Final (next week), its time to start contemplating our next
>>>> major
>>>> tasks.  The consensus pick for that has been the idea of a "unified SQL
>>>> generation engine" along with a shared project for the semantic
>>>> analysis of
>>>> HQL/JPQL (and recently it was decided to include JPA Criteria
>>>> interpretation here as well).
>>>>
>>>> The central premise is this.  Take the roughly 6 or 7 different
>>>> top-level
>>>> ways Hibernate generates SQL and combine that into one "engine" based on
>>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria shared
>>>> project will be one producer of such semantic trees.  Others would
>>>> include
>>>> persisters (for insert/update/delete requests) and loaders (for load
>>>> requests).
>>>>
>>>> We have a lot of tasks for this overall goal still remaining.
>>>>
>>>> We still have to finalize the design for the HQL/JPQL/Criteria to
>>>> semantic
>>>> tree translator.  One option is to proceed with the Antlr 4 based
>>>> approach
>>>> I started a PoC for.  John has been helping me some lately with that.
>>>> The
>>>> first task here is to come to a consensus whether Antlr 4 is the way we
>>>> want to proceed here.  We've been over the pros and cons before in
>>>> detail.
>>>> In summary, there is a lot to love with Antlr 4.  Our grammar for HQL
>>>> recognition and semantic tree building is very simple and elegant imo.
>>>> The
>>>> drawback is clearly the lack of tree walking, meaning that we are
>>>> responsible for writing by hand our walker for the semantic tree.  In
>>>> fact
>>>> multiple, since each consumer (orm, ogm, search) would need to write
>>>> their
>>>> own.  And if we decide to build another AST while walking the semantic
>>>> tree, we'd end up having to hand-write yet another walker for those.
>>>>
>>>> What I mean by that last part is that there are 2 ways we might choose
>>>> to
>>>> deal with the semantic tree.  For the purpose of discussion, let's look
>>>> at
>>>> the ORM case.  The first approach is to simply generate the SQL as we
>>>> walk
>>>> the semantic tree; this would be a 2 phase interpretation approach
>>>> (input
>>>> -> semantic tree -> SQL).  That works in many cases.  However it breaks
>>>> down in other cases.  This is exactly the approach our existing HQL
>>>> translator uses.  The other approach is to use a 3-phase translation
>>>> (input
>>>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to
>>>> one
>>>> of the major problems.  One source "semantic" query will often
>>>> correspond
>>>> to multiple SQL queries; that is hard to manage in the 2-phase approach.
>>>> And not to mention integrating things like follow-on fetches and other
>>>> enhancements we want to gain from this.  My vote is definitely for 3 or
>>>> more phases of interpretation.  The problem is that this is exactly
>>>> where
>>>> Antlr 4 sort of falls down.
>>>>
>>>> So first things first... we need to decide on Antlr 3 versus Antlr 4
>>>> (versus some other parser solution).
>>>>
>>>> Next, on the ORM side (every "backend" can decide this individually) we
>>>> need to decide on the approach for semantic-tree to SQL translation,
>>>> which
>>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>>>>
>>>> We really need to decide these things ASAP and get moving on them as
>>>> soon
>>>> as ORM 5.0 is finished.
>>>>
>>>> Also, this is a massive undertaking with huge gain potentials for not
>>>> just
>>>> ORM.  As such we need to understand who will be working on this.  Sanne,
>>>> Gunnar... I know y'all have a vested interest and a desire to work on
>>>> it.
>>>> John, I know the same is true for you.  Andrea?  Have you had a chance
>>>> to
>>>> look over the poc and/or get more familiar with Antlr?
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>

From steve at hibernate.org  Fri Aug 21 16:51:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 21 Aug 2015 20:51:31 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
Message-ID: <CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>

Just a heads up that I started a major refactoring of the antlr4 poc
project in preparation for starting to look at this next sql-gen step.

First I am making it into a multi-module project.  We will have the
hql-parser module, but then also an orm-sql-gen module to be able to play
with that part.  This makes sure we are not blending orm concerns into the
pure hql parser.

Also, I started working on splitting the "semantic query" model out into a
separate module as well.  There are a few reasons for this.  I wont go into
them all here.  The main one being that HQL is just one producer of this
semantic model.   Rather than another long name I went with the acronym SQM
(Semantic Query Model) here.  The top package being org.hibernate.sqm.

These changes already illustrated some tighter couplings then I had
intended, so it was a good exercise.  I'll push once I get those couplings
cleaned up.

On Fri, Aug 21, 2015 at 2:35 PM andrea boriero <dreborier at gmail.com> wrote:

> I haven't seen it, I'm going to read it.
>
> On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:
>
>> http://www.antlr2.org/article/1170602723163/treewalkers.html
>>
>> Not sure if y'all have seen this.  Its an old article advocating manual
>> tree walking (what we are facing here) over using generated tree walkers.
>>
>>
>>
>> On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I agree.  Its my biggest hang up with regard to using Antlr 4.
>>> Actually, its my only hang up with Antlr 4, but its a huge one.
>>>
>>> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <dreborier at gmail.com>
>>> wrote:
>>>
>>>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a look
>>>> at your poc.
>>>>
>>>> Apart some problems to fully understand the semantic model (due to my
>>>> lack of a complete knowledge of the domain problem),
>>>> I agree with you about the simplicity and elegance of  the grammar for
>>>> HQL recognition and semantic model building.
>>>>
>>>> What I don't like it's the necessity to build our own semantic model
>>>> walker/s in order to produce the final SQL.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org> wrote:
>>>>
>>>>> We've had a few discussions about this in the past.  As 5.0 is getting
>>>>> close to Final (next week), its time to start contemplating our next
>>>>> major
>>>>> tasks.  The consensus pick for that has been the idea of a "unified SQL
>>>>> generation engine" along with a shared project for the semantic
>>>>> analysis of
>>>>> HQL/JPQL (and recently it was decided to include JPA Criteria
>>>>> interpretation here as well).
>>>>>
>>>>> The central premise is this.  Take the roughly 6 or 7 different
>>>>> top-level
>>>>> ways Hibernate generates SQL and combine that into one "engine" based
>>>>> on
>>>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria shared
>>>>> project will be one producer of such semantic trees.  Others would
>>>>> include
>>>>> persisters (for insert/update/delete requests) and loaders (for load
>>>>> requests).
>>>>>
>>>>> We have a lot of tasks for this overall goal still remaining.
>>>>>
>>>>> We still have to finalize the design for the HQL/JPQL/Criteria to
>>>>> semantic
>>>>> tree translator.  One option is to proceed with the Antlr 4 based
>>>>> approach
>>>>> I started a PoC for.  John has been helping me some lately with that.
>>>>> The
>>>>> first task here is to come to a consensus whether Antlr 4 is the way we
>>>>> want to proceed here.  We've been over the pros and cons before in
>>>>> detail.
>>>>> In summary, there is a lot to love with Antlr 4.  Our grammar for HQL
>>>>> recognition and semantic tree building is very simple and elegant
>>>>> imo.  The
>>>>> drawback is clearly the lack of tree walking, meaning that we are
>>>>> responsible for writing by hand our walker for the semantic tree.  In
>>>>> fact
>>>>> multiple, since each consumer (orm, ogm, search) would need to write
>>>>> their
>>>>> own.  And if we decide to build another AST while walking the semantic
>>>>> tree, we'd end up having to hand-write yet another walker for those.
>>>>>
>>>>> What I mean by that last part is that there are 2 ways we might choose
>>>>> to
>>>>> deal with the semantic tree.  For the purpose of discussion, let's
>>>>> look at
>>>>> the ORM case.  The first approach is to simply generate the SQL as we
>>>>> walk
>>>>> the semantic tree; this would be a 2 phase interpretation approach
>>>>> (input
>>>>> -> semantic tree -> SQL).  That works in many cases.  However it breaks
>>>>> down in other cases.  This is exactly the approach our existing HQL
>>>>> translator uses.  The other approach is to use a 3-phase translation
>>>>> (input
>>>>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint
>>>>> to one
>>>>> of the major problems.  One source "semantic" query will often
>>>>> correspond
>>>>> to multiple SQL queries; that is hard to manage in the 2-phase
>>>>> approach.
>>>>> And not to mention integrating things like follow-on fetches and other
>>>>> enhancements we want to gain from this.  My vote is definitely for 3 or
>>>>> more phases of interpretation.  The problem is that this is exactly
>>>>> where
>>>>> Antlr 4 sort of falls down.
>>>>>
>>>>> So first things first... we need to decide on Antlr 3 versus Antlr 4
>>>>> (versus some other parser solution).
>>>>>
>>>>> Next, on the ORM side (every "backend" can decide this individually) we
>>>>> need to decide on the approach for semantic-tree to SQL translation,
>>>>> which
>>>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>>>>>
>>>>> We really need to decide these things ASAP and get moving on them as
>>>>> soon
>>>>> as ORM 5.0 is finished.
>>>>>
>>>>> Also, this is a massive undertaking with huge gain potentials for not
>>>>> just
>>>>> ORM.  As such we need to understand who will be working on this.
>>>>> Sanne,
>>>>> Gunnar... I know y'all have a vested interest and a desire to work on
>>>>> it.
>>>>> John, I know the same is true for you.  Andrea?  Have you had a chance
>>>>> to
>>>>> look over the poc and/or get more familiar with Antlr?
>>>>>
>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>

From steve at hibernate.org  Sat Aug 22 10:22:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 22 Aug 2015 14:22:01 +0000
Subject: [hibernate-dev] Hibernate.org layouts
In-Reply-To: <20150820091327.GD19723@Nineveh.lan>
References: <CAFdSV9uKOmgxPW4vvFLwtqS2i5JctPPCkMDYqHit5CM_yup3BA@mail.gmail.com>
	<20150820091327.GD19723@Nineveh.lan>
Message-ID: <CAFdSV9u66g78ar_iuBYs3aKmD3rJPiRkqLcLfW-rFM2Cw8Qrog@mail.gmail.com>

I went ahead for now with your first (1) option.  So for ORM, the left-hand
"Documentation" link now becomes 3: "Documentation (5.0)", "Documentation
(4.3)", "Documentation (4.2)".

Not ideal long term, but as you said, the easiest solution for now and it
works.  But it got me thinking that a lot of the website content is
actually version specific, docs and downloads being the 2 main ones.  I'd
like to discuss options for this a little bit in Barcelona


On Thu, Aug 20, 2015 at 4:13 AM Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> I am not a great expert on the templating side either, but I can tell you
> how it
> is put together atm.
>
> The left hand menu items for the different projects (About, Downloads,
> Documentation, etc)
> are actually generated from the site config.
>
> If you look into _config/site.yml, you see that each project defines a
> menu section which
> is in itself split between intern and extern. The menu items specified in
> site.yml are
> then displayed depending on the chosen project.
>
> The place where this is happening is
> _layouts/project/project-frame.html.haml:
>
> {code}
>       %ul.nav.nav-list
>         -# removes index.html and then replace download.html to download/
>         - current_path = page.output_path.sub(/index\.html$/,
> "").sub(/\.html$/,"/")
>         - project_description.menu.intern.each do |menu|
>           -# active if path is a subpath of the menu item. The project
> home has to be treated differently as every path is a subpath of home
>           - active = (menu.href == "/#{page.project}/" && menu.href ==
> current_path) || (menu.href != "/#{page.project}/" &&
> current_path.start_with?(menu.href))
>           %li{:class => "#{(active ? "active" : "")}"}
>             %a{:href => "#{relative("#{menu.href}")}"}
>               %i{:class => "#{menu.css_class} menu-icon"}
>               #{menu.name}
>         %li.divider
>         - project_description.menu.extern.each do |menu|
>           %li
>             %a{:href => "#{menu.href}"}
>               %i{:class => "#{menu.css_class} menu-icon"}
>               #{menu.name}
> {code}
>
> project_description.menu.intern.each will iterate over the intern links
> for a given project whereas
> project_description.menu.extern.each iterates the external links.
>
> So far so good. Depending on how dynamic you want all this to work you
> have multiple options.
>
> 1) Work with the current approach and just define your different
> documentation links. If you work
>    with the current structure you would get multiple Downloads links
> pointing to the different
>    doc versions. This is the simplest approach and does not require any
> template change at all
> 2) Create a sub hash orm:menu:intern:documentation:versions (just
> extending the nested structure
>    we already have. YAML will automatically create the nested hashes out
> of this.) In the template
>    you would then need to handle the ORM case a bit different (eg by
> checking whether the current
>    project is ORM). This way I could envision a single Download link which
> would point to the
>    current docs together with a little expander icon next to it which when
> clicked makes the
>    other documentation links visible by expanding some sort of div. I
> think this would be visually
>    much more appealing. Obviously you need to deal with template changes
> as well as HTML + CSS changes
>    for getting the drop out menu right.
> 3) In the template check whether your current items is the ORM Download
> and if so, do whatever you want.
>    This bypasses site.yml completely.
>
> Personally I think 1) is a great way to get started verify the new
> approach and its navigation. Once all is
> working as it should I would look into 2) since I think it would be
> visually much more appealing. Maybe
> Davide could help with the CSS/HTML part. I am pretty bad with this.
>
> Anyways, hope this points you into the right direction.
>
> --Hardy
>
>
>
>
>
> On Wed, Aug 19, 2015 at 10:52:32PM +0000, Steve Ebersole wrote:
> > In regards to WEBSITE-382
> > <https://hibernate.atlassian.net/browse/WEBSITE-382>[1], I would love to
> > get the "list" of version family specific doc page links into the left
> nav
> > ideally as another section there.  Anyone able to give me some pointers
> how
> > to hook into the left-hand nav links are managed?
> >
> > I see 'bothcol.html.haml' defines 'leftcol.html.haml' and
> > 'rightcol.html.haml' are defined.  But I have no idea if that is the
> right
> > place.  I have never even seen a right-hand column in use in the website.
> > And I have not found any specific 'leftcol.html.haml' or
> > 'rightcol.html.haml' files.
> >
> > [1] https://hibernate.atlassian.net/browse/WEBSITE-382
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Aug 22 14:16:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 22 Aug 2015 18:16:59 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
	<CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
Message-ID: <CAFdSV9sBHDqrNkhkAMn0=v=_x_vK=aD+1iU4QyrwzmFPSZj3jA@mail.gmail.com>

I got that initial refactoring pushed to my fork...

On Fri, Aug 21, 2015 at 3:51 PM Steve Ebersole <steve at hibernate.org> wrote:

> Just a heads up that I started a major refactoring of the antlr4 poc
> project in preparation for starting to look at this next sql-gen step.
>
> First I am making it into a multi-module project.  We will have the
> hql-parser module, but then also an orm-sql-gen module to be able to play
> with that part.  This makes sure we are not blending orm concerns into the
> pure hql parser.
>
> Also, I started working on splitting the "semantic query" model out into a
> separate module as well.  There are a few reasons for this.  I wont go into
> them all here.  The main one being that HQL is just one producer of this
> semantic model.   Rather than another long name I went with the acronym SQM
> (Semantic Query Model) here.  The top package being org.hibernate.sqm.
>
> These changes already illustrated some tighter couplings then I had
> intended, so it was a good exercise.  I'll push once I get those couplings
> cleaned up.
>
> On Fri, Aug 21, 2015 at 2:35 PM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> I haven't seen it, I'm going to read it.
>>
>> On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> http://www.antlr2.org/article/1170602723163/treewalkers.html
>>>
>>> Not sure if y'all have seen this.  Its an old article advocating manual
>>> tree walking (what we are facing here) over using generated tree walkers.
>>>
>>>
>>>
>>> On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> I agree.  Its my biggest hang up with regard to using Antlr 4.
>>>> Actually, its my only hang up with Antlr 4, but its a huge one.
>>>>
>>>> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <dreborier at gmail.com>
>>>> wrote:
>>>>
>>>>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a look
>>>>> at your poc.
>>>>>
>>>>> Apart some problems to fully understand the semantic model (due to my
>>>>> lack of a complete knowledge of the domain problem),
>>>>> I agree with you about the simplicity and elegance of  the grammar
>>>>> for HQL recognition and semantic model building.
>>>>>
>>>>> What I don't like it's the necessity to build our own semantic model
>>>>> walker/s in order to produce the final SQL.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> We've had a few discussions about this in the past.  As 5.0 is getting
>>>>>> close to Final (next week), its time to start contemplating our next
>>>>>> major
>>>>>> tasks.  The consensus pick for that has been the idea of a "unified
>>>>>> SQL
>>>>>> generation engine" along with a shared project for the semantic
>>>>>> analysis of
>>>>>> HQL/JPQL (and recently it was decided to include JPA Criteria
>>>>>> interpretation here as well).
>>>>>>
>>>>>> The central premise is this.  Take the roughly 6 or 7 different
>>>>>> top-level
>>>>>> ways Hibernate generates SQL and combine that into one "engine" based
>>>>>> on
>>>>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria
>>>>>> shared
>>>>>> project will be one producer of such semantic trees.  Others would
>>>>>> include
>>>>>> persisters (for insert/update/delete requests) and loaders (for load
>>>>>> requests).
>>>>>>
>>>>>> We have a lot of tasks for this overall goal still remaining.
>>>>>>
>>>>>> We still have to finalize the design for the HQL/JPQL/Criteria to
>>>>>> semantic
>>>>>> tree translator.  One option is to proceed with the Antlr 4 based
>>>>>> approach
>>>>>> I started a PoC for.  John has been helping me some lately with
>>>>>> that.  The
>>>>>> first task here is to come to a consensus whether Antlr 4 is the way
>>>>>> we
>>>>>> want to proceed here.  We've been over the pros and cons before in
>>>>>> detail.
>>>>>> In summary, there is a lot to love with Antlr 4.  Our grammar for HQL
>>>>>> recognition and semantic tree building is very simple and elegant
>>>>>> imo.  The
>>>>>> drawback is clearly the lack of tree walking, meaning that we are
>>>>>> responsible for writing by hand our walker for the semantic tree.  In
>>>>>> fact
>>>>>> multiple, since each consumer (orm, ogm, search) would need to write
>>>>>> their
>>>>>> own.  And if we decide to build another AST while walking the semantic
>>>>>> tree, we'd end up having to hand-write yet another walker for those.
>>>>>>
>>>>>> What I mean by that last part is that there are 2 ways we might
>>>>>> choose to
>>>>>> deal with the semantic tree.  For the purpose of discussion, let's
>>>>>> look at
>>>>>> the ORM case.  The first approach is to simply generate the SQL as we
>>>>>> walk
>>>>>> the semantic tree; this would be a 2 phase interpretation approach
>>>>>> (input
>>>>>> -> semantic tree -> SQL).  That works in many cases.  However it
>>>>>> breaks
>>>>>> down in other cases.  This is exactly the approach our existing HQL
>>>>>> translator uses.  The other approach is to use a 3-phase translation
>>>>>> (input
>>>>>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint
>>>>>> to one
>>>>>> of the major problems.  One source "semantic" query will often
>>>>>> correspond
>>>>>> to multiple SQL queries; that is hard to manage in the 2-phase
>>>>>> approach.
>>>>>> And not to mention integrating things like follow-on fetches and other
>>>>>> enhancements we want to gain from this.  My vote is definitely for 3
>>>>>> or
>>>>>> more phases of interpretation.  The problem is that this is exactly
>>>>>> where
>>>>>> Antlr 4 sort of falls down.
>>>>>>
>>>>>> So first things first... we need to decide on Antlr 3 versus Antlr 4
>>>>>> (versus some other parser solution).
>>>>>>
>>>>>> Next, on the ORM side (every "backend" can decide this individually)
>>>>>> we
>>>>>> need to decide on the approach for semantic-tree to SQL translation,
>>>>>> which
>>>>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>>>>>>
>>>>>> We really need to decide these things ASAP and get moving on them as
>>>>>> soon
>>>>>> as ORM 5.0 is finished.
>>>>>>
>>>>>> Also, this is a massive undertaking with huge gain potentials for not
>>>>>> just
>>>>>> ORM.  As such we need to understand who will be working on this.
>>>>>> Sanne,
>>>>>> Gunnar... I know y'all have a vested interest and a desire to work on
>>>>>> it.
>>>>>> John, I know the same is true for you.  Andrea?  Have you had a
>>>>>> chance to
>>>>>> look over the poc and/or get more familiar with Antlr?
>>>>>>
>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>

From hardy at hibernate.org  Sat Aug 22 15:33:03 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Sat, 22 Aug 2015 21:33:03 +0200
Subject: [hibernate-dev] Hibernate.org layouts
In-Reply-To: <CAFdSV9u66g78ar_iuBYs3aKmD3rJPiRkqLcLfW-rFM2Cw8Qrog@mail.gmail.com>
References: <CAFdSV9uKOmgxPW4vvFLwtqS2i5JctPPCkMDYqHit5CM_yup3BA@mail.gmail.com>
	<20150820091327.GD19723@Nineveh.lan>
	<CAFdSV9u66g78ar_iuBYs3aKmD3rJPiRkqLcLfW-rFM2Cw8Qrog@mail.gmail.com>
Message-ID: <20150822193303.GA53375@Nineveh.lan>

Hi,

On Sat, Aug 22, 2015 at 02:22:01PM +0000, Steve Ebersole wrote:
> I went ahead for now with your first (1) option.  So for ORM, the left-hand
> "Documentation" link now becomes 3: "Documentation (5.0)", "Documentation
> (4.3)", "Documentation (4.2)".

Right, definitely the easiest.

> Not ideal long term, but as you said, the easiest solution for now and it
> works.

Jupp. If you thought that working with awestruct was tricky and cumbersome
wait until you get down to HAML and Co ;-)

> But it got me thinking that a lot of the website content is
> actually version specific, docs and downloads being the 2 main ones.  I'd
> like to discuss options for this a little bit in Barcelona

Sure.

Btw, I aligned in.relation.to with hibernate.org now. This means I made the same
changes to the Rakefile on in.relation.to and there is also a Dockerfile there
as well now.

--Hardy

From steve at hibernate.org  Sun Aug 23 23:55:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 24 Aug 2015 03:55:13 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9sBHDqrNkhkAMn0=v=_x_vK=aD+1iU4QyrwzmFPSZj3jA@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
	<CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
	<CAFdSV9sBHDqrNkhkAMn0=v=_x_vK=aD+1iU4QyrwzmFPSZj3jA@mail.gmail.com>
Message-ID: <CAFdSV9sQ3UvRTnLWp=x91gNCnrOBi1VHQs6LdhbbESZ-2q4EYw@mail.gmail.com>

Another point I want to discuss up from because it affects tree structure.
Specifically the idea of an "unbounded implicit inheritance" query.  These
are queries like "from java.lang.Object".  Queries where the from clause
pulls in "unmapped inheritance".  These are fine, to an extent.  Hibernate
has natively supported these since way back[1].

What is problematic is cases where we have more than one "unmapped
inheritance" reference.  E.g. "from java.lang.Object o1, java.lang.Object
o2".  In fact its the same difficulty as an unbounded cartesian product,
but here in terms of the number of SQL queries we need to produce/execute.

So I propose that we allow just one "unmapped inheritance" reference per
query.

[1] Reminder to self... another "strict JPQL compliance" consideration.

On Sat, Aug 22, 2015 at 1:16 PM Steve Ebersole <steve at hibernate.org> wrote:

> I got that initial refactoring pushed to my fork...
>
> On Fri, Aug 21, 2015 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Just a heads up that I started a major refactoring of the antlr4 poc
>> project in preparation for starting to look at this next sql-gen step.
>>
>> First I am making it into a multi-module project.  We will have the
>> hql-parser module, but then also an orm-sql-gen module to be able to play
>> with that part.  This makes sure we are not blending orm concerns into the
>> pure hql parser.
>>
>> Also, I started working on splitting the "semantic query" model out into
>> a separate module as well.  There are a few reasons for this.  I wont go
>> into them all here.  The main one being that HQL is just one producer of
>> this semantic model.   Rather than another long name I went with the
>> acronym SQM (Semantic Query Model) here.  The top package being
>> org.hibernate.sqm.
>>
>> These changes already illustrated some tighter couplings then I had
>> intended, so it was a good exercise.  I'll push once I get those couplings
>> cleaned up.
>>
>> On Fri, Aug 21, 2015 at 2:35 PM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>>> I haven't seen it, I'm going to read it.
>>>
>>> On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> http://www.antlr2.org/article/1170602723163/treewalkers.html
>>>>
>>>> Not sure if y'all have seen this.  Its an old article advocating manual
>>>> tree walking (what we are facing here) over using generated tree walkers.
>>>>
>>>>
>>>>
>>>> On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> I agree.  Its my biggest hang up with regard to using Antlr 4.
>>>>> Actually, its my only hang up with Antlr 4, but its a huge one.
>>>>>
>>>>> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <dreborier at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a
>>>>>> look at your poc.
>>>>>>
>>>>>> Apart some problems to fully understand the semantic model (due to my
>>>>>> lack of a complete knowledge of the domain problem),
>>>>>> I agree with you about the simplicity and elegance of  the grammar
>>>>>> for HQL recognition and semantic model building.
>>>>>>
>>>>>> What I don't like it's the necessity to build our own semantic model
>>>>>> walker/s in order to produce the final SQL.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> We've had a few discussions about this in the past.  As 5.0 is
>>>>>>> getting
>>>>>>> close to Final (next week), its time to start contemplating our next
>>>>>>> major
>>>>>>> tasks.  The consensus pick for that has been the idea of a "unified
>>>>>>> SQL
>>>>>>> generation engine" along with a shared project for the semantic
>>>>>>> analysis of
>>>>>>> HQL/JPQL (and recently it was decided to include JPA Criteria
>>>>>>> interpretation here as well).
>>>>>>>
>>>>>>> The central premise is this.  Take the roughly 6 or 7 different
>>>>>>> top-level
>>>>>>> ways Hibernate generates SQL and combine that into one "engine"
>>>>>>> based on
>>>>>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria
>>>>>>> shared
>>>>>>> project will be one producer of such semantic trees.  Others would
>>>>>>> include
>>>>>>> persisters (for insert/update/delete requests) and loaders (for load
>>>>>>> requests).
>>>>>>>
>>>>>>> We have a lot of tasks for this overall goal still remaining.
>>>>>>>
>>>>>>> We still have to finalize the design for the HQL/JPQL/Criteria to
>>>>>>> semantic
>>>>>>> tree translator.  One option is to proceed with the Antlr 4 based
>>>>>>> approach
>>>>>>> I started a PoC for.  John has been helping me some lately with
>>>>>>> that.  The
>>>>>>> first task here is to come to a consensus whether Antlr 4 is the way
>>>>>>> we
>>>>>>> want to proceed here.  We've been over the pros and cons before in
>>>>>>> detail.
>>>>>>> In summary, there is a lot to love with Antlr 4.  Our grammar for HQL
>>>>>>> recognition and semantic tree building is very simple and elegant
>>>>>>> imo.  The
>>>>>>> drawback is clearly the lack of tree walking, meaning that we are
>>>>>>> responsible for writing by hand our walker for the semantic tree.
>>>>>>> In fact
>>>>>>> multiple, since each consumer (orm, ogm, search) would need to write
>>>>>>> their
>>>>>>> own.  And if we decide to build another AST while walking the
>>>>>>> semantic
>>>>>>> tree, we'd end up having to hand-write yet another walker for those.
>>>>>>>
>>>>>>> What I mean by that last part is that there are 2 ways we might
>>>>>>> choose to
>>>>>>> deal with the semantic tree.  For the purpose of discussion, let's
>>>>>>> look at
>>>>>>> the ORM case.  The first approach is to simply generate the SQL as
>>>>>>> we walk
>>>>>>> the semantic tree; this would be a 2 phase interpretation approach
>>>>>>> (input
>>>>>>> -> semantic tree -> SQL).  That works in many cases.  However it
>>>>>>> breaks
>>>>>>> down in other cases.  This is exactly the approach our existing HQL
>>>>>>> translator uses.  The other approach is to use a 3-phase translation
>>>>>>> (input
>>>>>>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint
>>>>>>> to one
>>>>>>> of the major problems.  One source "semantic" query will often
>>>>>>> correspond
>>>>>>> to multiple SQL queries; that is hard to manage in the 2-phase
>>>>>>> approach.
>>>>>>> And not to mention integrating things like follow-on fetches and
>>>>>>> other
>>>>>>> enhancements we want to gain from this.  My vote is definitely for 3
>>>>>>> or
>>>>>>> more phases of interpretation.  The problem is that this is exactly
>>>>>>> where
>>>>>>> Antlr 4 sort of falls down.
>>>>>>>
>>>>>>> So first things first... we need to decide on Antlr 3 versus Antlr 4
>>>>>>> (versus some other parser solution).
>>>>>>>
>>>>>>> Next, on the ORM side (every "backend" can decide this individually)
>>>>>>> we
>>>>>>> need to decide on the approach for semantic-tree to SQL translation,
>>>>>>> which
>>>>>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>>>>>>>
>>>>>>> We really need to decide these things ASAP and get moving on them as
>>>>>>> soon
>>>>>>> as ORM 5.0 is finished.
>>>>>>>
>>>>>>> Also, this is a massive undertaking with huge gain potentials for
>>>>>>> not just
>>>>>>> ORM.  As such we need to understand who will be working on this.
>>>>>>> Sanne,
>>>>>>> Gunnar... I know y'all have a vested interest and a desire to work
>>>>>>> on it.
>>>>>>> John, I know the same is true for you.  Andrea?  Have you had a
>>>>>>> chance to
>>>>>>> look over the poc and/or get more familiar with Antlr?
>>>>>>>
>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>

From dreborier at gmail.com  Mon Aug 24 08:40:42 2015
From: dreborier at gmail.com (andrea boriero)
Date: Mon, 24 Aug 2015 13:40:42 +0100
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9sQ3UvRTnLWp=x91gNCnrOBi1VHQs6LdhbbESZ-2q4EYw@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
	<CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
	<CAFdSV9sBHDqrNkhkAMn0=v=_x_vK=aD+1iU4QyrwzmFPSZj3jA@mail.gmail.com>
	<CAFdSV9sQ3UvRTnLWp=x91gNCnrOBi1VHQs6LdhbbESZ-2q4EYw@mail.gmail.com>
Message-ID: <CAL00eSQ-pXqK1w3nb-E1aiRFF5BxsG2+XrqkqX9f4EV7AApg_w@mail.gmail.com>

 I have nothing against your proposal so +1

On 24 August 2015 at 04:55, Steve Ebersole <steve at hibernate.org> wrote:

> Another point I want to discuss up from because it affects tree
> structure.  Specifically the idea of an "unbounded implicit inheritance"
> query.  These are queries like "from java.lang.Object".  Queries where the
> from clause pulls in "unmapped inheritance".  These are fine, to an
> extent.  Hibernate has natively supported these since way back[1].
>
> What is problematic is cases where we have more than one "unmapped
> inheritance" reference.  E.g. "from java.lang.Object o1, java.lang.Object
> o2".  In fact its the same difficulty as an unbounded cartesian product,
> but here in terms of the number of SQL queries we need to produce/execute.
>
> So I propose that we allow just one "unmapped inheritance" reference per
> query.
>
> [1] Reminder to self... another "strict JPQL compliance" consideration.
>
> On Sat, Aug 22, 2015 at 1:16 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I got that initial refactoring pushed to my fork...
>>
>> On Fri, Aug 21, 2015 at 3:51 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Just a heads up that I started a major refactoring of the antlr4 poc
>>> project in preparation for starting to look at this next sql-gen step.
>>>
>>> First I am making it into a multi-module project.  We will have the
>>> hql-parser module, but then also an orm-sql-gen module to be able to play
>>> with that part.  This makes sure we are not blending orm concerns into the
>>> pure hql parser.
>>>
>>> Also, I started working on splitting the "semantic query" model out into
>>> a separate module as well.  There are a few reasons for this.  I wont go
>>> into them all here.  The main one being that HQL is just one producer of
>>> this semantic model.   Rather than another long name I went with the
>>> acronym SQM (Semantic Query Model) here.  The top package being
>>> org.hibernate.sqm.
>>>
>>> These changes already illustrated some tighter couplings then I had
>>> intended, so it was a good exercise.  I'll push once I get those couplings
>>> cleaned up.
>>>
>>> On Fri, Aug 21, 2015 at 2:35 PM andrea boriero <dreborier at gmail.com>
>>> wrote:
>>>
>>>> I haven't seen it, I'm going to read it.
>>>>
>>>> On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:
>>>>
>>>>> http://www.antlr2.org/article/1170602723163/treewalkers.html
>>>>>
>>>>> Not sure if y'all have seen this.  Its an old article advocating
>>>>> manual tree walking (what we are facing here) over using generated tree
>>>>> walkers.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> I agree.  Its my biggest hang up with regard to using Antlr 4.
>>>>>> Actually, its my only hang up with Antlr 4, but its a huge one.
>>>>>>
>>>>>> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <dreborier at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a
>>>>>>> look at your poc.
>>>>>>>
>>>>>>> Apart some problems to fully understand the semantic model (due to
>>>>>>> my lack of a complete knowledge of the domain problem),
>>>>>>> I agree with you about the simplicity and elegance of  the grammar
>>>>>>> for HQL recognition and semantic model building.
>>>>>>>
>>>>>>> What I don't like it's the necessity to build our own semantic model
>>>>>>> walker/s in order to produce the final SQL.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> We've had a few discussions about this in the past.  As 5.0 is
>>>>>>>> getting
>>>>>>>> close to Final (next week), its time to start contemplating our
>>>>>>>> next major
>>>>>>>> tasks.  The consensus pick for that has been the idea of a "unified
>>>>>>>> SQL
>>>>>>>> generation engine" along with a shared project for the semantic
>>>>>>>> analysis of
>>>>>>>> HQL/JPQL (and recently it was decided to include JPA Criteria
>>>>>>>> interpretation here as well).
>>>>>>>>
>>>>>>>> The central premise is this.  Take the roughly 6 or 7 different
>>>>>>>> top-level
>>>>>>>> ways Hibernate generates SQL and combine that into one "engine"
>>>>>>>> based on
>>>>>>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria
>>>>>>>> shared
>>>>>>>> project will be one producer of such semantic trees.  Others would
>>>>>>>> include
>>>>>>>> persisters (for insert/update/delete requests) and loaders (for load
>>>>>>>> requests).
>>>>>>>>
>>>>>>>> We have a lot of tasks for this overall goal still remaining.
>>>>>>>>
>>>>>>>> We still have to finalize the design for the HQL/JPQL/Criteria to
>>>>>>>> semantic
>>>>>>>> tree translator.  One option is to proceed with the Antlr 4 based
>>>>>>>> approach
>>>>>>>> I started a PoC for.  John has been helping me some lately with
>>>>>>>> that.  The
>>>>>>>> first task here is to come to a consensus whether Antlr 4 is the
>>>>>>>> way we
>>>>>>>> want to proceed here.  We've been over the pros and cons before in
>>>>>>>> detail.
>>>>>>>> In summary, there is a lot to love with Antlr 4.  Our grammar for
>>>>>>>> HQL
>>>>>>>> recognition and semantic tree building is very simple and elegant
>>>>>>>> imo.  The
>>>>>>>> drawback is clearly the lack of tree walking, meaning that we are
>>>>>>>> responsible for writing by hand our walker for the semantic tree.
>>>>>>>> In fact
>>>>>>>> multiple, since each consumer (orm, ogm, search) would need to
>>>>>>>> write their
>>>>>>>> own.  And if we decide to build another AST while walking the
>>>>>>>> semantic
>>>>>>>> tree, we'd end up having to hand-write yet another walker for those.
>>>>>>>>
>>>>>>>> What I mean by that last part is that there are 2 ways we might
>>>>>>>> choose to
>>>>>>>> deal with the semantic tree.  For the purpose of discussion, let's
>>>>>>>> look at
>>>>>>>> the ORM case.  The first approach is to simply generate the SQL as
>>>>>>>> we walk
>>>>>>>> the semantic tree; this would be a 2 phase interpretation approach
>>>>>>>> (input
>>>>>>>> -> semantic tree -> SQL).  That works in many cases.  However it
>>>>>>>> breaks
>>>>>>>> down in other cases.  This is exactly the approach our existing HQL
>>>>>>>> translator uses.  The other approach is to use a 3-phase
>>>>>>>> translation (input
>>>>>>>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a
>>>>>>>> hint to one
>>>>>>>> of the major problems.  One source "semantic" query will often
>>>>>>>> correspond
>>>>>>>> to multiple SQL queries; that is hard to manage in the 2-phase
>>>>>>>> approach.
>>>>>>>> And not to mention integrating things like follow-on fetches and
>>>>>>>> other
>>>>>>>> enhancements we want to gain from this.  My vote is definitely for
>>>>>>>> 3 or
>>>>>>>> more phases of interpretation.  The problem is that this is exactly
>>>>>>>> where
>>>>>>>> Antlr 4 sort of falls down.
>>>>>>>>
>>>>>>>> So first things first... we need to decide on Antlr 3 versus Antlr 4
>>>>>>>> (versus some other parser solution).
>>>>>>>>
>>>>>>>> Next, on the ORM side (every "backend" can decide this
>>>>>>>> individually) we
>>>>>>>> need to decide on the approach for semantic-tree to SQL
>>>>>>>> translation, which
>>>>>>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>>>>>>>>
>>>>>>>> We really need to decide these things ASAP and get moving on them
>>>>>>>> as soon
>>>>>>>> as ORM 5.0 is finished.
>>>>>>>>
>>>>>>>> Also, this is a massive undertaking with huge gain potentials for
>>>>>>>> not just
>>>>>>>> ORM.  As such we need to understand who will be working on this.
>>>>>>>> Sanne,
>>>>>>>> Gunnar... I know y'all have a vested interest and a desire to work
>>>>>>>> on it.
>>>>>>>> John, I know the same is true for you.  Andrea?  Have you had a
>>>>>>>> chance to
>>>>>>>> look over the poc and/or get more familiar with Antlr?
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>

From johara at redhat.com  Mon Aug 24 09:00:11 2015
From: johara at redhat.com (John O'Hara)
Date: Mon, 24 Aug 2015 14:00:11 +0100
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
	<CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
Message-ID: <55DB155B.1000704@redhat.com>

The split makes a lot of sense, should we have another module for the 
criteria query SQM translation?

As we only have one grammar for HQL and JPQL, does jpql come under the 
hibernate-hql-parser-antlr4poc module?


On 21/08/15 21:51, Steve Ebersole wrote:
> Just a heads up that I started a major refactoring of the antlr4 poc 
> project in preparation for starting to look at this next sql-gen step.
>
> First I am making it into a multi-module project.  We will have the 
> hql-parser module, but then also an orm-sql-gen module to be able to 
> play with that part.  This makes sure we are not blending orm concerns 
> into the pure hql parser.
>
> Also, I started working on splitting the "semantic query" model out 
> into a separate module as well.  There are a few reasons for this.  I 
> wont go into them all here.  The main one being that HQL is just one 
> producer of this semantic model. Rather than another long name I went 
> with the acronym SQM (Semantic Query Model) here.  The top package 
> being org.hibernate.sqm.
>
> These changes already illustrated some tighter couplings then I had 
> intended, so it was a good exercise.  I'll push once I get those 
> couplings cleaned up.
>
> On Fri, Aug 21, 2015 at 2:35 PM andrea boriero <dreborier at gmail.com 
> <mailto:dreborier at gmail.com>> wrote:
>
>     I haven't seen it, I'm going to read it.
>
>     On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org
>     <mailto:steve at hibernate.org>> wrote:
>
>         http://www.antlr2.org/article/1170602723163/treewalkers.html
>
>         Not sure if y'all have seen this.  Its an old article
>         advocating manual tree walking (what we are facing here) over
>         using generated tree walkers.
>
>
>
>         On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole
>         <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>
>             I agree.  Its my biggest hang up with regard to using
>             Antlr 4.  Actually, its my only hang up with Antlr 4, but
>             its a huge one.
>
>             On Tue, Aug 18, 2015 at 9:30 AM andrea boriero
>             <dreborier at gmail.com <mailto:dreborier at gmail.com>> wrote:
>
>                 yes Steve I'm more familiar with Antlr4 ( but not 3)
>                 and I gave a look at your poc.
>
>                 Apart some problems to fully understand the semantic
>                 model (due to my lack of a complete knowledge of the
>                 domain problem),
>                 I agree with you about the simplicity and elegance of
>                  the grammar for HQL recognition and semantic model
>                 building.
>
>                 What I don't like it's the necessity to build our own
>                 semantic model walker/s in order to produce the final SQL.
>
>
>
>
>
>
>
>
>                 On 14 August 2015 at 16:32, Steve Ebersole
>                 <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>
>                     We've had a few discussions about this in the
>                     past.  As 5.0 is getting
>                     close to Final (next week), its time to start
>                     contemplating our next major
>                     tasks.  The consensus pick for that has been the
>                     idea of a "unified SQL
>                     generation engine" along with a shared project for
>                     the semantic analysis of
>                     HQL/JPQL (and recently it was decided to include
>                     JPA Criteria
>                     interpretation here as well).
>
>                     The central premise is this.  Take the roughly 6
>                     or 7 different top-level
>                     ways Hibernate generates SQL and combine that into
>                     one "engine" based on
>                     the input of a "semantic tree".  The mentioned
>                     HQL/JPQL/Criteria shared
>                     project will be one producer of such semantic
>                     trees.  Others would include
>                     persisters (for insert/update/delete requests) and
>                     loaders (for load
>                     requests).
>
>                     We have a lot of tasks for this overall goal still
>                     remaining.
>
>                     We still have to finalize the design for the
>                     HQL/JPQL/Criteria to semantic
>                     tree translator.  One option is to proceed with
>                     the Antlr 4 based approach
>                     I started a PoC for.  John has been helping me
>                     some lately with that.  The
>                     first task here is to come to a consensus whether
>                     Antlr 4 is the way we
>                     want to proceed here.  We've been over the pros
>                     and cons before in detail.
>                     In summary, there is a lot to love with Antlr 4. 
>                     Our grammar for HQL
>                     recognition and semantic tree building is very
>                     simple and elegant imo.  The
>                     drawback is clearly the lack of tree walking,
>                     meaning that we are
>                     responsible for writing by hand our walker for the
>                     semantic tree.  In fact
>                     multiple, since each consumer (orm, ogm, search)
>                     would need to write their
>                     own.  And if we decide to build another AST while
>                     walking the semantic
>                     tree, we'd end up having to hand-write yet another
>                     walker for those.
>
>                     What I mean by that last part is that there are 2
>                     ways we might choose to
>                     deal with the semantic tree.  For the purpose of
>                     discussion, let's look at
>                     the ORM case.  The first approach is to simply
>                     generate the SQL as we walk
>                     the semantic tree; this would be a 2 phase
>                     interpretation approach (input
>                     -> semantic tree -> SQL).  That works in many
>                     cases.  However it breaks
>                     down in other cases.  This is exactly the approach
>                     our existing HQL
>                     translator uses.  The other approach is to use a
>                     3-phase translation (input
>                     -> semantic-tree -> semantic-SQL-tree(s) -> SQL). 
>                     This gives a hint to one
>                     of the major problems.  One source "semantic"
>                     query will often correspond
>                     to multiple SQL queries; that is hard to manage in
>                     the 2-phase approach.
>                     And not to mention integrating things like
>                     follow-on fetches and other
>                     enhancements we want to gain from this.  My vote
>                     is definitely for 3 or
>                     more phases of interpretation.  The problem is
>                     that this is exactly where
>                     Antlr 4 sort of falls down.
>
>                     So first things first... we need to decide on
>                     Antlr 3 versus Antlr 4
>                     (versus some other parser solution).
>
>                     Next, on the ORM side (every "backend" can decide
>                     this individually) we
>                     need to decide on the approach for semantic-tree
>                     to SQL translation, which
>                     somewhat depends on the Antlr 3 versus Antlr 4
>                     decision.
>
>                     We really need to decide these things ASAP and get
>                     moving on them as soon
>                     as ORM 5.0 is finished.
>
>                     Also, this is a massive undertaking with huge gain
>                     potentials for not just
>                     ORM.  As such we need to understand who will be
>                     working on this.  Sanne,
>                     Gunnar... I know y'all have a vested interest and
>                     a desire to work on it.
>                     John, I know the same is true for you.  Andrea? 
>                     Have you had a chance to
>                     look over the poc and/or get more familiar with Antlr?
>
>                     _______________________________________________
>                     hibernate-dev mailing list
>                     hibernate-dev at lists.jboss.org
>                     <mailto:hibernate-dev at lists.jboss.org>
>                     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>


-- 
John O'Hara
johara at redhat.com

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


From gunnar at hibernate.org  Mon Aug 24 09:11:09 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 24 Aug 2015 15:11:09 +0200
Subject: [hibernate-dev] Published ORM docs partly still at CR2
Message-ID: <CADGJaX9K5GNXr6yp7KCJ20c6z+=0ZixNk-6DFxBEVZ4LQTrrBQ@mail.gmail.com>

Hi,

the docs at

* http://docs.jboss.org/hibernate/orm/5.0/devguide/en-US/html_single/ and
* http://docs.jboss.org/hibernate/orm/5.0/manual/en-US/html_single/

still say they represent CR 2. Not sure what has changed since then,
but seeing "5.0.0.Final" there would be nice :)

Thanks,

--Gunnar

From steve at hibernate.org  Mon Aug 24 09:49:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 24 Aug 2015 13:49:27 +0000
Subject: [hibernate-dev] Published ORM docs partly still at CR2
In-Reply-To: <CADGJaX9K5GNXr6yp7KCJ20c6z+=0ZixNk-6DFxBEVZ4LQTrrBQ@mail.gmail.com>
References: <CADGJaX9K5GNXr6yp7KCJ20c6z+=0ZixNk-6DFxBEVZ4LQTrrBQ@mail.gmail.com>
Message-ID: <CAFdSV9tL_W4fUbtMoRrpaUZaCHvB8y15XciNS1JbryV6Q1eM9A@mail.gmail.com>

Those are the old docs.  The rsync is unfortunately just not deleting them
and afaik we have no way to ssh in there to clean them up.

On Mon, Aug 24, 2015 at 8:11 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> the docs at
>
> * http://docs.jboss.org/hibernate/orm/5.0/devguide/en-US/html_single/ and
> * http://docs.jboss.org/hibernate/orm/5.0/manual/en-US/html_single/
>
> still say they represent CR 2. Not sure what has changed since then,
> but seeing "5.0.0.Final" there would be nice :)
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Aug 24 09:52:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 24 Aug 2015 13:52:06 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <55DB155B.1000704@redhat.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
	<CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
	<55DB155B.1000704@redhat.com>
Message-ID: <CAFdSV9uhKoOVvOjfAnOH6-PDPzSmpJM1R4GqjRvM5WrNN0QFow@mail.gmail.com>

On Mon, Aug 24, 2015 at 8:00 AM John O'Hara <johara at redhat.com> wrote:

> The split makes a lot of sense, should we have another module for the
> criteria query SQM translation?
>

I personally think that makes no sense to do.


As we only have one grammar for HQL and JPQL, does jpql come under the
> hibernate-hql-parser-antlr4poc module?
>

I am not sure what you are asking.  "Come under"?

From steve at hibernate.org  Mon Aug 24 10:04:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 24 Aug 2015 14:04:11 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9uhKoOVvOjfAnOH6-PDPzSmpJM1R4GqjRvM5WrNN0QFow@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
	<CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
	<55DB155B.1000704@redhat.com>
	<CAFdSV9uhKoOVvOjfAnOH6-PDPzSmpJM1R4GqjRvM5WrNN0QFow@mail.gmail.com>
Message-ID: <CAFdSV9vVF9y=HV3PXeH_SO1t4mSvmaM-jp35TrgRbVxVkpu-Kg@mail.gmail.com>

Another thing I think we ought to consider longer term is to replace the
contracts in the org.hibernate.sqm.domain package with
the javax.persistence.metamodel JPA model.

However, for ORM we cannot do that yet due to a major prerequisite.
Basically that would require the "melding" of hibernate-core and
hibernate-entitymanager into a single module and having, e.g., persisters
and types understand/implement the JPA contracts.


On Mon, Aug 24, 2015 at 8:52 AM Steve Ebersole <steve at hibernate.org> wrote:

> On Mon, Aug 24, 2015 at 8:00 AM John O'Hara <johara at redhat.com> wrote:
>
>> The split makes a lot of sense, should we have another module for the
>> criteria query SQM translation?
>>
>
> I personally think that makes no sense to do.
>
>
> As we only have one grammar for HQL and JPQL, does jpql come under the
>> hibernate-hql-parser-antlr4poc module?
>>
>
> I am not sure what you are asking.  "Come under"?
>

From smarlow at redhat.com  Mon Aug 24 10:07:35 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 24 Aug 2015 10:07:35 -0400
Subject: [hibernate-dev] ORM 5.0 Final - delayed
In-Reply-To: <55D5E525.1050809@redhat.com>
References: <CAFdSV9tXyk0v-FaeqiyUUAR4Tw3Zid+3BQeJ18WKNGxxScZRxQ@mail.gmail.com>
	<55D5E525.1050809@redhat.com>
Message-ID: <55DB2527.8070701@redhat.com>


On 08/20/2015 10:33 AM, Scott Marlow wrote:
> Please let me know if you want me to do any testing before the release.

Passed testing and merged into WildFly 10.0.0.Beta2.
>
> On 08/19/2015 02:34 PM, Steve Ebersole wrote:
>> I am going to delay releasing 5.0 Final until tomorrow at earliest.  The CI
>> server is having some massive trouble at the moment and I'd prefer to make
>> sure that we are getting clean builds there before I start the release.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From brett at hibernate.org  Mon Aug 24 10:24:41 2015
From: brett at hibernate.org (Brett Meyer)
Date: Mon, 24 Aug 2015 10:24:41 -0400
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAL00eSQ-pXqK1w3nb-E1aiRFF5BxsG2+XrqkqX9f4EV7AApg_w@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>	<CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>	<CAFdSV9sBHDqrNkhkAMn0=v=_x_vK=aD+1iU4QyrwzmFPSZj3jA@mail.gmail.com>	<CAFdSV9sQ3UvRTnLWp=x91gNCnrOBi1VHQs6LdhbbESZ-2q4EYw@mail.gmail.com>
	<CAL00eSQ-pXqK1w3nb-E1aiRFF5BxsG2+XrqkqX9f4EV7AApg_w@mail.gmail.com>
Message-ID: <55DB2929.20608@hibernate.org>

In practice, when are unmapped inheritance queries typically used?  I 
tend to see them only for bulk deletions, IIRC.  But in general, I'd 
assume they're a product of "doing something incorrectly", especially if 
the query includes more than one. On 08/24/2015 08:40 AM, andrea boriero 
wrote:
>   I have nothing against your proposal so +1
>
> On 24 August 2015 at 04:55, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Another point I want to discuss up from because it affects tree
>> structure.  Specifically the idea of an "unbounded implicit inheritance"
>> query.  These are queries like "from java.lang.Object".  Queries where the
>> from clause pulls in "unmapped inheritance".  These are fine, to an
>> extent.  Hibernate has natively supported these since way back[1].
>>
>> What is problematic is cases where we have more than one "unmapped
>> inheritance" reference.  E.g. "from java.lang.Object o1, java.lang.Object
>> o2".  In fact its the same difficulty as an unbounded cartesian product,
>> but here in terms of the number of SQL queries we need to produce/execute.
>>
>> So I propose that we allow just one "unmapped inheritance" reference per
>> query.
>>
>> [1] Reminder to self... another "strict JPQL compliance" consideration.
>>
>> On Sat, Aug 22, 2015 at 1:16 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I got that initial refactoring pushed to my fork...
>>>
>>> On Fri, Aug 21, 2015 at 3:51 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Just a heads up that I started a major refactoring of the antlr4 poc
>>>> project in preparation for starting to look at this next sql-gen step.
>>>>
>>>> First I am making it into a multi-module project.  We will have the
>>>> hql-parser module, but then also an orm-sql-gen module to be able to play
>>>> with that part.  This makes sure we are not blending orm concerns into the
>>>> pure hql parser.
>>>>
>>>> Also, I started working on splitting the "semantic query" model out into
>>>> a separate module as well.  There are a few reasons for this.  I wont go
>>>> into them all here.  The main one being that HQL is just one producer of
>>>> this semantic model.   Rather than another long name I went with the
>>>> acronym SQM (Semantic Query Model) here.  The top package being
>>>> org.hibernate.sqm.
>>>>
>>>> These changes already illustrated some tighter couplings then I had
>>>> intended, so it was a good exercise.  I'll push once I get those couplings
>>>> cleaned up.
>>>>
>>>> On Fri, Aug 21, 2015 at 2:35 PM andrea boriero <dreborier at gmail.com>
>>>> wrote:
>>>>
>>>>> I haven't seen it, I'm going to read it.
>>>>>
>>>>> On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:
>>>>>
>>>>>> http://www.antlr2.org/article/1170602723163/treewalkers.html
>>>>>>
>>>>>> Not sure if y'all have seen this.  Its an old article advocating
>>>>>> manual tree walking (what we are facing here) over using generated tree
>>>>>> walkers.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> I agree.  Its my biggest hang up with regard to using Antlr 4.
>>>>>>> Actually, its my only hang up with Antlr 4, but its a huge one.
>>>>>>>
>>>>>>> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <dreborier at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a
>>>>>>>> look at your poc.
>>>>>>>>
>>>>>>>> Apart some problems to fully understand the semantic model (due to
>>>>>>>> my lack of a complete knowledge of the domain problem),
>>>>>>>> I agree with you about the simplicity and elegance of  the grammar
>>>>>>>> for HQL recognition and semantic model building.
>>>>>>>>
>>>>>>>> What I don't like it's the necessity to build our own semantic model
>>>>>>>> walker/s in order to produce the final SQL.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> We've had a few discussions about this in the past.  As 5.0 is
>>>>>>>>> getting
>>>>>>>>> close to Final (next week), its time to start contemplating our
>>>>>>>>> next major
>>>>>>>>> tasks.  The consensus pick for that has been the idea of a "unified
>>>>>>>>> SQL
>>>>>>>>> generation engine" along with a shared project for the semantic
>>>>>>>>> analysis of
>>>>>>>>> HQL/JPQL (and recently it was decided to include JPA Criteria
>>>>>>>>> interpretation here as well).
>>>>>>>>>
>>>>>>>>> The central premise is this.  Take the roughly 6 or 7 different
>>>>>>>>> top-level
>>>>>>>>> ways Hibernate generates SQL and combine that into one "engine"
>>>>>>>>> based on
>>>>>>>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria
>>>>>>>>> shared
>>>>>>>>> project will be one producer of such semantic trees.  Others would
>>>>>>>>> include
>>>>>>>>> persisters (for insert/update/delete requests) and loaders (for load
>>>>>>>>> requests).
>>>>>>>>>
>>>>>>>>> We have a lot of tasks for this overall goal still remaining.
>>>>>>>>>
>>>>>>>>> We still have to finalize the design for the HQL/JPQL/Criteria to
>>>>>>>>> semantic
>>>>>>>>> tree translator.  One option is to proceed with the Antlr 4 based
>>>>>>>>> approach
>>>>>>>>> I started a PoC for.  John has been helping me some lately with
>>>>>>>>> that.  The
>>>>>>>>> first task here is to come to a consensus whether Antlr 4 is the
>>>>>>>>> way we
>>>>>>>>> want to proceed here.  We've been over the pros and cons before in
>>>>>>>>> detail.
>>>>>>>>> In summary, there is a lot to love with Antlr 4.  Our grammar for
>>>>>>>>> HQL
>>>>>>>>> recognition and semantic tree building is very simple and elegant
>>>>>>>>> imo.  The
>>>>>>>>> drawback is clearly the lack of tree walking, meaning that we are
>>>>>>>>> responsible for writing by hand our walker for the semantic tree.
>>>>>>>>> In fact
>>>>>>>>> multiple, since each consumer (orm, ogm, search) would need to
>>>>>>>>> write their
>>>>>>>>> own.  And if we decide to build another AST while walking the
>>>>>>>>> semantic
>>>>>>>>> tree, we'd end up having to hand-write yet another walker for those.
>>>>>>>>>
>>>>>>>>> What I mean by that last part is that there are 2 ways we might
>>>>>>>>> choose to
>>>>>>>>> deal with the semantic tree.  For the purpose of discussion, let's
>>>>>>>>> look at
>>>>>>>>> the ORM case.  The first approach is to simply generate the SQL as
>>>>>>>>> we walk
>>>>>>>>> the semantic tree; this would be a 2 phase interpretation approach
>>>>>>>>> (input
>>>>>>>>> -> semantic tree -> SQL).  That works in many cases.  However it
>>>>>>>>> breaks
>>>>>>>>> down in other cases.  This is exactly the approach our existing HQL
>>>>>>>>> translator uses.  The other approach is to use a 3-phase
>>>>>>>>> translation (input
>>>>>>>>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a
>>>>>>>>> hint to one
>>>>>>>>> of the major problems.  One source "semantic" query will often
>>>>>>>>> correspond
>>>>>>>>> to multiple SQL queries; that is hard to manage in the 2-phase
>>>>>>>>> approach.
>>>>>>>>> And not to mention integrating things like follow-on fetches and
>>>>>>>>> other
>>>>>>>>> enhancements we want to gain from this.  My vote is definitely for
>>>>>>>>> 3 or
>>>>>>>>> more phases of interpretation.  The problem is that this is exactly
>>>>>>>>> where
>>>>>>>>> Antlr 4 sort of falls down.
>>>>>>>>>
>>>>>>>>> So first things first... we need to decide on Antlr 3 versus Antlr 4
>>>>>>>>> (versus some other parser solution).
>>>>>>>>>
>>>>>>>>> Next, on the ORM side (every "backend" can decide this
>>>>>>>>> individually) we
>>>>>>>>> need to decide on the approach for semantic-tree to SQL
>>>>>>>>> translation, which
>>>>>>>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
>>>>>>>>>
>>>>>>>>> We really need to decide these things ASAP and get moving on them
>>>>>>>>> as soon
>>>>>>>>> as ORM 5.0 is finished.
>>>>>>>>>
>>>>>>>>> Also, this is a massive undertaking with huge gain potentials for
>>>>>>>>> not just
>>>>>>>>> ORM.  As such we need to understand who will be working on this.
>>>>>>>>> Sanne,
>>>>>>>>> Gunnar... I know y'all have a vested interest and a desire to work
>>>>>>>>> on it.
>>>>>>>>> John, I know the same is true for you.  Andrea?  Have you had a
>>>>>>>>> chance to
>>>>>>>>> look over the poc and/or get more familiar with Antlr?
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>>> hibernate-dev mailing list
>>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>>
>>>>>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Mon Aug 24 10:39:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 24 Aug 2015 14:39:58 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <55DB2929.20608@hibernate.org>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CAL00eSRo=kPBkrzquBg=KHHCBZ5w7pMS9+HQ53Hx-uz=Q2rypA@mail.gmail.com>
	<CAFdSV9v4Nz-3O25tvX7YVkDWHqA8mVqytDHFj95uJ2wTX1tt6A@mail.gmail.com>
	<CAFdSV9sC2tagc_44qbHMrsJ4r6JfKrxHNKKHXfiHTrqzNRifjw@mail.gmail.com>
	<CAL00eSQtvmFA6wNPx=JsaOAxUC6ZOYPyuBJ5GVck=p1rgJavSA@mail.gmail.com>
	<CAFdSV9u2fRW01caDRV3e3whDi_FFiWptACBNMJYG2EJfUSMPng@mail.gmail.com>
	<CAFdSV9sBHDqrNkhkAMn0=v=_x_vK=aD+1iU4QyrwzmFPSZj3jA@mail.gmail.com>
	<CAFdSV9sQ3UvRTnLWp=x91gNCnrOBi1VHQs6LdhbbESZ-2q4EYw@mail.gmail.com>
	<CAL00eSQ-pXqK1w3nb-E1aiRFF5BxsG2+XrqkqX9f4EV7AApg_w@mail.gmail.com>
	<55DB2929.20608@hibernate.org>
Message-ID: <CAFdSV9sD-C0jGwRjQCUdjJKXoeVFH+cjqft1U39Rzzq7SB7Npg@mail.gmail.com>

I agree in the case where "the query includes more than one".  However,
there are definitely valid uses for these.

Consider this case e.g...

interface Auditable {
    String createdBy;
    Instant createdAt;
    String updatedBy;
    Instant updatedAt;
}

@Entity
class Account implements Auditable {
    ...
}

@Entity
class Fund implements Auditable {
    ...
}

etc.

And a query to get all records created by a person within a date range:

"from Auditable a where a.createdBy = :person and a.createdAt between
:start and :end"

Is a perfectly valid (and useful!) query.



On Mon, Aug 24, 2015 at 9:25 AM Brett Meyer <brett at hibernate.org> wrote:

> In practice, when are unmapped inheritance queries typically used?  I
> tend to see them only for bulk deletions, IIRC.  But in general, I'd
> assume they're a product of "doing something incorrectly", especially if
> the query includes more than one. On 08/24/2015 08:40 AM, andrea boriero
> wrote:
> >   I have nothing against your proposal so +1
> >
> > On 24 August 2015 at 04:55, Steve Ebersole <steve at hibernate.org> wrote:
> >
> >> Another point I want to discuss up from because it affects tree
> >> structure.  Specifically the idea of an "unbounded implicit inheritance"
> >> query.  These are queries like "from java.lang.Object".  Queries where
> the
> >> from clause pulls in "unmapped inheritance".  These are fine, to an
> >> extent.  Hibernate has natively supported these since way back[1].
> >>
> >> What is problematic is cases where we have more than one "unmapped
> >> inheritance" reference.  E.g. "from java.lang.Object o1,
> java.lang.Object
> >> o2".  In fact its the same difficulty as an unbounded cartesian product,
> >> but here in terms of the number of SQL queries we need to
> produce/execute.
> >>
> >> So I propose that we allow just one "unmapped inheritance" reference per
> >> query.
> >>
> >> [1] Reminder to self... another "strict JPQL compliance" consideration.
> >>
> >> On Sat, Aug 22, 2015 at 1:16 PM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> I got that initial refactoring pushed to my fork...
> >>>
> >>> On Fri, Aug 21, 2015 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>>
> >>>> Just a heads up that I started a major refactoring of the antlr4 poc
> >>>> project in preparation for starting to look at this next sql-gen step.
> >>>>
> >>>> First I am making it into a multi-module project.  We will have the
> >>>> hql-parser module, but then also an orm-sql-gen module to be able to
> play
> >>>> with that part.  This makes sure we are not blending orm concerns
> into the
> >>>> pure hql parser.
> >>>>
> >>>> Also, I started working on splitting the "semantic query" model out
> into
> >>>> a separate module as well.  There are a few reasons for this.  I wont
> go
> >>>> into them all here.  The main one being that HQL is just one producer
> of
> >>>> this semantic model.   Rather than another long name I went with the
> >>>> acronym SQM (Semantic Query Model) here.  The top package being
> >>>> org.hibernate.sqm.
> >>>>
> >>>> These changes already illustrated some tighter couplings then I had
> >>>> intended, so it was a good exercise.  I'll push once I get those
> couplings
> >>>> cleaned up.
> >>>>
> >>>> On Fri, Aug 21, 2015 at 2:35 PM andrea boriero <dreborier at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> I haven't seen it, I'm going to read it.
> >>>>>
> >>>>> On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>>>
> >>>>>> http://www.antlr2.org/article/1170602723163/treewalkers.html
> >>>>>>
> >>>>>> Not sure if y'all have seen this.  Its an old article advocating
> >>>>>> manual tree walking (what we are facing here) over using generated
> tree
> >>>>>> walkers.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <
> steve at hibernate.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I agree.  Its my biggest hang up with regard to using Antlr 4.
> >>>>>>> Actually, its my only hang up with Antlr 4, but its a huge one.
> >>>>>>>
> >>>>>>> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <
> dreborier at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a
> >>>>>>>> look at your poc.
> >>>>>>>>
> >>>>>>>> Apart some problems to fully understand the semantic model (due to
> >>>>>>>> my lack of a complete knowledge of the domain problem),
> >>>>>>>> I agree with you about the simplicity and elegance of  the grammar
> >>>>>>>> for HQL recognition and semantic model building.
> >>>>>>>>
> >>>>>>>> What I don't like it's the necessity to build our own semantic
> model
> >>>>>>>> walker/s in order to produce the final SQL.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> We've had a few discussions about this in the past.  As 5.0 is
> >>>>>>>>> getting
> >>>>>>>>> close to Final (next week), its time to start contemplating our
> >>>>>>>>> next major
> >>>>>>>>> tasks.  The consensus pick for that has been the idea of a
> "unified
> >>>>>>>>> SQL
> >>>>>>>>> generation engine" along with a shared project for the semantic
> >>>>>>>>> analysis of
> >>>>>>>>> HQL/JPQL (and recently it was decided to include JPA Criteria
> >>>>>>>>> interpretation here as well).
> >>>>>>>>>
> >>>>>>>>> The central premise is this.  Take the roughly 6 or 7 different
> >>>>>>>>> top-level
> >>>>>>>>> ways Hibernate generates SQL and combine that into one "engine"
> >>>>>>>>> based on
> >>>>>>>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria
> >>>>>>>>> shared
> >>>>>>>>> project will be one producer of such semantic trees.  Others
> would
> >>>>>>>>> include
> >>>>>>>>> persisters (for insert/update/delete requests) and loaders (for
> load
> >>>>>>>>> requests).
> >>>>>>>>>
> >>>>>>>>> We have a lot of tasks for this overall goal still remaining.
> >>>>>>>>>
> >>>>>>>>> We still have to finalize the design for the HQL/JPQL/Criteria to
> >>>>>>>>> semantic
> >>>>>>>>> tree translator.  One option is to proceed with the Antlr 4 based
> >>>>>>>>> approach
> >>>>>>>>> I started a PoC for.  John has been helping me some lately with
> >>>>>>>>> that.  The
> >>>>>>>>> first task here is to come to a consensus whether Antlr 4 is the
> >>>>>>>>> way we
> >>>>>>>>> want to proceed here.  We've been over the pros and cons before
> in
> >>>>>>>>> detail.
> >>>>>>>>> In summary, there is a lot to love with Antlr 4.  Our grammar for
> >>>>>>>>> HQL
> >>>>>>>>> recognition and semantic tree building is very simple and elegant
> >>>>>>>>> imo.  The
> >>>>>>>>> drawback is clearly the lack of tree walking, meaning that we are
> >>>>>>>>> responsible for writing by hand our walker for the semantic tree.
> >>>>>>>>> In fact
> >>>>>>>>> multiple, since each consumer (orm, ogm, search) would need to
> >>>>>>>>> write their
> >>>>>>>>> own.  And if we decide to build another AST while walking the
> >>>>>>>>> semantic
> >>>>>>>>> tree, we'd end up having to hand-write yet another walker for
> those.
> >>>>>>>>>
> >>>>>>>>> What I mean by that last part is that there are 2 ways we might
> >>>>>>>>> choose to
> >>>>>>>>> deal with the semantic tree.  For the purpose of discussion,
> let's
> >>>>>>>>> look at
> >>>>>>>>> the ORM case.  The first approach is to simply generate the SQL
> as
> >>>>>>>>> we walk
> >>>>>>>>> the semantic tree; this would be a 2 phase interpretation
> approach
> >>>>>>>>> (input
> >>>>>>>>> -> semantic tree -> SQL).  That works in many cases.  However it
> >>>>>>>>> breaks
> >>>>>>>>> down in other cases.  This is exactly the approach our existing
> HQL
> >>>>>>>>> translator uses.  The other approach is to use a 3-phase
> >>>>>>>>> translation (input
> >>>>>>>>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a
> >>>>>>>>> hint to one
> >>>>>>>>> of the major problems.  One source "semantic" query will often
> >>>>>>>>> correspond
> >>>>>>>>> to multiple SQL queries; that is hard to manage in the 2-phase
> >>>>>>>>> approach.
> >>>>>>>>> And not to mention integrating things like follow-on fetches and
> >>>>>>>>> other
> >>>>>>>>> enhancements we want to gain from this.  My vote is definitely
> for
> >>>>>>>>> 3 or
> >>>>>>>>> more phases of interpretation.  The problem is that this is
> exactly
> >>>>>>>>> where
> >>>>>>>>> Antlr 4 sort of falls down.
> >>>>>>>>>
> >>>>>>>>> So first things first... we need to decide on Antlr 3 versus
> Antlr 4
> >>>>>>>>> (versus some other parser solution).
> >>>>>>>>>
> >>>>>>>>> Next, on the ORM side (every "backend" can decide this
> >>>>>>>>> individually) we
> >>>>>>>>> need to decide on the approach for semantic-tree to SQL
> >>>>>>>>> translation, which
> >>>>>>>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
> >>>>>>>>>
> >>>>>>>>> We really need to decide these things ASAP and get moving on them
> >>>>>>>>> as soon
> >>>>>>>>> as ORM 5.0 is finished.
> >>>>>>>>>
> >>>>>>>>> Also, this is a massive undertaking with huge gain potentials for
> >>>>>>>>> not just
> >>>>>>>>> ORM.  As such we need to understand who will be working on this.
> >>>>>>>>> Sanne,
> >>>>>>>>> Gunnar... I know y'all have a vested interest and a desire to
> work
> >>>>>>>>> on it.
> >>>>>>>>> John, I know the same is true for you.  Andrea?  Have you had a
> >>>>>>>>> chance to
> >>>>>>>>> look over the poc and/or get more familiar with Antlr?
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>>> hibernate-dev mailing list
> >>>>>>>>> hibernate-dev at lists.jboss.org
> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>>>
> >>>>>>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From daltodavide at gmail.com  Mon Aug 24 11:53:06 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Mon, 24 Aug 2015 16:53:06 +0100
Subject: [hibernate-dev] 2 CI slaves down
Message-ID: <CANoTJYNU61Sat7qKS-9idzvBjwa6QZs=1hbKpi-cxMthqk8L-A@mail.gmail.com>

Hi,
2 of the 4 slaves we use for CI are currently down.

Not sure what's the cause but I'm working on it.

Cheers,
Davide

From steve at hibernate.org  Mon Aug 24 23:12:12 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 25 Aug 2015 03:12:12 +0000
Subject: [hibernate-dev] Query Parser Redesign
Message-ID: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>

Andrea, this is in relation to something you asked me on IRC today.
Specifically in regards to FromClause and the fact that it maintains
pointers to parent/children.  As I said on IRC there is no intrinsic need
(I do not foresee) for keeping this structure; I really only did that
because FromCauseProcessor needed a stack of FromClauses and the FromClause
itself made a simple place to do that.

However, in later work I ran into minor problems because of that decision.
I need to make a copy of an entire SelectStatement tree.  But because the
FromClause is held twice (for non-root FromClauses) in the tree, it makes
it more complicated to do a "simple copy" than it need be.  Basically I
need to maintain a "Map<FromClause,FromClause> copy Map" :(

Long story short, I think I might revisit that decision and instead write a
dedicated stack in FromClauseProcessor for this.  In the morning... its too
late to start something that ambitious tonight.  I'll start that in the
morning, unless someone wants to pick that up in the next few hours before
I get back on line.

From gunnar at hibernate.org  Tue Aug 25 02:47:24 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 25 Aug 2015 08:47:24 +0200
Subject: [hibernate-dev] [HSEARCH] Wrong query results when embedding
	*-to-many associations
Message-ID: <CADGJaX-4o1k1HBEGdSEWPz+aHnSTE59sBmF1=USE--vD21nDtQ@mail.gmail.com>

Hi,

in the forum [1] a user runs into a variant of the old problem where
boolean searches on different fields of the elements of an embedded
association return wrong results due to hits in different elements of
the collections.

What is our recommendation/answer to this type of question? I've seen
it popping up several times, it seems to be a common trap for users.
Having an FAQ entry for this would be nice.

ES btw. nicely avoids this by storing nested objects in separate
"hidden" documents [2]. This allows to run queries without getting
results from different collection elements. It'd be a nice addition to
do something similar in HSEARCH?

Thanks,

--Gunnar

[1] https://forum.hibernate.org/viewtopic.php?f=9&t=1041259
[2] https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-nested-type.html

From gunnar at hibernate.org  Tue Aug 25 03:10:33 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 25 Aug 2015 09:10:33 +0200
Subject: [hibernate-dev] SEO ranking of ORM docs
In-Reply-To: <CADGJaX9EKfJeU3xXoJ3ijX14cN+6VuxhBKZJ3fzKnn5uq0W=Eg@mail.gmail.com>
References: <CADGJaX9EKfJeU3xXoJ3ijX14cN+6VuxhBKZJ3fzKnn5uq0W=Eg@mail.gmail.com>
Message-ID: <CADGJaX_orBEbjZJztiT6Z0=Z=vg9Wncr3_KBFruZMhyPYN3LaA@mail.gmail.com>

Hi,

It's still bugging me that ORM 3.x documentation regular shows up as
the top result in searches. With the docs being revamped for 5 it
seems like the right timing to make sure results from
https://docs.jboss.org/hibernate/stable/orm/... show up there first.

My SEO knowledge is close to none, but surely there is a way to
achieve this. Does anyone either know how to do it or know someone who
may help us with it? The new docs are great but it'd be a pity if
users can't find them easily.

Cheers,

--Gunnar



2015-04-08 16:50 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> Hi,
>
> When searching the web for things around Hibernate ORM, I often find 3.x
> documents as the top result. E.g. searching for "hibernate inheritance" on
> Google returns
> https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/inheritance.html
> as the first result.
>
> Instead it would be nice to see
> https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch10.html there
> (or some other up-to-date docs containing the relevant information), i.e.
> docs from the latest stable release.
>
> I have no idea really what would have to be done to achieve that. But maybe
> someone else knows the right knobs to turn?
>
> Cheers,
>
> --Gunnar
>

From hardy at hibernate.org  Tue Aug 25 03:43:35 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 25 Aug 2015 09:43:35 +0200
Subject: [hibernate-dev] [HSEARCH] Wrong query results when embedding
 *-to-many associations
In-Reply-To: <CADGJaX-4o1k1HBEGdSEWPz+aHnSTE59sBmF1=USE--vD21nDtQ@mail.gmail.com>
References: <CADGJaX-4o1k1HBEGdSEWPz+aHnSTE59sBmF1=USE--vD21nDtQ@mail.gmail.com>
Message-ID: <20150825074335.GB61135@Nineveh.lan>

> in the forum [1] a user runs into a variant of the old problem where
> boolean searches on different fields of the elements of an embedded
> association return wrong results due to hits in different elements of
> the collections.
> 
> What is our recommendation/answer to this type of question? I've seen
> it popping up several times, it seems to be a common trap for users.
> Having an FAQ entry for this would be nice.

I don't think the answer is "it depends" ;-)
I guess there are two main strategies:

#1 Use a custom field bridge in which you can index a combination of fields.
   Target this field when querying
#2 Turn the problem around. In many cases both entities (the entity holding  
   the association as well as the associated entity) are indexed. Target the
   associated entity with your query and navigate via the relation (provided 
   it is bi-directional) to the "parent" entity.

I think a FAQ entry makes sense, maybe with a more detailed example and description.
Or it could be added to the docs itself as a note to association querying.

> ES btw. nicely avoids this by storing nested objects in separate
> "hidden" documents [2]. This allows to run queries without getting
> results from different collection elements. It'd be a nice addition to
> do something similar in HSEARCH?

It would be an interesting feature indeed. I would imagine though that implementing 
it using additional Document instances could be quite tricky from our side.
The whole engine is based around the concept of single Document per entity. Also
the query part would need changing/extending.

I would think that ES uses query time joins for that [1]. We have multiple issues
for making use of query time joins as well - HSEARCH-1631 [2], HSEARCH-1237 [3].
I guess one would need to start with thinking through how this would work from
a configuration point of view and which changes are then required in the engine.

IMO this would be a high value feature (much higher than others we keep discussing).

--Hardy


[1] http://blog.trifork.com/2012/01/22/query-time-joining-in-lucene/
[2] https://hibernate.atlassian.net/browse/HSEARCH-1631
[3] https://hibernate.atlassian.net/browse/HSEARCH-1237
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150825/f4b2b0d8/attachment.bin 

From gunnar at hibernate.org  Tue Aug 25 06:24:21 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 25 Aug 2015 12:24:21 +0200
Subject: [hibernate-dev] Search/Validator: Deleting old release files on
	hibernate.org
Message-ID: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>

Sanne, Hardy,

Can we delete all the non-displayed release files from
https://github.com/hibernate/hibernate.org/tree/staging/_data/projects
for Search and Validator?

Fetching them takes a considerable time in the website build and I
don't think they are needed any longer once set to display=false and a
subsequent release has been done.

Thanks,

--Gunnar

From gunnar at hibernate.org  Tue Aug 25 06:34:13 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 25 Aug 2015 12:34:13 +0200
Subject: [hibernate-dev] Hibernate OGM 5.0.0.Alpha1 is out,
 bringing Redis support, update to Hibernate ORM 5 etc.
Message-ID: <CADGJaX_8v7UVgb09Hs4YCvpDocGQGN5aTnB3ZewVOFNkUQ9NLg@mail.gmail.com>

Hi,

It?s my pleasure to announce the first Alpha release of Hibernate OGM 5.

This release is based on Hibernate ORM 5. It brings experimental
support for the Redis key/value support, mapping improvements, updates
to the MongoDB driver 3.0 and much more.

Check out the full release announcement [1] for all the details.

Cheers,

--Gunnar

[1] http://in.relation.to/2015/08/24/redis-support-hibernate-orm5-update-hibernate-ogm-50-alpha1-released/


From hardy at hibernate.org  Tue Aug 25 07:02:43 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 25 Aug 2015 13:02:43 +0200
Subject: [hibernate-dev] Search/Validator: Deleting old release files on
 hibernate.org
In-Reply-To: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>
References: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>
Message-ID: <20150825110243.GC61135@Nineveh.lan>

Hi,

On Tue, Aug 25, 2015 at 12:24:21PM +0200, Gunnar Morling wrote:
> Can we delete all the non-displayed release files from
> https://github.com/hibernate/hibernate.org/tree/staging/_data/projects
> for Search and Validator?

+1 I can take care of this. I noticed the time it takes as well.
I kind of liked the idea of keeping the files and there are other
things we could do to fix it, but I agree that deleting them is
the simplest solution.


--Hardy

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

From davide at hibernate.org  Tue Aug 25 07:06:43 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Tue, 25 Aug 2015 12:06:43 +0100
Subject: [hibernate-dev] Search/Validator: Deleting old release files on
	hibernate.org
In-Reply-To: <20150825110243.GC61135@Nineveh.lan>
References: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>
	<20150825110243.GC61135@Nineveh.lan>
Message-ID: <CANoTJYNNqdW9QjZ+KuFVK3ZVXkBW1A57y-LD33XaNtuVtP-xRw@mail.gmail.com>

Can't we just move them into an archive folder?

On Tue, Aug 25, 2015 at 12:02 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> On Tue, Aug 25, 2015 at 12:24:21PM +0200, Gunnar Morling wrote:
> > Can we delete all the non-displayed release files from
> > https://github.com/hibernate/hibernate.org/tree/staging/_data/projects
> > for Search and Validator?
>
> +1 I can take care of this. I noticed the time it takes as well.
> I kind of liked the idea of keeping the files and there are other
> things we could do to fix it, but I agree that deleting them is
> the simplest solution.
>
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Tue Aug 25 07:33:46 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 25 Aug 2015 13:33:46 +0200
Subject: [hibernate-dev] Search/Validator: Deleting old release files on
 hibernate.org
In-Reply-To: <CANoTJYNNqdW9QjZ+KuFVK3ZVXkBW1A57y-LD33XaNtuVtP-xRw@mail.gmail.com>
References: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>
	<20150825110243.GC61135@Nineveh.lan>
	<CANoTJYNNqdW9QjZ+KuFVK3ZVXkBW1A57y-LD33XaNtuVtP-xRw@mail.gmail.com>
Message-ID: <20150825113346.GP6276@hibernate.org>

I'd like to keep them around, we could avoid the maven fetch dance for
display=false releases.

On Tue 2015-08-25 12:06, Davide D'Alto wrote:
> Can't we just move them into an archive folder?
> 
> On Tue, Aug 25, 2015 at 12:02 PM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> 
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 12:24:21PM +0200, Gunnar Morling wrote:
> > > Can we delete all the non-displayed release files from
> > > https://github.com/hibernate/hibernate.org/tree/staging/_data/projects
> > > for Search and Validator?
> >
> > +1 I can take care of this. I noticed the time it takes as well.
> > I kind of liked the idea of keeping the files and there are other
> > things we could do to fix it, but I agree that deleting them is
> > the simplest solution.
> >
> >
> > --Hardy
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Tue Aug 25 07:51:24 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 25 Aug 2015 13:51:24 +0200
Subject: [hibernate-dev] Search/Validator: Deleting old release files on
 hibernate.org
In-Reply-To: <20150825113346.GP6276@hibernate.org>
References: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>
	<20150825110243.GC61135@Nineveh.lan>
	<CANoTJYNNqdW9QjZ+KuFVK3ZVXkBW1A57y-LD33XaNtuVtP-xRw@mail.gmail.com>
	<20150825113346.GP6276@hibernate.org>
Message-ID: <20150825115124.GD61135@Nineveh.lan>

Hi,

On Tue, Aug 25, 2015 at 01:33:46PM +0200, Emmanuel Bernard wrote:
> I'd like to keep them around

:-) Funny, I thought I was the only one who wants to keep them around.
For me they are kind of part of the project history.

> we could avoid the maven fetch dance for
> display=false releases.

True. I actually looked quickly into this last week when I noticed
the problem as well as part of the Docker setup. The problem is that 
the current helper does not parse the content of the file. It is purely
based on the file/directory structure. So, one would also need to parse
the file itself as YAML and extract the 'release' property. Probably not
hard. Maybe I can have another look.

The other option is of course a different cache directory. The files are already
cached and no download occurs if the pom can be found in the local cache.
The problem is the files are cached in the general awestruct _tmp directory 
which we delete on 'clean'. By just changing this cache dir to a another project
relative or even user specific location we would skip the problem as well.
On the down-side we might miss out on "true" clean which removes all temporary
data. This could become an issue, if for example a corrupted pom gets into the cache.

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

From dreborier at gmail.com  Tue Aug 25 07:53:30 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 25 Aug 2015 12:53:30 +0100
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
Message-ID: <CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>

Hi Stevej

I'm playing with you idea to remove the parent/child from the FromClause
and introduce such a structure in the FromClauseProcessor.

just a question, in the current implementation a fromClause can have more
than one child fromClause , but I cannot figure out when this happen :(

Thanks a lot

On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org> wrote:

> Andrea, this is in relation to something you asked me on IRC today.
> Specifically in regards to FromClause and the fact that it maintains
> pointers to parent/children.  As I said on IRC there is no intrinsic need
> (I do not foresee) for keeping this structure; I really only did that
> because FromCauseProcessor needed a stack of FromClauses and the FromClause
> itself made a simple place to do that.
>
> However, in later work I ran into minor problems because of that decision.
> I need to make a copy of an entire SelectStatement tree.  But because the
> FromClause is held twice (for non-root FromClauses) in the tree, it makes
> it more complicated to do a "simple copy" than it need be.  Basically I
> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>
> Long story short, I think I might revisit that decision and instead write a
> dedicated stack in FromClauseProcessor for this.  In the morning... its too
> late to start something that ambitious tonight.  I'll start that in the
> morning, unless someone wants to pick that up in the next few hours before
> I get back on line.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Aug 25 08:17:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 25 Aug 2015 12:17:29 +0000
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
Message-ID: <CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>

from A a where a.b in (from B b ..) and a.c in (from C c ...) ...

But regardless, the children are not important for a stack, just the
parent.  As I said when we discussed on ORC, the children are just
maintained because I used them for tests.

On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <dreborier at gmail.com> wrote:

> Hi Stevej
>
> I'm playing with you idea to remove the parent/child from the FromClause
> and introduce such a structure in the FromClauseProcessor.
>
> just a question, in the current implementation a fromClause can have more
> than one child fromClause , but I cannot figure out when this happen :(
>
> Thanks a lot
>
> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Andrea, this is in relation to something you asked me on IRC today.
>> Specifically in regards to FromClause and the fact that it maintains
>> pointers to parent/children.  As I said on IRC there is no intrinsic need
>> (I do not foresee) for keeping this structure; I really only did that
>> because FromCauseProcessor needed a stack of FromClauses and the
>> FromClause
>> itself made a simple place to do that.
>>
>> However, in later work I ran into minor problems because of that decision.
>> I need to make a copy of an entire SelectStatement tree.  But because the
>> FromClause is held twice (for non-root FromClauses) in the tree, it makes
>> it more complicated to do a "simple copy" than it need be.  Basically I
>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>>
>> Long story short, I think I might revisit that decision and instead write
>> a
>> dedicated stack in FromClauseProcessor for this.  In the morning... its
>> too
>> late to start something that ambitious tonight.  I'll start that in the
>> morning, unless someone wants to pick that up in the next few hours before
>> I get back on line.
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From hardy at hibernate.org  Tue Aug 25 08:33:41 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 25 Aug 2015 14:33:41 +0200
Subject: [hibernate-dev] Search/Validator: Deleting old release files on
 hibernate.org
In-Reply-To: <20150825115124.GD61135@Nineveh.lan>
References: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>
	<20150825110243.GC61135@Nineveh.lan>
	<CANoTJYNNqdW9QjZ+KuFVK3ZVXkBW1A57y-LD33XaNtuVtP-xRw@mail.gmail.com>
	<20150825113346.GP6276@hibernate.org>
	<20150825115124.GD61135@Nineveh.lan>
Message-ID: <20150825123341.GF61135@Nineveh.lan>

Hi,

actually I was wrong, the fix is trivial. We have all the information to
check whether the release is "displayed".

I created a pull request - https://github.com/hibernate/hibernate.org/pull/97

I would have pushed it already, but it seems there is a problem with the
CI environment. I pushed to staging and the build failed due to a missing
Ruby/Rake setup. Not sure whether this is related to the recent changes/
work on the CI servers. If someone who knows this stuff could have a look,
it would be great.

--Hardy

> On Tue, Aug 25, 2015 at 01:33:46PM +0200, Emmanuel Bernard wrote:
> > I'd like to keep them around
> 
> :-) Funny, I thought I was the only one who wants to keep them around.
> For me they are kind of part of the project history.
> 
> > we could avoid the maven fetch dance for
> > display=false releases.
> 
> True. I actually looked quickly into this last week when I noticed
> the problem as well as part of the Docker setup. The problem is that 
> the current helper does not parse the content of the file. It is purely
> based on the file/directory structure. So, one would also need to parse
> the file itself as YAML and extract the 'release' property. Probably not
> hard. Maybe I can have another look.
> 
> The other option is of course a different cache directory. The files are already
> cached and no download occurs if the pom can be found in the local cache.
> The problem is the files are cached in the general awestruct _tmp directory 
> which we delete on 'clean'. By just changing this cache dir to a another project
> relative or even user specific location we would skip the problem as well.
> On the down-side we might miss out on "true" clean which removes all temporary
> data. This could become an issue, if for example a corrupted pom gets into the cache.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150825/fad15cdc/attachment.bin 

From dreborier at gmail.com  Tue Aug 25 08:41:51 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 25 Aug 2015 13:41:51 +0100
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
Message-ID: <CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>

I see,

Thanks

On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org> wrote:

> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
>
> But regardless, the children are not important for a stack, just the
> parent.  As I said when we discussed on ORC, the children are just
> maintained because I used them for tests.
>
> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> Hi Stevej
>>
>> I'm playing with you idea to remove the parent/child from the FromClause
>> and introduce such a structure in the FromClauseProcessor.
>>
>> just a question, in the current implementation a fromClause can have more
>> than one child fromClause , but I cannot figure out when this happen :(
>>
>> Thanks a lot
>>
>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> Andrea, this is in relation to something you asked me on IRC today.
>>> Specifically in regards to FromClause and the fact that it maintains
>>> pointers to parent/children.  As I said on IRC there is no intrinsic need
>>> (I do not foresee) for keeping this structure; I really only did that
>>> because FromCauseProcessor needed a stack of FromClauses and the
>>> FromClause
>>> itself made a simple place to do that.
>>>
>>> However, in later work I ran into minor problems because of that
>>> decision.
>>> I need to make a copy of an entire SelectStatement tree.  But because the
>>> FromClause is held twice (for non-root FromClauses) in the tree, it makes
>>> it more complicated to do a "simple copy" than it need be.  Basically I
>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>>>
>>> Long story short, I think I might revisit that decision and instead
>>> write a
>>> dedicated stack in FromClauseProcessor for this.  In the morning... its
>>> too
>>> late to start something that ambitious tonight.  I'll start that in the
>>> morning, unless someone wants to pick that up in the next few hours
>>> before
>>> I get back on line.
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From hardy at hibernate.org  Tue Aug 25 08:50:57 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 25 Aug 2015 14:50:57 +0200
Subject: [hibernate-dev] Search/Validator: Deleting old release files on
 hibernate.org
In-Reply-To: <20150825123341.GF61135@Nineveh.lan>
References: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>
	<20150825110243.GC61135@Nineveh.lan>
	<CANoTJYNNqdW9QjZ+KuFVK3ZVXkBW1A57y-LD33XaNtuVtP-xRw@mail.gmail.com>
	<20150825113346.GP6276@hibernate.org>
	<20150825115124.GD61135@Nineveh.lan>
	<20150825123341.GF61135@Nineveh.lan>
Message-ID: <20150825125057.GG61135@Nineveh.lan>

On Tue, Aug 25, 2015 at 02:33:41PM +0200, Hardy Ferentschik wrote:
> I would have pushed it already, but it seems there is a problem with the
> CI environment. I pushed to staging and the build failed due to a missing
> Ruby/Rake setup. Not sure whether this is related to the recent changes/
> work on the CI servers. If someone who knows this stuff could have a look,
> it would be great.

@gunnar - FYI, the prod build of hibernate.org is also broken, so the changes you
pushed there have not been synced yet.

--Hardy

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

From gunnar at hibernate.org  Tue Aug 25 09:15:39 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 25 Aug 2015 15:15:39 +0200
Subject: [hibernate-dev] Ansible set-up, error "unknown key type ecdsa"
Message-ID: <CADGJaX8+rPaDTO0OXLA7vukkNdwN-HP65jpBAWFxaPZoG-ruaA@mail.gmail.com>

Sanne,

When running Ansible to update the CI slaves on OS X, I get the following error:

TASK: [jenkins-slave | Ensure cimaster is a known host] ***********************
unknown key type ecdsa
fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
54.174.65.136) returned 255

Can we use another key type than "ecdsa"? Apparently the SSH coming
with OS X has no support for it (see [1]) and I'd prefer to use the
default version rather than having to install another one.

Thanks,

--Gunnar

[1] http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2

From gunnar at hibernate.org  Tue Aug 25 11:47:19 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 25 Aug 2015 17:47:19 +0200
Subject: [hibernate-dev] Search/Validator: Deleting old release files on
	hibernate.org
In-Reply-To: <20150825125057.GG61135@Nineveh.lan>
References: <CADGJaX_DyJTwttnL1RA=u6aA+_4VyLQxBZSSXRc0heHZhAsPpA@mail.gmail.com>
	<20150825110243.GC61135@Nineveh.lan>
	<CANoTJYNNqdW9QjZ+KuFVK3ZVXkBW1A57y-LD33XaNtuVtP-xRw@mail.gmail.com>
	<20150825113346.GP6276@hibernate.org>
	<20150825115124.GD61135@Nineveh.lan>
	<20150825123341.GF61135@Nineveh.lan>
	<20150825125057.GG61135@Nineveh.lan>
Message-ID: <CADGJaX9y52ZHPjZ_dZ0JfaUa_fb7X=z9reVaTRRCZ5Sg4S+Uwg@mail.gmail.com>

Merged your fix, Hardy.

The build is working again, too. There was something wrong with the
way how Rake/Bundler were installed (not sure tbh. how it actually
worked on some nodes, maybe due to some manual install?!), but this is
fixed now.

2015-08-25 14:50 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
> On Tue, Aug 25, 2015 at 02:33:41PM +0200, Hardy Ferentschik wrote:
>> I would have pushed it already, but it seems there is a problem with the
>> CI environment. I pushed to staging and the build failed due to a missing
>> Ruby/Rake setup. Not sure whether this is related to the recent changes/
>> work on the CI servers. If someone who knows this stuff could have a look,
>> it would be great.
>
> @gunnar - FYI, the prod build of hibernate.org is also broken, so the changes you
> pushed there have not been synced yet.
>
> --Hardy
>

From steve at hibernate.org  Tue Aug 25 15:12:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 25 Aug 2015 19:12:20 +0000
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
Message-ID: <CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>

Anyone want to propose an alternative approach to what I have working in my
Antlr 4 PoC?

If not, I think we should move that work to a GitHub Hibernate org repo and
start tracking work and Jiras there.  Objections?

Also its no longer *just* HQL, we also plan to support JPA criteria queries
here, interpreting them into semantic query models.  As such I propose the
top-level name of hibernate-query-parser, with 2 sub projects:
hibernate-sqm and hibernate-query-interpreter


On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <dreborier at gmail.com> wrote:

> I see,
>
> Thanks
>
> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org> wrote:
>
>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
>>
>> But regardless, the children are not important for a stack, just the
>> parent.  As I said when we discussed on ORC, the children are just
>> maintained because I used them for tests.
>>
>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>>> Hi Stevej
>>>
>>> I'm playing with you idea to remove the parent/child from the FromClause
>>> and introduce such a structure in the FromClauseProcessor.
>>>
>>> just a question, in the current implementation a fromClause can have
>>> more than one child fromClause , but I cannot figure out when this happen :(
>>>
>>> Thanks a lot
>>>
>>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> Andrea, this is in relation to something you asked me on IRC today.
>>>> Specifically in regards to FromClause and the fact that it maintains
>>>> pointers to parent/children.  As I said on IRC there is no intrinsic
>>>> need
>>>> (I do not foresee) for keeping this structure; I really only did that
>>>> because FromCauseProcessor needed a stack of FromClauses and the
>>>> FromClause
>>>> itself made a simple place to do that.
>>>>
>>>> However, in later work I ran into minor problems because of that
>>>> decision.
>>>> I need to make a copy of an entire SelectStatement tree.  But because
>>>> the
>>>> FromClause is held twice (for non-root FromClauses) in the tree, it
>>>> makes
>>>> it more complicated to do a "simple copy" than it need be.  Basically I
>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>>>>
>>>> Long story short, I think I might revisit that decision and instead
>>>> write a
>>>> dedicated stack in FromClauseProcessor for this.  In the morning... its
>>>> too
>>>> late to start something that ambitious tonight.  I'll start that in the
>>>> morning, unless someone wants to pick that up in the next few hours
>>>> before
>>>> I get back on line.
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>

From andrea at hibernate.org  Tue Aug 25 15:21:07 2015
From: andrea at hibernate.org (andrea boriero)
Date: Tue, 25 Aug 2015 20:21:07 +0100
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
Message-ID: <CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>

no objections

On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org> wrote:

> Anyone want to propose an alternative approach to what I have working in
> my Antlr 4 PoC?
>
> If not, I think we should move that work to a GitHub Hibernate org repo
> and start tracking work and Jiras there.  Objections?
>
> Also its no longer *just* HQL, we also plan to support JPA criteria
> queries here, interpreting them into semantic query models.  As such I
> propose the top-level name of hibernate-query-parser, with 2 sub projects:
> hibernate-sqm and hibernate-query-interpreter
>
>
> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> I see,
>>
>> Thanks
>>
>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
>>>
>>> But regardless, the children are not important for a stack, just the
>>> parent.  As I said when we discussed on ORC, the children are just
>>> maintained because I used them for tests.
>>>
>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <dreborier at gmail.com>
>>> wrote:
>>>
>>>> Hi Stevej
>>>>
>>>> I'm playing with you idea to remove the parent/child from the
>>>> FromClause and introduce such a structure in the FromClauseProcessor.
>>>>
>>>> just a question, in the current implementation a fromClause can have
>>>> more than one child fromClause , but I cannot figure out when this happen :(
>>>>
>>>> Thanks a lot
>>>>
>>>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org> wrote:
>>>>
>>>>> Andrea, this is in relation to something you asked me on IRC today.
>>>>> Specifically in regards to FromClause and the fact that it maintains
>>>>> pointers to parent/children.  As I said on IRC there is no intrinsic
>>>>> need
>>>>> (I do not foresee) for keeping this structure; I really only did that
>>>>> because FromCauseProcessor needed a stack of FromClauses and the
>>>>> FromClause
>>>>> itself made a simple place to do that.
>>>>>
>>>>> However, in later work I ran into minor problems because of that
>>>>> decision.
>>>>> I need to make a copy of an entire SelectStatement tree.  But because
>>>>> the
>>>>> FromClause is held twice (for non-root FromClauses) in the tree, it
>>>>> makes
>>>>> it more complicated to do a "simple copy" than it need be.  Basically I
>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>>>>>
>>>>> Long story short, I think I might revisit that decision and instead
>>>>> write a
>>>>> dedicated stack in FromClauseProcessor for this.  In the morning...
>>>>> its too
>>>>> late to start something that ambitious tonight.  I'll start that in the
>>>>> morning, unless someone wants to pick that up in the next few hours
>>>>> before
>>>>> I get back on line.
>>>>>
>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>

From steve at hibernate.org  Tue Aug 25 16:56:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 25 Aug 2015 20:56:37 +0000
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
Message-ID: <CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>

I am starting that work here ->
https://github.com/hibernate/hibernate-semantic-query


On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <andrea at hibernate.org> wrote:

> no objections
>
> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Anyone want to propose an alternative approach to what I have working in
>> my Antlr 4 PoC?
>>
>> If not, I think we should move that work to a GitHub Hibernate org repo
>> and start tracking work and Jiras there.  Objections?
>>
>> Also its no longer *just* HQL, we also plan to support JPA criteria
>> queries here, interpreting them into semantic query models.  As such I
>> propose the top-level name of hibernate-query-parser, with 2 sub projects:
>> hibernate-sqm and hibernate-query-interpreter
>>
>>
>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>>> I see,
>>>
>>> Thanks
>>>
>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
>>>>
>>>> But regardless, the children are not important for a stack, just the
>>>> parent.  As I said when we discussed on ORC, the children are just
>>>> maintained because I used them for tests.
>>>>
>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <dreborier at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Stevej
>>>>>
>>>>> I'm playing with you idea to remove the parent/child from the
>>>>> FromClause and introduce such a structure in the FromClauseProcessor.
>>>>>
>>>>> just a question, in the current implementation a fromClause can have
>>>>> more than one child fromClause , but I cannot figure out when this happen :(
>>>>>
>>>>> Thanks a lot
>>>>>
>>>>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> Andrea, this is in relation to something you asked me on IRC today.
>>>>>> Specifically in regards to FromClause and the fact that it maintains
>>>>>> pointers to parent/children.  As I said on IRC there is no intrinsic
>>>>>> need
>>>>>> (I do not foresee) for keeping this structure; I really only did that
>>>>>> because FromCauseProcessor needed a stack of FromClauses and the
>>>>>> FromClause
>>>>>> itself made a simple place to do that.
>>>>>>
>>>>>> However, in later work I ran into minor problems because of that
>>>>>> decision.
>>>>>> I need to make a copy of an entire SelectStatement tree.  But because
>>>>>> the
>>>>>> FromClause is held twice (for non-root FromClauses) in the tree, it
>>>>>> makes
>>>>>> it more complicated to do a "simple copy" than it need be.  Basically
>>>>>> I
>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>>>>>>
>>>>>> Long story short, I think I might revisit that decision and instead
>>>>>> write a
>>>>>> dedicated stack in FromClauseProcessor for this.  In the morning...
>>>>>> its too
>>>>>> late to start something that ambitious tonight.  I'll start that in
>>>>>> the
>>>>>> morning, unless someone wants to pick that up in the next few hours
>>>>>> before
>>>>>> I get back on line.
>>>>>>
>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>
>

From steve at hibernate.org  Tue Aug 25 18:17:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 25 Aug 2015 22:17:33 +0000
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
Message-ID: <CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>

I also created Jira project -> https://hibernate.atlassian.net/projects/SQM

On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve at hibernate.org> wrote:

> I am starting that work here ->
> https://github.com/hibernate/hibernate-semantic-query
>
>
> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <andrea at hibernate.org>
> wrote:
>
>> no objections
>>
>> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> Anyone want to propose an alternative approach to what I have working in
>>> my Antlr 4 PoC?
>>>
>>> If not, I think we should move that work to a GitHub Hibernate org repo
>>> and start tracking work and Jiras there.  Objections?
>>>
>>> Also its no longer *just* HQL, we also plan to support JPA criteria
>>> queries here, interpreting them into semantic query models.  As such I
>>> propose the top-level name of hibernate-query-parser, with 2 sub projects:
>>> hibernate-sqm and hibernate-query-interpreter
>>>
>>>
>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <dreborier at gmail.com>
>>> wrote:
>>>
>>>> I see,
>>>>
>>>> Thanks
>>>>
>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org> wrote:
>>>>
>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
>>>>>
>>>>> But regardless, the children are not important for a stack, just the
>>>>> parent.  As I said when we discussed on ORC, the children are just
>>>>> maintained because I used them for tests.
>>>>>
>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <dreborier at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Stevej
>>>>>>
>>>>>> I'm playing with you idea to remove the parent/child from the
>>>>>> FromClause and introduce such a structure in the FromClauseProcessor.
>>>>>>
>>>>>> just a question, in the current implementation a fromClause can have
>>>>>> more than one child fromClause , but I cannot figure out when this happen :(
>>>>>>
>>>>>> Thanks a lot
>>>>>>
>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Andrea, this is in relation to something you asked me on IRC today.
>>>>>>> Specifically in regards to FromClause and the fact that it maintains
>>>>>>> pointers to parent/children.  As I said on IRC there is no intrinsic
>>>>>>> need
>>>>>>> (I do not foresee) for keeping this structure; I really only did that
>>>>>>> because FromCauseProcessor needed a stack of FromClauses and the
>>>>>>> FromClause
>>>>>>> itself made a simple place to do that.
>>>>>>>
>>>>>>> However, in later work I ran into minor problems because of that
>>>>>>> decision.
>>>>>>> I need to make a copy of an entire SelectStatement tree.  But
>>>>>>> because the
>>>>>>> FromClause is held twice (for non-root FromClauses) in the tree, it
>>>>>>> makes
>>>>>>> it more complicated to do a "simple copy" than it need be.
>>>>>>> Basically I
>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>>>>>>>
>>>>>>> Long story short, I think I might revisit that decision and instead
>>>>>>> write a
>>>>>>> dedicated stack in FromClauseProcessor for this.  In the morning...
>>>>>>> its too
>>>>>>> late to start something that ambitious tonight.  I'll start that in
>>>>>>> the
>>>>>>> morning, unless someone wants to pick that up in the next few hours
>>>>>>> before
>>>>>>> I get back on line.
>>>>>>>
>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>

From steve at hibernate.org  Tue Aug 25 23:20:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 03:20:20 +0000
Subject: [hibernate-dev] HQL and spatial
Message-ID: <CAFdSV9uJLVp8HMeJzpOrmciDgzLSWZYVjZMbGuq_nkTLgGBW+g@mail.gmail.com>

Karel, etal

We have discussed spatial-specific extensions to HQL for quite some time.
But those discussions have always been kind of esoteric ("boy wouldn't it
be nice to have some spatial support in HQL").

As we are working on redesigning the parsing and interpretation of HQL
queries and since spatial has been integrated upstream, it seems like a
great time to discuss specifics of what this might mean.

I have never used spatial data, let alone crafted queries using spatial
data.  So I am not the best driver here.

What kinds of things make sense to add to HQL for supporting spatial
queries?

From gunnar at hibernate.org  Wed Aug 26 02:47:56 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 26 Aug 2015 08:47:56 +0200
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
Message-ID: <CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>

+1 for the new repo. Just forked it and am looking into the amazing
things you guys built recently :)

Can I push simple stuff to that repo right away (e.g. adding the
Eclipse plug-in to build.gradle)?

Cheers,

--Gunnar


2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> I also created Jira project -> https://hibernate.atlassian.net/projects/SQM
>
> On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> I am starting that work here ->
>> https://github.com/hibernate/hibernate-semantic-query
>>
>>
>> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <andrea at hibernate.org>
>> wrote:
>>
>>> no objections
>>>
>>> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> Anyone want to propose an alternative approach to what I have working in
>>>> my Antlr 4 PoC?
>>>>
>>>> If not, I think we should move that work to a GitHub Hibernate org repo
>>>> and start tracking work and Jiras there.  Objections?
>>>>
>>>> Also its no longer *just* HQL, we also plan to support JPA criteria
>>>> queries here, interpreting them into semantic query models.  As such I
>>>> propose the top-level name of hibernate-query-parser, with 2 sub projects:
>>>> hibernate-sqm and hibernate-query-interpreter
>>>>
>>>>
>>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <dreborier at gmail.com>
>>>> wrote:
>>>>
>>>>> I see,
>>>>>
>>>>> Thanks
>>>>>
>>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org> wrote:
>>>>>
>>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
>>>>>>
>>>>>> But regardless, the children are not important for a stack, just the
>>>>>> parent.  As I said when we discussed on ORC, the children are just
>>>>>> maintained because I used them for tests.
>>>>>>
>>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <dreborier at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Stevej
>>>>>>>
>>>>>>> I'm playing with you idea to remove the parent/child from the
>>>>>>> FromClause and introduce such a structure in the FromClauseProcessor.
>>>>>>>
>>>>>>> just a question, in the current implementation a fromClause can have
>>>>>>> more than one child fromClause , but I cannot figure out when this happen :(
>>>>>>>
>>>>>>> Thanks a lot
>>>>>>>
>>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Andrea, this is in relation to something you asked me on IRC today.
>>>>>>>> Specifically in regards to FromClause and the fact that it maintains
>>>>>>>> pointers to parent/children.  As I said on IRC there is no intrinsic
>>>>>>>> need
>>>>>>>> (I do not foresee) for keeping this structure; I really only did that
>>>>>>>> because FromCauseProcessor needed a stack of FromClauses and the
>>>>>>>> FromClause
>>>>>>>> itself made a simple place to do that.
>>>>>>>>
>>>>>>>> However, in later work I ran into minor problems because of that
>>>>>>>> decision.
>>>>>>>> I need to make a copy of an entire SelectStatement tree.  But
>>>>>>>> because the
>>>>>>>> FromClause is held twice (for non-root FromClauses) in the tree, it
>>>>>>>> makes
>>>>>>>> it more complicated to do a "simple copy" than it need be.
>>>>>>>> Basically I
>>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>>>>>>>>
>>>>>>>> Long story short, I think I might revisit that decision and instead
>>>>>>>> write a
>>>>>>>> dedicated stack in FromClauseProcessor for this.  In the morning...
>>>>>>>> its too
>>>>>>>> late to start something that ambitious tonight.  I'll start that in
>>>>>>>> the
>>>>>>>> morning, unless someone wants to pick that up in the next few hours
>>>>>>>> before
>>>>>>>> I get back on line.
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Aug 26 03:09:59 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 26 Aug 2015 09:09:59 +0200
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
Message-ID: <CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>

Hi Steve,

> The other approach is to use a 3-phase translation (input
> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to one
> of the major problems.  One source "semantic" query will often correspond
> to multiple SQL queries; that is hard to manage in the 2-phase approach.

In which situations will this happen? I can see inheritance where a
HQL query targeting a super-type needs to be translated into a SQL
query per sub-type table. What others are there?

For the purposes of OGM this phase ideally would not be tied to SQL,
as we phase the same task with non-SQL backends in SQL. I.e. i'd be
beneficial to have input -> semantic-tree ->
semantic-output-query-tree(s) -> (SQL|non-SQL query). There
"semantic-output-query-tree(s)" would be an abstract representation of
the queries to be executed, e.g. referencing the table name(s). But it
would be unaware of SQL specifics.

Thanks,

--Gunnar

From davide at hibernate.org  Wed Aug 26 05:33:26 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 26 Aug 2015 10:33:26 +0100
Subject: [hibernate-dev] HIbernate Shards contributors
Message-ID: <CANoTJYPVwOA-2+wkfZLfbTAPzx0AZkC2bXFpXLogcPHR2c1_yw@mail.gmail.com>

Hi,
on the forum someone is interested in updating the Hibernate Shards project:

https://forum.hibernate.org/viewtopic.php?f=9&t=1041314

In the website we ask to contact us if someone is interested to the project
but we don't provide an email address.


How should we reply to the post?

Cheers,
Davide

From sanne at hibernate.org  Wed Aug 26 05:33:45 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 26 Aug 2015 10:33:45 +0100
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
Message-ID: <CAFm4XO2jMxM9Qg3KjPcnNWXvqTM-3CxUrN4BE9SEA2Six9uFwA@mail.gmail.com>

Hi all,
joining the party late, just read it all up.

I'm highly +1 to multiple phases, I think it's a requirement for e.g.
cached reuse.

About ANTLR4 : it sounds better than ANTLR3 for maintenance reasons;
but I don't think we can grasp the full picture of all the things we
want to do and say "it's going to work" without going ahead quickly;
failure shouldn't scare us from experimenting: worst case we'll have a
better picture of what needs to be done.
My vote is to commit to ANTLR4 and try hard to make it work; we could
try keeping it isolated to potentially replace it but I'd rather focus
on implementing it all than to make it a replaceable engine; once we
have all ORM entry points pointing to the new engine we should have a
better picture to consider replacing it? I realize it's a risk, but
I'm confident that at worst it will take more work than expected:
since it's expecting hand coding of the walker, it's hardly going to
be a dead end.

Could we summarize the requirements? These are the ones I'm aware of,
trying to list them w/o too much detail as we all discussed them
already:

- Let the database specific Dialects customize the SQL (way more than today)
- Let Criteria & Loaders generate the same structures (to get the
Dialect customization and caching capabilities)
- Let OGM generate non-SQL output (significantly different walkers -
including as Criteria output & co)
- Being able to Cache the parsing phase: e.g. reuse an intermediate
tree as an immutable threadsafe structure, BUT w/o making query
parameters parameter values
- Validate such a query w/o having parameters (tooling, bootstrap
validation of named queries)
- Diagnostics: attach comments & purpose explanation to nodes,
pretty-printing in the logs, etc.. as with today's parser.

I think that's the requirements summary?

A comment on implementation:
Could we consider the need for multiple SQL statements as a detail of
one of the last phases?
My crux with that is that for different, non SQL technologies (OGM,
but even ORM if we eventually map to custom stored procedures),
yet those concrete execution plans should also be cacheable.
So I think that highlights the need for either an additional phase, or
simply that "the bottom phase" can in turn generate more phases and
reuse the Query Plan Caching SPI as needed.. i.e. a variable phases
approach.

Finally, the holy grail of persistence would be to switch between
different storage technologies depending on the query semantics; a
simple example would be the interaction with 2nd level caches could be
smarter, a more complex one would be an OGM application using an
hybrid storage like a RDBMS and an in memory datagrid: when you know
some data can be found in either store, you have to choose were to
load it from and that will depend on what kind of query we're dealing
with.
Another example is with Hibernate Search interaction: often people
want to filter a result both with Criteria and a full-text
restriction.
Not sure if we want to think about hybrid storage in the early phase already..

Thanks,
Sanne

On 26 August 2015 at 08:09, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi Steve,
>
>> The other approach is to use a 3-phase translation (input
>> -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to one
>> of the major problems.  One source "semantic" query will often correspond
>> to multiple SQL queries; that is hard to manage in the 2-phase approach.
>
> In which situations will this happen? I can see inheritance where a
> HQL query targeting a super-type needs to be translated into a SQL
> query per sub-type table. What others are there?
>
> For the purposes of OGM this phase ideally would not be tied to SQL,
> as we phase the same task with non-SQL backends in SQL. I.e. i'd be
> beneficial to have input -> semantic-tree ->
> semantic-output-query-tree(s) -> (SQL|non-SQL query). There
> "semantic-output-query-tree(s)" would be an abstract representation of
> the queries to be executed, e.g. referencing the table name(s). But it
> would be unaware of SQL specifics.
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Aug 26 06:05:35 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 26 Aug 2015 11:05:35 +0100
Subject: [hibernate-dev] HIbernate Shards contributors
In-Reply-To: <CANoTJYPVwOA-2+wkfZLfbTAPzx0AZkC2bXFpXLogcPHR2c1_yw@mail.gmail.com>
References: <CANoTJYPVwOA-2+wkfZLfbTAPzx0AZkC2bXFpXLogcPHR2c1_yw@mail.gmail.com>
Message-ID: <CAFm4XO21v1DfKbd4JgwzcBNUaDo1heC1ZQDG3Z+JmBchQSX_xg@mail.gmail.com>

Thanks for noticing, I'll reply there.

On 26 August 2015 at 10:33, Davide D'Alto <davide at hibernate.org> wrote:
> Hi,
> on the forum someone is interested in updating the Hibernate Shards project:
>
> https://forum.hibernate.org/viewtopic.php?f=9&t=1041314
>
> In the website we ask to contact us if someone is interested to the project
> but we don't provide an email address.
>
>
> How should we reply to the post?
>
> Cheers,
> Davide
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Aug 26 07:15:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 26 Aug 2015 12:15:16 +0100
Subject: [hibernate-dev] Ansible set-up, error "unknown key type ecdsa"
In-Reply-To: <CADGJaX8+rPaDTO0OXLA7vukkNdwN-HP65jpBAWFxaPZoG-ruaA@mail.gmail.com>
References: <CADGJaX8+rPaDTO0OXLA7vukkNdwN-HP65jpBAWFxaPZoG-ruaA@mail.gmail.com>
Message-ID: <CAFm4XO0D4rkRZfey9r=Wwf4KmmaKX1riwSYKAqmXu_jZUryquQ@mail.gmail.com>

On 25 August 2015 at 14:15, Gunnar Morling <gunnar at hibernate.org> wrote:
> Sanne,
>
> When running Ansible to update the CI slaves on OS X, I get the following error:
>
> TASK: [jenkins-slave | Ensure cimaster is a known host] ***********************
> unknown key type ecdsa
> fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
> 54.174.65.136) returned 255
>
> Can we use another key type than "ecdsa"? Apparently the SSH coming
> with OS X has no support for it (see [1]) and I'd prefer to use the
> default version rather than having to install another one.

That line though is just a trick to fetch the existing keys so I guess
that to change the key type we need to figure out when & how these are
generated.
I just checked and it seems like we actually generate (and use) RSA
keys now; maybe that line is just broken on all platforms (not just on
OSX)?
When making changes I only run the related portions of the Ansible
script, so that might have been broken since a while w/o anyone
noticing.
Davide extended this further with tags: see the readme to easily run
only the tasks related to a specific task (although we should tag all
tasks, not done yet).

I'm actually quite unhappy with that whole trick to get the generated
nodes exchange the keys; it doesn't seem like "the Ansible way" as
it's quite procedural, but I couldn't figure a better way other than
pre-generate them (and lots of other people have that problem on SO so
I'd hope it will improve).
Would you prefer us to pre-generate those keys manually and add them
to the list of secret tokens which we need to share among maintainers?
I was trying to keep the list of keys we all need and the preparation
steps minimal, but agree this one might not be worth the complexity.

FWIW, ECDSA is the future: get a better OS ;-)

Thanks,
Sanne

>
> Thanks,
>
> --Gunnar
>
> [1] http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From davide at hibernate.org  Wed Aug 26 07:28:49 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 26 Aug 2015 12:28:49 +0100
Subject: [hibernate-dev] Ansible set-up, error "unknown key type ecdsa"
In-Reply-To: <CAFm4XO0D4rkRZfey9r=Wwf4KmmaKX1riwSYKAqmXu_jZUryquQ@mail.gmail.com>
References: <CADGJaX8+rPaDTO0OXLA7vukkNdwN-HP65jpBAWFxaPZoG-ruaA@mail.gmail.com>
	<CAFm4XO0D4rkRZfey9r=Wwf4KmmaKX1riwSYKAqmXu_jZUryquQ@mail.gmail.com>
Message-ID: <CANoTJYPs6x9aB2u2R1CGkP8_Dzqq+1ZmHrvR3hm8-Agxq6vZpQ@mail.gmail.com>

Can't we keep some secrets tokens on master?
Or on a separate secret small machine?

This way we can transfer them from master during the creation of the slave.
Basically, I'm talking about improving the transfert-to-slave script.

> Davide extended this further with tags: see the readme to easily run
only the tasks related to a specific task (although we should tag all
tasks, not done yet).

I might now have explained that in the readme, but the Ansible
documentation is clear: http://docs.ansible.com/ansible/playbooks_tags.html

> FWIW, ECDSA is the future: get a better OS ;-)

+1 :)

Davide

On Wed, Aug 26, 2015 at 12:15 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 25 August 2015 at 14:15, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Sanne,
> >
> > When running Ansible to update the CI slaves on OS X, I get the
> following error:
> >
> > TASK: [jenkins-slave | Ensure cimaster is a known host]
> ***********************
> > unknown key type ecdsa
> > fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
> > 54.174.65.136) returned 255
> >
> > Can we use another key type than "ecdsa"? Apparently the SSH coming
> > with OS X has no support for it (see [1]) and I'd prefer to use the
> > default version rather than having to install another one.
>
> That line though is just a trick to fetch the existing keys so I guess
> that to change the key type we need to figure out when & how these are
> generated.
> I just checked and it seems like we actually generate (and use) RSA
> keys now; maybe that line is just broken on all platforms (not just on
> OSX)?
> When making changes I only run the related portions of the Ansible
> script, so that might have been broken since a while w/o anyone
> noticing.
> Davide extended this further with tags: see the readme to easily run
> only the tasks related to a specific task (although we should tag all
> tasks, not done yet).
>
> I'm actually quite unhappy with that whole trick to get the generated
> nodes exchange the keys; it doesn't seem like "the Ansible way" as
> it's quite procedural, but I couldn't figure a better way other than
> pre-generate them (and lots of other people have that problem on SO so
> I'd hope it will improve).
> Would you prefer us to pre-generate those keys manually and add them
> to the list of secret tokens which we need to share among maintainers?
> I was trying to keep the list of keys we all need and the preparation
> steps minimal, but agree this one might not be worth the complexity.
>
> FWIW, ECDSA is the future: get a better OS ;-)
>
> Thanks,
> Sanne
>
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1]
> http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Aug 26 07:38:04 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 26 Aug 2015 12:38:04 +0100
Subject: [hibernate-dev] Ansible set-up, error "unknown key type ecdsa"
In-Reply-To: <CANoTJYNR_LR+eWyvWatVvy7G6U+xb_yHGMYSDLw_dVJqAHsPNQ@mail.gmail.com>
References: <CADGJaX8+rPaDTO0OXLA7vukkNdwN-HP65jpBAWFxaPZoG-ruaA@mail.gmail.com>
	<CAFm4XO0D4rkRZfey9r=Wwf4KmmaKX1riwSYKAqmXu_jZUryquQ@mail.gmail.com>
	<CANoTJYNR_LR+eWyvWatVvy7G6U+xb_yHGMYSDLw_dVJqAHsPNQ@mail.gmail.com>
Message-ID: <CAFm4XO2Kk=3iCwKrmxPOqZ0jf2L2t6cL=NJ8DFDCSmDJ2Jwh+w@mail.gmail.com>

On 26 August 2015 at 12:28, Davide D'Alto <davide at hibernate.org> wrote:
> Can't we keep some secrets tokens on master?
> Or on a separate secret small machine?
>
> This way we can transfer them from master during the creation of the slave.
> Basically, I'm talking about improving the transfert-to-slave script.

That's what I proposed in the previous email, but there are tradeoffs
such as having to maintain more secret keys somewhere. I'm not sure
which approach is the lesser evil ;)

Sanne


>
>> Davide extended this further with tags: see the readme to easily run
> only the tasks related to a specific task (although we should tag all
> tasks, not done yet).
>
> I might now have explained that in the readme, but the Ansible documentation
> is clear: http://docs.ansible.com/ansible/playbooks_tags.html
>
>> FWIW, ECDSA is the future: get a better OS ;-)
>
> +1 :)
>
> Davide
>
> On Wed, Aug 26, 2015 at 12:15 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> On 25 August 2015 at 14:15, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Sanne,
>> >
>> > When running Ansible to update the CI slaves on OS X, I get the
>> > following error:
>> >
>> > TASK: [jenkins-slave | Ensure cimaster is a known host]
>> > ***********************
>> > unknown key type ecdsa
>> > fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
>> > 54.174.65.136) returned 255
>> >
>> > Can we use another key type than "ecdsa"? Apparently the SSH coming
>> > with OS X has no support for it (see [1]) and I'd prefer to use the
>> > default version rather than having to install another one.
>>
>> That line though is just a trick to fetch the existing keys so I guess
>> that to change the key type we need to figure out when & how these are
>> generated.
>> I just checked and it seems like we actually generate (and use) RSA
>> keys now; maybe that line is just broken on all platforms (not just on
>> OSX)?
>> When making changes I only run the related portions of the Ansible
>> script, so that might have been broken since a while w/o anyone
>> noticing.
>> Davide extended this further with tags: see the readme to easily run
>> only the tasks related to a specific task (although we should tag all
>> tasks, not done yet).
>>
>> I'm actually quite unhappy with that whole trick to get the generated
>> nodes exchange the keys; it doesn't seem like "the Ansible way" as
>> it's quite procedural, but I couldn't figure a better way other than
>> pre-generate them (and lots of other people have that problem on SO so
>> I'd hope it will improve).
>> Would you prefer us to pre-generate those keys manually and add them
>> to the list of secret tokens which we need to share among maintainers?
>> I was trying to keep the list of keys we all need and the preparation
>> steps minimal, but agree this one might not be worth the complexity.
>>
>> FWIW, ECDSA is the future: get a better OS ;-)
>>
>> Thanks,
>> Sanne
>>
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> >
>> > [1]
>> > http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From davide at hibernate.org  Wed Aug 26 07:51:34 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 26 Aug 2015 12:51:34 +0100
Subject: [hibernate-dev] Ansible set-up, error "unknown key type ecdsa"
In-Reply-To: <CAFm4XO2Kk=3iCwKrmxPOqZ0jf2L2t6cL=NJ8DFDCSmDJ2Jwh+w@mail.gmail.com>
References: <CADGJaX8+rPaDTO0OXLA7vukkNdwN-HP65jpBAWFxaPZoG-ruaA@mail.gmail.com>
	<CAFm4XO0D4rkRZfey9r=Wwf4KmmaKX1riwSYKAqmXu_jZUryquQ@mail.gmail.com>
	<CANoTJYNR_LR+eWyvWatVvy7G6U+xb_yHGMYSDLw_dVJqAHsPNQ@mail.gmail.com>
	<CAFm4XO2Kk=3iCwKrmxPOqZ0jf2L2t6cL=NJ8DFDCSmDJ2Jwh+w@mail.gmail.com>
Message-ID: <CANoTJYMOPC9fzW9Y48ZXdxtEA+MqVj0A1TLz8M-WVgBj23FM9A@mail.gmail.com>

> That's what I proposed in the previous email, but there are tradeoffs
> such as having to maintain more secret keys somewhere. I'm not sure
> which approach is the lesser evil ;)

I prefer having the keys in one place of reference.
It's easier to remember to keep it up-to-date.







On Wed, Aug 26, 2015 at 12:38 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 26 August 2015 at 12:28, Davide D'Alto <davide at hibernate.org> wrote:
> > Can't we keep some secrets tokens on master?
> > Or on a separate secret small machine?
> >
> > This way we can transfer them from master during the creation of the
> slave.
> > Basically, I'm talking about improving the transfert-to-slave script.
>
> That's what I proposed in the previous email, but there are tradeoffs
> such as having to maintain more secret keys somewhere. I'm not sure
> which approach is the lesser evil ;)
>
> Sanne
>
>
> >
> >> Davide extended this further with tags: see the readme to easily run
> > only the tasks related to a specific task (although we should tag all
> > tasks, not done yet).
> >
> > I might now have explained that in the readme, but the Ansible
> documentation
> > is clear: http://docs.ansible.com/ansible/playbooks_tags.html
> >
> >> FWIW, ECDSA is the future: get a better OS ;-)
> >
> > +1 :)
> >
> > Davide
> >
> > On Wed, Aug 26, 2015 at 12:15 PM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> On 25 August 2015 at 14:15, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > Sanne,
> >> >
> >> > When running Ansible to update the CI slaves on OS X, I get the
> >> > following error:
> >> >
> >> > TASK: [jenkins-slave | Ensure cimaster is a known host]
> >> > ***********************
> >> > unknown key type ecdsa
> >> > fatal: [209.132.178.232] => lookup_plugin.pipe(ssh-keyscan -t ecdsa
> >> > 54.174.65.136) returned 255
> >> >
> >> > Can we use another key type than "ecdsa"? Apparently the SSH coming
> >> > with OS X has no support for it (see [1]) and I'd prefer to use the
> >> > default version rather than having to install another one.
> >>
> >> That line though is just a trick to fetch the existing keys so I guess
> >> that to change the key type we need to figure out when & how these are
> >> generated.
> >> I just checked and it seems like we actually generate (and use) RSA
> >> keys now; maybe that line is just broken on all platforms (not just on
> >> OSX)?
> >> When making changes I only run the related portions of the Ansible
> >> script, so that might have been broken since a while w/o anyone
> >> noticing.
> >> Davide extended this further with tags: see the readme to easily run
> >> only the tasks related to a specific task (although we should tag all
> >> tasks, not done yet).
> >>
> >> I'm actually quite unhappy with that whole trick to get the generated
> >> nodes exchange the keys; it doesn't seem like "the Ansible way" as
> >> it's quite procedural, but I couldn't figure a better way other than
> >> pre-generate them (and lots of other people have that problem on SO so
> >> I'd hope it will improve).
> >> Would you prefer us to pre-generate those keys manually and add them
> >> to the list of secret tokens which we need to share among maintainers?
> >> I was trying to keep the list of keys we all need and the preparation
> >> steps minimal, but agree this one might not be worth the complexity.
> >>
> >> FWIW, ECDSA is the future: get a better OS ;-)
> >>
> >> Thanks,
> >> Sanne
> >>
> >> >
> >> > Thanks,
> >> >
> >> > --Gunnar
> >> >
> >> > [1]
> >> >
> http://apple.stackexchange.com/questions/77731/ecdsa-ssh-key-on-10-8-2
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From steve at hibernate.org  Wed Aug 26 08:15:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 12:15:37 +0000
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
	<CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
Message-ID: <CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>

Yes

On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> +1 for the new repo. Just forked it and am looking into the amazing
> things you guys built recently :)
>
> Can I push simple stuff to that repo right away (e.g. adding the
> Eclipse plug-in to build.gradle)?
>
> Cheers,
>
> --Gunnar
>
>
> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> > I also created Jira project ->
> https://hibernate.atlassian.net/projects/SQM
> >
> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> I am starting that work here ->
> >> https://github.com/hibernate/hibernate-semantic-query
> >>
> >>
> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <andrea at hibernate.org>
> >> wrote:
> >>
> >>> no objections
> >>>
> >>> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>
> >>>> Anyone want to propose an alternative approach to what I have working
> in
> >>>> my Antlr 4 PoC?
> >>>>
> >>>> If not, I think we should move that work to a GitHub Hibernate org
> repo
> >>>> and start tracking work and Jiras there.  Objections?
> >>>>
> >>>> Also its no longer *just* HQL, we also plan to support JPA criteria
> >>>> queries here, interpreting them into semantic query models.  As such I
> >>>> propose the top-level name of hibernate-query-parser, with 2 sub
> projects:
> >>>> hibernate-sqm and hibernate-query-interpreter
> >>>>
> >>>>
> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <dreborier at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> I see,
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>>>
> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
> >>>>>>
> >>>>>> But regardless, the children are not important for a stack, just the
> >>>>>> parent.  As I said when we discussed on ORC, the children are just
> >>>>>> maintained because I used them for tests.
> >>>>>>
> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <dreborier at gmail.com
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Stevej
> >>>>>>>
> >>>>>>> I'm playing with you idea to remove the parent/child from the
> >>>>>>> FromClause and introduce such a structure in the
> FromClauseProcessor.
> >>>>>>>
> >>>>>>> just a question, in the current implementation a fromClause can
> have
> >>>>>>> more than one child fromClause , but I cannot figure out when this
> happen :(
> >>>>>>>
> >>>>>>> Thanks a lot
> >>>>>>>
> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Andrea, this is in relation to something you asked me on IRC
> today.
> >>>>>>>> Specifically in regards to FromClause and the fact that it
> maintains
> >>>>>>>> pointers to parent/children.  As I said on IRC there is no
> intrinsic
> >>>>>>>> need
> >>>>>>>> (I do not foresee) for keeping this structure; I really only did
> that
> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses and the
> >>>>>>>> FromClause
> >>>>>>>> itself made a simple place to do that.
> >>>>>>>>
> >>>>>>>> However, in later work I ran into minor problems because of that
> >>>>>>>> decision.
> >>>>>>>> I need to make a copy of an entire SelectStatement tree.  But
> >>>>>>>> because the
> >>>>>>>> FromClause is held twice (for non-root FromClauses) in the tree,
> it
> >>>>>>>> makes
> >>>>>>>> it more complicated to do a "simple copy" than it need be.
> >>>>>>>> Basically I
> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
> >>>>>>>>
> >>>>>>>> Long story short, I think I might revisit that decision and
> instead
> >>>>>>>> write a
> >>>>>>>> dedicated stack in FromClauseProcessor for this.  In the
> morning...
> >>>>>>>> its too
> >>>>>>>> late to start something that ambitious tonight.  I'll start that
> in
> >>>>>>>> the
> >>>>>>>> morning, unless someone wants to pick that up in the next few
> hours
> >>>>>>>> before
> >>>>>>>> I get back on line.
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>>> hibernate-dev mailing list
> >>>>>>>> hibernate-dev at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Aug 26 08:41:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 12:41:41 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
Message-ID: <CAFdSV9vz1gyRmuTwT+o4vWcbsmZGknPDdqFjZNPkp52qmjwxWA@mail.gmail.com>

On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Steve,
>
> > The other approach is to use a 3-phase translation (input
> > -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to
> one
> > of the major problems.  One source "semantic" query will often correspond
> > to multiple SQL queries; that is hard to manage in the 2-phase approach.
>
> In which situations will this happen? I can see inheritance where a
> HQL query targeting a super-type needs to be translated into a SQL
> query per sub-type table. What others are there?
>

For ORM the only time this happens today for a SELECT query is in the
"split query" case I mentioned elsewhere (a query like 'from
java.lang.Object').  SQM does this much better than we do in ORM today.  in
SQM we build a semantic tree that encodes the "unmapped polymorphism" such
that we get a tree with 'java.lang.Object' as the root from element. But it
is a FromElement with a special type of EntityTypeDescriptor (which comes
from the caller remember): PolymorphicEntityTypeDescriptor.  On the ORM
side then I have a QuerySplitter that takes that query and makes a copy of
that entire SQM tree, one for each mapped implementor of the specified
class.  FWIW, ORM does this today, albeit in a different way.  Today we
split the query based on String manip and then feed it parser.  Here we
feed it to the parser and use the tree to split it; much less brittle :)

Really the cases where this would happen (one "concrete SQM" -> multiple
SQL) would be UPDATE and DELETE queries against "multi-table structures"
(inheritance, secondary tables).


For the purposes of OGM this phase ideally would not be tied to SQL,
> as we phase the same task with non-SQL backends in SQL. I.e. i'd be
> beneficial to have input -> semantic-tree ->
> semantic-output-query-tree(s) -> (SQL|non-SQL query). There
> "semantic-output-query-tree(s)" would be an abstract representation of
> the queries to be executed, e.g. referencing the table name(s). But it
> would be unaware of SQL specifics.
>

OGM would be doing this.  This SQM is the end result of the shared
library.  WHat each caller does with the SQM is up to that particular
caller.  We should consider moving QuerySplitter (its in my PoC, which now
acts as the PoC for using this in ORM) into the hibernate-sqm module.  Any
caller wanting to support those unmapped class references will need to do
the same thing.

BTW, another cool thing to note is the (still expanding) support for
"strict JPQL compliance" enforcement.

From guillaume.smet at gmail.com  Wed Aug 26 09:12:03 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 26 Aug 2015 15:12:03 +0200
Subject: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed
	interceptor
In-Reply-To: <CALt0+o-rqdU5QL6q6t5HgDkNQN+7PRNvBw8G3BND72Ka1fJCJw@mail.gmail.com>
References: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>
	<CAFdSV9sjK_HEi5B7ag0y9AtuNcdDr5_6XhgQF+Fnnf8MaY_Otw@mail.gmail.com>
	<CALt0+o-rqdU5QL6q6t5HgDkNQN+7PRNvBw8G3BND72Ka1fJCJw@mail.gmail.com>
Message-ID: <CALt0+o8EQC5Ey9ybo1QXYzrjf8qm7Gapi5-0f3GdB0qnT8AzFw@mail.gmail.com>

Hi Steve,

On Thu, May 7, 2015 at 5:37 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

>
> Yup, EntityManagerFactoryBuilderImpl.populate(SessionFactoryBuilder,
> StandardServiceRegistry) was my favorite spot too but it's currently
> private. Would you mind making it protected?
>

Working on my backlog for ORM 5 migration and looks like we missed this
one. Any chance it could be integrated in the next 5.x release?

Thanks!

From steve at hibernate.org  Wed Aug 26 09:34:43 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 13:34:43 +0000
Subject: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed
	interceptor
In-Reply-To: <CALt0+o8EQC5Ey9ybo1QXYzrjf8qm7Gapi5-0f3GdB0qnT8AzFw@mail.gmail.com>
References: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>
	<CAFdSV9sjK_HEi5B7ag0y9AtuNcdDr5_6XhgQF+Fnnf8MaY_Otw@mail.gmail.com>
	<CALt0+o-rqdU5QL6q6t5HgDkNQN+7PRNvBw8G3BND72Ka1fJCJw@mail.gmail.com>
	<CALt0+o8EQC5Ey9ybo1QXYzrjf8qm7Gapi5-0f3GdB0qnT8AzFw@mail.gmail.com>
Message-ID: <CAFdSV9tse=Czon+cyuD--YthOtjF31rLKVc0RBPDx2zKUum5vA@mail.gmail.com>

Is there a Jira?  PR?

On Wed, Aug 26, 2015, 8:12 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi Steve,
>
> On Thu, May 7, 2015 at 5:37 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>>
>> Yup, EntityManagerFactoryBuilderImpl.populate(SessionFactoryBuilder,
>> StandardServiceRegistry) was my favorite spot too but it's currently
>> private. Would you mind making it protected?
>>
>
> Working on my backlog for ORM 5 migration and looks like we missed this
> one. Any chance it could be integrated in the next 5.x release?
>
> Thanks!
>

From guillaume.smet at gmail.com  Wed Aug 26 09:54:31 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 26 Aug 2015 15:54:31 +0200
Subject: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed
	interceptor
In-Reply-To: <CAFdSV9tse=Czon+cyuD--YthOtjF31rLKVc0RBPDx2zKUum5vA@mail.gmail.com>
References: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>
	<CAFdSV9sjK_HEi5B7ag0y9AtuNcdDr5_6XhgQF+Fnnf8MaY_Otw@mail.gmail.com>
	<CALt0+o-rqdU5QL6q6t5HgDkNQN+7PRNvBw8G3BND72Ka1fJCJw@mail.gmail.com>
	<CALt0+o8EQC5Ey9ybo1QXYzrjf8qm7Gapi5-0f3GdB0qnT8AzFw@mail.gmail.com>
	<CAFdSV9tse=Czon+cyuD--YthOtjF31rLKVc0RBPDx2zKUum5vA@mail.gmail.com>
Message-ID: <CALt0+o8gKvqKrRKoOjLVra91CxeAP8X_1kk-p7zYq_Ommq856w@mail.gmail.com>

Nothing yet. Wanted to be sure you weren't against the principle of making
this method protected.

If you agree with this plan, I'll do the legwork.

On Wed, Aug 26, 2015 at 3:34 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Is there a Jira?  PR?
>
> On Wed, Aug 26, 2015, 8:12 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Hi Steve,
>>
>> On Thu, May 7, 2015 at 5:37 PM, Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>>>
>>> Yup, EntityManagerFactoryBuilderImpl.populate(SessionFactoryBuilder,
>>> StandardServiceRegistry) was my favorite spot too but it's currently
>>> private. Would you mind making it protected?
>>>
>>
>> Working on my backlog for ORM 5 migration and looks like we missed this
>> one. Any chance it could be integrated in the next 5.x release?
>>
>> Thanks!
>>
>

From steve at hibernate.org  Wed Aug 26 10:23:48 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 14:23:48 +0000
Subject: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed
	interceptor
In-Reply-To: <CALt0+o8gKvqKrRKoOjLVra91CxeAP8X_1kk-p7zYq_Ommq856w@mail.gmail.com>
References: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>
	<CAFdSV9sjK_HEi5B7ag0y9AtuNcdDr5_6XhgQF+Fnnf8MaY_Otw@mail.gmail.com>
	<CALt0+o-rqdU5QL6q6t5HgDkNQN+7PRNvBw8G3BND72Ka1fJCJw@mail.gmail.com>
	<CALt0+o8EQC5Ey9ybo1QXYzrjf8qm7Gapi5-0f3GdB0qnT8AzFw@mail.gmail.com>
	<CAFdSV9tse=Czon+cyuD--YthOtjF31rLKVc0RBPDx2zKUum5vA@mail.gmail.com>
	<CALt0+o8gKvqKrRKoOjLVra91CxeAP8X_1kk-p7zYq_Ommq856w@mail.gmail.com>
Message-ID: <CAFdSV9uZ9Oug1x-xtcJJeKfJfvknTLdDTnge24FSZZXUj3mwZQ@mail.gmail.com>

It's fine

On Wed, Aug 26, 2015, 8:54 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Nothing yet. Wanted to be sure you weren't against the principle of making
> this method protected.
>
> If you agree with this plan, I'll do the legwork.
>
> On Wed, Aug 26, 2015 at 3:34 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Is there a Jira?  PR?
>>
>> On Wed, Aug 26, 2015, 8:12 AM Guillaume Smet <guillaume.smet at gmail.com>
>> wrote:
>>
>>> Hi Steve,
>>>
>>> On Thu, May 7, 2015 at 5:37 PM, Guillaume Smet <guillaume.smet at gmail.com
>>> > wrote:
>>>
>>>>
>>>> Yup, EntityManagerFactoryBuilderImpl.populate(SessionFactoryBuilder,
>>>> StandardServiceRegistry) was my favorite spot too but it's currently
>>>> private. Would you mind making it protected?
>>>>
>>>
>>> Working on my backlog for ORM 5 migration and looks like we missed this
>>> one. Any chance it could be integrated in the next 5.x release?
>>>
>>> Thanks!
>>>
>>
>

From guillaume.smet at gmail.com  Wed Aug 26 10:40:42 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 26 Aug 2015 16:40:42 +0200
Subject: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed
	interceptor
In-Reply-To: <CAFdSV9uZ9Oug1x-xtcJJeKfJfvknTLdDTnge24FSZZXUj3mwZQ@mail.gmail.com>
References: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>
	<CAFdSV9sjK_HEi5B7ag0y9AtuNcdDr5_6XhgQF+Fnnf8MaY_Otw@mail.gmail.com>
	<CALt0+o-rqdU5QL6q6t5HgDkNQN+7PRNvBw8G3BND72Ka1fJCJw@mail.gmail.com>
	<CALt0+o8EQC5Ey9ybo1QXYzrjf8qm7Gapi5-0f3GdB0qnT8AzFw@mail.gmail.com>
	<CAFdSV9tse=Czon+cyuD--YthOtjF31rLKVc0RBPDx2zKUum5vA@mail.gmail.com>
	<CALt0+o8gKvqKrRKoOjLVra91CxeAP8X_1kk-p7zYq_Ommq856w@mail.gmail.com>
	<CAFdSV9uZ9Oug1x-xtcJJeKfJfvknTLdDTnge24FSZZXUj3mwZQ@mail.gmail.com>
Message-ID: <CALt0+o_RgQz1_BxGxr6TOLUnUWx9N5M+n6T4qY4CgwD7QSLbOA@mail.gmail.com>

Done: https://hibernate.atlassian.net/browse/HHH-10059

On Wed, Aug 26, 2015 at 4:23 PM, Steve Ebersole <steve at hibernate.org> wrote:

> It's fine
>
> On Wed, Aug 26, 2015, 8:54 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Nothing yet. Wanted to be sure you weren't against the principle of
>> making this method protected.
>>
>> If you agree with this plan, I'll do the legwork.
>>
>> On Wed, Aug 26, 2015 at 3:34 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Is there a Jira?  PR?
>>>
>>> On Wed, Aug 26, 2015, 8:12 AM Guillaume Smet <guillaume.smet at gmail.com>
>>> wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> On Thu, May 7, 2015 at 5:37 PM, Guillaume Smet <
>>>> guillaume.smet at gmail.com> wrote:
>>>>
>>>>>
>>>>> Yup, EntityManagerFactoryBuilderImpl.populate(SessionFactoryBuilder,
>>>>> StandardServiceRegistry) was my favorite spot too but it's currently
>>>>> private. Would you mind making it protected?
>>>>>
>>>>
>>>> Working on my backlog for ORM 5 migration and looks like we missed this
>>>> one. Any chance it could be integrated in the next 5.x release?
>>>>
>>>> Thanks!
>>>>
>>>
>>

From steve at hibernate.org  Wed Aug 26 13:27:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 17:27:29 +0000
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
	<CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
	<CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>
Message-ID: <CAFdSV9tz=+ZaO-qoNyZVpX-q1hvX+fnMp7OuRK3PsG27k=yg7A@mail.gmail.com>

Yes, but at this point lets make sure there is a Jira for any changes we
are making.

Also, I wanted to be specific that *no* clients of this code belong in this
repo.  I know y'all did that with the hibernate-hql-parser repo.  I just
want to be clear that that should *not* happen here.

On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <steve at hibernate.org> wrote:

> Yes
>
> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> +1 for the new repo. Just forked it and am looking into the amazing
>> things you guys built recently :)
>>
>> Can I push simple stuff to that repo right away (e.g. adding the
>> Eclipse plug-in to build.gradle)?
>>
>> Cheers,
>>
>> --Gunnar
>>
>>
>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> > I also created Jira project ->
>> https://hibernate.atlassian.net/projects/SQM
>> >
>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> I am starting that work here ->
>> >> https://github.com/hibernate/hibernate-semantic-query
>> >>
>> >>
>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <andrea at hibernate.org>
>> >> wrote:
>> >>
>> >>> no objections
>> >>>
>> >>> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>>
>> >>>> Anyone want to propose an alternative approach to what I have
>> working in
>> >>>> my Antlr 4 PoC?
>> >>>>
>> >>>> If not, I think we should move that work to a GitHub Hibernate org
>> repo
>> >>>> and start tracking work and Jiras there.  Objections?
>> >>>>
>> >>>> Also its no longer *just* HQL, we also plan to support JPA criteria
>> >>>> queries here, interpreting them into semantic query models.  As such
>> I
>> >>>> propose the top-level name of hibernate-query-parser, with 2 sub
>> projects:
>> >>>> hibernate-sqm and hibernate-query-interpreter
>> >>>>
>> >>>>
>> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <dreborier at gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> I see,
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>>>>
>> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
>> >>>>>>
>> >>>>>> But regardless, the children are not important for a stack, just
>> the
>> >>>>>> parent.  As I said when we discussed on ORC, the children are just
>> >>>>>> maintained because I used them for tests.
>> >>>>>>
>> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <
>> dreborier at gmail.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Hi Stevej
>> >>>>>>>
>> >>>>>>> I'm playing with you idea to remove the parent/child from the
>> >>>>>>> FromClause and introduce such a structure in the
>> FromClauseProcessor.
>> >>>>>>>
>> >>>>>>> just a question, in the current implementation a fromClause can
>> have
>> >>>>>>> more than one child fromClause , but I cannot figure out when
>> this happen :(
>> >>>>>>>
>> >>>>>>> Thanks a lot
>> >>>>>>>
>> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Andrea, this is in relation to something you asked me on IRC
>> today.
>> >>>>>>>> Specifically in regards to FromClause and the fact that it
>> maintains
>> >>>>>>>> pointers to parent/children.  As I said on IRC there is no
>> intrinsic
>> >>>>>>>> need
>> >>>>>>>> (I do not foresee) for keeping this structure; I really only did
>> that
>> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses and the
>> >>>>>>>> FromClause
>> >>>>>>>> itself made a simple place to do that.
>> >>>>>>>>
>> >>>>>>>> However, in later work I ran into minor problems because of that
>> >>>>>>>> decision.
>> >>>>>>>> I need to make a copy of an entire SelectStatement tree.  But
>> >>>>>>>> because the
>> >>>>>>>> FromClause is held twice (for non-root FromClauses) in the tree,
>> it
>> >>>>>>>> makes
>> >>>>>>>> it more complicated to do a "simple copy" than it need be.
>> >>>>>>>> Basically I
>> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>> >>>>>>>>
>> >>>>>>>> Long story short, I think I might revisit that decision and
>> instead
>> >>>>>>>> write a
>> >>>>>>>> dedicated stack in FromClauseProcessor for this.  In the
>> morning...
>> >>>>>>>> its too
>> >>>>>>>> late to start something that ambitious tonight.  I'll start that
>> in
>> >>>>>>>> the
>> >>>>>>>> morning, unless someone wants to pick that up in the next few
>> hours
>> >>>>>>>> before
>> >>>>>>>> I get back on line.
>> >>>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>>> hibernate-dev mailing list
>> >>>>>>>> hibernate-dev at lists.jboss.org
>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Aug 26 14:32:17 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 18:32:17 +0000
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator - thoughts?
Message-ID: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>

https://hibernate.atlassian.net/browse/SQM-11

From sanne at hibernate.org  Wed Aug 26 14:38:35 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 26 Aug 2015 19:38:35 +0100
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9tz=+ZaO-qoNyZVpX-q1hvX+fnMp7OuRK3PsG27k=yg7A@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
	<CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
	<CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>
	<CAFdSV9tz=+ZaO-qoNyZVpX-q1hvX+fnMp7OuRK3PsG27k=yg7A@mail.gmail.com>
Message-ID: <CAFm4XO39SNjT36a6h3ZVa2fSyP+64jzTUhXNimnLe0WXX99BNA@mail.gmail.com>

On 26 August 2015 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
> Yes, but at this point lets make sure there is a Jira for any changes we
> are making.
>
> Also, I wanted to be specific that *no* clients of this code belong in this
> repo.  I know y'all did that with the hibernate-hql-parser repo.  I just
> want to be clear that that should *not* happen here.

We had a short chat about this ^ on IRC; in summary I agree but we'll
have to deal with the following difficulties.

The obvious limitation of that is that each other project implementing
a tree walker will need to (potentially) adjust on internal tree
changes, but since that's obviously needed only when you upgrade the
parser version you want to use, the problem is deferred; assuming we
don't actually start all implementing such walkers until the tree is
relatively stable, that should be a fair enough limitation to not push
the burden of maintenance on the main parser maintainers, but keep the
effort as an opt-in choice for those wishing to upgrade.

The other little negative of that approach is that the current backend
which generates Lucene queries depends on Hibernate Search and is
consumed by both Hibernate OGM and by Infinispan, so having each
"consuming project" host the tree walker would either prevent OGM and
Infinispan to share the effort, or that would need an additional
separate repository, or we could host it within Hibernate Search as
some kind of parasite module (I'd rather not, for the same maintenance
reason).

We also wondered if the new parser should eventually be incorporated
within the Hibernate ORM repository. In terms of dependencies it would
not depend on hibernate-core so this would have no impact on other
consumers, other than coupling the release cycle to ORM.
Maybe this is premature to discuss as we certainly don't want it in
there at least until ORM actually uses it, but I think that for end
users it would be helpful to not have another dependency version to
align..

Thanks,
Sanne


>
> On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Yes
>>
>> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>>> +1 for the new repo. Just forked it and am looking into the amazing
>>> things you guys built recently :)
>>>
>>> Can I push simple stuff to that repo right away (e.g. adding the
>>> Eclipse plug-in to build.gradle)?
>>>
>>> Cheers,
>>>
>>> --Gunnar
>>>
>>>
>>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>> > I also created Jira project ->
>>> https://hibernate.atlassian.net/projects/SQM
>>> >
>>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> >
>>> >> I am starting that work here ->
>>> >> https://github.com/hibernate/hibernate-semantic-query
>>> >>
>>> >>
>>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <andrea at hibernate.org>
>>> >> wrote:
>>> >>
>>> >>> no objections
>>> >>>
>>> >>> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> >>>
>>> >>>> Anyone want to propose an alternative approach to what I have
>>> working in
>>> >>>> my Antlr 4 PoC?
>>> >>>>
>>> >>>> If not, I think we should move that work to a GitHub Hibernate org
>>> repo
>>> >>>> and start tracking work and Jiras there.  Objections?
>>> >>>>
>>> >>>> Also its no longer *just* HQL, we also plan to support JPA criteria
>>> >>>> queries here, interpreting them into semantic query models.  As such
>>> I
>>> >>>> propose the top-level name of hibernate-query-parser, with 2 sub
>>> projects:
>>> >>>> hibernate-sqm and hibernate-query-interpreter
>>> >>>>
>>> >>>>
>>> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <dreborier at gmail.com>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> I see,
>>> >>>>>
>>> >>>>> Thanks
>>> >>>>>
>>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> >>>>>
>>> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ...
>>> >>>>>>
>>> >>>>>> But regardless, the children are not important for a stack, just
>>> the
>>> >>>>>> parent.  As I said when we discussed on ORC, the children are just
>>> >>>>>> maintained because I used them for tests.
>>> >>>>>>
>>> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <
>>> dreborier at gmail.com>
>>> >>>>>> wrote:
>>> >>>>>>
>>> >>>>>>> Hi Stevej
>>> >>>>>>>
>>> >>>>>>> I'm playing with you idea to remove the parent/child from the
>>> >>>>>>> FromClause and introduce such a structure in the
>>> FromClauseProcessor.
>>> >>>>>>>
>>> >>>>>>> just a question, in the current implementation a fromClause can
>>> have
>>> >>>>>>> more than one child fromClause , but I cannot figure out when
>>> this happen :(
>>> >>>>>>>
>>> >>>>>>> Thanks a lot
>>> >>>>>>>
>>> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <steve at hibernate.org>
>>> >>>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>>> Andrea, this is in relation to something you asked me on IRC
>>> today.
>>> >>>>>>>> Specifically in regards to FromClause and the fact that it
>>> maintains
>>> >>>>>>>> pointers to parent/children.  As I said on IRC there is no
>>> intrinsic
>>> >>>>>>>> need
>>> >>>>>>>> (I do not foresee) for keeping this structure; I really only did
>>> that
>>> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses and the
>>> >>>>>>>> FromClause
>>> >>>>>>>> itself made a simple place to do that.
>>> >>>>>>>>
>>> >>>>>>>> However, in later work I ran into minor problems because of that
>>> >>>>>>>> decision.
>>> >>>>>>>> I need to make a copy of an entire SelectStatement tree.  But
>>> >>>>>>>> because the
>>> >>>>>>>> FromClause is held twice (for non-root FromClauses) in the tree,
>>> it
>>> >>>>>>>> makes
>>> >>>>>>>> it more complicated to do a "simple copy" than it need be.
>>> >>>>>>>> Basically I
>>> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>>> >>>>>>>>
>>> >>>>>>>> Long story short, I think I might revisit that decision and
>>> instead
>>> >>>>>>>> write a
>>> >>>>>>>> dedicated stack in FromClauseProcessor for this.  In the
>>> morning...
>>> >>>>>>>> its too
>>> >>>>>>>> late to start something that ambitious tonight.  I'll start that
>>> in
>>> >>>>>>>> the
>>> >>>>>>>> morning, unless someone wants to pick that up in the next few
>>> hours
>>> >>>>>>>> before
>>> >>>>>>>> I get back on line.
>>> >>>>>>>>
>>> >>>>>>> _______________________________________________
>>> >>>>>>>> hibernate-dev mailing list
>>> >>>>>>>> hibernate-dev at lists.jboss.org
>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>
>>> >>>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Aug 26 16:32:39 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 20:32:39 +0000
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFm4XO39SNjT36a6h3ZVa2fSyP+64jzTUhXNimnLe0WXX99BNA@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
	<CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
	<CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>
	<CAFdSV9tz=+ZaO-qoNyZVpX-q1hvX+fnMp7OuRK3PsG27k=yg7A@mail.gmail.com>
	<CAFm4XO39SNjT36a6h3ZVa2fSyP+64jzTUhXNimnLe0WXX99BNA@mail.gmail.com>
Message-ID: <CAFdSV9soXNZQSqZjJ-Z8sDzTiSpvR2=1huFwf0JsOcQPZVWW=Q@mail.gmail.com>

I think I'd like to rename this repo and the 2 modules.  I think its easier
to call the overall repo hibernate-sqm.  And then within that rename the 2
modules:
* hibernate-sqm -> hibernate-sqm-model
* hibernate-query-interpreter -> ?

Still not sure what to call this "query->SQM" module.  Thoughts?


On Wed, Aug 26, 2015 at 1:39 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 26 August 2015 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
> > Yes, but at this point lets make sure there is a Jira for any changes we
> > are making.
> >
> > Also, I wanted to be specific that *no* clients of this code belong in
> this
> > repo.  I know y'all did that with the hibernate-hql-parser repo.  I just
> > want to be clear that that should *not* happen here.
>
> We had a short chat about this ^ on IRC; in summary I agree but we'll
> have to deal with the following difficulties.
>
> The obvious limitation of that is that each other project implementing
> a tree walker will need to (potentially) adjust on internal tree
> changes, but since that's obviously needed only when you upgrade the
> parser version you want to use, the problem is deferred; assuming we
> don't actually start all implementing such walkers until the tree is
> relatively stable, that should be a fair enough limitation to not push
> the burden of maintenance on the main parser maintainers, but keep the
> effort as an opt-in choice for those wishing to upgrade.
>
> The other little negative of that approach is that the current backend
> which generates Lucene queries depends on Hibernate Search and is
> consumed by both Hibernate OGM and by Infinispan, so having each
> "consuming project" host the tree walker would either prevent OGM and
> Infinispan to share the effort, or that would need an additional
> separate repository, or we could host it within Hibernate Search as
> some kind of parasite module (I'd rather not, for the same maintenance
> reason).
>
> We also wondered if the new parser should eventually be incorporated
> within the Hibernate ORM repository. In terms of dependencies it would
> not depend on hibernate-core so this would have no impact on other
> consumers, other than coupling the release cycle to ORM.
> Maybe this is premature to discuss as we certainly don't want it in
> there at least until ORM actually uses it, but I think that for end
> users it would be helpful to not have another dependency version to
> align..
>
> Thanks,
> Sanne
>
>
> >
> > On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Yes
> >>
> >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >>> +1 for the new repo. Just forked it and am looking into the amazing
> >>> things you guys built recently :)
> >>>
> >>> Can I push simple stuff to that repo right away (e.g. adding the
> >>> Eclipse plug-in to build.gradle)?
> >>>
> >>> Cheers,
> >>>
> >>> --Gunnar
> >>>
> >>>
> >>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >>> > I also created Jira project ->
> >>> https://hibernate.atlassian.net/projects/SQM
> >>> >
> >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>> >
> >>> >> I am starting that work here ->
> >>> >> https://github.com/hibernate/hibernate-semantic-query
> >>> >>
> >>> >>
> >>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <
> andrea at hibernate.org>
> >>> >> wrote:
> >>> >>
> >>> >>> no objections
> >>> >>>
> >>> >>> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>> >>>
> >>> >>>> Anyone want to propose an alternative approach to what I have
> >>> working in
> >>> >>>> my Antlr 4 PoC?
> >>> >>>>
> >>> >>>> If not, I think we should move that work to a GitHub Hibernate org
> >>> repo
> >>> >>>> and start tracking work and Jiras there.  Objections?
> >>> >>>>
> >>> >>>> Also its no longer *just* HQL, we also plan to support JPA
> criteria
> >>> >>>> queries here, interpreting them into semantic query models.  As
> such
> >>> I
> >>> >>>> propose the top-level name of hibernate-query-parser, with 2 sub
> >>> projects:
> >>> >>>> hibernate-sqm and hibernate-query-interpreter
> >>> >>>>
> >>> >>>>
> >>> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <
> dreborier at gmail.com>
> >>> >>>> wrote:
> >>> >>>>
> >>> >>>>> I see,
> >>> >>>>>
> >>> >>>>> Thanks
> >>> >>>>>
> >>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>> >>>>>
> >>> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...)
> ...
> >>> >>>>>>
> >>> >>>>>> But regardless, the children are not important for a stack, just
> >>> the
> >>> >>>>>> parent.  As I said when we discussed on ORC, the children are
> just
> >>> >>>>>> maintained because I used them for tests.
> >>> >>>>>>
> >>> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <
> >>> dreborier at gmail.com>
> >>> >>>>>> wrote:
> >>> >>>>>>
> >>> >>>>>>> Hi Stevej
> >>> >>>>>>>
> >>> >>>>>>> I'm playing with you idea to remove the parent/child from the
> >>> >>>>>>> FromClause and introduce such a structure in the
> >>> FromClauseProcessor.
> >>> >>>>>>>
> >>> >>>>>>> just a question, in the current implementation a fromClause can
> >>> have
> >>> >>>>>>> more than one child fromClause , but I cannot figure out when
> >>> this happen :(
> >>> >>>>>>>
> >>> >>>>>>> Thanks a lot
> >>> >>>>>>>
> >>> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <
> steve at hibernate.org>
> >>> >>>>>>> wrote:
> >>> >>>>>>>
> >>> >>>>>>>> Andrea, this is in relation to something you asked me on IRC
> >>> today.
> >>> >>>>>>>> Specifically in regards to FromClause and the fact that it
> >>> maintains
> >>> >>>>>>>> pointers to parent/children.  As I said on IRC there is no
> >>> intrinsic
> >>> >>>>>>>> need
> >>> >>>>>>>> (I do not foresee) for keeping this structure; I really only
> did
> >>> that
> >>> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses and
> the
> >>> >>>>>>>> FromClause
> >>> >>>>>>>> itself made a simple place to do that.
> >>> >>>>>>>>
> >>> >>>>>>>> However, in later work I ran into minor problems because of
> that
> >>> >>>>>>>> decision.
> >>> >>>>>>>> I need to make a copy of an entire SelectStatement tree.  But
> >>> >>>>>>>> because the
> >>> >>>>>>>> FromClause is held twice (for non-root FromClauses) in the
> tree,
> >>> it
> >>> >>>>>>>> makes
> >>> >>>>>>>> it more complicated to do a "simple copy" than it need be.
> >>> >>>>>>>> Basically I
> >>> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
> >>> >>>>>>>>
> >>> >>>>>>>> Long story short, I think I might revisit that decision and
> >>> instead
> >>> >>>>>>>> write a
> >>> >>>>>>>> dedicated stack in FromClauseProcessor for this.  In the
> >>> morning...
> >>> >>>>>>>> its too
> >>> >>>>>>>> late to start something that ambitious tonight.  I'll start
> that
> >>> in
> >>> >>>>>>>> the
> >>> >>>>>>>> morning, unless someone wants to pick that up in the next few
> >>> hours
> >>> >>>>>>>> before
> >>> >>>>>>>> I get back on line.
> >>> >>>>>>>>
> >>> >>>>>>> _______________________________________________
> >>> >>>>>>>> hibernate-dev mailing list
> >>> >>>>>>>> hibernate-dev at lists.jboss.org
> >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >>>>>>>>
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>
> >>> >>>
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Aug 26 16:58:39 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 26 Aug 2015 21:58:39 +0100
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
Message-ID: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>

Assuming you build a Lucene Query the following way:

    queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();

What is your expectation, if the "age" field is being indexed as a NumericField?

Thanks,
Sanne

From gunnar at hibernate.org  Wed Aug 26 17:24:23 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 26 Aug 2015 23:24:23 +0200
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9soXNZQSqZjJ-Z8sDzTiSpvR2=1huFwf0JsOcQPZVWW=Q@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
	<CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
	<CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>
	<CAFdSV9tz=+ZaO-qoNyZVpX-q1hvX+fnMp7OuRK3PsG27k=yg7A@mail.gmail.com>
	<CAFm4XO39SNjT36a6h3ZVa2fSyP+64jzTUhXNimnLe0WXX99BNA@mail.gmail.com>
	<CAFdSV9soXNZQSqZjJ-Z8sDzTiSpvR2=1huFwf0JsOcQPZVWW=Q@mail.gmail.com>
Message-ID: <CADGJaX9BZwyFdV97OTTexHswJtJP_W0Uf3Sx2fyo5cFr6ccvyw@mail.gmail.com>

hibernate-query-parser?

2015-08-26 22:32 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> I think I'd like to rename this repo and the 2 modules.  I think its easier
> to call the overall repo hibernate-sqm.  And then within that rename the 2
> modules:
> * hibernate-sqm -> hibernate-sqm-model
> * hibernate-query-interpreter -> ?
>
> Still not sure what to call this "query->SQM" module.  Thoughts?
>
>
> On Wed, Aug 26, 2015 at 1:39 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> On 26 August 2015 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
>> > Yes, but at this point lets make sure there is a Jira for any changes we
>> > are making.
>> >
>> > Also, I wanted to be specific that *no* clients of this code belong in
>> this
>> > repo.  I know y'all did that with the hibernate-hql-parser repo.  I just
>> > want to be clear that that should *not* happen here.
>>
>> We had a short chat about this ^ on IRC; in summary I agree but we'll
>> have to deal with the following difficulties.
>>
>> The obvious limitation of that is that each other project implementing
>> a tree walker will need to (potentially) adjust on internal tree
>> changes, but since that's obviously needed only when you upgrade the
>> parser version you want to use, the problem is deferred; assuming we
>> don't actually start all implementing such walkers until the tree is
>> relatively stable, that should be a fair enough limitation to not push
>> the burden of maintenance on the main parser maintainers, but keep the
>> effort as an opt-in choice for those wishing to upgrade.
>>
>> The other little negative of that approach is that the current backend
>> which generates Lucene queries depends on Hibernate Search and is
>> consumed by both Hibernate OGM and by Infinispan, so having each
>> "consuming project" host the tree walker would either prevent OGM and
>> Infinispan to share the effort, or that would need an additional
>> separate repository, or we could host it within Hibernate Search as
>> some kind of parasite module (I'd rather not, for the same maintenance
>> reason).
>>
>> We also wondered if the new parser should eventually be incorporated
>> within the Hibernate ORM repository. In terms of dependencies it would
>> not depend on hibernate-core so this would have no impact on other
>> consumers, other than coupling the release cycle to ORM.
>> Maybe this is premature to discuss as we certainly don't want it in
>> there at least until ORM actually uses it, but I think that for end
>> users it would be helpful to not have another dependency version to
>> align..
>>
>> Thanks,
>> Sanne
>>
>>
>> >
>> > On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> Yes
>> >>
>> >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >>
>> >>> +1 for the new repo. Just forked it and am looking into the amazing
>> >>> things you guys built recently :)
>> >>>
>> >>> Can I push simple stuff to that repo right away (e.g. adding the
>> >>> Eclipse plug-in to build.gradle)?
>> >>>
>> >>> Cheers,
>> >>>
>> >>> --Gunnar
>> >>>
>> >>>
>> >>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> >>> > I also created Jira project ->
>> >>> https://hibernate.atlassian.net/projects/SQM
>> >>> >
>> >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve at hibernate.org>
>> >>> wrote:
>> >>> >
>> >>> >> I am starting that work here ->
>> >>> >> https://github.com/hibernate/hibernate-semantic-query
>> >>> >>
>> >>> >>
>> >>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <
>> andrea at hibernate.org>
>> >>> >> wrote:
>> >>> >>
>> >>> >>> no objections
>> >>> >>>
>> >>> >>> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org>
>> >>> wrote:
>> >>> >>>
>> >>> >>>> Anyone want to propose an alternative approach to what I have
>> >>> working in
>> >>> >>>> my Antlr 4 PoC?
>> >>> >>>>
>> >>> >>>> If not, I think we should move that work to a GitHub Hibernate org
>> >>> repo
>> >>> >>>> and start tracking work and Jiras there.  Objections?
>> >>> >>>>
>> >>> >>>> Also its no longer *just* HQL, we also plan to support JPA
>> criteria
>> >>> >>>> queries here, interpreting them into semantic query models.  As
>> such
>> >>> I
>> >>> >>>> propose the top-level name of hibernate-query-parser, with 2 sub
>> >>> projects:
>> >>> >>>> hibernate-sqm and hibernate-query-interpreter
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <
>> dreborier at gmail.com>
>> >>> >>>> wrote:
>> >>> >>>>
>> >>> >>>>> I see,
>> >>> >>>>>
>> >>> >>>>> Thanks
>> >>> >>>>>
>> >>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at hibernate.org>
>> >>> wrote:
>> >>> >>>>>
>> >>> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...)
>> ...
>> >>> >>>>>>
>> >>> >>>>>> But regardless, the children are not important for a stack, just
>> >>> the
>> >>> >>>>>> parent.  As I said when we discussed on ORC, the children are
>> just
>> >>> >>>>>> maintained because I used them for tests.
>> >>> >>>>>>
>> >>> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <
>> >>> dreborier at gmail.com>
>> >>> >>>>>> wrote:
>> >>> >>>>>>
>> >>> >>>>>>> Hi Stevej
>> >>> >>>>>>>
>> >>> >>>>>>> I'm playing with you idea to remove the parent/child from the
>> >>> >>>>>>> FromClause and introduce such a structure in the
>> >>> FromClauseProcessor.
>> >>> >>>>>>>
>> >>> >>>>>>> just a question, in the current implementation a fromClause can
>> >>> have
>> >>> >>>>>>> more than one child fromClause , but I cannot figure out when
>> >>> this happen :(
>> >>> >>>>>>>
>> >>> >>>>>>> Thanks a lot
>> >>> >>>>>>>
>> >>> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <
>> steve at hibernate.org>
>> >>> >>>>>>> wrote:
>> >>> >>>>>>>
>> >>> >>>>>>>> Andrea, this is in relation to something you asked me on IRC
>> >>> today.
>> >>> >>>>>>>> Specifically in regards to FromClause and the fact that it
>> >>> maintains
>> >>> >>>>>>>> pointers to parent/children.  As I said on IRC there is no
>> >>> intrinsic
>> >>> >>>>>>>> need
>> >>> >>>>>>>> (I do not foresee) for keeping this structure; I really only
>> did
>> >>> that
>> >>> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses and
>> the
>> >>> >>>>>>>> FromClause
>> >>> >>>>>>>> itself made a simple place to do that.
>> >>> >>>>>>>>
>> >>> >>>>>>>> However, in later work I ran into minor problems because of
>> that
>> >>> >>>>>>>> decision.
>> >>> >>>>>>>> I need to make a copy of an entire SelectStatement tree.  But
>> >>> >>>>>>>> because the
>> >>> >>>>>>>> FromClause is held twice (for non-root FromClauses) in the
>> tree,
>> >>> it
>> >>> >>>>>>>> makes
>> >>> >>>>>>>> it more complicated to do a "simple copy" than it need be.
>> >>> >>>>>>>> Basically I
>> >>> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
>> >>> >>>>>>>>
>> >>> >>>>>>>> Long story short, I think I might revisit that decision and
>> >>> instead
>> >>> >>>>>>>> write a
>> >>> >>>>>>>> dedicated stack in FromClauseProcessor for this.  In the
>> >>> morning...
>> >>> >>>>>>>> its too
>> >>> >>>>>>>> late to start something that ambitious tonight.  I'll start
>> that
>> >>> in
>> >>> >>>>>>>> the
>> >>> >>>>>>>> morning, unless someone wants to pick that up in the next few
>> >>> hours
>> >>> >>>>>>>> before
>> >>> >>>>>>>> I get back on line.
>> >>> >>>>>>>>
>> >>> >>>>>>> _______________________________________________
>> >>> >>>>>>>> hibernate-dev mailing list
>> >>> >>>>>>>> hibernate-dev at lists.jboss.org
>> >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> >>>>>>>>
>> >>> >>>>>>>
>> >>> >>>>>>>
>> >>> >>>>>
>> >>> >>>
>> >>> > _______________________________________________
>> >>> > hibernate-dev mailing list
>> >>> > hibernate-dev at lists.jboss.org
>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Aug 26 18:20:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 26 Aug 2015 22:20:33 +0000
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CADGJaX9BZwyFdV97OTTexHswJtJP_W0Uf3Sx2fyo5cFr6ccvyw@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
	<CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
	<CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>
	<CAFdSV9tz=+ZaO-qoNyZVpX-q1hvX+fnMp7OuRK3PsG27k=yg7A@mail.gmail.com>
	<CAFm4XO39SNjT36a6h3ZVa2fSyP+64jzTUhXNimnLe0WXX99BNA@mail.gmail.com>
	<CAFdSV9soXNZQSqZjJ-Z8sDzTiSpvR2=1huFwf0JsOcQPZVWW=Q@mail.gmail.com>
	<CADGJaX9BZwyFdV97OTTexHswJtJP_W0Uf3Sx2fyo5cFr6ccvyw@mail.gmail.com>
Message-ID: <CAFdSV9ty4Ndzenh+r=ACgw6OonAk6NFW3qtjr8TRgPteeTYo=g@mail.gmail.com>

I'm ok with that.  Everyone else?


On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> hibernate-query-parser?
>
> 2015-08-26 22:32 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> > I think I'd like to rename this repo and the 2 modules.  I think its
> easier
> > to call the overall repo hibernate-sqm.  And then within that rename the
> 2
> > modules:
> > * hibernate-sqm -> hibernate-sqm-model
> > * hibernate-query-interpreter -> ?
> >
> > Still not sure what to call this "query->SQM" module.  Thoughts?
> >
> >
> > On Wed, Aug 26, 2015 at 1:39 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >
> >> On 26 August 2015 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
> >> > Yes, but at this point lets make sure there is a Jira for any changes
> we
> >> > are making.
> >> >
> >> > Also, I wanted to be specific that *no* clients of this code belong in
> >> this
> >> > repo.  I know y'all did that with the hibernate-hql-parser repo.  I
> just
> >> > want to be clear that that should *not* happen here.
> >>
> >> We had a short chat about this ^ on IRC; in summary I agree but we'll
> >> have to deal with the following difficulties.
> >>
> >> The obvious limitation of that is that each other project implementing
> >> a tree walker will need to (potentially) adjust on internal tree
> >> changes, but since that's obviously needed only when you upgrade the
> >> parser version you want to use, the problem is deferred; assuming we
> >> don't actually start all implementing such walkers until the tree is
> >> relatively stable, that should be a fair enough limitation to not push
> >> the burden of maintenance on the main parser maintainers, but keep the
> >> effort as an opt-in choice for those wishing to upgrade.
> >>
> >> The other little negative of that approach is that the current backend
> >> which generates Lucene queries depends on Hibernate Search and is
> >> consumed by both Hibernate OGM and by Infinispan, so having each
> >> "consuming project" host the tree walker would either prevent OGM and
> >> Infinispan to share the effort, or that would need an additional
> >> separate repository, or we could host it within Hibernate Search as
> >> some kind of parasite module (I'd rather not, for the same maintenance
> >> reason).
> >>
> >> We also wondered if the new parser should eventually be incorporated
> >> within the Hibernate ORM repository. In terms of dependencies it would
> >> not depend on hibernate-core so this would have no impact on other
> >> consumers, other than coupling the release cycle to ORM.
> >> Maybe this is premature to discuss as we certainly don't want it in
> >> there at least until ORM actually uses it, but I think that for end
> >> users it would be helpful to not have another dependency version to
> >> align..
> >>
> >> Thanks,
> >> Sanne
> >>
> >>
> >> >
> >> > On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >> >
> >> >> Yes
> >> >>
> >> >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >> >>
> >> >>> +1 for the new repo. Just forked it and am looking into the amazing
> >> >>> things you guys built recently :)
> >> >>>
> >> >>> Can I push simple stuff to that repo right away (e.g. adding the
> >> >>> Eclipse plug-in to build.gradle)?
> >> >>>
> >> >>> Cheers,
> >> >>>
> >> >>> --Gunnar
> >> >>>
> >> >>>
> >> >>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >> >>> > I also created Jira project ->
> >> >>> https://hibernate.atlassian.net/projects/SQM
> >> >>> >
> >> >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <
> steve at hibernate.org>
> >> >>> wrote:
> >> >>> >
> >> >>> >> I am starting that work here ->
> >> >>> >> https://github.com/hibernate/hibernate-semantic-query
> >> >>> >>
> >> >>> >>
> >> >>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <
> >> andrea at hibernate.org>
> >> >>> >> wrote:
> >> >>> >>
> >> >>> >>> no objections
> >> >>> >>>
> >> >>> >>> On 25 August 2015 at 20:12, Steve Ebersole <steve at hibernate.org
> >
> >> >>> wrote:
> >> >>> >>>
> >> >>> >>>> Anyone want to propose an alternative approach to what I have
> >> >>> working in
> >> >>> >>>> my Antlr 4 PoC?
> >> >>> >>>>
> >> >>> >>>> If not, I think we should move that work to a GitHub Hibernate
> org
> >> >>> repo
> >> >>> >>>> and start tracking work and Jiras there.  Objections?
> >> >>> >>>>
> >> >>> >>>> Also its no longer *just* HQL, we also plan to support JPA
> >> criteria
> >> >>> >>>> queries here, interpreting them into semantic query models.  As
> >> such
> >> >>> I
> >> >>> >>>> propose the top-level name of hibernate-query-parser, with 2
> sub
> >> >>> projects:
> >> >>> >>>> hibernate-sqm and hibernate-query-interpreter
> >> >>> >>>>
> >> >>> >>>>
> >> >>> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <
> >> dreborier at gmail.com>
> >> >>> >>>> wrote:
> >> >>> >>>>
> >> >>> >>>>> I see,
> >> >>> >>>>>
> >> >>> >>>>> Thanks
> >> >>> >>>>>
> >> >>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <
> steve at hibernate.org>
> >> >>> wrote:
> >> >>> >>>>>
> >> >>> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...)
> >> ...
> >> >>> >>>>>>
> >> >>> >>>>>> But regardless, the children are not important for a stack,
> just
> >> >>> the
> >> >>> >>>>>> parent.  As I said when we discussed on ORC, the children are
> >> just
> >> >>> >>>>>> maintained because I used them for tests.
> >> >>> >>>>>>
> >> >>> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <
> >> >>> dreborier at gmail.com>
> >> >>> >>>>>> wrote:
> >> >>> >>>>>>
> >> >>> >>>>>>> Hi Stevej
> >> >>> >>>>>>>
> >> >>> >>>>>>> I'm playing with you idea to remove the parent/child from
> the
> >> >>> >>>>>>> FromClause and introduce such a structure in the
> >> >>> FromClauseProcessor.
> >> >>> >>>>>>>
> >> >>> >>>>>>> just a question, in the current implementation a fromClause
> can
> >> >>> have
> >> >>> >>>>>>> more than one child fromClause , but I cannot figure out
> when
> >> >>> this happen :(
> >> >>> >>>>>>>
> >> >>> >>>>>>> Thanks a lot
> >> >>> >>>>>>>
> >> >>> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <
> >> steve at hibernate.org>
> >> >>> >>>>>>> wrote:
> >> >>> >>>>>>>
> >> >>> >>>>>>>> Andrea, this is in relation to something you asked me on
> IRC
> >> >>> today.
> >> >>> >>>>>>>> Specifically in regards to FromClause and the fact that it
> >> >>> maintains
> >> >>> >>>>>>>> pointers to parent/children.  As I said on IRC there is no
> >> >>> intrinsic
> >> >>> >>>>>>>> need
> >> >>> >>>>>>>> (I do not foresee) for keeping this structure; I really
> only
> >> did
> >> >>> that
> >> >>> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses
> and
> >> the
> >> >>> >>>>>>>> FromClause
> >> >>> >>>>>>>> itself made a simple place to do that.
> >> >>> >>>>>>>>
> >> >>> >>>>>>>> However, in later work I ran into minor problems because of
> >> that
> >> >>> >>>>>>>> decision.
> >> >>> >>>>>>>> I need to make a copy of an entire SelectStatement tree.
> But
> >> >>> >>>>>>>> because the
> >> >>> >>>>>>>> FromClause is held twice (for non-root FromClauses) in the
> >> tree,
> >> >>> it
> >> >>> >>>>>>>> makes
> >> >>> >>>>>>>> it more complicated to do a "simple copy" than it need be.
> >> >>> >>>>>>>> Basically I
> >> >>> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :(
> >> >>> >>>>>>>>
> >> >>> >>>>>>>> Long story short, I think I might revisit that decision and
> >> >>> instead
> >> >>> >>>>>>>> write a
> >> >>> >>>>>>>> dedicated stack in FromClauseProcessor for this.  In the
> >> >>> morning...
> >> >>> >>>>>>>> its too
> >> >>> >>>>>>>> late to start something that ambitious tonight.  I'll start
> >> that
> >> >>> in
> >> >>> >>>>>>>> the
> >> >>> >>>>>>>> morning, unless someone wants to pick that up in the next
> few
> >> >>> hours
> >> >>> >>>>>>>> before
> >> >>> >>>>>>>> I get back on line.
> >> >>> >>>>>>>>
> >> >>> >>>>>>> _______________________________________________
> >> >>> >>>>>>>> hibernate-dev mailing list
> >> >>> >>>>>>>> hibernate-dev at lists.jboss.org
> >> >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>> >>>>>>>>
> >> >>> >>>>>>>
> >> >>> >>>>>>>
> >> >>> >>>>>
> >> >>> >>>
> >> >>> > _______________________________________________
> >> >>> > hibernate-dev mailing list
> >> >>> > hibernate-dev at lists.jboss.org
> >> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>>
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From wolfgang at crypteron.com  Thu Aug 27 00:38:54 2015
From: wolfgang at crypteron.com (Wolfgang Wedemeyer)
Date: Wed, 26 Aug 2015 21:38:54 -0700
Subject: [hibernate-dev] Hibernate Integrator Causes Flush When Using JPA
	Transactions Around Queries
Message-ID: <9CA903B5-7CAD-4E0A-89AE-242C915B7B65@crypteron.com>

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

From sanne at hibernate.org  Thu Aug 27 05:09:06 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 27 Aug 2015 10:09:06 +0100
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFdSV9ty4Ndzenh+r=ACgw6OonAk6NFW3qtjr8TRgPteeTYo=g@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
	<CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
	<CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>
	<CAFdSV9tz=+ZaO-qoNyZVpX-q1hvX+fnMp7OuRK3PsG27k=yg7A@mail.gmail.com>
	<CAFm4XO39SNjT36a6h3ZVa2fSyP+64jzTUhXNimnLe0WXX99BNA@mail.gmail.com>
	<CAFdSV9soXNZQSqZjJ-Z8sDzTiSpvR2=1huFwf0JsOcQPZVWW=Q@mail.gmail.com>
	<CADGJaX9BZwyFdV97OTTexHswJtJP_W0Uf3Sx2fyo5cFr6ccvyw@mail.gmail.com>
	<CAFdSV9ty4Ndzenh+r=ACgw6OonAk6NFW3qtjr8TRgPteeTYo=g@mail.gmail.com>
Message-ID: <CAFm4XO3BRv8VxMWkVrQQgUw76yZseKWn_tiJ4ZYdZqMEX-0dWA@mail.gmail.com>

On 26 August 2015 at 23:20, Steve Ebersole <steve at hibernate.org> wrote:
> I'm ok with that.  Everyone else?
>
>
> On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> hibernate-query-parser?

+1

>>
>> 2015-08-26 22:32 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> > I think I'd like to rename this repo and the 2 modules.  I think its
>> > easier
>> > to call the overall repo hibernate-sqm.  And then within that rename the
>> > 2
>> > modules:
>> > * hibernate-sqm -> hibernate-sqm-model
>> > * hibernate-query-interpreter -> ?
>> >
>> > Still not sure what to call this "query->SQM" module.  Thoughts?
>> >
>> >
>> > On Wed, Aug 26, 2015 at 1:39 PM Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >
>> >> On 26 August 2015 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > Yes, but at this point lets make sure there is a Jira for any changes
>> >> > we
>> >> > are making.
>> >> >
>> >> > Also, I wanted to be specific that *no* clients of this code belong
>> >> > in
>> >> this
>> >> > repo.  I know y'all did that with the hibernate-hql-parser repo.  I
>> >> > just
>> >> > want to be clear that that should *not* happen here.
>> >>
>> >> We had a short chat about this ^ on IRC; in summary I agree but we'll
>> >> have to deal with the following difficulties.
>> >>
>> >> The obvious limitation of that is that each other project implementing
>> >> a tree walker will need to (potentially) adjust on internal tree
>> >> changes, but since that's obviously needed only when you upgrade the
>> >> parser version you want to use, the problem is deferred; assuming we
>> >> don't actually start all implementing such walkers until the tree is
>> >> relatively stable, that should be a fair enough limitation to not push
>> >> the burden of maintenance on the main parser maintainers, but keep the
>> >> effort as an opt-in choice for those wishing to upgrade.
>> >>
>> >> The other little negative of that approach is that the current backend
>> >> which generates Lucene queries depends on Hibernate Search and is
>> >> consumed by both Hibernate OGM and by Infinispan, so having each
>> >> "consuming project" host the tree walker would either prevent OGM and
>> >> Infinispan to share the effort, or that would need an additional
>> >> separate repository, or we could host it within Hibernate Search as
>> >> some kind of parasite module (I'd rather not, for the same maintenance
>> >> reason).
>> >>
>> >> We also wondered if the new parser should eventually be incorporated
>> >> within the Hibernate ORM repository. In terms of dependencies it would
>> >> not depend on hibernate-core so this would have no impact on other
>> >> consumers, other than coupling the release cycle to ORM.
>> >> Maybe this is premature to discuss as we certainly don't want it in
>> >> there at least until ORM actually uses it, but I think that for end
>> >> users it would be helpful to not have another dependency version to
>> >> align..
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >>
>> >> >
>> >> > On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >> >
>> >> >> Yes
>> >> >>
>> >> >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >> >>
>> >> >>> +1 for the new repo. Just forked it and am looking into the amazing
>> >> >>> things you guys built recently :)
>> >> >>>
>> >> >>> Can I push simple stuff to that repo right away (e.g. adding the
>> >> >>> Eclipse plug-in to build.gradle)?
>> >> >>>
>> >> >>> Cheers,
>> >> >>>
>> >> >>> --Gunnar
>> >> >>>
>> >> >>>
>> >> >>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> >> >>> > I also created Jira project ->
>> >> >>> https://hibernate.atlassian.net/projects/SQM
>> >> >>> >
>> >> >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole
>> >> >>> > <steve at hibernate.org>
>> >> >>> wrote:
>> >> >>> >
>> >> >>> >> I am starting that work here ->
>> >> >>> >> https://github.com/hibernate/hibernate-semantic-query
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <
>> >> andrea at hibernate.org>
>> >> >>> >> wrote:
>> >> >>> >>
>> >> >>> >>> no objections
>> >> >>> >>>
>> >> >>> >>> On 25 August 2015 at 20:12, Steve Ebersole
>> >> >>> >>> <steve at hibernate.org>
>> >> >>> wrote:
>> >> >>> >>>
>> >> >>> >>>> Anyone want to propose an alternative approach to what I have
>> >> >>> working in
>> >> >>> >>>> my Antlr 4 PoC?
>> >> >>> >>>>
>> >> >>> >>>> If not, I think we should move that work to a GitHub Hibernate
>> >> >>> >>>> org
>> >> >>> repo
>> >> >>> >>>> and start tracking work and Jiras there.  Objections?
>> >> >>> >>>>
>> >> >>> >>>> Also its no longer *just* HQL, we also plan to support JPA
>> >> criteria
>> >> >>> >>>> queries here, interpreting them into semantic query models.
>> >> >>> >>>> As
>> >> such
>> >> >>> I
>> >> >>> >>>> propose the top-level name of hibernate-query-parser, with 2
>> >> >>> >>>> sub
>> >> >>> projects:
>> >> >>> >>>> hibernate-sqm and hibernate-query-interpreter
>> >> >>> >>>>
>> >> >>> >>>>
>> >> >>> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <
>> >> dreborier at gmail.com>
>> >> >>> >>>> wrote:
>> >> >>> >>>>
>> >> >>> >>>>> I see,
>> >> >>> >>>>>
>> >> >>> >>>>> Thanks
>> >> >>> >>>>>
>> >> >>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole
>> >> >>> >>>>> <steve at hibernate.org>
>> >> >>> wrote:
>> >> >>> >>>>>
>> >> >>> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c
>> >> >>> >>>>>> ...)
>> >> ...
>> >> >>> >>>>>>
>> >> >>> >>>>>> But regardless, the children are not important for a stack,
>> >> >>> >>>>>> just
>> >> >>> the
>> >> >>> >>>>>> parent.  As I said when we discussed on ORC, the children
>> >> >>> >>>>>> are
>> >> just
>> >> >>> >>>>>> maintained because I used them for tests.
>> >> >>> >>>>>>
>> >> >>> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <
>> >> >>> dreborier at gmail.com>
>> >> >>> >>>>>> wrote:
>> >> >>> >>>>>>
>> >> >>> >>>>>>> Hi Stevej
>> >> >>> >>>>>>>
>> >> >>> >>>>>>> I'm playing with you idea to remove the parent/child from
>> >> >>> >>>>>>> the
>> >> >>> >>>>>>> FromClause and introduce such a structure in the
>> >> >>> FromClauseProcessor.
>> >> >>> >>>>>>>
>> >> >>> >>>>>>> just a question, in the current implementation a fromClause
>> >> >>> >>>>>>> can
>> >> >>> have
>> >> >>> >>>>>>> more than one child fromClause , but I cannot figure out
>> >> >>> >>>>>>> when
>> >> >>> this happen :(
>> >> >>> >>>>>>>
>> >> >>> >>>>>>> Thanks a lot
>> >> >>> >>>>>>>
>> >> >>> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <
>> >> steve at hibernate.org>
>> >> >>> >>>>>>> wrote:
>> >> >>> >>>>>>>
>> >> >>> >>>>>>>> Andrea, this is in relation to something you asked me on
>> >> >>> >>>>>>>> IRC
>> >> >>> today.
>> >> >>> >>>>>>>> Specifically in regards to FromClause and the fact that it
>> >> >>> maintains
>> >> >>> >>>>>>>> pointers to parent/children.  As I said on IRC there is no
>> >> >>> intrinsic
>> >> >>> >>>>>>>> need
>> >> >>> >>>>>>>> (I do not foresee) for keeping this structure; I really
>> >> >>> >>>>>>>> only
>> >> did
>> >> >>> that
>> >> >>> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses
>> >> >>> >>>>>>>> and
>> >> the
>> >> >>> >>>>>>>> FromClause
>> >> >>> >>>>>>>> itself made a simple place to do that.
>> >> >>> >>>>>>>>
>> >> >>> >>>>>>>> However, in later work I ran into minor problems because
>> >> >>> >>>>>>>> of
>> >> that
>> >> >>> >>>>>>>> decision.
>> >> >>> >>>>>>>> I need to make a copy of an entire SelectStatement tree.
>> >> >>> >>>>>>>> But
>> >> >>> >>>>>>>> because the
>> >> >>> >>>>>>>> FromClause is held twice (for non-root FromClauses) in the
>> >> tree,
>> >> >>> it
>> >> >>> >>>>>>>> makes
>> >> >>> >>>>>>>> it more complicated to do a "simple copy" than it need be.
>> >> >>> >>>>>>>> Basically I
>> >> >>> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map"
>> >> >>> >>>>>>>> :(
>> >> >>> >>>>>>>>
>> >> >>> >>>>>>>> Long story short, I think I might revisit that decision
>> >> >>> >>>>>>>> and
>> >> >>> instead
>> >> >>> >>>>>>>> write a
>> >> >>> >>>>>>>> dedicated stack in FromClauseProcessor for this.  In the
>> >> >>> morning...
>> >> >>> >>>>>>>> its too
>> >> >>> >>>>>>>> late to start something that ambitious tonight.  I'll
>> >> >>> >>>>>>>> start
>> >> that
>> >> >>> in
>> >> >>> >>>>>>>> the
>> >> >>> >>>>>>>> morning, unless someone wants to pick that up in the next
>> >> >>> >>>>>>>> few
>> >> >>> hours
>> >> >>> >>>>>>>> before
>> >> >>> >>>>>>>> I get back on line.
>> >> >>> >>>>>>>>
>> >> >>> >>>>>>> _______________________________________________
>> >> >>> >>>>>>>> hibernate-dev mailing list
>> >> >>> >>>>>>>> hibernate-dev at lists.jboss.org
>> >> >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >>> >>>>>>>>
>> >> >>> >>>>>>>
>> >> >>> >>>>>>>
>> >> >>> >>>>>
>> >> >>> >>>
>> >> >>> > _______________________________________________
>> >> >>> > hibernate-dev mailing list
>> >> >>> > hibernate-dev at lists.jboss.org
>> >> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >>>
>> >> >>
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From davide at hibernate.org  Thu Aug 27 05:25:43 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 27 Aug 2015 10:25:43 +0100
Subject: [hibernate-dev] Query Parser Redesign
In-Reply-To: <CAFm4XO3BRv8VxMWkVrQQgUw76yZseKWn_tiJ4ZYdZqMEX-0dWA@mail.gmail.com>
References: <CAFdSV9uCpOuezpsxZ+X0VbsPqpHwsuPT+UkCUFp1NpLNgMVr4g@mail.gmail.com>
	<CAL00eSS+oXRfm5WCkz5YBS-TTWeK4-ARbtD+eMrxr+cq1bnjVA@mail.gmail.com>
	<CAFdSV9t7OyvU=groA13XBa4mja8-3FYYMhyAj=Pf-s6Jo9ePAQ@mail.gmail.com>
	<CAL00eSRzo7ivd6_jTHg0yYcH1Lu_EZB75j-Bw8BCLMNsLaWSyA@mail.gmail.com>
	<CAFdSV9sJDcHhd2NzAXp1kOoK6eX0isqi0Tqo7Pcut28mqV3P=g@mail.gmail.com>
	<CAL00eSSMzo7d+0cKpDq7X0LgACg44zBW2s-=qZoqiCvUen59OA@mail.gmail.com>
	<CAFdSV9szwUmDRVKjG0ADxRS_6ZOXZxnXz8QBd8Qb818-EP--Cw@mail.gmail.com>
	<CAFdSV9v5FeynD-3h7qP7pg1otWPzg8NutV9w7phmB6xiNYL2Vg@mail.gmail.com>
	<CADGJaX9OhOrPpAOQQ2R4mamGb7OvKKUJcy8-3qyvUaLdtiGKvg@mail.gmail.com>
	<CAFdSV9tDvgMELMWm9V4NPjRxmM-MBQ71-_4di0A1FsFvpj5qKg@mail.gmail.com>
	<CAFdSV9tz=+ZaO-qoNyZVpX-q1hvX+fnMp7OuRK3PsG27k=yg7A@mail.gmail.com>
	<CAFm4XO39SNjT36a6h3ZVa2fSyP+64jzTUhXNimnLe0WXX99BNA@mail.gmail.com>
	<CAFdSV9soXNZQSqZjJ-Z8sDzTiSpvR2=1huFwf0JsOcQPZVWW=Q@mail.gmail.com>
	<CADGJaX9BZwyFdV97OTTexHswJtJP_W0Uf3Sx2fyo5cFr6ccvyw@mail.gmail.com>
	<CAFdSV9ty4Ndzenh+r=ACgw6OonAk6NFW3qtjr8TRgPteeTYo=g@mail.gmail.com>
	<CAFm4XO3BRv8VxMWkVrQQgUw76yZseKWn_tiJ4ZYdZqMEX-0dWA@mail.gmail.com>
Message-ID: <CANoTJYPPYjnWUBcfJ47_hDS03RG525gY_f2pTv1Po3_aoTtW2w@mail.gmail.com>

+1

On Thu, Aug 27, 2015 at 10:09 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 26 August 2015 at 23:20, Steve Ebersole <steve at hibernate.org> wrote:
> > I'm ok with that.  Everyone else?
> >
> >
> > On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> hibernate-query-parser?
>
> +1
>
> >>
> >> 2015-08-26 22:32 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >> > I think I'd like to rename this repo and the 2 modules.  I think its
> >> > easier
> >> > to call the overall repo hibernate-sqm.  And then within that rename
> the
> >> > 2
> >> > modules:
> >> > * hibernate-sqm -> hibernate-sqm-model
> >> > * hibernate-query-interpreter -> ?
> >> >
> >> > Still not sure what to call this "query->SQM" module.  Thoughts?
> >> >
> >> >
> >> > On Wed, Aug 26, 2015 at 1:39 PM Sanne Grinovero <sanne at hibernate.org>
> >> > wrote:
> >> >
> >> >> On 26 August 2015 at 18:27, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> >> > Yes, but at this point lets make sure there is a Jira for any
> changes
> >> >> > we
> >> >> > are making.
> >> >> >
> >> >> > Also, I wanted to be specific that *no* clients of this code belong
> >> >> > in
> >> >> this
> >> >> > repo.  I know y'all did that with the hibernate-hql-parser repo.  I
> >> >> > just
> >> >> > want to be clear that that should *not* happen here.
> >> >>
> >> >> We had a short chat about this ^ on IRC; in summary I agree but we'll
> >> >> have to deal with the following difficulties.
> >> >>
> >> >> The obvious limitation of that is that each other project
> implementing
> >> >> a tree walker will need to (potentially) adjust on internal tree
> >> >> changes, but since that's obviously needed only when you upgrade the
> >> >> parser version you want to use, the problem is deferred; assuming we
> >> >> don't actually start all implementing such walkers until the tree is
> >> >> relatively stable, that should be a fair enough limitation to not
> push
> >> >> the burden of maintenance on the main parser maintainers, but keep
> the
> >> >> effort as an opt-in choice for those wishing to upgrade.
> >> >>
> >> >> The other little negative of that approach is that the current
> backend
> >> >> which generates Lucene queries depends on Hibernate Search and is
> >> >> consumed by both Hibernate OGM and by Infinispan, so having each
> >> >> "consuming project" host the tree walker would either prevent OGM and
> >> >> Infinispan to share the effort, or that would need an additional
> >> >> separate repository, or we could host it within Hibernate Search as
> >> >> some kind of parasite module (I'd rather not, for the same
> maintenance
> >> >> reason).
> >> >>
> >> >> We also wondered if the new parser should eventually be incorporated
> >> >> within the Hibernate ORM repository. In terms of dependencies it
> would
> >> >> not depend on hibernate-core so this would have no impact on other
> >> >> consumers, other than coupling the release cycle to ORM.
> >> >> Maybe this is premature to discuss as we certainly don't want it in
> >> >> there at least until ORM actually uses it, but I think that for end
> >> >> users it would be helpful to not have another dependency version to
> >> >> align..
> >> >>
> >> >> Thanks,
> >> >> Sanne
> >> >>
> >> >>
> >> >> >
> >> >> > On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <
> steve at hibernate.org>
> >> >> wrote:
> >> >> >
> >> >> >> Yes
> >> >> >>
> >> >> >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <
> gunnar at hibernate.org>
> >> >> wrote:
> >> >> >>
> >> >> >>> +1 for the new repo. Just forked it and am looking into the
> amazing
> >> >> >>> things you guys built recently :)
> >> >> >>>
> >> >> >>> Can I push simple stuff to that repo right away (e.g. adding the
> >> >> >>> Eclipse plug-in to build.gradle)?
> >> >> >>>
> >> >> >>> Cheers,
> >> >> >>>
> >> >> >>> --Gunnar
> >> >> >>>
> >> >> >>>
> >> >> >>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >> >> >>> > I also created Jira project ->
> >> >> >>> https://hibernate.atlassian.net/projects/SQM
> >> >> >>> >
> >> >> >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole
> >> >> >>> > <steve at hibernate.org>
> >> >> >>> wrote:
> >> >> >>> >
> >> >> >>> >> I am starting that work here ->
> >> >> >>> >> https://github.com/hibernate/hibernate-semantic-query
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <
> >> >> andrea at hibernate.org>
> >> >> >>> >> wrote:
> >> >> >>> >>
> >> >> >>> >>> no objections
> >> >> >>> >>>
> >> >> >>> >>> On 25 August 2015 at 20:12, Steve Ebersole
> >> >> >>> >>> <steve at hibernate.org>
> >> >> >>> wrote:
> >> >> >>> >>>
> >> >> >>> >>>> Anyone want to propose an alternative approach to what I
> have
> >> >> >>> working in
> >> >> >>> >>>> my Antlr 4 PoC?
> >> >> >>> >>>>
> >> >> >>> >>>> If not, I think we should move that work to a GitHub
> Hibernate
> >> >> >>> >>>> org
> >> >> >>> repo
> >> >> >>> >>>> and start tracking work and Jiras there.  Objections?
> >> >> >>> >>>>
> >> >> >>> >>>> Also its no longer *just* HQL, we also plan to support JPA
> >> >> criteria
> >> >> >>> >>>> queries here, interpreting them into semantic query models.
> >> >> >>> >>>> As
> >> >> such
> >> >> >>> I
> >> >> >>> >>>> propose the top-level name of hibernate-query-parser, with 2
> >> >> >>> >>>> sub
> >> >> >>> projects:
> >> >> >>> >>>> hibernate-sqm and hibernate-query-interpreter
> >> >> >>> >>>>
> >> >> >>> >>>>
> >> >> >>> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <
> >> >> dreborier at gmail.com>
> >> >> >>> >>>> wrote:
> >> >> >>> >>>>
> >> >> >>> >>>>> I see,
> >> >> >>> >>>>>
> >> >> >>> >>>>> Thanks
> >> >> >>> >>>>>
> >> >> >>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole
> >> >> >>> >>>>> <steve at hibernate.org>
> >> >> >>> wrote:
> >> >> >>> >>>>>
> >> >> >>> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c
> >> >> >>> >>>>>> ...)
> >> >> ...
> >> >> >>> >>>>>>
> >> >> >>> >>>>>> But regardless, the children are not important for a
> stack,
> >> >> >>> >>>>>> just
> >> >> >>> the
> >> >> >>> >>>>>> parent.  As I said when we discussed on ORC, the children
> >> >> >>> >>>>>> are
> >> >> just
> >> >> >>> >>>>>> maintained because I used them for tests.
> >> >> >>> >>>>>>
> >> >> >>> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero <
> >> >> >>> dreborier at gmail.com>
> >> >> >>> >>>>>> wrote:
> >> >> >>> >>>>>>
> >> >> >>> >>>>>>> Hi Stevej
> >> >> >>> >>>>>>>
> >> >> >>> >>>>>>> I'm playing with you idea to remove the parent/child from
> >> >> >>> >>>>>>> the
> >> >> >>> >>>>>>> FromClause and introduce such a structure in the
> >> >> >>> FromClauseProcessor.
> >> >> >>> >>>>>>>
> >> >> >>> >>>>>>> just a question, in the current implementation a
> fromClause
> >> >> >>> >>>>>>> can
> >> >> >>> have
> >> >> >>> >>>>>>> more than one child fromClause , but I cannot figure out
> >> >> >>> >>>>>>> when
> >> >> >>> this happen :(
> >> >> >>> >>>>>>>
> >> >> >>> >>>>>>> Thanks a lot
> >> >> >>> >>>>>>>
> >> >> >>> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <
> >> >> steve at hibernate.org>
> >> >> >>> >>>>>>> wrote:
> >> >> >>> >>>>>>>
> >> >> >>> >>>>>>>> Andrea, this is in relation to something you asked me on
> >> >> >>> >>>>>>>> IRC
> >> >> >>> today.
> >> >> >>> >>>>>>>> Specifically in regards to FromClause and the fact that
> it
> >> >> >>> maintains
> >> >> >>> >>>>>>>> pointers to parent/children.  As I said on IRC there is
> no
> >> >> >>> intrinsic
> >> >> >>> >>>>>>>> need
> >> >> >>> >>>>>>>> (I do not foresee) for keeping this structure; I really
> >> >> >>> >>>>>>>> only
> >> >> did
> >> >> >>> that
> >> >> >>> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses
> >> >> >>> >>>>>>>> and
> >> >> the
> >> >> >>> >>>>>>>> FromClause
> >> >> >>> >>>>>>>> itself made a simple place to do that.
> >> >> >>> >>>>>>>>
> >> >> >>> >>>>>>>> However, in later work I ran into minor problems because
> >> >> >>> >>>>>>>> of
> >> >> that
> >> >> >>> >>>>>>>> decision.
> >> >> >>> >>>>>>>> I need to make a copy of an entire SelectStatement tree.
> >> >> >>> >>>>>>>> But
> >> >> >>> >>>>>>>> because the
> >> >> >>> >>>>>>>> FromClause is held twice (for non-root FromClauses) in
> the
> >> >> tree,
> >> >> >>> it
> >> >> >>> >>>>>>>> makes
> >> >> >>> >>>>>>>> it more complicated to do a "simple copy" than it need
> be.
> >> >> >>> >>>>>>>> Basically I
> >> >> >>> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map"
> >> >> >>> >>>>>>>> :(
> >> >> >>> >>>>>>>>
> >> >> >>> >>>>>>>> Long story short, I think I might revisit that decision
> >> >> >>> >>>>>>>> and
> >> >> >>> instead
> >> >> >>> >>>>>>>> write a
> >> >> >>> >>>>>>>> dedicated stack in FromClauseProcessor for this.  In the
> >> >> >>> morning...
> >> >> >>> >>>>>>>> its too
> >> >> >>> >>>>>>>> late to start something that ambitious tonight.  I'll
> >> >> >>> >>>>>>>> start
> >> >> that
> >> >> >>> in
> >> >> >>> >>>>>>>> the
> >> >> >>> >>>>>>>> morning, unless someone wants to pick that up in the
> next
> >> >> >>> >>>>>>>> few
> >> >> >>> hours
> >> >> >>> >>>>>>>> before
> >> >> >>> >>>>>>>> I get back on line.
> >> >> >>> >>>>>>>>
> >> >> >>> >>>>>>> _______________________________________________
> >> >> >>> >>>>>>>> hibernate-dev mailing list
> >> >> >>> >>>>>>>> hibernate-dev at lists.jboss.org
> >> >> >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >>> >>>>>>>>
> >> >> >>> >>>>>>>
> >> >> >>> >>>>>>>
> >> >> >>> >>>>>
> >> >> >>> >>>
> >> >> >>> > _______________________________________________
> >> >> >>> > hibernate-dev mailing list
> >> >> >>> > hibernate-dev at lists.jboss.org
> >> >> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >>>
> >> >> >>
> >> >> > _______________________________________________
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Thu Aug 27 05:27:28 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 27 Aug 2015 11:27:28 +0200
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
Message-ID: <20150827092728.GA9971@Nineveh.lan>

On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
> Assuming you build a Lucene Query the following way:
> 
>     queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
> 
> What is your expectation, if the "age" field is being indexed as a NumericField?

I would say that this throws an exception. At least atm. Numeric encoded
fields needs to be targeted by a range query. One could imagine to transparently
create a range query in this case. I guess by the metadata we could tell that we have
a numeric field. However, that's a a lot of magic then, in particular since we
always that that a keyword query maps to a TermQuery.

--Hardy

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

From gunnar at hibernate.org  Thu Aug 27 05:36:23 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 27 Aug 2015 11:36:23 +0200
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <20150827092728.GA9971@Nineveh.lan>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
Message-ID: <CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>

2015-08-27 11:27 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
> On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
>> Assuming you build a Lucene Query the following way:
>>
>>     queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>>
>> What is your expectation, if the "age" field is being indexed as a NumericField?
>
> I would say that this throws an exception. At least atm. Numeric encoded
> fields needs to be targeted by a range query. One could imagine to transparently
> create a range query in this case. I guess by the metadata we could tell that we have
> a numeric field. However, that's a a lot of magic then, in particular since we
> always that that a keyword query maps to a TermQuery.

Hum, but that's already happening, no?

See DSLTest.testUseOfFieldBridge() where we do exactly that:

    monthQb.keyword().onField( "monthValue" ).matching( 2 ).createQuery();

Internally it's creating a NumericRangeQuery with start/end set to the
same value.

If the field uses a null encoding bridge, it'd be a String field,
though, if I am not mistaken (unless we use some numeric null encoding
as discussed recently), so a simple TermQuery query would be the right
thing.


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

From sanne at hibernate.org  Thu Aug 27 05:53:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 27 Aug 2015 10:53:29 +0100
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
Message-ID: <CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>

For the record, Gustavo replied forgetting to CC the list stating that
he would expect it to produce a valid NumericRangeQuery, and that
seems to be the expectation of Adrian too, gauging at some code he
wrote.

That surprised me. I'm personally feeling more comfortable with
Hardy's answer, as I'm looking at "keyword()" as something which
explicitly demands for a TermQuery.

However the current DSL implementation will have this produce a valid
NumericRangeQuery - except in some corner cases I'm working on - so I
don't think we can change this in a minor release, not least as the
HQL parser and downstream projects rely on this.

There is an open issue caused by the fact that the current
implementation isn't consistent as it fails to recognize the field as
Numeric when it's wrapped by one of the other FieldBridge decorators
(a simple instanceof isn't safe for such purposes).

So.. questions:

1# Deprecate?
I'll have to fix the inconsistency for now and make it produce a
working query in all cases... but do we want to deprecate this and
have it produce a WARN to state that you really shouldn't use a
keyword() on numeric fields?

2# Alternatives?
If we decide that keyword() should not be abused for this and will be
deprecated, should we give an alternative method like
"exactEqualsQuery()" to provide a flexible alternative (working with
either keyword, number, null tokens).

Thanks,
Sanne



On 27 August 2015 at 10:36, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2015-08-27 11:27 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>> On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
>>> Assuming you build a Lucene Query the following way:
>>>
>>>     queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>>>
>>> What is your expectation, if the "age" field is being indexed as a NumericField?
>>
>> I would say that this throws an exception. At least atm. Numeric encoded
>> fields needs to be targeted by a range query. One could imagine to transparently
>> create a range query in this case. I guess by the metadata we could tell that we have
>> a numeric field. However, that's a a lot of magic then, in particular since we
>> always that that a keyword query maps to a TermQuery.
>
> Hum, but that's already happening, no?
>
> See DSLTest.testUseOfFieldBridge() where we do exactly that:
>
>     monthQb.keyword().onField( "monthValue" ).matching( 2 ).createQuery();
>
> Internally it's creating a NumericRangeQuery with start/end set to the
> same value.
>
> If the field uses a null encoding bridge, it'd be a String field,
> though, if I am not mistaken (unless we use some numeric null encoding
> as discussed recently), so a simple TermQuery query would be the right
> thing.
>
>
>>
>> --Hardy
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Thu Aug 27 06:07:56 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 27 Aug 2015 12:07:56 +0200
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
	<CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
Message-ID: <CADGJaX9rxrgrbMPxkM3KFssxu+9eM1-pKeUKw01qF2v=XVPNQQ@mail.gmail.com>

Is there any strong reason for not supporting this on numeric fields?
Assuming the remaining corner cases can be fixed (null handling
mainly?), my vote goes for keeping the current behaviour.

I suppose many people don't think in the technical terms of
"TermQuery" or "NumericRangeQuery" but just in terms of the data they
want to look for. Different methods to be used based on the field type
will make things harder for them. Also consider potential future
alternative backends of the query DSL (ES) where string/numeric/date
match queries can be handled uniformly.


2015-08-27 11:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> For the record, Gustavo replied forgetting to CC the list stating that
> he would expect it to produce a valid NumericRangeQuery, and that
> seems to be the expectation of Adrian too, gauging at some code he
> wrote.
>
> That surprised me. I'm personally feeling more comfortable with
> Hardy's answer, as I'm looking at "keyword()" as something which
> explicitly demands for a TermQuery.
>
> However the current DSL implementation will have this produce a valid
> NumericRangeQuery - except in some corner cases I'm working on - so I
> don't think we can change this in a minor release, not least as the
> HQL parser and downstream projects rely on this.
>
> There is an open issue caused by the fact that the current
> implementation isn't consistent as it fails to recognize the field as
> Numeric when it's wrapped by one of the other FieldBridge decorators
> (a simple instanceof isn't safe for such purposes).
>
> So.. questions:
>
> 1# Deprecate?
> I'll have to fix the inconsistency for now and make it produce a
> working query in all cases... but do we want to deprecate this and
> have it produce a WARN to state that you really shouldn't use a
> keyword() on numeric fields?
>
> 2# Alternatives?
> If we decide that keyword() should not be abused for this and will be
> deprecated, should we give an alternative method like
> "exactEqualsQuery()" to provide a flexible alternative (working with
> either keyword, number, null tokens).
>
> Thanks,
> Sanne
>
>
>
> On 27 August 2015 at 10:36, Gunnar Morling <gunnar at hibernate.org> wrote:
>> 2015-08-27 11:27 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>>> On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
>>>> Assuming you build a Lucene Query the following way:
>>>>
>>>>     queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>>>>
>>>> What is your expectation, if the "age" field is being indexed as a NumericField?
>>>
>>> I would say that this throws an exception. At least atm. Numeric encoded
>>> fields needs to be targeted by a range query. One could imagine to transparently
>>> create a range query in this case. I guess by the metadata we could tell that we have
>>> a numeric field. However, that's a a lot of magic then, in particular since we
>>> always that that a keyword query maps to a TermQuery.
>>
>> Hum, but that's already happening, no?
>>
>> See DSLTest.testUseOfFieldBridge() where we do exactly that:
>>
>>     monthQb.keyword().onField( "monthValue" ).matching( 2 ).createQuery();
>>
>> Internally it's creating a NumericRangeQuery with start/end set to the
>> same value.
>>
>> If the field uses a null encoding bridge, it'd be a String field,
>> though, if I am not mistaken (unless we use some numeric null encoding
>> as discussed recently), so a simple TermQuery query would be the right
>> thing.
>>
>>
>>>
>>> --Hardy
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu Aug 27 06:34:19 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 27 Aug 2015 11:34:19 +0100
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CADGJaX9rxrgrbMPxkM3KFssxu+9eM1-pKeUKw01qF2v=XVPNQQ@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
	<CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
	<CADGJaX9rxrgrbMPxkM3KFssxu+9eM1-pKeUKw01qF2v=XVPNQQ@mail.gmail.com>
Message-ID: <CAFm4XO04vTtCBN8P6jH3VR3DV0WAV1dDFEZrj-=uUCYscUQ-+g@mail.gmail.com>

On 27 August 2015 at 11:07, Gunnar Morling <gunnar at hibernate.org> wrote:
> Is there any strong reason for not supporting this on numeric fields?
> Assuming the remaining corner cases can be fixed (null handling
> mainly?), my vote goes for keeping the current behaviour.

Right we can't just change behaviour currently, especially as the fix
I'm working on needs backporting so that would break stuff in a micro
release,
but *if* we agree this shouldn't have been the intent, we can start
the education and deprecation procedures at least by logging warnings,
rather than say kill it in 6.0.

Regarding "strong reason", my doubt is just that the method seems
wrong for the purpose: keyWORD(), and it seems to imply we override an
explicit user choice.

For example, I intentionally asked it extremely neutrally and you all
gave different opinions ;-)

> I suppose many people don't think in the technical terms of
> "TermQuery" or "NumericRangeQuery" but just in terms of the data they
> want to look for. Different methods to be used based on the field type
> will make things harder for them. Also consider potential future
> alternative backends of the query DSL (ES) where string/numeric/date
> match queries can be handled uniformly.

Sure people don't have to grasp all implementation details, in fact
the API signature returns "Query" and it's probably not visible to
users which kind it is.

But I wonder that - in case people just want something which works for
equality - if we shouldn't make a better named method for that.

Also, I hate it when frameworks "know better" and for some automagic
reason it overrides an explicit user request. It seems to me the user
is explicitly demanding to build a keyword-based query, and we
override that because of some metadata we happen to have in this case.
This whole logic might even work in this case but it's certainly
inconsistent with other DSL usage, as often we don't have the full
picture of metadata and just rely on the user to build the right query
type and set the correct options.

So that wraps why I'm concerned and surprised by this; I agree that we
should have an easy equality query builder too - just torn about it
being named like this as it's certainly violating some "least
surprise" principle. But if the majority thinks it was well understood
(except obviously the low-level thinkers like myself and Hardy) we can
keep the status quo.

Sanne



>
>
> 2015-08-27 11:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> For the record, Gustavo replied forgetting to CC the list stating that
>> he would expect it to produce a valid NumericRangeQuery, and that
>> seems to be the expectation of Adrian too, gauging at some code he
>> wrote.
>>
>> That surprised me. I'm personally feeling more comfortable with
>> Hardy's answer, as I'm looking at "keyword()" as something which
>> explicitly demands for a TermQuery.
>>
>> However the current DSL implementation will have this produce a valid
>> NumericRangeQuery - except in some corner cases I'm working on - so I
>> don't think we can change this in a minor release, not least as the
>> HQL parser and downstream projects rely on this.
>>
>> There is an open issue caused by the fact that the current
>> implementation isn't consistent as it fails to recognize the field as
>> Numeric when it's wrapped by one of the other FieldBridge decorators
>> (a simple instanceof isn't safe for such purposes).
>>
>> So.. questions:
>>
>> 1# Deprecate?
>> I'll have to fix the inconsistency for now and make it produce a
>> working query in all cases... but do we want to deprecate this and
>> have it produce a WARN to state that you really shouldn't use a
>> keyword() on numeric fields?
>>
>> 2# Alternatives?
>> If we decide that keyword() should not be abused for this and will be
>> deprecated, should we give an alternative method like
>> "exactEqualsQuery()" to provide a flexible alternative (working with
>> either keyword, number, null tokens).
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 27 August 2015 at 10:36, Gunnar Morling <gunnar at hibernate.org> wrote:
>>> 2015-08-27 11:27 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>>>> On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
>>>>> Assuming you build a Lucene Query the following way:
>>>>>
>>>>>     queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>>>>>
>>>>> What is your expectation, if the "age" field is being indexed as a NumericField?
>>>>
>>>> I would say that this throws an exception. At least atm. Numeric encoded
>>>> fields needs to be targeted by a range query. One could imagine to transparently
>>>> create a range query in this case. I guess by the metadata we could tell that we have
>>>> a numeric field. However, that's a a lot of magic then, in particular since we
>>>> always that that a keyword query maps to a TermQuery.
>>>
>>> Hum, but that's already happening, no?
>>>
>>> See DSLTest.testUseOfFieldBridge() where we do exactly that:
>>>
>>>     monthQb.keyword().onField( "monthValue" ).matching( 2 ).createQuery();
>>>
>>> Internally it's creating a NumericRangeQuery with start/end set to the
>>> same value.
>>>
>>> If the field uses a null encoding bridge, it'd be a String field,
>>> though, if I am not mistaken (unless we use some numeric null encoding
>>> as discussed recently), so a simple TermQuery query would be the right
>>> thing.
>>>
>>>
>>>>
>>>> --Hardy
>>>>
>>>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Thu Aug 27 06:53:06 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 27 Aug 2015 12:53:06 +0200
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CAFm4XO04vTtCBN8P6jH3VR3DV0WAV1dDFEZrj-=uUCYscUQ-+g@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
	<CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
	<CADGJaX9rxrgrbMPxkM3KFssxu+9eM1-pKeUKw01qF2v=XVPNQQ@mail.gmail.com>
	<CAFm4XO04vTtCBN8P6jH3VR3DV0WAV1dDFEZrj-=uUCYscUQ-+g@mail.gmail.com>
Message-ID: <CADGJaX_r688SPdcS00R3KXaqfEe0DVOoMLDG3sCJ8ETn0ok2kQ@mail.gmail.com>

2015-08-27 12:34 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> On 27 August 2015 at 11:07, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Is there any strong reason for not supporting this on numeric fields?
>> Assuming the remaining corner cases can be fixed (null handling
>> mainly?), my vote goes for keeping the current behaviour.
>
> Right we can't just change behaviour currently, especially as the fix
> I'm working on needs backporting so that would break stuff in a micro
> release,
> but *if* we agree this shouldn't have been the intent, we can start
> the education and deprecation procedures at least by logging warnings,
> rather than say kill it in 6.0.
>
> Regarding "strong reason", my doubt is just that the method seems
> wrong for the purpose: keyWORD(), and it seems to imply we override an
> explicit user choice.

Agreed on the name being sub-par for that usage pattern most of us
apparently have in mind. So yes, if there was another uniformly-to-use
method for equality I wouldn't mind limiting the current one to string
fields.

>
> For example, I intentionally asked it extremely neutrally and you all
> gave different opinions ;-)
>
>> I suppose many people don't think in the technical terms of
>> "TermQuery" or "NumericRangeQuery" but just in terms of the data they
>> want to look for. Different methods to be used based on the field type
>> will make things harder for them. Also consider potential future
>> alternative backends of the query DSL (ES) where string/numeric/date
>> match queries can be handled uniformly.
>
> Sure people don't have to grasp all implementation details, in fact
> the API signature returns "Query" and it's probably not visible to
> users which kind it is.
>
> But I wonder that - in case people just want something which works for
> equality - if we shouldn't make a better named method for that.
>
> Also, I hate it when frameworks "know better" and for some automagic
> reason it overrides an explicit user request. It seems to me the user
> is explicitly demanding to build a keyword-based query, and we
> override that because of some metadata we happen to have in this case.
> This whole logic might even work in this case but it's certainly
> inconsistent with other DSL usage, as often we don't have the full
> picture of metadata and just rely on the user to build the right query
> type and set the correct options.
>
> So that wraps why I'm concerned and surprised by this; I agree that we
> should have an easy equality query builder too - just torn about it
> being named like this as it's certainly violating some "least
> surprise" principle. But if the majority thinks it was well understood
> (except obviously the low-level thinkers like myself and Hardy) we can
> keep the status quo.
>
> Sanne
>
>
>
>>
>>
>> 2015-08-27 11:53 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>> For the record, Gustavo replied forgetting to CC the list stating that
>>> he would expect it to produce a valid NumericRangeQuery, and that
>>> seems to be the expectation of Adrian too, gauging at some code he
>>> wrote.
>>>
>>> That surprised me. I'm personally feeling more comfortable with
>>> Hardy's answer, as I'm looking at "keyword()" as something which
>>> explicitly demands for a TermQuery.
>>>
>>> However the current DSL implementation will have this produce a valid
>>> NumericRangeQuery - except in some corner cases I'm working on - so I
>>> don't think we can change this in a minor release, not least as the
>>> HQL parser and downstream projects rely on this.
>>>
>>> There is an open issue caused by the fact that the current
>>> implementation isn't consistent as it fails to recognize the field as
>>> Numeric when it's wrapped by one of the other FieldBridge decorators
>>> (a simple instanceof isn't safe for such purposes).
>>>
>>> So.. questions:
>>>
>>> 1# Deprecate?
>>> I'll have to fix the inconsistency for now and make it produce a
>>> working query in all cases... but do we want to deprecate this and
>>> have it produce a WARN to state that you really shouldn't use a
>>> keyword() on numeric fields?
>>>
>>> 2# Alternatives?
>>> If we decide that keyword() should not be abused for this and will be
>>> deprecated, should we give an alternative method like
>>> "exactEqualsQuery()" to provide a flexible alternative (working with
>>> either keyword, number, null tokens).
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>>
>>> On 27 August 2015 at 10:36, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>> 2015-08-27 11:27 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>>>>> On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
>>>>>> Assuming you build a Lucene Query the following way:
>>>>>>
>>>>>>     queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>>>>>>
>>>>>> What is your expectation, if the "age" field is being indexed as a NumericField?
>>>>>
>>>>> I would say that this throws an exception. At least atm. Numeric encoded
>>>>> fields needs to be targeted by a range query. One could imagine to transparently
>>>>> create a range query in this case. I guess by the metadata we could tell that we have
>>>>> a numeric field. However, that's a a lot of magic then, in particular since we
>>>>> always that that a keyword query maps to a TermQuery.
>>>>
>>>> Hum, but that's already happening, no?
>>>>
>>>> See DSLTest.testUseOfFieldBridge() where we do exactly that:
>>>>
>>>>     monthQb.keyword().onField( "monthValue" ).matching( 2 ).createQuery();
>>>>
>>>> Internally it's creating a NumericRangeQuery with start/end set to the
>>>> same value.
>>>>
>>>> If the field uses a null encoding bridge, it'd be a String field,
>>>> though, if I am not mistaken (unless we use some numeric null encoding
>>>> as discussed recently), so a simple TermQuery query would be the right
>>>> thing.
>>>>
>>>>
>>>>>
>>>>> --Hardy
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From andrea at hibernate.org  Thu Aug 27 08:04:40 2015
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 27 Aug 2015 13:04:40 +0100
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
Message-ID: <CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>

i like the idea of "matches" operator for dealing with "is null".
+1

On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org> wrote:

> https://hibernate.atlassian.net/browse/SQM-11
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Thu Aug 27 08:20:08 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 27 Aug 2015 14:20:08 +0200
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
Message-ID: <20150827122008.GA10204@Nineveh.lan>

> > I would say that this throws an exception. At least atm. Numeric encoded
> > fields needs to be targeted by a range query. One could imagine to transparently
> > create a range query in this case. I guess by the metadata we could tell that we have
> > a numeric field. However, that's a a lot of magic then, in particular since we
> > always that that a keyword query maps to a TermQuery.
> 
> Hum, but that's already happening, no?
> 
> See DSLTest.testUseOfFieldBridge() where we do exactly that:
> 
>     monthQb.keyword().onField( "monthValue" ).matching( 2 ).createQuery();
> 
> Internally it's creating a NumericRangeQuery with start/end set to the
> same value.

Hmm, I am pretty sure we did not start of this way, but maybe this has changed 
in the meantime. I seem to vaguely remember that we did something in this area
after the first cut.

--Hardy

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

From hardy at hibernate.org  Thu Aug 27 08:35:34 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 27 Aug 2015 14:35:34 +0200
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
	<CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
Message-ID: <20150827123534.GB10204@Nineveh.lan>

On Thu, Aug 27, 2015 at 10:53:29AM +0100, Sanne Grinovero wrote:
> So.. questions:
> 
> 1# Deprecate?
> I'll have to fix the inconsistency for now and make it produce a
> working query in all cases... but do we want to deprecate this and
> have it produce a WARN to state that you really shouldn't use a
> keyword() on numeric fields?

+1 (Personally I could even imagine to throw an exception with a clear
message on which type of query should be used.  I don't see that as a contract
break).

> 2# Alternatives?
> If we decide that keyword() should not be abused for this and will be
> deprecated, should we give an alternative method like
> "exactEqualsQuery()" to provide a flexible alternative (working with
> either keyword, number, null tokens).

That's my thinking as well. We already have this distinction between numeric 
and non numeric types via the .range() entry point vs all the rest. 
I would opt for 'numericEquals' or just 'equals'.

I wonder whether the difference between strings and numbers could be even more
obvious by changing the entry into query building. Right now we have:

Query luceneQuery = queryBuilder 
    .keyword()
    ...

Query luceneQuery = queryBuilder 
    .range()
    ...

We could have an additional level:

 Query luceneQuery = queryBuilder
     .string() 
     .keyword()
     ...
 
 Query luceneQuery = queryBuilder
     .numeric()
     .range()
     ...

Obviously not backwards compatible. Food for thought.

--Hardy

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

From hardy at hibernate.org  Thu Aug 27 08:56:59 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 27 Aug 2015 14:56:59 +0200
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CAFm4XO04vTtCBN8P6jH3VR3DV0WAV1dDFEZrj-=uUCYscUQ-+g@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
	<CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
	<CADGJaX9rxrgrbMPxkM3KFssxu+9eM1-pKeUKw01qF2v=XVPNQQ@mail.gmail.com>
	<CAFm4XO04vTtCBN8P6jH3VR3DV0WAV1dDFEZrj-=uUCYscUQ-+g@mail.gmail.com>
Message-ID: <20150827125659.GC10204@Nineveh.lan>

On Thu, Aug 27, 2015 at 11:34:19AM +0100, Sanne Grinovero wrote:
> Regarding "strong reason", my doubt is just that the method seems
> wrong for the purpose: keyWORD(), and it seems to imply we override an
> explicit user choice.

Right. I also think some sort of understanding is necessary. Obviously you 
can try to hide everything away, but this will only make it harder for the users
wanted to go a bit below the surface.

> But I wonder that - in case people just want something which works for
> equality - if we shouldn't make a better named method for that.

+1

> Also, I hate it when frameworks "know better" and for some automagic
> reason it overrides an explicit user request. It seems to me the user
> is explicitly demanding to build a keyword-based query, and we
> override that because of some metadata we happen to have in this case.
> This whole logic might even work in this case but it's certainly
> inconsistent with other DSL usage, as often we don't have the full
> picture of metadata and just rely on the user to build the right query
> type and set the correct options.

+1 

--Hardy


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

From hardy at hibernate.org  Thu Aug 27 08:58:43 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 27 Aug 2015 14:58:43 +0200
Subject: [hibernate-dev] Search DSL expectations for "keyword()" clause
In-Reply-To: <CADGJaX_r688SPdcS00R3KXaqfEe0DVOoMLDG3sCJ8ETn0ok2kQ@mail.gmail.com>
References: <CAFm4XO0cW_oDYPuaXJh2pyu7xb+0_B56FRCmHFvdoyKXxpUbhA@mail.gmail.com>
	<20150827092728.GA9971@Nineveh.lan>
	<CADGJaX9V=xfanAgp6VcUrVhK8Sn1ad9d6QzXzoo-0mH=acLuAQ@mail.gmail.com>
	<CAFm4XO1+QVAbNVXWe0z9QsfyiDzUygGfJw76Hu4D0m8sRX5QrQ@mail.gmail.com>
	<CADGJaX9rxrgrbMPxkM3KFssxu+9eM1-pKeUKw01qF2v=XVPNQQ@mail.gmail.com>
	<CAFm4XO04vTtCBN8P6jH3VR3DV0WAV1dDFEZrj-=uUCYscUQ-+g@mail.gmail.com>
	<CADGJaX_r688SPdcS00R3KXaqfEe0DVOoMLDG3sCJ8ETn0ok2kQ@mail.gmail.com>
Message-ID: <20150827125843.GD10204@Nineveh.lan>

> Agreed on the name being sub-par for that usage pattern most of us
> apparently have in mind. So yes, if there was another uniformly-to-use
> method for equality I wouldn't mind limiting the current one to string
> fields.

Cool

--Hardy


From gunnar at hibernate.org  Thu Aug 27 09:45:15 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 27 Aug 2015 15:45:15 +0200
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9vz1gyRmuTwT+o4vWcbsmZGknPDdqFjZNPkp52qmjwxWA@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
	<CAFdSV9vz1gyRmuTwT+o4vWcbsmZGknPDdqFjZNPkp52qmjwxWA@mail.gmail.com>
Message-ID: <CADGJaX9zV3E+FTzEBDgcTD4QY_g2LM1sm-GzG4evRuNvMUyXLw@mail.gmail.com>

2015-08-26 14:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi Steve,
>>
>> > The other approach is to use a 3-phase translation (input
>> > -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint to
>> > one
>> > of the major problems.  One source "semantic" query will often
>> > correspond
>> > to multiple SQL queries; that is hard to manage in the 2-phase approach.
>>
>> In which situations will this happen? I can see inheritance where a
>> HQL query targeting a super-type needs to be translated into a SQL
>> query per sub-type table. What others are there?
>
>
> For ORM the only time this happens today for a SELECT query is in the "split
> query" case I mentioned elsewhere (a query like 'from java.lang.Object').
> SQM does this much better than we do in ORM today.  in SQM we build a
> semantic tree that encodes the "unmapped polymorphism" such that we get a
> tree with 'java.lang.Object' as the root from element. But it is a
> FromElement with a special type of EntityTypeDescriptor (which comes from
> the caller remember): PolymorphicEntityTypeDescriptor.  On the ORM side then
> I have a QuerySplitter that takes that query and makes a copy of that entire
> SQM tree, one for each mapped implementor of the specified class.  FWIW, ORM
> does this today, albeit in a different way.  Today we split the query based
> on String manip and then feed it parser.  Here we feed it to the parser and
> use the tree to split it; much less brittle :)
>
> Really the cases where this would happen (one "concrete SQM" -> multiple
> SQL) would be UPDATE and DELETE queries against "multi-table structures"
> (inheritance, secondary tables).
>
>
>> For the purposes of OGM this phase ideally would not be tied to SQL,
>> as we phase the same task with non-SQL backends in SQL. I.e. i'd be
>> beneficial to have input -> semantic-tree ->
>> semantic-output-query-tree(s) -> (SQL|non-SQL query). There
>> "semantic-output-query-tree(s)" would be an abstract representation of
>> the queries to be executed, e.g. referencing the table name(s). But it
>> would be unaware of SQL specifics.
>
>
> OGM would be doing this.  This SQM is the end result of the shared library.
> WHat each caller does with the SQM is up to that particular caller.  We
> should consider moving QuerySplitter (its in my PoC, which now acts as the
> PoC for using this in ORM) into the hibernate-sqm module.  Any caller
> wanting to support those unmapped class references will need to do the same
> thing.

Yes, that'd be good I think. We'd have to apply the same rules for
splitting as ORM.

>
> BTW, another cool thing to note is the (still expanding) support for "strict
> JPQL compliance" enforcement.

From steve at hibernate.org  Thu Aug 27 11:57:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 27 Aug 2015 15:57:59 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CADGJaX9zV3E+FTzEBDgcTD4QY_g2LM1sm-GzG4evRuNvMUyXLw@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
	<CAFdSV9vz1gyRmuTwT+o4vWcbsmZGknPDdqFjZNPkp52qmjwxWA@mail.gmail.com>
	<CADGJaX9zV3E+FTzEBDgcTD4QY_g2LM1sm-GzG4evRuNvMUyXLw@mail.gmail.com>
Message-ID: <CAFdSV9s3h8_TMPhPb_wMEvrqUQuWi=AvUew_aYAaHKw7TUoMSQ@mail.gmail.com>

I do want to pull ORM in to the hibernate-sqm module as a test dependency
to be able to more easily set up the ModelMetadata stuff based on a
SessionFactory.  That is possibly awkward later when we then use
hibernate-sqm in ORM in terms of having 2 different versions of ORM.  I am
open to alternatives that don't involve *me* developing a real(ish)
ModelMetadata
impl from scratch.

On Thu, Aug 27, 2015 at 8:45 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> 2015-08-26 14:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> > On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> Hi Steve,
> >>
> >> > The other approach is to use a 3-phase translation (input
> >> > -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint
> to
> >> > one
> >> > of the major problems.  One source "semantic" query will often
> >> > correspond
> >> > to multiple SQL queries; that is hard to manage in the 2-phase
> approach.
> >>
> >> In which situations will this happen? I can see inheritance where a
> >> HQL query targeting a super-type needs to be translated into a SQL
> >> query per sub-type table. What others are there?
> >
> >
> > For ORM the only time this happens today for a SELECT query is in the
> "split
> > query" case I mentioned elsewhere (a query like 'from java.lang.Object').
> > SQM does this much better than we do in ORM today.  in SQM we build a
> > semantic tree that encodes the "unmapped polymorphism" such that we get a
> > tree with 'java.lang.Object' as the root from element. But it is a
> > FromElement with a special type of EntityTypeDescriptor (which comes from
> > the caller remember): PolymorphicEntityTypeDescriptor.  On the ORM side
> then
> > I have a QuerySplitter that takes that query and makes a copy of that
> entire
> > SQM tree, one for each mapped implementor of the specified class.  FWIW,
> ORM
> > does this today, albeit in a different way.  Today we split the query
> based
> > on String manip and then feed it parser.  Here we feed it to the parser
> and
> > use the tree to split it; much less brittle :)
> >
> > Really the cases where this would happen (one "concrete SQM" -> multiple
> > SQL) would be UPDATE and DELETE queries against "multi-table structures"
> > (inheritance, secondary tables).
> >
> >
> >> For the purposes of OGM this phase ideally would not be tied to SQL,
> >> as we phase the same task with non-SQL backends in SQL. I.e. i'd be
> >> beneficial to have input -> semantic-tree ->
> >> semantic-output-query-tree(s) -> (SQL|non-SQL query). There
> >> "semantic-output-query-tree(s)" would be an abstract representation of
> >> the queries to be executed, e.g. referencing the table name(s). But it
> >> would be unaware of SQL specifics.
> >
> >
> > OGM would be doing this.  This SQM is the end result of the shared
> library.
> > WHat each caller does with the SQM is up to that particular caller.  We
> > should consider moving QuerySplitter (its in my PoC, which now acts as
> the
> > PoC for using this in ORM) into the hibernate-sqm module.  Any caller
> > wanting to support those unmapped class references will need to do the
> same
> > thing.
>
> Yes, that'd be good I think. We'd have to apply the same rules for
> splitting as ORM.
>
> >
> > BTW, another cool thing to note is the (still expanding) support for
> "strict
> > JPQL compliance" enforcement.
>

From steve at hibernate.org  Thu Aug 27 13:30:12 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 27 Aug 2015 17:30:12 +0000
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9s3h8_TMPhPb_wMEvrqUQuWi=AvUew_aYAaHKw7TUoMSQ@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
	<CAFdSV9vz1gyRmuTwT+o4vWcbsmZGknPDdqFjZNPkp52qmjwxWA@mail.gmail.com>
	<CADGJaX9zV3E+FTzEBDgcTD4QY_g2LM1sm-GzG4evRuNvMUyXLw@mail.gmail.com>
	<CAFdSV9s3h8_TMPhPb_wMEvrqUQuWi=AvUew_aYAaHKw7TUoMSQ@mail.gmail.com>
Message-ID: <CAFdSV9spuAH7crkRuD-HeYKBWjZN-UhAkL==Me--igEfckwtdA@mail.gmail.com>

Nevermind.  I will not do that.  I think I have found a still-easyish way
to do it.


On Thu, Aug 27, 2015 at 10:57 AM Steve Ebersole <steve at hibernate.org> wrote:

> I do want to pull ORM in to the hibernate-sqm module as a test dependency
> to be able to more easily set up the ModelMetadata stuff based on a
> SessionFactory.  That is possibly awkward later when we then use
> hibernate-sqm in ORM in terms of having 2 different versions of ORM.  I am
> open to alternatives that don't involve *me* developing a real(ish) ModelMetadata
> impl from scratch.
>
> On Thu, Aug 27, 2015 at 8:45 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 2015-08-26 14:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> > On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >>
>> >> Hi Steve,
>> >>
>> >> > The other approach is to use a 3-phase translation (input
>> >> > -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint
>> to
>> >> > one
>> >> > of the major problems.  One source "semantic" query will often
>> >> > correspond
>> >> > to multiple SQL queries; that is hard to manage in the 2-phase
>> approach.
>> >>
>> >> In which situations will this happen? I can see inheritance where a
>> >> HQL query targeting a super-type needs to be translated into a SQL
>> >> query per sub-type table. What others are there?
>> >
>> >
>> > For ORM the only time this happens today for a SELECT query is in the
>> "split
>> > query" case I mentioned elsewhere (a query like 'from
>> java.lang.Object').
>> > SQM does this much better than we do in ORM today.  in SQM we build a
>> > semantic tree that encodes the "unmapped polymorphism" such that we get
>> a
>> > tree with 'java.lang.Object' as the root from element. But it is a
>> > FromElement with a special type of EntityTypeDescriptor (which comes
>> from
>> > the caller remember): PolymorphicEntityTypeDescriptor.  On the ORM side
>> then
>> > I have a QuerySplitter that takes that query and makes a copy of that
>> entire
>> > SQM tree, one for each mapped implementor of the specified class.
>> FWIW, ORM
>> > does this today, albeit in a different way.  Today we split the query
>> based
>> > on String manip and then feed it parser.  Here we feed it to the parser
>> and
>> > use the tree to split it; much less brittle :)
>> >
>> > Really the cases where this would happen (one "concrete SQM" -> multiple
>> > SQL) would be UPDATE and DELETE queries against "multi-table structures"
>> > (inheritance, secondary tables).
>> >
>> >
>> >> For the purposes of OGM this phase ideally would not be tied to SQL,
>> >> as we phase the same task with non-SQL backends in SQL. I.e. i'd be
>> >> beneficial to have input -> semantic-tree ->
>> >> semantic-output-query-tree(s) -> (SQL|non-SQL query). There
>> >> "semantic-output-query-tree(s)" would be an abstract representation of
>> >> the queries to be executed, e.g. referencing the table name(s). But it
>> >> would be unaware of SQL specifics.
>> >
>> >
>> > OGM would be doing this.  This SQM is the end result of the shared
>> library.
>> > WHat each caller does with the SQM is up to that particular caller.  We
>> > should consider moving QuerySplitter (its in my PoC, which now acts as
>> the
>> > PoC for using this in ORM) into the hibernate-sqm module.  Any caller
>> > wanting to support those unmapped class references will need to do the
>> same
>> > thing.
>>
>> Yes, that'd be good I think. We'd have to apply the same rules for
>> splitting as ORM.
>>
>> >
>> > BTW, another cool thing to note is the (still expanding) support for
>> "strict
>> > JPQL compliance" enforcement.
>>
>

From gbadner at redhat.com  Thu Aug 27 14:03:21 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 27 Aug 2015 11:03:21 -0700
Subject: [hibernate-dev] Hibernate Integrator Causes Flush When Using
 JPA Transactions Around Queries
In-Reply-To: <9CA903B5-7CAD-4E0A-89AE-242C915B7B65@crypteron.com>
References: <9CA903B5-7CAD-4E0A-89AE-242C915B7B65@crypteron.com>
Message-ID: <CAFDzhiRiUGnj+TJ2i6MfGKX5+=9ct6MJtTZ5wVQe+XL572E2Cg@mail.gmail.com>

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 <wolfgang at crypteron.com>
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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu Aug 27 18:11:58 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 27 Aug 2015 15:11:58 -0700
Subject: [hibernate-dev] Hibernate ORM 4.2 and 4.3 branches
Message-ID: <CAFDzhiSRG1gWCMVzO-Dq-wfiwPZFf=uKyEWFCu3PLifW=bk0Aw@mail.gmail.com>

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

From steve at hibernate.org  Thu Aug 27 18:24:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 27 Aug 2015 22:24:29 +0000
Subject: [hibernate-dev] Hibernate ORM 4.2 and 4.3 branches
In-Reply-To: <CAFDzhiSRG1gWCMVzO-Dq-wfiwPZFf=uKyEWFCu3PLifW=bk0Aw@mail.gmail.com>
References: <CAFDzhiSRG1gWCMVzO-Dq-wfiwPZFf=uKyEWFCu3PLifW=bk0Aw@mail.gmail.com>
Message-ID: <CAFdSV9sX9mJxk1TbF=yjsjmZVLp0imf9kNDy9Qv3H4XcL1OMGA@mail.gmail.com>

+1

On Thu, Aug 27, 2015 at 5:12 PM Gail Badner <gbadner at redhat.com> wrote:

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

From dreborier at gmail.com  Fri Aug 28 03:38:51 2015
From: dreborier at gmail.com (andrea boriero)
Date: Fri, 28 Aug 2015 08:38:51 +0100
Subject: [hibernate-dev] Hibernate ORM 4.2 and 4.3 branches
In-Reply-To: <CAFdSV9sX9mJxk1TbF=yjsjmZVLp0imf9kNDy9Qv3H4XcL1OMGA@mail.gmail.com>
References: <CAFDzhiSRG1gWCMVzO-Dq-wfiwPZFf=uKyEWFCu3PLifW=bk0Aw@mail.gmail.com>
	<CAFdSV9sX9mJxk1TbF=yjsjmZVLp0imf9kNDy9Qv3H4XcL1OMGA@mail.gmail.com>
Message-ID: <CAL00eSQTYYvL7TRzuK-5shK5UHo2XR6cZXELih1tPaC-XYaW0Q@mail.gmail.com>

+1

On 27 August 2015 at 23:24, Steve Ebersole <steve at hibernate.org> wrote:

> +1
>
> On Thu, Aug 27, 2015 at 5:12 PM Gail Badner <gbadner at redhat.com> wrote:
>
> > 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Aug 28 07:07:09 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 28 Aug 2015 12:07:09 +0100
Subject: [hibernate-dev] Hibernate ORM SQL generation
In-Reply-To: <CAFdSV9spuAH7crkRuD-HeYKBWjZN-UhAkL==Me--igEfckwtdA@mail.gmail.com>
References: <CAFdSV9vmZB6Y7dLmNo_1npuQqiPFryJYG=J3og0hYF1W+_+szQ@mail.gmail.com>
	<CADGJaX8PGfsBDrAc6S_juSAHR6KtGHC6mtPovxyaPGtpOaCk2A@mail.gmail.com>
	<CAFdSV9vz1gyRmuTwT+o4vWcbsmZGknPDdqFjZNPkp52qmjwxWA@mail.gmail.com>
	<CADGJaX9zV3E+FTzEBDgcTD4QY_g2LM1sm-GzG4evRuNvMUyXLw@mail.gmail.com>
	<CAFdSV9s3h8_TMPhPb_wMEvrqUQuWi=AvUew_aYAaHKw7TUoMSQ@mail.gmail.com>
	<CAFdSV9spuAH7crkRuD-HeYKBWjZN-UhAkL==Me--igEfckwtdA@mail.gmail.com>
Message-ID: <CAFm4XO2NArnR2bajJxMZOEbt3iE3QtagR-nZuHKKw4f9o04qdA@mail.gmail.com>

On 27 August 2015 at 18:30, Steve Ebersole <steve at hibernate.org> wrote:
> Nevermind.  I will not do that.  I think I have found a still-easyish way
> to do it.

Great! Highly appreciate that.


>
> On Thu, Aug 27, 2015 at 10:57 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> I do want to pull ORM in to the hibernate-sqm module as a test dependency
>> to be able to more easily set up the ModelMetadata stuff based on a
>> SessionFactory.  That is possibly awkward later when we then use
>> hibernate-sqm in ORM in terms of having 2 different versions of ORM.  I am
>> open to alternatives that don't involve *me* developing a real(ish) ModelMetadata
>> impl from scratch.
>>
>> On Thu, Aug 27, 2015 at 8:45 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> 2015-08-26 14:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>> > On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>> >>
>>> >> Hi Steve,
>>> >>
>>> >> > The other approach is to use a 3-phase translation (input
>>> >> > -> semantic-tree -> semantic-SQL-tree(s) -> SQL).  This gives a hint
>>> to
>>> >> > one
>>> >> > of the major problems.  One source "semantic" query will often
>>> >> > correspond
>>> >> > to multiple SQL queries; that is hard to manage in the 2-phase
>>> approach.
>>> >>
>>> >> In which situations will this happen? I can see inheritance where a
>>> >> HQL query targeting a super-type needs to be translated into a SQL
>>> >> query per sub-type table. What others are there?
>>> >
>>> >
>>> > For ORM the only time this happens today for a SELECT query is in the
>>> "split
>>> > query" case I mentioned elsewhere (a query like 'from
>>> java.lang.Object').
>>> > SQM does this much better than we do in ORM today.  in SQM we build a
>>> > semantic tree that encodes the "unmapped polymorphism" such that we get
>>> a
>>> > tree with 'java.lang.Object' as the root from element. But it is a
>>> > FromElement with a special type of EntityTypeDescriptor (which comes
>>> from
>>> > the caller remember): PolymorphicEntityTypeDescriptor.  On the ORM side
>>> then
>>> > I have a QuerySplitter that takes that query and makes a copy of that
>>> entire
>>> > SQM tree, one for each mapped implementor of the specified class.
>>> FWIW, ORM
>>> > does this today, albeit in a different way.  Today we split the query
>>> based
>>> > on String manip and then feed it parser.  Here we feed it to the parser
>>> and
>>> > use the tree to split it; much less brittle :)
>>> >
>>> > Really the cases where this would happen (one "concrete SQM" -> multiple
>>> > SQL) would be UPDATE and DELETE queries against "multi-table structures"
>>> > (inheritance, secondary tables).
>>> >
>>> >
>>> >> For the purposes of OGM this phase ideally would not be tied to SQL,
>>> >> as we phase the same task with non-SQL backends in SQL. I.e. i'd be
>>> >> beneficial to have input -> semantic-tree ->
>>> >> semantic-output-query-tree(s) -> (SQL|non-SQL query). There
>>> >> "semantic-output-query-tree(s)" would be an abstract representation of
>>> >> the queries to be executed, e.g. referencing the table name(s). But it
>>> >> would be unaware of SQL specifics.
>>> >
>>> >
>>> > OGM would be doing this.  This SQM is the end result of the shared
>>> library.
>>> > WHat each caller does with the SQM is up to that particular caller.  We
>>> > should consider moving QuerySplitter (its in my PoC, which now acts as
>>> the
>>> > PoC for using this in ORM) into the hibernate-sqm module.  Any caller
>>> > wanting to support those unmapped class references will need to do the
>>> same
>>> > thing.
>>>
>>> Yes, that'd be good I think. We'd have to apply the same rules for
>>> splitting as ORM.
>>>
>>> >
>>> > BTW, another cool thing to note is the (still expanding) support for
>>> "strict
>>> > JPQL compliance" enforcement.
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Aug 28 10:02:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 28 Aug 2015 14:02:44 +0000
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
Message-ID: <CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>

What do y'all think of using a symbol like ~ for this?  The idea would be
similar to the "wavy equals" from logic used to denote "approximately
equals".


On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <andrea at hibernate.org> wrote:

> i like the idea of "matches" operator for dealing with "is null".
> +1
>
> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org> wrote:
>
>> https://hibernate.atlassian.net/browse/SQM-11
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Fri Aug 28 10:09:23 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 28 Aug 2015 15:09:23 +0100
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
Message-ID: <CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>

On 28 August 2015 at 15:02, Steve Ebersole <steve at hibernate.org> wrote:
> What do y'all think of using a symbol like ~ for this?  The idea would be
> similar to the "wavy equals" from logic used to denote "approximately
> equals".

I was hoping that one day we would be able to use the '~' symbol for
full-text queries, i.e. a fuzzy match for text fields to extend HQL.
But we have no concrete plans about that, and we currently don't do a
great job in allowing people to combine full-text restrictions with
relational restrictions, so that might be an unrealistic dream.


> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <andrea at hibernate.org> wrote:
>
>> i like the idea of "matches" operator for dealing with "is null".
>> +1
>>
>> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> https://hibernate.atlassian.net/browse/SQM-11
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From andrea at hibernate.org  Fri Aug 28 10:09:50 2015
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 28 Aug 2015 15:09:50 +0100
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
Message-ID: <CAL00eSQezyVLH70zTW6yhnM288Ux6NAU4mehTPOrnB-n+v3h4A@mail.gmail.com>

+1 for ~

On 28 August 2015 at 15:02, Steve Ebersole <steve at hibernate.org> wrote:

> What do y'all think of using a symbol like ~ for this?  The idea would be
> similar to the "wavy equals" from logic used to denote "approximately
> equals".
>
>
> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <andrea at hibernate.org>
> wrote:
>
>> i like the idea of "matches" operator for dealing with "is null".
>> +1
>>
>> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> https://hibernate.atlassian.net/browse/SQM-11
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From brett at hibernate.org  Fri Aug 28 10:36:13 2015
From: brett at hibernate.org (Brett Meyer)
Date: Fri, 28 Aug 2015 10:36:13 -0400
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
	<CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>
Message-ID: <55E071DD.1080101@hibernate.org>

+1 to ~.  Sanne has a good point, but I think I'd rather see a function 
name there (CONTAINS, etc.).

On 08/28/2015 10:09 AM, Sanne Grinovero wrote:
> On 28 August 2015 at 15:02, Steve Ebersole <steve at hibernate.org> wrote:
>> What do y'all think of using a symbol like ~ for this?  The idea would be
>> similar to the "wavy equals" from logic used to denote "approximately
>> equals".
> I was hoping that one day we would be able to use the '~' symbol for
> full-text queries, i.e. a fuzzy match for text fields to extend HQL.
> But we have no concrete plans about that, and we currently don't do a
> great job in allowing people to combine full-text restrictions with
> relational restrictions, so that might be an unrealistic dream.
>
>
>> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <andrea at hibernate.org> wrote:
>>
>>> i like the idea of "matches" operator for dealing with "is null".
>>> +1
>>>
>>> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> https://hibernate.atlassian.net/browse/SQM-11
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Sat Aug 29 02:46:46 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 29 Aug 2015 08:46:46 +0200
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <55E071DD.1080101@hibernate.org>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
	<CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>
	<55E071DD.1080101@hibernate.org>
Message-ID: <CADGJaX8Qwmwy3zcmBSZoBPX12roQ4PcHLHCAJgwrd1WdMXQdBQ@mail.gmail.com>

I like the idea of a new operator, but I side with Sanne that "~"
would be useful for similarity/full-text searches.

What about "?=", somewhat inspired by Groovy's Elvis operator? It
seems nicer to me for expressing null-awareness. The pattern could
even be generalized by using the operator prefix for making some more
comparison operators null-aware: "?<", "?>" etc.

--Gunnar



2015-08-28 16:36 GMT+02:00 Brett Meyer <brett at hibernate.org>:
> +1 to ~.  Sanne has a good point, but I think I'd rather see a function
> name there (CONTAINS, etc.).
>
> On 08/28/2015 10:09 AM, Sanne Grinovero wrote:
>> On 28 August 2015 at 15:02, Steve Ebersole <steve at hibernate.org> wrote:
>>> What do y'all think of using a symbol like ~ for this?  The idea would be
>>> similar to the "wavy equals" from logic used to denote "approximately
>>> equals".
>> I was hoping that one day we would be able to use the '~' symbol for
>> full-text queries, i.e. a fuzzy match for text fields to extend HQL.
>> But we have no concrete plans about that, and we currently don't do a
>> great job in allowing people to combine full-text restrictions with
>> relational restrictions, so that might be an unrealistic dream.
>>
>>
>>> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <andrea at hibernate.org> wrote:
>>>
>>>> i like the idea of "matches" operator for dealing with "is null".
>>>> +1
>>>>
>>>> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org> wrote:
>>>>
>>>>> https://hibernate.atlassian.net/browse/SQM-11
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Sat Aug 29 13:21:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 29 Aug 2015 17:21:01 +0000
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CADGJaX8Qwmwy3zcmBSZoBPX12roQ4PcHLHCAJgwrd1WdMXQdBQ@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
	<CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>
	<55E071DD.1080101@hibernate.org>
	<CADGJaX8Qwmwy3zcmBSZoBPX12roQ4PcHLHCAJgwrd1WdMXQdBQ@mail.gmail.com>
Message-ID: <CAFdSV9u=MPGHBv215qSgj+PRsA_uuQgfMHeYDise6YGHtOPJ2g@mail.gmail.com>

Sorry, but I agree with Brett.  CONTAINS is a much more natural way to
perform a full-text search, especially for those coming from SQL.

On Sat, Aug 29, 2015 at 1:47 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> I like the idea of a new operator, but I side with Sanne that "~"
> would be useful for similarity/full-text searches.
>
> What about "?=", somewhat inspired by Groovy's Elvis operator? It
> seems nicer to me for expressing null-awareness. The pattern could
> even be generalized by using the operator prefix for making some more
> comparison operators null-aware: "?<", "?>" etc.
>
> --Gunnar
>
>
>
> 2015-08-28 16:36 GMT+02:00 Brett Meyer <brett at hibernate.org>:
> > +1 to ~.  Sanne has a good point, but I think I'd rather see a function
> > name there (CONTAINS, etc.).
> >
> > On 08/28/2015 10:09 AM, Sanne Grinovero wrote:
> >> On 28 August 2015 at 15:02, Steve Ebersole <steve at hibernate.org> wrote:
> >>> What do y'all think of using a symbol like ~ for this?  The idea would
> be
> >>> similar to the "wavy equals" from logic used to denote "approximately
> >>> equals".
> >> I was hoping that one day we would be able to use the '~' symbol for
> >> full-text queries, i.e. a fuzzy match for text fields to extend HQL.
> >> But we have no concrete plans about that, and we currently don't do a
> >> great job in allowing people to combine full-text restrictions with
> >> relational restrictions, so that might be an unrealistic dream.
> >>
> >>
> >>> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <andrea at hibernate.org>
> wrote:
> >>>
> >>>> i like the idea of "matches" operator for dealing with "is null".
> >>>> +1
> >>>>
> >>>> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>>
> >>>>> https://hibernate.atlassian.net/browse/SQM-11
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> >>>>
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sat Aug 29 19:06:44 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 30 Aug 2015 00:06:44 +0100
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CAFdSV9u=MPGHBv215qSgj+PRsA_uuQgfMHeYDise6YGHtOPJ2g@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
	<CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>
	<55E071DD.1080101@hibernate.org>
	<CADGJaX8Qwmwy3zcmBSZoBPX12roQ4PcHLHCAJgwrd1WdMXQdBQ@mail.gmail.com>
	<CAFdSV9u=MPGHBv215qSgj+PRsA_uuQgfMHeYDise6YGHtOPJ2g@mail.gmail.com>
Message-ID: <CAFm4XO0jjSV-YVAvSdBmHfbJQ35OF82fT_7Srvuue6q-cOSnxw@mail.gmail.com>

I think we all agree that we want at least the high level intent of an
HQL query to be understandable without having to keep a reference
sheet of its special symbols at hand.

I would interpret that "~" symbol differently, so I don't think it's
suited to imply some special meaning related to "null" and while I
normally understand we argue about "naming things" as we all have
different language backgrounds, this one seems universally established
in the scientific world, so I'm afraid that it would look a really odd
choice to most users.

Gunnar's proposal looks better, as that's commonly used in similar
scenarios: beyond Groovy, it's commonly used for ternary operator
which is essentially a short hand for a conditional:
  - https://en.wikipedia.org/wiki/%3F:

On full-text query, looks like a clarification is in order on why I
was thinking about that symbol specifically:
A full-text query goes far beyond "containing" some keywords; for
example it can provide matches on synonyms, disregard typos, expand
acronyms, or even give different semantic value for words depending on
their position and role in a sentence. The match is really about
"search stuff which is semantically similar to this".
I realize that most SQL technologies provide only a limited subset of
such options, and that's exactly why we provide alternatives like
Hibernate Search which do much more and better ;-)
i.e. with Search such an operator would mean "equals or almost
equals", for some definition of "almost equals" which we allow the
user to specify precisely in the mapping and configuration.

Thanks,
Sanne

On 29 August 2015 at 18:21, Steve Ebersole <steve at hibernate.org> wrote:
> Sorry, but I agree with Brett.  CONTAINS is a much more natural way to
> perform a full-text search, especially for those coming from SQL.
>
> On Sat, Aug 29, 2015 at 1:47 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> I like the idea of a new operator, but I side with Sanne that "~"
>> would be useful for similarity/full-text searches.
>>
>> What about "?=", somewhat inspired by Groovy's Elvis operator? It
>> seems nicer to me for expressing null-awareness. The pattern could
>> even be generalized by using the operator prefix for making some more
>> comparison operators null-aware: "?<", "?>" etc.
>>
>> --Gunnar
>>
>>
>>
>> 2015-08-28 16:36 GMT+02:00 Brett Meyer <brett at hibernate.org>:
>> > +1 to ~.  Sanne has a good point, but I think I'd rather see a function
>> > name there (CONTAINS, etc.).
>> >
>> > On 08/28/2015 10:09 AM, Sanne Grinovero wrote:
>> >> On 28 August 2015 at 15:02, Steve Ebersole <steve at hibernate.org> wrote:
>> >>> What do y'all think of using a symbol like ~ for this?  The idea would
>> be
>> >>> similar to the "wavy equals" from logic used to denote "approximately
>> >>> equals".
>> >> I was hoping that one day we would be able to use the '~' symbol for
>> >> full-text queries, i.e. a fuzzy match for text fields to extend HQL.
>> >> But we have no concrete plans about that, and we currently don't do a
>> >> great job in allowing people to combine full-text restrictions with
>> >> relational restrictions, so that might be an unrealistic dream.
>> >>
>> >>
>> >>> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <andrea at hibernate.org>
>> wrote:
>> >>>
>> >>>> i like the idea of "matches" operator for dealing with "is null".
>> >>>> +1
>> >>>>
>> >>>> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>>>
>> >>>>> https://hibernate.atlassian.net/browse/SQM-11
>> >>>>> _______________________________________________
>> >>>>> hibernate-dev mailing list
>> >>>>> hibernate-dev at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>>
>> >>>>
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Sat Aug 29 19:17:34 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 29 Aug 2015 23:17:34 +0000
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CAFm4XO0jjSV-YVAvSdBmHfbJQ35OF82fT_7Srvuue6q-cOSnxw@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
	<CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>
	<55E071DD.1080101@hibernate.org>
	<CADGJaX8Qwmwy3zcmBSZoBPX12roQ4PcHLHCAJgwrd1WdMXQdBQ@mail.gmail.com>
	<CAFdSV9u=MPGHBv215qSgj+PRsA_uuQgfMHeYDise6YGHtOPJ2g@mail.gmail.com>
	<CAFm4XO0jjSV-YVAvSdBmHfbJQ35OF82fT_7Srvuue6q-cOSnxw@mail.gmail.com>
Message-ID: <CAFdSV9sTOL0FbuK8Ut4KV2gk0=XGWHa0RTB-TcgNS0K16yG4iQ@mail.gmail.com>

So if we don't want to use ~ here, I am fine with that.  However I do not
want this used for full text searching.

On Sat, Aug 29, 2015, 6:07 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> I think we all agree that we want at least the high level intent of an
> HQL query to be understandable without having to keep a reference
> sheet of its special symbols at hand.
>
> I would interpret that "~" symbol differently, so I don't think it's
> suited to imply some special meaning related to "null" and while I
> normally understand we argue about "naming things" as we all have
> different language backgrounds, this one seems universally established
> in the scientific world, so I'm afraid that it would look a really odd
> choice to most users.
>
> Gunnar's proposal looks better, as that's commonly used in similar
> scenarios: beyond Groovy, it's commonly used for ternary operator
> which is essentially a short hand for a conditional:
>   - https://en.wikipedia.org/wiki/%3F:
>
> On full-text query, looks like a clarification is in order on why I
> was thinking about that symbol specifically:
> A full-text query goes far beyond "containing" some keywords; for
> example it can provide matches on synonyms, disregard typos, expand
> acronyms, or even give different semantic value for words depending on
> their position and role in a sentence. The match is really about
> "search stuff which is semantically similar to this".
> I realize that most SQL technologies provide only a limited subset of
> such options, and that's exactly why we provide alternatives like
> Hibernate Search which do much more and better ;-)
> i.e. with Search such an operator would mean "equals or almost
> equals", for some definition of "almost equals" which we allow the
> user to specify precisely in the mapping and configuration.
>
> Thanks,
> Sanne
>
> On 29 August 2015 at 18:21, Steve Ebersole <steve at hibernate.org> wrote:
> > Sorry, but I agree with Brett.  CONTAINS is a much more natural way to
> > perform a full-text search, especially for those coming from SQL.
> >
> > On Sat, Aug 29, 2015 at 1:47 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >
> >> I like the idea of a new operator, but I side with Sanne that "~"
> >> would be useful for similarity/full-text searches.
> >>
> >> What about "?=", somewhat inspired by Groovy's Elvis operator? It
> >> seems nicer to me for expressing null-awareness. The pattern could
> >> even be generalized by using the operator prefix for making some more
> >> comparison operators null-aware: "?<", "?>" etc.
> >>
> >> --Gunnar
> >>
> >>
> >>
> >> 2015-08-28 16:36 GMT+02:00 Brett Meyer <brett at hibernate.org>:
> >> > +1 to ~.  Sanne has a good point, but I think I'd rather see a
> function
> >> > name there (CONTAINS, etc.).
> >> >
> >> > On 08/28/2015 10:09 AM, Sanne Grinovero wrote:
> >> >> On 28 August 2015 at 15:02, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> >>> What do y'all think of using a symbol like ~ for this?  The idea
> would
> >> be
> >> >>> similar to the "wavy equals" from logic used to denote
> "approximately
> >> >>> equals".
> >> >> I was hoping that one day we would be able to use the '~' symbol for
> >> >> full-text queries, i.e. a fuzzy match for text fields to extend HQL.
> >> >> But we have no concrete plans about that, and we currently don't do a
> >> >> great job in allowing people to combine full-text restrictions with
> >> >> relational restrictions, so that might be an unrealistic dream.
> >> >>
> >> >>
> >> >>> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <
> andrea at hibernate.org>
> >> wrote:
> >> >>>
> >> >>>> i like the idea of "matches" operator for dealing with "is null".
> >> >>>> +1
> >> >>>>
> >> >>>> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >> >>>>
> >> >>>>> https://hibernate.atlassian.net/browse/SQM-11
> >> >>>>> _______________________________________________
> >> >>>>> hibernate-dev mailing list
> >> >>>>> hibernate-dev at lists.jboss.org
> >> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>>>>
> >> >>>>
> >> >>> _______________________________________________
> >> >>> hibernate-dev mailing list
> >> >>> hibernate-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat Aug 29 19:22:08 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 29 Aug 2015 23:22:08 +0000
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
	thoughts?
In-Reply-To: <CAFdSV9sTOL0FbuK8Ut4KV2gk0=XGWHa0RTB-TcgNS0K16yG4iQ@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
	<CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>
	<55E071DD.1080101@hibernate.org>
	<CADGJaX8Qwmwy3zcmBSZoBPX12roQ4PcHLHCAJgwrd1WdMXQdBQ@mail.gmail.com>
	<CAFdSV9u=MPGHBv215qSgj+PRsA_uuQgfMHeYDise6YGHtOPJ2g@mail.gmail.com>
	<CAFm4XO0jjSV-YVAvSdBmHfbJQ35OF82fT_7Srvuue6q-cOSnxw@mail.gmail.com>
	<CAFdSV9sTOL0FbuK8Ut4KV2gk0=XGWHa0RTB-TcgNS0K16yG4iQ@mail.gmail.com>
Message-ID: <CAFdSV9v4QS0JdkQXHEqaD4kiXwrePogjsAxOfXiRLADEL8cdSw@mail.gmail.com>

My phone is being crazy with sending replies :(

So if we don't want to use ~ here, I am fine with that.  However I do not
want this used for full text searching.  Your argument is that its "not a
natural fit" for use in this nullness checking, but that same argument fits
full text searching.

On Sat, Aug 29, 2015 at 6:17 PM Steve Ebersole <steve at hibernate.org> wrote:

> So if we don't want to use ~ here, I am fine with that.  However I do not
> want this used for full text searching.
>
> On Sat, Aug 29, 2015, 6:07 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> I think we all agree that we want at least the high level intent of an
>> HQL query to be understandable without having to keep a reference
>> sheet of its special symbols at hand.
>>
>> I would interpret that "~" symbol differently, so I don't think it's
>> suited to imply some special meaning related to "null" and while I
>> normally understand we argue about "naming things" as we all have
>> different language backgrounds, this one seems universally established
>> in the scientific world, so I'm afraid that it would look a really odd
>> choice to most users.
>>
>> Gunnar's proposal looks better, as that's commonly used in similar
>> scenarios: beyond Groovy, it's commonly used for ternary operator
>> which is essentially a short hand for a conditional:
>>   - https://en.wikipedia.org/wiki/%3F:
>>
>> On full-text query, looks like a clarification is in order on why I
>> was thinking about that symbol specifically:
>> A full-text query goes far beyond "containing" some keywords; for
>> example it can provide matches on synonyms, disregard typos, expand
>> acronyms, or even give different semantic value for words depending on
>> their position and role in a sentence. The match is really about
>> "search stuff which is semantically similar to this".
>> I realize that most SQL technologies provide only a limited subset of
>> such options, and that's exactly why we provide alternatives like
>> Hibernate Search which do much more and better ;-)
>> i.e. with Search such an operator would mean "equals or almost
>> equals", for some definition of "almost equals" which we allow the
>> user to specify precisely in the mapping and configuration.
>>
>> Thanks,
>> Sanne
>>
>> On 29 August 2015 at 18:21, Steve Ebersole <steve at hibernate.org> wrote:
>> > Sorry, but I agree with Brett.  CONTAINS is a much more natural way to
>> > perform a full-text search, especially for those coming from SQL.
>> >
>> > On Sat, Aug 29, 2015 at 1:47 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >
>> >> I like the idea of a new operator, but I side with Sanne that "~"
>> >> would be useful for similarity/full-text searches.
>> >>
>> >> What about "?=", somewhat inspired by Groovy's Elvis operator? It
>> >> seems nicer to me for expressing null-awareness. The pattern could
>> >> even be generalized by using the operator prefix for making some more
>> >> comparison operators null-aware: "?<", "?>" etc.
>> >>
>> >> --Gunnar
>> >>
>> >>
>> >>
>> >> 2015-08-28 16:36 GMT+02:00 Brett Meyer <brett at hibernate.org>:
>> >> > +1 to ~.  Sanne has a good point, but I think I'd rather see a
>> function
>> >> > name there (CONTAINS, etc.).
>> >> >
>> >> > On 08/28/2015 10:09 AM, Sanne Grinovero wrote:
>> >> >> On 28 August 2015 at 15:02, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >> >>> What do y'all think of using a symbol like ~ for this?  The idea
>> would
>> >> be
>> >> >>> similar to the "wavy equals" from logic used to denote
>> "approximately
>> >> >>> equals".
>> >> >> I was hoping that one day we would be able to use the '~' symbol for
>> >> >> full-text queries, i.e. a fuzzy match for text fields to extend HQL.
>> >> >> But we have no concrete plans about that, and we currently don't do
>> a
>> >> >> great job in allowing people to combine full-text restrictions with
>> >> >> relational restrictions, so that might be an unrealistic dream.
>> >> >>
>> >> >>
>> >> >>> On Thu, Aug 27, 2015 at 7:05 AM andrea boriero <
>> andrea at hibernate.org>
>> >> wrote:
>> >> >>>
>> >> >>>> i like the idea of "matches" operator for dealing with "is null".
>> >> >>>> +1
>> >> >>>>
>> >> >>>> On 26 August 2015 at 19:32, Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >> >>>>
>> >> >>>>> https://hibernate.atlassian.net/browse/SQM-11
>> >> >>>>> _______________________________________________
>> >> >>>>> hibernate-dev mailing list
>> >> >>>>> hibernate-dev at lists.jboss.org
>> >> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >>>>>
>> >> >>>>
>> >> >>> _______________________________________________
>> >> >>> hibernate-dev mailing list
>> >> >>> hibernate-dev at lists.jboss.org
>> >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >> _______________________________________________
>> >> >> hibernate-dev mailing list
>> >> >> hibernate-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From hardy at hibernate.org  Sun Aug 30 15:20:46 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Sun, 30 Aug 2015 21:20:46 +0200
Subject: [hibernate-dev] SQM-11 : Consider a new matches operator -
 thoughts?
In-Reply-To: <CAFdSV9v4QS0JdkQXHEqaD4kiXwrePogjsAxOfXiRLADEL8cdSw@mail.gmail.com>
References: <CAFdSV9s501nMnFLNDRx0wYYUDeu=0=fboCb0Oqawmt3rkOBMnQ@mail.gmail.com>
	<CAL00eSQgJYZY=nQVtaBxM0Q536O=EabfnA1_3aHc_4DcfFMarA@mail.gmail.com>
	<CAFdSV9upinb_1BbTv84-=hGhoExjzEbZ-8uvpPnSi7Pr8Txnxw@mail.gmail.com>
	<CAFm4XO2XONiXvqaVS0DZBfLXPSY3yO-aHxr579Hty+YZLqyDkw@mail.gmail.com>
	<55E071DD.1080101@hibernate.org>
	<CADGJaX8Qwmwy3zcmBSZoBPX12roQ4PcHLHCAJgwrd1WdMXQdBQ@mail.gmail.com>
	<CAFdSV9u=MPGHBv215qSgj+PRsA_uuQgfMHeYDise6YGHtOPJ2g@mail.gmail.com>
	<CAFm4XO0jjSV-YVAvSdBmHfbJQ35OF82fT_7Srvuue6q-cOSnxw@mail.gmail.com>
	<CAFdSV9sTOL0FbuK8Ut4KV2gk0=XGWHa0RTB-TcgNS0K16yG4iQ@mail.gmail.com>
	<CAFdSV9v4QS0JdkQXHEqaD4kiXwrePogjsAxOfXiRLADEL8cdSw@mail.gmail.com>
Message-ID: <20150830192046.GA94183@Nineveh.lan>

Hi,

> So if we don't want to use ~ here, I am fine with that.

+1 

> However I do not want this used for full text searching.

+1 I find it a bad match as well. First I think the type of integration we
would need between ORM and Search is faaaaar off in the future. If it even
makes sense.

Also the '~' has a very specific funtion in full text queries as well. 
Fuzzy query in the Lucene world. So using '~' as a general full text search
operator seems wrong from that perspective as well.

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

From steve at hibernate.org  Sun Aug 30 15:31:47 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 30 Aug 2015 19:31:47 +0000
Subject: [hibernate-dev] SQM - initial UPDATE/DELETE support
Message-ID: <CAFdSV9tfE2FbQ5q23YuJ2MoAKi-pi8_pdap_BcLMRDrJ0cdn9g@mail.gmail.com>

Just a heads up that I added initial support for UPDATE/DELETE statements
this weekend.  I am not happy with the way the "root from element" is
modeled in UPDATE/DELETE statements, and especially the wide difference
with how they work with SelectStatement and FromClause.  I plan to do some
more work there.

I think part of that is to move away from using a concrete FromClause as
the base for the "stack", instead leveraging a contract more like
FromElementSpace and something like a FromElementContainer (FromClause
would be one such container, so would a UpdateStatement and a
DeleteStatement).  Still brainstorming the specifics at the moment.