[hibernate-dev] Test 2

[Steve Ebersole]

___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: 
https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/message/BNBMCZDTE43BLT3QJ3P7WZQB25AKV4S4/

[hibernate-dev] Hibernate ORM 6.2.0 Final Release

[Steve Ebersole]

Hibernate ORM 6.2.0 Final has just been released.  See
https://in.relation.to/2023/03/30/orm-62-final/ for the details.
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 6.2.0.CR4 release

[Steve Ebersole]

Hibernate ORM 6.2.0.CR4 has been released.  See the announcement
 for the details.
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 6.2 CR3 release

[Steve Ebersole]

See the release announcement 
for the details.
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate 6.2 CR2 release

[Steve Ebersole]

This release has tons of bug fixes, stabilized code and support for SQL
`MERGE`!

Check it out - https://in.relation.to/2023/01/27/orm-62-cr2/
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

[Steve Ebersole]

Let me know what y'all think -
https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team

On Thu, Jun 2, 2022 at 7:37 AM Steve Ebersole  wrote:

> I think we generally agree and understand each other here.
>
>
> On Thu, Jun 2, 2022 at 6:32 AM Imre Jonk via hibernate-dev <
> hibernate-dev@lists.jboss.org> wrote:
>
>>
>> This sounds a lot like how we do our version numbering as well. We try
>> to be as backward-compatible as possible with new "y" (minor) and
>> particularly the "z" (patch) releases, and try to put all the breaking
>> changes in the "x" (major) releases. But in the end, given a large
>> enough userbase, every (documented or undocumented) behavior of an API
>> is being relied upon by someone, meaning that every change will break
>> someone's workflow: https://xkcd.com/1172/
>
>
> Extrapolating what you say, we could never fix bugs because that buggy
> behavior is "being relied upon by someone".  I simply reject that.  Fairly
> sure that is not what you are saying, but this has been my point throughout
> this conversation - words are important.  Especially when you start talking
> about expectations across a large number of people.
>
>
> Depends on your definition of a "major version" ;)
>>
>
> Yep, we are back to words being important :D
>
> I've already documented here what we consider a major version and its
> implications; so you know my definition.
>
>
>
>> I meant that the Hibernate developers once in a while have to say to
>> each other "Let's stop backporting fixes for release series x.y. People
>> have had enough time to upgrade, now let's spend the time we save on
>> things in our roadmap".
>>
>
> Sure, but that's the thing.  That is reactive, not proactive.  Consider
> the current 5.x -> 6.x situation again... What most people who ask this
> stuff really want is, as soon as 6.0 is released, some date when 5.x will
> become unsupported.  But that is not something we are ever going to do - it
> is impossible.
>
>
> I now see the end-of-life warnings on the 5.0, 5.1, 5.2, 5.4 and 5.5
>> release pages! Did you just add those? They are great! I think this
>> gives a very clear signal to anyone still using those versions that
>> they are now quite overdue on their updates.
>>
>
> We discussed it and Yoann added that stuff.  Thanks Yoann!
>
>
> This has some overlap with human psychology. Someone should probably do
>> a study on this. They could start with looking at what happened when
>> Python 2's end-of-life date was finally announced... (you are probably
>> well aware, but if not: everyone was dragging their feet until the
>> announcement, which caused an enormous acceleration in the Python 3
>> transition).
>>
>
> Not a Python developer[1], so not really familiar with that specifically;
> but it is a common enough situation in software development.  It  also
> probably meant that Python 3 was not as thoroughly tested as it could have
> been prior to that accelerated migration.
>
> We are lucky in that we have a wonderful community, many of whom are very
> helpful in the early shake out of these new releases.  E.g., we had a lot
> of testing and feedback of 6.0 well before it went Final.
>
>
> > As you plan moving to 6.0, definitely check out the Jakarta
>> > Transformer to help automate some of the tedious Java Persistence to
>> > Jakarta Persistence move.
>>
>> Thanks! I'm passing this on to our developers.
>
>
> They can also use the transformer config files Christian wrote for our own
> migration efforts[2].
>
> [1] I had to develop in Jython for almost a year once and REFUSE to ever
> do anything Python related ever again ;)
> [2]
> https://github.com/hibernate/hibernate-orm/tree/ff9e9eebc9992c7bc9128e9bf33d4b51b2bee7a4/rules
>
>
>
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

[Steve Ebersole]

I think we generally agree and understand each other here.


On Thu, Jun 2, 2022 at 6:32 AM Imre Jonk via hibernate-dev <
hibernate-dev@lists.jboss.org> wrote:

>
> This sounds a lot like how we do our version numbering as well. We try
> to be as backward-compatible as possible with new "y" (minor) and
> particularly the "z" (patch) releases, and try to put all the breaking
> changes in the "x" (major) releases. But in the end, given a large
> enough userbase, every (documented or undocumented) behavior of an API
> is being relied upon by someone, meaning that every change will break
> someone's workflow: https://xkcd.com/1172/


Extrapolating what you say, we could never fix bugs because that buggy
behavior is "being relied upon by someone".  I simply reject that.  Fairly
sure that is not what you are saying, but this has been my point throughout
this conversation - words are important.  Especially when you start talking
about expectations across a large number of people.


Depends on your definition of a "major version" ;)
>

Yep, we are back to words being important :D

I've already documented here what we consider a major version and its
implications; so you know my definition.



> I meant that the Hibernate developers once in a while have to say to
> each other "Let's stop backporting fixes for release series x.y. People
> have had enough time to upgrade, now let's spend the time we save on
> things in our roadmap".
>

Sure, but that's the thing.  That is reactive, not proactive.  Consider the
current 5.x -> 6.x situation again... What most people who ask this stuff
really want is, as soon as 6.0 is released, some date when 5.x will become
unsupported.  But that is not something we are ever going to do - it is
impossible.


I now see the end-of-life warnings on the 5.0, 5.1, 5.2, 5.4 and 5.5
> release pages! Did you just add those? They are great! I think this
> gives a very clear signal to anyone still using those versions that
> they are now quite overdue on their updates.
>

We discussed it and Yoann added that stuff.  Thanks Yoann!


This has some overlap with human psychology. Someone should probably do
> a study on this. They could start with looking at what happened when
> Python 2's end-of-life date was finally announced... (you are probably
> well aware, but if not: everyone was dragging their feet until the
> announcement, which caused an enormous acceleration in the Python 3
> transition).
>

Not a Python developer[1], so not really familiar with that specifically;
but it is a common enough situation in software development.  It  also
probably meant that Python 3 was not as thoroughly tested as it could have
been prior to that accelerated migration.

We are lucky in that we have a wonderful community, many of whom are very
helpful in the early shake out of these new releases.  E.g., we had a lot
of testing and feedback of 6.0 well before it went Final.


> As you plan moving to 6.0, definitely check out the Jakarta
> > Transformer to help automate some of the tedious Java Persistence to
> > Jakarta Persistence move.
>
> Thanks! I'm passing this on to our developers.


They can also use the transformer config files Christian wrote for our own
migration efforts[2].

[1] I had to develop in Jython for almost a year once and REFUSE to ever do
anything Python related ever again ;)
[2]
https://github.com/hibernate/hibernate-orm/tree/ff9e9eebc9992c7bc9128e9bf33d4b51b2bee7a4/rules
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

[Steve Ebersole]

Happened to be doing my morning email purge and this luckily came in at
just that time :D


On Wed, Jun 1, 2022 at 7:32 AM Imre Jonk via hibernate-dev <
hibernate-dev@lists.jboss.org> wrote:

> Hi Steve,
> You can find our
> support policy here if you are interested:
> https://www.ciphermail.com/documentation/faq/support-policy.html


That seems very similar to the one I wrote for Hibernate.  I do see now
that ours is probably a bit unclear, specifically in terms of how we view
the different version components.  I'll update that.

The synopsis - consider the version x.y.z -


   1. `x` is a major version which identifies a "significant" change.  The
   implications range from changes to external contracts to removal of
   deprecated stuff to new features.  Often they will have limited backwards
   compatibility.
   2. `y` indicates new feature(s), which are not "disruptive" to
   applications.  All `y` for a given `x` are collectively called a family.
   Within a family there will be compatibility  - always at the API level.
   And we strive to maintain compatibility at the SPI (integration) level,
   though we do sometimes change these when absolutely necessary.
   3. `z` includes just bug-fixes

Things we identify as incubating, internal, etc also affect this.  And in
fact, with 6.0 I started to formalize this - see
https://docs.jboss.org/hibernate/orm/6.0/incubating/incubating.txt and
https://docs.jboss.org/hibernate/orm/6.0/internals/internal.txt

But that still does not help with time frames per-se...

Thing is, somewhere in every release cycle, the Hibernate developers
> have to make a decision when they stop providing backported fixes.
> Right now that decision is made on an ad-hoc basis (if I'm not
> mistaken).


Some well chosen words here ;)

* "~somewhere~ in every release cycle" - Well, not every release cycle.  As
we transition to major versions that is true(ish).  I think that is what
you probably meant, but just to be clear.
* "ad-hoc basis" - That is not the phrase I would choose necessarily, but
not far off.  It is more that we do not know until we know.  Take 5.6 and
6.0... the elephant in the room there is the move from Java Persistence to
Jakarta Persistence, which is way out of our control.  But it has a major
impact on applications.. Not all "EE" spec impls, let alone libraries, have
made that transition yet which puts applications in a bind.  Because of
that it is impossible to give a date when 5.x will no longer be supported.

As you plan moving to 6.0, definitely check out the Jakarta Transformer to
help automate some of the tedious Java Persistence to Jakarta Persistence
move.
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

[Steve Ebersole]

On Tue, May 31, 2022 at 11:18 AM Imre Jonk via hibernate-dev <
hibernate-dev@lists.jboss.org> wrote:

>
> I think the reality is that people who use software that has been
> declared end-of-life by their suppliers often don't backport it
> themselves. I've unfortunately seen enough cases of this happening...


Before I was lucky enough to get paid for working on Hibernate, I worked on
it in my free time.  But we used it at the company I worked for at the
time.  I often ended up using custom builds, though generally that was more
"forward facing" as I generally wanted features or fixes I was working on
that were maybe not ready for a community release.

I also have done it with projects that I was not part of the development
of.  In fact, I still do as I had to do some of this with the move to
Jakarta EE and the fact that not all of the libraries we use were updated
for Jakarta at the time.

So I have done it.  As do many others.  Not arguing, it's just an
interesting topic.  Many developers I think also shy away from this with
Hibernate specifically because of FUD over the LGPL.


(If it isn't clear by now, I am a big proponent of updating software in
> a timely manner instead of feet-dragging until you drown in "upgrade
> debt".)
>

Awesome!  I like the phrase too!


I put the X there deliberately. It is not at all my place to make
> decisions on this; how long users of older versions should receive
> bugfixes, and indeed if they should receive updates at all, is
> something that only the Hibernate developers can decide on.
>

But that's the problem.  There is not a hard and fast rule.  There is no
single 'X'.  Only a Sith thinks in absolutes ;)  I joke (my daughter and I
were watching some Star Wars last night, so just fresh in my mind).


The uncertainty comes from not knowing whether the Hibernate release
> someone is using will receive backported fixes or not. I did not mean
> to extrapolate that to all users. Maybe I should have put "uncertainty
> among some Hibernate users" there as I do not in fact know whether many
> users experience this uncertainty. However, I am not the first one to
> voice this uncertainty, so it is not just *my* uncertainty either:
>

Maybe a better solution would be to somehow earmark this on the release
pages.  E.g. https://hibernate.org/orm/releases/5.4/.  Maybe a new "status"
in addition to "development" and "stable".  I am not the website guru
though so that is something the team would need to discuss.

It does not alleviate the "when" aspect, but honestly I do not foresee that
happening.  Too many variables and we are generally too busy doing actual
development.

Open to suggestions though.


I just noticed the backporting information linked to in that second
> forum thread, here:
> https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team


Ah, thanks!  I thought I had written that down, but could not find it :D

We have a slightly different definition of version naming though it follows
the semantics of semantic versioning.  6.1 has new features, so strictly
following semantic versioning it should be named 7.0.  So sure, we could
rename 6.1 to 7.0 and have these "nonsense major versions", but really what
does that gain anyone?

Anyway, that's all to say I still cannot give you a date.  I can say
probably not before the end of summer.  5.6 is interesting because there is
one consumer (Quarkus) currently using it that we want to support.  But
they have not yet made the move to Jakarta so cannot use 6.x yet.  For what
it is worth...
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

[Steve Ebersole]

The reality is that we are a very small team - it is simply not feasible to
maintain that many branches[1].

You are not asking about "time to upgrade" anyway, in my opinion.  You are
asking about removing the need to upgrade, which is very different.  Us
stopping support for 5.6 does not mean you can no longer use 5.6.  It
simply means we (this very tiny team) will no longer back-port changes.
You can continue to use it; and in fact, since it is open source, you can
even continue to do these back-ports yourself.

As for a statement on the website, I'm not sure exactly what that would
look like.  Your suggestion is just vague.  "X months"?  How many months is
that?  2?  24?  Big difference.  E.g., you realize 6.0 was released exactly
2 months ago to the day right[2][3]?  That is "months" already.  And I have
already said we will continue to support 5.6 for the time being, so that
will be "months"++.  The rest of your statement is in fact exactly what we
do already[4].  I'm not against adding something to the website if it helps
clarify things, but that wording is not it.

P.S. To be fair, by "reduce doubt among Hibernate users" you mean *your*
"doubt".  Which is fine, but let's not extrapolate that to all Hibernate
users.


[1] Though really, point me to any project / product the size and
complexity of Hibernate, not to mention user base, that supports as many
code bases for free that you are asking.
[2] https://in.relation.to/2022/03/31/orm-60-final/
[3] That was 6.0.0.Final.  Including CR releases (which I do) its been
many, many months.
[4] 6.0 has been out for months. 6.1 is about to be released.  And we are
still supporting 5.6.
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

[Steve Ebersole]

There is not a hard date.  Not in the immediate future is the best I can
say at the moment.



On Mon, May 30, 2022 at 3:54 AM Imre Jonk via hibernate-dev <
hibernate-dev@lists.jboss.org> wrote:

> Hi there,
>
> We're very excited about the Hibernate ORM 6.0 release! Our developers
> have looked at upgrading our copy from 5.6 to 6.0, but they consider
> 6.0 "not yet stable enough" (no idea if that's justified) and have had
> some issues with the upgrade guide. They estimate the upgrade to take
> about ten man-days. That's all the feedback I have right now,
> unfortunately.
>
> We want to schedule our upgrade to Hibernate 6 ideally before the
> Hibernate developers stop backporting bug fixes to the 5.x branches.
> Could you make a rough prediction when that would be, so that we and
> others looking at Hibernate 6 can schedule their upgrade?
>
> Thanks a lot,
>
> --
> Imre Jonk
> IT Automation Engineer
> CipherMail B.V.
>
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Hibernate ORM 6.0 Final

[Steve Ebersole]

On Fri, Apr 1, 2022 at 3:34 AM Yoann Rodiere  wrote:

> Congratulations to you all! That's a huge milestone, after literal years
> of work.
>
> Also, thanks for asking for opinions and helping with upgrades in Search
> along the way, it really made keeping up with the Alphas/Betas/CRs easier.
>

You're welcome.  And thanks to you as well.  You setting up Search testing
on 6.0 as early as you did really helped shake out a lot of the rough edges
and remaining bugs.


Now onwards to 6.0.1 :D
>

This one is perfect, no need for 6.0.1 - straight on to 6.1! :D
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 6.0 Final

[Steve Ebersole]

Hibernate ORM 6.0 Final has been released -
https://in.relation.to/2022/03/31/orm-60-final/
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] SourceForge bundles

[Steve Ebersole]

Per https://hibernate.atlassian.net/browse/HHH-14992 and
https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/SourceForge.20bundles/near/265421351
I propose that we stop creating ZIP and TGZ bundles for upload to
SourceForge.

Creating those files and uploading them routinely takes over an hour or
more.  That's a lot of time during the release process; and for no real
gain.  The more time the process takes, the more possibility for something
to go wrong which is incredibly hard to recover from depending just how far
the process got.

So I propose we just eliminate this.  Please direct responses to the Jira
or Zulip discussion.

Thanks!
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: Design of threadsafe, immutable internal components

[Steve Ebersole]

Overall I generally agree and as far as I have ever heard using the
concurrent form of hash-map rather than the non-concurrent one is a minimal
overhead if at all, so why not.

The way most of these Maps are used are already concurrency safe.  So as
long as we mean to simply keep this in mind when creating new code and
changing up the existing code then +1

On Thu, Oct 29, 2020 at 10:57 AM Sanne Grinovero 
wrote:

> Hi all,
>
> I'm inspecting some old code, and regularly finding a pattern which
> isn't entirely correct; it's not a big deal as it seems to not cause
> any problems so far in practice (expect the one I'm working on!), but
> I'll share this in hope we can slowly improve such things while
> evolving the codebase.
>
> When making an immutable, internal component we'll often have many
> fields with a "final" qualifier. This is good and we should definitely
> keep doing it.
>
> But also, one needs to ensure that once the constructor of an object
> has completed, such objects referenced in the final field should no
> longer be mutated (unless of course they are mutated in a thread safe
> way as well).
>
> To get more concrete, the following pattern is frequent in our code,
> but should not be used:
>
> class A {
>
>private final HashMap state = new HashMap();
>
> A() { //constructor
> }
>
> public initState( p ) {
>state.put (p, v);
> }
> }
>
> There's many reasons for this; at this stage my concern is mostly that
> the actual state which we're writing in the _state_ field doesn't
> benefit from the effect of the final field on visibility, as by
> specification the "freeze" of state is applied when the constructor
> has concluded.
> an additional problem is that such protected methods get to work on a
> partially constructed object as the constructor hasn't finished being
> invoked yet; this leads to additional subtle errors when the method is
> overridden by subclasses or relying on state from superclasses.
>
> A better version could be:
>
> class A {
>
>private final Map state;
>
> A(params) { //constructor
>this.state = initState( params );
> }
>
> static Map initState( params ) {
>   HashMap state = new HashMap();
>for ( some_loop on params ) {
>state.put (p, v);
>}
>return state;
>   }
>
> }
>
> If this doesn't work in your case as you need to "collect" some data
> by passing A to various other services, like we frequently need, this
> would suggest that you need an intermediary object, such as a builder
> pattern: collect all things you need, then build the immutable final
> representation of the state you need and make sure the builder is
> discarded.
>
> Alternatively, that "state" Map could use a ConcurrentHashMap if your
> service actually needs runtime state mutation by design.
>
> Please take this in consideration, as it will allow us to write better
> maintainable code, unlocks some possible optimisations which are
> otherwise hard to implement, and above all is actually correct in
> regards to the Java memory model.
>
> In the above example, it's interesting to highlight that the current
> code is working fine as we eventually publish references to A over a
> barrier, which will publish the state of the post-initialized A.state
> , so there's no rush in fixing such things BUT when I need to make
> changes to such patterns it's challenging to trace the barriers to
> make sure I'm not inadvertently introducing an obscure issue. Would be
> best to not rely on such root barriers.
>
> For those who want to know more, a good reference is Chapter 17.5 of
> the Java Language Specification.
>
> Thanks!
> Sanne
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: HCANN evolution

[Steve Ebersole]

On Thu, Oct 22, 2020 at 9:00 AM Sanne Grinovero  wrote:

> On Thu, 22 Oct 2020 at 14:50, Steve Ebersole  wrote:
>
> N.B. I'm considering these steps as a preparation step, I didn't yet
> address the core of the memory retention issue - I'll get to that
> next, having simplified the problem first.
>

Awesome, thanks!

It is possible that dom4j itself might be causing some of the perf problems
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: HCANN evolution

[Steve Ebersole]

Sounds good, I'll take a look.

Longer term, the best option from the perspective of ORM is to simply drop
HCANN altogether in favor of Jandex + JAXB.  In fact, I am considering
playing with that on top of your work.  It would be awesome to start
dropping the things that hold us to including dom4j

On Thu, Oct 22, 2020 at 8:02 AM Yoann Rodiere  wrote:

> Hi,
>
> Looks good to me, but please ping me when you submit the PR. HCANN is used
> in Hibernate Search as well, and not just the ORM module.
> If we ever need to have two ORM modules in Hibernate Search (one for ORM 5
> and one for ORM 6), I'll need to be sure that Hibernate Search can switch
> from HCANN 5 to 6 without recompiling...
>
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Thu, 22 Oct 2020 at 14:51, Sanne Grinovero  wrote:
>
> > Hi all,
> >
> > While investigating a case of too much memory being held after boot, I
> > noticed Hibernate Commons Annotations's old design and patterns are a
> > strong contributor to the problem.
> >
> > We talked many times about getting rid of it, yet we know it's not
> > easy as we have a high level of coupling - but I believe we can
> > achieve it in iterative steps, reducing the coupling.
> >
> > I now have a draft of patches which remove its capability to load
> > classes and packages "by name";  this implies it removing any
> > interaction with classloaders, and associated complexity; this will of
> > course require some adaptation in ORM but it turns out its own code is
> > also cleaner as a result (ORM's ClassLoaderService is preferred), so
> > I'd like to proceed.
> >
> > Unless there are strong objections, I'll mark all those classes which
> > I mean to delete as deprecated in HCANN 5.x, and remove them in HCANN
> > master (6).
> > Then I'll release the next 5.x and propose the adaptation PR to ORM;
> > since I'm not actually removing the functionality yet we still have
> > the option to keep the ORM patches limited to a smaller scope, should
> > there be any concerns regarding specific details (to be discussed in
> > PRs), but I don't believe this should be necessary.
> >
> > I'd also like to release an HCANN 6 preview and have ORM6 use it.
> >
> > Among other benefits, this will leave the HCANN codebase significantly
> > smaller and more focused on its core goals; I believe after this
> > cleanup it looks much better and we might not need to fully get rid of
> > it, for example it does solve the generics problem quite elegantly, so
> > there's no need to throw that out too.
> >
> > Thanks,
> > Sann
> > ___
> > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> > To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
> ___
> hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] CI environment(s)

[Steve Ebersole]

There is a discussion on
https://github.com/hibernate/hibernate-orm/pull/3391 related to the use of
Travis versus Jenkins for CI tests.

If anyone has strong opinions please comment on the PR.

Thanks!
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [hibernate-dev] Dropping support for Java 8 in Hibernate ORM (Search) v6 ?

[Steve Ebersole]

I also think ORM 6 is not the time to do this.  Especially moving to Java
11.

I think it is worthwhile though to discuss possibly moving to Java 9 to
take advantage of multi-release jars as Christian mentioned.  But Java 9
has its own set of difficulties for adoption with modules.  It is a
tough call.


On Fri, Jul 24, 2020 at 10:09 AM Yoann Rodiere  wrote:

> Hi,
>
> I share Christian's concerns; Hibernate Search 6 is already a huge change
> for users, so I'm not sure reducing our potential user base even further by
> requiring JDK11 is a good idea.
>
> I don't have numbers, but from my understanding a lot of people are still
> on JDK8, be it only because of the whole modulepath mess that scared a lot
> of people off (even though modules are optional...). If someone can prove
> me wrong and show me reliable statistics about JDK8 users being a minority,
> I'd be glad to put JDK8 behind me, but I doubt that's the case...
>
> "Middleware" consumers of our libraries are another problem:
>
> * Infinispan 12, from what I can see, still supports JDK 8.
> * I believe Spring does, too.
> * Quarkus, well... I suppose you know about Quarkus better than me.
> * ...
>
> Regarding benefits:
>
> The only benefit I could see from moving to JDK11 is the availability of
> the Flow interfaces, which would certainly be useful to introduce proper
> Publisher/Subscriber support in Search queries. But then that's not
> something we'll have time to work on anytime soon.
>
> I may be mistaken, but I'm not sure Jigsaw is gaining enough traction to
> justify investing more than just defining automatic modules for the time
> being.
>
> As to multi-tenancy in JDBC... Let's finish ORM6 first? :) Nothing stops us
> from only publishing a 6.1, and then moving immediately to 7, if we really
> end up addressing all the higher-priority items faster than expected and we
> need JDK11 features soon.
>
> Bottom line: maybe we could just deprecate JDK8? Log a warning on startup?
> And yes, ORM7/Search7 may be a better time to move to JDK11.
>
> On a side note, I'm not as enthusiastic as Christian about Moditect; last
> time we tried to use it on Search, it required us to build with JDK11, so
> we couldn't use it, since we were building releases with JDK8. Though
> nowadays we build releases with JDK11 (and -release 8), so it may be an
> option.
>
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Fri, 24 Jul 2020 at 16:23, Christian Beikov  >
> wrote:
>
> > Hey,
> >
> > I'm not sure it is a good idea to do this for Hibernate ORM 6 already as
> > that would probably hinder adoption. Some projects just didn't update to
> > Java 9+ yet because using the newer versions would have no real benefit.
> >
> > We can use the Multi-Release JAR feature to make use of JDK features
> > introduced in newer Java versions. Since the Java 11 doesn't provide any
> > significant languages changes for which it would be worth dropping
> > support for Java 8, I see no reason for raising the minimum version
> > requirement.
> >
> > We can benefit from Jigsaw already by defining module-info file and let
> > the moditect plugin(from Gunnar) compile it. If necessary, we can make
> > use of the Multi-Release JAR feature to use the module system APIs.
> >
> > How about raising the minimum Java version for Hibernate ORM 7 instead?
> >
> > Regards,
> >
> > Christian
> >
> > Am 24.07.2020 um 16:00 schrieb Sanne Grinovero:
> > > Hi all,
> > >
> > > [meta: I had this email as a draft on hold since a year; very glad to
> > > finally be able to send it.]
> > >
> > > We're usually quite conservative in dropping support for older JDKs
> > > within the Hibernate team, but there's an increasing maintenance (and
> > > development) cost when keeping older JDK compatibility for too long.
> > >
> > > In particular, Java 8 compatibility was so far still a requirement for
> > > various strategic integrations; first, we had runtimes targeting
> > > GraalVM still needing it, but they support Java 11 now as well; after
> > > that, Azure Functions were also still requiring Java 8, but this
> > > limitation was resolved now.
> > >
> > > We're aware that Java 8 is still widely used; still I think we need to
> > > look forward - for various reasons, including maintenance burden, and
> > > to deliver a better experience on the later versions of the JDK. Also,
> > > looking at the existing usage statistics implies a fallacy: that's
> > > current production usage, while the code we normally work is
> > > (typically) not going to see production usage for quite some time.
> > >
> > > While we'll want to keep Java 8 compatibility for existing
> > > [maintained] releases, there is no compelling reason anymore to keep
> > > doing this for the upcoming major releases.
> > >
> > > So I'd propose we require Java 11 the minimum compatible runtime for
> > > ORM v6 onward, and I'd suggest we do the same with all our actively
> > > developed projects.
> > >
> > > Initially, I don't really 

Re: [hibernate-dev] [ORM] Query with condition on subclass attribute

[Steve Ebersole]

It is not portable.  Hibernate applies an implicit treat-as operation in
such cases.  This is actually Hibernate's behavior from the beginning.  JPA
says this should use an explicit treat-as operation.

On Wed, Jul 1, 2020, 4:58 PM Gail Badner  wrote:

> Hi,
>
> Given the following inheritance hierarchy:
>
> @Entity
> public class Person {
> @Id
> private int id;
> ...
> }
>
> @Entity
> public class Employee extends Person {
> private String title;
> }
>
> Executing a query like the following succeeds.
>
> "from Person where title = 'abc'"
>
> I thought that it would fail because Person does not have an attribute
> named "title". Instead, the query succeeds and returns the Employee with
> the specified title.
>
> I don't see anything in the JPA spec that indicates whether this is
> portable.
>
> Does anyone know if this is portable?
>
> Thanks,
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] v6 and load-event

[Steve Ebersole]

Load event handling does not have "anything" parameters.  Am I
understanding you correctly?

On Fri, Jun 5, 2020, 11:42 AM Gail Badner  wrote:

> Hi Steve,
>
> Sorry, I have not read the entire thread carefully, so please disregard if
> not relevant.
>
> Would this provide functionality like what we discussed for an
> OperationContext?
>
> https://hibernate.atlassian.net/browse/HHH-10478
>
> Thanks,
> Gail
>
> On Fri, May 29, 2020 at 4:21 AM Steve Ebersole 
> wrote:
>
>> If/when it comes to needing that, I kind of like that continuation design.
>> But I agree, Yoann is right - let's leave it off until needed or until we
>> have specific requirements.
>>
>> Thanks everyone!
>>
>> On Fri, May 29, 2020 at 2:19 AM Sanne Grinovero 
>> wrote:
>>
>> > On Fri, 29 May 2020 at 07:22, Yoann Rodiere 
>> wrote:
>> > >
>> > > +1 not to add surround capability initially. Sounds better to start
>> > simple and make things more complex when we actually need it :)
>> >
>> > Right. I didn't mean to raise additional requirements without having
>> > investigated those tracing libraries - what I meant really is just to
>> > raise awareness that we'll likely need to evolve it further when it
>> > comes to finally implement such things.
>> >
>> > >
>> > > Yoann Rodière
>> > > Hibernate Team
>> > > yo...@hibernate.org
>> > >
>> > >
>> > > On Fri, 29 May 2020 at 07:25, Sanne Grinovero 
>> > wrote:
>> > >>
>> > >> Yes, I agree.
>> > >>
>> > >> On Thu, 28 May 2020, 22:11 Steve Ebersole, 
>> wrote:
>> > >>>
>> > >>> Wanted to clarify -
>> > >>>
>> > >>> Regarding incremental addition of "surround listeners", so long as
>> we
>> > are all in agreement that this simply means there will be absolutely no
>> > surround capability ***initially*** then I am fine with that.
>> > >>>
>> > >>> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole > >
>> > wrote:
>> > >>>>
>> > >>>> Hm, the dynamic enable/disable stuff should be easy to handle, no?
>> > Depends on what specific library you are thinking of and exactly how
>> that
>> > detail gets propagated to us.  At the end of the day, its really as
>> simple
>> > as protecting the creation of some of these objects with `if
>> > (enabled)`-type checks.
>> > >>>>
>> > >>>> But again, if you have specific details in mind we can take a look.
>> > >>>>
>> > >>>> Also, I think it is not at all a good idea to even plan for
>> > "different types of events".  In fact I'm fine with getting rid of
>> > LoadEvent completely from that contract and simply directly passing the
>> > information that is likely useful.  I mean at the end of the day a
>> listener
>> > for load events is going to be interested in the same set of
>> information.
>> > Yes, some will not need all of that information but that's not really a
>> > concern IMO.  Especially if we inline the parameters and completely
>> avoid
>> > the event object instantiation
>> > >>>>
>> > >>>> Regarding incremental addition of "surround listeners", so long as
>> we
>> > are all in agreement that this simply means there will be absolutely no
>> > surround capability then I am fine with that.
>> > >>>>
>> > >>>>
>> > >>>> On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero <
>> sa...@hibernate.org>
>> > wrote:
>> > >>>>>
>> > >>>>> On Thu, 28 May 2020 at 21:27, Steve Ebersole > >
>> > wrote:
>> > >>>>> >
>> > >>>>> > Any thoughts on this "continuation" approach?
>> > >>>>>
>> > >>>>> I love the pattern! Maybe we'll need also some ability to not
>> capture
>> > >>>>> the state for events which don't have any?
>> > >>>>>
>> > >>>>> I wonder if that implies we'll need two different event contracts:
>> > one
>> > >>>>> for the listeners which need state and one for those which don't;
>> but
>> > >>>>> I'm n

Re: [hibernate-dev] My email

[Steve Ebersole]

I started a discussion on the PR.

Thanks Catalin

On Wed, Jun 3, 2020 at 8:29 AM Catalin Tudose 
wrote:

> Done. Please let me know if it is fine and if I should do anything else at
> this point.
> Thank you!
>
> On Wed, Jun 3, 2020 at 4:13 PM Steve Ebersole  wrote:
>
>> If you have a test, consider creating a PR against the 6.0 branch.
>> That's the easiest way for us to look at it
>>
>> On Wed, Jun 3, 2020 at 7:34 AM Catalin Tudose 
>> wrote:
>>
>>> Hello!
>>>
>>> Thank you for the answers.
>>> I have a test case with CriteriaBuilder that is working fine with the
>>> 5.4.17.Final version, but it is throwing an exception with the 6.0.0.Alpha5
>>> version. I simply replaced the dependencies in the Maven pom.xml file.
>>> I am getting:
>>> java.lang.IllegalStateException: Could not resolve table reference
>>> `T_DEPARTMENT` relative to TableGroup `null` related with NavigablePath
>>> `NavigablePath[edu.jpa.entity.Employee.department.{id}]`
>>> I initially took a look at the JIRA open issues looking for the keywords
>>> "relative to TableGroup" and "related with NavigablePath", but could not
>>> find anything.
>>> I can provide the source code for both examples (should I attach it to
>>> an e-mail on the list?) and I hope it will worth your attention.
>>>
>>> On Wed, Jun 3, 2020 at 3:16 PM Steve Ebersole 
>>> wrote:
>>>
>>>> Welcome!
>>>>
>>>> Depends if it is simply something that has not yet been implemented or
>>>> if it truly is a bug.  It is Alpha after all.
>>>>
>>>> Feel free to start a discussion here or on Zulip
>>>>
>>>> On Wed, Jun 3, 2020, 6:31 AM Sanne Grinovero 
>>>> wrote:
>>>>
>>>>> Sure that's not a problem.
>>>>>
>>>>> However, 6.x has many open issues still - it might be best to track
>>>>> things on JIRA as usual:
>>>>>  - https://hibernate.atlassian.net/secure/Dashboard.jspa
>>>>>
>>>>> Either way is fine in principle, just normally we use the list to
>>>>> discuss proposals; for example if you plan to contribute a fix and
>>>>> have questions, or just want to let others know that you're looking at
>>>>> it then the list is more suitable.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> On Wed, 3 Jun 2020 at 11:26, Catalin Tudose 
>>>>> wrote:
>>>>> >
>>>>> > Great, thank you!
>>>>> > There is a possible issue I discovered with 6.0.0.Alpha5.
>>>>> > Would that be fine to share it on this list?
>>>>> >
>>>>> > On Wed, Jun 3, 2020 at 1:22 PM Sanne Grinovero 
>>>>> wrote:
>>>>> >>
>>>>> >> Hi Catalin,
>>>>> >>
>>>>> >> looks like you managed to post to the list!
>>>>> >>
>>>>> >> welcome,
>>>>> >> Sanne
>>>>> >>
>>>>> >> On Wed, 3 Jun 2020 at 11:15, Catalin Tudose <
>>>>> catalin.tud...@gmail.com> wrote:
>>>>> >> >
>>>>> >> > Hello!
>>>>> >> >
>>>>> >> > I would like to post to the hibernate-dev@lists.jboss.org
>>>>> mailing list!
>>>>> >> > My e-mail is catalin.tud...@gmail.com
>>>>> >> >
>>>>> >> > Thank you!
>>>>> >> > ___
>>>>> >> > 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] My email

[Steve Ebersole]

If you have a test, consider creating a PR against the 6.0 branch.  That's
the easiest way for us to look at it

On Wed, Jun 3, 2020 at 7:34 AM Catalin Tudose 
wrote:

> Hello!
>
> Thank you for the answers.
> I have a test case with CriteriaBuilder that is working fine with the
> 5.4.17.Final version, but it is throwing an exception with the 6.0.0.Alpha5
> version. I simply replaced the dependencies in the Maven pom.xml file.
> I am getting:
> java.lang.IllegalStateException: Could not resolve table reference
> `T_DEPARTMENT` relative to TableGroup `null` related with NavigablePath
> `NavigablePath[edu.jpa.entity.Employee.department.{id}]`
> I initially took a look at the JIRA open issues looking for the keywords
> "relative to TableGroup" and "related with NavigablePath", but could not
> find anything.
> I can provide the source code for both examples (should I attach it to an
> e-mail on the list?) and I hope it will worth your attention.
>
> On Wed, Jun 3, 2020 at 3:16 PM Steve Ebersole  wrote:
>
>> Welcome!
>>
>> Depends if it is simply something that has not yet been implemented or if
>> it truly is a bug.  It is Alpha after all.
>>
>> Feel free to start a discussion here or on Zulip
>>
>> On Wed, Jun 3, 2020, 6:31 AM Sanne Grinovero  wrote:
>>
>>> Sure that's not a problem.
>>>
>>> However, 6.x has many open issues still - it might be best to track
>>> things on JIRA as usual:
>>>  - https://hibernate.atlassian.net/secure/Dashboard.jspa
>>>
>>> Either way is fine in principle, just normally we use the list to
>>> discuss proposals; for example if you plan to contribute a fix and
>>> have questions, or just want to let others know that you're looking at
>>> it then the list is more suitable.
>>>
>>> Thanks!
>>>
>>> On Wed, 3 Jun 2020 at 11:26, Catalin Tudose 
>>> wrote:
>>> >
>>> > Great, thank you!
>>> > There is a possible issue I discovered with 6.0.0.Alpha5.
>>> > Would that be fine to share it on this list?
>>> >
>>> > On Wed, Jun 3, 2020 at 1:22 PM Sanne Grinovero 
>>> wrote:
>>> >>
>>> >> Hi Catalin,
>>> >>
>>> >> looks like you managed to post to the list!
>>> >>
>>> >> welcome,
>>> >> Sanne
>>> >>
>>> >> On Wed, 3 Jun 2020 at 11:15, Catalin Tudose 
>>> wrote:
>>> >> >
>>> >> > Hello!
>>> >> >
>>> >> > I would like to post to the hibernate-dev@lists.jboss.org mailing
>>> list!
>>> >> > My e-mail is catalin.tud...@gmail.com
>>> >> >
>>> >> > Thank you!
>>> >> > ___
>>> >> > 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] My email

[Steve Ebersole]

Welcome!

Depends if it is simply something that has not yet been implemented or if
it truly is a bug.  It is Alpha after all.

Feel free to start a discussion here or on Zulip

On Wed, Jun 3, 2020, 6:31 AM Sanne Grinovero  wrote:

> Sure that's not a problem.
>
> However, 6.x has many open issues still - it might be best to track
> things on JIRA as usual:
>  - https://hibernate.atlassian.net/secure/Dashboard.jspa
>
> Either way is fine in principle, just normally we use the list to
> discuss proposals; for example if you plan to contribute a fix and
> have questions, or just want to let others know that you're looking at
> it then the list is more suitable.
>
> Thanks!
>
> On Wed, 3 Jun 2020 at 11:26, Catalin Tudose 
> wrote:
> >
> > Great, thank you!
> > There is a possible issue I discovered with 6.0.0.Alpha5.
> > Would that be fine to share it on this list?
> >
> > On Wed, Jun 3, 2020 at 1:22 PM Sanne Grinovero 
> wrote:
> >>
> >> Hi Catalin,
> >>
> >> looks like you managed to post to the list!
> >>
> >> welcome,
> >> Sanne
> >>
> >> On Wed, 3 Jun 2020 at 11:15, Catalin Tudose 
> wrote:
> >> >
> >> > Hello!
> >> >
> >> > I would like to post to the hibernate-dev@lists.jboss.org mailing
> list!
> >> > My e-mail is catalin.tud...@gmail.com
> >> >
> >> > Thank you!
> >> > ___
> >> > 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] Hibernate Reactive: Release day!

[Steve Ebersole]

Nice!  Congratulations

On Fri, May 29, 2020 at 9:27 AM Sanne Grinovero  wrote:

> It's released. Version 1.0.0.Alpha1 (not 0.0.1 as I mentioned in my
> previous email)
>
> Kudos to Yoann, as it's fully automated and it takes just under a
> minute to do the release - we should definitely try to do the same on
> other projects.
>
> On Fri, 29 May 2020 at 15:14, Sanne Grinovero  wrote:
> >
> > Hi all,
> >
> > we're about to test a first automated release.. Hibernate Reactive v.
> 0.0.1
> >
> > I expect some of you might be annoyed that they had "one more cool
> > improvement" which didn't make it; don't be: the release process is
> > highly automated (thanks to Yoann!) and we will have many more
> > triggered in the following days as we polish the process.
> >
> > Thanks,
> > Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] v6 and load-event

[Steve Ebersole]

If/when it comes to needing that, I kind of like that continuation design.
But I agree, Yoann is right - let's leave it off until needed or until we
have specific requirements.

Thanks everyone!

On Fri, May 29, 2020 at 2:19 AM Sanne Grinovero  wrote:

> On Fri, 29 May 2020 at 07:22, Yoann Rodiere  wrote:
> >
> > +1 not to add surround capability initially. Sounds better to start
> simple and make things more complex when we actually need it :)
>
> Right. I didn't mean to raise additional requirements without having
> investigated those tracing libraries - what I meant really is just to
> raise awareness that we'll likely need to evolve it further when it
> comes to finally implement such things.
>
> >
> > Yoann Rodière
> > Hibernate Team
> > yo...@hibernate.org
> >
> >
> > On Fri, 29 May 2020 at 07:25, Sanne Grinovero 
> wrote:
> >>
> >> Yes, I agree.
> >>
> >> On Thu, 28 May 2020, 22:11 Steve Ebersole,  wrote:
> >>>
> >>> Wanted to clarify -
> >>>
> >>> Regarding incremental addition of "surround listeners", so long as we
> are all in agreement that this simply means there will be absolutely no
> surround capability ***initially*** then I am fine with that.
> >>>
> >>> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole 
> wrote:
> >>>>
> >>>> Hm, the dynamic enable/disable stuff should be easy to handle, no?
> Depends on what specific library you are thinking of and exactly how that
> detail gets propagated to us.  At the end of the day, its really as simple
> as protecting the creation of some of these objects with `if
> (enabled)`-type checks.
> >>>>
> >>>> But again, if you have specific details in mind we can take a look.
> >>>>
> >>>> Also, I think it is not at all a good idea to even plan for
> "different types of events".  In fact I'm fine with getting rid of
> LoadEvent completely from that contract and simply directly passing the
> information that is likely useful.  I mean at the end of the day a listener
> for load events is going to be interested in the same set of information.
> Yes, some will not need all of that information but that's not really a
> concern IMO.  Especially if we inline the parameters and completely avoid
> the event object instantiation
> >>>>
> >>>> Regarding incremental addition of "surround listeners", so long as we
> are all in agreement that this simply means there will be absolutely no
> surround capability then I am fine with that.
> >>>>
> >>>>
> >>>> On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero 
> wrote:
> >>>>>
> >>>>> On Thu, 28 May 2020 at 21:27, Steve Ebersole 
> wrote:
> >>>>> >
> >>>>> > Any thoughts on this "continuation" approach?
> >>>>>
> >>>>> I love the pattern! Maybe we'll need also some ability to not capture
> >>>>> the state for events which don't have any?
> >>>>>
> >>>>> I wonder if that implies we'll need two different event contracts:
> one
> >>>>> for the listeners which need state and one for those which don't; but
> >>>>> I'm not eager to overcomplicate this.
> >>>>>
> >>>>> > Or maybe its just not important (yet) to handle "surround"
> handling?
> >>>>>
> >>>>> I'm confident that integration with tracing libraries would be very
> >>>>> useful and interesting to have - but indeed not having time to
> >>>>> research it properly I'm a bit afraid that it might need further
> >>>>> changes to reach excellent performance.
> >>>>>
> >>>>> For example one thing I remember is that with some libraries you're
> >>>>> supposed to have the option to enable/disable the profiling options
> >>>>> dynamically, and since there's an expectation of no overhead when
> it's
> >>>>> disabled this would need to imply having a way for the overhead of
> >>>>> allocating space for the captured state to "vanish": this might be a
> >>>>> bit more complicated, or need to be able to take advantage of JIT
> >>>>> optimisations.
> >>>>>
> >>>>> So if we end up thinking that such event APIs need to be different
> >>>>> depending on the need for state, perhaps indeed it's better

Re: [hibernate-dev] v6 and load-event

[Steve Ebersole]

Wanted to clarify -

Regarding incremental addition of "surround listeners", so long as we are
all in agreement that this simply means there will be absolutely no
surround capability ***initially*** then I am fine with that.

On Thu, May 28, 2020 at 4:10 PM Steve Ebersole  wrote:

> Hm, the dynamic enable/disable stuff should be easy to handle, no?
> Depends on what specific library you are thinking of and exactly how that
> detail gets propagated to us.  At the end of the day, its really as simple
> as protecting the creation of some of these objects with `if
> (enabled)`-type checks.
>
> But again, if you have specific details in mind we can take a look.
>
> Also, I think it is not at all a good idea to even plan for "different
> types of events".  In fact I'm fine with getting rid of LoadEvent
> completely from that contract and simply directly passing the information
> that is likely useful.  I mean at the end of the day a listener for load
> events is going to be interested in the same set of information.  Yes, some
> will not need all of that information but that's not really a concern IMO.
> Especially if we inline the parameters and completely avoid the event
> object instantiation
>
> Regarding incremental addition of "surround listeners", so long as we are
> all in agreement that this simply means there will be absolutely no
> surround capability then I am fine with that.
>
>
> On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero 
> wrote:
>
>> On Thu, 28 May 2020 at 21:27, Steve Ebersole  wrote:
>> >
>> > Any thoughts on this "continuation" approach?
>>
>> I love the pattern! Maybe we'll need also some ability to not capture
>> the state for events which don't have any?
>>
>> I wonder if that implies we'll need two different event contracts: one
>> for the listeners which need state and one for those which don't; but
>> I'm not eager to overcomplicate this.
>>
>> > Or maybe its just not important (yet) to handle "surround" handling?
>>
>> I'm confident that integration with tracing libraries would be very
>> useful and interesting to have - but indeed not having time to
>> research it properly I'm a bit afraid that it might need further
>> changes to reach excellent performance.
>>
>> For example one thing I remember is that with some libraries you're
>> supposed to have the option to enable/disable the profiling options
>> dynamically, and since there's an expectation of no overhead when it's
>> disabled this would need to imply having a way for the overhead of
>> allocating space for the captured state to "vanish": this might be a
>> bit more complicated, or need to be able to take advantage of JIT
>> optimisations.
>>
>> So if we end up thinking that such event APIs need to be different
>> depending on the need for state, perhaps indeed it's better to
>> postpone the design of those with state to when someone has time to
>> research an optimal integration with a tracing library. It might not
>> be too hard, I just haven't explored it myself yet.
>>
>> Maybe let's do this incrementally, considering the "continuation"
>> approach a next step?
>>
>> Thanks,
>> Sanne
>>
>> >
>> > On Wed, May 27, 2020 at 9:27 AM Steve Ebersole 
>> wrote:
>> >>
>> >> Inline...
>> >>
>> >> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero 
>> wrote:
>> >>>
>> >>> At high level I agree, just have 3 more thoughts:
>> >>>
>> >>> # Regarding the "swap" of information between listeners - could that
>> >>> even work? I might have misunderstood something, but wouldn't we
>> >>> require listeners to run in some specific order for such swapping to
>> >>> work?
>> >>
>> >>
>> >> This is why we allow control over the ordering of the registered
>> listeners.  And yes, that is and was a hokey solution.  Nothing changes
>> there really if that is why you are using load listener.
>> >>
>> >>
>> >>>
>> >>> # The "surround advice" you mention for e.g. timing seems very
>> >>> interesting, especially as I'd love us to be able to integrate with
>> >>> tracing libraries - but these would need to be able to co-relate the
>> >>> pre-load event with some post-load event. How would that work?  I'd
>> >>> expect these to need having a single listener implementation which
>> >>> implements both PreL

Re: [hibernate-dev] v6 and load-event

[Steve Ebersole]

Hm, the dynamic enable/disable stuff should be easy to handle, no?  Depends
on what specific library you are thinking of and exactly how that detail
gets propagated to us.  At the end of the day, its really as simple as
protecting the creation of some of these objects with `if (enabled)`-type
checks.

But again, if you have specific details in mind we can take a look.

Also, I think it is not at all a good idea to even plan for "different
types of events".  In fact I'm fine with getting rid of LoadEvent
completely from that contract and simply directly passing the information
that is likely useful.  I mean at the end of the day a listener for load
events is going to be interested in the same set of information.  Yes, some
will not need all of that information but that's not really a concern IMO.
Especially if we inline the parameters and completely avoid the event
object instantiation

Regarding incremental addition of "surround listeners", so long as we are
all in agreement that this simply means there will be absolutely no
surround capability then I am fine with that.


On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero  wrote:

> On Thu, 28 May 2020 at 21:27, Steve Ebersole  wrote:
> >
> > Any thoughts on this "continuation" approach?
>
> I love the pattern! Maybe we'll need also some ability to not capture
> the state for events which don't have any?
>
> I wonder if that implies we'll need two different event contracts: one
> for the listeners which need state and one for those which don't; but
> I'm not eager to overcomplicate this.
>
> > Or maybe its just not important (yet) to handle "surround" handling?
>
> I'm confident that integration with tracing libraries would be very
> useful and interesting to have - but indeed not having time to
> research it properly I'm a bit afraid that it might need further
> changes to reach excellent performance.
>
> For example one thing I remember is that with some libraries you're
> supposed to have the option to enable/disable the profiling options
> dynamically, and since there's an expectation of no overhead when it's
> disabled this would need to imply having a way for the overhead of
> allocating space for the captured state to "vanish": this might be a
> bit more complicated, or need to be able to take advantage of JIT
> optimisations.
>
> So if we end up thinking that such event APIs need to be different
> depending on the need for state, perhaps indeed it's better to
> postpone the design of those with state to when someone has time to
> research an optimal integration with a tracing library. It might not
> be too hard, I just haven't explored it myself yet.
>
> Maybe let's do this incrementally, considering the "continuation"
> approach a next step?
>
> Thanks,
> Sanne
>
> >
> > On Wed, May 27, 2020 at 9:27 AM Steve Ebersole 
> wrote:
> >>
> >> Inline...
> >>
> >> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero 
> wrote:
> >>>
> >>> At high level I agree, just have 3 more thoughts:
> >>>
> >>> # Regarding the "swap" of information between listeners - could that
> >>> even work? I might have misunderstood something, but wouldn't we
> >>> require listeners to run in some specific order for such swapping to
> >>> work?
> >>
> >>
> >> This is why we allow control over the ordering of the registered
> listeners.  And yes, that is and was a hokey solution.  Nothing changes
> there really if that is why you are using load listener.
> >>
> >>
> >>>
> >>> # The "surround advice" you mention for e.g. timing seems very
> >>> interesting, especially as I'd love us to be able to integrate with
> >>> tracing libraries - but these would need to be able to co-relate the
> >>> pre-load event with some post-load event. How would that work?  I'd
> >>> expect these to need having a single listener implementation which
> >>> implements both PreLoadEventListener and PostLoadEventListener, but
> >>> also they'll likely need some capability to store some information
> >>> contextual to the "event".
> >>
> >>
> >> I was just thinking through this one as well.  My initial thought was
> exactly what you proposed - some combination of pre/post listener with some
> ability to store state between.  But that gets ugly.
> >>
> >> Another option I thought about is easier to illustrate, but basically
> works on the principle of "continuation" many surround advice solutions are
> based on:
> https://gist.github.com/sebers

Re: [hibernate-dev] v6 and load-event

[Steve Ebersole]

Any thoughts on this "continuation" approach?

Or maybe its just not important (yet) to handle "surround" handling?

On Wed, May 27, 2020 at 9:27 AM Steve Ebersole  wrote:

> Inline...
>
> On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero 
> wrote:
>
>> At high level I agree, just have 3 more thoughts:
>>
>> # Regarding the "swap" of information between listeners - could that
>> even work? I might have misunderstood something, but wouldn't we
>> require listeners to run in some specific order for such swapping to
>> work?
>>
>
> This is why we allow control over the ordering of the registered
> listeners.  And yes, that is and was a hokey solution.  Nothing changes
> there really if that is why you are using load listener.
>
>
>
>> # The "surround advice" you mention for e.g. timing seems very
>> interesting, especially as I'd love us to be able to integrate with
>> tracing libraries - but these would need to be able to co-relate the
>> pre-load event with some post-load event. How would that work?  I'd
>> expect these to need having a single listener implementation which
>> implements both PreLoadEventListener and PostLoadEventListener, but
>> also they'll likely need some capability to store some information
>> contextual to the "event".
>>
>
> I was just thinking through this one as well.  My initial thought was
> exactly what you proposed - some combination of pre/post listener with some
> ability to store state between.  But that gets ugly.
>
> Another option I thought about is easier to illustrate, but basically
> works on the principle of "continuation" many surround advice solutions are
> based on:
> https://gist.github.com/sebersole/142765fe2417492061e92726e7cb6bd8
>
> I kept the name LoadEventListener there, but since it changes the contract
> anyway I'd probably rename this to something like SurroundLoadEventListener
>
>
>
>> # To clarify on my previous comment regarding why I'd consider having
>> an actual Event class more maintainable:
>> Sure we won't have inline classes widely used for a while, but I
>> prefer planning for the long term - also we could start using them
>> very soon via multi-release jars, which would simply imply that users
>> on newer JDKs would see more benefits than other users.
>> But especially, such event instances are passed over and over across
>> many methods; so in terms of maintenance and readability, such methods
>> would need to pass many parameters rather than one: the example made
>> above is oversimplifying our use.  Also while I understand it's
>> unlikely, having a "cheap" event objects makes it easier to change the
>> exact types being passed on.
>> BTW stack space is cheap but forcing many references to be passed when
>> one single reference could do might also have some performance
>> implications since these are passed many times - I've never tested
>> this scientifically though :)   Inline objects would typically be
>> allocated on the stack as well, but they don't force the JVM to do so.
>
>
>> Also while I said that it's unlikely we want to change those types,
>> the very coming of inline types might actually encourage us to make
>> changes in this area, even though these events have been stable for
>> years; for example "String entityName" seems like an excellent
>> candidate to become "EntityName typeIdentifier" - and then allow us to
>> improve the persister maps, which have been a bottleneck in the past.
>> So sure we could remove them and just pass parameters, we'd just need
>> to change more code if such a situation arises - I'm just highliting
>> the drawbacks for our consideration, not recommending against it :)
>>
>
> Maybe its simply a difference of wording, but to me none of this validates
> how keeping an event class is more maintainable.  If you want to say that
> eventually the overhead of having an actual event class will be less, ok,
> but that's different.
>
> For sure though we'd have lots of uses for in-line value types throughout
> the code base.  Just not sure this really an argument for keeping the event
> impl in-and-of-itself.
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] v6 and load-event

[Steve Ebersole]

Inline...

On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero  wrote:

> At high level I agree, just have 3 more thoughts:
>
> # Regarding the "swap" of information between listeners - could that
> even work? I might have misunderstood something, but wouldn't we
> require listeners to run in some specific order for such swapping to
> work?
>

This is why we allow control over the ordering of the registered
listeners.  And yes, that is and was a hokey solution.  Nothing changes
there really if that is why you are using load listener.



> # The "surround advice" you mention for e.g. timing seems very
> interesting, especially as I'd love us to be able to integrate with
> tracing libraries - but these would need to be able to co-relate the
> pre-load event with some post-load event. How would that work?  I'd
> expect these to need having a single listener implementation which
> implements both PreLoadEventListener and PostLoadEventListener, but
> also they'll likely need some capability to store some information
> contextual to the "event".
>

I was just thinking through this one as well.  My initial thought was
exactly what you proposed - some combination of pre/post listener with some
ability to store state between.  But that gets ugly.

Another option I thought about is easier to illustrate, but basically works
on the principle of "continuation" many surround advice solutions are based
on: https://gist.github.com/sebersole/142765fe2417492061e92726e7cb6bd8

I kept the name LoadEventListener there, but since it changes the contract
anyway I'd probably rename this to something like SurroundLoadEventListener



> # To clarify on my previous comment regarding why I'd consider having
> an actual Event class more maintainable:
> Sure we won't have inline classes widely used for a while, but I
> prefer planning for the long term - also we could start using them
> very soon via multi-release jars, which would simply imply that users
> on newer JDKs would see more benefits than other users.
> But especially, such event instances are passed over and over across
> many methods; so in terms of maintenance and readability, such methods
> would need to pass many parameters rather than one: the example made
> above is oversimplifying our use.  Also while I understand it's
> unlikely, having a "cheap" event objects makes it easier to change the
> exact types being passed on.
> BTW stack space is cheap but forcing many references to be passed when
> one single reference could do might also have some performance
> implications since these are passed many times - I've never tested
> this scientifically though :)   Inline objects would typically be
> allocated on the stack as well, but they don't force the JVM to do so.


> Also while I said that it's unlikely we want to change those types,
> the very coming of inline types might actually encourage us to make
> changes in this area, even though these events have been stable for
> years; for example "String entityName" seems like an excellent
> candidate to become "EntityName typeIdentifier" - and then allow us to
> improve the persister maps, which have been a bottleneck in the past.
> So sure we could remove them and just pass parameters, we'd just need
> to change more code if such a situation arises - I'm just highliting
> the drawbacks for our consideration, not recommending against it :)
>

Maybe its simply a difference of wording, but to me none of this validates
how keeping an event class is more maintainable.  If you want to say that
eventually the overhead of having an actual event class will be less, ok,
but that's different.

For sure though we'd have lots of uses for in-line value types throughout
the code base.  Just not sure this really an argument for keeping the event
impl in-and-of-itself.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] v6 and load-event

[Steve Ebersole]

n example of this approach already in
>> org.hibernate.internal.SessionImpl#internalClear : the signature I had
>> to use is a bit puzzling, but it manages to avoid allocating the event
>> (unless needed) and also avoids allocating the iterator on the
>> listeners.
>>
>> For example PostLoad events by default have a single listener, but
>> looking more closely I believe we could avoid registering that single
>> listener depending on configuration.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On Tue, 26 May 2020 at 16:00, Steve Ebersole  wrote:
>> >
>> > Historically we made a terrible design mistake with the event system as
>> a
>> > whole.  This has both a confusing design impact and a very real
>> performance
>> > impact.  The main problem is the smashing together of things that handle
>> > events and things that listen to such events.
>> >
>> > In working on a problem in v6 I have come to a point where fixing this
>> > design flaw for load events specifically would be a huge help.  So I'm
>> > going to make a proposal for how to specifically change this for load
>> event
>> > handling.  The plan at the moment is to not make similar changes to the
>> > other event types for now, though I certainly would like to keep them
>> all
>> > in mind with regard to the overall design for if/when we can get to the
>> > others.
>> >
>> > So I'd love feedback specifically regarding (1) general design
>> considering
>> > other event types and (2) issues/concerns specific to load event type.
>> >
>> > I created a simple example at
>> > https://gist.github.com/sebersole/2a1c3ac010a166fc91e62b088179678d
>> >
>> > Thanks!
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Beyond checkstyle

[Steve Ebersole]

It is an interesting idea.  Guess it depends just how configurable it is to
get what we want.




On Tue, May 26, 2020 at 5:03 AM Sanne Grinovero  wrote:

> Hi all,
>
> in Quarkus we're using a plugin which automatically reformats the code
> and sorts imports.
>
> In our older projects we've been using checkstyle; the goal has always
> been to try to avoid conflicts and improve readability, but to try to
> impose such consistency typically leads to a significant annoyance and
> waste of time during development - so imposing checkstyle hans't been
> very popular, and certainly comes at a cost.
>
> So the idea in Quarkus has this nice effect: rather than getting "in
> the way" it uses a plugin which automatically fixes the code, one
> needs to just add the further changes to version control (CI can be
> setup to fail rather than fix). The plugin used by Quarkus have some
> drawbacks though: the code style can't be configured, and it happens
> to look very different than the Hibernate conventions so I don't think
> it would be useful for us.
>
> With Hibernate Reactive I started now to explore a new tool which looks
> better:
>  -
> https://github.com/hibernate/hibernate-reactive/pull/191/commits/c7c47c4c990da945e6058631a2eddfdb06ca7e05
>
> This one is rather flexible and configurable, great support for
> Gradle, and can also be set to automatically fix the code rather than
> complain.
>
> We're going to use it on Hibernate Reactive to enforce only some
> essentials: license headers, remove unused imports, remove end-of-line
> whitespace.  I suppose we could start using it for some more advanced
> rules later, but I'd be cautious about it. One high on my list of
> wishlist is to have imports sorted in a standard way, as that's
> another source of totally pointless, annoying conflicts.
>
> Other projects might want to explore using it as well?
>
> It supposedly supports Maven as well; haven't tests it though.
> See:
>  - https://github.com/diffplug/spotless
>
> Thanks
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] v6 and load-event

[Steve Ebersole]

Historically we made a terrible design mistake with the event system as a
whole.  This has both a confusing design impact and a very real performance
impact.  The main problem is the smashing together of things that handle
events and things that listen to such events.

In working on a problem in v6 I have come to a point where fixing this
design flaw for load events specifically would be a huge help.  So I'm
going to make a proposal for how to specifically change this for load event
handling.  The plan at the moment is to not make similar changes to the
other event types for now, though I certainly would like to keep them all
in mind with regard to the overall design for if/when we can get to the
others.

So I'd love feedback specifically regarding (1) general design considering
other event types and (2) issues/concerns specific to load event type.

I created a simple example at
https://gist.github.com/sebersole/2a1c3ac010a166fc91e62b088179678d

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

[hibernate-dev] ORM 6.0 Alpha5 released

[Steve Ebersole]

https://in.relation.to/2020/04/24/hibernate-orm-600-Alpha5-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Unable to release :(

[Steve Ebersole]

I manually uploaded to SourceForge and Andrea helped (thanks!) with the doc
server.

I'll work on a release announcement this weekend, there was a lot involved
in this one.



On Fri, Apr 24, 2020 at 2:11 PM Steve Ebersole  wrote:

> I ran the 6.0 Alpha5 release.  All the tasks completed fine except I was
> not able to upload the "dist" to Sourceforge nor the docs to JBoss.  All
> artifacts are pushed to BinTray.
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Unable to release :(

[Steve Ebersole]

I ran the 6.0 Alpha5 release.  All the tasks completed fine except I was
not able to upload the "dist" to Sourceforge nor the docs to JBoss.  All
artifacts are pushed to BinTray.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Migration to Jakarta API: some practical aspects in dealing with Git and mass replacements

[Steve Ebersole]

Thanks for taking care of this Sanne.

On Mon, Apr 20, 2020 at 7:58 AM Sanne Grinovero  wrote:

> Hi all,
>
> the migration to the Jakarta API is rather simple and can be performed
> by "find and replace" operations, but it will affect a lot of code and
> might get int the way of other work.
>
> To keep things simple and avoid tedious, massive conflict resolutions
> for all of us who are having "work in progress" somewhere in branches,
> open pull requests, and local work in progress which didn't make it to
> pull requests yet, I would suggest to not blindly merge/rebase changes
> from master, but take a little special care while this process is
> ongoing.
>
> For example, I just pushed the update to Hibernate Validator 7
> [HHH-13950], which is done
> via the following two commits:
>
>  1 -
> https://github.com/hibernate/hibernate-orm/commit/b9a24f458c6e9c5331b2362f58eb36e5c244de5e
>
>  2 -
> https://github.com/hibernate/hibernate-orm/commit/60abc8aa76492992047d1d6b08b95df3846a
>
> Please note I'm using the commit description space to make notes about
> how to port these commits.
>
> I hope this helps; on top of single scripts for the individual
> commits, when I'm done I'll also share a "one shot" script which could
> be useful to process patches, so to have them apply cleanly for all
> the unmerged work in progress we might have around.
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-13916 / WFLY-13259

[Steve Ebersole]

Not really sure what "better" names you have in mind, but to me only one of
these 2 is really an identifier.  This new method is more a niche value to
me.  So not sure why you want to rename the original.

On Fri, Apr 17, 2020 at 3:36 PM Sanne Grinovero  wrote:

> On Thu, 16 Apr 2020 at 01:06, Gail Badner  wrote:
> >
> > Hi Galder,
> >
> > Thanks for the response. I agree this would be a good change for H6. I'm
> happy to hear that this is on someone's radar for Infinispan.
> >
> > Sanne, regarding:
> > > I'd say if you clearly mark the old method deprecated (or even remove
> it?) it
> > will be guaranteed we don't forget about this improvement.
> >
> > Are you suggesting that
> SharedSessionContractImplementor#getSessionIdentifier be deprecated?
> > If so, it has other uses, so it really can't be deprecated.
>
> Right, sorry let me clarify that. What I'm getting at is that clearly
> the current method is being used in different contexts; I see at leat
> two main ones:
>  - requiring a Serializable identifier (across the wire for
> clustering, and to be stored in databases) - typically an UUID.
>  - some form of "identity token" as we discussed on Zulip, which is
> far cheaper to generate but unsuitable for serialization.
>
> When we get to such realizations, I generally think it's a good idea
> to create more suitably named versions for *both* such use cases so to
> avoid the overloaded notion we currently have.
> Then, as second step deprecate (or remove) the original method.
>
> Since we're discussing a major release, I'd remove the existing
> method, or if you prefer the more conservative approach create JIRA
> for it to be removed just before Final if that's more convenient -
> for example keeping it a little longer could facilitate testing of the
> previews without already needing the custom 2LC release but
> I suspect it's not really worth it to be overzealous.
>
> Thanks,
> Sanne
>
>
> >
> > I've moved the fix version for HHH-13916 to 6.0.0.Beta1 and created a
> wip/6.0 PR: https://github.com/hibernate/hibernate-orm/pull/3341 .
> >
> > Regards,
> > Gail
> >
> >
> > On Wed, Apr 15, 2020 at 7:58 AM Galder Zamarreno 
> wrote:
> >>
> >> Given that there's a workaround for the issue, I'd agree with Sanne to
> make this an ORM 6+ only improvement.
> >>
> >> Indeed I'm no longer in the team and hence could not be the maintainer
> for such a module, but I'd be happy to discuss improvements for ORM6
> caching. I've not been aware of any discussions on that yet.
> >>
> >> On the Infinispan side, just a couple of weeks back Tristan was asking
> me about the need for a remote Infinispan cache provider for ORM. Maybe
> ORM6 offers a good opportunity to rework the provider and make it easy to
> maintain a local/remote provider.
> >>
> >> Galder
> >>
> >>
> >> On Wed, Apr 15, 2020 at 1:42 PM Sanne Grinovero 
> wrote:
> >>>
> >>> On Wed, 15 Apr 2020 at 02:16, Gail Badner  wrote:
> >>> >
> >>> > FWIW, there's no point in fixing HHH-13916 unless we hear that
> Infinispan is going to use the fix.
> >>>
> >>> I suppose we can expect that that will eventually happen - I just
> >>> don't know when and were to best make a note of such a need? I'd say
> >>> if you clearly mark the old method deprecated (or even remove it?) it
> >>> will be guaranteed we don't forget about this improvement.
> >>>
> >>> As far as I know, there isn't an Infinispan 2LC codebase for ORM6 yet,
> >>> and there will be more differences likely?
> >>>
> >>> Also keep in mind that Galder no longer works on Infinispan, he's now
> >>> focused on GraalVM and JDK engineering. I'm glad he's still around and
> >>> we might be able to bother him for suggestions and wisdom, but I'm not
> >>> sure yet who's going to be responsible to create such a new module.
> >>> Radim is on the performance team; as always, would be awesome to have
> >>> his help but I don't know of the performance team will be able to own
> >>> the module maintenance.
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>>
> >>> >
> >>> > Radim/Galder, WDYT?
> >>> >
> >>> > Thanks,
> >>> > Gail
> >>> >
> >>> > On Tue, Apr 14, 2020 at 3:25 PM Gail Badner 
> wrote:
> >>> >>
> >>> >> Hi Sanne,
> >>> >>
> >>> >> I've reworked HHH-13916 to use this alternative, and set the fix
> version to 6-wishlist.
> >>> >>
> >>> >> Regards,
> >>> >> Gail
> >>> >>
> >>> >> On Tue, Apr 14, 2020 at 1:23 AM Sanne Grinovero <
> sa...@hibernate.org> wrote:
> >>> >>>
> >>> >>> Hi Gail,
> >>> >>>
> >>> >>> I would go ahead with this improvement for ORM 6 and avoid spending
> >>> >>> your precious time on a v5 improvement - especially if it's going
> to
> >>> >>> require coordination with both the Infinispan and WildFly teams.
> >>> >>>
> >>> >>> Thanks
> >>> >>>
> >>> >>> On Fri, 10 Apr 2020 at 00:56, Gail Badner 
> wrote:
> >>> >>> >
> >>> >>> > I've been looking into how to fix this issue:
> >>> >>> >
> >>> >>> > https://hibernate.atlassian.net/browse/HHH-13916
> >>> >>> > https://issues.redhat.com/browse/WFLY-13259
> >>> 

Re: [hibernate-dev] Hibernate Rx: Remove Optional from API

[Steve Ebersole]

Bit off track, but since you mentioned load, etc... Take a look at
the IdentifierLoadAccess, etc variants for loading.  E.g.

interface IdentifierLoadAccess {
T getReference(Object id);
T load(Object id);
Optional loadOptional(Object id);
}

Granted I'm partial, but I think that's pretty clear :)

Reactive stuff is a bit different, but from my experience I would never
ever ever use something like `Optional` for an
association.  In fact back in the day this was more/less what Top Link did
for to-one mappings and it was fugly.  Not that you are suggesting that
per-se.


On Thu, Apr 16, 2020 at 9:11 AM Sanne Grinovero  wrote:

> I would agree with you all about the general sentiment against the use
> of Optional, but there's one use case in which I think it might make
> sense (although bear with me as I've never really used it much yet) :
>
> there's several methods on the standard Session and EntityManager in
> Hibernate ORM to fetch a single entity: load/find/get/...
>
> Even after all these years, I always have to open the Javadoc to
> remember which ones are making assumptions about the entity existence
> in the database (so could return a proxy even if the object doesn't
> actually existin the DB), and which ones are going to check first in
> the DB, possibly returning null.
>
> Wouldn't Optional be great there to express the doubt vs the certainty
> of it returning something?
>
> Similarly in xToOne associations, having to remember to set the
> "optional" attribute, or having business code having to match the
> mapping is not ideal. That's perhaps unrelated, as this second point
> is more about how users should express mappings rather than how we
> expose APIs, but I mean it as an example to not necessarily go to the
> extreme of ignoring that it might have some use in some selected
> cases.
>
> Thanks,
> Sanne
>
> On Thu, 16 Apr 2020 at 11:44, Davide D'Alto  wrote:
> >
> > Hi,
> > Gavin sent this PR: https://github.com/hibernate/hibernate-rx/pull/93
> >
> > It removes Optional from the API, for example:
> >
> >  CompletionStage> fetch(T association);
> >
> > becomes:
> >
> >  CompletionStage fetch(T association);
> >
> > Is there anybody here with strong opinions about keeping Optional in the
> > API?
> >
> > Thanks,
> > Davide
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?

[Steve Ebersole]

I do not plan on dropping hibernate-osgi.  Its there; it works.  Any
specific reason you say that Yoann?

Brett is the only one to do anything with that "tutorial".  Though as time
went on its focus was more a way to find problems when the paxexam tests
failed - they almost always give useless feedback.  If you think people are
using it as a tutorial then I agree we should remove it or update it.
Depending whether it still has benefit for troubleshooting I'd actually
just clarify its intent somehow rather removing it.  Brett?



On Thu, Apr 16, 2020 at 8:42 AM Sanne Grinovero  wrote:

> Agreed, I'll remove it.  Thanks Steve and Yoann!
>
> I'll remove them from 5.5 soon, you can then merge the removal in 6.0
> or do it differently if that's easier.
>
> This is the JIRA:
>  - https://hibernate.atlassian.net/browse/HHH-13952
>
> Regarding OSGi (which Yoann raised): I agree we shouldn't spend
> significant amounts of time on it, but as long as tests still work and
> it doesn't get in the way I'll leave them be.
> I have a related JIRA for OSGi as well: the tutorial is using very old
> (unmaintained?) dependency versions, so it will either need to be
> removed (people can always read the older tutorial), or it should be
> updated (and tested).
> I might give it a shot to update it, but I'm afraid it will need a
> full set of Jakarta EE 9 dependencies available as well.
>  - https://hibernate.atlassian.net/browse/HHH-13951
>
> Yoann, great idea about the platform agnostic testrunner. We should
> keep that in mind, hopefully we'll be able to make it happen
> eventually.
>
> Thanks,
> Sanne
>
>
> On Thu, 16 Apr 2020 at 13:46, Steve Ebersole  wrote:
> >
> > Considering the changes in WildFly, I also think we should just drop
> hibernate-orm-modules.
> >
> > For 6.0 I will definitely do this.  I also think removing it is good for
> 5.5.
> >
> > Not sure it is even worth the hassle for earlier releases however.
> >
> >
> > On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero 
> wrote:
> >>
> >> As we're working to upgrade to Jakarta EE 9, our feature packs for
> >> Wildfly are not going to be functional for a while at least.
> >>
> >> Not only do we have to upgrade to JPA 3, but we also need to upgrade
> >> our integrations with a different Validator, a different CDI - none of
> >> these are provided by WildFly yet.
> >>
> >> I see several options:
> >>  A] I could disable the feature pack generation and its integration
> tests.
> >>  B] Keep generating and releasing a knowingly broken feature pack,
> >> disable its integration tests, document this is work in progress.
> >>  C] Delete all this stuff
> >>
> >> Frankly it's tempting to just delete it all: WildFly has switched to a
> >> new model which replaces the "feature pack" notion we have, so even if
> >> Wildfly were to provide an Jakarta EE 9 build for us to run
> >> integration tests sometimes soon I'm sadly quite certain that we'll
> >> have to rethink how these packs are generated, and if it's still worth
> >> for us doing this.
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Sanne
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?

[Steve Ebersole]

Considering the changes in WildFly, I also think we should just drop
hibernate-orm-modules.

For 6.0 I will definitely do this.  I also think removing it is good for
5.5.

Not sure it is even worth the hassle for earlier releases however.


On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero  wrote:

> As we're working to upgrade to Jakarta EE 9, our feature packs for
> Wildfly are not going to be functional for a while at least.
>
> Not only do we have to upgrade to JPA 3, but we also need to upgrade
> our integrations with a different Validator, a different CDI - none of
> these are provided by WildFly yet.
>
> I see several options:
>  A] I could disable the feature pack generation and its integration tests.
>  B] Keep generating and releasing a knowingly broken feature pack,
> disable its integration tests, document this is work in progress.
>  C] Delete all this stuff
>
> Frankly it's tempting to just delete it all: WildFly has switched to a
> new model which replaces the "feature pack" notion we have, so even if
> Wildfly were to provide an Jakarta EE 9 build for us to run
> integration tests sometimes soon I'm sadly quite certain that we'll
> have to rethink how these packs are generated, and if it's still worth
> for us doing this.
>
> Any thoughts?
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] ORM 6 : hibernate-orm-modules & Antlr 4

[Steve Ebersole]

I am working on re-enabling the `hibernate-orm-modules` module but am
running into a problem being able to resolve Antlr 4 classes.  I'm sure the
problem is related to the entry `` in
`hibernate-core.xml` but I am not sure how to fix that.  Any ideas?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

[Steve Ebersole]

When y'all talk about the bytecode enhancement solution, I'd like to better
understand what you mean exactly.

Do you mean at run-time like we did for ORM when we combined
Session/EntityManager?  The problem there is that this only works when we
control the environment (WildFly e.g.).  Do you mean at build-time?

Generally I am not a fan of either of these approaches.

My preference is based on the previous discussions that we intend no more
5.x release families (5.5, 5.6, etc).  Given that I'd prefer that we:

   1. Create a new 5.x family (5.5, 5.9, etc) that adds support for JPA 3
   on top of 5.3.  This would effectively "kill" 5.4.  This new 5.x release
   would be based on the JPA 3 API (renamed packages) and be able to read JPA
   3 annotations.  It would be nice if this version could read
   javax.persistence annotation as well, but to me that is a nice-to-have.
   None of us really has the time to tackle that work at the moment.  And who
   know, maybe a contributor takes that on.
   2. Convert 6 to use JPA 3 API.  I'd prefer to not support "dual
   annotation reading" here - based simply on resources.  This is a long term
   view - moving forward I do not think it is reasonable expectation to use
   JPA 3 API with JPA 2 annotations.  That might (debatable) make sense for a
   transitory period, but I'd rather not "waste" the effort here for 6.

For (1), in theory, I'd prefer to keep it using the JPA 2 API and read
both.  However I suggested using the JPA 3 API there because I assume we
are going to need a JPA 3 compliant version sooner rather than later for
TCKs.

On Wed, Mar 11, 2020 at 3:51 AM Sanne Grinovero  wrote:

> On Wed, 11 Mar 2020 at 08:39, Yoann Rodiere  wrote:
>
> > > Yet I'm convinced that having a release
> > > which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
> > > renamed) would be no good to us, as it would create an adoption
> > > barrier for both cathegories of people: the ones not interested to
> > > migrate away from JPA2, and the ones not interested to migrate beyond
> > > JPA3.
> >
> > I get that, but I'm definitely not as hopeful as you are as to the
> > reliability of those bytecode hacks you mentioned. But I guess that's an
> > uphill battle.
> >
>
> I'm not a fan of bytecode hacks either, so maybe let's just see what a POC
> looks like before tearing it down?
>
> What's to stop you from supporting JPA2.0 in ORM 7, with the same hacks you
> > mentioned for JPA3?
> >
>
> Right, and in fact I mentioned as one of the possibilities for ORM6 to be
> able to read and interpret the "legacy" annotations from JPA2.
>
> I believe that's important to not get in the way of adoption but rather
> actively help with some flexibility, otherwise people will have a very hard
> time to upgrade to 6, and that's something that risks becoming a
> significant burden on us all.
>
> Thanks,
> Sanne
>
>
> >- People who want JPA3 only have a hack-free ORM 7 that happens to
> >support JPA2 annotations.
> >- People who want JPA2 can migrate to ORM 7, and we'll provide hacks
> >to make it work.
> >
> > At least we wouldn't be penalizing people who want to migrate to JPA3
> with
> > potentially unreliable bytecode hacks. Only people who want the latest
> and
> > greatest on an older API (which is, after all, quite an unreasonable
> > request) would have to put up with that.
> > And we'll be able to completely ignore these hacks in ORM 8 after we
> > rebased it on 7, since ORM 8 will drop support for JPA2 (I hope?).
> >
> > Yoann Rodière
> >
> > Sr. Software Engineer, Middleware Engineering, Hibernate team
> >
> > Red Hat 
> >
> > 
> >
> >
> > On Wed, 11 Mar 2020 at 00:17, Guillaume Smet 
> > wrote:
> >
> >> On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero 
> >> wrote:
> >>
> >> > The "big bang" approach that Validator implemented is an option as
> >> > well; but the context is a bit different as we're having an actual
> >> > major release being developed, and the matter of possible time
> >> > pressure.
> >> >
> >>
> >> Thus the proposal of Yoann and me to just rename the current 6 to a
> later
> >> version and release a new major version that only contains the Jakarta
> >> package change.
> >>
> >> That way, we don't end up doing additional work and having weird
> versions
> >> partially supporting both.
> >>
> >> --
> >> Guillaume
> >> ___
> >> 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] Jakarta EE: JPA 3.0 is coming

[Steve Ebersole]

I'm curious... why are we saying that we need to simultaneously support
both sets of annotations and config settings?

As a user, if I choose to use the Jakarta-based JPA I would fully expect
that to only work with the Jakarta-based annotations and settings.

Is there something in the spec I am missing that says we need to understand
both simultaneously?

On Tue, Mar 10, 2020 at 9:21 AM Guillaume Smet 
wrote:

> Hi,
>
> On Tue, Mar 10, 2020 at 2:48 PM Yoann Rodiere  wrote:
>
> > > In particular I wonder, how would you all feel if (for example)
> > > Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API
> > > artifacts?
> >
> > Mixed feelings, to be honest
>
>
> Same here. I thought we decided against supporting both at the same time.
>
> As for HV, I won't. HV 7 will only support jakarta packages all over the
> place. And if you want jakarta packages, you will have to use HV 7. And
> it's going to be a big bang, meaning you also need jakarta-package CDI and
> so on.
>
> That is an important point for ORM too because that means you will have to
> also support both legacy CDI and new jakarta CDI if you want to support
> both at the same time. Pretty sure it's going to be a nightmare.
>
> Quick feedback on the HV move: it was relatively easy (but it's less
> code/complex than ORM).
>
> >From my point of view, the options are:
> 1/
> - release an ORM 5.5 with Jakarta packages but it will break all existing
> applications in a minor, not ideal
> - move 6 to jakarta packages too to avoid conflicts
>
> 2/
> - rename 6 to 7 (or 8)
> - release a 6 (or 7) with jakarta packages
>
> I don't think tying the Jakarta package release to the 6 cycle is a good
> idea so that's not an option for me.
>
> Note that in any case, some patches will be significantly harder to
> backport to 5.4 (and vice versa).
>
> --
> Guillaume
> ___
> 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] Custom EventType and listeners

[Steve Ebersole]

I agree at the high level.

On Thu, Mar 5, 2020 at 9:17 AM Sanne Grinovero  wrote:

> Hi Gail,
>
> at high level it seems a reasonable idea to me.
>
> In more detail, let's make sure the `registeredEventListeners`
> initialization is not affected by data races, but we can defer
> discussing such details on a PR as that would probably be clearer.
>
> Thanks,
> Sanne
>
> On Thu, 5 Mar 2020 at 07:16, Gail Badner  wrote:
> >
> > There has been some discussion that it may be useful for hibernate-rx to
> be
> > able to define RX-specific event types and listeners.
> >
> > I've created a POC [1] that adds this support. I still need to do some
> > testing, but I would like some feedback before I spend too much time on
> > this.
> >
> > Please let me know if this is a reasonable improvement. If it is, I will
> > create an HHH jira and create a pull request.
> >
> > Thanks,
> > Gail
> >
> > [1]
> >
> https://github.com/gbadner/hibernate-core/commit/2d368a2ce1da36468ab7f965467711bc59f439cf
> > ___
> > 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] Property using field access and has final getter/setter method

[Steve Ebersole]

If any getters or setters are final then the ProxyFactory cannot be used
and imo should not get built, especially moving forward as we could use
bytecode-based proxies

On Wed, Mar 4, 2020 at 2:11 PM Gail Badner  wrote:

> This commit [1] for HHH-11838 [2] causes an error to get logged by
> ProxyFactoryHelper#validateProxyability [3] for a property that uses field
> access and has a corresponding final getter/setter method.
>
> The logged error does not cause any failure, and the ByteBuddyProxyFactory
> gets built.
>
> Should this error be logged in this case?
>
> When the error message is valid, should ByteBuddyProxyFactory not get
> built?
>
> Thanks,
> Gail
>
> [1]
>
> https://github.com/hibernate/hibernate-orm/commit/f8b78bcad0df43bd9b69fa5ee9d3bf10a3202318
> [2] https://hibernate.atlassian.net/browse/HHH-11838
> [3]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/proxy/pojo/ProxyFactoryHelper.java#L87-L94
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM : format of the version logged on boot

[Steve Ebersole]

I tend to agree with Gail here.  Sure Sanne I understand your view there,
but realistically:
1) which other ORM jars do you see printing its version?
2) when are you expecting that ORM jar versions can be mixed amongst the
different modules?

On Thu, Feb 13, 2020 at 10:42 AM Sanne Grinovero 
wrote:

> Thanks all, I'll make the changes then:
>  - https://hibernate.atlassian.net/browse/HHH-13863
>
> Gail, answered to you below - sorry it took so long.
>
> On Fri, 7 Feb 2020 at 18:24, Gail Badner  wrote:
> >
> > +1 to changing it.
> >
> > The name was changed from "core" to "ORM" some years back. Can "core"
> just be dropped now?
>
> I'd prefer keeping the qualifier as it's referring to the
> "hibernate-core" jar, in the sense it's one jar among the various jars
> in Hibernate ORM as a whole.
>
> The reason is that there's tooling coming to help spotting misaligned
> jars, so say hibernate-core and hibernate-ehcache need to be at the
> same version, as they both belong to Hibernate ORM as whole.
> Essentially, we still need a way to identify the parts as they are
> packaged into different jars, so the qualifier is still useful in some
> contexts.
>
> >
> > On Fri, Feb 7, 2020 at 6:20 AM Yoann Rodiere 
> wrote:
> >>
> >> +1
> >>
> >>
> >> Yoann Rodière
> >> Hibernate Team
> >> yo...@hibernate.org
> >>
> >>
> >> On Fri, 7 Feb 2020 at 14:58, Sanne Grinovero 
> wrote:
> >>
> >> > It's minor cosmetics, but I'd like to change the format of the message
> >> > we log on boot.
> >> >
> >> > Currently we have:
> >> > INFO  [org.hib.Version] HHH000412: Hibernate Core
> {5.4.11-SNAPSHOT}
> >> >
> >> > I would like to change it into:
> >> >INFO  [org.hib.Version] HHH000412: Hibernate ORM core version
> >> > 5.4.11-SNAPSHOT
> >> >
> >> > in particular:
> >> >  - to remove the "{}" wrapping around the number
> >> >  - add "ORM"
> >> >  - lowercase "core" and add "version"
> >> >
> >> > Looks good? It would be more consistent with our own project
> >> > naming/branding, and with the format of similar messages being logged
> >> > by other popular libraries.
> >> >
> >> > Thanks,
> >> > Sanne
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

Hi Dave.

Same - I was swamped with stuff at the end of last week.

Yes, from what I was reading postgres is a bit strange in storing temporal
values.  Not unique to postgres - many databases do interesting things.

I'm curious how the driver handles binding Java 8 types directly.  The JDBC
spec was updated to support these types through the generic `#setObject`
methods (`#getObject` as well?).  Does the driver handle this.

Out of curiosity, which jdbc driver are you helping with?



On Thu, Jan 9, 2020 at 10:23 AM Dave Cramer  wrote:

> Hi,
>
> As one of the maintainers of the postgres jdbc driver I am interested in
> this discussion.
> Postgres only stores date/times in UTC. Everything else is a translation.
> The driver uses the client's timezone for all dates/times (for better or
> worse) If there is anything I can do to help make things easier, let me
> know.
>
>
>
> --
> Sent from: http://hibernate-development.74578.x6.nabble.com/
> ___
> 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] 6.0 - HQL literals

[Steve Ebersole]

Sorry Yoann, it was a crazy week and I missed this reply somehow...

Yes, you did an awesome job with setting up tests.  We will obviously make
sure those continue to work as we move forward.

I did mention in the original email (I think anyway, I meant to) that there
seemed to be a problem in parsing with Java 8 in certain scenarios.  I
found this via a SO post asking why something was not working the way I
expected.  The answer was that there is a bug in Java 8, but that parseBest
seems to work consistently across both versions.  We plan to talk about
moving to Java 9 as a base anyway so this may not be an issue either way we
decide to go regarding parse or parseBest.


On Wed, Jan 8, 2020 at 4:21 AM Yoann Rodiere  wrote:

> > This does nothing with Type.  The way the grammar is defined it
> literally understands each piece of the temporal.  So given, e.g.,
> {2020-01-01}, we know that 2020 is the year, etc.  This is the benefit of
> defining it syntactically.
>
> I trust you can build a temporal correctly from a string. I'm more
> concerned about passing that information to the JDBC driver through a
> parameter, or even directly to the database through an SQL literal. Last
> time I checked you had to use java.sql types to pass temporal parameters to
> JDBC drivers, so you will have to convert the java.time value to a
> java.sql.Timestamp or similar eventually. And *that* is much more tricky
> that I, at least, originally thought.
>
> Among other quirks:
>
>- creating a Timestamp from a year/day/etc. assumes the given
>year/day/etc. are in the default JVM timezone.
>- the JDBC driver will sometimes extract the year/day/etc. and
>interpret them as being in the DB timezone, or will sometimes use a
>DateFormat with a timezone to convert it to the correct timezone. It
>depends on the driver and even the version of the driver.
>- java.sql.Timestamp and java.time do not rely on the same calendar:
>Julian/Gregorian calendar for one, proleptic Gregorian calendar for the
>other.
>- java.sql.Timestamp and java.time do not assume the same offsets for
>various zone IDs around and before 1900, when time zones were not a
>formalized concept.
>
> I've spent days on conversion problems between java.time and java.sql in
> ORM over the last few months.
>
> Which is why I think using LocalDateTimeType to convert between the
> LocalDateTime literal and the Timestamp would be a good idea. If you want
> to rewrite that code for literals, sure that can work, but exhaustive
> testing will be needed.
>
> > As counter-intuitive as it sounds, a ZonedDateTime actually includes an
> offset to differentiate the overlap case you mention.
>
> Yep. That's why it accepts parsing a ZoneDateTime with both a zone ID and
> an offset. Try this:
> https://gist.github.com/yrodiere/278996f865a9854e222aea58b5a7f26e
>
> Note that a bug affects parsing ZoneDateTimes with both offset and zone ID
> on JDK8 (fixed in 9): https://bugs.openjdk.java.net/browse/JDK-8066982
> We have a helper to work around that in Search:
> https://github.com/hibernate/hibernate-search/blob/334e4aad5c776151bcf5dbb6d27bf61fc8a93443/util/common/src/main/java/org/hibernate/search/util/common/impl/TimeHelper.java#L38
>
> > I think the confusion here is in terms of (1) recognizing a temporal
> literal and "parsing it" and (2) applying it to SQL.  Different parts of
> the puzzle.
>
> Yep.
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Tue, 7 Jan 2020 at 19:50, Steve Ebersole  wrote:
>
>> As far as I know, even Java does not support that.  A true zone-id would
>>> be something like (for me) "America/Chicago".  If I ask Java to parse
>>> "2020-01-01 10:10:10 America/Chicago +02:00" it just says no.  For me, CST
>>> (standard) and CDT (daylight savings) are really synonyms for offset -
>>> either UTC-05:00 or UTC-06:00 depending on day of the year.
>>>
>>
>> It seems like the proper syntax for that would actually be "2020-01-01
>> 10:10:10+02:00 America/Chicago", but in my
>> testing DateTimeFormatter#parseBest did not handle that form either
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

Well, again, this is configurable.  If you don't want to use it, don't ;)

On Thu, Jan 9, 2020 at 1:28 AM Christian Beikov 
wrote:

> Am 08.01.2020 um 20:21 schrieb Steve Ebersole:
>
> On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
>>
>> This is about JPA Criteria whereas I was referring to how a literal in
>> HQL ends up in the SQL. I agree that with JPA Criteria things are
>> different as the API for parameters in queries is not very neat. A flag
>> for controlling how literals should be rendered in for JPA Criteria
>> sounds ok, but ultimately, a literal should be just that, a literal.
>>
>
> Well no - its about how literals defined in ORM queries should be handled
> in JDBC.  The HQL / criteria distinction is not important here.
>
> We'll agree to disagree that query literals should always be rendered as
> SQL literals.
>
> I got that you are concerned with the security aspect and think that the
> DBMS optimizer will not be able to build significantly better plans than
> with parameters. Is there any other reason why you prefer rendering
> literals as JDBC parameter by default?
>
> Since string literals in JPQL/HQL are defined syntactically like in SQL,
> the security part sounds managable to me as other (currently existing)
> literals are non-problematic due to their nature i.e. being numeric or
> strictly typed such the representation can't interferre with the SQL they
> are embedded into.
>
> The performance part is for me actually very critical. I attached a few
> links[1][2][3][4] to articles that cover this topic. Essentially, the
> difference in execution plans come from wrong row count estimates because
> of wrong selectivity. When using parameters, DBMS do a few tricks to
> overcome the problems of unknown selectivity due to a missing value. Oracle
> is pretty good at that AFAIU, but the behavior is configurable and we might
> run in an environment where it isn't configure how we'd expect it to be.
>
> PostgreSQL seems to use a generic plan(with wrong selectivity estimates)
> after the 5th execution and other DBMS probably have similar problems. In
> general, using literals is imporant when there are only a few values or
> when the row distribution is non-uniform. The problem gets big when a query
> has lots of joins that multiply to the wrong estimates, leading to e.g.
> full table scans rather than index scans.
>
> [1]
> http://davetechnotes.blogspot.com/2009/02/literal-vs-bind-variables-bind-variable.html
>
> [2]
> https://medium.com/@FranckPachot/postgresql-bind-variable-peeking-fb4be4942252
>
> [3]
> https://blog.jooq.org/2018/04/12/why-sql-bind-variables-are-important-for-performance/
>
> [4]
> https://blog.jooq.org/2017/05/30/when-to-use-bind-values-and-when-to-use-inline-values-in-sql/
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov 
wrote:

>
> This is about JPA Criteria whereas I was referring to how a literal in
> HQL ends up in the SQL. I agree that with JPA Criteria things are
> different as the API for parameters in queries is not very neat. A flag
> for controlling how literals should be rendered in for JPA Criteria
> sounds ok, but ultimately, a literal should be just that, a literal.
>

Well no - its about how literals defined in ORM queries should be handled
in JDBC.  The HQL / criteria distinction is not important here.

We'll agree to disagree that query literals should always be rendered as
SQL literals.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

On Wed, Jan 8, 2020 at 7:11 AM Christian Beikov 
wrote:

> Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
> > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
> > mailto:christian.bei...@gmail.com>> wrote:
> >
> > If a user enters a HQL literal, that user wants the literal to be
> > rendered like that if possible(which should always be possible).
> >
> >
> > Like I said earlier, we actually try to render literals (of any type)
> > as parameters whenever we can (which is almost always possible)
>
> IMO this should be configurable and I personally would prefer rendering
> as SQL literal as I'd argue people would generally only use a literal if
> they really want a literal i.e. not append a literal in a dynamic way
> like `"FROM Entity e WHERE e.active = " + someBoolean`. Such a query
> might be better off with a parameter. Why do you prefer rendering
> literals as parameter?
>

It is controllable.  Actually this part is not new to 6.  We added that
previously.  Vlad pulled it back from 6 into 5 back, although unfortunately
put it in a bad package and for some reason chose to name it differently.
So 5.x has `org.hibernate.query.criteria.LiteralHandlingMode`. 6.0
deprecates that in favor of
`org.hibernate.query.QueryLiteralRendering`

I'm not sure I'd classify all usages of literals as you do.  I think there
are a fair amount of people who do it simply because its easier and more
concise.


Most DBMS can better optimize a query plan when encountering literals
> vs. parameters e.g. choose a partial index or have better estimates. The
> trade-off is performance for possibly "worse" statement cache hit rate.
> I'd argue people would just use parameters if they want possible
> statement sharing or better caching.
>

Exactly, although a few additional thoughts:

   1. Passing along the literals as-is means possibly having SQL injection
   issues.  We'd really need to validate the content of the literal value.
   Parameters are safe from such injection attacks.
   2. The cases where the database optimizer can build a "better" plan
   using a literal versus a parameter is generally pretty small.  I can think
   of partition columns, tenancy columns - things of that nature.  You
   think its more broad?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov 
wrote:

> If a user enters a HQL literal, that user wants the literal to be
> rendered like that if possible(which should always be possible).
>

Like I said earlier, we actually try to render literals (of any type) as
parameters whenever we can (which is almost always possible)


The only thing we have to define is whether the literal is by default in
> the JVM TZ, JDBC TZ or UTC. We could offer syntax variants that default
> to UTC etc.
>

> Not sure what makes sense, even if I like UTC more, to me it feels like
> the default should be using the JDBC TZ(which by default is the JVM TZ)
> and offer a dedicated literal syntax for the UTC variant as well as
> support for specifying the TZ explicitly.
>

The literal can define the zone if they want control.  I think that is
enough.  Conceptually that is what "JDBC time zone" is supposed to mean
exactly what we are discussing here, right?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

Actually Java and JDBC say that all of these Java 8 temporal types are
valid to pass via JDBC.  It's done "implicitly" via the various
`#setObject` methods (as opposed to `#setTimestamp` e.g.).

Part of the problem here (6 and before) at the moment is that our
LocalDateTimeType, ZonedDateTimeType, etc types use the JDBC Time, Date and
Timestamp SQL mappings rather than SQL type descriptors that simply use
`#setObject`


On Wed, Jan 8, 2020 at 5:57 AM Yoann Rodiere  wrote:

> > Can't we just render a literal in the DBMS proprietary way as literal
> again
> > but with respective TZ information to avoid TZ issues in the JDBC driver?
>
> This may be an option. We would need to take into account the default JVM
> timezone, or the "jdbc_timezone" setting, to set the correct offset.
> However, I believe some JDBC drivers (MariaDB?) have options to convert
> between the JVM timezone and the DB timezone, because apparently some DBs
> assume the timezone of date/time values to be something else than UTC. Not
> sure SQL literals would be interpreted correctly in such scenarios.
>
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Wed, 8 Jan 2020 at 12:41, Christian Beikov 
> wrote:
>
> > Can't we just render a literal in the DBMS proprietary way as literal
> again
> > but with respective TZ information to avoid TZ issues in the JDBC driver?
> >
> > If we use an instant literal we use the UTC TZ in a SQL literal or
> function
> > to render that.
> >
> > Yoann Rodiere  schrieb am Mi., 8. Jän. 2020, 11:22:
> >
> > > > This does nothing with Type.  The way the grammar is defined it
> > literally
> > > understands each piece of the temporal.  So given, e.g., {2020-01-01},
> we
> > > know that 2020 is the year, etc.  This is the benefit of defining it
> > > syntactically.
> > >
> > > I trust you can build a temporal correctly from a string. I'm more
> > > concerned about passing that information to the JDBC driver through a
> > > parameter, or even directly to the database through an SQL literal.
> Last
> > > time I checked you had to use java.sql types to pass temporal
> parameters
> > to
> > > JDBC drivers, so you will have to convert the java.time value to a
> > > java.sql.Timestamp or similar eventually. And *that* is much more
> tricky
> > > that I, at least, originally thought.
> > >
> > > Among other quirks:
> > >
> > >- creating a Timestamp from a year/day/etc. assumes the given
> > >year/day/etc. are in the default JVM timezone.
> > >- the JDBC driver will sometimes extract the year/day/etc. and
> > interpret
> > >them as being in the DB timezone, or will sometimes use a DateFormat
> > > with a
> > >timezone to convert it to the correct timezone. It depends on the
> > driver
> > >and even the version of the driver.
> > >- java.sql.Timestamp and java.time do not rely on the same calendar:
> > >Julian/Gregorian calendar for one, proleptic Gregorian calendar for
> > the
> > >other.
> > >- java.sql.Timestamp and java.time do not assume the same offsets
> for
> > >various zone IDs around and before 1900, when time zones were not a
> > >formalized concept.
> > >
> > > I've spent days on conversion problems between java.time and java.sql
> in
> > > ORM over the last few months.
> > >
> > > Which is why I think using LocalDateTimeType to convert between the
> > > LocalDateTime literal and the Timestamp would be a good idea. If you
> want
> > > to rewrite that code for literals, sure that can work, but exhaustive
> > > testing will be needed.
> > >
> > > > As counter-intuitive as it sounds, a ZonedDateTime actually includes
> an
> > > offset to differentiate the overlap case you mention.
> > >
> > > Yep. That's why it accepts parsing a ZoneDateTime with both a zone ID
> and
> > > an offset. Try this:
> > > https://gist.github.com/yrodiere/278996f865a9854e222aea58b5a7f26e
> > >
> > > Note that a bug affects parsing ZoneDateTimes with both offset and zone
> > ID
> > > on JDK8 (fixed in 9): https://bugs.openjdk.java.net/browse/JDK-8066982
> > > We have a helper to work around that in Search:
> > >
> > >
> >
> https://github.com/hibernate/hibernate-search/blob/334e4aad5c776151bcf5dbb6d27bf61fc8a93443/util/common/src/main/java/org/hibernate/search/util/common/impl/TimeHelper.java#L38
> > >
> > >

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

On Wed, Jan 8, 2020 at 4:21 AM Yoann Rodiere  wrote:

> > This does nothing with Type.  The way the grammar is defined it
> literally understands each piece of the temporal.  So given, e.g.,
> {2020-01-01}, we know that 2020 is the year, etc.  This is the benefit of
> defining it syntactically.
>
> I trust you can build a temporal correctly from a string. I'm more
> concerned about passing that information to the JDBC driver through a
> parameter, or even directly to the database through an SQL literal. Last
> time I checked you had to use java.sql types to pass temporal parameters to
> JDBC drivers, so you will have to convert the java.time value to a
> java.sql.Timestamp or similar eventually. And *that* is much more tricky
> that I, at least, originally thought.
>


Not sure why we keep coming back to how the literal will be used in JDBC.
Again, this topic is about HQL parsing.

Yes, handling temporal values at the JDBC/SQL level can be very tricky.
That's true however whether that temporal value is an HQL literal or an
attribute value.

And its just a completely different topic overall.

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

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

>
> As far as I know, even Java does not support that.  A true zone-id would
> be something like (for me) "America/Chicago".  If I ask Java to parse
> "2020-01-01 10:10:10 America/Chicago +02:00" it just says no.  For me, CST
> (standard) and CDT (daylight savings) are really synonyms for offset -
> either UTC-05:00 or UTC-06:00 depending on day of the year.
>

It seems like the proper syntax for that would actually be "2020-01-01
10:10:10+02:00 America/Chicago", but in my
testing DateTimeFormatter#parseBest did not handle that form either
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

On Tue, Jan 7, 2020 at 10:05 AM Yoann Rodiere  wrote:

> On Tue, 7 Jan 2020 at 14:45, Steve Ebersole  wrote:
>
>> Sorry, I should have been more clear.  The literals are not "passed
>> through"; it's just a mechanism to be able to recognize the literal
>> syntactically while parsing.  All of those forms I showed actually are
>> handled in the code and interpreted as a Java temporal.  We then do
>> whatever we want to do with it in order to send it to the database (often
>> even as a parameter).
>>
>
> You mean you use the org.hibernate.type.Type instance registered in the
> dialect for this Java type to convert it to the SQL type? Nice, that
> definitely sounds more robust than what I thought.
>

This does nothing with Type.  The way the grammar is defined it literally
understands each piece of the temporal.  So given, e.g., {2020-01-01}, we
know that 2020 is the year, etc.  This is the benefit of defining it
syntactically.

I suppose the org.hibernate.type.Type instance used is inferred from the
> class of the litteral, which should be good enough in most cases. It may
> not work properly when users assigned their own type to a property, for
> example "where foo = {d 2020-01-01}" where "foo" is a LocalDate mapped as a
> Timestamp (see org.hibernate.test.type.LocalDateTest.
> DateAsTimestampRemappingH2Dialect). But that's rather advanced use case,
> and if you provide a way to define custom literal types as you said, users
> will have a way out.
>

This ties in with what I mentioned above.  The literal value is always an
instance of a Java 8 temporal type.  The Type we associate with the node
will be pulled from the TypeConfiguration.


Be aware that the form zone id + offset may also make sense, when users
> want to use a zone id during DST switch with overlap (the same datetime
> happens twice in the same zone, so the offset is needed for disambiguation).
> I suppose the offset alone would be enough, but from what I've seen, the
> resulting ZoneDateTime object is different depending on whether you pass
> zone id + offset or just offset.
>

As far as I know, even Java does not support that.  A true zone-id would be
something like (for me) "America/Chicago".  If I ask Java to parse
"2020-01-01 10:10:10 America/Chicago +02:00" it just says no.  For me, CST
(standard) and CDT (daylight savings) are really synonyms for offset -
either UTC-05:00 or UTC-06:00 depending on day of the year.

As counter-intuitive as it sounds, a ZonedDateTime actually includes an
offset to differentiate the overlap case you mention.



>
>
> * We also support a STRING_LITERAL form of temporal literals as I
>> mentioned originally.  In my experience, using
>> `java.time.format.DateTimeFormatter#parseBest` always returned a
>> ZonedDateTime whether a zone-id or offset was specified.  My understanding
>> is that this varies from Java 8 to Java 9.  So that's something to consider
>> as well.
>>
>


> Not sure I see which literal you're talking about, since the ones you
> mentioned were temporal literals; do you mean something like "where date =
> '2019-01-01'"?
>
If it's new, I'd personally be in favor of not allowing this and sticking
> to a specific syntax for time literals. Seems less error-prone.
>

No I meant the alternative form I mentioned initially.  So I could have
`{ts '2020-0101 10:10:10'}` or `{2020-0101 10:10:10`).  The first form is
parsed from the String via `java.time.format.DateTimeFormatter#parseBest`.
For the other form, we actually process each int value individually and
piece together the correct temporal.


I was talking about the org.hibernate.type.Type implementations for all the
> Java date/time types, be it in java.util or in java.time. As you know, each
> type maps to the database column slightly differently, and each has its
> quirks, because of how JDBC drivers handle date/time types. Quite a few
> JDBC drivers behave very strangely, especially in corner cases (DST switch,
> dates before year 1900, ...). Often, the legacy date/time APIs are to blame
> (though I wouldn't touch the older versions of the MySQL drivers with a ten
> foot pole).
>
> More to the point: I know from experience it is quite hard to get the
> conversion from Java date/time values to an SQL date/time value to work
> properly in all cases (JDBC driver, JVM timezone, database timezone). But
> if you re-use org.hibernate.type.Type to convert literals to SQL types,
> then it should behave the same as when persisting, so queries such as
> "where foo = {2019-01-01}" should work even if the date is converted in a
> convoluted way before it is sent to the database.
> You can find examples in package org.hibernate.test.type: LocalTimeTest,
> L

Re: [hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

Thanks for the feedback.

I added some comments in-line.

On Tue, Jan 7, 2020 at 1:59 AM Yoann Rodiere  wrote:

> Hi,
>
> The syntax looks nice.
> I suppose it's future-proof enough, though I can imagine us getting in
> trouble if JDBC starts allowing parameterized or custom formats, which may
> start with a digit or even (in edge cases) look like a date. That seems
> unlikely, so I think it's an acceptable risk.
>
> I'm not entirely sure allowing JDBC literals to be "passed-through" the
> HQL will always be intuitive, even if it's already allowed for integers:
> under some circumstances we map date-only or time-only types to timestamps,
> for example. The database might cast a date-only value to a timestamp
> automatically by setting hours/minutes/etc to zero, but I'm not sure that's
> what *we* do when persisting, considering the various hacks we have around
> timezones; '2019-01-01' might very well be converted to
> '2018-12-31T23:00:00', for all I know. As a result, there might be a broad
> range of Java types where these literals will be seen as "buggy".
>

Sorry, I should have been more clear.  The literals are not "passed
through"; it's just a mechanism to be able to recognize the literal
syntactically while parsing.  All of those forms I showed actually are
handled in the code and interpreted as a Java temporal.  We then do
whatever we want to do with it in order to send it to the database (often
even as a parameter).

As far as timezones, a datetime with no timezone is interpreted as a
LocalDateTime.  However I did have an open question there still regarding
*which* local - the local VM's timezone?  Or the "JDBC timezone" (which we
know via our `hibernate.jdbc.time_zone` setting)?  The literals can also
contain zone id or offset.  I choose to not except the form with 'T'.
E.g., all of these are valid:

   - {2020-01-01 10:10:10} - LocalDateTime
   - {2020-01-01 10:10:10 UTC} - ZonedDateTime
   - {2020-01-01 10:10:10 Z} - ZonedDateTime
   - {2020-01-01 10:10:10 +2} - ZonedDateTime
   - {2020-01-01 10:10:10 +02} - ZonedDateTime
   - {2020-01-01 10:10:10 +02:00} - ZonedDateTime
   - {2020-01-01 10:10:10 UTC+02:00} - ZonedDateTime
   - {2020-01-01 10:10:10 CST} - ZonedDateTime
   - {2020-01-01 10:10:10 America/Central} - ZonedDateTime
   - etc

* We also support a STRING_LITERAL form of temporal literals as I mentioned
originally.  In my experience, using
`java.time.format.DateTimeFormatter#parseBest` always returned a
ZonedDateTime whether a zone-id or offset was specified.  My understanding
is that this varies from Java 8 to Java 9.  So that's something to consider
as well.  I mention this because I tried to make interpreting the syntactic
form consistent.  If you are interested in the specifics of how this
happens, see:

   1. 
org.hibernate.query.hql.internal.SemanticQueryBuilder#interpretTemporalLiteral
   (handles syntactic forms)
   2. org.hibernate.type.descriptor.DateTimeUtils#DATE_TIME (handles String
   forms)


I don't understand the "broad range of Java types ..." part.  What do you
mean?  Do you have an example?


I might be wrong, but only exhaustive testing of all literals with all
> date/time types on all RDBMS will let us know for sure. Let's keep in mind
> how many bugs have surfaced from time-related features in the past...
>

Gavin actually did quite a bit of that in the PR he sent us.  He added
pretty cool support for various temporal-related things such as how to
handle formatting (to_char, etc), extraction and temporal arithmetic -
specifically formalizing and normalizing them across databases.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] 6.0 - HQL literals

[Steve Ebersole]

Initially when I started working on 6.0 I added support for defining
temporal literals using JDBC's "escape syntax".  JDBC already defines a
syntax for declaring temporal literals using this syntax -

   - {d '2020-01-01'} for a Date
   - {t '10:10:10'} for a Time
   - {ts '2020-01-01 10:10:10'} for a Timestamp

I had planned on using this syntax to define generalized support for adding
new types of literals using the "prefix" which is the first identifier
after the open brace.  I did not have any concrete plans for specific types
of literals, although I was hoping this would fit with hibernate-spatial
needs.

Since temporal values are so common I added another simplified form:

   - {2020-01-01} for a "Date"
   - {10:10:10} for a "Time"
   - {2020-01-01 10:10:10} for a "Timestamp"

Notice first the absence of quotes for these.  The patterns is defined as a
syntactic element of the grammar (thanks to Gavin King for this particular
idea)[1].

As a side note, I first tried to use back-ticks for these simplified
temporal literals rather than braces but that conflicts with the
`QUOTED_IDENTIFIER` lexer rule.  `QUOTED_IDENTIFIER` is never used (and
really kind of meaningless in the HQL grammar) so one option would be to
remove that rule and use the back-ticks for these literals like
`2020-01-01` as opposed to {2020-01-01} if folks like that better.

It's also important to note that I actually use the Java 8 temporal types
internally to represent these simplified literals because it is easy to
translate from one type to another starting from these types.

Anyone have objections or suggestions regarding any of this?


[1] -
https://github.com/hibernate/hibernate-orm/blob/eab6107ec2e7b3a0c06146a9ff51b9964f4b3169/hibernate-core/src/main/antlr/org/hibernate/grammars/hql/HqlParser.g4#L484
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Composite IDs with a null property/field

[Steve Ebersole]

I've already chimed in ;)

 I don't think this is something we should do.

On Wed, Dec 18, 2019, 3:44 PM Gail Badner  wrote:

> The main obstacle I see is that Hibernate assumes that ID columns are
> non-nullable, even if ID columns are explicitly mapped as nullable.
>
> This is consistent with the JPA spec, which says:
>
> "Every entity must have a primary key."
>
> ANSI SQL 92 says:
>
> "In addition, if the unique constraint was defined with PRIMARY KEY, then
> it requires that none of the values in the specified column or columns be
> the null value."
>
> javax.persistence.Column#nullable has a default of true.
>
> Since Hibernate ignores the default (as appropriate for a primary key), I
> think that it is also appropriate to ignore an explicit mapping to make it
> nullable (i.e., @Column(nullable="true")).
>
> I don't think it's a good idea to add a new property that would change
> this behavior for ID columns.
>
> Aside from the issue I mentioned above about ComponentType#hydrate [1],
> SQL Hibernate generates for loading an entity by ID would have to change.
> Currently, Hibernate generates SQL like the following:
>
> select ... from ... where  bundle = ? and key = ? and locale = ?
>
> If the locale column is null, then Session#get will return null.
>
> It is possible to create a custom (@Loader) to change the query used by
> Session#get.
>
> Unfortunately, that won't work when loading entities with a Query like
> "from ... where id = ?".
>
> IMO, if we want to support this use case, we should use Hibernate-specific
> annotations to indicate that a composite ID column should be forced to be
> nullable.
>
> I haven't thought too much about this yet, but something like the
> following comes to mind:
>
> @EnbeddedId
> @UniqueKeyIdColumns( uniqueKeyIdColumns = {
> @UniqueKeyIdColumn( name="BUNDLE_NAME" ),
> @UniqueKeyIdColumn( name="KEY" ),
> @UniqueKeyIdColumn( name="LOCALE", nullable="true" )
> }
>
> The default for UniqueKeyIdColumn#nullable would be false.
>
> This would likely affect SPIs.
>
> Honestly, I am on the fence about whether this use case should be
> supported.
>
> Steve, Emmanuel, please chime in with your opinion?
>
> Thanks,
> Gail
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/ComponentType.java#L671-L675
>
> On Tue, Dec 17, 2019 at 10:41 AM Gail Badner  wrote:
>
>> Jan-Willem, thanks very much for your feedback!
>>
>> You may be right about Hibernate not allowing a formula for a composite
>> ID property. It appears it's not allowed when hbm mapping is used. I'll
>> have to check to see if a formula is allowed when mapped with annotations..
>>
>> Looking a the mapping for Address again, I see the composite ID does not
>> contain a formula. Instead Address is associated with 2 different entity
>> names, each with a specified "where" attribute that indicates which entity
>> name the specific mapping is for:
>>
>> >table="Address"
>>entity-name="BillingAddress"
>>where="add_type='BILLING'"
>>check="add_type in ('BILLING', 'SHIPPING')"
>>select-before-update="true"
>>dynamic-update="true">
>>
>>
>>   
>>   
>>
>>...
>>
>> 
>>
>> >table="Address"
>>entity-name="ShippingAddress"
>>where="add_type='SHIPPING'"
>>select-before-update="true"
>>dynamic-update="true">
>>
>>
>>   
>>   
>>
>>...
>> 
>>
>> We would need to check the entity's "where" attribute or @Where clause
>> attribute value to see if the fragment references a composite ID column.
>>
>> Regards,
>> Gail
>>
>> On Tue, Dec 17, 2019 at 1:29 AM Jan-Willem Gmelig Meyling <
>> jan-wil...@youngmediaexperts.nl> wrote:
>>
>>> PostgreSQL doesn’t allow nullable columns in a compound primary key. It
>>> allows a unique constraint on a nullable column, but then it happily
>>> inserts the two values below - without constraint violation error.
>>>
>>> I too have stumbled upon the need for nullable identifiers in Hibernate
>>> however. Mostly when I want to map native query results without an actual
>>> PK to an entity class. Another use case is mapping a @Subselect entity.
>>> These may not have an actual identifier, for example when creating a join
>>> product, so in order for all results to appear at all, you specify a
>>> compound key based on your requirements. I have experienced that this
>>> compound key may contain null values (in case of a LEFT JOIN for example).
>>>
>>> As far as I am aware, it is currently not allowed to use Formula’s as
>>> @Id - I’ve stumbled upon this exception recently and I think correctly so .
>>> Maybe it is allowed for compound keys however. I think its safe to only
>>> allow null properties in an compound identifier if none of the identifier
>>> properties is a formula.
>>>
>>> Kind regards,
>>>
>>> Jan-Willem
>>>
>>>
>>>
>>>
>>>
>>>
>>> > On 17 Dec 2019, at 00:26, Gail Badner  wrote:
>>> >
>>> > I've confirmed that the same inserts 

Re: [hibernate-dev] IdClass superclasses

[Steve Ebersole]

Actually I was thinking of @EmbeddedId, but you were asking about @IdClass.

I think (2) sounds more natural.


On Tue, Dec 10, 2019 at 3:12 PM Steve Ebersole  wrote:

> To me this is perfectly consistent with how inheritance works in entity
> hierarchies.  Unless a super type is marked with @Entity
> or @MappedSuperclass, the "attributes" defined on that specific class are
> not picked up.
>
> Maybe I'm misunderstanding you?
>
> On Mon, Dec 9, 2019 at 1:58 PM Gail Badner  wrote:
>
>> Hi,
>>
>> Suppose we have the following:
>>
>> public class CompositeKey implements Serializable {
>>
>>   private Long id1;
>>
>>   private Long id2;
>>
>>   public CompositeKey(Long id1, Long id2) {
>> super();
>> this.id1 = id1;
>> this.id2 = id2;
>>   }
>> ...
>> }
>> public class InheritedKey extends CompositeKey {
>>
>>   private Long id3;
>>
>>   public InheritedKey(Long id1, Long id2, Long id3) {
>> super(id1, id2);
>> this.id3 = id3;
>>   }
>> ...
>> }
>>
>> @Entity(name = "IKE")
>> @IdClass(InheritedKey.class)public class InheritedKeyEntity {
>>
>>   @Id
>>   private Long id1;
>>
>>   @Id
>>   private Long id2;
>>
>>   @Id
>>   private Long id3;
>>
>>   private String name;
>> ...
>> }
>>
>>
>> Currently, Hibernate does not include InheritedKey#id3 in
>> InheritedKeyEntity's composite key unless InheritedKey is annotated with
>> @MappedSuperclass.
>>
>> I think there are some improvements that can be made.
>>
>> 1) As you can see, the entity, itself, has all of the ID fields annotated.
>> An improvement would be for Hibernate to ensure that all mapped ID
>> properties have been detected, and throw an exception if this is not the
>> case.
>>
>> 2) A class used as an IdClass does not need any annotations (as opposed to
>> a class used for an EmbeddedId class, which requires {{@Embeddable}}).
>> Since the class used as an IdClass does not need to be annotated, it seems
>> kind of strange that its superclass would need to be annotated with
>> {{@MappedSuperclass}} in order for its fields/properties to be persistent.
>> Since the field/property names must match what is annotated in an IdClass,
>> it is clear that the field/property in a superclass is intended to be an
>> ID. Perhaps we could make annotating the superclass with
>> {{@MappedSuperclass}} optional?
>>
>> Opinions?
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] IdClass superclasses

[Steve Ebersole]

To me this is perfectly consistent with how inheritance works in entity
hierarchies.  Unless a super type is marked with @Entity
or @MappedSuperclass, the "attributes" defined on that specific class are
not picked up.

Maybe I'm misunderstanding you?

On Mon, Dec 9, 2019 at 1:58 PM Gail Badner  wrote:

> Hi,
>
> Suppose we have the following:
>
> public class CompositeKey implements Serializable {
>
>   private Long id1;
>
>   private Long id2;
>
>   public CompositeKey(Long id1, Long id2) {
> super();
> this.id1 = id1;
> this.id2 = id2;
>   }
> ...
> }
> public class InheritedKey extends CompositeKey {
>
>   private Long id3;
>
>   public InheritedKey(Long id1, Long id2, Long id3) {
> super(id1, id2);
> this.id3 = id3;
>   }
> ...
> }
>
> @Entity(name = "IKE")
> @IdClass(InheritedKey.class)public class InheritedKeyEntity {
>
>   @Id
>   private Long id1;
>
>   @Id
>   private Long id2;
>
>   @Id
>   private Long id3;
>
>   private String name;
> ...
> }
>
>
> Currently, Hibernate does not include InheritedKey#id3 in
> InheritedKeyEntity's composite key unless InheritedKey is annotated with
> @MappedSuperclass.
>
> I think there are some improvements that can be made.
>
> 1) As you can see, the entity, itself, has all of the ID fields annotated.
> An improvement would be for Hibernate to ensure that all mapped ID
> properties have been detected, and throw an exception if this is not the
> case.
>
> 2) A class used as an IdClass does not need any annotations (as opposed to
> a class used for an EmbeddedId class, which requires {{@Embeddable}}).
> Since the class used as an IdClass does not need to be annotated, it seems
> kind of strange that its superclass would need to be annotated with
> {{@MappedSuperclass}} in order for its fields/properties to be persistent.
> Since the field/property names must match what is annotated in an IdClass,
> it is clear that the field/property in a superclass is intended to be an
> ID. Perhaps we could make annotating the superclass with
> {{@MappedSuperclass}} optional?
>
> Opinions?
>
> Thanks,
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

[Steve Ebersole]

>
> > JPA does not allow mixing of @IdClass and @EmbeddedId.  But I think
> that's a valid option.  In fact in our original work on 6 where we
> completely replaced the mapping model (persisters) i had added support for
> this.  We could add an improvement to pull this feature to 6 proper?
>
> There would be some rough edges (what would
> org.hibernate.Session#getIdentifier return, the embedded id or the idclass?
> What would Session.load accept? What would be the declared type of the ID
> in JPA Criteria?). But that could be a valuable feature for people who
> really want composite IDs. And it could solve the caching problem.
> However, if we need to solve the caching problem in ORM 5 and are not in a
> position to declare that caching isn't supported for such identifiers...
> then we'll have to work on some hack in ORM 5. So maybe it's not a priority
> in ORM 6.
>

`Session#getIdentifier` would return the embedded-id, imo.  The embedded-id
is the "real" id.  The id-class is just a simplified "syntactic sugar" used
only for an alternative form of loading.  In fact for an entity with an
id-class you can load using either approach, though the legacy form of
loading an entity with a non-aggregated composite id is truly painful.

Just spit-balling, one option would be to expose a even more simplified
loading for these entities using `Session#byId` (or a new similar method)
allowing specifying the simplified, basic "maps-id" values for the load.
Just for illustration, something like:

session.byCompositeId( EntityWithCompositeId.class )
.using( "idAttribute1", "idAttribute1-value" )
.using( "keyManyToOne", "keyManyToOne-basic-id-value" )
...
.load();

That's geared toward non-aggregated composite id cases, though really it
could be available in aggregated composite id cases as well.

We could also allow a form in normal load-by-id using a Map maybe?  I only
mention this as even though its still a "new feature", it does not require
any API changes or new APIs.

final Map idValues = new HashMap();
idValues.put( "idAttribute1", "idAttribute1-value" );
idValues.put( "keyManyToOne", "keyManyToOne-basic-id-value" );
...
session.get( EntityWithCompositeId.class, idValues );

Or even an "array Map" option to avoid the Map instantiation:

final Object[] idValues = new Object[] {
"idAttribute1", "idAttribute1-value",
"keyManyToOne", "keyManyToOne-basic-id-value",
...
};
assert idValues.length %2 == 0;
session.get( EntityWithCompositeId.class, idValues );

Of course, if the embedded-id could also have an id-class you'd use that.

I'd like to see all of these as options btw, not one-or-the-other.  Though
I'm fine if no-one else likes the `Session#byCompositeId` idea.  It was
just a spur-of-the-moment idea.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

[Steve Ebersole]

A few things...

On Thu, Dec 5, 2019 at 1:17 AM Yoann Rodiere  wrote:

Embedded IDs containing an association are a monstrosity anyway, and
> lead to problems even on the user side.
> E.g. you can't serialize (to a String, JSON, ...) and more importantly
> deserialize such ID without a session, in particular when using IDs in URL
> paths or in JSON content.
>

I disagree to an extent here.  Assuming I think composite ids are a good
idea anyway (I dont) then I actually think this is the most natural way to
model this.  I personally think JPA's MapsId is the monstrosity here ;)
FWIW however, JPA does not define support for @EmbeddedId with
a @ManyToOne.  So in that sense we'd be "ok" simply saying "ok, we support
mapping those, but they cannot be cached" if we need to go that route.

We already support a form of loading an entity with MapsId using the basic
form of the associated id if the associated entity as just a simple id.
It's not a stretch to extend that to composite ids I think which would be a
good feature.  Consider:

@Entity
public class Person {
  @Id String ssn;

  ...
}

@Entity
public class MedicalHistory {
  @Id
  @OneToOne
  @JoinColumn(name="FK")
  Person patient;

  ...
}

You can load a MedicalHistory here using the Person id.  E.g.
`session.get( MedicalHistory.class,
"123-45-6789" );`

If you consider a case like:

@Entity
@IdClass(EmployeeId.class)
public class Employee {
  @Id String firstName
  @Id String lastName

  ...
}

public class DependentId {
  String name;
  EmployeeId emp;
}

@Entity
@IdClass(DependentId.class)
public class Dependent {
  @Id String name;
  @Id
  @JoinColumns({
@JoinColumn(name="FK1", referencedColumnName="firstName"),
@JoinColumn(name="FK2", referencedColumnName="lastName")
  })
  @ManyToOne Employee emp;

  ...
}

It would be nice to allow loading a Dependent like: `session.load(
Dependent.class,
new Object[] {"Steve","Ebersole"} );`  The trouble there is the ordering of
the values compared to the attribute order.

This is all beyond the original question, but your point about loading
these made me think about this.  Ofc serializing does not disassemble, so
this is a moot point in regards to that.  For JSON, depends on your
marshalling


For these IDs to make sense, we would need to force users to define a
> separate, association-free class (using @IdClass?) to represent the
> "serializable" form of the embedded ID, which would also be used in
> Session.find() et. al. This would probably help when it comes to caching,
> too.
>

JPA does not allow mixing of @IdClass and @EmbeddedId.  But I think that's
a valid option.  In fact in our original work on 6 where we completely
replaced the mapping model (persisters) i had added support for this.  We
could add an improvement to pull this feature to 6 proper?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

[Steve Ebersole]

I think Sanne meant relying on equals/hasCode of the embeddable itself,
which we do not do as you pointed out.

On Wed, Dec 4, 2019 at 5:19 PM Gail Badner  wrote:

> Hi Sanne,
>
> By default, the cache key is of type CacheKeyImplementation [1]. As long as
> a composite key is a ComponentType (not a CustomType),
> CacheKeyImplementation#equals and #hashCode uses ComponentType#equals and
> #hashCode, not the custom implementation of the embeddable class methods.
>
> IIRC, a CustomType cannot contain an association, so disassembling a custom
> type should not be necessary.
>
> Steve, does that sound right to you?
>
> I believe that what you mentioned above does apply to "simple" cache keys,
> where the cache key is the ID itself. There are other cases where a simple
> cache key is not appropriate (e.g., multiple entity classes with the same
> type of ID). I don't remember offhand if there are warnings logged in those
> cases. We could warn if an application attempted to use a simple cache key
> with a cacheable entity that has a composite key with an association.
>
> Regarding B -- it is not possible to assemble the ID when
> calling CacheKeyImplementation#equals or #hashCode, because
> a CacheKeyImplementation does not have a reference to a Session, so it
> cannot resolve an associated entity. In any case, there should be no need
> to assemble an associated entity. It should be sufficient to for the
> disassembled entity ID to be used for #equals and #hashCode operations.
>
> [1]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/CacheKeyImplementation.java
>
>
>
> On Wed, Dec 4, 2019 at 2:03 PM Sanne Grinovero 
> wrote:
>
> > Hi Gail,
> >
> > going for a disassembled ID would seem logical, but we'll need some
> > special care to deal with custom implementations of equals/hashcode.
> >
> > Clearly a composite ID object would require the users to implement a
> > custom equals(); going for a solution based on a disassembled ID we
> > would need to either:
> >
> > A# trust the equals implementation is "the obvious one"
> >
> > B# hydrate both sides of the equals check for each time there's need
> > to invoke an equals (and same for hashcode)
> >
> > I'm afraid only B would be backwards compatible and bullet-proof, and
> > yet its performance overhead would make it a terrible choice.
> >
> > Perhaps the best solution is to constrain this, and warn that such a
> > model is not a good fit for caching?
> >
> > Unless someone has a better idea; thinking out of the box: could be
> > interesting to explore not allowing users to implement custom equality
> > contracts as that's the root of many problems, but that would require
> > much more careful thought, and for sure a significant breaking change.
> >
> > Or allow people to implement any custom equals, but ignore them and
> > apply "the obvious one" consistently.
> >
> > Thanks,
> > Sanne
> >
> >
> >
> > On Wed, 4 Dec 2019 at 19:40, Gail Badner  wrote:
> > >
> > > When an entity is cached with a composite ID containing a many-to-one
> > > association, the cache key will contain the many-to-one associated
> > entity.
> > > If the associated entity is not enhanced, then it could be an
> > uninitialized
> > > proxy.
> > >
> > > I've created a test case [1] that illustrates this using Infinispan.
> The
> > > test case is for 5.1 branch, since hibernate-infinispan is still
> included
> > > in that branch. The same would happen for master as well.
> > >
> > > Aside from the obvious issue with increased memory requirements to
> store
> > an
> > > entity, there are other problems as well.
> > >
> > > What I've found so far is that caching a key with an uninitialized
> entity
> > > proxy can cause some big problems:
> > >
> > > 1) A lookup will never find this key unless the lookup is done with a
> > cache
> > > key containing the same entity proxy instance.
> > >
> > > 2) Calling EntityManager#find with a composite ID containing a detached
> > > uninitialized entity proxy will result in a
> LazyInitializationException.
> > > This does not happen with second-level cache disabled.
> > >
> > > 3) Calling EntityManager#find with a composite ID containing a managed
> > > uninitialized entity proxy will result in the proxy being initialized.
> > This
> > > does not happen with second-level cache disabled.
> > >
> > > I have not looked into what happens when the associated entity is
> > enhanced
> > > and uninitialized (i.e., enhancement-as-proxy).
> > >
> > > IIUC, disassembling the ID that gets stored in the cache key would be
> far
> > > more efficient, and would avoid these issues. We would only want to do
> > this
> > > when a composite ID contains an association. This would require changes
> > in
> > > some SPIs though, to account for the disassembled ID type.
> > >
> > > I've been discussing necessary changes with Scott to cache a
> > > disassembled ID. Before we get too far down this road, I'd like to get
> 

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

[Steve Ebersole]

This all sounds s familar.  But I was not able to find the Jira.

Seems to be there was a reason that we don't disassemble the id, though
that reason escapes me atm.  That does seem like the logical thing to do.
Regardless of why I think we may have decided not to, it would still be
interesting to see if you could make that work

On Wed, Dec 4, 2019 at 1:40 PM Gail Badner  wrote:

> When an entity is cached with a composite ID containing a many-to-one
> association, the cache key will contain the many-to-one associated entity.
> If the associated entity is not enhanced, then it could be an uninitialized
> proxy.
>
> I've created a test case [1] that illustrates this using Infinispan. The
> test case is for 5.1 branch, since hibernate-infinispan is still included
> in that branch. The same would happen for master as well.
>
> Aside from the obvious issue with increased memory requirements to store an
> entity, there are other problems as well.
>
> What I've found so far is that caching a key with an uninitialized entity
> proxy can cause some big problems:
>
> 1) A lookup will never find this key unless the lookup is done with a cache
> key containing the same entity proxy instance.
>
> 2) Calling EntityManager#find with a composite ID containing a detached
> uninitialized entity proxy will result in a LazyInitializationException.
> This does not happen with second-level cache disabled.
>
> 3) Calling EntityManager#find with a composite ID containing a managed
> uninitialized entity proxy will result in the proxy being initialized. This
> does not happen with second-level cache disabled.
>
> I have not looked into what happens when the associated entity is enhanced
> and uninitialized (i.e., enhancement-as-proxy).
>
> IIUC, disassembling the ID that gets stored in the cache key would be far
> more efficient, and would avoid these issues. We would only want to do this
> when a composite ID contains an association. This would require changes in
> some SPIs though, to account for the disassembled ID type.
>
> I've been discussing necessary changes with Scott to cache a
> disassembled ID. Before we get too far down this road, I'd like to get some
> feedback.
>
> In the first place, should an entity instance be stored in a cache key?
>
> Is disassembling primary keys that contain an association the appropriate
> way to go? If so, I'll continue with a POC for doing this.
>
> Thanks,
> Gail
>
> [1]
>
> https://github.com/gbadner/hibernate-core/blob/753e36edf5137296d28b2a07cee3daffc16c6d1e/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysWithEagerEntityFactoryTest.java
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] ORM 6.0.0 Alpha3 released

[Steve Ebersole]

The third Alpha of ORM 6.0 has just been released.  See the details at
https://in.relation.to/2019/11/24/600-Alpha3-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Planning next 6.0 Alpha

[Steve Ebersole]

Andrea and I talked this morning about where we are with 6.0 development
and planning the next Alpha as well as moving the work branch back
upstream.  Next week we will see how far we are on the tasks we are
currently working on.  The triggers for the release/move are:

   1. WRT inheritance, SINGLE_TABLE and TABLE_PER_CLASS are implemented,
   though TABLE_PER_CLASS is somewhat hacked.  Either add support for JOINED,
   or finish up TABLE_PER_CLASS support
   2. Support for all "model part" mappings should be implemented in the
   mapping model (though its ok for ANY to slide).  Currently only to-one and
   ANY-mappings are the only ones missing and Koen has started working on
   to-ones already.
   3. Conversion of LoadPlans to use the new mapping model.  LoadPlans are
   what gets used for any direct loading of an entity or collection via
   loading, subsequent fetching, etc.  This would unify both Query and loading
   to use the SQL AST approach.  At that point the walking model that
   LoadPlans currently use would no longer be used at all internally so we
   should discuss removal of those contracts.  That may need to simply be
   deprecated for now and removed later, but at the least we should offer a
   way to enable/disable the actual generation of that model for performance
   (boot-time time-based performance as well as runtime performance by
   reducing memory usage).  Another option would be to try to have the mapping
   model also implement the walking model contracts; no idea yet how feasible
   that is.

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

Re: [hibernate-dev] "JDK: oraclejdk8 Java" check is failing for a PR

[Steve Ebersole]

Nice!

On Tue, Oct 15, 2019, 5:57 PM Gail Badner  wrote:

> It passed this time. :)
>
> On Tue, Oct 15, 2019 at 2:51 PM Gail Badner  wrote:
>
>> OK, I see it now.
>>
>> Thanks!
>> Gail
>>
>> On Tue, Oct 15, 2019 at 2:24 PM Steve Ebersole 
>> wrote:
>>
>>> Yes, in the upper right end corner there is a "Restart Job" link...
>>> That's for any Travis job
>>>
>>> On Tue, Oct 15, 2019 at 1:20 PM Gail Badner  wrote:
>>>
>>>> "JDK: oraclejdk8 Java" check is failing [1] for PR:
>>>> https://github.com/hibernate/hibernate-orm/pull/3066
>>>>
>>>> It's showing that OsgiIntegrationTest is failing. I can't reproduce this
>>>> locally, but maybe I'm not using the same version of
>>>>
>>>> Has anyone else seen this before?
>>>>
>>>> Is there a way to repeat the job to see if it is transient?
>>>>
>>>> Thanks,
>>>> Gail
>>>>
>>>> [1] https://travis-ci.org/hibernate/hibernate-orm/jobs/597997496
>>>> ___
>>>> 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] "JDK: oraclejdk8 Java" check is failing for a PR

[Steve Ebersole]

Yes, in the upper right end corner there is a "Restart Job" link...  That's
for any Travis job

On Tue, Oct 15, 2019 at 1:20 PM Gail Badner  wrote:

> "JDK: oraclejdk8 Java" check is failing [1] for PR:
> https://github.com/hibernate/hibernate-orm/pull/3066
>
> It's showing that OsgiIntegrationTest is failing. I can't reproduce this
> locally, but maybe I'm not using the same version of
>
> Has anyone else seen this before?
>
> Is there a way to repeat the job to see if it is transient?
>
> Thanks,
> Gail
>
> [1] https://travis-ci.org/hibernate/hibernate-orm/jobs/597997496
> ___
> 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] Rebased ORM6

[Steve Ebersole]

We went ahead and finished the remaining merges and pushed to
https://github.com/sebersole/hibernate-core/tree/wip/6.0

To be clear - this branch includes everything from master (as of this
morning) and all ongoing 6.0 work.

On Wed, Sep 4, 2019 at 8:08 AM Steve Ebersole  wrote:

> Andrea and I took a look at this `SessionImpl#buildLockOptions` as you
> asked.  But unfortunately your work moved the logic completely around,
> moving it from a no-longer-existent method into a static method on a new
> helper class you added.  So its hard to compare what functionally changed.
>
>
> On Fri, Aug 30, 2019 at 2:57 PM Sanne Grinovero 
> wrote:
>
>> I've completed a rebase of Steve's latest ORM6 branch onto our latest ORM5
>> master, so to have it incorporate all latest bugfixes and performance
>> enhancements we recently developed on master.
>>
>> To be more specific, this is a rebase of commit
>> 'wip/sqm-jpa-types-sql-ast'
>> [2e002c73c6] onto 'master' [40b30fa099].
>>
>> I'm pushing it as branch '6-rebased-August' to my own fork. (commit
>> [ec3a325fbc]).
>>
>> I hope that anyone having some work in progress could cherry pick on top
>> of
>> that :)
>> Also you probably want to push it somewhere else and give a more creative
>> name.
>>
>> Steve: the last commit might need special attention.
>>
>> I needed to review the SessionImpl#buildLockOptions method as there was a
>> conflict, but while trying to resolve it I realized the method was
>> probably
>> not doing what it was supposed to, so I changed it - I think fixing
>> something odd but I might have misunderstood the intent, or thrown off by
>> some mistake during rebase. Would appreciate another pair of eyes on that
>> one as I definitely changed the semantics.
>>
>> Thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Rebased ORM6

[Steve Ebersole]

Andrea and I took a look at this `SessionImpl#buildLockOptions` as you
asked.  But unfortunately your work moved the logic completely around,
moving it from a no-longer-existent method into a static method on a new
helper class you added.  So its hard to compare what functionally changed.


On Fri, Aug 30, 2019 at 2:57 PM Sanne Grinovero  wrote:

> I've completed a rebase of Steve's latest ORM6 branch onto our latest ORM5
> master, so to have it incorporate all latest bugfixes and performance
> enhancements we recently developed on master.
>
> To be more specific, this is a rebase of commit 'wip/sqm-jpa-types-sql-ast'
> [2e002c73c6] onto 'master' [40b30fa099].
>
> I'm pushing it as branch '6-rebased-August' to my own fork. (commit
> [ec3a325fbc]).
>
> I hope that anyone having some work in progress could cherry pick on top of
> that :)
> Also you probably want to push it somewhere else and give a more creative
> name.
>
> Steve: the last commit might need special attention.
>
> I needed to review the SessionImpl#buildLockOptions method as there was a
> conflict, but while trying to resolve it I realized the method was probably
> not doing what it was supposed to, so I changed it - I think fixing
> something odd but I might have misunderstood the intent, or thrown off by
> some mistake during rebase. Would appreciate another pair of eyes on that
> one as I definitely changed the semantics.
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] EntityMetamodel

[Steve Ebersole]

Seems like we dropped the need for the subclass checking here but did not
remove passing that Function.  Technically it could be removed and the
EntityMetamodel
constructor reverted

On Mon, Sep 2, 2019 at 9:14 PM Gail Badner  wrote:

> HHH-11147 changed a EntityMetamodel constructor argument from
> a SessionFactoryImplementor to a PersisterCreationContext.
>
> Would a custom EntityPersister break due to calling the constructor with
> the new argument type?
>
> From what I can tell, the argument was changed to PersisterCreationContext
> go get access to an entity's metamodel, intended to be used
> by EnhancementHelper.includeInBaseFetchGroup.
>
> The Function subclassChecker is passed to:
> * BytecodeEnhancementMetadataPojoImpl.from
> * LazyAttributesMetadata.from
> * EnhancementHelper.includeInBaseFetchGroup
>
> EnhancementHelper.includeInBaseFetchGroup does not use the value passed in
> for hasSubclassChecker.
>
> Can the EntityMetamodel constructor be changed back to take a
> SessionFactoryImplementor?
>
> Can the hasSubclassChecker argument be removed from
> BytecodeEnhancementMetadataPojoImpl.from, LazyAttributesMetadata.from, and
> EnhancementHelper.includeInBaseFetchGroup?
>
> Thanks,
> Gail
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Property#isLazy

[Steve Ebersole]

Do you have an example where this is actually a problem?

On Mon, Sep 2, 2019 at 8:01 PM Gail Badner  wrote:

> HHH-11147 changed Property#isLazy as shown in [1].
>
> The part that concerns me is:
>
> + // For a many-to-one, this is always false.  Whether the
> + // association is EAGER, PROXY or NO-PROXY we want the fk
> + // selected
> + return false;
>
> I don't think this is correct when enhancement-as-proxy is disabled.
>
> Join#isLazy relies on Property#isLazy for the properties included in the
> Join.
>
> If Join#isLazy is returning the wrong value,
> then SingleTableEntityPersister#isSubclassTableLazy
> and JoinedSubclassEntityPersister#isSubclassTableLazy will return the wrong
> value.
>
> Steve, WDYT?
>
> Thanks,
> Gail
>
> [1]
> https://github.com/hibernate/hibernate-orm/commit/cc01f2561dbca95bd58048f85e283ba1719ee588#diff-f564326e8dae92695cdffe6509fb8f0b
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] No default implementation for PersistenceContext#addEnhancedProxy

[Steve Ebersole]

We do not support an application implementing a custom PersistenceContext.

I'm not against adding a default, but most likely that default would be a
"throw an exception" type which I am not sure is useful

On Mon, Sep 2, 2019 at 4:19 PM Gail Badner  wrote:

> HHH-11147 added PersistenceContext#addEnhancedProxy without a default
> implementation.
>
> Would an application implement PersistenceContext? If so, this would be a
> breaking change.
>
> Please let me know...
>
> Thanks,
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] hibernate.id.optimizer.pooled.preferred=hilo or legacy-hilo

[Steve Ebersole]

In my opinion we really should not drop them unless we also write a
conversion for the existing I'd values in the database to account for the
new scheme the user picks.  It's really just left there to allow these
legacy databases keep working

On Wed, Aug 28, 2019 at 7:09 AM Steve Ebersole 
wrote:

> In my opinion we really should not drop them unless we also write a
> conversion for the existing I'd values in the database to account for the
> new scheme the user picks.  It's really just left there to allow these
> legacy databases keep working
>
> On Wed, Aug 28, 2019, 12:08 AM Gail Badner  wrote:
>
>> Hi,
>>
>> The documentation for hibernate.id.optimizer.pooled.preferred says the
>> following:
>>
>> hilo; legacy-hilo
>>
>> Define a custom algorithm for generating pools of values based on a single
>> value from a table or sequence.
>>
>> These optimizers are not recommended for use. They are maintained (and
>> mentioned) here simply for use by legacy applications that used these
>> strategies previously.
>>
>> Will these settings be supported long-term, or are there plans to
>> deprecate/remove them?
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Entity implementation of equals()

[Steve Ebersole]

There are 2 different discussions here:

1) How to implement `#equals` to account for HibernateProxy
2) How to implement `#equals` in a MappedSuperclass

These things are at odds here.

With regards to (1), as discussed above, you have to allow subclasses in
the equality comparison *if* you want to use proxy-based laziness.  Is
there a specific discussion about that?  Well there is, or used to be, an
entire section in the documentation about implementing `#equals` properly.
I do not remember whether it mentions this "allow subclasses"
specifically.  However it is common sense given the documented way that
proxy-based laziness works.

The real problem here is that the MappedSuperclass is defined "above" the
root entities in the hierarchy and the user is trying to define the
comparison there.  Allowing subclass matching there means that any entity
type would equal any other entity types, even entities in a different
entity hierarchy.  E.g. say Customer and Order are both root entities and
extend a common MappedSuperclass named BaseEntity - if BaseEntity defines
`#equals` to allow subclasses to match then a Customer would equal an Order
which is clearly wrong.

As far as using getters in the `#equals` impl to account for laziness... I
do not know if it is specifically documented somewhere, but again that's
just common sense.

Note that these in particular could be handled via the new "bytecode proxy"
feature. There would be no HibernateProxy involved and access to getters
*or fields* would trigger the load. Just a thought



On Tue, Aug 27, 2019, 11:18 PM Gail Badner  wrote:

> Please see below...
>
> On Tue, Aug 27, 2019 at 8:00 PM Jan-Willem Gmelig Meyling <
> jan-wil...@youngmediaexperts.nl> wrote:
>
>> I tend to use this.getClass().isInstance(o) and this.getClass().cast(o)
>> which works even in a mapped super class on most occasions. (Assuming that
>> the proxy delegates equals to a concrete target).
>>
>
> Your suggestion worked to get past the class comparison.
>
> There is still an issue though when comparing to a HibernateProxy.
>
> This returns false: bID.equals( that.bID).
>
> This returns true: bID.equals( that.getbID() ).
>
> I've never noticed this before.
>
> Steve, is there some requirement that getters have be used to compare
> properties when an entity can be lazy?
>
>
>>
>> Jan-Willem
>>
>>
>> > Op 27 aug. 2019 om 22:29 heeft Steve Ebersole 
>> het volgende geschreven:
>> >
>> > Generally speaking an `#equals` method would not allow subclasses to
>> > match.  For entity mappings specifically I this it is generally
>> considered
>> > kosher to allow subclass matching in `#equals`.  Interestingly, when
>> > generating `#equals` overrides through IntelliJ it even asks
>> specifically
>> > whether subclasses should be allowed to match.  In fact it mentions (or
>> > used to mention) Hibernate specifically wrt proxies in the dialog.
>> >
>> > And it's actually required (as you found) if you want to use Hibernate's
>> > proxy-based lazy loading.
>>
>
> It makes sense, but I don't remember reading it. Is this documented
> somewhere?
>
> HHH-13590 specifically has to do with an entity's #equals(Object o) with o
> being a HibernateProxy.
>
> The fix unproxies the HibernateProxy, so that the argument to
> #equals(Object o) is the target (not a HibernateProxy).
>
> Thanks,
> Gail
>
> >
>> > However, this is a case with a MappedSuperclass and specifically a
>> > MappedSupperclass that is I guess shared amongst multiple root entities.
>> > So here the allowance of subclasses is not really feasible and relying
>> on
>> > any kind of equality checking defined on the MappedSuperclass is not
>> going
>> > to work
>> >
>> >> On Tue, Aug 27, 2019 at 6:49 PM Gail Badner 
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'm looking into the impact of HHH-13590.
>> >>
>> >> In the test for HHH-13590, I see that the mapped superclass entity
>> defines
>> >> equals() as:
>> >>
>> >> @Override
>> >> public boolean equals(Object o) {
>> >>   if (this == o) return true;
>> >>   if (o == null || getClass() != o.getClass()) return false;
>> >>
>> >>   ...
>> >>
>> >> }
>> >>
>> >> Due to the bug:
>> >> * this is a Project instance;
>> >> * o is a HibernateProxy with target == this.
>> >>
>> >> Because the getClass() != o.getClass(), false is returned, and that
>> 

Re: [hibernate-dev] Entity implementation of equals()

[Steve Ebersole]

Generally speaking an `#equals` method would not allow subclasses to
match.  For entity mappings specifically I this it is generally considered
kosher to allow subclass matching in `#equals`.  Interestingly, when
generating `#equals` overrides through IntelliJ it even asks specifically
whether subclasses should be allowed to match.  In fact it mentions (or
used to mention) Hibernate specifically wrt proxies in the dialog.

And it's actually required (as you found) if you want to use Hibernate's
proxy-based lazy loading.

However, this is a case with a MappedSuperclass and specifically a
MappedSupperclass that is I guess shared amongst multiple root entities.
So here the allowance of subclasses is not really feasible and relying on
any kind of equality checking defined on the MappedSuperclass is not going
to work

On Tue, Aug 27, 2019 at 6:49 PM Gail Badner  wrote:

> Hi,
>
> I'm looking into the impact of HHH-13590.
>
> In the test for HHH-13590, I see that the mapped superclass entity defines
> equals() as:
>
> @Override
> public boolean equals(Object o) {
>if (this == o) return true;
>if (o == null || getClass() != o.getClass()) return false;
>
>...
>
> }
>
> Due to the bug:
> * this is a Project instance;
> * o is a HibernateProxy with target == this.
>
> Because the getClass() != o.getClass(), false is returned, and that
> ultimately causes the test to fail.
>
> The fix for HHH-13590 results in comparing a Project instance with itself
> (not the proxy).
>
> I see that the documentation has a similar implementation of equals() in
> "Example 111. Natural Id equals/hashCode" of [1].
>
> In general, is it OK for equals() to require both instances to be of the
> same class?
>
> Thanks,
> Gail
>
> [1]
>
> https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#mapping-model-pojo-equalshashcode
> ___
> 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] ConnectionObserver

[Steve Ebersole]

I'm fine with deprecating and removing.

WRT changing `List` to just `ConnectionObserver` rather
we'd want to change it to `ConnectionObserverStatsBridge` to avoid the
polymorphic call overhead.  But otherwise I agree with everything

On Tue, Aug 20, 2019 at 3:51 PM Gail Badner  wrote:

> In 4.2 and 4.3, it was possible to add a ConnectionObserver
> using
> org.hibernate.engine.jdbc.spi.LogicalConnectionImplementor#addObserver(ConnectionObserver
> observer).
>
> Starting in 5.0, LogicalConnectionImplementor was moved
> to org.hibernate.resource.jdbc.spi, and it's no longer possible to add a
> ConnectionObserver.
>
> For now, I think it's OK to change JdbcObserverImpl#observers from a
> List, to:
>
> private final transient ConnectionObserver observer;
>
> Also, I'm fine with ConnectionObserver being deprecated, and later removed.
>
> Steve, WDYT?
>
>
> On Tue, Aug 20, 2019 at 10:55 AM Sanne Grinovero 
> wrote:
>
> > While refactoring some related optimisations, I noticed there's
> > currently no way to register a custom ConnectionObserver.
> >
> > There seems to be only one implementation, which is registered by
> default:
> >  -
> >
> org.hibernate.internal.ConnectionObserverStatsBridge#ConnectionObserverStatsBridge
> >
> > Some questions:
> >
> > # Is this expected?
> >
> > # Should we deprecate the SPI so to make this more explict in the
> > future, and possibly eventually discuss removing it?
> >
> > # Since I'm working on performance optimisations, may I take advantage
> > currently of the fact that there's only one registered? We're
> > currently iterating "the list of obeservers"...
> >
> > Thanks
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Any external uses for ORM's StatisticsImpl ?

[Steve Ebersole]

I do not remember the history for it.

+1 for removing that no-arg form.

On Wed, Aug 7, 2019 at 4:08 AM Sanne Grinovero  wrote:

> Hi all,
>
> while working on HHH-13527 I noticed that there's quite some
> complexity in StatisticsImpl to deal with the fact that the final
> field `sessionFactory` could be null in some cases.
>
> This field can only be null if its public no-argument constructor is
> invoked, yet there is no code in whole of ORM invoking this.
>
> I'm therefore tempted to remove this constructor and cleanup all those
> checks for null; anybody knows why that constructor was explicitly
> marked to stay with @SuppressWarnings({ "UnusedDeclaration" })  ?
>  -
> https://github.com/hibernate/hibernate-orm/blob/a26b971d434453be482e7675fc8e9884c8f791e0/hibernate-core/src/main/java/org/hibernate/stat/internal/StatisticsImpl.java#L108-L111
>
> Suggesting this change for 5.4 (and beyond) only.
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Test FormulaWithPartitionByTest seems to rely on implementation specific ordering

[Steve Ebersole]

The query is selecting ids, so I assume you mean `1,2,3` as the
expectation.

Clearly Firebird cannot support what the query is attempting to do - so the
best option is to skip this test for Firebird.  However, the order-by is
really not serving any purpose to the test aside from making the assertions
easier; so another option would be to remove the order-by and assert the
results via iterating them.

On Sat, Jun 22, 2019 at 3:19 AM Mark Rotteveel  wrote:

> The test FormulaWithPartitionByTest against Firebird 3 fails because the
> returned result has a different order than the one expected by the test.
>
> As far as I can tell, the order expected by the test is arbitrary or at
> least, as far as I can tell, the order expected is not necessarily
> required by the SQL standard (although it might as well be a bug in
> Firebird, I'm just not sure).
>
> The testdata is
> (ID, DISCOUNT_CODE, DISCOUNT_VALUE)
> (1, "20", 12.34)
> (2, "20", 15.89)
> (3, "100", 12.5)
>
> With generated query:
>  select
>  formulawit0_.id as id1_0_,
>  formulawit0_.DISCOUNT_CODE as DISCOUNT_CODE2_0_,
>  formulawit0_.DISCOUNT_VALUE as DISCOUNT_VALUE3_0_,
>  ROW_NUMBER() OVER( PARTITION
>  BY
>  formulawit0_.DISCOUNT_CODE
>  ORDER BY
>  SIGN(formulawit0_.DISCOUNT_VALUE) DESC ) as formula0_
>  from
>  DisplayItem formulawit0_
>  order by
>  formulawit0_.id
>
> The expected order of the row_number() is 1, 2, 1 but due to the
> evaluation order in Firebird of order by in window functions and the top
> level order by, the resulting order is 2, 1, 1.
>
> I can see four solutions for this:
>
> 1. Just ignore the test for Firebird 3
> 2. Add a Firebird specific expectation of order (although that would be
> testing what is likely an implementation artifact)
> 3. Enforce a more specific order in the window function by changing the
> order by to ORDER BY SIGN(DISCOUNT_VALUE) DESC, ID
> 4. Enforce an order by that is consistent with the data: ORDER BY
> DISCOUNT_VALUE (the use of SIGN with the shown data can lead to an
> arbitrary order as the result is always 1).
>
> What would have your preference?
>
> Mark
> --
> Mark Rotteveel
> ___
> 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] Post-connect queries for 6.1?

[Steve Ebersole]

Add a feature request to Jira I guess.  Of course you can already achieve
this using a custom ConnectionProvider and most connection pools allow such
things.  For me personally this is not a critical feature.

On Mon, May 13, 2019 at 7:57 AM Jordan Gigov  wrote:

> I thought it would be good to have an API that will call any registered
> queries upon connecting to the database, and maybe ones before returning it
> to the connection pool.
> I'm thinking it should be called in the implementations of
> ConnectionProvider
> and MultiTenantConnectionProvider.
>
> The basic purpose would be so you can set certain parameters. For example
> in setting the timezone in PostgreSQL:
>
> SET SESSION TIME ZONE 'UTC';
>
> Or in MySQL:
>
> SET SESSION time_zone = 'Europe/Berlin';
>
> This would of course require dialect handling, and access to some of the
> configuration settings given to the SessionFactory.
> There should also be a way for users to customize these with a
> per-persistence-unit configuration of some sort. They might want to pass
> other such runtime tweaks.
> Someone may want to send something like this to their MySQL:
>
> SET SESSION sql_mode = 'TRADITIONAL,ANSI';
>
> I realize it's too late to think about this for 6.0, but it's something to
> consider for later on.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-11147 - bytecode based "proxies"

[Steve Ebersole]

Over the last 3 weeks or so, we have put a lot of work into HHH-11147 which
essentially allows bytecode enhancement to behave like the more traditional
proxy feature (create a reference based solely on the entity id).

We are wrapping up development of that improvement, enhancement, change,
whatever-you-want-to-call-it...  One remaining question however is how to
make this change available in terms of releases.  It seems to big of a deal
to simply drop in a new bug-fix release.

Should we consider a 5.5 release?  Push it to 6?  Thoughts?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jenkins upgrade

[Steve Ebersole]

Thanks guys!

On Tue, Apr 30, 2019 at 8:07 AM Davide D'Alto  wrote:

> On a related note, I've created a new AMI to use as slave and
> configure Jenkins to use it.
> If there are issues, it is still possible to use the old one  by
> updating the Jenkins configuration (http://ci.hibernate.org/configure)
> to the AMI ID we used before (custom fedora v23).
>
> Cheers,
> Davide
>
> On Tue, Apr 30, 2019 at 11:46 AM Yoann Rodiere 
> wrote:
> >
> > Hello,
> >
> > TL;DR: I just updated Jenkins and its plugins. If things stop working
> > correctly, please let me know.
> >
> > Some details below, in case I'm not here when things start to break
> down...
> >
> > I updated Jenkins and its plugins to the latest versions, hoping to fix
> the
> > problem we've been having lately where we would only ever get a single
> EC2
> > slave.
> >
> > The result was an AWS EC2 plugin that started many, many EC2 slaves, but
> on
> > the Jenkins side mapped all slaves to the same URL, which resulted in
> > multiple builds running concurrently on the same EC2 instance, which
> > obviously resulted in many failures.
> >
> > I rolled back the AWS EC2 plugin from 1.42 to 1.39 (like I had to do a
> few
> > weeks ago), and things to be back to normal. It even works better than
> > before I attempted the upgrade: the plugin correctly spawns multiple
> slaves
> > as required.
> >
> > Frankly I don't understand what is going on, but it works again so I'll
> > stop touching it. I suppose I should take the time to investigate,
> attempt
> > to reproduce the problem and report it to the plugin maintainers. I
> > currently do not have a few days to spare for that, so it'll wait...
> >
> > For the record, I also had to do the following during the upgrade:
> >
> >- I had to update the AWS permissions for the EC2 plugin:
> >
> https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin#AmazonEC2Plugin-Version1.41(Oct24th,2018)
> >- I had to install a plugin to ensure running builds are no longer
> >allowed to do whatever they want (~root permissions):
> >
> https://jenkins.io/doc/book/system-administration/security/build-authorization/
> >
> > Cheers,
> >
> >
> > Yoann Rodière
> > Hibernate NoORM Team
> > yo...@hibernate.org
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [ORM] Do we have a way to check if an object is an entity?

[Steve Ebersole]

That's going to depend on which "bootstrap" they use.  JPA defines 2 which
it terms "SE" and "EE".  Not sure this will work in all EE bootstrap
environments, but you have:


PersistenceProviderResolver resolver =
PersistenceProviderResolverHolder.getPersistenceProviderResolver();
List providers = resolver.getPersistenceProviders();


On Thu, Apr 25, 2019 at 1:25 PM Guillaume Smet 
wrote:

> On Thu, Apr 25, 2019 at 8:05 PM Steve Ebersole 
> wrote:
>
>> EMF + Metamodel are standard JPA contracts:
>>
>> 
>> try {
>> emf.getMetamodel().managedType( theClass );
>> }
>> catch ( IllegalArgumentException e ) {
>> // JPA defined exception if the passed class is not a managed type
>> }
>>
>> Again, that will (should) work on any provider
>>
>
> Thanks.
>
> So I was pretty sure it would work with any provider. My question was
> more: how to make it work with multiple providers? Right now, the current
> implementation is very low level and doesn't use anything but JPA to get
> the EMF. But I didn't see any way to get all the potentially created EMF.
>
> I suppose I could try to get all the EMF from CDI - that would make this
> feature CDI-compatible only but I suppose it's acceptable. I will probably
> will need to do that after everything is initialized or I will have a
> chicken and egg problem as the EMF needs to get the ValidatorFactory. The
> thing is that, in this case, all the EMF should be created via CDI or it
> won't work very well.
>
> Collecting once and for all all the managed types via
> emf.getMetamodel().getManagedTypes() should work.
>
> @Gunnar Morling  does it make sense to you too?
>
> --
> Guillaume
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [ORM] Do we have a way to check if an object is an entity?

[Steve Ebersole]

EMF + Metamodel are standard JPA contracts:


try {
emf.getMetamodel().managedType( theClass );
}
catch ( IllegalArgumentException e ) {
// JPA defined exception if the passed class is not a managed type
}


Again, that will (should) work on any provider

On Thu, Apr 25, 2019 at 1:01 PM Guillaume Smet 
wrote:

> Hi,
>
> In Hibernate Validator, we have a TraversableResolver which avoids to
> validate the uninitialized properties of an entity.
>
> This is done in
>
> https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/engine/resolver/JPATraversableResolver.java#L35
> and, as you can see, we execute Persistence.getPersistenceUtil().isLoaded(
> traversableObject, traversableProperty.getName() ) even if the
> traversableObject has nothing to do with Hibernate ORM.
>
> I'm looking for an API that could tell me if an object is a class
> potentially managed by ORM (be it an entity, an embeddable or whatever: any
> class potentially containing a lazy field).
>
> I was thinking that maybe injecting an EntityManagerFactory (it would
> require CDI though) and using the Metamodel could somehow work... but the
> PersistenceUtil API we currently use is capable of dealing with several
> persistence providers and I don't think the injected EntityManagerFactory
> approach will fly in this case.
>
> Is there something I could use to do that, that would be portable and cover
> the cases currently (somehow) taken care of?
>
> Any ideas welcome.
>
> Thanks!
>
> --
> Guillaume
> ___
> 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] Make Gradle plugin available on plugins.gradle.org? (HHH-13354)

[Steve Ebersole]

It would need to be published differently than the rest of the modules (or
an extra additional publish).  It is a good idea though

On Tue, Apr 9, 2019 at 9:15 AM Sanne Grinovero  wrote:

> Hi Gail,
>
> I'm familiar with the Gradle plugin portal, happy to look into this.
> Thanks for highlighting this one!
>
> I'll be off for travelling and conferences the next two weeks. If
> anyone needs this earlier, feel free to take the issue but le me know
> :)
>
> Thanks,
> Sanne
>
>
> On Tue, 9 Apr 2019 at 04:36, Gail Badner  wrote:
> >
> > An issue was opened to make Gradle plugin available on
> plugins.gradle.org.
> >
> > Should this be done? If so, how?
> >
> > Regards,
> > Gail
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - multi-table mutations

[Steve Ebersole]

On Tue, Mar 26, 2019 at 10:17 AM Sanne Grinovero 
wrote:

>
> Why should we not?
>

There is a very compelling reason for that.  I'll have to leave it at that.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - multi-table mutations

[Steve Ebersole]

On Tue, Mar 26, 2019 at 9:57 AM Sanne Grinovero  wrote:

> One question: could we benefit from "cascade delete" rules defined in
> the table structure?


> If Hibernate ORM was able parse the cascading rules from existing
> schemas, and possibly generate them for new schemas, you could have an
> entire crop of additional such optimisations. I'm not sure if I'm
> talking about material for ORM 7+ but if you could make sure that such
> future optimisations aren't ruled out that would be awesome :)
>

Good point.

We actually do already have some limited support for cascading FKs in ORM -
`org.hibernate.annotations.OnDelete`.  And it is exported to the database
if defined.  We do not (nor should we) parse this information from the
existing schema.

What you are asking about specifically would require us to round out that
support (secondary tables at least are not yet supported) and of course to
leverage that in the HQL bulk deletion handlers.  Not impossible or even
particularly difficult - but enough work that I'd rather that be handled
somewhere post-6.0
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - multi-table mutations

[Steve Ebersole]

https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/6.2E0.20-.20multi-table.20mutation

On Tue, Mar 26, 2019 at 8:25 AM Steve Ebersole  wrote:

> While working on 6 I discovered that we maybe do not do the best job in
> regards to "bulk update/delete" queries against multi-table entities
> (secondary tables, joined inheritance, etc).  This short-coming exists in
> previous versions.  Essentially, when a strategy is not explicitly
> specified we fallback to using an "id table" and performing the SQL updates
> or deletes using the id table as a sub-query.  The problem is that for some
> databases this breaks when the ids are composite due to the database not
> having complete support for tuples.  For example, H2 does not allow the
> sub-query for an in-predicate to return more than one column: so a query
> like `... where (id1, id2) in (select val1, val2 from ...)` will not work.
> This tuple concern is something I had not considered when I first wrote
> this feature.
>
> Obviously with 6 we have a chance to improve this.  So I have been
> thinking about some ways this might be improved.  The guiding principle
> here was to make this as implicit as possible...
>
> Because certain strategies will not work when the ids are composite, I
> think the first consideration is whether we want to allow the strategy to
> be definable per-entity.  The idea would be to allow for the most efficient
> strategy to be used generally (whatever that might be for the given
> app/database) but to pick an alternative strategy in cases where that
> "fallback" one will not work.  The Dialect should certainly play a part in
> this strategy selection.
>
> And lastly, we should consider whether it is beneficial to leverage these
> strategies when performing normal mutations (merge, persist, etc).  I think
> really this comes down to whether we think there is a benefit to handling
> these via CTE if the database supports that as opposed to sending
> individual updates or deletes against each table.
>
> Thoughts?
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] 6.0 - multi-table mutations

[Steve Ebersole]

While working on 6 I discovered that we maybe do not do the best job in
regards to "bulk update/delete" queries against multi-table entities
(secondary tables, joined inheritance, etc).  This short-coming exists in
previous versions.  Essentially, when a strategy is not explicitly
specified we fallback to using an "id table" and performing the SQL updates
or deletes using the id table as a sub-query.  The problem is that for some
databases this breaks when the ids are composite due to the database not
having complete support for tuples.  For example, H2 does not allow the
sub-query for an in-predicate to return more than one column: so a query
like `... where (id1, id2) in (select val1, val2 from ...)` will not work.
This tuple concern is something I had not considered when I first wrote
this feature.

Obviously with 6 we have a chance to improve this.  So I have been thinking
about some ways this might be improved.  The guiding principle here was to
make this as implicit as possible...

Because certain strategies will not work when the ids are composite, I
think the first consideration is whether we want to allow the strategy to
be definable per-entity.  The idea would be to allow for the most efficient
strategy to be used generally (whatever that might be for the given
app/database) but to pick an alternative strategy in cases where that
"fallback" one will not work.  The Dialect should certainly play a part in
this strategy selection.

And lastly, we should consider whether it is beneficial to leverage these
strategies when performing normal mutations (merge, persist, etc).  I think
really this comes down to whether we think there is a benefit to handling
these via CTE if the database supports that as opposed to sending
individual updates or deletes against each table.

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

Re: [hibernate-dev] Should we support out of date non-LTS Java versions?

[Steve Ebersole]

+1 to everything Yoann said.


On Wed, Feb 13, 2019, 5:42 AM Yoann Rodiere  wrote:

> Hi,
>
> I think we should make it clear that only LTS JVMs are actually supported,
> and non-LTS JVMs are only supported on a "best effort" basis, with some
> focus on the very latest non-LTS JVM.
> I doubt we have the appropriate resources to do anything more than that.
>
> To be more specific, I would see things this way:
>
>- We may remove compatibility with an LTS JVM in a major release.
>- We will always, systematically remove compatibility with older non-LTS
>JVMs in every major or minor release, except the very latest JVM (which
>might be a non-LTS): we don't even test them anymore, and we don't list
>them as compatible on our website.
>- We may remove compatibility with a non-LTS JVM in a micro release, but
>we try not to actively do it...
>
> Specifically in the case of your dependency removal in a micro: that
> doesn't seem very useful to users, and doesn't solve a bug, so I wouldn't
> do it. Also, changing dependencies in a micro doesn't feel quite right: I'd
> expect micros to be drop-in replacements, and I can imagine adding/removing
> dependencies to cause trouble in build tools/build configuration.
> But I wouldn't make it a hard rule, either: we may be forced to do it one
> day because of a bug, and such a small break is still better than a bug.
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
>
> On Wed, 13 Feb 2019 at 03:47, Sanne Grinovero  wrote:
>
> > Hi all,
> >
> > I just tested if we still need the dependency to
> > 'javax.activation:javax.activation-api:1.2.0' from Hibernate ORM /
> > master, as I was suspecting the original reasons to add it might be
> > out of date.
> >
> > I guessed almost right, as it turns out we don't need this dependency
> > for Java 11, nor it was ever needed for Java 8 either: it was
> > introduced to solve a specific Java 9 compatibility issue.
> >
> > I verified it's still needed for Java 9 compatibility. Personally that
> > makes me think I'd rather remove the dependency, people should no
> > longer use Java 9;
> >
> > Java 9 has been "out of support" since a while now: I expect people to
> > either be on the latest stable release Java 11 - or on the previous
> > stable release aka Java 8 (others might be toying with 12 and/or 13
> > but that's not relevant).
> >
> > Clearly since we have no more 5.x minor releases planned, I'm thinking
> > of dropping a JVM version in a micro (!) - but considering this is an
> > unsupported non-LTS JVM I'm not considering this to be an outrageous
> > idea as we'd normally treat such a suggestion.
> >
> > Please don't take this as nitpicking about removing a single
> > dependecy: that's easy enough for people to ignore and workaround by
> > re-adding it explicitly; it's more important to focus on us creating a
> > clear policy for the future.
> >
> > Can we establish how we'll treat support for any other future
> > non-Long-Term-Support JVM version?
> >
> > Next time we might have a more tricky issue, and I think we should
> > make our intentions and policy clear so to have freedom to drop
> > support for experimental Java releases as we see fit, provided they
> > are out of date.
> >
> > I couldn't test JDK 10 - but that doesn't matter as the details of
> > this specific issue are irrelevant to the main point of agreeing on a
> > general policy.
> >
> > Comments?
> >
> > Thanks,
> > Sanne
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Still an issue with Agroal when closing the pool

[Steve Ebersole]

Have we gotten any reply about this?

On Wed, Jan 23, 2019 at 8:58 AM Guillaume Smet 
wrote:

> Hello Luis,
>
> Any chance you could take a look at this one?
>
> I just got it again on my laptop and it happened quite frequently on our CI
> lately.
>
> AFAICS, it's always failing in the setting isolation test but it can be
> different test methods. Just had it for
> AgroalTransactionIsolationConfigTest > testSettingIsolationAsNumericString
> this time.
>
> --
> Guillaume
>
> On Sat, Jan 5, 2019 at 10:40 PM Guillaume Smet 
> wrote:
>
> > Hi Luis,
> >
> > We talked at some point about a potential issue in Agroal, you said 1.3
> > should have all the known issues solved but apparently, there is still
> one
> > as we have transient test failures on ORM from time to time.
> >
> > A good example is the following one:
> >
> >
> http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-javassist/lastCompletedBuild/testReport/org.hibernate.test.agroal/AgroalTransactionIsolationConfigTest/testSettingIsolationAsName/
> > (it's build #265, haven't found a way to get a stable URL from Jenkins)
> >
> > The issue is in this test:
> >
> org.hibernate.test.agroal.AgroalTransactionIsolationConfigTest.testSettingIsolationAsName
> > .
> >
> > And we have the following stacktrace when closing the pool:
> >
> > java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@189a0b8e
> rejected from io.agroal.pool.util.PriorityScheduledExecutor@2ded5d2e[Shutting
> down, pool size = 1, active threads = 0, queued tasks = 1, completed tasks
> = 2]
> >   at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> >   at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> >   at
> java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> >   at
> java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:533)
> >   at
> java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:622)
> >   at
> io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:46)
> >   at
> io.agroal.pool.util.PriorityScheduledExecutor.executeNow(PriorityScheduledExecutor.java:35)
> >   at
> io.agroal.pool.util.PriorityScheduledExecutor.shutdown(PriorityScheduledExecutor.java:67)
> >   at io.agroal.pool.ConnectionPool.close(ConnectionPool.java:126)
> >   at io.agroal.pool.DataSource.close(DataSource.java:54)
> >   at
> org.hibernate.agroal.internal.AgroalConnectionProvider.stop(AgroalConnectionProvider.java:142)
> >   at
> org.hibernate.testing.common.connections.BaseTransactionIsolationConfigTest.testSettingIsolationAsName(BaseTransactionIsolationConfigTest.java:101)
> >
> >
> > It happens once in a while. I already had the issue locally but lately I
> > only observed it on CI.
> >
> > I suppose it won't be easy to get to the bottom of it but it would be
> nice
> > if we could get this fixed.
> >
> > Thanks.
> >
> > --
> > Guillaume
> >
> ___
> 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] Loggers

[Steve Ebersole]

Following the recent post about boot logging and recent work on a new
"module" (criteria queries) in 6, I wanted to circle back to this with a
few thoughts.  Now that this approach has been in place for quite a while
and has been getting used we have a better feel for how this works in
practice.

One thing I realized is that the use of symbolic names for the loggers
allows us to extend the idea of a "supported API" to logging as well.  What
I mean by this is that logging config would work from one release to the
next because we are using symbolic names rather than class names.  Even if
we did extensive refactoring moving classes to different packages, renaming
classes, etc... the logger names would stay the same.  Which is not a small
thing.  From a document I am working on:

== Logger/category names

Symbolic name versus FQN as logger/category name

Pros::

* Easier to configure as a hierarchy (imo);
* Safe from refactoring - which seems minor, but it makes logging config
something we could support, just as if it were an API

Cons::

* Easy for classes to use FQN instead of symbolic name

I personally really like moving TRACE and DEBUG logging to using this
approach as well.  It has worked really well in testing.  Its is so much
nicer to enable logging for query handling using:

log4j.logger.org.hibernate.orm.query=debug
log4j.logger.org.hibernate.orm.sql=debug

compared to:

log4j.logger.org.hibernate.hql=debug
log4j.logger.org.hibernate.loader=debug
log4j.logger.org.hibernate.sql=debug
log4j.logger.org.hibernate.type=debug
...

To be clear, there are also categories "under" the ones I used in the
example.  E.g. to see "query logging" just for HQL you'd use the
`log4j.logger.org.hibernate.orm.query.hql` (which has additional categories
as well (`log4j.logger.org.hibernate.orm.query.sqm.hql.parse.tree`, etc).
I wanted to make sure everyone is on board with this before we get too far
down this path - using symbolic names for TRACE/DEBUG logging.

One last thing I forgot to mention earlier is that this does require
changing the message ids.  The range for these ids are defined as part of
the message logger (the interface) via annotation.  As we move messages to
a different (modular) logger class the id range has to change.  This only
affects (is only supposed to affect[1]) message loggers (INFO/WARN/ERROR),
not info logging (TRACE/DEBUG).


[1] Historically we have only used message loggers (with ids) for
INFO/WARN/ERROR.  Some of the more recent changes by Guillaume change that
a bit and moved a few message logger messages to be DEBUG.  I think this is
another thing we should nail down moving forward - do we want TRACE/DEBUG
logging to potentially be messaged (with id) logs?




On Fri, Sep 28, 2018 at 10:46 AM Sanne Grinovero 
wrote:

> On Fri, 28 Sep 2018 at 16:43, Steve Ebersole  wrote:
> >
> > Thanks for the feedback!
>
> I'm actually sorry for the delay :) Just back from 2 weeks off, catching
> up.
>
> > WRT effort, the plan is to make these changes as I do work in a
> particular area which is what I have been doing - not a "one shot, go back
> and change all logging".
>
> +1
>
> > WRT granularity, sure that would be a concern.  It really comes back to
> having a good "logical" design of the logger name hierarchy.
> >
> > WRT coordination, yep -
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/logger_id_ranges.adoc
>
> Awesome!
>
> Thanks,
> Sanne
>
> >
> > On Fri, Sep 28, 2018 at 10:35 AM Sanne Grinovero 
> wrote:
> >>
> >> Hi Steve,
> >>
> >> I love the cathegories idea; I think we discussed it before.  My only
> >> concern is that it's a lot of work to implement, but if you feel it's
> >> doable that's great.
> >>
> >> In terms of "changes needed" I'm not worried either. Like you said, 6
> >> would have had different names for most cases; at least moving forward
> >> such names would be more stable even if we decide to move some code in
> >> the future.
> >>
> >> One doubt is the granularity. I guess the risk is that maintainers
> >> will tend to reuse the same limited set of cathegories; we will need
> >> to make sure there are enough cathegories so that people can still
> >> enable the single aspect they might be interested in debugging, but
> >> maybe that's not important as people can always post-filter things
> >> when the output gets too verbose.
> >>
> >> We will need a way to coordinate on valid ranges for the various
> >> @ValidIdRange. Infinispan used a wiki for this; the upside is that
> >> it's out of the repository: a good thing to avoid reuse across repo
> >> branches - e.g. it's not ideal to

Re: [hibernate-dev] [ORM] Reducing startup log verbosity

[Steve Ebersole]

Sounds good to me! :)

On Fri, Jan 11, 2019 at 8:19 AM Sanne Grinovero  wrote:

> On Fri, 11 Jan 2019 at 14:00, Steve Ebersole  wrote:
> >
> > Guillaume - I added a general start-a-discussion comment to the PR.
> Hopefully anyone with an opinion on that can chime in there.  Beyond that,
> +1
> >
> >
> > Sanne - ok, I see.  You are not expecting users to have to deal with
> wrapping/scrolling because you limit the presented information to an
> arbitrary set of values.  That's certainly an option.  My only caution
> there is that this is an arbitrary list of values-of-interest.
> >
> > We all agree version is important.  It is beyond that that we start to
> have different preferences.  I think everything beyond that is DEBUG-level
> info.  For any additional values, I worry about the arbitrary nature of
> what we present and don't in this message.  I mean to me, the same argument
> that leads to "caching enabled/disabled" being important enough to list
> also dictates that CDI integration is important enough too.  Same for
> BytecodeProvider, ConnectionProvider, ...  Its this question of where we
> draw the line that concerns me.  And if we are drawing an arbitrary line,
> why are we drawing that line at all?
>
> Yeah it's arbitrary. When I proposed it I thought with some luck we
> might have a quick consensus; if not let's just stick to the version.
>
> > I'll eagerly await your discussion about enabling caching by default ;)
>
> Let's face that in front of some great food in Rome :)
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [ORM] Reducing startup log verbosity

[Steve Ebersole]

Guillaume - I added a general start-a-discussion comment to the PR.
Hopefully anyone with an opinion on that can chime in there.  Beyond
that, +1


Sanne - ok, I see.  You are not expecting users to have to deal with
wrapping/scrolling because you limit the presented information to an
arbitrary set of values.  That's certainly an option.  My only caution
there is that this is an arbitrary list of values-of-interest.

We all agree version is important.  It is beyond that that we start to have
different preferences.  I think everything beyond that is DEBUG-level
info.  For any additional values, I worry about the arbitrary nature of
what we present and don't in this message.  I mean to me, the same argument
that leads to "caching enabled/disabled" being important enough to list
also dictates that CDI integration is important enough too.  Same for
BytecodeProvider, ConnectionProvider, ...  Its this question of where we
draw the line that concerns me.  And if we are drawing an arbitrary line,
why are we drawing that line at all?

I'll eagerly await your discussion about enabling caching by default ;)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Default access type and MappedSuperclass

[Steve Ebersole]

Trying to make sure I understand.. so the report is just wrong?  Or is
there some difference in your model versus theirs?


On Thu, Jan 10, 2019 at 2:22 PM andrea boriero  wrote:

> yes also for the MappedSuperclass
>
> from:
>
> @MappedSuperclass
> public abstract class AbstractCatalogEntity {
> @Column( name = "CODE")
> private String code;
>
> @Column( name = "NAME")
> private String name;
> }
>
> @Entity
> public class CatalogEntity extends AbstractCatalogEntity {
> @Id
> private Long id;
> }
>
> I obtained :
>
> @Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor")
> @StaticMetamodel(AbstractCatalogEntity.class)
> public abstract class AbstractCatalogEntity_ {
>
> public static volatile SingularAttribute
> code;
> public static volatile SingularAttribute
> name;
>
> public static final String CODE = "code";
> public static final String NAME = "name";
>
> }
>
> @Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor")
> @StaticMetamodel(CatalogEntity.class)
> public abstract class CatalogEntity_ extends
> org.hibernate.userguide.model.AbstractCatalogEntity_ {
>
> public static volatile SingularAttribute id;
>
> public static final String ID = "id";
>
> }
>
>
>
>
> On Thu, 10 Jan 2019 at 11:52, Guillaume Smet 
> wrote:
>
> > The generated model of the MappedSuperclass?
> >
> > Because the one of the subclass is correct for sure.
> >
> > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero 
> > wrote:
> >
> >> I'm not sure I have fully understood the issue, the @Id may be not
> >> defined in the MappedSuperclass but for sure it must be in the
> subclasses
> >> extending it.
> >>
> >> I have tried and I can reproduce the issue only if I do not specify
> >> any @Id annotation in the subclass, but as soon as I add the @Id to a
> >> subclass of the MappedSuperclass the generated static metamodel is
> correct.
> >>
> >>
> >> On Thu, 10 Jan 2019 at 11:04, Guillaume Smet 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> We recently had this issue opened about us not choosing the right
> access
> >>> type for a mapped super class:
> >>> https://hibernate.atlassian.net/browse/HHH-12938 .
> >>>
> >>> Hibernate currently base the access type decision on the sole placement
> >>> of
> >>> the @Id annotation, which, in the case of a @MappedSuperclass might not
> >>> be
> >>> defined (this is the OP's case).
> >>>
> >>> I closed the issue explaining what we do and pointing a workaround but
> >>> the
> >>> OP rightfully replied with the JPA spec saying "The default access type
> >>> of
> >>> an entity hierarchy is determined by the placement of mapping
> annotations
> >>> on the attributes of the entity classes and mapped superclasses of the
> >>> entity hierarchy that do not explicitly specify an access type".
> >>>
> >>> I'm wondering if we should also consider the @Column annotations
> >>> placement
> >>> if there is no @Id annotation.
> >>>
> >>> If the answer is that it's already fixed in 6, it's all good for me :).
> >>>
> >>> Thoughts?
> >>>
> >>> --
> >>> Guillaume
> >>> ___
> >>> hibernate-dev mailing list
> >>> hibernate-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [ORM] Reducing startup log verbosity

[Steve Ebersole]

On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero 
wrote:

> On Thu, 10 Jan 2019 at 01:44, Steve Ebersole  wrote:
> >
> > I disagree that logging a single message is a better solution because
> that probably ends up wrapping multiple lines, just as your sample happened
> to do in the email.  IMO that is actually more difficult to read.
>
> Ok keep it in one line if you prefer. No strong preference on how it's
> presented, but I think it's a big mistake to hide essential
> diagnostics: "paste the logs" is often useful when helping someone; it
> gets much harder if you first have to change categories.
>

You are combining separate things here

First, *you* are the one that suggested doing it on one line unless I have
misunderstood.  My point is simply that practically speaking that will
either mean having to read wrapped lines (eww) or scroll horizontally
(double eww) to read this info.  If your desire is to continue present this
information anyway, then, well, what exactly are we changing?  Just making
it harder to read?

"Diagnostics".. interesting choice of word... if you are diagnosing
something that implies that there is a problem you are debugging...  but
here we are talking about boot-time informational logging.  Different
beasts.

If the distinction you are trying to make is that we want to see at a
glance what config Hibernate thinks it just processed versus what you think
it should be (was caching enabled, etc) - well, where do you draw the
line?  Because this gets back to my first point; if you log everything that
is "useful" in this single boot-time log message it is going to be
completely unreadable.


+1 those symbolic loggers are a great idea. But then please don't hide
> this information at least until we have those easier logger
> categories: Guillaume is set to patch 5.4x - which doesn't have them
> yet.
>

What I am doing in 6 has no bearing on this discussion.  Either we display
information or we don't - that is the crux of this discussion, not which
logger/category name we use.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Default access type and MappedSuperclass

[Steve Ebersole]

Hm, seems like the "AP delayed generation" approach is a possibility.  From
a quick search:

https://stackoverflow.com/questions/41874462/java-annotation-process-not-yet-generated-elements
https://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/RoundEnvironment.html#processingOver%28%29

Disclaimer - I have not tried this, just read about it...

On Thu, Jan 10, 2019 at 7:18 AM Steve Ebersole  wrote:

> This is one of the cases (there are others) where we do not completely
> follow the JPA spec.
>
> TBH I'm not really sure how we would address this in an annotation
> processor, though granted my knowledge of those APIs is limited.  But as I
> understand it we have to generate the metamodel class as we process the
> model class without knowledge of or access to other classes.  Specifically
> here, we see the MappedSuperclasss first as it is a superclass and the
> compiler needs to process it first.
>
> I had planned on re-looking at this in 7 to offer a non-AP solution to
> metamodel generation.  I don't think anything requires that we support this
> through an AP.
>
> There are other problems using an AP for this, namely it is extremely
> difficult to incorporate orm.xml info whether partial or complete.
>
> I guess a solution for now would involve somehow delaying the generation
> of the metamodel classes until the end of the AP cycle which (IIUC) would
> only really work with `proc:only`
>
> On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet 
> wrote:
>
>> The generated model of the MappedSuperclass?
>>
>> Because the one of the subclass is correct for sure.
>>
>> On Thu, Jan 10, 2019 at 12:44 PM andrea boriero 
>> wrote:
>>
>> > I'm not sure I have fully understood the issue, the @Id may be not
>> defined
>> > in the MappedSuperclass but for sure it must be in the subclasses
>> extending
>> > it.
>> >
>> > I have tried and I can reproduce the issue only if I do not specify
>> > any @Id annotation in the subclass, but as soon as I add the @Id to a
>> > subclass of the MappedSuperclass the generated static metamodel is
>> correct.
>> >
>> >
>> > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> We recently had this issue opened about us not choosing the right
>> access
>> >> type for a mapped super class:
>> >> https://hibernate.atlassian.net/browse/HHH-12938 .
>> >>
>> >> Hibernate currently base the access type decision on the sole
>> placement of
>> >> the @Id annotation, which, in the case of a @MappedSuperclass might
>> not be
>> >> defined (this is the OP's case).
>> >>
>> >> I closed the issue explaining what we do and pointing a workaround but
>> the
>> >> OP rightfully replied with the JPA spec saying "The default access
>> type of
>> >> an entity hierarchy is determined by the placement of mapping
>> annotations
>> >> on the attributes of the entity classes and mapped superclasses of the
>> >> entity hierarchy that do not explicitly specify an access type".
>> >>
>> >> I'm wondering if we should also consider the @Column annotations
>> placement
>> >> if there is no @Id annotation.
>> >>
>> >> If the answer is that it's already fixed in 6, it's all good for me :).
>> >>
>> >> Thoughts?
>> >>
>> >> --
>> >> Guillaume
>> >> ___
>> >> 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] Default access type and MappedSuperclass

[Steve Ebersole]

This is one of the cases (there are others) where we do not completely
follow the JPA spec.

TBH I'm not really sure how we would address this in an annotation
processor, though granted my knowledge of those APIs is limited.  But as I
understand it we have to generate the metamodel class as we process the
model class without knowledge of or access to other classes.  Specifically
here, we see the MappedSuperclasss first as it is a superclass and the
compiler needs to process it first.

I had planned on re-looking at this in 7 to offer a non-AP solution to
metamodel generation.  I don't think anything requires that we support this
through an AP.

There are other problems using an AP for this, namely it is extremely
difficult to incorporate orm.xml info whether partial or complete.

I guess a solution for now would involve somehow delaying the generation of
the metamodel classes until the end of the AP cycle which (IIUC) would only
really work with `proc:only`

On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet 
wrote:

> The generated model of the MappedSuperclass?
>
> Because the one of the subclass is correct for sure.
>
> On Thu, Jan 10, 2019 at 12:44 PM andrea boriero 
> wrote:
>
> > I'm not sure I have fully understood the issue, the @Id may be not
> defined
> > in the MappedSuperclass but for sure it must be in the subclasses
> extending
> > it.
> >
> > I have tried and I can reproduce the issue only if I do not specify
> > any @Id annotation in the subclass, but as soon as I add the @Id to a
> > subclass of the MappedSuperclass the generated static metamodel is
> correct.
> >
> >
> > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet 
> > wrote:
> >
> >> Hi,
> >>
> >> We recently had this issue opened about us not choosing the right access
> >> type for a mapped super class:
> >> https://hibernate.atlassian.net/browse/HHH-12938 .
> >>
> >> Hibernate currently base the access type decision on the sole placement
> of
> >> the @Id annotation, which, in the case of a @MappedSuperclass might not
> be
> >> defined (this is the OP's case).
> >>
> >> I closed the issue explaining what we do and pointing a workaround but
> the
> >> OP rightfully replied with the JPA spec saying "The default access type
> of
> >> an entity hierarchy is determined by the placement of mapping
> annotations
> >> on the attributes of the entity classes and mapped superclasses of the
> >> entity hierarchy that do not explicitly specify an access type".
> >>
> >> I'm wondering if we should also consider the @Column annotations
> placement
> >> if there is no @Id annotation.
> >>
> >> If the answer is that it's already fixed in 6, it's all good for me :).
> >>
> >> Thoughts?
> >>
> >> --
> >> Guillaume
> >> ___
> >> 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