[hibernate-dev] Hibernate ORM 5.2.13.Final has been released

[andrea boriero]

*For
details:http://in.relation.to/2018/02/07/hibernate-orm-5213-final-release
*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.9.0.Final released

[Yoann Rodiere]

Hello,

We just published 5.9.0.Final, the first stable release in the 5.9 branch.
This release brings a brand-new JSR-352 integration for mass indexing,
WildFly feature packs, and better integration to modular environments.

Check out our blog for more information about this release:

http://in.relation.to/2018/02/07/hibernate-search-5-9-0-Final/
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

[Steve Ebersole]

Ok, so this is the crux then because it really comes down to whether you
believe whether it is valid to *only* export the annotation-based
validations as DDL.

And keep in mind that this code is basically unchanged from all the way
back to the initial "integrations" with HV.  So back then the
thought-process (not mine, btw) was that yes, that *is* valid - hence the
option to chose just DDL as an option.

But if thats now no longer valid then that changes things.



On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet 
wrote:

> Hi,
>
> On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole 
> wrote:
>>
>> Is it valid for a user to want *just* DDL-based validation?  How would
>> that
>> work in Gunnar's request?
>>
>
> From your writings, I suspect I'm the only one with this opinion but my
> answer would be: "not if you use Bean Validation annotations".
>
> If you use BV's @NotNull, you expect BV to validate the input. And you
> might want additional DDL in your database to be on the safe side (which
> should be the default IMHO).
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Steve Ebersole]

Yes, I can see this being a problem.  Its caused by some very old, fulgy
code in how "list-valued parameters" are handled internally.

I'm not sure the best way to deal with this.  Unfortunately reverting this
is not possible - its necessary for JPA compliance.  The simple workaround
of course is to use named parameters yourself.  Honestly JPA's notion of
"positional" parameters is nonsensical since they are not positional - the
ordinals can repeat and can appear in any order... nothing particularly
positional about that.  In fact they are really nothing more than named
parameters that happen to use int-valued labels.

Longer term 6.0 will address this because it changes that "old, fulgy"
internal code - but those same changes are not possibly in 5.3.


On Fri, Feb 2, 2018 at 3:37 PM Laurent Almeras  wrote:

> Hi,
>
> After digging further, it seems to me that there is a bug with Hibernate
> 5.3.
>
> I debug and step through the query handling, and the generated QueryDSL
> query seems correct to me:
>
> =
> select queuedTaskHolder
> from QueuedTaskHolder queuedTaskHolder
> where queuedTaskHolder.status in (?1) and queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
> =
>
> The (:x1_0, :x1_1, :x1_2, :x1_3) part appears in the hibernate query
> handling inside layers, in
>
> org.hibernate.query.internal.QueryParameterBindingsImpl.expandListValuedParameters(String,
> SharedSessionContractImplementor) method. It seems that the purpose of
> this method is to transform query and parameters arguments when argument
> is a list. So query is rewritten with named parameters, and query
> parameters are modified to inject this new parameters.
>
> And this query is then rejected in
>
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(AST,
> AST) because there are namedParameters.
>
> If I switch dependency to 5.2.12.Final release, the same code works.
>
> I'll try to write a minimal test-case about this when I'll get some
> spare time.
>
> --
> Laurent Almeras
>
> On 02/02/2018 06:00 PM, Laurent Almeras wrote:
> > Hi,
> >
> > Testing Hibernate 9.3.0.Beta2, I run into this issue:
> >
> >
> > ===
> >   Cannot define positional and named parameterSpecs : select
> > queuedTaskHolder
> > from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> > queuedTaskHolder
> > where queuedTaskHolder.status in (:x1_0, :x1_1, :x1_2, :x1_3) and
> > queuedTaskHolder.queueId = ?2
> > ===
> >
> >
> > Hibernate complains that query contains both named and positional
> > parameters (note that this query use to work on Hibernate 5.2.x).
> >
> > This new behavior is linked to:
> >
> > * this commit:
> >
> https://github.com/hibernate/hibernate-orm/commit/5e0274adbbd3e0aa3092c29a765fd203c8279126
> >
> > * this issue: https://hibernate.atlassian.net/browse/HHH-12116
> > * and this parent issue:
> https://hibernate.atlassian.net/browse/HHH-12101
> >
> > I also find that you already talk about this behavior on this same
> > mailing-list:
> >
> http://lists.jboss.org/pipermail/hibernate-dev/2016-September/015460.html
> >
> >
> > I think that allowing this behavior was not a good idea, so I don't have
> > any hope that you consider this as a bug. But I think it should be
> > noticed in the release note
> > (http://in.relation.to/2018/01/18/hibernate-orm-530-beta1-release/) or
> > in this ticket (https://hibernate.atlassian.net/browse/HHH-12101) as a
> > side-effect.
> >
> >
> > On my side, I run in this issue because I use QueryDSL-jpa, and the
> > query I give as an example is buggy because it mixes a IN statement
> > (named parameter) dans an EQUAL statement (positional parameter).
> >
> > Is there anyone following both Hibernate and QueryDSL here that is
> > already aware or working on this issue ?
> >
> >
> > Thanks
> >
> > Laurent Almeras
> >
> ___
> 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 DDL doesn't reflect BV constraints with validation mode CALLBACK

[Gunnar Morling]

2018-02-07 16:08 GMT+01:00 Steve Ebersole :

> Ok, so this is the crux then because it really comes down to whether you
> believe whether it is valid to *only* export the annotation-based
> validations as DDL.
>
> And keep in mind that this code is basically unchanged from all the way
> back to the initial "integrations" with HV.  So back then the
> thought-process (not mine, btw) was that yes, that *is* valid - hence the
> option to chose just DDL as an option.
>

You'd still have that ability with my suggestion, just keep validation mode
to NONE and set hibernate.validator.apply_to_ddl = true.

By "safest mode" above I meant CALLBACK is the right way if you really want
to make sure that lifecycle validation occurs, or you'll get an exception
if no BV provider is present. It can't happen that lifecycle validation
silently, unexpectedly doesn't happen. Hence I prefer it over AUTO. And as
things stand I can't benefit from constraints in DDL export in that case,
which is a pity.

But if thats now no longer valid then that changes things.
>
>
>
> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet 
> wrote:
>
> > Hi,
> >
> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole 
> > wrote:
> >>
> >> Is it valid for a user to want *just* DDL-based validation?  How would
> >> that
> >> work in Gunnar's request?
> >>
> >
> > From your writings, I suspect I'm the only one with this opinion but my
> > answer would be: "not if you use Bean Validation annotations".
> >
> > If you use BV's @NotNull, you expect BV to validate the input. And you
> > might want additional DDL in your database to be on the safe side (which
> > should be the default IMHO).
> >
> > --
> > 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] ORM documentation info hibernate.org

[Steve Ebersole]

Now that the hibernate.org infrastructure supports doc versions, should we
remove the version drop-down from the info pages?  Vlad I know you spent
some time adding that; what are your thoughts?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM documentation info hibernate.org

[andrea boriero]

I think it is not necessary anymore, so +1 for removing it.

On 7 February 2018 at 18:32, Steve Ebersole  wrote:

> Now that the hibernate.org infrastructure supports doc versions, should we
> remove the version drop-down from the info pages?  Vlad I know you spent
> some time adding that; what are your thoughts?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Steve Ebersole]

Yes, I understood the situation.

I'm saying that in your query you should just be able to switch to use
named parameters (prefixed with `:`, rather than `?`) as a workaround

On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras 
wrote:

> Hi,
>
> Thanks for this insight ; but as I stated (and this is a correction of the
> assumptions of my first email) in my second email, it seems that the wrong
> query (with mixed positional and named parameters) is built in hibernate
> inside layers (and not in QueryDSL).
>
> I get rid of my QueryDSL query and replace it with raw JPQL query :
>
>
> 
> Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
> "from QueuedTaskHolder queuedTaskHolder\n" +
> "where queuedTaskHolder.status in (?1) and
> queuedTaskHolder.queueId = ?2\n" +
> "order by queuedTaskHolder.id asc").setParameter(1,
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter(2, "queue");
> return query.getResultList();
> 
>
> And it fails with the very same message :
>
>
> 
>
>
> Cannot define positional and named parameterSpecs : select queuedTaskHolder
> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
> queuedTaskHolder
>
> where queuedTaskHolder.status in (:x1_0, :x1_1) and
> queuedTaskHolder.queueId = ?2
> order by queuedTaskHolder.id asc
> at
> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
> at
> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
> 
>
> It used to work with Hibernate 5.2.x ; and by reading JPQL spec (not sure
> if this is the right version -
> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
> ) it seems that " IN (?param) " is a valid syntax.
>
> I agree that mixed query may not be supported, but even if positional
> parameter queries bring nothing more than named parameters ones, there are
> also required for JPA compliance ?
>
> Can you say me if I made some wrong assumptions ? If not, is it usefull I
> provide some minimal test-case ?
>
>
>
> *Side-note:* same query written with named parameters is OK (as expected):
>
>
> 
> Query query = getEntityManager().createQuery("select
> queuedTaskHolder\n" +
> "from QueuedTaskHolder queuedTaskHolder\n" +
> "where queuedTaskHolder.status in (:statuses) and
> queuedTaskHolder.queueId = :queue\n" +
> "order by queuedTaskHolder.id asc").setParameter("statuses",
> ImmutableList.of(TaskStatus.CANCELLED,
> TaskStatus.COMPLETED)).setParameter("queue", "queue");
> return query.getResultList();
> 
>
>
>
> Thanks,
>
> Le 07/02/2018 à 17:30, Steve Ebersole a écrit :
>
> Yes, I can see this being a problem.  Its caused by some very old, fulgy
> code in how "list-valued parameters" are handled internally.
>
> I'm not sure the best way to deal with this.  Unfortunately reverting this
> is not possible - its necessary for JPA compliance.  The simple workaround
> of course is to use named parameters yourself.  Honestly JPA's notion of
> "positional" parameters is nonsensical since they are not positional - the
> ordinals can repeat and can appear in any order... nothing particularly
> positional about that.  In fact they are really nothing more than named
> parameters that happen to use int-valued labels.
>
> Longer term 6.0 will address this because it changes that "old, fulgy"
> internal code - but those same changes are not possibly in 5.3.
>
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM documentation info hibernate.org

[Vlad Mihalcea]

I also think it's redundant now.

Vlad

On Wed, Feb 7, 2018 at 8:36 PM, andrea boriero  wrote:

> I think it is not necessary anymore, so +1 for removing it.
>
> On 7 February 2018 at 18:32, Steve Ebersole  wrote:
>
> > Now that the hibernate.org infrastructure supports doc versions, should
> we
> > remove the version drop-down from the info pages?  Vlad I know you spent
> > some time adding that; what are your thoughts?
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Some insight about HHH-12101 / remove HQL-style positional parameters

[Steve Ebersole]

And I did say that this is indeed a problem assuming you are right, and I
have no reason to believe you are not.  In fact I can see how that would
happen.  Yes all based on Hibernate internals.

So I am not trying to blow you off as "this is not a bug".  I think it is a
bug.  I'm just saying I do not yet know what to do about it.

On Wed, Feb 7, 2018 at 12:41 PM Steve Ebersole  wrote:

> Yes, I understood the situation.
>
> I'm saying that in your query you should just be able to switch to use
> named parameters (prefixed with `:`, rather than `?`) as a workaround
>
> On Wed, Feb 7, 2018 at 11:21 AM Laurent Almeras <
> laurent.alme...@laposte.net> wrote:
>
>> Hi,
>>
>> Thanks for this insight ; but as I stated (and this is a correction of
>> the assumptions of my first email) in my second email, it seems that the
>> wrong query (with mixed positional and named parameters) is built in
>> hibernate inside layers (and not in QueryDSL).
>>
>> I get rid of my QueryDSL query and replace it with raw JPQL query :
>>
>>
>> 
>> Query query = getEntityManager().createQuery("select
>> queuedTaskHolder\n" +
>> "from QueuedTaskHolder queuedTaskHolder\n" +
>> "where queuedTaskHolder.status in (?1) and
>> queuedTaskHolder.queueId = ?2\n" +
>> "order by queuedTaskHolder.id asc").setParameter(1,
>> ImmutableList.of(TaskStatus.CANCELLED,
>> TaskStatus.COMPLETED)).setParameter(2, "queue");
>> return query.getResultList();
>> 
>>
>> And it fails with the very same message :
>>
>>
>> 
>>
>>
>> Cannot define positional and named parameterSpecs : select
>> queuedTaskHolder
>> from org.iglooproject.jpa.more.business.task.model.QueuedTaskHolder
>> queuedTaskHolder
>>
>> where queuedTaskHolder.status in (:x1_0, :x1_1) and
>> queuedTaskHolder.queueId = ?2
>> order by queuedTaskHolder.id asc
>> at
>> org.hibernate.hql.internal.ast.HqlSqlWalker.generatePositionalParameter(HqlSqlWalker.java:1094)
>> at
>> org.hibernate.hql.internal.antlr.HqlSqlBaseWalker.parameter(HqlSqlBaseWalker.java:3463)
>> 
>>
>> It used to work with Hibernate 5.2.x ; and by reading JPQL spec (not sure
>> if this is the right version -
>> https://docs.oracle.com/html/E13946_01/ejb3_langref.html#ejb3_langref_in
>> ) it seems that " IN (?param) " is a valid syntax.
>>
>> I agree that mixed query may not be supported, but even if positional
>> parameter queries bring nothing more than named parameters ones, there are
>> also required for JPA compliance ?
>>
>> Can you say me if I made some wrong assumptions ? If not, is it usefull I
>> provide some minimal test-case ?
>>
>>
>>
>> *Side-note:* same query written with named parameters is OK (as
>> expected):
>>
>>
>> 
>> Query query = getEntityManager().createQuery("select
>> queuedTaskHolder\n" +
>> "from QueuedTaskHolder queuedTaskHolder\n" +
>> "where queuedTaskHolder.status in (:statuses) and
>> queuedTaskHolder.queueId = :queue\n" +
>> "order by queuedTaskHolder.id asc").setParameter("statuses",
>> ImmutableList.of(TaskStatus.CANCELLED,
>> TaskStatus.COMPLETED)).setParameter("queue", "queue");
>> return query.getResultList();
>> 
>>
>>
>>
>> Thanks,
>>
>> Le 07/02/2018 à 17:30, Steve Ebersole a écrit :
>>
>> Yes, I can see this being a problem.  Its caused by some very old, fulgy
>> code in how "list-valued parameters" are handled internally.
>>
>> I'm not sure the best way to deal with this.  Unfortunately reverting
>> this is not possible - its necessary for JPA compliance.  The simple
>> workaround of course is to use named parameters yourself.  Honestly JPA's
>> notion of "positional" parameters is nonsensical since they are not
>> positional - the ordinals can repeat and can appear in any order... nothing
>> particularly positional about that.  In fact they are really nothing more
>> than named parameters that happen to use int-valued labels.
>>
>> Longer term 6.0 will address this because it changes that "old, fulgy"
>> internal code - but those same changes are not possibly in 5.3.
>>
>>
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

[Steve Ebersole]

Of course you can.  `mode = CALLBACK,DDL`

You mean that you cannot using single-valued setting

On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling  wrote:

> 2018-02-07 16:08 GMT+01:00 Steve Ebersole :
>
>> Ok, so this is the crux then because it really comes down to whether you
>> believe whether it is valid to *only* export the annotation-based
>> validations as DDL.
>>
>> And keep in mind that this code is basically unchanged from all the way
>> back to the initial "integrations" with HV.  So back then the
>> thought-process (not mine, btw) was that yes, that *is* valid - hence the
>> option to chose just DDL as an option.
>>
>
> You'd still have that ability with my suggestion, just keep validation
> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>
> By "safest mode" above I meant CALLBACK is the right way if you really
> want to make sure that lifecycle validation occurs, or you'll get an
> exception if no BV provider is present. It can't happen that lifecycle
> validation silently, unexpectedly doesn't happen. Hence I prefer it over
> AUTO. And as things stand I can't benefit from constraints in DDL export in
> that case, which is a pity.
>
> But if thats now no longer valid then that changes things.
>>
>>
>>
>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet 
>> wrote:
>>
>
>> > Hi,
>> >
>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole 
>> > wrote:
>> >>
>> >> Is it valid for a user to want *just* DDL-based validation?  How would
>> >> that
>> >> work in Gunnar's request?
>> >>
>> >
>> > From your writings, I suspect I'm the only one with this opinion but my
>> > answer would be: "not if you use Bean Validation annotations".
>> >
>> > If you use BV's @NotNull, you expect BV to validate the input. And you
>> > might want additional DDL in your database to be on the safe side (which
>> > should be the default IMHO).
>> >
>> > --
>> > 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] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

[Gunnar Morling]

Right, giving multiple values isn't allowed as per JPA's XSD.

2018-02-07 19:44 GMT+01:00 Steve Ebersole :

> Of course you can.  `mode = CALLBACK,DDL`
>
> You mean that you cannot using single-valued setting
>
> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling 
> wrote:
>
>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole :
>>
>>> Ok, so this is the crux then because it really comes down to whether you
>>> believe whether it is valid to *only* export the annotation-based
>>> validations as DDL.
>>>
>>> And keep in mind that this code is basically unchanged from all the way
>>> back to the initial "integrations" with HV.  So back then the
>>> thought-process (not mine, btw) was that yes, that *is* valid - hence the
>>> option to chose just DDL as an option.
>>>
>>
>> You'd still have that ability with my suggestion, just keep validation
>> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>>
>> By "safest mode" above I meant CALLBACK is the right way if you really
>> want to make sure that lifecycle validation occurs, or you'll get an
>> exception if no BV provider is present. It can't happen that lifecycle
>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>> that case, which is a pity.
>>
>> But if thats now no longer valid then that changes things.
>>>
>>>
>>>
>>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet 
>>> wrote:
>>>
>>
>>> > Hi,
>>> >
>>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole 
>>> > wrote:
>>> >>
>>> >> Is it valid for a user to want *just* DDL-based validation?  How would
>>> >> that
>>> >> work in Gunnar's request?
>>> >>
>>> >
>>> > From your writings, I suspect I'm the only one with this opinion but my
>>> > answer would be: "not if you use Bean Validation annotations".
>>> >
>>> > If you use BV's @NotNull, you expect BV to validate the input. And you
>>> > might want additional DDL in your database to be on the safe side
>>> (which
>>> > should be the default IMHO).
>>> >
>>> > --
>>> > 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] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

[Steve Ebersole]

How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?

Look, I don't mind revisiting a change here.  I really have no horse n this
race - this is not even my code originally.  TBH I thought this was code
that you did.  So I don't mind changes here if there is a consensus.  But
let's use real reasons ;)

On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling  wrote:

> Right, giving multiple values isn't allowed as per JPA's XSD.
>
> 2018-02-07 19:44 GMT+01:00 Steve Ebersole :
>
>> Of course you can.  `mode = CALLBACK,DDL`
>>
>> You mean that you cannot using single-valued setting
>>
>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling 
>> wrote:
>>
>>> 2018-02-07 16:08 GMT+01:00 Steve Ebersole :
>>>
 Ok, so this is the crux then because it really comes down to whether you
 believe whether it is valid to *only* export the annotation-based
 validations as DDL.

 And keep in mind that this code is basically unchanged from all the way
 back to the initial "integrations" with HV.  So back then the
 thought-process (not mine, btw) was that yes, that *is* valid - hence
 the
 option to chose just DDL as an option.

>>>
>>> You'd still have that ability with my suggestion, just keep validation
>>> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>>>
>>> By "safest mode" above I meant CALLBACK is the right way if you really
>>> want to make sure that lifecycle validation occurs, or you'll get an
>>> exception if no BV provider is present. It can't happen that lifecycle
>>> validation silently, unexpectedly doesn't happen. Hence I prefer it over
>>> AUTO. And as things stand I can't benefit from constraints in DDL export in
>>> that case, which is a pity.
>>>
>>> But if thats now no longer valid then that changes things.



 On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet >>> >
 wrote:

>>>
 > Hi,
 >
 > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole 
 > wrote:
 >>
 >> Is it valid for a user to want *just* DDL-based validation?  How
 would
 >> that
 >> work in Gunnar's request?
 >>
 >
 > From your writings, I suspect I'm the only one with this opinion but
 my
 > answer would be: "not if you use Bean Validation annotations".
 >
 > If you use BV's @NotNull, you expect BV to validate the input. And you
 > might want additional DDL in your database to be on the safe side
 (which
 > should be the default IMHO).
 >
 > --
 > 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] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

[Gunnar Morling]

> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?

I was referring to the dedicated  element, which is
restricted to the values AUTO, CALLBACK, NONE in that XSD and which can be
given at most once [1]. I can see though how it'd work with the
javax.persistence.validation.mode String property.

So, yeah, technically no change needed. Still quite subtle and very easy to
miss. Waiting a bit for some more feedback by others, if we decide to leave
it as is, we need at least to update the HV docs to describe this in more
depth (we only mention  but not that string property).

[1]
https://github.com/hibernate/hibernate-orm/blob/master/tooling/metamodel-generator/src/main/xsd/persistence_2_1.xsd#L326-L339
.

2018-02-07 20:05 GMT+01:00 Steve Ebersole :

> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>
> Look, I don't mind revisiting a change here.  I really have no horse n
> this race - this is not even my code originally.  TBH I thought this was
> code that you did.  So I don't mind changes here if there is a consensus.
> But let's use real reasons ;)
>
> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling 
> wrote:
>
>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>
>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole :
>>
>>> Of course you can.  `mode = CALLBACK,DDL`
>>>
>>> You mean that you cannot using single-valued setting
>>>
>>> On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling 
>>> wrote:
>>>
 2018-02-07 16:08 GMT+01:00 Steve Ebersole :

> Ok, so this is the crux then because it really comes down to whether
> you
> believe whether it is valid to *only* export the annotation-based
> validations as DDL.
>
> And keep in mind that this code is basically unchanged from all the way
> back to the initial "integrations" with HV.  So back then the
> thought-process (not mine, btw) was that yes, that *is* valid - hence
> the
> option to chose just DDL as an option.
>

 You'd still have that ability with my suggestion, just keep validation
 mode to NONE and set hibernate.validator.apply_to_ddl = true.

 By "safest mode" above I meant CALLBACK is the right way if you really
 want to make sure that lifecycle validation occurs, or you'll get an
 exception if no BV provider is present. It can't happen that lifecycle
 validation silently, unexpectedly doesn't happen. Hence I prefer it over
 AUTO. And as things stand I can't benefit from constraints in DDL export in
 that case, which is a pity.

 But if thats now no longer valid then that changes things.
>
>
>
> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
> guillaume.s...@gmail.com>
> wrote:
>

> > Hi,
> >
> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole 
> > wrote:
> >>
> >> Is it valid for a user to want *just* DDL-based validation?  How
> would
> >> that
> >> work in Gunnar's request?
> >>
> >
> > From your writings, I suspect I'm the only one with this opinion but
> my
> > answer would be: "not if you use Bean Validation annotations".
> >
> > If you use BV's @NotNull, you expect BV to validate the input. And
> you
> > might want additional DDL in your database to be on the safe side
> (which
> > should be the default IMHO).
> >
> > --
> > 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] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

[Steve Ebersole]

No, I think you are right and `hibernate.validator.apply_to_ddl` should
apply to CALLBACK as well.

On Wed, Feb 7, 2018 at 1:45 PM Gunnar Morling  wrote:

> > How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>
> I was referring to the dedicated  element, which is
> restricted to the values AUTO, CALLBACK, NONE in that XSD and which can
> be given at most once [1]. I can see though how it'd work with the
> javax.persistence.validation.mode String property.
>
> So, yeah, technically no change needed. Still quite subtle and very easy
> to miss. Waiting a bit for some more feedback by others, if we decide to
> leave it as is, we need at least to update the HV docs to describe this in
> more depth (we only mention  but not that string property).
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/tooling/metamodel-generator/src/main/xsd/persistence_2_1.xsd#L326-L339
> .
>
> 2018-02-07 20:05 GMT+01:00 Steve Ebersole :
>
>> How is a String "CALLBACK,DDL" considered "multiple values" to an XSD?
>>
>> Look, I don't mind revisiting a change here.  I really have no horse n
>> this race - this is not even my code originally.  TBH I thought this was
>> code that you did.  So I don't mind changes here if there is a consensus.
>> But let's use real reasons ;)
>>
>> On Wed, Feb 7, 2018 at 12:53 PM Gunnar Morling 
>> wrote:
>>
>>> Right, giving multiple values isn't allowed as per JPA's XSD.
>>>
>>> 2018-02-07 19:44 GMT+01:00 Steve Ebersole :
>>>
 Of course you can.  `mode = CALLBACK,DDL`

 You mean that you cannot using single-valued setting

 On Wed, Feb 7, 2018 at 12:02 PM Gunnar Morling 
 wrote:

> 2018-02-07 16:08 GMT+01:00 Steve Ebersole :
>
>> Ok, so this is the crux then because it really comes down to whether
>> you
>> believe whether it is valid to *only* export the annotation-based
>> validations as DDL.
>>
>> And keep in mind that this code is basically unchanged from all the
>> way
>> back to the initial "integrations" with HV.  So back then the
>> thought-process (not mine, btw) was that yes, that *is* valid - hence
>> the
>> option to chose just DDL as an option.
>>
>
> You'd still have that ability with my suggestion, just keep validation
> mode to NONE and set hibernate.validator.apply_to_ddl = true.
>
> By "safest mode" above I meant CALLBACK is the right way if you really
> want to make sure that lifecycle validation occurs, or you'll get an
> exception if no BV provider is present. It can't happen that lifecycle
> validation silently, unexpectedly doesn't happen. Hence I prefer it over
> AUTO. And as things stand I can't benefit from constraints in DDL export 
> in
> that case, which is a pity.
>
> But if thats now no longer valid then that changes things.
>>
>>
>>
>> On Tue, Feb 6, 2018 at 3:15 PM Guillaume Smet <
>> guillaume.s...@gmail.com>
>> wrote:
>>
>
>> > Hi,
>> >
>> > On Tue, Feb 6, 2018 at 5:01 PM, Steve Ebersole > >
>> > wrote:
>> >>
>> >> Is it valid for a user to want *just* DDL-based validation?  How
>> would
>> >> that
>> >> work in Gunnar's request?
>> >>
>> >
>> > From your writings, I suspect I'm the only one with this opinion
>> but my
>> > answer would be: "not if you use Bean Validation annotations".
>> >
>> > If you use BV's @NotNull, you expect BV to validate the input. And
>> you
>> > might want additional DDL in your database to be on the safe side
>> (which
>> > should be the default IMHO).
>> >
>> > --
>> > 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] ORM documentation info hibernate.org

[Sanne Grinovero]

No strong objection, but I quite like it giving a quick shortcut to
switch version.

It's also well visible, making sure people are on the version they
mean to be - which is useful if they "land" directly on a version
documentation from outdated links or search engines.



On 7 February 2018 at 18:38, Vlad Mihalcea  wrote:
> I also think it's redundant now.
>
> Vlad
>
> On Wed, Feb 7, 2018 at 8:36 PM, andrea boriero  wrote:
>
>> I think it is not necessary anymore, so +1 for removing it.
>>
>> On 7 February 2018 at 18:32, Steve Ebersole  wrote:
>>
>> > Now that the hibernate.org infrastructure supports doc versions, should
>> we
>> > remove the version drop-down from the info pages?  Vlad I know you spent
>> > some time adding that; what are your thoughts?
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM documentation info hibernate.org

[Steve Ebersole]

That's a good thought.

On Wed, Feb 7, 2018, 3:52 PM Sanne Grinovero  wrote:

> No strong objection, but I quite like it giving a quick shortcut to
> switch version.
>
> It's also well visible, making sure people are on the version they
> mean to be - which is useful if they "land" directly on a version
> documentation from outdated links or search engines.
>
>
>
> On 7 February 2018 at 18:38, Vlad Mihalcea 
> wrote:
> > I also think it's redundant now.
> >
> > Vlad
> >
> > On Wed, Feb 7, 2018 at 8:36 PM, andrea boriero 
> wrote:
> >
> >> I think it is not necessary anymore, so +1 for removing it.
> >>
> >> On 7 February 2018 at 18:32, Steve Ebersole 
> wrote:
> >>
> >> > Now that the hibernate.org infrastructure supports doc versions,
> should
> >> we
> >> > remove the version drop-down from the info pages?  Vlad I know you
> spent
> >> > some time adding that; what are your thoughts?
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> 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