date:20170127

On Tue, Sep 13, 2016 at 9:55 PM Gail Badner  wrote:

> Sorry for the late response. I've been looking through the fix for
> HHH-5163 [1] to jog my memory.
>
> Here are some reasons why CacheableResultTransformer is important when
> caching query results:
>
> 1) The same SQL can be generated when associations are joined as when
> associations are fetched, but what gets cached is different. The cached
> results exclude fetched associations. QueryKey needs to contain the proper
> CacheableResultTransformer to indicate which tuple elements are cached to
> distinguish the differing results.
>

Just to be clear... Those 2 cases *do not* generate the same SQL.  In fetch
case the SELECT clause includes the association columns, in the
non-fetch-join case it doe not.

But I understand what you mean.  And with 6.0 this is no longer a concern
since all of the selections (the SQL selections) are cached.  Along with
the fact that we know the "fetch graph" now in 6.0 wrt that cached data we
can easily (well "easily" is relative) rebuild the full graph.

> 2) IIRC, the tuple elements that got cached by the legacy Criteria and HQL
> were inconsistent, and I believe that in some cases the ResultTransformer
> was applied before caching the value, which added to problems assembling
> the query results (HHH--2463). CacheableResultTransformer ensured that what
> got cached was consistent (excluding fetched values), and ensured that rows
> were untransformed (padded with nulls where fetches were) and
> re-transformed (if necessary) by a specified transformer as necessary.
>

Right.  This is it.  And with 6.0 because we now cache the actual JDBC
values (meaning transformations are applied "on top of" the cached values)
this is no longer a concern.

> I added lots of tests for this change, so I think we will find out quickly
> if something gets broken.
>

Sweet!  Although hopefully the tests do not assert that fetched
 associations are no longer present.  That was not the case pre-6.x but is
no longer true as discussed above.

Steve, I'm not completely following your discussion. Some pseudocode would
> help.
>

I gave psuedo code above and in the Jira I linked.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Query#iterate

I know I started a discussion of this somewhere with some of you, but I
cannot find it anymore.

I had suggested we consider getting rid of this Query#iterate method.  I
just wanted to get everyone's opinions of this.  Specifically, getting of
it in 6.0.

If anyone has dug much into the current Antlr 2 based parser you will be
familiar with this idea of shallow versus non-shallow queries.  That is
where this comes into play.  Query#iterate is a shallow query
(shallow=true).  All other queries are non-shallow.

There are quite a few internal reasons to simply drop that method and get
rid of the idea of this shallow flag.  I am happy to discuss these reasons
for those interested and that do not know.

But obviously we should not be getting rid of things just because of
"internal complications" if they are used by many users.  I cannot speak to
whether any users use this, let alone how many.

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

Re: [hibernate-dev] Query#iterate

I just know of people that are using iterate() now for efficient 
incremental processing, but I guess any other approach(streams maybe?) 
to do incremental processing would be good enough for these users.

Unfortunately I don't know what a shallow query is or what the 
implication on the query or the processing of being shallow are.
I guess this has to do with how row processing is done? I can imagine 
that this complicates the implementation, but really, there are users 
out there which rely on the performance model of that.

Am 27.01.2017 um 15:42 schrieb Steve Ebersole:
> I know I started a discussion of this somewhere with some of you, but I
> cannot find it anymore.
>
> I had suggested we consider getting rid of this Query#iterate method.  I
> just wanted to get everyone's opinions of this.  Specifically, getting of
> it in 6.0.
>
> If anyone has dug much into the current Antlr 2 based parser you will be
> familiar with this idea of shallow versus non-shallow queries.  That is
> where this comes into play.  Query#iterate is a shallow query
> (shallow=true).  All other queries are non-shallow.
>
> There are quite a few internal reasons to simply drop that method and get
> rid of the idea of this shallow flag.  I am happy to discuss these reasons
> for those interested and that do not know.
>
> But obviously we should not be getting rid of things just because of
> "internal complications" if they are used by many users.  I cannot speak to
> whether any users use this, let alone how many.
>
> Thoughts?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[hibernate-dev] boolean type support

Another thing we run into in 6.0 dev is handling booleans, specifically in
regards to dealing with the database representation (0 or 1, versus 'T' of
'F', versus ...).

The way we handle this today (pre-6.0) is to "fake it" by registering a
JavaTypeDescriptor for each representation combo[1].  We can obviously
continue to do it this way.

But in moving forward we wanted to take a step back and look at this
again.  And really this is the kind of scenario that AttributeConverters
are designed to handle.  So we are considering to instead actually handle
this via an AttributeConverter.  To fully understand this remember that we
have also moved AttributeConverter tracking on to the attribute[2] itself
as opposed to "baking it" into a Type.  In that way it would just be
handled by the "type system" to automatically add an AttributeConverter to
the attribute.

Obviously that only works if there is not already an AttributeConverter
applied to to the attribute.  I cannot imagine that ever happens in a
supported way, or a way that we want to support.  Essentially that would
mean a condition where we convert the value twice in each direction.  But
in case we miss some ase, I wanted to ask the list.


[1] Yes, it seems odd that this is handled in the JavaTypeDescriptor.  The
reason it happens that way is that it is incorporated into the wrap/unwrap
code.
[2] I say "attribute" just a a means of simplification.  It is really a
Navigable which is new concept and probably not well known to everyone..
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] boolean type support

Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> Obviously that only works if there is not already an AttributeConverter
> applied to to the attribute.  I cannot imagine that ever happens in a
> supported way, or a way that we want to support.  Essentially that would
> mean a condition where we convert the value twice in each direction.  But
> in case we miss some ase, I wanted to ask the list.
So if a user defines a converter for Boolean=>Enum for example, that 
would not work on e.g. Oracle since on such a DB the column type is integer?
I am not sure if a converter for Boolean as source type would make 
sense, but if allowing it adds a lot of complexity I'd say don't support 
it for now and wait for a user to complain. Seems like a pretty edgy 
edge case to me :D
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [HV/HSEARCH] Free form

2017-01-27 Thread Emmanuel Bernard

I took the flight home to play with free form and specifically how we would
retrieve data from the free form structure.
By free-form I mean non POJO but they will have schema (not expressed here).

https://github.com/emmanuelbernard/hibernate-search/commit/0bd3fbab137bdad81bfa5b9934063792a050f537

And in particular
https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/StructureTraverser.java
https://github.com/emmanuelbernard/hibernate-search/blob/freeform/freeform/src/main/java/org/hibernate/freeform/pojo/impl/PojoStructureTraverser.java

It probably does not compile, I could not make the build work.

I figured it was important to dump this raw thinking because it will influence
and will be influenced by the redesign of the DocumentBuilder of Hibernate
Search.

There are several options for traversing a free form structure
- expose the traversing API as a holder to navigate all properties per
structure and sub structure. This is what the prototype shows. Caching needs to
be accessed via a hashmap get or other lookup. Metadata and the traversing
structure will be navigated in parallel
- expose a structure that is specialized to a single property or container
unwrapping aspect. The structures will be spread across and embedded in the
Metadata

Another angle:
- create a traversable object per payload to carry it (sharing metadata info
per type)
- have a stateless traversable object that is provided the payload for each
access

The former seems better as it does not create a traversable object per object
navigated.
The latter is better for payloads that need parsing or are better at sequential
access since state could be cached.

We need to discuss that and know where DocumentBuilder is going to properly
design this API.

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

Re: [hibernate-dev] Query#iterate

I would not bother too much about iterate since it can be easily emulated
with an entity query.
If I recall correctly, Query#iterate does something like this:

select e.id
from Entity e
where condition

and for every identifier we can load the entity from the 2nd-level cache
instead of loading it from the DB.

Now, if the entities are not already cached, it will be a disaster if N is
fairly large.
For this reason, I think we should deprecate it and remove it anyway.

Vlad

On Fri, Jan 27, 2017 at 5:50 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> I just know of people that are using iterate() now for efficient
> incremental processing, but I guess any other approach(streams maybe?)
> to do incremental processing would be good enough for these users.
>
> Unfortunately I don't know what a shallow query is or what the
> implication on the query or the processing of being shallow are.
> I guess this has to do with how row processing is done? I can imagine
> that this complicates the implementation, but really, there are users
> out there which rely on the performance model of that.
>
> Am 27.01.2017 um 15:42 schrieb Steve Ebersole:
> > I know I started a discussion of this somewhere with some of you, but I
> > cannot find it anymore.
> >
> > I had suggested we consider getting rid of this Query#iterate method.  I
> > just wanted to get everyone's opinions of this.  Specifically, getting of
> > it in 6.0.
> >
> > If anyone has dug much into the current Antlr 2 based parser you will be
> > familiar with this idea of shallow versus non-shallow queries.  That is
> > where this comes into play.  Query#iterate is a shallow query
> > (shallow=true).  All other queries are non-shallow.
> >
> > There are quite a few internal reasons to simply drop that method and get
> > rid of the idea of this shallow flag.  I am happy to discuss these
> reasons
> > for those interested and that do not know.
> >
> > But obviously we should not be getting rid of things just because of
> > "internal complications" if they are used by many users.  I cannot speak
> to
> > whether any users use this, let alone how many.
> >
> > Thoughts?
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Query#iterate

On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov 
wrote:

> I just know of people that are using iterate() now for efficient
> incremental processing, but I guess any other approach(streams maybe?)
> to do incremental processing would be good enough for these users.
>
>
ScrollableResults do not meet that need?

> Unfortunately I don't know what a shallow query is or what the
> implication on the query or the processing of being shallow are.
>

Just what I said before.  "shallow" is simply a boolean flag that is part
of the translator.  It is set to true when the translation is triggered
from Query#iterate.  When the translation is triggered from Query#list or
Query#scroll it is set to false.

> I guess this has to do with how row processing is done?

The main thing is effects is the SQL we render.  For "entity returns" it
simply selects the ids and we expect to then load them (immediately!) by
that id (N+1).  Its usefulness is actually VERY limited in scope as it
actually performs horrendously in, what, 95-99% of use cases?

Interestingly it really does not have much effect on "row processing".
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Query#iterate

I'm sorry, I apparently confused iterate() with scroll() then, so forget 
what I wrote before ^^

In face of that new info, I actually don't know of any actual users. 
After thinking a bit about it, why not make that behavior configurable 
via setProperty and drop that method?

Am 27.01.2017 um 19:01 schrieb Steve Ebersole:
> On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov 
> mailto:christian.bei...@gmail.com>> wrote:
>
> I just know of people that are using iterate() now for efficient
> incremental processing, but I guess any other approach(streams maybe?)
> to do incremental processing would be good enough for these users.
>
>
> ScrollableResults do not meet that need?
>
> Unfortunately I don't know what a shallow query is or what the
> implication on the query or the processing of being shallow are.
>
>
> Just what I said before.  "shallow" is simply a boolean flag that is 
> part of the translator.  It is set to true when the translation is 
> triggered from Query#iterate.  When the translation is triggered from 
> Query#list or Query#scroll it is set to false.
>
> I guess this has to do with how row processing is done?
>
>
> The main thing is effects is the SQL we render.  For "entity returns" 
> it simply selects the ids and we expect to then load them 
> (immediately!) by that id (N+1).  Its usefulness is actually VERY 
> limited in scope as it actually performs horrendously in, what, 95-99% 
> of use cases?
>
> Interestingly it really does not have much effect on "row processing".
>

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

Re: [hibernate-dev] boolean type support

On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
christian.bei...@gmail.com> wrote:

> Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> > Obviously that only works if there is not already an AttributeConverter
> > applied to to the attribute.  I cannot imagine that ever happens in a
> > supported way, or a way that we want to support.  Essentially that would
> > mean a condition where we convert the value twice in each direction.  But
> > in case we miss some ase, I wanted to ask the list.
> So if a user defines a converter for Boolean=>Enum for example, that
> would not work on e.g. Oracle since on such a DB the column type is
> integer?
>

I am not following what you mean.  Why would an enum be a boolean?  You
mean something like:

enum Sex { MALE, FEMALE )

and then storing into the DB as `IS_MALE`?

I mean I guess someone *could* write an app that way.  I'd laugh at them,
but I guess they could ;)

Anyway, they can already do that... it called an AttributeConverter :P

More I am asking about the legacy BooleanType, YesNoType and
TrueFalseType.  These each used different JavaTypeDescriptor instances
encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..)
representations.

So in stepping back and thinking about how this "should" be designed, I am
thinking that the most logical design is to have just a single
JavaTypeDesriptor for boolean and to somehow keep the specific DB storage
representations as part of the attribute[1].

But then we start thinking how that should affect the wrap/unwrap process.
Well, we already have a way for attribute-level "config" to alter the
wrap/unwrap process - again, AttributeConverter.  So at the minimum we will
handle this in the same manner as we hande AttributeConverter.  But then we
asked whether we might just *use* AttributeConverter for this; this design
works well, so long as these attributes do not also have an
AttributeConverter associated with them.

I think I'd propose this...

We'd essentially say that we do not natively understand how to store
booleans (just bear with me...).  Specifically how to convert them into a
DB storable format.  Which means we'd need something to help us perform
that conversion.  If the user has attached an AttributeConverter to the
attribute we'd simply use that.  If they have not, then we'd look to this
config option to see if they have specified how to do that globally.  If
they have not done that either, we'd simply as the Dialect.

[1] I'd never do this, but it is entirely possible that a user would want a
boolean value from one attribute stored in the DB as 0/1 and another
attribute store as Y/N.  So attribute is the highest granularity we need to
resolve this at.  But they might instead very well want to store all
boolean values in their app to the DB as a single representation - we'd
support that via config, as well as fallback to Dialect
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Query#iterate

Because the behavior is also fundamentally questionable.

On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
christian.bei...@gmail.com> wrote:

> I'm sorry, I apparently confused iterate() with scroll() then, so forget
> what I wrote before ^^
>
> In face of that new info, I actually don't know of any actual users. After
> thinking a bit about it, why not make that behavior configurable via
> setProperty and drop that method?
>
>
> Am 27.01.2017 um 19:01 schrieb Steve Ebersole:
>
> On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
> I just know of people that are using iterate() now for efficient
> incremental processing, but I guess any other approach(streams maybe?)
> to do incremental processing would be good enough for these users.
>
>
> ScrollableResults do not meet that need?
>
>
>
> Unfortunately I don't know what a shallow query is or what the
> implication on the query or the processing of being shallow are.
>
>
> Just what I said before.  "shallow" is simply a boolean flag that is part
> of the translator.  It is set to true when the translation is triggered
> from Query#iterate.  When the translation is triggered from Query#list or
> Query#scroll it is set to false.
>
>
>
> I guess this has to do with how row processing is done?
>
>
> The main thing is effects is the SQL we render.  For "entity returns" it
> simply selects the ids and we expect to then load them (immediately!) by
> that id (N+1).  Its usefulness is actually VERY limited in scope as it
> actually performs horrendously in, what, 95-99% of use cases?
>
> Interestingly it really does not have much effect on "row processing".
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] boolean type support

Correction : If they have not done that either, we'd simply *ask* the
Dialect.

On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole  wrote:

> On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
> Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> > Obviously that only works if there is not already an AttributeConverter
> > applied to to the attribute.  I cannot imagine that ever happens in a
> > supported way, or a way that we want to support.  Essentially that would
> > mean a condition where we convert the value twice in each direction.  But
> > in case we miss some ase, I wanted to ask the list.
> So if a user defines a converter for Boolean=>Enum for example, that
> would not work on e.g. Oracle since on such a DB the column type is
> integer?
>
>
> I am not following what you mean.  Why would an enum be a boolean?  You
> mean something like:
>
> enum Sex { MALE, FEMALE )
>
> and then storing into the DB as `IS_MALE`?
>
> I mean I guess someone *could* write an app that way.  I'd laugh at them,
> but I guess they could ;)
>
> Anyway, they can already do that... it called an AttributeConverter :P
>
> More I am asking about the legacy BooleanType, YesNoType and
> TrueFalseType.  These each used different JavaTypeDescriptor instances
> encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..)
> representations.
>
> So in stepping back and thinking about how this "should" be designed, I am
> thinking that the most logical design is to have just a single
> JavaTypeDesriptor for boolean and to somehow keep the specific DB storage
> representations as part of the attribute[1].
>
> But then we start thinking how that should affect the wrap/unwrap
> process.  Well, we already have a way for attribute-level "config" to alter
> the wrap/unwrap process - again, AttributeConverter.  So at the minimum we
> will handle this in the same manner as we hande AttributeConverter.  But
> then we asked whether we might just *use* AttributeConverter for this; this
> design works well, so long as these attributes do not also have an
> AttributeConverter associated with them.
>
> I think I'd propose this...
>
> We'd essentially say that we do not natively understand how to store
> booleans (just bear with me...).  Specifically how to convert them into a
> DB storable format.  Which means we'd need something to help us perform
> that conversion.  If the user has attached an AttributeConverter to the
> attribute we'd simply use that.  If they have not, then we'd look to this
> config option to see if they have specified how to do that globally.  If
> they have not done that either, we'd simply as the Dialect.
>
>
> [1] I'd never do this, but it is entirely possible that a user would want
> a boolean value from one attribute stored in the DB as 0/1 and another
> attribute store as Y/N.  So attribute is the highest granularity we need to
> resolve this at.  But they might instead very well want to store all
> boolean values in their app to the DB as a single representation - we'd
> support that via config, as well as fallback to Dialect
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Query#iterate

I'm for removing it even if it didn't complicate the query parser.

Vlad

On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole  wrote:

> Because the behavior is also fundamentally questionable.
>
> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
> > I'm sorry, I apparently confused iterate() with scroll() then, so forget
> > what I wrote before ^^
> >
> > In face of that new info, I actually don't know of any actual users.
> After
> > thinking a bit about it, why not make that behavior configurable via
> > setProperty and drop that method?
> >
> >
> > Am 27.01.2017 um 19:01 schrieb Steve Ebersole:
> >
> > On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov <
> > christian.bei...@gmail.com> wrote:
> >
> > I just know of people that are using iterate() now for efficient
> > incremental processing, but I guess any other approach(streams maybe?)
> > to do incremental processing would be good enough for these users.
> >
> >
> > ScrollableResults do not meet that need?
> >
> >
> >
> > Unfortunately I don't know what a shallow query is or what the
> > implication on the query or the processing of being shallow are.
> >
> >
> > Just what I said before.  "shallow" is simply a boolean flag that is part
> > of the translator.  It is set to true when the translation is triggered
> > from Query#iterate.  When the translation is triggered from Query#list or
> > Query#scroll it is set to false.
> >
> >
> >
> > I guess this has to do with how row processing is done?
> >
> >
> > The main thing is effects is the SQL we render.  For "entity returns" it
> > simply selects the ids and we expect to then load them (immediately!) by
> > that id (N+1).  Its usefulness is actually VERY limited in scope as it
> > actually performs horrendously in, what, 95-99% of use cases?
> >
> > Interestingly it really does not have much effect on "row processing".
> >
> >
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] boolean type support

If you think we can handle this better using Attributes, then we can give
it a try.

Nevertheless, the current implementation is nice as well. We have a single
Java descriptor and multiple Sql descriptors to cover various DB column
types or column values.

Vlad

On Fri, Jan 27, 2017 at 8:28 PM, Steve Ebersole  wrote:

> Correction : If they have not done that either, we'd simply *ask* the
> Dialect.
>
> On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole 
> wrote:
>
> > On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
> > christian.bei...@gmail.com> wrote:
> >
> > Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> > > Obviously that only works if there is not already an AttributeConverter
> > > applied to to the attribute.  I cannot imagine that ever happens in a
> > > supported way, or a way that we want to support.  Essentially that
> would
> > > mean a condition where we convert the value twice in each direction.
> But
> > > in case we miss some ase, I wanted to ask the list.
> > So if a user defines a converter for Boolean=>Enum for example, that
> > would not work on e.g. Oracle since on such a DB the column type is
> > integer?
> >
> >
> > I am not following what you mean.  Why would an enum be a boolean?  You
> > mean something like:
> >
> > enum Sex { MALE, FEMALE )
> >
> > and then storing into the DB as `IS_MALE`?
> >
> > I mean I guess someone *could* write an app that way.  I'd laugh at them,
> > but I guess they could ;)
> >
> > Anyway, they can already do that... it called an AttributeConverter :P
> >
> > More I am asking about the legacy BooleanType, YesNoType and
> > TrueFalseType.  These each used different JavaTypeDescriptor instances
> > encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..)
> > representations.
> >
> > So in stepping back and thinking about how this "should" be designed, I
> am
> > thinking that the most logical design is to have just a single
> > JavaTypeDesriptor for boolean and to somehow keep the specific DB storage
> > representations as part of the attribute[1].
> >
> > But then we start thinking how that should affect the wrap/unwrap
> > process.  Well, we already have a way for attribute-level "config" to
> alter
> > the wrap/unwrap process - again, AttributeConverter.  So at the minimum
> we
> > will handle this in the same manner as we hande AttributeConverter.  But
> > then we asked whether we might just *use* AttributeConverter for this;
> this
> > design works well, so long as these attributes do not also have an
> > AttributeConverter associated with them.
> >
> > I think I'd propose this...
> >
> > We'd essentially say that we do not natively understand how to store
> > booleans (just bear with me...).  Specifically how to convert them into a
> > DB storable format.  Which means we'd need something to help us perform
> > that conversion.  If the user has attached an AttributeConverter to the
> > attribute we'd simply use that.  If they have not, then we'd look to this
> > config option to see if they have specified how to do that globally.  If
> > they have not done that either, we'd simply as the Dialect.
> >
> >
> > [1] I'd never do this, but it is entirely possible that a user would want
> > a boolean value from one attribute stored in the DB as 0/1 and another
> > attribute store as Y/N.  So attribute is the highest granularity we need
> to
> > resolve this at.  But they might instead very well want to store all
> > boolean values in their app to the DB as a single representation - we'd
> > support that via config, as well as fallback to Dialect
> >
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] boolean type support

But see that's my point.  That's *not* what we have.  We have 3
JavaTypeDescriptors (instances) and 3 SqlTypeDescriptors (instances) to
handle this.  Sure we have 1 JavaTypeDescriptor *class*, but it takes 3
distinct configurations.  But the problem with this is...  when I see a
Boolean/boolean type in the domain model which JavaTypeDescriptor does that
resolve to?

Anyway, I will try it and see how it goes.

On Fri, Jan 27, 2017 at 12:42 PM Vlad Mihalcea 
wrote:

> If you think we can handle this better using Attributes, then we can give
> it a try.
>
> Nevertheless, the current implementation is nice as well. We have a single
> Java descriptor and multiple Sql descriptors to cover various DB column
> types or column values.
>
> Vlad
> On Fri, Jan 27, 2017 at 8:28 PM, Steve Ebersole 
> wrote:
>
> Correction : If they have not done that either, we'd simply *ask* the
> Dialect.
>
>
> On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole 
> wrote:
>
> > On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov <
> > christian.bei...@gmail.com> wrote:
> >
> > Am 27.01.2017 um 17:31 schrieb Steve Ebersole:
> > > Obviously that only works if there is not already an AttributeConverter
> > > applied to to the attribute.  I cannot imagine that ever happens in a
> > > supported way, or a way that we want to support.  Essentially that
> would
> > > mean a condition where we convert the value twice in each direction.
> But
> > > in case we miss some ase, I wanted to ask the list.
> > So if a user defines a converter for Boolean=>Enum for example, that
> > would not work on e.g. Oracle since on such a DB the column type is
> > integer?
> >
> >
> > I am not following what you mean.  Why would an enum be a boolean?  You
> > mean something like:
> >
> > enum Sex { MALE, FEMALE )
> >
> > and then storing into the DB as `IS_MALE`?
> >
> > I mean I guess someone *could* write an app that way.  I'd laugh at them,
> > but I guess they could ;)
> >
> > Anyway, they can already do that... it called an AttributeConverter :P
> >
> > More I am asking about the legacy BooleanType, YesNoType and
> > TrueFalseType.  These each used different JavaTypeDescriptor instances
> > encoding the specific true/false DB ('Y'/'N', 'T'/'F', 1/0, ..)
> > representations.
> >
> > So in stepping back and thinking about how this "should" be designed, I
> am
> > thinking that the most logical design is to have just a single
> > JavaTypeDesriptor for boolean and to somehow keep the specific DB storage
> > representations as part of the attribute[1].
> >
> > But then we start thinking how that should affect the wrap/unwrap
> > process.  Well, we already have a way for attribute-level "config" to
> alter
> > the wrap/unwrap process - again, AttributeConverter.  So at the minimum
> we
> > will handle this in the same manner as we hande AttributeConverter.  But
> > then we asked whether we might just *use* AttributeConverter for this;
> this
> > design works well, so long as these attributes do not also have an
> > AttributeConverter associated with them.
> >
> > I think I'd propose this...
> >
> > We'd essentially say that we do not natively understand how to store
> > booleans (just bear with me...).  Specifically how to convert them into a
> > DB storable format.  Which means we'd need something to help us perform
> > that conversion.  If the user has attached an AttributeConverter to the
> > attribute we'd simply use that.  If they have not, then we'd look to this
> > config option to see if they have specified how to do that globally.  If
> > they have not done that either, we'd simply as the Dialect.
> >
> >
> > [1] I'd never do this, but it is entirely possible that a user would want
> > a boolean value from one attribute stored in the DB as 0/1 and another
> > attribute store as Y/N.  So attribute is the highest granularity we need
> to
> > resolve this at.  But they might instead very well want to store all
> > boolean values in their app to the DB as a single representation - we'd
> > support that via config, as well as fallback to Dialect
> >
> >
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Query#iterate

2017-01-27 Thread Sanne Grinovero

+1 to remove

On 27 January 2017 at 18:34, Vlad Mihalcea  wrote:
> I'm for removing it even if it didn't complicate the query parser.
>
> Vlad
>
> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole  wrote:
>
>> Because the behavior is also fundamentally questionable.
>>
>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
>> christian.bei...@gmail.com> wrote:
>>
>> > I'm sorry, I apparently confused iterate() with scroll() then, so forget
>> > what I wrote before ^^
>> >
>> > In face of that new info, I actually don't know of any actual users.
>> After
>> > thinking a bit about it, why not make that behavior configurable via
>> > setProperty and drop that method?
>> >
>> >
>> > Am 27.01.2017 um 19:01 schrieb Steve Ebersole:
>> >
>> > On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov <
>> > christian.bei...@gmail.com> wrote:
>> >
>> > I just know of people that are using iterate() now for efficient
>> > incremental processing, but I guess any other approach(streams maybe?)
>> > to do incremental processing would be good enough for these users.
>> >
>> >
>> > ScrollableResults do not meet that need?
>> >
>> >
>> >
>> > Unfortunately I don't know what a shallow query is or what the
>> > implication on the query or the processing of being shallow are.
>> >
>> >
>> > Just what I said before.  "shallow" is simply a boolean flag that is part
>> > of the translator.  It is set to true when the translation is triggered
>> > from Query#iterate.  When the translation is triggered from Query#list or
>> > Query#scroll it is set to false.
>> >
>> >
>> >
>> > I guess this has to do with how row processing is done?
>> >
>> >
>> > The main thing is effects is the SQL we render.  For "entity returns" it
>> > simply selects the ids and we expect to then load them (immediately!) by
>> > that id (N+1).  Its usefulness is actually VERY limited in scope as it
>> > actually performs horrendously in, what, 95-99% of use cases?
>> >
>> > Interestingly it really does not have much effect on "row processing".
>> >
>> >
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Query#iterate

+1 for remove then too. We can still add it later via a configuration 
property if someone complains.

Am 27.01.2017 um 19:50 schrieb Sanne Grinovero:
> +1 to remove
>
> On 27 January 2017 at 18:34, Vlad Mihalcea  wrote:
>> I'm for removing it even if it didn't complicate the query parser.
>>
>> Vlad
>>
>> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole  wrote:
>>
>>> Because the behavior is also fundamentally questionable.
>>>
>>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
>>> christian.bei...@gmail.com> wrote:
>>>
 I'm sorry, I apparently confused iterate() with scroll() then, so forget
 what I wrote before ^^

 In face of that new info, I actually don't know of any actual users.
>>> After
 thinking a bit about it, why not make that behavior configurable via
 setProperty and drop that method?

 Am 27.01.2017 um 19:01 schrieb Steve Ebersole:

 On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov <
 christian.bei...@gmail.com> wrote:

 I just know of people that are using iterate() now for efficient
 incremental processing, but I guess any other approach(streams maybe?)
 to do incremental processing would be good enough for these users.

 ScrollableResults do not meet that need?

 Unfortunately I don't know what a shallow query is or what the
 implication on the query or the processing of being shallow are.

 Just what I said before.  "shallow" is simply a boolean flag that is part
 of the translator.  It is set to true when the translation is triggered
 from Query#iterate.  When the translation is triggered from Query#list or
 Query#scroll it is set to false.

 I guess this has to do with how row processing is done?

 The main thing is effects is the SQL we render.  For "entity returns" it
 simply selects the ids and we expect to then load them (immediately!) by
 that id (N+1).  Its usefulness is actually VERY limited in scope as it
 actually performs horrendously in, what, 95-99% of use cases?

 Interestingly it really does not have much effect on "row processing".

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

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

Re: [hibernate-dev] Query#iterate

They can always emulate it with a query that returns the ids and then just
call entityManager.find for each id so I don't think we'll ever need to add
it back.

Vlad

On Fri, Jan 27, 2017 at 9:16 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> +1 for remove then too. We can still add it later via a configuration
> property if someone complains.
>
> Am 27.01.2017 um 19:50 schrieb Sanne Grinovero:
> > +1 to remove
> >
> > On 27 January 2017 at 18:34, Vlad Mihalcea 
> wrote:
> >> I'm for removing it even if it didn't complicate the query parser.
> >>
> >> Vlad
> >>
> >> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole 
> wrote:
> >>
> >>> Because the behavior is also fundamentally questionable.
> >>>
> >>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
> >>> christian.bei...@gmail.com> wrote:
> >>>
>  I'm sorry, I apparently confused iterate() with scroll() then, so
> forget
>  what I wrote before ^^
> 
>  In face of that new info, I actually don't know of any actual users.
> >>> After
>  thinking a bit about it, why not make that behavior configurable via
>  setProperty and drop that method?
> 
> 
>  Am 27.01.2017 um 19:01 schrieb Steve Ebersole:
> 
>  On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov <
>  christian.bei...@gmail.com> wrote:
> 
>  I just know of people that are using iterate() now for efficient
>  incremental processing, but I guess any other approach(streams maybe?)
>  to do incremental processing would be good enough for these users.
> 
> 
>  ScrollableResults do not meet that need?
> 
> 
> 
>  Unfortunately I don't know what a shallow query is or what the
>  implication on the query or the processing of being shallow are.
> 
> 
>  Just what I said before.  "shallow" is simply a boolean flag that is
> part
>  of the translator.  It is set to true when the translation is
> triggered
>  from Query#iterate.  When the translation is triggered from
> Query#list or
>  Query#scroll it is set to false.
> 
> 
> 
>  I guess this has to do with how row processing is done?
> 
> 
>  The main thing is effects is the SQL we render.  For "entity returns"
> it
>  simply selects the ids and we expect to then load them (immediately!)
> by
>  that id (N+1).  Its usefulness is actually VERY limited in scope as it
>  actually performs horrendously in, what, 95-99% of use cases?
> 
>  Interestingly it really does not have much effect on "row processing".
> 
> 
> 
> >>> ___
> >>> hibernate-dev mailing list
> >>> hibernate-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Extended KEY expression support

I have a little proposal for supporting the use of a KEY expression in
the FROM clause and I'd like to hear your opinions on that.
Unfortunately the JPA spec does not support that, but since a key of a
java.util.Map mapping may be an entity type, we need to specify how one
can "join" that key explicitly.

Right now(pre HHH-10537), when joining a java.util.Map mapping, an inner
join is generated for the map key entity type. In my fix for HHH-10537 I
changed the behavior to respect/inherit the join type of the collection
join.
The problem is, that one can't further join any attributes on that key,
because there is no syntax in the HQL or the JPA spec that allows to do
that.

We need to decide (1) whether we always want to join the entity key or
require the user to do that specifically via e.g. something like "JOIN
alias.map m JOIN KEY(m) k"
and also (2) how the syntax for joining further attributes should look
like. If we decide to not allow the "JOIN KEY(m)" syntax for (1) we have
to support something like "JOIN KEY(m).association", otherwise we can
just use the alias like for normal joins "JOIN k.association".
Either way, we have to change the grammar but I'd rather like to
support/implement the map key joining syntax like "JOIN KEY(m) k" for
(1). A further change to that would be to not generate the implicit key
table join anymore but require the user to do the join explicitly. Since
that would break backwards compatibility, I'd like to make that behavior
configurable and of course, by default it will generate the implicit key
join to maintain backwards compatibility. I also propose to switch the
default in 6.0 so that the join is not generate anymore.
The usage in the JPA Criteria API will unfortunately require a cast
since the return type of javax.persistence.metamodel.MapAttribute#key()
is javax.persistence.metamodel.Path instead of
javax.persistence.metamodel.SingularAttribute but essentially the same
functionality is available to a user out of the box.
Specifying a custom join for a key would look like this in the Criteria API

MapAttribute mapAttribute = ...
Join keyEntity =
mapAttribute.join((SingularAttribute) mapAttribute.key(), JoinType.LEFT);
keyEntity.join(...)

So the questions again.
1. Do you all agree that this is important and should be done?
2. Agree to not generate implicit joins for keys in future versions?
3. Allow joining the key in a separate join?
4. Allow further joins on a key?
5. Happy with how it can be done in JPA Criteria?

In addition to that, it would be nice if anyone could make someone from
the JPA EG aware of this.
From a JPQL BNF point of view, I'd propose the following changes

from

join_single_valued_path_expression::=
identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field

|
map_field_identification_variable

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

Re: [hibernate-dev] Extended KEY expression support

Fwiw EclipseLink supports both syntaxes "JOIN KEY(m) k" and also "JOIN 
KEY(m).association".

Am 27.01.2017 um 20:25 schrieb Christian Beikov:
> I have a little proposal for supporting the use of a KEY expression in 
> the FROM clause and I'd like to hear your opinions on that.
> Unfortunately the JPA spec does not support that, but since a key of a 
> java.util.Map mapping may be an entity type, we need to specify how 
> one can "join" that key explicitly.
>
> Right now(pre HHH-10537), when joining a java.util.Map mapping, an 
> inner join is generated for the map key entity type. In my fix for 
> HHH-10537 I changed the behavior to respect/inherit the join type of 
> the collection join.
> The problem is, that one can't further join any attributes on that 
> key, because there is no syntax in the HQL or the JPA spec that allows 
> to do that.
>
> We need to decide (1) whether we always want to join the entity key or 
> require the user to do that specifically via e.g. something like "JOIN 
> alias.map m JOIN KEY(m) k"
> and also (2) how the syntax for joining further attributes should look 
> like. If we decide to not allow the "JOIN KEY(m)" syntax for (1) we 
> have to support something like "JOIN KEY(m).association", otherwise we 
> can just use the alias like for normal joins "JOIN k.association".
> Either way, we have to change the grammar but I'd rather like to 
> support/implement the map key joining syntax like "JOIN KEY(m) k" for 
> (1). A further change to that would be to not generate the implicit 
> key table join anymore but require the user to do the join explicitly. 
> Since that would break backwards compatibility, I'd like to make that 
> behavior configurable and of course, by default it will generate the 
> implicit key join to maintain backwards compatibility. I also propose 
> to switch the default in 6.0 so that the join is not generate anymore.
> The usage in the JPA Criteria API will unfortunately require a cast 
> since the return type of 
> javax.persistence.metamodel.MapAttribute#key() is 
> javax.persistence.metamodel.Path instead of 
> javax.persistence.metamodel.SingularAttribute but essentially the same 
> functionality is available to a user out of the box.
> Specifying a custom join for a key would look like this in the 
> Criteria API
>
> MapAttribute mapAttribute = ...
> Join keyEntity = 
> mapAttribute.join((SingularAttribute MapKeyEntity>) mapAttribute.key(), JoinType.LEFT);
> keyEntity.join(...)
>
> So the questions again.
>  1. Do you all agree that this is important and should be done?
>  2. Agree to not generate implicit joins for keys in future versions?
>  3. Allow joining the key in a separate join?
>  4. Allow further joins on a key?
>  5. Happy with how it can be done in JPA Criteria?
>
> In addition to that, it would be nice if anyone could make someone 
> from the JPA EG aware of this.
> From a JPQL BNF point of view, I'd propose the following changes
>
> from
>
> join_single_valued_path_expression::=
> identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field
>  
>
>
> to
>
> join_single_valued_path_expression::=
> identification_variable.{single_valued_embeddable_object_field.}*single_valued_object_field
>  
> |
> map_field_identification_variable
>
> Regards,
> Christian

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

Re: [hibernate-dev] Extended KEY expression support

My initial thoughts...

On Fri, Jan 27, 2017 at 1:29 PM Christian Beikov 
wrote:

> I have a little proposal for supporting the use of a KEY expression in
> the FROM clause and I'd like to hear your opinions on that.
> Unfortunately the JPA spec does not support that, but since a key of a
> java.util.Map mapping may be an entity type, we need to specify how one
> can "join" that key explicitly.
>

> Right now(pre HHH-10537), when joining a java.util.Map mapping, an inner
> join is generated for the map key entity type. In my fix for HHH-10537 I
> changed the behavior to respect/inherit the join type of the collection
> join.
> The problem is, that one can't further join any attributes on that key,
> because there is no syntax in the HQL or the JPA spec that allows to do
> that.
>
> We need to decide (1) whether we always want to join the entity key or
> require the user to do that specifically via e.g. something like "JOIN
> alias.map m JOIN KEY(m) k"
> and also (2) how the syntax for joining further attributes should look
> like. If we decide to not allow the "JOIN KEY(m)" syntax for (1) we have
> to support something like "JOIN KEY(m).association", otherwise we can
> just use the alias like for normal joins "JOIN k.association".
>

I definitely like the syntax to join the key if it happens to be an entity
(or an embedded!).  That makes the syntax for further referencing or
joining it's attributes very natural.

Either way, we have to change the grammar but I'd rather like to
> support/implement the map key joining syntax like "JOIN KEY(m) k" for
> (1).

By "change the grammar" I assume you mean the JPA query BNF?  Because the
SQM grammar already supports this.  Or perhaps you mean the pre-6.0
Hibernate grammar?  If so, see below.

A further change to that would be to not generate the implicit key
> table join anymore but require the user to do the join explicitly. Since
> that would break backwards compatibility, I'd like to make that behavior
> configurable and of course, by default it will generate the implicit key
> join to maintain backwards compatibility. I also propose to switch the
> default in 6.0 so that the join is not generate anymore.
>

I personally would vote to *not* make this change in 5.x even in terms of
making it configurable.  The grammar there is fugly enough already and this
is the kind of thing (especially making branches of it configurable) that
takes that fugliness to a new level.

But I think it is a useful change and would certainly consider it for 6.0

> The usage in the JPA Criteria API will unfortunately require a cast
> since the return type of javax.persistence.metamodel.MapAttribute#key()
> is javax.persistence.metamodel.Path instead of
> javax.persistence.metamodel.SingularAttribute but essentially the same
> functionality is available to a user out of the box.
>

Right.  In terms of SQM and 6.0 this perfectly illustrates the importance
of the Navigable/NavigableSource contracts and defining references and
joins based on them as opposed to strictly attribute-based.

I *hate* the idea of making the map key "pose" as a SingularAttribute just
for the sake of doing things we should be able to do with it.  We have to
cast anyway, so I'd much prefer to cast to Hibernate-specific (this is
Hibernate specific anyway) contracts that expose this more properly
probably based on Navigable/NavigableSource above.

In those terms, a map key is always a Navigable.  If the key happens to be
an entity (or an embedded!) then the key is also a NavigableSource and can
therefore be further dereferenced.  I'd rather base such an extension on
this concept rather than making map key be something it is not just to make
it work.  We can make it work and model it correctly!

Specifying a custom join for a key would look like this in the Criteria API
>
> MapAttribute mapAttribute = ...
> Join keyEntity =
> mapAttribute.join((SingularAttribute MapKeyEntity>) mapAttribute.key(), JoinType.LEFT);
> keyEntity.join(...)
>
> So the questions again.
>   1. Do you all agree that this is important and should be done?

  2. Agree to not generate implicit joins for keys in future versions?

  3. Allow joining the key in a separate join?
>

I am missing how 1, 2 and 3 are any different.  Anyway...

I think it is useful.  I think we should plan to do it... for 6.0

>   4. Allow further joins on a key?
>

And this is a natural consequence of 1, 2 and 3 ;)

>   5. Happy with how it can be done in JPA Criteria?
>

Meh.  JPA is a spec.  We can make proposals, but we are not the only ones
on the EG.  What is more important to me is that we make it possible from
*our* implementation of the spec.

Especially moving forward considering we dropped the legacy criteria API
and plan to develop criteria extensions on top of the JPA criteria API.  It
is overall better designed - we just need to add in our extras that JPA
does not support.  What that looks like exactly (to get around JPA not
defining it) is not very as rel

Re: [hibernate-dev] Extended KEY expression support