Re: [hibernate-dev] ORM 5 -> 6 first merge meeting

[Vlad Mihalcea]

Ok, I'll add the commits that cannot be integrated to the Google Docs list
then.

Vlad

On Thu, Dec 20, 2018 at 7:30 AM Steve Ebersole  wrote:

> Seems to me it would be better to wait until the whole commit can be
> integrated.  Just seems like it would be easier to keep track of
>
>
> On Wed, Dec 19, 2018, 3:25 PM Guillaume Smet 
> wrote:
>
>> Hi Vlad,
>>
>> Not sure if it's better to partially push the commits or to have them in a
>> list to deal with later (tests + commit).
>>
>> What do the others think about it?
>>
>> On Wed, Dec 19, 2018 at 6:37 PM Vlad Mihalcea 
>> wrote:
>>
>> > I have merged some PRs and have some commits still left to integrate
>> into
>> > 6. Indeed that some if them cannot be fully integrated because they
>> rely on
>> > non-implemented functionality. But I'll add the tests in the pending
>> tests
>> > folder.
>> >
>> > Vlad
>> >
>> > On Wed, 19 Dec 2018, 18:19 Guillaume Smet > wrote:
>> >
>> >> Hi,
>> >>
>> >> We had the first 5 -> 6 merge meeting with Chris yesterday. We
>> >> cherry-picked all the simple things but there were a few more
>> problematic
>> >> things:
>> >> - things that needs to be ported soon but weren't a simple cherry-pick
>> >> - things that cannot be ported right now because not yet available in 6
>> >>
>> >> We decided to push a document in the 6 tree containing the status so
>> that
>> >> we have proper versioning:
>> >>
>> https://github.com/hibernate/hibernate-orm/blob/wip/6.0/MERGE_STATUS.adoc
>> >>
>> >> Andrea, Chris and Vlad each have one issue affected. Maybe let's try to
>> >> target the next meeting as the limit for merging them (or push them to
>> >> kept
>> >> for later), probably January 8th-9th.
>> >>
>> >> When you're done with a merge, please remove the related content from
>> the
>> >> document so that we can keep track of things.
>> >>
>> >> 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
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 Alpha1 prep

[Vlad Mihalcea]

Hi,

I also agree with Christian. For the `hibernate-entitymanager`, the problem
came from Spring as they wanted to support multiple versions of Hibernate.

I wrote them on Twitter about this change so that they can adjust their
framework to accommodate it.

Vlad

On Wed, Dec 5, 2018 at 3:53 PM Christian Beikov 
wrote:

> Am 05.12.2018 um 14:42 schrieb Steve Ebersole:
> > As I am preparing the Alpha1 release a few topics of discussion have come
> > up...
> >
> > Previously (last year's f2f) we had decided to unify the artifact naming
> > conventions; specifically for ORM this meant renaming the groupId from
> > `org.hibernate` to `org.hibernate.orm` as part of 6.0.  I wanted to see
> if
> > everyone still agrees with this.
> +1
> > There are a few artifacts we need to decide how to handle:
> >
> > - `hibernate-entitymanager` and `hibernate-java8` have been part of
> > `hibernate-core` since 5.2 (I thought moving
> `hibernate-entitymanager`
> > happened way earlier, but seems like not).  Should we drop these?
> They
> > have been defined as relocations for quite some time now).
> +1 for dropping the relocation artifacts
> > - `hibernate-ehcache` defines support for using Ehcache 2 as a
> > second-level cache, which is a version the Ehcache team does not even
> > support anymore and have not for quite a few years.  Ehcache 3 is a
> JCache
> > compliant version and the way that the Ehcache team prefer to handle
> the
> > integration (in fact they wrote most of `hibernate-jcache`).  IMO
> this
> > should be removed as well.  Thoughts?
> Sounds reasonable.
> > - `hibernate-infinispan` - support for using Infinispan as a
> Hibernate
> > L2C has been moved to the Infinispan project. Again, IMO this module
> should
> > go away.  Thoughts?
> +1 as well
> > Andrea, Chris.. anything you can think of that I missed?
> > ___
> > 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] Can't build Hibernate ORM 5.1 documentation

[Vlad Mihalcea]

Hi,

Form 5.2, we no longer have the DocBooks tasks.

The only document using DocBook in 5.1 is the Integration Guide:

http://docs.jboss.org/hibernate/orm/5.1/integrationsGuide/

We converted that to AsciiDoc in 5.2

http://docs.jboss.org/hibernate/orm/5.2/integrationguide/

It's worth investigating whether we could remove them from 5.1 as well.

Vlad

On Wed, Nov 28, 2018 at 11:37 AM Gail Badner  wrote:

> Andrea found a solution that works. :)
>
> On Tue, Nov 27, 2018 at 10:49 PM Gail Badner  wrote:
>
>> I'm getting ready to release 5.1.17, but I'm having trouble building the
>> documentation.
>>
>> I can't even build the documentation using 5.1.16 tag. It worked fine
>> when I released 5.1.16.Final in August.
>>
>> A new property was added for HHH-13011, and I need to get that documented
>> in the user guide for 5.1.17.
>>
>> Here is what I'm seeing when I execute `./gradlew buildDocs`:
>>
>> :documentation:renderDocBook_mappingGuide_en-US_html
>> rendering Book(mappingGuide) en-US/html
>> Extending script classloader with the jdocbookXsl dependencies
>> redirecting console output to file
>> [/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log]
>>
>> Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd:
>>  Error reported by XML parser: The markup declarations contained or
>> pointed to by the document type declaration must be well-formed.
>> Resetting console output
>> :documentation:renderDocBook_mappingGuide_en-US_html FAILED
>>
>> FAILURE: Build failed with an exception.
>>
>> * What went wrong:
>> Execution failed for task
>> ':documentation:renderDocBook_mappingGuide_en-US_html'.
>> > error rendering [org.xml.sax.SAXParseException; systemId:
>> http://docbook.org/xml/5.0/dtd/docbook.dtd; lineNumber: 1; columnNumber:
>> 1; The markup decl
>> arations contained or pointed to by the document type declaration must be
>> well-formed.] on Hibernate_Mapping_Guide.xml
>>
>> The log file 
>> (/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log)
>> was empty.
>>
>> I'm attaching the console log from executing `./gradlew buildDocs --debug
>> --info`.
>>
>> Any ideas???
>>
>> Thanks,
>> Gail
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Vlad Mihalcea]

Hi,

My question was more about LocalTime, which is much more straightforward to
address than LocalDateTime in the context of time zones.

For DateTime types which support timezones, I'll have to study to see what
other non-breaking alternatives we may have.

Vlad

On Fri, Oct 5, 2018 at 2:28 PM Steve Ebersole  wrote:

> Ah good, its time for this yearly discussion :D
>
> The problem is as Vlad points out.  We are kind of forced to do
> *something* wrt timezone to often times counteract what the JDBC driver
> will do.  As I have always contended, imo that saving a date into the
> database with any kind of timzone (other than UTC) is simply wrong.  I
> personally would never do it - and I think we've seen enough of the down
> sides to doing it.  As Sanne points out, storing epoch-based dates
> (Instant, etc) is always the best option
>
> One cool option would be an AttributeConverter that handles the timezone
> transformation, combined with telling Hibernate to always use UTC for the
> JDBC timezone
>
>
> On Fri, Oct 5, 2018 at 4:44 AM Sanne Grinovero 
> wrote:
>
>> On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea 
>> wrote:
>> >
>> > Hi
>> >
>> > IMO no timezone conversion whatsoever should be applied when
>> > > persisting LocalDateTime as it doesn't contain any TZ information.
>> >
>> >
>> > That's not very easy to do since either the JDBC Driver or the database
>> > engine might to the timezone conversion based on the underlying setting.
>> >
>> > In fact I'd even recommend to use a string-based column type to store
>> > > LDT, as it avoids these kinds of issues altogether.
>>
>> +1 I think we need to enforce that. Mapping a Java type which is
>> explicitly designed to be insensitive to TZ should not be stored into
>> a type which is sensitive to it. That would otherwise defeat the
>> purpose of using these specific types.
>>
>> If people really want to convert stuff, that's business logic. So that
>> belong in the business layer: let them do explicit conversion in their
>> own code before invoking the setter of an entity, that will also help
>> to bring awareness on any conversion issue they might have.
>>
>> >
>> >
>> > Actually, a Long (BigInt) column type with the epoch would be more
>> suitable
>> > than a CHAR-based column since it's more compact and achieves the same
>> goal.
>> > However, many clients will not want to store Date/Time in Int or String
>> > columns as explained in the following article:
>>
>> -1
>>
>> let's use Epoch based numerics for Java types which are based on
>> Epoch. e.g. java.time.Instant.
>>
>> People can always transform a date into an epoch-independent number by
>> simply encoding it as a number;
>> e.g. "2018-10-31" -> 20181031 . I guess it could save you some bytes
>> but I'd be skeptical on doing this automatically.
>>
>> >
>> > https://www.periscopedata.com/blog/better-sql-schema
>> >
>> > Maybe introducing another value for "hibernate.jdbc.time_zone"
>> ("as_is"?)
>> > > that would also impact how we map timezone-less types, would be a
>> good idea?
>> >
>> >
>> > We would have to introduce a new configuration property as a strategy
>> where
>> > the current behavior is "legacy"
>> > while the new one must be explicitly enabled.
>> >
>> > Vlad
>> >
>> > On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere 
>> wrote:
>> >
>> > > > In fact I'd even recommend to use a string-based column type to
>> store
>> > > > LDT, as it avoids these kinds of issues altogether.
>> > >
>> > > Or just, you know, "timestamp without timezone". Where possible.
>> > >
>> > > More to the point, I agree with Vlad's proposition, and I also think
>> ORM
>> > > should avoid messing with timezones as much as possible: when the user
>> > > didn't provide one (LocalDate, LocalDateTime, Date), don't store one,
>> when
>> > > he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store
>> it
>> > > exactly as provided. The goal being to return the exact value that was
>> > > persisted when later retrieving the data.
>> > > But unfortunately I think there is a lot of legacy behaviors that
>> differ
>> > > from this, so any attempt at "fixing" it would break

Re: [hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Vlad Mihalcea]

Hi

IMO no timezone conversion whatsoever should be applied when
> persisting LocalDateTime as it doesn't contain any TZ information.


That's not very easy to do since either the JDBC Driver or the database
engine might to the timezone conversion based on the underlying setting.

In fact I'd even recommend to use a string-based column type to store
> LDT, as it avoids these kinds of issues altogether.


Actually, a Long (BigInt) column type with the epoch would be more suitable
than a CHAR-based column since it's more compact and achieves the same goal.
However, many clients will not want to store Date/Time in Int or String
columns as explained in the following article:

https://www.periscopedata.com/blog/better-sql-schema

Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
> that would also impact how we map timezone-less types, would be a good idea?


We would have to introduce a new configuration property as a strategy where
the current behavior is "legacy"
while the new one must be explicitly enabled.

Vlad

On Fri, Oct 5, 2018 at 11:17 AM Yoann Rodiere  wrote:

> > In fact I'd even recommend to use a string-based column type to store
> > LDT, as it avoids these kinds of issues altogether.
>
> Or just, you know, "timestamp without timezone". Where possible.
>
> More to the point, I agree with Vlad's proposition, and I also think ORM
> should avoid messing with timezones as much as possible: when the user
> didn't provide one (LocalDate, LocalDateTime, Date), don't store one, when
> he provided one (ZonedDateTime, OffsetDateTime, Calendar, ...), store it
> exactly as provided. The goal being to return the exact value that was
> persisted when later retrieving the data.
> But unfortunately I think there is a lot of legacy behaviors that differ
> from this, so any attempt at "fixing" it would break compatibility and make
> someone angry.
>
> Maybe introducing another value for "hibernate.jdbc.time_zone" ("as_is"?)
> that would also impact how we map timezone-less types, would be a good idea?
>
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
>
> On Fri, 5 Oct 2018 at 09:38, Gunnar Morling  wrote:
>
>> IMO no timezone conversion whatsoever should be applied when
>> persisting LocalDateTime as it doesn't contain any TZ information.
>>
>> If the target column type requires a TZ, it should be set to UTC,
>> storing the given value without any shift. I.e. the LDT value
>> 2007-12-03T10:15:30 should be stored as 2007-12-03T10:15:30@UTC, no
>> matter what's the VM's timezone or any TZ related config. This allows
>> to retrieve the original value later on, also if e.g. the loading VM
>> is in a different TZ.
>>
>> In fact I'd even recommend to use a string-based column type to store
>> LDT, as it avoids these kinds of issues altogether.
>>
>> --Gunnar
>>
>>
>>
>>
>>
>> Am Fr., 5. Okt. 2018 um 07:15 Uhr schrieb Vlad Mihalcea
>> :
>> >
>> > Hi,
>> > While reviewing this Jira issue:
>> >
>> > https://hibernate.atlassian.net/browse/HHH-12988
>> >
>> > and further discussing it via Twitter, I wonder if we should persist
>> > LocalTime as-is without any TimeZone transformation
>> > that may be done if we enable `hibernate.jdbc.time_zone`?
>> >
>> > According to the Date/Time API, LocalTime should not be relative to any
>> > TimeZone.
>> >
>> > If we make this change, it means we need to use a LocalTime SQL
>> descriptor
>> > that ignores the jdbc.time_zone property,
>> > and the change is going to break compatibility as well.
>> >
>> > Vlad
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Should the LocalTimeType use the globally configured TimeZone?

[Vlad Mihalcea]

Hi,
While reviewing this Jira issue:

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

and further discussing it via Twitter, I wonder if we should persist
LocalTime as-is without any TimeZone transformation
that may be done if we enable `hibernate.jdbc.time_zone`?

According to the Date/Time API, LocalTime should not be relative to any
TimeZone.

If we make this change, it means we need to use a LocalTime SQL descriptor
that ignores the jdbc.time_zone property,
and the change is going to break compatibility as well.

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

Re: [hibernate-dev] Loggers

[Vlad Mihalcea]

I think it's a good idea.

However, will this break all current applications that use the package name
log appenders?

Vlad

On Fri, Sep 14, 2018 at 7:20 PM, Steve Ebersole  wrote:

> Yes, I know no one likes talking about logging.  "Its not important", until
> it is ;)
>
> TLDR I am considering moving to using "module names" for logger names
> instead of Class names even for DEBUG/TRACE logging and see if anyone had
> strong arguments to not do this..
>
> Full version---
>
> For some time I have been moving to an approach of defining message
> loggers[1] using a single contract per function or "module" - e.g.:
>
>1. the second level caching module uses the dedicated message logger
>`ConnectionPoolingLogger`
>2. the ManagedBeanRegistry module uses the dedicated message logger
>`BeansMessageLogger`
>3. etc
>
> Each of these define a dedicate instance instance they can use.  E.g.
> ConnectionPoolingLogger is defined as:
>
> 
> @MessageLogger( projectCode = "HHH" )
> @ValidIdRange( min = 10001001, max = 10001500 )
> public interface ConnectionPoolingLogger extends BasicLogger {
>
> ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger(
> ConnectionPoolingLogger.class,
> "org.hibernate.orm.connections.pooling"
> );
>
> ...
> }
> 
>
> I won't get into all the whys I do this unless someone cares ;)
>
> But I am contemplating doing the same for basic loggers so I wanted to ask
> everyone else's opinion since this means a change in how you'd have to
> configure logging for DEBUG/TRACE output.  Usually you'd use the Class name
> as the logger name and use that to control logging in the back-end (log4j,
> etc).  If I do this, you'd have to instead use the module name.
>
> There are quite a few reasons I am considering  this, including all of the
> reasons I did it for  message loggers in the first place.  If I am
> debugging the loading of a collection or an entity, today I'd have to know
> all the packages involved (there is no common root name) and list them in
> my log4j.properties; that is because the process is ultimately handled by
> delegates or helpers in many different packages (`org.hibernate.loader`,
> `org.hibernate.persister`, `org.hibernate.type`, ...).  It sure would be
> nice to just be able to say `org.hibernate.loading` or
> `org.hibernate.loading.entity` or `org.hibernate.loading.collection` or
> ...
> for a number of reasons:
>
>1. When we need to see logging from someone it is a lot easier to tell
>the module name(s) you need enabled as opposed a list of package and
> class
>names.
>2. When running JPA TCK it is essentially impossible to attach debugger
>to step through code when debugging a failure - you have to rely on
>debugging through output.  *Well that used to be the case, but the
>latest TCK broke logging to STDOUT somehow so we ended up having to try
> and
>reproduce the failure in our testsuite - so then it does not matter
> either
>way ;)*
>3. Easier to document -
>http://docs.jboss.org/hibernate/orm/5.3/topical/
> html_single/logging/Logging.html
>
> Thoughts?
>
>
> [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which
> we use for user-focused log messages.  Should always be logged at >= INFO
> [2]
> [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for
> developer-focused log messages (for debugging).  Should always be logged at
> DEBUG or TRACE
> ___
> 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] @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element

[Vlad Mihalcea]

Here are my comments:

1. I think the @MapsId behavior is the right one even if we don't enable
cascading on the child-side.
Although theoretically, we should not do that, in reality, if we disable
this behavior, some apps will break.

We could document the behavior so that, when used @MapdId or PKJC,
Hibernate is allowed to cascade the parent if it's transient.

2. According to the JPA spec, the @OneToOne optional attribute is defined
like this:

(Optional) Whether the association is optional.
> If set to false then a non-null relationship must
> always exist.


I don't think that `optional` should be related to the FK generation. For
me, `optional` is more like adding NOT NULL to the FK column.

3. This reminds me of this Jira issue:

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

I guess it makes sense to have what you proposed:

Is this expected? If so, then ChildMapsId#parent cannot be optional by
> default (without @NotFound(IGNORE).


As for these questions:

1) the application must initialize ChildPKJC#id before persisting the
> entity [1]; otherwise,  the following exception is thrown:
> javax.persistence.PersistenceException:
> org.hibernate.id.IdentifierGenerationException: ids for this class must be
> manually assigned before calling save():


This is a consequence of the current behavior. I've added this phrase to
explain what happens.
If we change the behavior, we should update the doc too.

Related to:

[2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of the
> spec has this footnote:
> [12] If the application does not set the primary key attribute
> corresponding to the relationship, the value of that attribute may not be
> available until after the entity has been flushed to the database.


 They say "may not", meaning that setting the ID prior to flushing is not
going to break the spec.

For sequence identifiers, we always get the ID generated prior to the flush
anyway.

And for:

[3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote:
> [121]It is not expected that a database foreign key be defined for the
> OneToOne mapping, as the OneToOne relationship may be defined as
> “optional=true”.


I don't think that makes any sense at all. The real one-to-one database
table relationship is supposed to use a FK.
Now, without MapsId or PKJC, we actually have a "one-to-many" table
relationship with a UNIQUE constraint.
Even so, the FK is always mandatory. I have no idea why the JPA spec says
that.

Vlad


On Sat, Sep 1, 2018 at 10:33 AM, Gail Badner  wrote:

> FWIW, I've already spent a lot of time looking into the possible bugs I've
> described. I have a good idea about how to fix each one, so there's no need
> to research these. At this point, I'm just trying to get confirmation of
> whether they really are bugs.
>
> On Sat, Sep 1, 2018 at 12:21 AM, Gail Badner  wrote:
>
> > FYI, I am taking PTO Tuesday, 9/4. I hope to be able to move forward on
> > this when I return on 9/5.
> >
> > I see some differences. Some may be expected, but I think there are some
> > bugs.
> >
> > For example, suppose we have the following entities:
> >
> > @Entity
> > public class Parent {
> > @Id
> > private Long id;
> > }
> >
> > @Entity
> > public class ChildPKJC {
> > @Id
> > private Long id;
> >
> > @OneToOne  // note that cascade-persist is not enabled
> > @PrimaryKeyJoinColumn
> > private Parent parent;
> > }
> >
> > public class ChildMapsId {
> > @Id
> > private Long id;
> >
> > @OneToOne  // note that cascade-persist is not enabled
> > @MapsId
> > private Parent parent;
> > }
> >
> > 
> > 
> > ---
> >
> > When persisting ChildPKJC:
> >
> > 1) the application must initialize ChildPKJC#id before persisting the
> > entity [1]; otherwise,  the following exception is thrown:
> > javax.persistence.PersistenceException: org.hibernate.id.
> IdentifierGenerationException:
> > ids for this class must be manually assigned before calling save():
> >
> > 2) if ChildPKJC#parent is new with an assigned ID, and ChildPKJC#id is
> > assigned parent's ID, the ChildPKJC Entity is persisted with the parent's
> > ID, but parent is not persisted.
> >
> > When persisting ChildMapsId:
> >
> > 1) Hibernate automatically initializes ChildMapsId#id to parent.id [2]
> >
> > 2) if ChildMapsId#parent is new, parent is automatically
> > cascade-persisted (even though CascadeStyle.PERSIST is not mapped), then
> > the ChildMapsId entity is persisted.
> >
> > Are these expected difference? (My guess is yes)
> >
> > 
> > 
> > ---
> >
> > Foreign key generation:
> >
> > If ChildPKJC#parent is optional there is no foreign key generated from
> ChildPKJC
> > referencing Parent. [3] If ChildPKJC#parent is not optional, a foreign
> > key is generated

Re: [hibernate-dev] Reducing the memory usage of HQLQueryPlan

[Vlad Mihalcea]

Pad to the nearest power of 2. The performance improvement comes from the
likelihood of reusing the SQL Execution Plan on DBs that have a cache for
that: Oracle, SQL Server, DB2.

Vlad

On Sun, 12 Aug 2018, 04:43 Steve Ebersole,  wrote:

> Pad to what?  The number of elements in that passed list can literally be
> anything between 1 and Interger#MAX_VALUE.  Are you saying that we should
> expand any/all multi-valued parameters to Interger#MAX_VALUE JDBC params?
>
> I guess we could do "buckets" of padding, but I am not convinced that
> really buys us any performance.  Especially when you started considering
> queries with multiple multi-valued parameters where we'd end up with a
> product of the padding buckets for each.
>
> I'm up for trying anything we think might improve performance.  But that
> implies a baseline to make a comparison anyway - so I plan on continuing
> with the current approach for now...
>
>
> On Fri, Aug 10, 2018, 8:11 AM Christian Beikov  >
> wrote:
>
> > I'd like to note that with the array rendering strategy i.e. `where x =
> > ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
> > the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
> > necessary to keep the SQL-AST around for the purpose of parameter
> > expansion, but maybe there are other reasons to keep it around?
> >
> > Wdyt?
> >
> >
> > Mit freundlichen Grüßen,
> > 
> > *Christian Beikov*
> > Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
> > > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
> > > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
> > >
> > > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
> > > AggregatedSelectQueryPlanImpl
> > > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan
> operates
> > > much like HQLQueryPlan when holding more than one QueryTranslator.
> > >
> > > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
> > > less memory) than QueryTranslator.  And it follows that
> > > AggregatedSelectQueryPlan
> > > ought to consume less memory than HQLQueryPlan+QueryTranslators.
> > >
> > > The other win, which is likely much bigger gain, is that previously
> > > parameter expansions (think `... where x in (:someListOfValues)`)
> > resulted
> > > in separate plans based on the number of values in `someListOfValues` -
> > > more HQLQueryPlan instances for the same HQL.  This is actually one of
> > the
> > > (many) explicit design goals for 6.  The cached plan is the same
> > regardless
> > > of the number of values in `someListOfValues`; the expansion happens
> > during
> > > execution.
> > >
> > > Relatedly, this last part also lets us reuse cached plans in more
> > scenarios
> > > than we do currently: enabled Filters, enabled FetchProfiles, etc.  All
> > of
> > > these things are applied/resolved during execution.  So there is a
> slight
> > > trade off between reducing the number of cached plans versus
> translating
> > > the SQM AST to a SQL AST.  This is important too because often times
> the
> > > query plan cache is "overrun" due to all of the "different cache keys"
> > > aspect (parameter list expansion, filters, etc) - so that often the
> > queries
> > > get pushed from the cache and need complete re-building.
> > >
> > > We cannot really verify this though until Luis, et.al, are able to
> > resume
> > > the performance testing...
> > >
> > > [1]
> > >
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/AggregatedSelectQueryPlanImpl.java
> > > [2]
> > >
> >
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/query/sqm/internal/ConcreteSqmSelectQueryPlan.java
> > >
> > >
> > > On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet <
> guillaume.s...@gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> >From what I can see, the HQLQueryPlan objects are rather big, mostly
> > due
> > >> to
> > >> the sqlAst element of the QueryTranslators.
> > >>
> > >> They can consume a fair amount of memory when you have a lot of HQL
> > >> queries.
> > >>
> > >> We need at least some of the information collected by the AST but I'm
> > >> wondering if we really need to keep all the AST information in memory
> > once
> > >> the query has been parsed and the SQL query generated.
> > >>
> > >> The purpose of this email is mostly to know if this element has been
> > >> accounted for in 6 development?
> > >>
> > >> I haven't checked if it would be doable to improve the situation
> without
> > >> breaking too much stuff in 5.x.
> > >>
> > >> Thanks.
> > >>
> > >> --
> > >> Guillaume
> > >> ___
> > >> hibernate-dev mailing list
> > >> hibernate-dev@lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > > ___

Re: [hibernate-dev] Reducing the memory usage of HQLQueryPlan

[Vlad Mihalcea]

I added support for IN query clause parameter padding:

https://vladmihalcea.com/improve-statement-caching-efficiency-in-clause-parameter-padding/

So, we also support this feature since Hibernate 5.2.18 and 5.3.

Vlad

On Fri, Aug 10, 2018 at 5:34 PM, Steve Ebersole  wrote:

> Unless someone added support for it recently, the padding for IN is not
> for Query handling, it's for batch loading which is a very different
> scenario.  With batch loading we know a finite number of JDBC params - the
> batch size.
>
>
> On Fri, Aug 10, 2018, 9:17 AM Vlad Mihalcea 
> wrote:
>
>> We already have the parameter padding for IN queries, and there's a PR for
>> supplying ARRAY via ANY(?).
>>
>> For the second approach, we just have to test it thoroughly to make sure
>> that all major JDBC Driver support it properly.
>> Also, I'd only have the second approach activated via a config property as
>> I'm not sure how efficient the Execution Plan gets with this approach.
>> That also needs some testing.
>>
>> Vlad
>>
>> On Fri, Aug 10, 2018 at 4:03 PM, Christian Beikov <
>> christian.bei...@gmail.com> wrote:
>>
>> > I'd like to note that with the array rendering strategy i.e. `where x =
>> > ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
>> > the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
>> > necessary to keep the SQL-AST around for the purpose of parameter
>> > expansion, but maybe there are other reasons to keep it around?
>> >
>> > Wdyt?
>> >
>> >
>> > Mit freundlichen Grüßen,
>> > 
>> 
>> > *Christian Beikov*
>> > Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
>> > > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
>> > > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
>> > >
>> > > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
>> > > AggregatedSelectQueryPlanImpl
>> > > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan
>> operates
>> > > much like HQLQueryPlan when holding more than one QueryTranslator.
>> > >
>> > > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence
>> use
>> > > less memory) than QueryTranslator.  And it follows that
>> > > AggregatedSelectQueryPlan
>> > > ought to consume less memory than HQLQueryPlan+QueryTranslators.
>> > >
>> > > The other win, which is likely much bigger gain, is that previously
>> > > parameter expansions (think `... where x in (:someListOfValues)`)
>> > resulted
>> > > in separate plans based on the number of values in `someListOfValues`
>> -
>> > > more HQLQueryPlan instances for the same HQL.  This is actually one of
>> > the
>> > > (many) explicit design goals for 6.  The cached plan is the same
>> > regardless
>> > > of the number of values in `someListOfValues`; the expansion happens
>> > during
>> > > execution.
>> > >
>> > > Relatedly, this last part also lets us reuse cached plans in more
>> > scenarios
>> > > than we do currently: enabled Filters, enabled FetchProfiles, etc.
>> All
>> > of
>> > > these things are applied/resolved during execution.  So there is a
>> slight
>> > > trade off between reducing the number of cached plans versus
>> translating
>> > > the SQM AST to a SQL AST.  This is important too because often times
>> the
>> > > query plan cache is "overrun" due to all of the "different cache keys"
>> > > aspect (parameter list expansion, filters, etc) - so that often the
>> > queries
>> > > get pushed from the cache and need complete re-building.
>> > >
>> > > We cannot really verify this though until Luis, et.al, are able to
>> > resume
>> > > the performance testing...
>> > >
>> > > [1]
>> > > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
>> > hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
>> > AggregatedSelectQueryPlanImpl.java
>> > > [2]
>> > > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
>> > hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
>> > ConcreteSqmSelectQueryPlan.java
>> > >
>> > >
>> > > On 

Re: [hibernate-dev] Reducing the memory usage of HQLQueryPlan

[Vlad Mihalcea]

We already have the parameter padding for IN queries, and there's a PR for
supplying ARRAY via ANY(?).

For the second approach, we just have to test it thoroughly to make sure
that all major JDBC Driver support it properly.
Also, I'd only have the second approach activated via a config property as
I'm not sure how efficient the Execution Plan gets with this approach.
That also needs some testing.

Vlad

On Fri, Aug 10, 2018 at 4:03 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> I'd like to note that with the array rendering strategy i.e. `where x =
> ANY(?)` and the padding strategy i.e. pad the JDBC params, we can reduce
> the cache trashing and avoid re-walking of the SQL-AST. IMO it's not
> necessary to keep the SQL-AST around for the purpose of parameter
> expansion, but maybe there are other reasons to keep it around?
>
> Wdyt?
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 09.08.2018 um 16:57 schrieb Steve Ebersole:
> > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImpl[1]
> > (polymorphic queries) and ConcreteSqmSelectQueryPlan[2].
> >
> > ConcreteSqmSelectQueryPlan holds a reference to the SQM AST;
> > AggregatedSelectQueryPlanImpl
> > hold 2+ ConcreteSqmSelectQueryPlans.  AggregatedSelectQueryPlan operates
> > much like HQLQueryPlan when holding more than one QueryTranslator.
> >
> > ConcreteSqmSelectQueryPlan ought to hold much less state (and hence use
> > less memory) than QueryTranslator.  And it follows that
> > AggregatedSelectQueryPlan
> > ought to consume less memory than HQLQueryPlan+QueryTranslators.
> >
> > The other win, which is likely much bigger gain, is that previously
> > parameter expansions (think `... where x in (:someListOfValues)`)
> resulted
> > in separate plans based on the number of values in `someListOfValues` -
> > more HQLQueryPlan instances for the same HQL.  This is actually one of
> the
> > (many) explicit design goals for 6.  The cached plan is the same
> regardless
> > of the number of values in `someListOfValues`; the expansion happens
> during
> > execution.
> >
> > Relatedly, this last part also lets us reuse cached plans in more
> scenarios
> > than we do currently: enabled Filters, enabled FetchProfiles, etc.  All
> of
> > these things are applied/resolved during execution.  So there is a slight
> > trade off between reducing the number of cached plans versus translating
> > the SQM AST to a SQL AST.  This is important too because often times the
> > query plan cache is "overrun" due to all of the "different cache keys"
> > aspect (parameter list expansion, filters, etc) - so that often the
> queries
> > get pushed from the cache and need complete re-building.
> >
> > We cannot really verify this though until Luis, et.al, are able to
> resume
> > the performance testing...
> >
> > [1]
> > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
> AggregatedSelectQueryPlanImpl.java
> > [2]
> > https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> hibernate-core/src/main/java/org/hibernate/query/sqm/internal/
> ConcreteSqmSelectQueryPlan.java
> >
> >
> > On Thu, Aug 9, 2018 at 9:21 AM Guillaume Smet 
> > wrote:
> >
> >> Hi,
> >>
> >> >From what I can see, the HQLQueryPlan objects are rather big, mostly
> due
> >> to
> >> the sqlAst element of the QueryTranslators.
> >>
> >> They can consume a fair amount of memory when you have a lot of HQL
> >> queries.
> >>
> >> We need at least some of the information collected by the AST but I'm
> >> wondering if we really need to keep all the AST information in memory
> once
> >> the query has been parsed and the SQL query generated.
> >>
> >> The purpose of this email is mostly to know if this element has been
> >> accounted for in 6 development?
> >>
> >> I haven't checked if it would be doable to improve the situation without
> >> breaking too much stuff in 5.x.
> >>
> >> 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
> ___
> 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] 5.3 cache issues [Requires Steve]

[Vlad Mihalcea]

The short name approach sounds goid and would accommodate any future cache
region implementation changes.

For 5.3, I'd say we allow the old named to be resolved to the new ones,
like symbolic links.

This will allow users to migrate to 5.3 without changing existing
ehcache.xml configs.

We could write a log WARN for 5.3 and stop supporting old region names in
6.x.

Vlad



On Mon, 2 Jul 2018, 23:00 Steve Ebersole,  wrote:

> Changing the name of the default query results cache I can see being a
> problem in retrospect.  That is something the user might want to
> configure.
>
> I am much less convinced about the update-timestamps cache.  I guess it
> would depend on what they are configuring.
>
> Overall what I would suggest is a hybrid approach where we move to a "short
> name" solution much like we have for most other config values.  So, e.g.,
> the name of the default query result region would be
> `default-query-result-region`.  We could then have the providers understand
> that "magic value" and have them look for configs under either names they
> wish (temporarily which Emmanuel suggested, if that's what we want) - we'd
> change our OOTB providers to look for all three names.
>
> On Mon, Jul 2, 2018 at 10:12 AM Guillaume Smet 
> wrote:
>
> > Hi all,
> >
> > So following our off-list discussions , I wanted to share a document we
> > wrote with Yoann with some details about the usability/compatibility of
> the
> > new cache implementation in 5.3:
> >
> >
> https://docs.google.com/document/d/19xmsWlYOkXeAnZlEjcxFy6SUitxmT1JywoDyX22TrvE/edit?usp=sharing
> >
> > (The document should be public and everyone should be able to comment)
> >
> > We tried to be as detailed as possible. What we need to decide is in
> > bold/red as Actions.
> >
> > The idea is to act on it for 5.3.2 so before Thursday. The PR for the
> first
> > issue is mostly ready but will require some tuning depending on our
> > decisions, we still need to work on the second one depending on the
> > outcome.
> >
> > Everyone interested/concerned, please step in so that we can reach a
> > consensus quickly and merge what is appropriate.
> >
> > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM progress: tricky branch state

[Vlad Mihalcea]

If 5.3 cannot take new features, it's better to branch it and have a 5.4
branch for the master until 6.0 is ready.

There are lots of interesting improvements that are provided via PRs or as
suggestions on  the forum, so it would be detrimental to our users to delay
those until 6.0 can be used in production.

Vlad

On Mon, 2 Jul 2018, 18:48 Sanne Grinovero,  wrote:

> On Hibernate ORM we're currently having "master" branch essentially
> being a maintenance branch, aka master today is what's planned to be
> version 5.3.2.Final in some days, 5.3.3 later, etc..
>
> This is quite unusual, and it begs some extra attention: normally we'd
> start a new minor in master, so that PRs of any kind could be welcome
> in master, while specific, cherry-picked fixes are backported to the
> last maintained minors.
>
> This is not the case now and until we move on to a new minor or major
> we'll need to be particularly careful about what is allowed to be
> merged.
> I'm not pointing fingers to any specific commit, my concern is just
> raised by the high volume of changes being merged. They all look great
> individually but changes are not good at this point :)
>
> Not sure what to suggest to people wanting to contribute new features
> today; maybe hold as we assume the 6.0 work will be merged in master
> soon? Will be hard to say no to many reasonable requests though.
>
> Steve, do you think that the 6.0 merge could happen soon enough to not
> need any process changes in how  we deal with master?
>
> 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] Hibernate ORM 5.2.18 to be the last in 5.2 series?

[Vlad Mihalcea]

+1.

Unless there will be some serious issues that call for a 5.2.19 release, we
should focus on 5.3.

Vlad

On Wed, Jun 6, 2018 at 3:45 PM, Steve Ebersole  wrote:

> +1 to stopping 5.2 releases.
>
> On Wed, Jun 6, 2018 at 7:40 AM Guillaume Smet 
> wrote:
>
> > On Tue, Jun 5, 2018 at 10:33 PM Gail Badner  wrote:
> >
> > > Chris mentioned that he is planning to release 5.2.18 on Thursday.
> > >
> >
> > It would be nice if we could get
> > https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
> > 5.2.18, considering it's a regression introduced after 5.2.13. If we
> didn't
> > expect 5.2.18 to be the last 5.2, I wouldn't ask.
> >
> > I don't know if Christian has some bandwidth to take a look as it seems
> > related to his prior work.
> >
> > --
> > 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] Health check status API

[Vlad Mihalcea]

We could do it via the Statistics mechanism which can be made available via
JMX.

We just have to add whatever info they are interested in to monitor.

Vlad

On Thu, May 31, 2018 at 7:40 PM, Sanne Grinovero 
wrote:

> It was suggested to me that Hibernate ORM could help people developing
> microservices on Kubernetes / Openshift by making "health checks"
> easier.
>
> In short, how to expose to some management API that we're being able
> to connect to the database and do our usual things.
>
> This could be done by connection pools as well but I suspect there
> could be benefits in exposing this information in a unified way at an
> higher level API; also on top of using ad-hoc specific connection
> APIs, or Dialect specific instructions, I guess we could monitor
> timeout exceptions, etc.. happening on the application sessions.
>
> Wrote some notes on:
>  - https://hibernate.atlassian.net/browse/HHH-12655
>
> Probably best to explore this in ORM first, but then Search and OGM
> could expose/implement it too for their respective services?
>
> Or maybe people would prefer to just run a query?
>
> 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] Auto-registering the cacheable entities and collections

[Vlad Mihalcea]

Hi,

While upgrading my Hibernate testing repository to 5.3, I realized that we
no longer auto-register the 2nd-level cache for entities and the
collections even if those are annotated with the Hibernate @Cache
annotation.

I noticed that the Hibernate tests have been modified and we require to
register those manually:

for ( Map.Entry entry : getCachedClasses().entrySet() ) {
config.put( AvailableSettings.CLASS_CACHE_PREFIX + "." +
entry.getKey().getName(), entry.getValue() );
}
for ( Map.Entry entry : getCachedCollections().entrySet() )
{
config.put( AvailableSettings.COLLECTION_CACHE_PREFIX + "." +
entry.getKey(), entry.getValue() );
}

Now, if I don't do that, I get the following exception:

Caused by: org.hibernate.cache.CacheException: On-the-fly creation of
JCache Cache objects is not supported
[com.vladmihalcea.book.hpjp.hibernate.cache.query.QueryCacheTest$Post.comments]
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.createCache(EhcacheRegionFactory.java:106)
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.getOrCreateCache(EhcacheRegionFactory.java:100)
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.createDomainDataStorageAccess(EhcacheRegionFactory.java:71)
at
org.hibernate.cache.spi.support.RegionFactoryTemplate.buildDomainDataRegion(RegionFactoryTemplate.java:31)
at
org.hibernate.cache.internal.EnabledCaching.prime(EnabledCaching.java:108)
at
org.hibernate.metamodel.internal.MetamodelImpl.primeSecondLevelCacheRegions(MetamodelImpl.java:284)
at
org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:116)
at
org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:295)
at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)


However, I don't even use JCache. I use "ehcache" instead.

properties.put("hibernate.cache.region.factory_class", "ehcache");

Was a JCache requirement?

Can we auto-register the entities and collections for other cache providers?

I'm worried about all those applications trying to upgrade to 5.3. Imagine
if they have hundreds of entities and collections. People will surely start
complaining if we force them to do that manually during bootstrap. More,
I'm not sure how they can do when they just bootstrap via a JPA
persistence.xml configuration file.

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

Re: [hibernate-dev] Unidirectional @OneToMany @JoinColumn associations

[Vlad Mihalcea]

Hi,

For the OneToMany with @JoinColumn, the user can workaround this limitation
by just using the @ManyToOne on the child side on any column they want
and turning the unidirectional association into a bidirectional one. I
remember I tested it and it worked just fine.

For the  OneToMany with @JoinTable, the only workaround would be if they
map the join table as an entity and use the @ManyToOne on the columns they
want
the association to be based on.

Since unidirectional associations don't perform that well, I'm not sure
whether it's worth adding support for these use cases.

Vlad

On Wed, May 30, 2018 at 9:32 AM, Gail Badner  wrote:

> Unidirectional OneToMany associations using @JoinColumn that reference
> columns that are not PK columns is not currently supported.
>
> The JPA 2.1 documentation for @JoinTable says:
>
> "Support for referenced columns that are not primary key columns of the
> referenced table is optional. Applications that use such mappings will not
> be portable."
>
> I don't see anything in the user doc that explicitly states that Hibernate
> does not support this.
>
> Is this considered a bug?
>
> Also, what about a unidirectional OneToMany using a @JoinColumn that
> references some, but not all, of primary key columns? Hibernate does not
> support that either. Should Hibernate support it since they are primary key
> columns?
>
> 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-orm-modules nmartifacts not publish

[Vlad Mihalcea]

Thanks. I will have to look if we have some outdated docs pointing to the
old artefact.

On Tue, 29 May 2018, 18:21 Chris Cranford,  wrote:

> I believe we renamed it to `hibernate-orm-jbossmodules` in 5.3.0.CR2 as I
> see that with 5.3.1.Final too.
>
> On 05/29/2018 10:59 AM, Vlad Mihalcea wrote:
>
> I checked this forum question:
> https://discourse.hibernate.org/t/org-hibernate-hibernate-orm-modules-no-longer-published/861/2
>
> And, indeed, the Hibernate-orm-modules artefacts are missing from Maven
> Central.
>
> Was this intentional or do we have a problem related to publishing them?
>
> Vlad
> ___
> hibernate-dev mailing 
> listhibernate-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate-orm-modules nmartifacts not publish

[Vlad Mihalcea]

I checked this forum question:

https://discourse.hibernate.org/t/org-hibernate-hibernate-orm-modules-no-longer-published/861/2

And, indeed, the Hibernate-orm-modules artefacts are missing from Maven
Central.

Was this intentional or do we have a problem related to publishing them?

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

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Vlad Mihalcea]

I named it MetadataBuilderContributor because you can do more than just
registering SqlFunctions. While implementing it, I realized that, this way,
it's going to be very flexible to customize the Hibernate-native Metadata
while doing the JPA bootstrap.

Related to ManagedBeanRegitry, I'm trying to convert to using it, but
stumbled on this issue.

If I try to get a Bean like this:

managedBeanRegistry.getBean( MetadataBuilderContributor.class );

And there is no BeanContainer set via "hibernate.resource.beans.container",
then the FallbackContainedBean is used, which tries to instantiate the
provided interface:

beanType.newInstance();

But since I provide an interface, the call will fail.

The only workaround I found is this:

ManagedBeanRegistry managedBeanRegistry = standardServiceRegistry
.getService( ManagedBeanRegistry.class );

BeanContainer beanContainer = managedBeanRegistry.getBeanContainer();

ManagedBean
metadataBuilderContributorManagedBean = null;
if ( beanContainer != null ) {
metadataBuilderContributorManagedBean = managedBeanRegistry
.getBean( MetadataBuilderContributor.class );
}

MetadataBuilderContributor metadataBuilderContributor =
metadataBuilderContributorManagedBean
.getBeanInstance();

Am I using it the wrong way, or do we need to check the BeanContainer first
to make sure it's not null before getting a Bean from the
ManagedBeanRegistry?

Vlad


On Thu, May 17, 2018 at 9:07 PM, Steve Ebersole  wrote:

> Personally I think both a contributor and CDI integration
> (ManagedBeanRegitry) make sense here.  Btw, the name for the contributor
> should not be SqlFunctionContributor - it should reflect the ultimate goal
> here which is SqmFunctionTemplate; I can see SqmFunctionContributor or just
> FunctionContributor.  This is an example of what I meant about waiting for
> 6...
>
> On Thu, May 17, 2018 at 12:50 PM Vlad Mihalcea 
> wrote:
>
>> Sure thing. I'll try to adapt it to using the Bean registry.
>>
>> Vlad
>>
>> On Thu, 17 May 2018, 20:07 Chris Cranford,  wrote:
>>
>> > I personally agree with Christian, I don't see the use of the
>> > ManagedBeanRegistry being a problem.  The new interface certainly opens
>> > the door for a variety of builder settings to be contributed easily and
>> > using the registry allows for a versatile way to provide that bean,
>> > whether it be through some CDI/Spring environment or the fallback
>> > solution where we instantiate it ourselves.  I believe the code as you
>> > have it can easily be adapted to use the registry by replacing the
>> > "newInstance()" call with a call into getting the bean from the
>> > registry.  The registry itself internally should handle getting the bean
>> > from the container or returning you a new instance we instantiate
>> > ourselves.
>> >
>> > On 05/17/2018 12:25 PM, Christian Beikov wrote:
>> > > The functions could be contributed via a CDI/Spring bean which might
>> not
>> > > be such a bad idea I think. In a test environment there could be a
>> > > different contributor active than in production. Of course, this could
>> > > also be handled by passing in different configuration property values,
>> > > but that's why I was saying I'm not sure about it. Maybe someone else
>> > > has an idea if using ManagedBeanRegistry might make sense?
>> > >
>> > >
>> > > Mit freundlichen Grüßen,
>> > > 
>> 
>> > > *Christian Beikov*
>> > > Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
>> > >> Hi,
>> > >>
>> > >> Looking at the SessionFactoryImpl class, the only way to provide an
>> > >> SqlFunction is either via the Dialect or via the
>> SessionFactoryOptions:
>> > >> this.sqlFunctionRegistry  =new SQLFunctionRegistry(
>> > jdbcServices.getJdbcEnvironment().getDialect(),
>> > options.getCustomSqlFunctionMap() );
>> > >> I'm not sure if the ManagedBeanRegistry would have helped in this
>> case
>> > >> without requiring more code changes.
>> > >>
>> > >> Vlad
>> > >>
>> > >> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov
>> > >> mailto:christian.bei...@gmail.com>>
>> wrote:
>> > >>
>> > >> It looks ok to me although I'm not sure if it wouldn't be more
>> > >> appropriate to instantiate the contributor via
>> ManagedBeanRegistry.
>> > >>
>

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Vlad Mihalcea]

Sure thing. I'll try to adapt it to using the Bean registry.

Vlad

On Thu, 17 May 2018, 20:07 Chris Cranford,  wrote:

> I personally agree with Christian, I don't see the use of the
> ManagedBeanRegistry being a problem.  The new interface certainly opens
> the door for a variety of builder settings to be contributed easily and
> using the registry allows for a versatile way to provide that bean,
> whether it be through some CDI/Spring environment or the fallback
> solution where we instantiate it ourselves.  I believe the code as you
> have it can easily be adapted to use the registry by replacing the
> "newInstance()" call with a call into getting the bean from the
> registry.  The registry itself internally should handle getting the bean
> from the container or returning you a new instance we instantiate
> ourselves.
>
> On 05/17/2018 12:25 PM, Christian Beikov wrote:
> > The functions could be contributed via a CDI/Spring bean which might not
> > be such a bad idea I think. In a test environment there could be a
> > different contributor active than in production. Of course, this could
> > also be handled by passing in different configuration property values,
> > but that's why I was saying I'm not sure about it. Maybe someone else
> > has an idea if using ManagedBeanRegistry might make sense?
> >
> >
> > Mit freundlichen Grüßen,
> > ----
> > *Christian Beikov*
> > Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
> >> Hi,
> >>
> >> Looking at the SessionFactoryImpl class, the only way to provide an
> >> SqlFunction is either via the Dialect or via the SessionFactoryOptions:
> >> this.sqlFunctionRegistry  =new SQLFunctionRegistry(
> jdbcServices.getJdbcEnvironment().getDialect(),
> options.getCustomSqlFunctionMap() );
> >> I'm not sure if the ManagedBeanRegistry would have helped in this case
> >> without requiring more code changes.
> >>
> >> Vlad
> >>
> >> On Thu, May 17, 2018 at 5:22 PM, Christian Beikov
> >> mailto:christian.bei...@gmail.com>> wrote:
> >>
> >> It looks ok to me although I'm not sure if it wouldn't be more
> >> appropriate to instantiate the contributor via ManagedBeanRegistry.
> >>
> >>
> >> Mit freundlichen Grüßen,
> >>
>  
> >> *Christian Beikov*
> >> Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
> >> > In the end, I thought of a more generic approach to for JPA
> >> bootstrapping
> >> > which, not only allows us to register SqlFunctions, but we can
> >> apply other
> >> > changes on the MetadataBuilder object used during bootstrap.
> >> >
> >> > This is the Pull Request:
> >> >
> >> > https://github.com/hibernate/hibernate-orm/pull/2288
> >> <https://github.com/hibernate/hibernate-orm/pull/2288>
> >> >
> >> > Let me know what you think.
> >> >
> >> > Vlad
> >> >
> >> > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole
> >> mailto:st...@hibernate.org>> wrote:
> >> >
> >> >> Its not so much hindering 6.0 that I am concerned with.  The
> >> problem is
> >> >> updatability for the user.  The more things they use that
> >> change = the more
> >> >> work to upgrade.
> >> >>
> >> >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea
> >> mailto:mihalcea.v...@gmail.com>>
> >> >> wrote:
> >> >>
> >> >>> I suppose this will be refactored considerably in 6.x.
> >> >>>
> >> >>> However, it's just a small change and I don't think it will
> >> hinder any
> >> >>> 6.x changes.
> >> >>>
> >> >>> I'm thinking of defining an SqlFunctionContributor interface
> >> >>> (@FunctionalInterface)
> >> >>> which can be provided via the properties Map that's supplied
> >> when using
> >> >>> the Persistence#createEntityManagerFactory method.
> >> >>>
> >> >>> In EntityManagerFactoryBuilder, I can just inspect that and
> >> pass it
>

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Vlad Mihalcea]

Hi,

Looking at the SessionFactoryImpl class, the only way to provide an
SqlFunction is either via the Dialect or via the SessionFactoryOptions:

this.sqlFunctionRegistry = new SQLFunctionRegistry(
jdbcServices.getJdbcEnvironment().getDialect(),
options.getCustomSqlFunctionMap() );

I'm not sure if the ManagedBeanRegistry would have helped in this case
without requiring more code changes.

Vlad

On Thu, May 17, 2018 at 5:22 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> It looks ok to me although I'm not sure if it wouldn't be more
> appropriate to instantiate the contributor via ManagedBeanRegistry.
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
> > In the end, I thought of a more generic approach to for JPA bootstrapping
> > which, not only allows us to register SqlFunctions, but we can apply
> other
> > changes on the MetadataBuilder object used during bootstrap.
> >
> > This is the Pull Request:
> >
> > https://github.com/hibernate/hibernate-orm/pull/2288
> >
> > Let me know what you think.
> >
> > Vlad
> >
> > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole 
> wrote:
> >
> >> Its not so much hindering 6.0 that I am concerned with.  The problem is
> >> updatability for the user.  The more things they use that change = the
> more
> >> work to upgrade.
> >>
> >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea 
> >> wrote:
> >>
> >>> I suppose this will be refactored considerably in 6.x.
> >>>
> >>> However, it's just a small change and I don't think it will hinder any
> >>> 6.x changes.
> >>>
> >>> I'm thinking of defining an SqlFunctionContributor interface
> >>> (@FunctionalInterface)
> >>> which can be provided via the properties  Map that's supplied when
> using
> >>> the Persistence#createEntityManagerFactory method.
> >>>
> >>> In EntityManagerFactoryBuilder, I can just inspect that and pass it
> >>> further to MetamodelBuilder.
> >>>
> >>> So, it does not take any effort to implement it and users can benefit
> >>> from it. I recently answered a question on the forum on this topic:
> >>>
> >>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
> >>> in-queries/752/14
> >>>
> >>> And, realized that I was wrong about suggesting doing it via the
> >>> Integrator mechanism (since the Metamodel is already frozen by the
> time we
> >>> execute the Integrator).
> >>>
> >>> Vlad
> >>>
> >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole 
> >>> wrote:
> >>>
> >>>> This should maybe wait for 6.0.  We are ditching SQLFunction in favor
> of
> >>>> a more AST-friendly contract.
> >>>>
> >>>> Beyond that, go for it.
> >>>>
> >>>>
> >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea 
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I realized that only the native Hibernate bootstrapping mechanism
> allows
> >>>>> for passing custom SQL functions.
> >>>>>
> >>>>> For JPA, we can extend the Dialect to register, but that's not always
> >>>>> desirable as it requires a code change
> >>>>> every time the user switches to a new Dialect version.
> >>>>>
> >>>>> For this reason, I created this Jira issue:
> >>>>>
> >>>>> https://hibernate.atlassian.net/browse/HHH-12589
> >>>>>
> >>>>> Let me know if anyone has anything against implementing this feature.
> >>>>>
> >>>>> Vlad
> >>>>> ___
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev@lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev 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] Simplify SQL function registration when bootstrapping via JPA

[Vlad Mihalcea]

In the end, I thought of a more generic approach to for JPA bootstrapping
which, not only allows us to register SqlFunctions, but we can apply other
changes on the MetadataBuilder object used during bootstrap.

This is the Pull Request:

https://github.com/hibernate/hibernate-orm/pull/2288

Let me know what you think.

Vlad

On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole  wrote:

> Its not so much hindering 6.0 that I am concerned with.  The problem is
> updatability for the user.  The more things they use that change = the more
> work to upgrade.
>
> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea 
> wrote:
>
>> I suppose this will be refactored considerably in 6.x.
>>
>> However, it's just a small change and I don't think it will hinder any
>> 6.x changes.
>>
>> I'm thinking of defining an SqlFunctionContributor interface
>> (@FunctionalInterface)
>> which can be provided via the properties  Map that's supplied when using
>> the Persistence#createEntityManagerFactory method.
>>
>> In EntityManagerFactoryBuilder, I can just inspect that and pass it
>> further to MetamodelBuilder.
>>
>> So, it does not take any effort to implement it and users can benefit
>> from it. I recently answered a question on the forum on this topic:
>>
>> https://discourse.hibernate.org/t/i-cant-use-group-concat-
>> in-queries/752/14
>>
>> And, realized that I was wrong about suggesting doing it via the
>> Integrator mechanism (since the Metamodel is already frozen by the time we
>> execute the Integrator).
>>
>> Vlad
>>
>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole 
>> wrote:
>>
>>> This should maybe wait for 6.0.  We are ditching SQLFunction in favor of
>>> a more AST-friendly contract.
>>>
>>> Beyond that, go for it.
>>>
>>>
>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I realized that only the native Hibernate bootstrapping mechanism allows
>>>> for passing custom SQL functions.
>>>>
>>>> For JPA, we can extend the Dialect to register, but that's not always
>>>> desirable as it requires a code change
>>>> every time the user switches to a new Dialect version.
>>>>
>>>> For this reason, I created this Jira issue:
>>>>
>>>> https://hibernate.atlassian.net/browse/HHH-12589
>>>>
>>>> Let me know if anyone has anything against implementing this feature.
>>>>
>>>> Vlad
>>>> ___
>>>> hibernate-dev mailing list
>>>> hibernate-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Vlad Mihalcea]

I suppose this will be refactored considerably in 6.x.

However, it's just a small change and I don't think it will hinder any 6.x
changes.

I'm thinking of defining an SqlFunctionContributor interface
(@FunctionalInterface)
which can be provided via the properties  Map that's supplied when using
the Persistence#createEntityManagerFactory method.

In EntityManagerFactoryBuilder, I can just inspect that and pass it further
to MetamodelBuilder.

So, it does not take any effort to implement it and users can benefit from
it. I recently answered a question on the forum on this topic:

https://discourse.hibernate.org/t/i-cant-use-group-concat-in-queries/752/14

And, realized that I was wrong about suggesting doing it via the Integrator
mechanism (since the Metamodel is already frozen by the time we execute the
Integrator).

Vlad

On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole  wrote:

> This should maybe wait for 6.0.  We are ditching SQLFunction in favor of a
> more AST-friendly contract.
>
> Beyond that, go for it.
>
>
> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> I realized that only the native Hibernate bootstrapping mechanism allows
>> for passing custom SQL functions.
>>
>> For JPA, we can extend the Dialect to register, but that's not always
>> desirable as it requires a code change
>> every time the user switches to a new Dialect version.
>>
>> For this reason, I created this Jira issue:
>>
>> https://hibernate.atlassian.net/browse/HHH-12589
>>
>> Let me know if anyone has anything against implementing this feature.
>>
>> Vlad
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Vlad Mihalcea]

Hi,

I realized that only the native Hibernate bootstrapping mechanism allows
for passing custom SQL functions.

For JPA, we can extend the Dialect to register, but that's not always
desirable as it requires a code change
every time the user switches to a new Dialect version.

For this reason, I created this Jira issue:

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

Let me know if anyone has anything against implementing this feature.

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

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Vlad Mihalcea]

I asked because someone might have an idea about some change that was doe
in 5.3 that might affect it.
For the moment, I haven't started doing anything about it.

Vlad

On Thu, May 3, 2018 at 2:01 PM, Guillaume Smet 
wrote:

> On Thu, May 3, 2018 at 9:35 AM, Vlad Mihalcea 
> wrote:
>
>> I think it's worth investigating the cause and see how we could address it
>> in the next release.
>>
>
> Sure, something looks fishy there.
>
> Will you do it or do you expect someone else to do it? It's not very clear
> from your email.
>
> --
> Guillaume
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Vlad Mihalcea]

Hi,

On Discourse, a user told us that the memory footprint has increased
dramatically between 5.2 and 5.3:

https://discourse.hibernate.org/t/batch-fetch-style-recommendations/631/5?u=vlad

I think it's worth investigating the cause and see how we could address it
in the next release.

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

Re: [hibernate-dev] Why do we have the date in the URL of blog posts?

[Vlad Mihalcea]

I also switched my blog from dates to simple slugs at the beginning of the
year.

As long as you add the proper Redirection rules in .htaccess_posts, it
shouldn't be any problem.

Google does not penalize 301 redirects, so you don't lose any SEO ranking
if you use 301 redirects.

We can also change the slug names for new articles only while leaving the
old ones as-is.

Vlad

On Thu, Mar 22, 2018 at 2:24 PM, Yoann Rodiere  wrote:

> > The data in the post slug only makes sense for news sites where posts are
> highly associated to a given date.
>
> A lot of our posts are. Release announcements and weekly newsletters in
> particular.
>
> I personally don't see the problem with dates in URLs. I don't see any
> problem with not having them, either. But I do see a problem with changing
> the URL scheme: potential dead links, SEO nightmare... We would need a damn
> good reason to do it, and I'm not sure those you mentioned are enough...
>
> On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> The data in the post slug only makes sense for news sites where posts are
>> highly associated to a given date.
>>
>> In our case, the data works against us as people might think an article is
>> outdated by just inspecting the slug and thinking that
>> a 3 year-old article might not be relevant anymore.
>>
>> It's better if we use simple slug names that capture the article focus
>> keywords and remove the date altogether.
>>
>> Vlad
>>
>> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling 
>> wrote:
>>
>> > Hi,
>> >
>> > While talking to a few bloggers from the Java ecosphere at JavaLand last
>> > week, the question came up why we have the date in the URL of blog
>> posts.
>> >
>> > Arguably, it doesn't add value there (we show the date on the actual
>> posts
>> > themselves), and makes the URLs slightly worse to read. In particular,
>> we
>> > don't allow for browsing posts by year or month (e.g.
>> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting
>> the
>> > date would also make the original idea of the URL fly again ("in
>> relation
>> > to xyz").
>> >
>> > Anyone with thoughts whether we should change the scheme (keeping
>> existing
>> > ones of course)?
>> >
>> > That all said, I've no idea whether the date in there is good to have or
>> > not in terms of SEO. I suppose it doesn't matter.
>> >
>> > --Gunnar
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> 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] Why do we have the date in the URL of blog posts?

[Vlad Mihalcea]

Hi,

The data in the post slug only makes sense for news sites where posts are
highly associated to a given date.

In our case, the data works against us as people might think an article is
outdated by just inspecting the slug and thinking that
a 3 year-old article might not be relevant anymore.

It's better if we use simple slug names that capture the article focus
keywords and remove the date altogether.

Vlad

On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling 
wrote:

> Hi,
>
> While talking to a few bloggers from the Java ecosphere at JavaLand last
> week, the question came up why we have the date in the URL of blog posts.
>
> Arguably, it doesn't add value there (we show the date on the actual posts
> themselves), and makes the URLs slightly worse to read. In particular, we
> don't allow for browsing posts by year or month (e.g.
> http://in.relation.to/2018/), so it's even a bit misleading. Omitting the
> date would also make the original idea of the URL fly again ("in relation
> to xyz").
>
> Anyone with thoughts whether we should change the scheme (keeping existing
> ones of course)?
>
> That all said, I've no idea whether the date in there is good to have or
> not in terms of SEO. I suppose it doesn't matter.
>
> --Gunnar
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Defaultable service strategies

[Vlad Mihalcea]

Sounds good to me.

Vlad

On Wed, 21 Mar 2018, 20:48 Steve Ebersole,  wrote:

> Thoughts on allowing certain services to be defaulted to the single
> implementor registered with the `StrategySelector` service when there is
> just one?
>
> For example, when resolving the RegionFactory unless both (a)
> `hibernate.cache.region.factory_class` and (b) one of
> `hibernate.cache.use_second_level_cache` or
> `hibernate.cache.use_query_cache` are defined caching support will be
> disabled.  What I am proposing would kick in in this case and check to see
> if there is just a single RegionFactory registered with the
> StrategySelector and if so use that one.
>
> It would allow Hibernate to more seamlessly operate as a JPA provider too,
> as currently to use caching with JPA and Hibernate users have to do the
> normal JPA stuff and then also define these Hibernate settings.  It would
> be nicer if they could just do the JPA stuff.
> ___
> 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] Null-Pointer Exception with 5.2.14

[Vlad Mihalcea]

Hi Petar,

You can use this template:

http://in.relation.to/2016/01/14/hibernate-jpa-test-case-template/

to create a test case that replicates the issue. You don't need to provide
all entities,
just the 4 entities that build that hierarchy you have mentioned in your
email.

If you can replicate it, please open a Jira issue and attach the test case
so that it's easier
to investigate the cause and provide a fix.

Thanks,
Vlad

On Thu, Mar 1, 2018 at 10:41 AM, Petar Tahchiev 
wrote:

> Hi Christian,
>
> My model has more than 250 entities big. Here's the code that throws the
> NLP:
>
> Class c1 = clazz1.getMappedClass();
> Class c2 = commonPersistentClass.getMappedClass();
> MappedSuperclass commonMappedSuperclass = null;
>
> // First we traverse up the clazz2/commonPersistentClass super types
> until we find a common type
> while ( !c2.isAssignableFrom( c1 ) ) {
>if ( commonPersistentClass == null) {
>   if ( commonMappedSuperclass.getSuperPersistentClass() == null )
> {// < NLPEX happens here!!
>  commonMappedSuperclass =
> commonMappedSuperclass.getSuperMappedSuperclass();
>  commonPersistentClass = null;
>   }
>   else {
>  commonPersistentClass =
> commonMappedSuperclass.getSuperPersistentClass();
>  commonMappedSuperclass = null;
>   }
>}
>else {
>   if ( commonPersistentClass.getSuperclass() == null ) {
>  commonMappedSuperclass =
> commonPersistentClass.getSuperMappedSuperclass();
>  commonPersistentClass = null;
>   }
>   else {
>  commonPersistentClass = commonPersistentClass.getSuperclass();
>  commonMappedSuperclass = null;
>   }
>}
> }
>
> As you can see the commonMappedSuperclass is not initialized and stays
> null!
> At this moment c1 is CustomerEntity and c2 is UserGroupEntity. The
> hierarchy looks like this:
>
>  Principal
>/  \
> UsergroupUser
> |
>Customer
>
> HTH
>
>
>
> 2018-02-28 21:52 GMT+02:00 Christian Beikov :
>
> > Hey, I saw the comment on the issue. Thanks for reporting. Could you
> > maybe post the model that causes this? I'd need to create a reproducer
> > to be able to analyze this further.
> >
> >
> > Mit freundlichen Grüßen,
> > 
> > *Christian Beikov*
> > Am 28.02.2018 um 20:11 schrieb Petar Tahchiev:
> > > Hi guys,
> > > I have this exception with latest 5.2.14 (my project runs fine with
> > 5.2.13):
> > >
> > > Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
> > > default] Unable to build Hibernate SessionFactory
> > >  at
> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImp
> > l.persistenceException(EntityManagerFactoryBuilderImpl.java:970)
> > >  at
> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(
> > EntityManagerFactoryBuilderImpl.java:895)
> > >  at
> > > org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceP
> > rovider.createContainerEntityManagerFactory(
> SpringHibernateJpaPersistenceP
> > rovider.java:57)
> > >  at
> > > org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.
> > createNativeEntityManagerFactory(LocalContainerEntityManagerFac
> > toryBean.java:365)
> > >  at
> > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.
> > buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBe
> an.java:387)
> > >  at
> > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBe
> > an.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376)
> > >  at
> > > org.springframework.orm.jpa.LocalContainerEntityManagerFac
> > toryBean.afterPropertiesSet(LocalContainerEntityManagerFac
> > toryBean.java:341)
> > >  at
> > > org.springframework.beans.factory.support.
> AbstractAutowireCapableBeanFac
> > tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
> > >  at
> > > org.springframework.beans.factory.support.
> AbstractAutowireCapableBeanFac
> > tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
> > >  ... 32 more
> > > Caused by: org.hibernate.MappingException: Could not instantiate
> > persister
> > > org.hibernate.persister.entity.SingleTableEntityPersister
> > >  at
> > > org.hibernate.persister.internal.PersisterFactoryImpl.
> > createEntityPersister(PersisterFactoryImpl.java:112)
> > >  at
> > > org.hibernate.persister.internal.PersisterFactoryImpl.
> > createEntityPersister(PersisterFactoryImpl.java:77)
> > >  at
> > > org.hibernate.metamodel.internal.MetamodelImpl.
> > initialize(MetamodelImpl.java:128)
> > >  at
> > > org.hibernate.internal.SessionFactoryImpl.(
> > SessionFactoryImpl.java:300)
> > >  at
> > > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(
> > SessionFactoryBuilderImpl.java:460)
> > >  at
> > > org.hibernate.jpa.boot.internal.Entit

Re: [hibernate-dev] Why does implicit join translate to inner join?

[Vlad Mihalcea]

Hi,

Maybe Steve remembers the reason why INNER JOIN was chosen.

One possible reason was to have a single way of treating implicit joins.

In WHERE and ORDER BY clauses, implicit join makes sense to render an INNER
JOIN.

Only when used in the SELECT clause only, LEFT JOIN would work just fine.

So, I guess it was because we wanted to handle the implicit join in the
same fashion no matter where it is used.

But, I might be wrong, so I'm looking forward to Steve's answer too.

Vlad

On Thu, Feb 22, 2018 at 12:05 PM, Lukas Eder  wrote:

> Sure, there may be a chicken and egg situation between Hibernate and JPA,
> but I'm trying to understand why this was specified the way it is, as I
> find this quite surprising.
>
> 2018-02-22 10:59 GMT+01:00 andrea boriero :
>
> > Hi Lukas,
> >
> > I think it is based on JPA 2.1 spec, 4.4.4 Path Expressions , "Path
> > expression navigability is composed using “inner join” semantics."
> >
> > On 22 February 2018 at 08:09, Lukas Eder  wrote:
> >
> >>  Hello,
> >>
> >> Vlad Mihalcea [1] was so kind to point me to this mailing list with my
> >> question about implicit joins. The user guide [2] states that:
> >>
> >>   "Implicit joins are always treated as inner joins."
> >>
> >> To me, this seems wrong, semantically, if implicit joins follow optional
> >> (nullable) foreign key relationships. Let's assume that customers have
> >> optional addresses. When we write
> >>
> >>   SELECT c.firstName, c.lastName, c.address.city.country.code
> >>   FROM customer c
> >>
> >> The resulting query will INNER JOIN the customer / address / city /
> >> country
> >> tables, filtering out customers with no address, or addresses with no
> >> cities, or cities with no countries (let's ignore the modelling aspect).
> >> In
> >> fact, I got a CROSS JOIN with join predicate in the WHERE clause, but
> that
> >> doesn't really change anything. Hence the SELECT clause applies a
> filter,
> >> which is rather surprising. To me, this seems simply wrong just like it
> >> would be wrong for Stream.map() to apply any filters.
> >>
> >> However, I'm sure there must have been good reasons to default to this
> >> behaviour, even in the presence of optional foreign keys.
> >>
> >> Does anyone know what those reasons are?
> >> Cheers,
> >> Lukas
> >>
> >> [1]: https://twitter.com/vlad_mihalcea/status/965927462684196864
> >> [2]: http://docs.jboss.org/hibernate/orm/5.2/userguide/
> >> html_single/Hibernate_User_Guide.html#hql-implicit-join
> >> ___
> >> 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] Empty IN list support

[Vlad Mihalcea]

I see that we are only using it for testing so that we can skip the:

testEmptyInListQuery

query on certain Dialects.

We could use this info when rendering the JPQL/HQL queries to throw an
exception before executing the query.
Nevertheless, an exception will be thrown anyway even if we don't do it.

Vlad

On Fri, Feb 16, 2018 at 11:21 AM, Bregler, Jonathan <
jonathan.breg...@sap.com> wrote:

> Hi,
>
> HANA doesn't support empty IN lists, so executing an HQL query that gets
> transformed into a SQL query with an empty IN list results in a SQL parser
> error on the database side. I noticed that the Dialect class already
> defines a method called "supportsEmptyInList()" which according to the
> Javadoc returns "True if empty in lists are supported; false otherwise".
> However, this method doesn't seem to be used anywhere in the Hibernate
> code. Is there a reason for that?
>
> Thanks,
> Jonathan
> ___
> 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

[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] Repackaging dependencies with Hibernate

[Vlad Mihalcea]

Thaks Sanne,

Can you add your response to the Hibernate forum?

Maybe the forum question will be indexed by Google and other people will
benefit from your answer.

Vlad

On Tue, Feb 6, 2018 at 3:36 PM, Steve Ebersole  wrote:

> I started writing the same response but I'll simply +1 Sanne's excellent
> reply
>
> On Tue, Feb 6, 2018, 7:35 AM Sanne Grinovero  wrote:
>
>> Repackaging, shading, etc.. are all a nightmare for supporting the
>> library down the road so we'd strongly prefer against doing such
>> things.
>> For users it's a nightmare as well when it comes to debug things, as
>> it breaks all tools such as having your IDE download the matching
>> sources for stacktraces, etc..
>>
>> FWIW, we had a similar discussion on Infinispan some years ago, with
>> some people really wanting to hide some dependencies into shaded
>> modules to make project setup simpler. I lost that argument: shading
>> was done, and later we had so much pain that the decision was now
>> finally reverted. That team learned the lesson and will never use
>> shading again.
>>
>> I hate to sound biased, but when you run an application in WildFly you
>> don't have this issue, as these "internal dependencies" don't pollute
>> the application's classpath: it's not a problem at all if the user
>> pulls in a different version of ANTLR.
>> I don't know much about WebLogic, but it really should be able to do
>> the same as any app server is required to provide some similar feature
>> - perhaps in the WebLogic case it's not nicely exposed as a feature
>> people can use, but that's their problem to not expose useful stuff :)
>>
>> Regarding non technical issues: I'm not aware of a licensing issue,
>> not blocking at least in the case of ANTLR although we'd likely need
>> to add some clarification notes in the readme and licensing notes, in
>> case we really wanted to do such a thing ..
>>
>> I'm glad others - e.g. Spring - repackage their dependencies, so
>> that's less likely to conflict with our dependencies :P
>>
>> Thanks,
>> Sanne
>>
>>
>> On 6 February 2018 at 12:42, Vlad Mihalcea 
>> wrote:
>> > Hi,
>> >
>> > This Hibernate forum question provides a good point:
>> >
>> > https://discourse.hibernate.org/t/hibernate-in-weblogic-
>> has-a-conflicting-antlr-version-what-to-do/189
>> >
>> > Frameworks like EclipseLink and Spring (
>> > https://twitter.com/starbuxman/status/960854907854249986 ) repackage
>> > dependencies to avoid the issue when the user needs a different library
>> > version (ANTLR 3.3) in their Classpath.
>> >
>> > Is it possible to do so for Hibernate ORM? Is there any license issues
>> that
>> > would prevent doing it?
>> >
>> > Vlad
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Repackaging dependencies with Hibernate

[Vlad Mihalcea]

Hi,

This Hibernate forum question provides a good point:

https://discourse.hibernate.org/t/hibernate-in-weblogic-has-a-conflicting-antlr-version-what-to-do/189

Frameworks like EclipseLink and Spring (
https://twitter.com/starbuxman/status/960854907854249986 ) repackage
dependencies to avoid the issue when the user needs a different library
version (ANTLR 3.3) in their Classpath.

Is it possible to do so for Hibernate ORM? Is there any license issues that
would prevent doing it?

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

Re: [hibernate-dev] Support for entities without default constructor

[Vlad Mihalcea]

For anyone interested, Josh Long tell more about why they took this
approach where they inject the default constructor:

https://twitter.com/starbuxman/status/960049941916696578

Rafael Winterhaler shows that this can be easily done with Byte Buddy which
we already used before:

https://twitter.com/rafaelcodes/status/959892398997458946

If we can prove that it's indeed significantly faster than using Java
Reflection to build entities,
I think we should think about taking this approach as well.

What do you think of this?

Vlad

On Sat, Feb 3, 2018 at 5:03 PM, Vlad Mihalcea 
wrote:

> Hi,
>
> I realized that we could allow users to define entities without a default
> constructor.
>
> For Kotlin, which supportsdefault values, this could be beneficial.
>
> There is some info about how we could do that in this using Objenesis in
> the following Spring issue:
>
> https://jira.spring.io/plugins/servlet/mobile#issue/SPR-10594
>
> Let me know what you think,
> Vlad
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Support for entities without default constructor

[Vlad Mihalcea]

Hi,

I realized that we could allow users to define entities without a default
constructor.

For Kotlin, which supportsdefault values, this could be beneficial.

There is some info about how we could do that in this using Objenesis in
the following Spring issue:

https://jira.spring.io/plugins/servlet/mobile#issue/SPR-10594

Let me know what you think,
Vlad
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.3.0 release tomorrow

[Vlad Mihalcea]

Thanks,

I was having some Pull Requests which I pushed to 5.2.13 and wanted to have
them in 5.3 as well.

I will add them now.

Vlad

On Thu, Feb 1, 2018 at 3:34 PM, Steve Ebersole  wrote:

> If it's stuff that's ready to go, go for it.  I'll send out an email when
> I'm ready to start.
>
> On Thu, Feb 1, 2018, 7:28 AM Vlad Mihalcea 
> wrote:
>
>> Hi Steve,
>>
>> Is it ok to commit on the master branch today or should we wait for 5.3
>> to be released?
>>
>> Vlad
>> On Thu, Feb 1, 2018 at 4:03 AM, Steve Ebersole 
>> wrote:
>>
>>> I am waiting until I hear back from Joel from Sonatype regarding
>>> disabling
>>> the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release.
>>>
>>> On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet <
>>> guillaume.s...@gmail.com>
>>> wrote:
>>>
>>
>>> > On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole 
>>> > wrote:
>>> >
>>> >> Yes, I agree.  As it is, it is very likely that in 2 weeks we will
>>> have
>>> >> ORM 5.3.0.CR1.  So even if you did do a OGM release at that time we
>>> are
>>> >> going to be limited in what exactly we can change if we find changes
>>> are
>>> >> needed.
>>> >>
>>> >> Interestingly this goes back to earlier discussions about "release
>>> >> early/often" for the purpose of identifying regressions.  Granted
>>> there
>>> >> y'all were talking about 5.2, but the same happens here from the ORM
>>> >> perspective in 5.3.  We need to not be dragging version non-stable
>>> releases
>>> >> out as we continue to wait for +1's from all integrators (Search, OGM,
>>> >> Spring, etc).
>>> >>
>>> >
>>> > Yes, for a lot of reasons (good and bad) we were really bad with the
>>> ORM
>>> > 5.2 support in OGM.
>>> >
>>> > We are very aware of that and the idea is to not do that again :).
>>> >
>>> > We (probably Davide) will let you know about our progress soon.
>>> >
>>> > --
>>> > 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] Minor changes to the website

[Vlad Mihalcea]

Great job Guillaume,

It looks awesome.

Vlad

On Wed, Jan 31, 2018 at 2:15 PM, Guillaume Smet 
wrote:

> Hi,
>
> Just so you know, I just made a few minor changes to the website:
> - in the Releases dymanic submenu, you now have a label stating "latest
> stable"/"development" to make it clearer what the versions are (it's
> especially useful at this point of the ORM development for instance as 5.3
> is the latest but not yet considered stable)
> - I made the Documentation entry menu of ORM dynamic with a submenu
> following the same principles as for Releases. It avoids going to the
> latest then using the dropdown at the top (I kept the dropdown anyway)
>
> In passing, I also added a placeholder page for the ORM 5.3 doc stating it
> will be available soon.
>
> HTH
>
> --
> 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] Should EntityManager#refresh retain an existing lock?

[Vlad Mihalcea]

Hi Gail,

Steve is right. Database locks cannot be released unless you end the
transaction and that's how it works on any RDBMS, either in 2PL Mode or
MVCC.

As for optimistic locks:

1. LockModeType.OPTIMISTIC

The check is done at the end of the end of the transaction. Refresh will
only update the version, but the check should still be done so we should
not probably switch to LockModeTypeNONE.

2. OPTIMISTIC_FORCE_INCREMENT,

This one triggers a version increment in a different entity, so it should
not be affected by the refresh of our entity.

Vlad

On Thu, Feb 1, 2018 at 1:12 AM, Gail Badner  wrote:

> OK, sounds good.
>
> Thanks,
> Gail
>
> On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole 
> wrote:
>
> > It is possible to call EntityManager#lock(Object entity, LockModeType
> >> lockMode) with a lower-level lock, but that request will be ignored.
> >> Hibernate will only upgrade a lock.
> >>
> >
> > Sure, this is in keeping with most (all?) databases - a transaction can
> > only acquire more restrictive locks.
> >
> >
> >
> >> I think that clarifies retaining the same lock-level for the entity when
> >> calling EntityManager#refresh(Object entity).
> >>
> >> If no one has any comments that disagree with this in the next couple of
> >> days, I'll go with that.
> >>
> >
> > That's the correct handling.
> >
> >
> ___
> 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] 5.3.0 release tomorrow

[Vlad Mihalcea]

Hi Steve,

Is it ok to commit on the master branch today or should we wait for 5.3 to
be released?

Vlad

On Thu, Feb 1, 2018 at 4:03 AM, Steve Ebersole  wrote:

> I am waiting until I hear back from Joel from Sonatype regarding disabling
> the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release.
>
> On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet 
> wrote:
>
> > On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole 
> > wrote:
> >
> >> Yes, I agree.  As it is, it is very likely that in 2 weeks we will have
> >> ORM 5.3.0.CR1.  So even if you did do a OGM release at that time we are
> >> going to be limited in what exactly we can change if we find changes are
> >> needed.
> >>
> >> Interestingly this goes back to earlier discussions about "release
> >> early/often" for the purpose of identifying regressions.  Granted there
> >> y'all were talking about 5.2, but the same happens here from the ORM
> >> perspective in 5.3.  We need to not be dragging version non-stable
> releases
> >> out as we continue to wait for +1's from all integrators (Search, OGM,
> >> Spring, etc).
> >>
> >
> > Yes, for a lot of reasons (good and bad) we were really bad with the ORM
> > 5.2 support in OGM.
> >
> > We are very aware of that and the idea is to not do that again :).
> >
> > We (probably Davide) will let you know about our progress soon.
> >
> > --
> > 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] Serializable SessionFactory

[Vlad Mihalcea]

Sure, we need to profile it first.

>From what our users have told us, getting the metadata from the database
takes some time and my
goal was to identify whether we can do something about that.

I'll come back once I have more info.

Vlad

On Thu, Jan 11, 2018 at 3:05 PM, Sanne Grinovero 
wrote:

> On 11 January 2018 at 12:39, Steve Ebersole  wrote:
> > I just don't see how serializing a full SessionFactory to disk is a good
> > idea.
> >
> > What do you mean by "avoiding (caching) the DB metadata retrieving the
> > part"?
>
> I'm wondering too. I would be very cautious with that: if the
> datasource connection is (temporarily) broken, because for example
> Hibernate was restarted, we don't really know which assumptions will
> still be true. The metadata is possibly no longer valid.
>
> You can't know for sure if the "development cycle" of the users isn't
> including some step which makes changes to the database, or maybe even
> updates it. I actually expect this to be common and this would cause a
> lot of trouble.
>
> If we're willing to invest to make the ORM bootstrap faster, that's
> great but we should work on identifying what is being slow and what
> can be done without making it dangerous.
>
> >
> > On Thu, Jan 11, 2018 at 2:08 AM Vlad Mihalcea 
> > wrote:
> >
> >> Yes, out of the JVM. This PR allows the SF to be serialized to a file,
> so
> >> the next time we bootstrap, we reload the whole SF from the file
> instead.
> >>
> >> There are many unforeseen issues probably related to this PR and it
> might
> >> hurt maintenance in the long-run.
> >>
> >> For this reason, I'm going to leave the PR open as-is, and investigate
> >> whether we can bootstrap faster by avoiding (cacahing) the DB metadata
> >> retrieving the part.
> >>
> >> Vlad
> >>
> >> On Wed, Jan 10, 2018 at 7:45 PM, Steve Ebersole 
> >> wrote:
> >>
> >>> The SessionFactory being Serialized outside the VM?  Because otherwise
> it
> >>> is already "serializable" via VM serialization hooks
> >>> and org.hibernate.internal.SessionFactoryRegistry.  And I'm not so
> >>> convinced we should support serializing it for "out of" VM use aside
> from
> >>> what we already do which assumes the new target VM has a similarly
> named
> >>> SessionFactory in its org.hibernate.internal.SessionFactoryRegistry.
> >>>
> >>> On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea <
> mihalcea.v...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> While reviewing old PRs we have in the ORM project, I stumbled on this
> >>>> one
> >>>> about serializing the SessionFactory.
> >>>>
> >>>> I created a new PR, rebased on top of the current master branch and
> all
> >>>> tests are passing fine.
> >>>>
> >>>> If anyone wants to take a look, this is the PR:
> >>>>
> >>>> https://github.com/hibernate/hibernate-orm/pull/2107
> >>>>
> >>>> I'm thinking we should integrate it in 5.3.Alpha and stabilize it if
> >>>> there
> >>>> are some unforeseen changes.
> >>>>
> >>>> The only drawback is that, if we allow the SF to be Serializable,
> >>>> upgrading
> >>>> will be much more difficult in case we change object structure.
> >>>> We could make it clear that this might not be supported or use the
> >>>> serialVersionUID to point to Hibernate version: major.minor.patch.
> >>>>
> >>>> The main benefit is that, for a microservices architecture, Hibernate
> >>>> could
> >>>> start much faster this way.
> >>>>
> >>>> Vlad
> >>>> ___
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev@lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> >>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Serializable SessionFactory

[Vlad Mihalcea]

Yes, out of the JVM. This PR allows the SF to be serialized to a file, so
the next time we bootstrap, we reload the whole SF from the file instead.

There are many unforeseen issues probably related to this PR and it might
hurt maintenance in the long-run.

For this reason, I'm going to leave the PR open as-is, and investigate
whether we can bootstrap faster by avoiding (cacahing) the DB metadata
retrieving the part.

Vlad

On Wed, Jan 10, 2018 at 7:45 PM, Steve Ebersole  wrote:

> The SessionFactory being Serialized outside the VM?  Because otherwise it
> is already "serializable" via VM serialization hooks
> and org.hibernate.internal.SessionFactoryRegistry.  And I'm not so
> convinced we should support serializing it for "out of" VM use aside from
> what we already do which assumes the new target VM has a similarly named
> SessionFactory in its org.hibernate.internal.SessionFactoryRegistry.
>
> On Wed, Jan 10, 2018 at 11:20 AM Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> While reviewing old PRs we have in the ORM project, I stumbled on this one
>> about serializing the SessionFactory.
>>
>> I created a new PR, rebased on top of the current master branch and all
>> tests are passing fine.
>>
>> If anyone wants to take a look, this is the PR:
>>
>> https://github.com/hibernate/hibernate-orm/pull/2107
>>
>> I'm thinking we should integrate it in 5.3.Alpha and stabilize it if there
>> are some unforeseen changes.
>>
>> The only drawback is that, if we allow the SF to be Serializable,
>> upgrading
>> will be much more difficult in case we change object structure.
>> We could make it clear that this might not be supported or use the
>> serialVersionUID to point to Hibernate version: major.minor.patch.
>>
>> The main benefit is that, for a microservices architecture, Hibernate
>> could
>> start much faster this way.
>>
>> Vlad
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Serializable SessionFactory

[Vlad Mihalcea]

Hi,

While reviewing old PRs we have in the ORM project, I stumbled on this one
about serializing the SessionFactory.

I created a new PR, rebased on top of the current master branch and all
tests are passing fine.

If anyone wants to take a look, this is the PR:

https://github.com/hibernate/hibernate-orm/pull/2107

I'm thinking we should integrate it in 5.3.Alpha and stabilize it if there
are some unforeseen changes.

The only drawback is that, if we allow the SF to be Serializable, upgrading
will be much more difficult in case we change object structure.
We could make it clear that this might not be supported or use the
serialVersionUID to point to Hibernate version: major.minor.patch.

The main benefit is that, for a microservices architecture, Hibernate could
start much faster this way.

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

[hibernate-dev] Locking German and French forums

[Vlad Mihalcea]

Hi,

I'm going to lock the German and French forums since users posts
question there from time to time,
and the questions remain answered.

If someone has anything against it, let me know. Otherwise, we should use
the English one until we move to Discourse.

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

Re: [hibernate-dev] Realising the JavaDoc jars as well

[Vlad Mihalcea]

I tested it locally, and when publishing the jars to Maven local, the
JavaDoc is now included.

Don't know if there's anything to be done about it.

Vlad

On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero 
wrote:

> +1 to merge it (if it works - which I didn't check)
>
> Some history can easily be found:
>  - http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html
>
> Thanks,
> Sanne
>
>
> On 11 December 2017 at 15:24, Vlad Mihalcea 
> wrote:
> > Hi,
> >
> > I've noticed this Pull Request which is valid and worth integrating:
> >
> > https://github.com/hibernate/hibernate-orm/pull/2078
> >
> > Before I merge it, I wanted to make sure whether this change was
> accidental
> > or intentional.
> >
> > Was there any reason not to ship the JavaDoc jars along with the release
> > artifacts and the sources jars as well?
> >
> > Thanks,
> > Vlad
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Realising the JavaDoc jars as well

[Vlad Mihalcea]

Hi,

I've noticed this Pull Request which is valid and worth integrating:

https://github.com/hibernate/hibernate-orm/pull/2078

Before I merge it, I wanted to make sure whether this change was accidental
or intentional.

Was there any reason not to ship the JavaDoc jars along with the release
artifacts and the sources jars as well?

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

[hibernate-dev] Why does the disassembledStateText in StandardCacheEntryImpl build from the actual state[] and not from disassembledState[]?

[Vlad Mihalcea]

Hi,

While working on fixing https://hibernate.atlassian.net/browse/HHH-12107,
I realized that the way we create the disassembledStateText property of the
StandardCacheEntryImpl object does not resemble the name of the attribute.

Now, I wonder why we don't build the disassembledStateText from
disassembledState?

Currently, the disassembledStateText is built from the hydrated state
instead. Is there any reason why we do that? Is it for correlating the
disassembledState Object array that's contained in the
StandardCacheEntryImpl object with the original entity hydrated state?

The problem with HHH-12107 was that, from structured 2nd-level cache where
we content is saved as a Map, when we reconstruct the
StandardCacheEntryImpl object
from the Map we get from the 2nd-level cache, we only know the
disassembledState when building the StandardCacheEntryImpl object reference.
So, we can't construct the same disassembledStateText value until we have
the actual hydrated state.

We would not have this issue if the disassembledStateText was built from
the disassembledState Object array via a call to Arrays.deepToString. But
changing the way we build the disassembledStateText is problematic if the
2nd-level cache provider relies on that property.

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

Re: [hibernate-dev] JPA Compliance

[Vlad Mihalcea]

Makes sense. I think it's reasonable to add this since this is what a
many-to-many table relationship looks like.

But, it's ok to postpone it until 6.0.

Vlad

On Tue, Nov 28, 2017 at 12:38 PM, andrea boriero 
wrote:

> It is not about the order but about duplicates.
>
> With the following
> class A {
>List bsl
> @JoinTable(name = "A_B",
> joinColumns = @JoinColumn(name = "A_ID"),
> inverseJoinColumns = @JoinColumn(name = "B_ID"),
> )
> @ManyToMany
> public List getBs() {
> return b;
> }
> }
>
> class *B*{
> List as;
> 
> @ManyToMany(mappedBy = "bs", cascade=CascadeType.ALL)
> public List getAs() {
> return as;
>  }
> }
>
> and it seems JPA expects the JoinTable A_B to have a PK (A_ID,B_ID).
>
> On 28 November 2017 at 05:44, Vlad Mihalcea 
> wrote:
>
>> I don't understand what is the requirement for the @Bag annotation and
>> the  `hibernate.jpa.compliance=list` setting.
>>
>> From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an
>> ordered List.
>> Otherwise, the order is undefined.
>> Is there anything I'm missing about handling Lists according to the JPA
>> spec?
>>
>> Vlad
>>
>> On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole 
>> wrote:
>>
>>> So then how about the following:
>>>
>>>
>>>1. Add a multi-valued setting to define various categories of JPA
>>>compliance.  E.g. `hibernate.jpa.compliance` with multi-selectable values
>>>such as:
>>>1. query (strict jpql compliance)
>>>   2. txn (transaction handling per spec)
>>>   3. close (multiple calls to EMF and EM #close methods)
>>>   4. list (no bags)
>>>   5. others?
>>>   6. all (there should be some form of specifying all)
>>>2. Add @Bag as an explicit declaration of a bag, even if
>>>`hibernate.jpa.compliance=list` is specified - that setting just
>>>controls how List with no @OrderColumn is interpreted.  I vote to delay
>>>adding that until 6.0
>>>3. Retain current behavior for "double close" calls unless "close"
>>>compliance has been specified.
>>>4. Keep current behavior unless "txn" compliance has been specified
>>>
>>>
>>>
>>> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero 
>>> wrote:
>>>
>>>> On 24 November 2017 at 17:39, Steve Ebersole 
>>>> wrote:
>>>>
>>>>> Andrea, SF is a EMF.  Unwrapping simply returns the same instance.
>>>>>
>>>>
>>>> yes but has you pointed out due to the bootstrapping the behaviour of
>>>> the SF will be strict JPA compliant.
>>>>
>>>>>
>>>>> Another thing I was discussing with Andrea in chat is possibly making
>>>>> these multi-valued, or having multiple values for this.  I can't imagine
>>>>> the FQN case is really all that appealing to a user.  I'm fairly certain a
>>>>> user would rather simply say "yeah, treat transactions according the JPA
>>>>> spec" as opposed to "here is a class I will provide that will tell will
>>>>> treat transactions according to the JPA spec".
>>>>>
>>>>> We have started to identify some cases where we deviate from the
>>>>> spec[1], such as:
>>>>> * Strict query compliance.  As I mentioned earlier we do have such a
>>>>> setting already for this in particular
>>>>> * List versus Bag determination from mappings.
>>>>> * Closed EMF (SF) handling
>>>>> * EntityTransaction status checking - JPA says we should throw
>>>>> exceptions whereas we just ignore the call.
>>>>>
>>>>> We need to decide also which of these we want to just change outright
>>>>> versus controlling via a setting.
>>>>>
>>>>> * Setting
>>>>> * Setting, or introduce a new @Bag annotation - the annotation option
>>>>> is actually pretty appealing since often times the bag behavior is so
>>>>> unexpected from users...
>>>>>
>>>>
>>>> @Bag seems really a good idea to me but that means changing the current
>>>> default behaviour, forcing users to change the code, so not sure if we need
>>>> also a setting.
>>>>
>>>>
>>>>>

Re: [hibernate-dev] JPA Compliance

[Vlad Mihalcea]

I don't understand what is the requirement for the @Bag annotation and the
 `hibernate.jpa.compliance=list` setting.

>From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an
ordered List.
Otherwise, the order is undefined.
Is there anything I'm missing about handling Lists according to the JPA
spec?

Vlad

On Mon, Nov 27, 2017 at 11:29 PM, Steve Ebersole 
wrote:

> So then how about the following:
>
>
>1. Add a multi-valued setting to define various categories of JPA
>compliance.  E.g. `hibernate.jpa.compliance` with multi-selectable values
>such as:
>1. query (strict jpql compliance)
>   2. txn (transaction handling per spec)
>   3. close (multiple calls to EMF and EM #close methods)
>   4. list (no bags)
>   5. others?
>   6. all (there should be some form of specifying all)
>2. Add @Bag as an explicit declaration of a bag, even if
>`hibernate.jpa.compliance=list` is specified - that setting just
>controls how List with no @OrderColumn is interpreted.  I vote to delay
>adding that until 6.0
>3. Retain current behavior for "double close" calls unless "close"
>compliance has been specified.
>4. Keep current behavior unless "txn" compliance has been specified
>
>
>
> On Mon, Nov 27, 2017 at 4:54 AM andrea boriero 
> wrote:
>
>> On 24 November 2017 at 17:39, Steve Ebersole  wrote:
>>
>>> Andrea, SF is a EMF.  Unwrapping simply returns the same instance.
>>>
>>
>> yes but has you pointed out due to the bootstrapping the behaviour of the
>> SF will be strict JPA compliant.
>>
>>>
>>> Another thing I was discussing with Andrea in chat is possibly making
>>> these multi-valued, or having multiple values for this.  I can't imagine
>>> the FQN case is really all that appealing to a user.  I'm fairly certain a
>>> user would rather simply say "yeah, treat transactions according the JPA
>>> spec" as opposed to "here is a class I will provide that will tell will
>>> treat transactions according to the JPA spec".
>>>
>>> We have started to identify some cases where we deviate from the
>>> spec[1], such as:
>>> * Strict query compliance.  As I mentioned earlier we do have such a
>>> setting already for this in particular
>>> * List versus Bag determination from mappings.
>>> * Closed EMF (SF) handling
>>> * EntityTransaction status checking - JPA says we should throw
>>> exceptions whereas we just ignore the call.
>>>
>>> We need to decide also which of these we want to just change outright
>>> versus controlling via a setting.
>>>
>>> * Setting
>>> * Setting, or introduce a new @Bag annotation - the annotation option is
>>> actually pretty appealing since often times the bag behavior is so
>>> unexpected from users...
>>>
>>
>> @Bag seems really a good idea to me but that means changing the current
>> default behaviour, forcing users to change the code, so not sure if we need
>> also a setting.
>>
>>
>>> * I think we should just change the behavior of calling EMF#close on a
>>> closed EMF.  Any application that happens to be relying on us no-op'ing
>>> this call can easily change that to protect the call with an `#isOpen`
>>> check.  In fact I think we should change all of these to match the JPA
>>> expectations such that it is an error to call any of the following: #close,
>>> #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties,
>>> #getPersistenceUnitUtil, #createEntityManager.  To me these all seem pretty
>>> reasonable.  And in fact I think we used to handle this all properly from
>>> the EMF side.  I think we just lost that behavior when we changed to have
>>> our contracts extend the JPA ones since we kept the legacy Hibernate
>>> behavior in SessionFactory.
>>>
>>
>> I do not like the EMF#close behaviour, probably a prefer a separate
>> setting for this.
>>
>>
>>> * This one I am very undecided.  I can see very valid arguments for each.
>>>
>>
>> probably for such case a setting may be a good option.
>>
>>>
>>> [1] we really ought to start keeping a list of these.  I have started
>>> adding them to the migration guide.  Just as a list of things we need to
>>> support configuring or switch to the JPA "way".
>>>
>>> On Fri, Nov 17, 2017 at 11:06 AM andrea boriero 
>>> wrote:
>>>
>>>> I think for 5

Re: [hibernate-dev] HHH-12125 - @GeneratedValue & 5.3

[Vlad Mihalcea]

That's a great idea. I stumbled on this issue many times, and it's very
good to simplify the mapping as you suggested.

+1

Vlad

On Sat, Nov 25, 2017 at 6:18 PM, Steve Ebersole  wrote:

> The background is all in the Jira, but the crux is this... it is better to
> allow a user to do this:
>
> @GeneratedValue( strategy=SEQUENCE, generator="my_seq")
>
> rather than:
>
> @GeneratedValue( strategy=SEQUENCE, generator="my_seq")
> @SequenceGenerator( name="my_seq", sequenceName="my_seq" )
>
> You can see that `SequenceGenerator` is completely unnecessary in this case
> because it adds no new information beyond what is already available on the
> `@GeneratedValue`.
>
> This works great for `GeneratedValue#strategy=SEQUENCE` and
> `GeneratedValue#strategy=TABLE`, however consider this mapping:
>
> @GeneratedValue( strategy=AUTO, generator="increment" )
> @GenericGenerator( name = "increment", strategy = "increment" )
>
> Here we have the same underlying concern - the `@GenericGenerator` is just
> noise, it adds no additional information.  In keeping with the work done as
> part of HHH-12125 it would be great to allow users to instead just say:
>
> @GeneratedValue( strategy=AUTO, generator="increment" )
>
> The problem here is that this last one is actually the responsibility of
> `org.hibernate.boot.model.IdGeneratorStrategyInterpreter
> #determineGeneratorName`
> to interpret, but it is not passed the `GeneratedValue#generator` value.
>
> So the easiest solution would be to add an additional parameter to
> `IdGeneratorStrategyInterpreter#determineGeneratorName` for passing in the
> generator name.  The concern here is that `IdGeneratorStrategyInterpreter`
> is defined in the API space and could very well have custom impls.
>
> A lesser solution wold be to add checks to the code that calls
> `IdGeneratorStrategyInterpreter#determineGeneratorName` to check for
> "magic" generator names before asking the
> `IdGeneratorStrategyInterpreter`.  This is just a very inflexible and
> non-extensible solution, but maybe this works for 5.3 and we can adjust
> `IdGeneratorStrategyInterpreter` as part of 6.0.
>
> 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] JPA Compliance

[Vlad Mihalcea]

When I said multiple modes, I was thinking of defining all these situations
In some interface which declares methods like:

boolean throwsExceptionWhenClosingAClosedEMF()

The interface can have two implementations for Strict JPA and Native mode.

However, the setting could take the FQN of the interface implementation, so
a user can define those compatibility methods according to their needs.

E.g. Maybe someone wants the Strict JPA mode but with just 2 differences;

- don't throw exception when closing the ENG twice
- use the native Hibernate FlushMode.AUTO instead of the JPA one.

Vlad

On 16 Nov 2017 10:49 pm, "Steve Ebersole"  wrote:

> There is already a similar setting, although specific to query language:
> `hibernate.query.jpaql_strict_compliance` - so there is precedence for
> such a solution.
>
> I'm not sure about the "with multiple modes" aspect though.  What are
> these other enumerated mode values?
>
>
> On Thu, Nov 16, 2017 at 2:15 PM Vlad Mihalcea 
> wrote:
>
>> Where the JPA way is questionable, let's add one configuration:
>> hibernate.jpa.compliance with multiple modes:
>>
>> - strict: we do whatever the JPA standard says we should do, like
>> throwing an exception when trying to close the EMF twice
>> - native: we bend the rule where we don't agree with the standard
>>
>> Maybe we should expose all those cases and group them in some interface
>> to allow the user to customize the level of compliance they need.
>>
>> Vlad
>>
>> On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole 
>> wrote:
>>
>>> It was added deprecated.  Meaning I added it knowing it would go away
>>> and I wanted to avoid users using it.
>>>
>>> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA
>>> 2.2.  Yes there is a longer term aspect as well with 6.0 and beyond.
>>>
>>> Its specifically the "where the JPA way is questionable" aspect I am
>>> asking about.  Like to me, it really never makes sense to throw an
>>> exception when I close something that is already closed. So how do we
>>> handle cases like this?
>>>
>>>
>>> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea 
>>> wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> I think that for 5.2 was ok to have the isJpaBootstrap method to avoid
>>>> breaking compatibility for the native bootstrap.
>>>> For 6.0, maybe it's easier if we just align to the JPA spec where it
>>>> makes sense,
>>>> and only provide a separation where the JPA way is questionable.
>>>>
>>>> I noticed that the isJpaBootstrap method is deprecated. Was it
>>>> intended to be removed in 6.0?
>>>>
>>>> Vlad
>>>>
>>>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole 
>>>> wrote:
>>>>
>>>>> Part of 5.2 was merging the JPA contracts into the corresponding
>>>>> Hibernate
>>>>> ones.  So, e.g., we no longer "wrap" a SessionFactory in an impl of
>>>>> EntityManagerFactory - instead, SessionFactory now extends
>>>>> EntityManagerFactory.
>>>>>
>>>>> This caused a few problems that we handled as they came up.  In
>>>>> working on
>>>>> the JPA 2.2 compatibility testing, I see that there are a few more
>>>>> still
>>>>> that we need to resolve.  Mostly they relate to JPA expecting
>>>>> exceptions in
>>>>> certain cases where Hibernate has historically been lenient.  E.g., JPA
>>>>> says that calling EntityManagerFactory#close on an EMF that is already
>>>>> closed should result in an exception.  Historically, calling
>>>>> SessionFactory#close on a SF that is already closed is simply ignored.
>>>>> Philosophical debates aside[1], we need to decide how we want to handle
>>>>> this situation such that we can throw the JPA-expected exceptions when
>>>>> needed.  Do we simply change SF#close to match the JPA expectation?
>>>>> Or do
>>>>> we somehow
>>>>> make SF#close aware of JPA versus "native" use?  This latter option
>>>>> was the
>>>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly
>>>>> continue to use that as the basis of the solution here for other cases.
>>>>>
>>>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code.
>>>>> So if
>

Re: [hibernate-dev] JPA Compliance

[Vlad Mihalcea]

Where the JPA way is questionable, let's add one configuration:
hibernate.jpa.compliance with multiple modes:

- strict: we do whatever the JPA standard says we should do, like throwing
an exception when trying to close the EMF twice
- native: we bend the rule where we don't agree with the standard

Maybe we should expose all those cases and group them in some interface to
allow the user to customize the level of compliance they need.

Vlad

On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole 
wrote:

> It was added deprecated.  Meaning I added it knowing it would go away and
> I wanted to avoid users using it.
>
> BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA
> 2.2.  Yes there is a longer term aspect as well with 6.0 and beyond.
>
> Its specifically the "where the JPA way is questionable" aspect I am
> asking about.  Like to me, it really never makes sense to throw an
> exception when I close something that is already closed. So how do we
> handle cases like this?
>
>
> On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea 
> wrote:
>
>> Hi Steve,
>>
>> I think that for 5.2 was ok to have the isJpaBootstrap method to avoid
>> breaking compatibility for the native bootstrap.
>> For 6.0, maybe it's easier if we just align to the JPA spec where it
>> makes sense,
>> and only provide a separation where the JPA way is questionable.
>>
>> I noticed that the isJpaBootstrap method is deprecated. Was it intended
>> to be removed in 6.0?
>>
>> Vlad
>>
>> On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole 
>> wrote:
>>
>>> Part of 5.2 was merging the JPA contracts into the corresponding
>>> Hibernate
>>> ones.  So, e.g., we no longer "wrap" a SessionFactory in an impl of
>>> EntityManagerFactory - instead, SessionFactory now extends
>>> EntityManagerFactory.
>>>
>>> This caused a few problems that we handled as they came up.  In working
>>> on
>>> the JPA 2.2 compatibility testing, I see that there are a few more still
>>> that we need to resolve.  Mostly they relate to JPA expecting exceptions
>>> in
>>> certain cases where Hibernate has historically been lenient.  E.g., JPA
>>> says that calling EntityManagerFactory#close on an EMF that is already
>>> closed should result in an exception.  Historically, calling
>>> SessionFactory#close on a SF that is already closed is simply ignored.
>>> Philosophical debates aside[1], we need to decide how we want to handle
>>> this situation such that we can throw the JPA-expected exceptions when
>>> needed.  Do we simply change SF#close to match the JPA expectation?  Or
>>> do
>>> we somehow
>>> make SF#close aware of JPA versus "native" use?  This latter option was
>>> the
>>> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly
>>> continue to use that as the basis of the solution here for other cases.
>>>
>>> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code.  So
>>> if
>>> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms,
>>> that flag is set to true.  It's an ok solution, but it does have some
>>> limitations - mainly, there was previously a distinction between SF#close
>>> being called versus EMF#close being called (they were different classes,
>>> so
>>> they could react differently).  Therefore, regardless of bootstrap
>>> mechanism, if the user unwrapped the EMF to a SF, they would always get
>>> the
>>> legacy SF behavior.
>>>
>>> So long story short, so we want to consider an alternative approach to
>>> deciding what to do in "some"[2] of these cases?  Again, we clearly need
>>> these to throw the spec-mandated exceptions in certain "strict
>>> compliance"
>>> situations.  The question really is how to do that.  Should we:
>>>
>>>1. just completely change the behavior to align with the spec?
>>>2. change the behavior to match the spec *conditionally*, where that
>>>condition could be:
>>>   1. `#isJpaBootstrap`
>>>   2. some setting
>>>   3. some extension contract
>>>   4. something else?
>>
>>
>>>
>>> Thoughts?
>>>
>>>
>>> [1] It's not relevant e.g. that I think JPA is wrong here.  We need to
>>> comply with the spec, at least in certain cases ;)
>>>
>>> [2] I say "some" here, because I think the spec is correct in some cases
>>> -
>>> for example, I think its clearly correct that a closed EMF throws an
>>> exception when `#createEntityManager` is called.  Personally I think its
>>> questionable whether closing an already closed EMF should be an
>>> exception.
>>>
>> ___
>>> 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] JPA Compliance

[Vlad Mihalcea]

Hi Steve,

I think that for 5.2 was ok to have the isJpaBootstrap method to avoid
breaking compatibility for the native bootstrap.
For 6.0, maybe it's easier if we just align to the JPA spec where it makes
sense,
and only provide a separation where the JPA way is questionable.

I noticed that the isJpaBootstrap method is deprecated. Was it intended to
be removed in 6.0?

Vlad

On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole  wrote:

> Part of 5.2 was merging the JPA contracts into the corresponding Hibernate
> ones.  So, e.g., we no longer "wrap" a SessionFactory in an impl of
> EntityManagerFactory - instead, SessionFactory now extends
> EntityManagerFactory.
>
> This caused a few problems that we handled as they came up.  In working on
> the JPA 2.2 compatibility testing, I see that there are a few more still
> that we need to resolve.  Mostly they relate to JPA expecting exceptions in
> certain cases where Hibernate has historically been lenient.  E.g., JPA
> says that calling EntityManagerFactory#close on an EMF that is already
> closed should result in an exception.  Historically, calling
> SessionFactory#close on a SF that is already closed is simply ignored.
> Philosophical debates aside[1], we need to decide how we want to handle
> this situation such that we can throw the JPA-expected exceptions when
> needed.  Do we simply change SF#close to match the JPA expectation?  Or do
> we somehow
> make SF#close aware of JPA versus "native" use?  This latter option was the
> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly
> continue to use that as the basis of the solution here for other cases.
>
> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code.  So if
> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms,
> that flag is set to true.  It's an ok solution, but it does have some
> limitations - mainly, there was previously a distinction between SF#close
> being called versus EMF#close being called (they were different classes, so
> they could react differently).  Therefore, regardless of bootstrap
> mechanism, if the user unwrapped the EMF to a SF, they would always get the
> legacy SF behavior.
>
> So long story short, so we want to consider an alternative approach to
> deciding what to do in "some"[2] of these cases?  Again, we clearly need
> these to throw the spec-mandated exceptions in certain "strict compliance"
> situations.  The question really is how to do that.  Should we:
>
>1. just completely change the behavior to align with the spec?
>2. change the behavior to match the spec *conditionally*, where that
>condition could be:
>   1. `#isJpaBootstrap`
>   2. some setting
>   3. some extension contract
>   4. something else?
>
> Thoughts?
>
>
> [1] It's not relevant e.g. that I think JPA is wrong here.  We need to
> comply with the spec, at least in certain cases ;)
>
> [2] I say "some" here, because I think the spec is correct in some cases -
> for example, I think its clearly correct that a closed EMF throws an
> exception when `#createEntityManager` is called.  Personally I think its
> questionable whether closing an already closed EMF should be an exception.
> ___
> 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 CI is angry: ORM build job is failing since the 2nd of November

[Vlad Mihalcea]

Done:

http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/

On Mon, Nov 6, 2017 at 5:01 PM, Sanne Grinovero  wrote:

> Davide, checking the CI logs I see:
>
> Not sending mail to user ggam@[edited] with no permission to view
> hibernate-orm-master-h2-check #358
> Not sending mail to user bogdan.stirbat@[edited] with no permission to
> view hibernate-orm-master-h2-check #358
> Not sending mail to user andrew_geery@[edited] with no permission to
> view hibernate-orm-master-h2-check #358
> An attempt to send an e-mail to empty list of recipients, ignored.
>
> So nobody heard of this. Would be great if we could figure out a way
> to notify the people who merged the PR, on top of trying to reach the
> commit authors?
>
>
> > On 6 November 2017 at 14:53, Vlad Mihalcea 
> wrote:
> >> They are not working. I haven't got any alert about the build failure.
> >>
> >> Vlad
> >>
> >> On 6 Nov 2017 4:51 pm, "Sanne Grinovero"  wrote:
> >>>
> >>> On 6 November 2017 at 14:41, Vlad Mihalcea 
> >>> wrote:
> >>> > Looks like there is some indentation issue:
> >>> >
> >>> >
> >>> > http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-
> h2-check/ws/tooling/metamodel-generator/target/reports/
> checkstyle/main.html#f-/mnt/jenkins-workdir/workspace/
> hibernate-orm-master-h2-check/tooling/metamodel-generator/
> src/main/java/org/hibernate/jpamodelgen/annotation/
> AnnotationMetaEntity.java
> >>> >
> >>> > I'll fix it and see if the job runs fine afterward.
> >>>
> >>> Thanks! And let me know if the CI emails aren't working, we'll look
> into
> >>> that.
> >>>
> >>> Sanne
> >>>
> >>> >
> >>> > Vlad
> >>> >
> >>> > On Mon, Nov 6, 2017 at 4:38 PM, Sanne Grinovero  >
> >>> > wrote:
> >>> >>
> >>> >> Vlad, according to CI looks like you are responsible for having
> merged
> >>> >> the offending changes :)
> >>> >> Would you mind fixing it? It just failed to build some local
> >>> >> experiments and I wasn't sure what I was doing wrong.
> >>> >>
> >>> >> http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-
> h2-check/358/
> >>> >>
> >>> >> You should have received automated nagging emails too, please let me
> >>> >> know if you didn't?
> >>> >>
> >>> >> Thanks,
> >>> >> Sanne
> >>> >
> >>> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate CI is angry: ORM build job is failing since the 2nd of November

[Vlad Mihalcea]

Looks like there is some indentation issue:

http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/ws/tooling/metamodel-generator/target/reports/checkstyle/main.html#f-/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2-check/tooling/metamodel-generator/src/main/java/org/hibernate/jpamodelgen/annotation/AnnotationMetaEntity.java

I'll fix it and see if the job runs fine afterward.

Vlad

On Mon, Nov 6, 2017 at 4:38 PM, Sanne Grinovero  wrote:

> Vlad, according to CI looks like you are responsible for having merged
> the offending changes :)
> Would you mind fixing it? It just failed to build some local
> experiments and I wasn't sure what I was doing wrong.
>
> http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-h2-check/358/
>
> You should have received automated nagging emails too, please let me
> know if you didn't?
>
> Thanks,
> Sanne
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] @db.dialect@ - yet again

[Vlad Mihalcea]

Hi,

Looks like IDEA rebuilds the project and generates the @db.dialect@ issue.

I tackled it with the following Bash script:

@echo off
> set db=%1
> set module="hibernate-core"
> if not "%2"=="" SET module="hibernate-%2"
> if "%2"=="doc" SET module="documentation"
> set target="d:\Vlad\Work\GitHub\hibernate-orm\%module%\target\"
> IF EXIST %target%\resources\test (
> del %target%\resources\test\hibernate.properties
> )
> pushd %target%
> cd ..
> gradlew pTR -Pdb=%db%
> popd


It's Windows, but it can be easily translated to Linux bash.

I call it as follows:

> ptr h2

This one prepared hibernate-core for H2

> ptr mysql

This one prepared hibernate-core for MySQL

>  ptr h2 envers

This one prepared hibernate-envers for H2

I usually run it from Idea Terminal.

Vlad

On Thu, Oct 12, 2017 at 3:22 PM, Steve Ebersole  wrote:

> I just upgraded to IntelliJ 2017.3 EAP and am back to this frustrating
> "Dialect class not found: @db.dialect@" problem.  I run the
> `processTestResources` (or `compile`, does not matter) and then when I try
> to run a test in the IDE I get this error.
>
> What is the magic incantation I am missing?
> ___
> 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 Types" project

[Vlad Mihalcea]

Hi,

It's because not all database support ARRAY or JSON.

We've been discussing this on the mailing list (around one year ago) and I
remember we concluded that we can only add these types to ORM core
if the vast majority of the Hibernate-supported database offer JSON or
ARRAY.

Also, even if we add support for them, it's improbable that we are going to
backport it to 5.1, 5.0, 4.3, 4.2 and 4.1. So, since my blog readers
requested me to provide these types via Maven Central, I decided to bundle
them in a new library.

If more and more databases add support for JSON, we could add support for
it in 6.0.
For ARRAY, I doubt that more DBs will support it if they haven't done it by
now.

Vlad

On Thu, Sep 28, 2017 at 9:47 AM, Gunnar Morling 
wrote:

> Hey Vlad,
>
> I recently learned about your "Hibernate Types" project [1]. It's great to
> see support for JSON, arrays, etc!
>
> Out of curiosity, though, why did you decide to make it a separate project
> instead of adding these very useful types to Hibernate itself? Seems it'd
> be easier for people to us them that way.
>
> Cheers,
>
> --Gunnar
>
> [1]
> https://vladmihalcea.com/2017/09/25/the-hibernate-types-
> open-source-project-is-born/
> ___
> 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] Too simple a solution for HHH-11147 ?

[Vlad Mihalcea]

Hi Thomas,

You can send a Pull Request. I'll ask Luis Barreiro to review it since he's
the expert in this area.

Thanks,
Vlad

On Thu, Sep 28, 2017 at 12:33 AM, Thomas Reinhardt 
wrote:

>
> Hello,
>
> I investigated HHH-11147 (Allow enhanced entities to be returned in a
> completely uninitialized state) and have a very small fix for that issue.
> I want your feedback if I am going the correct route here. Seems too
> easy and lazy loading is a pretty important piece of hibernate.
>
> To spare everyone opening the issue just to get an overview here is a
> short summary:
>
>
>
> The use case is an entity with a simple relation:
>
> @Entity
> @Proxy(lazy=true)
> class MyEntity {
>@ManyToOne(fetch=FetchType.LAZY)
>OtherEntity other;
> }
>
> Both entities are bytecode enhanced at compiletime with
> enableLazyInitialization=true. The problem is that the "other" entity is
> fetched despite being annotated as lazy.
>
>
>
> My quick fix is actually only two changed lines. A proper diff
> (HHH-11147-quick-and-dirty.diff) is attached to the issue. I did
> specifically not make a PR just for this discussion but if requested I
> can of course make one. A pseudo-diff can be found below.
>
> I did test this fix on our main application and it seems to work. There
> are two main questions:
> 1) could there be cases where we create a proxyFactory without need?
> 2) am I killing the benefits of the bytecode enhancement by using a
> proxy or do I still get things like association handling?
>
>
> Sorry for the wall of text but I thought this discussion does not belong
> in the issue itself. Correct me if I am wrong.
>
> Greetings,
> Thomas
>
>
>
> Pseudo-diff:
>
> org.hibernate.event.internal.DefaultLoadEventListener
> proxyOrLoad(LoadEvent, EntityPersister, EntityKey, LoadType) {
> ...
> // this class has no proxies (so do a shortcut)
> -  if ( !persister.hasProxy() ) {
> +  if ( !persister.getEntityMetamodel().isLazy() ) {
>return load( event, persister, keyToLoad, options );
> ...
> }
>
>
>
> org.hibernate.tuple.entity.AbstractEntityTuplizer
> public AbstractEntityTuplizer(...) {
> ...
> instantiator = buildInstantiator( entityMetamodel, mappingInfo );
> -  if ( entityMetamodel.isLazy() &&
> -   !entityMetamodel.getBytecodeEnhancementMetadata()
> -.isEnhancedForLazyLoading() ) {
> +  if ( entityMetamodel.isLazy() ) {
>proxyFactory = buildProxyFactory( ... );
> ...
> }
>
>
> ___
> 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] Number of SQL statements

[Vlad Mihalcea]

HI,

We already have such tool for the Hibernate tests. The one that I suggested
does not use FlexyPool, but datasource-proxy.

Vlad

On Fri, Sep 22, 2017 at 5:55 PM, Sanne Grinovero 
wrote:

> Hi Thomas,
>
> I can't answer your question - will leave that to the people working
> on Hibernate ORM - but let me share that I'd also love to see such a
> tool or an example for unit tests (integration tests) to assert that
> some specific piece of code won't be generating more than N database
> round trips. That would be extremely useful!
>
> Let me suggst to focus on the actual network round-trips though:
> looking at the number of statements being generated is misleading as
> Hibernate ORM is able to do many clever things with multiple
> statements; for example you might see many of them being logged but it
> could still be wrapping them all in a single batch, therefore not
> being a performance problem.
>
> Vlad could this be a feature of your Flexy Pool ? Would love to see
> such a feature as a JUnit Rule ...
>
> Thanks,
> Sanne
>
> On 22 September 2017 at 15:34, Thomas Reinhardt 
> wrote:
> >
> > Hello Hibernate Team,
> >
> > is there a good way to check in a junit test which number of sql
> > statements are generated ?
> > I want to tackle some of the lazy loading/class enhancement issues and
> > those need good tests of course.
> >
> > Somehow related: I have a (rather trivial) fix for HHH-7842 (Hibernate
> > Criteria does not respect fetch mode, when alias is used). As this is
> > related to the now deprecated Hibernate Criteria API is there any chance
> > my fix gets accepted or should I spare my time?
> >
> >
> > Thanks,
> >  Thomas
> > ___
> > 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] Number of SQL statements

[Vlad Mihalcea]

Hi,

1. To validate the number of SQL statements, use this SQL Statement count
validator I explained in this article:

https://vladmihalcea.com/2014/02/01/how-to-detect-the-n-plus-one-query-problem-during-testing/

2. For Hibernate Criteria, I don't think you should bother since it will be
removed in the future and the fix might not be backported to older versions.

You could use the JPA Criteria instead.

Vlad

On Fri, Sep 22, 2017 at 5:34 PM, Thomas Reinhardt 
wrote:

>
> Hello Hibernate Team,
>
> is there a good way to check in a junit test which number of sql
> statements are generated ?
> I want to tackle some of the lazy loading/class enhancement issues and
> those need good tests of course.
>
> Somehow related: I have a (rather trivial) fix for HHH-7842 (Hibernate
> Criteria does not respect fetch mode, when alias is used). As this is
> related to the now deprecated Hibernate Criteria API is there any chance
> my fix gets accepted or should I spare my time?
>
>
> Thanks,
>  Thomas
> ___
> 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] [Search and more] What is new in a give release

[Vlad Mihalcea]

Hi,

To be able to load the User Guide like this:

https://docs.jboss.org/hibernate/orm/5.2


we have two options:

1. Either we rename the User Guide to index.adoc so that it will become
index.html.
2. We leave it as-is, but when we copy the docs to JBoss, we also copy the
User Guide as index.html as well. This will allow our users to retain
bookmarks they've created since we published the new User Guide.

Let me know which one do you prefer.
Vlad

On Thu, Sep 14, 2017 at 3:34 PM, Steve Ebersole  wrote:

> Yoann,
>
> First thanks for the work on this.  I think it looks worlds better.  A few
> minor things:
>
>
>1. Not sure of the source for this, but can we fix these doc link for
>5.2 from `
>https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/
> Hibernate_User_Guide.html`
>to `https://docs.jboss.org/hibernate/orm/5.2`?  Also, why https?  Not
>sure it matters, just found it odd
>2. Much of the information on that ORM releases page is, in turn,
>version/series specific.  Any reason why those pieces of information are
>not part of the series?  Either in the synopsis on the releases page or
> on
>the specific series page, or both.  Specifically
>   1. "Compatibility Matrix" - the fact that its a table based on series
>   is a good indicator it is all series specific ;)
>   2. "Maven Repository" - I'd personally prefer to have this as part of
>   the series info
>3. I think the individual series pages are missing a key piece of
>information... the "synopsis" of that series.  I guess partially this
> fits
>under "what's new"
>
> Other than these minor things I love it.  Great job!
>
> P.S. another question is whether (and if so, how) to apply the same
> treatment to the Documentation info in terms of the nav links.
>
> On Thu, Sep 14, 2017 at 7:05 AM Yoann Rodiere  wrote:
>
> > I polished the changes, applied them to all projects (ORM, OGM,
> Validator,
> > Search), and sent a PR:
> > https://github.com/hibernate/hibernate.org/pull/126
> > Could you guys review it? Mainly I'd need one person per project to check
> > they agree with the changes, especially in their project's section.
> > Also, there's still a bit of work to do for each project, mainly filling
> > in missing metadata (see the PR).
> >
> > Yoann Rodière
> > Hibernate NoORM Team
> > yo...@hibernate.org
> >
> > On 14 September 2017 at 10:38, Emmanuel Bernard 
> > wrote:
> >
> >> On Wed 17-09-13 10:55, Sanne Grinovero wrote:
> >>
> >>> On 13 September 2017 at 10:51, Yoann Rodiere 
> >>> wrote:
> >>>
>  It's more the number of columns, what if you add more version, should
> I
> > scroll horizontally? Also releeases tend to be shown vertically with
> > version in desc order. This model breaks a bit this habit.
> >
> 
> 
>  At least versions are in desc order :D
>  More seriously, I was more worried about the number of dependencies
> than
>  about the number of series. We don't want to maintain a hundred
>  branches, so
>  we'll probably try to keep the number of series to a minimum, but we
> do
>  want
>  to offer as much as possible to users, so we may offer many different
>  integrations, and thus many different dependencies. Just think if the
>  ORM
>  team wants to display supported versions of each DBMS... So I thought
>  showing versions horizontally would be more future-proof.
>  I'll try to add horizontal scrolling to the table. The oldest releases
>  may
>  not be displayed, but then those are not the one we want to advertise,
>  so...
>  And in any case, we have limited horizontal space, so we have to hide
>  *something*.
>  About phones, I think bootstrap has something, I'll give it a try.
> 
>  On "Downloads" we only want to promote the active branches; have some
> > basic series descriptions but way more ecclectic than the releases
> > descriptions. We make them cross-linked and everyone is happy?
> >
> 
> 
>  Sure, we can do that. But the "downloads" page will essentially be a
>  stripped-down version of the "releases" page.
> 
> >>>
> >>> +1 since maintenance is automated I see no problem with a little
> >>> redundancy.
> >>>
> >>
> >> I'm not sure two pages is really solving the problem. It looks like you
> >> don't want to make a choice. But I don't have a pro/con opinion.
> >> My real concern is since you will have two pages, what's the navigation
> >> logic? How do you reach each on of these pages?
> >>
> >> Just thinking out loud here but I think the one way to solve long
> >> standing Steve objective is indeed to have per series sections of the
> >> website (including download, documentation, migration guide)
> >> And a top nav for "latest/promoted" releases (like we have today
> >> really).
> >> How do you merge the two navigation wise is what I don't know.
> >> This is for l

Re: [hibernate-dev] Problems with PreparedStatementSpyConnectionProvider

[Vlad Mihalcea]

Hi,

The only time when I saw that class failing was for MariaDB because the
Connection was final and we could not proxy it.
That's when I switched to Mockito 2.

However, the goal of that class is to allow it to run as a regular PS, but
to proxy it so that any PS call invocation is recorded.

Vlad

On Sun, Sep 10, 2017 at 5:28 PM, Mark Rotteveel 
wrote:

> I have run into a peculiar problem with
> PreparedStatementSpyConnectionProvider, the tests that use it fail for
> Firebird (and Jaybird 3) for reasons I don't understand.
>
> As far as I can tell from debugging, in tests that use this class, the
> statement misbehaves and instead of executing parts of its
> implementation, the bytecode modifications applied to the statement by
> PreparedStatementSpyConnectionProvider suddenly return a value from a
> previous execution, which then causes an exception or other invalid
> behavior because it is an incorrect value for the current execution path.
>
> Has anyone seen this before, and what can I do to address this?
>
> 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] Are the tests in the documentation module expected to run on MySQL only?

[Vlad Mihalcea]

I test Hibernate with the following DBs mostly:

- H2
- Oracle
- SQL Server
- PostgreSQL
- MySQL and MariaDb

For other databases, it's not guaranteed that all tests will run.

Related to that function, we could other add a change, but it must work on
the DBs above too.
Or, you could just mark the test with @SkipForDialect.

Thanks,
Vlad

On Fri, Sep 8, 2017 at 7:41 PM, Mark Rotteveel  wrote:

> Are the tests in the documentation module expected to run on MySQL /
> MariaDB only? Or are they expected to run on all databases?
>
> The test org.hibernate.userguide.mapping.basic.SubselectTest is failing
> on Firebird, because it has the following subselect:
>
> @Subselect(
>  "select " +
>  "  a.id as id, " +
>  "  concat(concat(c.first_name, ' '), c.last_name) as clientName, " +
>  "  sum(at.cents) as balance " +
>  "from account a " +
>  "join client c on c.id = a.client_id " +
>  "join account_transaction at on a.id = at.account_id " +
>  "group by a.id, concat(concat(c.first_name, ' '), c.last_name)"
> )
>
> Firebird doesn't have a concat function. According to the version
> history, this test previously used the SQL standard concat operator
> '||', but this was changed in May with the commit comment "Fix test
> failing on MariaDB".
>
> I am surprised that this change wouldn't be failing on other databases
> either (unless most of them define a concat function next to supporting
> the || operator).
>
> To fix this database independently, it would need to be changed to use
> the JDBC concat function escape:
>
> @Subselect(
>  "select " +
>  "  a.id as id, " +
>  "  {fn concat({fn concat(c.first_name, ' ')}, c.last_name)} as
> clientName, " +
>  "  sum(atr.cents) as balance " +
>  "from account a " +
>  "join client c on c.id = a.client_id " +
>  "join account_transaction atr on a.id = atr.account_id " +
>  "group by a.id, {fn concat({fn concat(c.first_name, ' ')},
> c.last_name)}"
> )
>
> However, JDBC function escape are (almost) never used in Hibernate
> tests, so I wonder if this would need to be handled elsewhere.
>
> What to do? Do I ignore the documentation tests, add an exception for
> Firebird or create a pull request with the above change, or something else?
> --
> 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] Unresolved issues targeting 5.2.11

[Vlad Mihalcea]

Much appreciated,

Vlad

On Fri, Sep 1, 2017 at 9:19 AM, Gail Badner  wrote:

> Hi Vlad,
>
> Thanks for letting me know. I'll take a look tomorrow.
>
> Regards,
> Gail
>
> On Thu, Aug 31, 2017 at 10:25 PM, Vlad Mihalcea 
> wrote:
>
>> Hi Gail,
>>
>> My issues have Pull Requests that need to be reviewed.
>>
>> However, there are around 8 PRs which I'd like someone to review so that
>> we can include them in 5.2.11:
>>
>> https://github.com/hibernate/hibernate-orm/pulls?q=is%3Aopen
>> +is%3Apr+author%3Avladmihalcea+label%3A%22Ready+for+review%22
>>
>> Thanks,
>> Vlad
>>
>> On Fri, Sep 1, 2017 at 6:37 AM, Gail Badner  wrote:
>>
>>> Unless something critical comes up, I plan release 5.2.11 next week.
>>> There are currently 24 unresolved issues. [1]
>>>
>>> I am CC'ing everyone that is assigned issues that are still unresolved.
>>> Please take a moment to move any issues that you know will not be ready for
>>> 5.2.11 to 5.2.12.
>>>
>>> There are also 7 issues that are unassigned. If you are familiar with
>>> those, then please take a look and move to 5.2.12 if they will not be
>>> finished.
>>>
>>> Thanks,
>>> Gail
>>>
>>> [1] https://hibernate.atlassian.net/projects/HHH/versions/28600/
>>> tab/release-report-todo
>>>
>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Unresolved issues targeting 5.2.11

[Vlad Mihalcea]

Hi Gail,

My issues have Pull Requests that need to be reviewed.

However, there are around 8 PRs which I'd like someone to review so that we
can include them in 5.2.11:

https://github.com/hibernate/hibernate-orm/pulls?q=is%3Aopen+is%3Apr+author%3Avladmihalcea+label%3A%22Ready+for+review%22

Thanks,
Vlad

On Fri, Sep 1, 2017 at 6:37 AM, Gail Badner  wrote:

> Unless something critical comes up, I plan release 5.2.11 next week. There
> are currently 24 unresolved issues. [1]
>
> I am CC'ing everyone that is assigned issues that are still unresolved.
> Please take a moment to move any issues that you know will not be ready for
> 5.2.11 to 5.2.12.
>
> There are also 7 issues that are unassigned. If you are familiar with
> those, then please take a look and move to 5.2.12 if they will not be
> finished.
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/projects/HHH/versions/
> 28600/tab/release-report-todo
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Deprecated methods of NativeQuery via SQLQuery

[Vlad Mihalcea]

That's a good question.

There are some methods which don't have a replacement in JPA so we should
probably move to some subclass and remove the deprecated flag.

Vlad

On Wed, Aug 30, 2017 at 5:59 PM, Guillaume Smet 
wrote:

> Hi,
>
> In OGM tests, we have a lot of warnings on this sort of constructs:
> NativeQuery query = session.createNativeQuery( nativeQuery ).addEntity(
> OscarWildePoem.class );
> because addEntity() comes from SQLQuery and SQLQuery is deprecated.
>
> I don't think it's a good thing for our users as they have a warning and
> they can't really do anything about it.
>
> I have a vague rememberance of a  discussion about it a few months ago but
> I don't remember the outcome of it.
>
> Shouldn't we copy all the non deprecated methods of SQLQuery to NativeQuery
> so that our users don't get a warning?
>
> Or maybe I missed something?
>
> 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] [ORM] Documentation inconsistencies

[Vlad Mihalcea]

Hi,

The inconsistencies are due to the latest release being done quite a long
time ago.

The 5.2 User Guide was generated when we released 5.2.10 while the GitHub
repo contains many doc changes that will be available only when we release
5.2.11.

Vlad

On Tue, Aug 29, 2017 at 8:12 PM, Marko B  wrote:

> Hi all!
>
> I've noticed some inconsistency between the Hibernate ORM User Guide [1]
> and what seems to be in the documentation files in the GitHub repo. In
> particular examples of @GeneratedValue usages:
>
> Example 131. Unnamed sequence
> @Entity
> public class MyEntity {
>
> @Id
> @GeneratedValue( generation = SEQUENCE )
> public Integer id;
>
> ...
> }
>
> and in documentation files on GitHub [2] which seems to be using java code
> from test sources [3], it's:
>
> @Id
> @GeneratedValue(
> strategy = GenerationType.SEQUENCE
> )
> private Long id;
>
> I've noticed it, as User Guide example is using this `generation` attribute
> which should probably be `strategy` instead.
>
> Have a nice day,
> Marko
>
> [1]
> http://docs.jboss.org/hibernate/orm/5.2/userguide/
> html_single/Hibernate_User_Guide.html
> [2]
> https://github.com/hibernate/hibernate-orm/blob/master/
> documentation/src/main/asciidoc/userguide/chapters/domain/identifiers.adoc
> [3]
> https://github.com/hibernate/hibernate-orm/blob/master/
> documentation/src/test/java/org/hibernate/userguide/mapping/identifier/
> SequenceGeneratorUnnamedTest.java#L55-L57
> ___
> 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] SQL Server 2016

[Vlad Mihalcea]

For SQL Server, 2012 is our latest supported Dialect.

I've been running tests on my local SQL Server 2016 Express and everything
worked fine.
As for Jenkins, we don't have support for MSSQL.

I'm not sure if the Linux version license allows us to run tests on
Jenkins, but if it does,
I think we should add a new automated Job for MSSQL as well.

Vlad

On Tue, Aug 29, 2017 at 1:01 PM, Sanne Grinovero 
wrote:

> Do we support SQL Server 2016 ?
>
> I saw no explicit mention of it in the docs but I suppose it might
> work. Do we test it, regularly or occasionally?
>
> 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] Empty composites and embeddable containing an embeddable

[Vlad Mihalcea]

I guess we should create the nested embeddable as well.

Vlad

On Fri, Aug 11, 2017 at 2:02 AM, Gail Badner  wrote:

> If an embeddable contains an embeddable, and the outer embeddable is
> instantiated due to hibernate.create_empty_composites.enabled=true, should
> the inner embeddable be instantiated as well?
>
> Currently, the inner embeddable is not instantiated. I am guessing that it
> should be. I just wanted to make sure before creating a jira and fixing.
>
> 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] Contributions - changes "CLA" process

[Vlad Mihalcea]

Woohoo! That's great news.

Vlad

On Tue, Aug 8, 2017 at 12:27 AM, Steve Ebersole  wrote:

> Currently we have had to rely on a less-than-ideal CLA approach as part of
> the process for accepting a contribution.  That CLA app is a hassle for
> contributors and it is a head-ache for the folks who manage them.  So in an
> effort to stream-line this process, we will be making the following changes
> to this process:
>
>1. We will no longer be using that CLA app.
>2. CONTRIBUTING.MD will be updated to indicate that developers
>implicitly agree to contributing their contributions under the terms of
> the
>pertinent license (LGPL generally).  Some documentation and some website
>pages refer to the CLA process and will be updated to point to the
>CONTRIBUTING.MD file directly.
>3. Did I say we would no longer be using the CLA app? ;)
>
> The end result is that when we process contributions (whether PR, patch
> attached to Jira, etc) we no longer need to ask the contributor to sign the
> CLA - such approval is implicitly given.
>
> Note that this is not really even a change.  The proposed process is the
> general understanding of contributions to any project in terms of agreement
> with the terms of that project's license.  The point of the CLA was never
> really acceptance of the terms of the license anyway.  It was more
> identifying contributors of pieces of code in case we ever want to
> re-license.
>
> This all came from a discussion with the Red Hat legal team, so I feel
> extremely confident this is a good change and a sound one.
>
> I will only be making said changes to the ORM repo.  I leave it up to the
> non-ORM team whether they want to change the non-ORM repos to follow these
> guidelines as well.
> ___
> 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 FAQ

[Vlad Mihalcea]

Hi Steve,

I read it and I have some the following suggestions:

1. For the Performance section, I'd add the transparent JDBC batch updates,
the delayed connection acquisition, cacheable natural id fetching.

2. For the How does Hibernate compare to JPA section, I'd add a list of
cool features Hibernate has to offer on top of JPA:

- extended identifier generators (hi/lo, pooled, pooled-lo)
- customizable CRUD (@SQLInsert, @SQLUpdate, @SQLDelete) statements
- immutable entities (e.g. @Immutable)
- versionless optimistic locking (e.g. OptimisticLockType.ALL,
OptimisticLockType.DIRTY)
- support for skipping (without waiting) pessimistic lock requests
- support for multitenancy

3. For the jOOQ part:

I'm not sure about the "JDBC libraries" term. All data access frameworks
build on top of JDBC. Maybe "SQL statement builder frameworks" or "Active
Record frameworks" are more suitable.

Otherwise, it's a good addition to the Hibernate documentation.

Vlad

On Fri, Aug 4, 2017 at 6:46 PM, Steve Ebersole  wrote:

> I spent some time this a.m. working on changes to the ORM FAQ page:
> http://staging.hibernate.org/orm/faq/
>
> Let me know what you think.  It's still not "done", but further along.
>
> I am trying to avoid "usage" FAQ entries.  These should be more generalized
> project FAQs.  We should decide how/where we want to handle "usage" FAQs,
> if at all.
> ___
> 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] Plan on adding the JPA 2.2 Query#getResultStream() in 5.2

[Vlad Mihalcea]

I added this Pull Request, and, if it gets approved, we could integrate it
for 5.2.11

https://github.com/hibernate/hibernate-orm/pull/1973

On Thu, Aug 3, 2017 at 10:47 AM, Gunnar Morling 
wrote:

> > I've never considered changing the dependencies in any way.
>
> Cool, we're all on the same page then.
>
> 2017-08-02 21:16 GMT+01:00 Vlad Mihalcea :
>
>> Sure, but you may not publish something like an JPA 2.1+ with just some
>>> of the 2.2 methods.
>>
>>
>> I don't understand this part because, for instance, we already support
>> Java 1.8 Date/Time types for quite some time. So, Hibernate 5.x already
>> supports JPA 2.1 +.
>>
>> The 5.1 Stream support is also in the JPA 2.1+ category too. The only
>> difference is that the method is called stream and not getStreamResult.
>>
>> Now, back to the org.hibernate.query.Query method:
>>
>> default Stream getResultStream() {
>>return stream();
>> }
>>
>>
>> Even if the JPA 2.2 define this method, we can still implement it as a
>> default method and that will work for both JPA 2.1 and JPA 2.2, right?
>>
>> I've never considered changing the dependencies in any way. It's just
>> this method that makes it easier to use Hibernate 5.2 with both JPA 2.1 and
>> JPA 2.2 API.
>>
>> Vlad
>>
>> On Wed, Aug 2, 2017 at 8:40 PM, Gunnar Morling 
>> wrote:
>>
>>> Sure, but you may not publish something like an JPA 2.1+ with just some
>>> of the 2.2 methods.
>>>
>>> 2017-08-02 17:40 GMT+01:00 Sanne Grinovero :
>>>
>>>> On 2 August 2017 at 17:07, Gunnar Morling  wrote:
>>>> >> You don't plan on actually updating the JPA API we use at build time
>>>> >> right?
>>>> >
>>>> > We cannot do that, you may not provide a version of a spec'ed API with
>>>> > additional methods. It'd have to be in ORM's sub-interface or similar.
>>>>
>>>> The new spec'ed API already has this method.
>>>>
>>>
>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Plan on adding the JPA 2.2 Query#getResultStream() in 5.2

[Vlad Mihalcea]

>
> Sure, but you may not publish something like an JPA 2.1+ with just some of
> the 2.2 methods.


I don't understand this part because, for instance, we already support Java
1.8 Date/Time types for quite some time. So, Hibernate 5.x already supports
JPA 2.1 +.

The 5.1 Stream support is also in the JPA 2.1+ category too. The only
difference is that the method is called stream and not getStreamResult.

Now, back to the org.hibernate.query.Query method:

default Stream getResultStream() {
   return stream();
}


Even if the JPA 2.2 define this method, we can still implement it as a
default method and that will work for both JPA 2.1 and JPA 2.2, right?

I've never considered changing the dependencies in any way. It's just this
method that makes it easier to use Hibernate 5.2 with both JPA 2.1 and JPA
2.2 API.

Vlad

On Wed, Aug 2, 2017 at 8:40 PM, Gunnar Morling  wrote:

> Sure, but you may not publish something like an JPA 2.1+ with just some of
> the 2.2 methods.
>
> 2017-08-02 17:40 GMT+01:00 Sanne Grinovero :
>
>> On 2 August 2017 at 17:07, Gunnar Morling  wrote:
>> >> You don't plan on actually updating the JPA API we use at build time
>> >> right?
>> >
>> > We cannot do that, you may not provide a version of a spec'ed API with
>> > additional methods. It'd have to be in ORM's sub-interface or similar.
>>
>> The new spec'ed API already has this method.
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Plan on adding the JPA 2.2 Query#getResultStream() in 5.2

[Vlad Mihalcea]

I don't think it will break anything since the method will be a default one
in org.hibernate.query.Query

default Stream getResultStream() {
   return stream();
}

That will do it.

Vlad


On Wed, Aug 2, 2017 at 6:16 PM, Sanne Grinovero  wrote:

> On 2 August 2017 at 15:21, Vlad Mihalcea  wrote:
> > Hi,
> >
> > I plan on adding the JPA 2.2 Query#getResultStream() method since we
> > already support streaming and,
> > this way, Hibernate 5.2 will work even if the client has a JPA 2.2
> > dependency in their classpath.
> >
> > https://jcp.org/aboutJava/communityprocess/maintenance/
> jsr338/ChangeLog-JPA-2.2-MR.txt
> >
> > While we can allow the 6.0 release to be fully JPA 2.2 compliant, is
> there
> > anyone against adding the aforementioned change in 5.2 as well?
> >
> > Vlad
>
> Such a change would break Hibernate Search integration.
>
> I'm not strictly against it as we can catch up on the Search side, but
> it introduces a burden for end users to be aware of which precise
> versions they will need: typically we promise that any "micro" in the
> same major.minor will be compatible, so we'd be violating this rule.
> Anyone not using this method would be unaffected so this seems a very
> minor point but I think the "stick to the rules" part is more valuable
> to keep people from worrying.
>
> On which interfaces do you plan adding this method exactly?
>
> You don't plan on actually updating the JPA API we use at build time right?
>
> Thanks,
> Sanne
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Plan on adding the JPA 2.2 Query#getResultStream() in 5.2

[Vlad Mihalcea]

Hi,

I plan on adding the JPA 2.2 Query#getResultStream() method since we
already support streaming and,
this way, Hibernate 5.2 will work even if the client has a JPA 2.2
dependency in their classpath.

https://jcp.org/aboutJava/communityprocess/maintenance/jsr338/ChangeLog-JPA-2.2-MR.txt

While we can allow the 6.0 release to be fully JPA 2.2 compliant, is there
anyone against adding the aforementioned change in 5.2 as well?

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

Re: [hibernate-dev] Difference between Comment and Hint in Hibernate query

[Vlad Mihalcea]

HI,

I think I'll have to make it a little bit more clear in the docs as well. I
Knew about Hibernate comments and assumed they could be used as hints.

Now, that I look back on the Query API I see they were added in 4.3:

http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/Query.html#addQueryHint(java.lang.String)

But I can't find it in 4.2:

http://docs.jboss.org/hibernate/orm/4.2/javadocs/org/hibernate/Query.html

I will adjust my PR accordingly so that the comment on @NamedQuery will
only be propagated if the associated Hibernate property is set.
As for @NamedNativeQuery, I think we need to support it since we have the
comment attribute on the annotation level.

Vlad

On Tue, Aug 1, 2017 at 6:16 PM, Steve Ebersole  wrote:

> See inline..
>
> On Tue, Aug 1, 2017 at 9:05 AM Vlad Mihalcea 
> wrote:
>
>> I created a new Pull Request so that comments can be handled for named
>> queries (even for UPDATE/DELETE queries):
>>
>> https://github.com/hibernate/hibernate-orm/pull/1970
>>
>
> Not really following this.  See `org.hibernate.annotations.NamedQuery#comment`
> and `org.hibernate.annotations.QueryHints#COMMENT`.  So we do support
> this for named queries.  Hints are generally only useful (if at all) for
> SELECTs.  Comments can be useful for any type of statement, but again we
> have the support for those in place in regards to named queries.
>
>
> I think we should add two new issues;
>>
>> 1. So that we could pass Query Hints for Named (Native) Queries as well.
>> Right now we can only pass comments which are appended at the beginning of
>> the SQL statement.
>>
>
> I completely disagree about supporting comments and/or hints for native
> SQL queries.
>
> As for "[we only support] comments which are appended at the beginning of
> the SQL statement" - that is true for comments.  However, it is inaccurate
> for hints - see `org.hibernate.dialect.Dialect#getQueryHintString`.  So
> the hook is in place for handling this for hints.  There is no such hook
> for comments - do you concretely know of a Dialect that supports a comment
> elsewhere than the start?  I'm a little leery of adding support for this
> pre-6.0 as we know for certain that this will change (String-based versus
> AST-based).  If you wan to add such a hook in 6.0, I am ok with that -
> provided you can show me such a concrete use case.
>
>
>
>
>> 2. I see we support Query Hints for Oracle and SQL Server. We should
>> support MySQL as well:
>>
>> https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html
>>
>
> Sure - I think its a good idea to support this where ever  the underlying
> database supports it.
>
>
> If you have time to take a look on the PR, let me know what you think.
>>
>
> I'll take a look at the PR after we resolve these general points and they
> are incorporated into the PR.
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Difference between Comment and Hint in Hibernate query

[Vlad Mihalcea]

I created a new Pull Request so that comments can be handled for named
queries (even for UPDATE/DELETE queries):

https://github.com/hibernate/hibernate-orm/pull/1970

I think we should add two new issues;

1. So that we could pass Query Hints for Named (Native) Queries as well.
Right now we can only pass comments which are appended at the beginning of
the SQL statement.
2. I see we support Query Hints for Oracle and SQL Server. We should
support MySQL as well:

https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html

If you have time to take a look on the PR, let me know what you think.

Thanks

On Tue, Aug 1, 2017 at 4:28 PM, Steve Ebersole  wrote:

> They have different intentions and are potentially applied in different
> ways for different databases - hence separate.
>
> E.g. DB2 supports a query comment, but does not support optimizer hints...
> so these need to be handled differently
>
> On Tue, Aug 1, 2017, 8:19 AM Vlad Mihalcea 
> wrote:
>
>> I'm asking because the
>>
>> org.hibernate.annotations.NamedNativeQuery or
>> org.hibernate.annotations.NamedQuery
>>
>> define the comment attribute with the following Javadoc:
>>
>> /**
>>  * A comment added to the generated SQL query.  Useful when engaging with 
>> DBA.
>>  */
>> String comment() default "";
>>
>> So, Hibernate clients could use the comment attribute in order to supply
>> an Oracle query hint, right?
>>
>> In this case, should we treat this attribute as a query hint so that the
>> Oracle/SQL Server hint logic applies to this one as well?
>>
>> Vlad
>>
>> On Tue, Aug 1, 2017 at 4:07 PM, Steve Ebersole 
>> wrote:
>>
>>> Query hints are hints for the database' s query parser/optimizer.
>>>
>>> A comment is a... well a comment :)
>>>
>>> On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> While working on integrating a Pull Request, I realized that the
>>>> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>>>>
>>>> private String comment;
>>>> private List queryHints;
>>>>
>>>> Both these two are to be sent to the database, so why do we have both?
>>>>
>>>> I also noticed that only for Query Hints we do take into consideration
>>>> DB
>>>> specific query hint syntax:
>>>>
>>>> // Keep this here, rather than moving to Select.  Some Dialects may
>>>> need the hint to be appended to the very
>>>> // end or beginning of the finalized SQL statement, so wait until
>>>> everything is processed.
>>>> if ( parameters.getQueryHints() != null &&
>>>> parameters.getQueryHints().size() > 0 ) {
>>>>sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
>>>> }
>>>>
>>>> Shouldn't we only have either comment or queryHints? Or what is the
>>>> difference between these two?
>>>>
>>>> Vlad
>>>> ___
>>>> hibernate-dev mailing list
>>>> hibernate-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

[Vlad Mihalcea]

Sure. Send me a Pull Request and I'll integrate it.

Vlad

On Tue, Aug 1, 2017 at 2:29 PM, Arnold Gálovics 
wrote:

> Hey Vlad,
>
> Thanks for the clarification. Do you think it worth mentioning this in the
> docs?
>
> Best,
> Arnold
>
> On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea 
> wrote:
>
>> In MVCC, shared and exclusive are not as significant as in 2PL
>> concurrency control which only SQL Server supports by default nowadays.
>>
>> Even if the row is locked in shared or exclusive mode, some other DB will
>> still read it. It's just that they will not be able to modify it or
>> acquire locks. Here, if you acquire a shared lock, others will still be
>> able to acquire a shared lock as well, and that will offer no advantage for
>> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
>>
>> So, I suppose the lock should always be exclusive so that other lock
>> requests are blocked until the lock is released.
>>
>> Vlad
>>
>> On Fri, Jul 28, 2017 at 9:35 AM, Arnold Gálovics <
>> galovicsarn...@gmail.com> wrote:
>>
>>> Hey,
>>>
>>> I'm still a bit uncertain about this, as I only tested this lock mode
>>> with H2 which as far as I know is not supporting shared locks, so it will
>>> automatically acquire an exclusive lock. That is a possibility why I've
>>> seen the FOR UPDATE clause at the end of the SELECT statement.
>>>
>>> *My question rather is:* what's the intended behavior of this lock
>>> mode?
>>> Okay, it's a pessimistic lock with incrementing the version number
>>> automatically at locking time. What type of lock will it acquire? Shared or
>>> exclusive?
>>> I think this is important and it should be really mentioned in the
>>> Hibernate docs as now it's a bit confusing. The JPA spec is also unclear
>>> for me about this lock mode.
>>>
>>> Thank you guys for helping me out!
>>>
>>> Best Regards,
>>> Arnold
>>>
>>>
>>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea 
>>> wrote:
>>>
>>>> That's how Hibernate was executing the statements when I wrote the
>>>> article.
>>>>
>>>> I spotted the difference when writing the book, but didn't have time to
>>>> update the article.
>>>> I changed the SQL output to reflect the current behavior which adds a
>>>> FOR UPDATE clause when fetching the entity.
>>>>
>>>> I also rephrased that sentence since it's no longer relevant to the
>>>> current behavior.
>>>>
>>>> Vlad
>>>>
>>>> On Thu, Jul 27, 2017 at 4:46 PM, Arnold Gálovics <
>>>> galovicsarn...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm a bit confused with the mentioned lock mode.
>>>>>
>>>>> *The doc says the following:*
>>>>> *"The entity is locked pessimistically and its version is incremented
>>>>> automatically even if the entity has not changed."*
>>>>>
>>>>> I'm checking this with an H2 DB and the current behavior is the
>>>>> following:
>>>>> - the version attribute is incremented in advance, right after fetching
>>>>> (I'm using EntityManager#find here, but with lock, it should be the
>>>>> same)
>>>>> - the original fetching query contains the SELECT ... FOR UPDATE clause
>>>>>
>>>>> Knowing this, it seems for me that this lock mode involves a DB lock,
>>>>> however the doc doesn't say anything about this, especially whether
>>>>> it's a
>>>>> shared or exclusive lock.
>>>>>
>>>>> I've checked Vlad's article about this.
>>>>> https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
>>>>> ns-how-does-pessimistic_force_increment-lock-mode-work/
>>>>>
>>>>> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
>>>>> lead
>>>>> you into thinking that you are using a pessimistic locking strategy,
>>>>> while
>>>>> in reality this Lock Mode is just an optimistic locking variation."*
>>>>>
>>>>> So now I'm unsure what this really is.
>>>>>
>>>>> Could you please briefly describe it to me if I missed something?
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>>> Best Regards,
>>>>> Arnold
>>>>> ___
>>>>> 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] Difference between Comment and Hint in Hibernate query

[Vlad Mihalcea]

I'm asking because the

org.hibernate.annotations.NamedNativeQuery or
org.hibernate.annotations.NamedQuery

define the comment attribute with the following Javadoc:

/**
 * A comment added to the generated SQL query.  Useful when engaging with DBA.
 */
String comment() default "";

So, Hibernate clients could use the comment attribute in order to supply an
Oracle query hint, right?

In this case, should we treat this attribute as a query hint so that the
Oracle/SQL Server hint logic applies to this one as well?

Vlad

On Tue, Aug 1, 2017 at 4:07 PM, Steve Ebersole  wrote:

> Query hints are hints for the database' s query parser/optimizer.
>
> A comment is a... well a comment :)
>
> On Tue, Aug 1, 2017, 6:37 AM Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> While working on integrating a Pull Request, I realized that the
>> org.hibernate.engine.spi.QueryParameters provides these two attributes:
>>
>> private String comment;
>> private List queryHints;
>>
>> Both these two are to be sent to the database, so why do we have both?
>>
>> I also noticed that only for Query Hints we do take into consideration DB
>> specific query hint syntax:
>>
>> // Keep this here, rather than moving to Select.  Some Dialects may
>> need the hint to be appended to the very
>> // end or beginning of the finalized SQL statement, so wait until
>> everything is processed.
>> if ( parameters.getQueryHints() != null &&
>> parameters.getQueryHints().size() > 0 ) {
>>sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
>> }
>>
>> Shouldn't we only have either comment or queryHints? Or what is the
>> difference between these two?
>>
>> Vlad
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Difference between Comment and Hint in Hibernate query

[Vlad Mihalcea]

Hi,

While working on integrating a Pull Request, I realized that the
org.hibernate.engine.spi.QueryParameters provides these two attributes:

private String comment;
private List queryHints;

Both these two are to be sent to the database, so why do we have both?

I also noticed that only for Query Hints we do take into consideration DB
specific query hint syntax:

// Keep this here, rather than moving to Select.  Some Dialects may
need the hint to be appended to the very
// end or beginning of the finalized SQL statement, so wait until
everything is processed.
if ( parameters.getQueryHints() != null &&
parameters.getQueryHints().size() > 0 ) {
   sql = dialect.getQueryHintString( sql, parameters.getQueryHints() );
}

Shouldn't we only have either comment or queryHints? Or what is the
difference between these two?

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

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

[Vlad Mihalcea]

In MVCC, shared and exclusive are not as significant as in 2PL concurrency
control which only SQL Server supports by default nowadays.

Even if the row is locked in shared or exclusive mode, some other DB will
still read it. It's just that they will not be able to modify it or
acquire locks. Here, if you acquire a shared lock, others will still be
able to acquire a shared lock as well, and that will offer no advantage for
the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.

So, I suppose the lock should always be exclusive so that other lock
requests are blocked until the lock is released.

Vlad

On Fri, Jul 28, 2017 at 9:35 AM, Arnold Gálovics 
wrote:

> Hey,
>
> I'm still a bit uncertain about this, as I only tested this lock mode with
> H2 which as far as I know is not supporting shared locks, so it will
> automatically acquire an exclusive lock. That is a possibility why I've
> seen the FOR UPDATE clause at the end of the SELECT statement.
>
> *My question rather is:* what's the intended behavior of this lock mode?
> Okay, it's a pessimistic lock with incrementing the version number
> automatically at locking time. What type of lock will it acquire? Shared or
> exclusive?
> I think this is important and it should be really mentioned in the
> Hibernate docs as now it's a bit confusing. The JPA spec is also unclear
> for me about this lock mode.
>
> Thank you guys for helping me out!
>
> Best Regards,
> Arnold
>
>
> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea 
> wrote:
>
>> That's how Hibernate was executing the statements when I wrote the
>> article.
>>
>> I spotted the difference when writing the book, but didn't have time to
>> update the article.
>> I changed the SQL output to reflect the current behavior which adds a FOR
>> UPDATE clause when fetching the entity.
>>
>> I also rephrased that sentence since it's no longer relevant to the
>> current behavior.
>>
>> Vlad
>>
>> On Thu, Jul 27, 2017 at 4:46 PM, Arnold Gálovics <
>> galovicsarn...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm a bit confused with the mentioned lock mode.
>>>
>>> *The doc says the following:*
>>> *"The entity is locked pessimistically and its version is incremented
>>> automatically even if the entity has not changed."*
>>>
>>> I'm checking this with an H2 DB and the current behavior is the
>>> following:
>>> - the version attribute is incremented in advance, right after fetching
>>> (I'm using EntityManager#find here, but with lock, it should be the same)
>>> - the original fetching query contains the SELECT ... FOR UPDATE clause
>>>
>>> Knowing this, it seems for me that this lock mode involves a DB lock,
>>> however the doc doesn't say anything about this, especially whether it's
>>> a
>>> shared or exclusive lock.
>>>
>>> I've checked Vlad's article about this.
>>> https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
>>> ns-how-does-pessimistic_force_increment-lock-mode-work/
>>>
>>> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
>>> lead
>>> you into thinking that you are using a pessimistic locking strategy,
>>> while
>>> in reality this Lock Mode is just an optimistic locking variation."*
>>>
>>> So now I'm unsure what this really is.
>>>
>>> Could you please briefly describe it to me if I missed something?
>>>
>>> Thanks in advance!
>>>
>>> Best Regards,
>>> Arnold
>>> ___
>>> 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] PESSIMISTIC_FORCE_INCREMENT lock mode

[Vlad Mihalcea]

That's how Hibernate was executing the statements when I wrote the article.

I spotted the difference when writing the book, but didn't have time to
update the article.
I changed the SQL output to reflect the current behavior which adds a FOR
UPDATE clause when fetching the entity.

I also rephrased that sentence since it's no longer relevant to the current
behavior.

Vlad

On Thu, Jul 27, 2017 at 4:46 PM, Arnold Gálovics 
wrote:

> Hi all,
>
> I'm a bit confused with the mentioned lock mode.
>
> *The doc says the following:*
> *"The entity is locked pessimistically and its version is incremented
> automatically even if the entity has not changed."*
>
> I'm checking this with an H2 DB and the current behavior is the following:
> - the version attribute is incremented in advance, right after fetching
> (I'm using EntityManager#find here, but with lock, it should be the same)
> - the original fetching query contains the SELECT ... FOR UPDATE clause
>
> Knowing this, it seems for me that this lock mode involves a DB lock,
> however the doc doesn't say anything about this, especially whether it's a
> shared or exclusive lock.
>
> I've checked Vlad's article about this.
> https://vladmihalcea.com/2015/02/16/hibernate-locking-
> patterns-how-does-pessimistic_force_increment-lock-mode-work/
>
> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might lead
> you into thinking that you are using a pessimistic locking strategy, while
> in reality this Lock Mode is just an optimistic locking variation."*
>
> So now I'm unsure what this really is.
>
> Could you please briefly describe it to me if I missed something?
>
> Thanks in advance!
>
> Best Regards,
> Arnold
> ___
> 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] Are arrays of non-basic elements supported?

[Vlad Mihalcea]

I applied your suggestions an issued a new commit.

On Thu, Jul 27, 2017 at 5:26 PM, Steve Ebersole  wrote:

> I think that is still confusing.  I'd suggest something like:
>
> 
> When discussing arrays, it is important to understand the distinction
> between SQL array types and Java arrays that are mapped as part of the
> application's domain model.
>
> Not all databases implement the SQL-99 ARRAY type and, for this reason,
> Hibernate doesn't support native database array types.
>
> Hibernate does support the mapping of arrays in the Java domain model -
> conceptually the same as mapping a List.  However, it is important to
> realize that it is impossible for Hibernate to offer lazy-loading for
> arrays of entities and, for this reason, it is strongly recommended to map
> a "collection" of entities using a List rather than an array.
> 
>
>
> On Thu, Jul 27, 2017 at 2:04 AM Vlad Mihalcea 
> wrote:
>
>> I fixed it with the following commit:
>>
>> https://github.com/hibernate/hibernate-orm/commit/
>> 871722dc08ec131cd1f5238e1b48df8db2dcc402
>>
>> Let me know if it's more clear now.
>>
>> Vlad
>>
>> On Wed, Jul 26, 2017 at 7:32 PM, Gail Badner  wrote:
>>
>>> OK, I'll make sure Hibernate also treats an empty array element as
>>>  equivalent to null as well.
>>>
>>> Vlad, thanks for correcting the documentation.
>>>
>>> On Wed, Jul 26, 2017 at 7:38 AM, Vlad Mihalcea 
>>> wrote:
>>>
>>>> The docs says:
>>>>
>>>> When it comes to arrays, there is quite a difference between Java
>>>> arrays and relational database array types (e.g. VARRAY, ARRAY). First, not
>>>> all database systems implement the SQL-99 ARRAY type, and, for this reason,
>>>> Hibernate doesn’t support native database array types. Second, Java arrays
>>>> are relevant for basic types only since storing multiple embeddables or
>>>> entities should always be done using the Java Collection API.
>>>>
>>>> I guess the "Second, Java arrays ..." part is indeed a little bit
>>>> misleading.
>>>>
>>>> I created the following issue:
>>>>
>>>> https://hibernate.atlassian.net/browse/HHH-11891
>>>>
>>>> Is it a problem if I link the docs to my blog post about how to support
>>>> arrays of basic types?
>>>>
>>>> https://vladmihalcea.com/2017/06/21/how-to-map-java-and-sql-
>>>> arrays-with-jpa-and-hibernate/
>>>>
>>>> Thanks,
>>>> Vlad
>>>>
>>>> On Wed, Jul 26, 2017 at 4:04 PM, Steve Ebersole 
>>>> wrote:
>>>>
>>>>> That doc section is wrong.  Vlad - can you fix that
>>>>>
>>>>> We do in fact support arrays of all types including embeddables and
>>>>> entities.  However, we have always recommended to not use arrays for
>>>>> entities as arrays cannot be lazy loaded (not even using bytecode
>>>>> enhancement).
>>>>>
>>>>> On Mon, Jul 24, 2017 at 6:29 PM Gail Badner 
>>>>> wrote:
>>>>>
>>>>> > Documentation makes it sound like only arrays of basic types are
>>>>> supported.
>>>>> > [1]
>>>>> >
>>>>> > I see a test using an array of entities, but I don't see one for an
>>>>> array
>>>>> > of embeddables. [2]
>>>>> >
>>>>> > Regards,
>>>>> > Gail
>>>>> >
>>>>> > [1]
>>>>> >
>>>>> > http://docs.jboss.org/hibernate/orm/5.2/userguide/
>>>>> html_single/Hibernate_User_Guide.html#collections-array
>>>>> > [2]
>>>>> >
>>>>> > https://github.com/hibernate/hibernate-orm/blob/master/
>>>>> hibernate-core/src/test/java/org/hibernate/test/
>>>>> annotations/array/Contest.java#L40-L42
>>>>> > ___
>>>>> > 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 - procedure/function calls via NativeQuery

[Vlad Mihalcea]

If we make this change, we need to make sure the StoredProcedureQuery works
properly for functions too:

https://vladmihalcea.com/2016/04/27/how-to-call-sql-server-stored-procedures-and-functions-from-hibernate/

Currently, it only supports stored procedures and not database functions.
However, users can also use session.doWork instead so there is a workaround
anyway.

Vlad

On Thu, Jul 27, 2017 at 11:37 AM, Arnold Gálovics 
wrote:

> Hey,
>
> @Vlad: if they eventually have to adjust their code, why is it so hard to
> use the proper API for calling stored procedures?
>
> I'm supporting Steve's idea to remove this complexity and force the users
> to use the proper API. I think for 6.0 this change can be acceptable and
> should be mentioned in the migration guide.
>
> Best Regards,
> Arnold
>
>
>
> On Thu, Jul 27, 2017 at 7:25 AM, Vlad Mihalcea 
> wrote:
>
>> I run a quick Google search for "Hibernate NnativeQuery stored procedure"
>> and found these links:
>>
>> http://www.baeldung.com/stored-procedures-with-hibernate-tutorial
>>
>> https://www.mkyong.com/hibernate/how-to-call-store-procedure
>> -in-hibernate/
>>
>> I guess people used to do this. We could use some QueryHint which needs to
>> be supplied when users want to execute a SP via NativeQuery.
>> I think it's less painful to have this option instead of disallowing it
>> completely.
>>
>> Vlad
>>
>> On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole 
>> wrote:
>>
>> > Another unnecessary complexity I'd like discuss removing is the ability
>> to
>> > execute procedure/function calls via NativeQuery.  The complexity is a
>> > bunch of String parsing and token interpretation we need to do in order
>> to
>> > discovery this intention.  Given that both JPA and Hibernate define
>> > specific APIs for executing procedure/function calls this seems like an
>> > unnecessary complexity and overhead.
>> >
>> > Objections?  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] Are arrays of non-basic elements supported?

[Vlad Mihalcea]

I fixed it with the following commit:

https://github.com/hibernate/hibernate-orm/commit/871722dc08ec131cd1f5238e1b48df8db2dcc402

Let me know if it's more clear now.

Vlad

On Wed, Jul 26, 2017 at 7:32 PM, Gail Badner  wrote:

> OK, I'll make sure Hibernate also treats an empty array element as
>  equivalent to null as well.
>
> Vlad, thanks for correcting the documentation.
>
> On Wed, Jul 26, 2017 at 7:38 AM, Vlad Mihalcea 
> wrote:
>
>> The docs says:
>>
>> When it comes to arrays, there is quite a difference between Java arrays
>> and relational database array types (e.g. VARRAY, ARRAY). First, not all
>> database systems implement the SQL-99 ARRAY type, and, for this reason,
>> Hibernate doesn’t support native database array types. Second, Java arrays
>> are relevant for basic types only since storing multiple embeddables or
>> entities should always be done using the Java Collection API.
>>
>> I guess the "Second, Java arrays ..." part is indeed a little bit
>> misleading.
>>
>> I created the following issue:
>>
>> https://hibernate.atlassian.net/browse/HHH-11891
>>
>> Is it a problem if I link the docs to my blog post about how to support
>> arrays of basic types?
>>
>> https://vladmihalcea.com/2017/06/21/how-to-map-java-and-sql-
>> arrays-with-jpa-and-hibernate/
>>
>> Thanks,
>> Vlad
>>
>> On Wed, Jul 26, 2017 at 4:04 PM, Steve Ebersole 
>> wrote:
>>
>>> That doc section is wrong.  Vlad - can you fix that
>>>
>>> We do in fact support arrays of all types including embeddables and
>>> entities.  However, we have always recommended to not use arrays for
>>> entities as arrays cannot be lazy loaded (not even using bytecode
>>> enhancement).
>>>
>>> On Mon, Jul 24, 2017 at 6:29 PM Gail Badner  wrote:
>>>
>>> > Documentation makes it sound like only arrays of basic types are
>>> supported.
>>> > [1]
>>> >
>>> > I see a test using an array of entities, but I don't see one for an
>>> array
>>> > of embeddables. [2]
>>> >
>>> > Regards,
>>> > Gail
>>> >
>>> > [1]
>>> >
>>> > http://docs.jboss.org/hibernate/orm/5.2/userguide/html_singl
>>> e/Hibernate_User_Guide.html#collections-array
>>> > [2]
>>> >
>>> > https://github.com/hibernate/hibernate-orm/blob/master/hiber
>>> nate-core/src/test/java/org/hibernate/test/annotations/array
>>> /Contest.java#L40-L42
>>> > ___
>>> > 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 - procedure/function calls via NativeQuery

[Vlad Mihalcea]

I run a quick Google search for "Hibernate NnativeQuery stored procedure"
and found these links:

http://www.baeldung.com/stored-procedures-with-hibernate-tutorial

https://www.mkyong.com/hibernate/how-to-call-store-procedure-in-hibernate/

I guess people used to do this. We could use some QueryHint which needs to
be supplied when users want to execute a SP via NativeQuery.
I think it's less painful to have this option instead of disallowing it
completely.

Vlad

On Thu, Jul 27, 2017 at 1:08 AM, Steve Ebersole  wrote:

> Another unnecessary complexity I'd like discuss removing is the ability to
> execute procedure/function calls via NativeQuery.  The complexity is a
> bunch of String parsing and token interpretation we need to do in order to
> discovery this intention.  Given that both JPA and Hibernate define
> specific APIs for executing procedure/function calls this seems like an
> unnecessary complexity and overhead.
>
> Objections?  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] Are arrays of non-basic elements supported?

[Vlad Mihalcea]

The docs says:

When it comes to arrays, there is quite a difference between Java arrays
and relational database array types (e.g. VARRAY, ARRAY). First, not all
database systems implement the SQL-99 ARRAY type, and, for this reason,
Hibernate doesn’t support native database array types. Second, Java arrays
are relevant for basic types only since storing multiple embeddables or
entities should always be done using the Java Collection API.

I guess the "Second, Java arrays ..." part is indeed a little bit
misleading.

I created the following issue:

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

Is it a problem if I link the docs to my blog post about how to support
arrays of basic types?

https://vladmihalcea.com/2017/06/21/how-to-map-java-and-sql-arrays-with-jpa-and-hibernate/

Thanks,
Vlad

On Wed, Jul 26, 2017 at 4:04 PM, Steve Ebersole  wrote:

> That doc section is wrong.  Vlad - can you fix that
>
> We do in fact support arrays of all types including embeddables and
> entities.  However, we have always recommended to not use arrays for
> entities as arrays cannot be lazy loaded (not even using bytecode
> enhancement).
>
> On Mon, Jul 24, 2017 at 6:29 PM Gail Badner  wrote:
>
> > Documentation makes it sound like only arrays of basic types are
> supported.
> > [1]
> >
> > I see a test using an array of entities, but I don't see one for an array
> > of embeddables. [2]
> >
> > Regards,
> > Gail
> >
> > [1]
> >
> > http://docs.jboss.org/hibernate/orm/5.2/userguide/
> html_single/Hibernate_User_Guide.html#collections-array
> > [2]
> >
> > https://github.com/hibernate/hibernate-orm/blob/master/
> hibernate-core/src/test/java/org/hibernate/test/annotations/array/Contest.
> java#L40-L42
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM Docbook removal

[Vlad Mihalcea]

Hi,

Since it's more than one year since we switched to Asciidoc, I think we
should remove the docbook folder.

Does anyone has anything against it or thinks this is not a good idea?

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

Re: [hibernate-dev] Hibernate Extras module

[Vlad Mihalcea]

Hi,

For Ipv4 Type, we need a dependency for PgObject.
For JSON, we need the Jackson dependency, and I would not add those to the
hibernate-core.

That's why I'm thinking of an extra module.

Vlad

On Sat, Jul 1, 2017 at 7:48 PM, Arnold Gálovics 
wrote:

> Hi Vlad,
>
> "any other features that cannot be added into the hibernate-core because they
> are DB-specific."
> Aren't Dialects in Hibernate DB specific? Why is there a reason not to
> support some DB specific feature in Hibernate core?
>
> Isn't it possible to have DB specific Hibernate modules? For example
> hibernate-core contains the core of Hibernate (as the name suggests) but
> everything else DB specific is in a specific module, Dialects, custom
> types, etc.
>
> If you could clarify this for me, that would be great as I don't know the
> historic reasons. :-)
>
> Thank you guys!
>
> Best,
> Arnold
>
> On Sat, Jul 1, 2017 at 6:31 PM, Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> Someone asked me if I can supply the JSON Type as a separate module so
>> that
>> it can be grabbed from Maven Central:
>>
>> https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-
>> using-generic-hibernate-types/
>>
>> I wonder if we should supply a hibernate-extras where we include
>> non-standard features:
>>
>> - JSON Types
>> - ARRAY types
>> - Ipv4 Types
>>
>> or any other features that cannot be added into the hibernate-core because
>> they are DB-specific.
>>
>> Let me know what you think.
>>
>> Vlad
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Extras module

[Vlad Mihalcea]

Hi,

Someone asked me if I can supply the JSON Type as a separate module so that
it can be grabbed from Maven Central:

https://vladmihalcea.com/2016/06/20/how-to-map-json-objects-using-generic-hibernate-types/

I wonder if we should supply a hibernate-extras where we include
non-standard features:

- JSON Types
- ARRAY types
- Ipv4 Types

or any other features that cannot be added into the hibernate-core because
they are DB-specific.

Let me know what you think.

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

Re: [hibernate-dev] Continue to add 5.2 deprecations for 6.0 work?

[Vlad Mihalcea]

The concept is good and we should apply it. Instead of @EndOfLife we could
use @Deprecating
as it suggests a continuing action has not finished yet, but the eventual
outcome is obvious.

Makes sense?

Vlad

On Wed, Jun 28, 2017 at 4:51 PM, Steve Ebersole  wrote:

> Vald, while I personally completely agree with you that @Deprecated is the
> proper approach (imo), some users do not.  @EndOfLife offers a *possible*
> alternative.  Yes using @EndOfLife does not warn users of using
> deprecated features unless they do something "extra" as I mentioned in my
> original email.
>
> The question is whether @EndOfLife is an appropriate "middle ground"
>
> On Wed, Jun 28, 2017 at 4:56 AM andrea boriero 
> wrote:
>
>> In my opinion deprecating something is useful only when we are able to
>> provide an alternative, not sure about the best approach in case we do not
>> have a current alternative.
>>
>> On 28 June 2017 at 08:55, Vlad Mihalcea  wrote:
>>
>>> I would use the regular Java deprecation mechanism is just make sure
>>> we write the plan in the Javadoc and the User Guide.
>>>
>>> On example is Query#setResultTransformer:
>>>
>>> >
>>> >  * @deprecated (since 5.2)
>>> >  * @todo develop a new approach to result transformers
>>> >  */
>>> > @Deprecated
>>> > Query setResultTransformer(ResultTransformer transformer);
>>>
>>> If we didn't use deprecated here, and chose only @EndOfLife,
>>>
>>> people might complain even more that they didn't ackowledged that this
>>> method is going to be changed in future.
>>>
>>> Vlad
>>>
>>>
>>>
>>> On Tue, Jun 27, 2017 at 5:15 PM, Steve Ebersole 
>>> wrote:
>>>
>>> > Per subject I wanted to come to a consensus as to how exact we want to
>>> be
>>> > in terms of continuing to add deprecations to 5.2 for ongoing 6.0 work.
>>> > Considering that these deprecations are meant to be a guide for users
>>> to
>>> > migrate to 6.0 I think we should try to be as complete as possible in
>>> this
>>> > effort, but wanted to hear other's views.
>>> >
>>> > An alternative is the @EndOfLife annotation I have recently added to
>>> 6.0.
>>> > We could back port this annotation and use that instead; the reason
>>> being
>>> > that people complain when we deprecate something without being able to
>>> > specify its "replacement".  This would be an option to do both.  The
>>> > drawback is that this annotation obviously has no tie-in with javac -
>>> users
>>> > would have to go out of their way to find these.
>>> > ___
>>> > 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] Continue to add 5.2 deprecations for 6.0 work?

[Vlad Mihalcea]

I would use the regular Java deprecation mechanism is just make sure
we write the plan in the Javadoc and the User Guide.

On example is Query#setResultTransformer:

>
>  * @deprecated (since 5.2)
>  * @todo develop a new approach to result transformers
>  */
> @Deprecated
> Query setResultTransformer(ResultTransformer transformer);

If we didn't use deprecated here, and chose only @EndOfLife,

people might complain even more that they didn't ackowledged that this
method is going to be changed in future.

Vlad



On Tue, Jun 27, 2017 at 5:15 PM, Steve Ebersole  wrote:

> Per subject I wanted to come to a consensus as to how exact we want to be
> in terms of continuing to add deprecations to 5.2 for ongoing 6.0 work.
> Considering that these deprecations are meant to be a guide for users to
> migrate to 6.0 I think we should try to be as complete as possible in this
> effort, but wanted to hear other's views.
>
> An alternative is the @EndOfLife annotation I have recently added to 6.0.
> We could back port this annotation and use that instead; the reason being
> that people complain when we deprecate something without being able to
> specify its "replacement".  This would be an option to do both.  The
> drawback is that this annotation obviously has no tie-in with javac - users
> would have to go out of their way to find these.
> ___
> 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] Feature Request: Encrypt sensitive data with an "encrypted store/filter"

[Vlad Mihalcea]

Hi,

The easiest way to do it is to use Transparent Data Encryption in the RDBMS:

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-tde

For simple use cases, you can just use the @ColumnTransformer as explained
in this article:

https://vladmihalcea.com/2017/02/24/how-to-encrypt-and-decrypt-data-with-hibernate/

There used to be the Jasypt project which provided encryption for
Hibernate, but it does not look like it's very active:

http://www.jasypt.org/

Vlad

On Fri, Jun 23, 2017 at 8:25 PM, Sebastian Bicchi <
sebastian.bic...@sec-research.com> wrote:

> Dear all,
>
> this is my first Thread/Request on this mailing list and maybe I'm
> completely wrong here. If so - please excuse that and ignore this message.
>
> Now back to topic: My small "start-up" was confronted with the problem of
> storing sensitive data in the database via hibernate. The data I cared most
> about were credentials to APIs, tokens, private keys for signing, etc., in
> other words: Data that our application needed in plaintext but also might
> help an attacker in case of a breach of the database. Also data that you
> not necessarily would reveal to an DBA, especially if you make use of
> managed databases (how much do you trust your database?).
>
> So we implemented an encrypted key-value store. The encrypted key value
> store encrypts at the moment only the value of the stored key-value pair.
> We're working on encrypting the key (=ID) as well. Because you can't trust
> the file system of the web-app server as well as the database, the secure
> store needs to be initialized with a passphrase or keyfile at the start of
> the (web-)application. After initialization the encrypted kv store resides
> inside of "@Context HttpServletRequest" and is accessible by the Web-App.
> The key for de/encryption only resides inside the memory of the server.
> This is the big win - even if you get a database dump (and there are *a
> lot* of dumps on pastebin or in the darknet) you wont be able to decrypt
> the stored values. Also, if you get access to the file system - you wont be
> able to decipher the values.
>
> The Class of the Encrypted Key Value store only lets you initialize it
> with a passphrase, but never read the passphrase nor the symmetric key.
> Nevertheless there is no perfect security: If an attacker obtains full root
> access to the web application server he will be able to get access to the
> keys by dumping the memory of the JVM. Also if there is an code execution
> weakness you might be able to obtain values - we counter measure that by
> using Java Security Manager. Only signed classes can will get access to the
> Encrypted Key Value Store. Also we set up a restriction on reflections.
>
> Now my request/question: Do you think it would make sense to add an
> annotation "@Encrypted" to encrypt fields at ORM Level? In my opinion this
> would be a great security win for hibernate (even if the JPA doesn't define
> an "Encrypted Entity"). It would be very nice if you just annotate a field
> with "@Encrypted" and let a transparent encryption do the work.
>
> There are several steps to archive this, but I think it is possible:
> * Each entity needs an Initialization Vector
> * It is possible to make use of "format preserving encryption" and
> therefore not breaking the schema with encryption
> * Without format preserving encryption, the encrypted fields will be
> converted to an @Lob or at least some binary type
> * The initialization of the application needs to be done by an user  -
> there is no generic way to archive this without breaking the security
>
> If you think that might be a good thing for hibernate, please advice were
> it should be implemented and I will try to do so.
>
>
> Kind regards
> Sebastian Bicchi
>
> --
> Sec-Research GmbH
> Graf Starhemberggasse 6/4
> 1040 Vienna
> Tel.: +43 (0)660/228 25 77
> https://www.sec-research.com
> FN445069p, Handelsgericht Wien
> --
>
>
> ___
> 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] Migration path from 3.6 to 5.2

[Vlad Mihalcea]

Hi,

You can migrate from 3.6 to 5.2 directly. Just read all the migration
guides from 3.x to 5.2 to know what has changed and what you need to take
into consideration. For example, 5.x uses the enhanced identifier
generators which you might want to disable if you relied on the old
sequence-based optimizer strategies.

Vlad

On Tue, Jun 13, 2017 at 12:40 AM, Prasanth Mathialagan <
prasanthmathiala...@gmail.com> wrote:

> Hi,
>
> We have been using hibernate-orm in our application for a long time. The
> version of hibernate we use is 3.6.10.Final. I know it is archaic. We would
> like to migrate to the latest stable version (5.2) to reap the benefits of
> new optimizations and features. Initially we thought about upgrading to
> 4.x. Since we are also doing Java 8 and Spring 4 upgrades, we have decided
> that it would be better to migrate hibernate to 5.2 together.
>
> I know it is not possible to migrate from 3.6 to 5.2 directly.I have
> checked online for migration guides. But I am bit off about which path
> should I take to migrate (eg. 3.6 to 4.3 to 4.5 to 5.2). Can someone help
> me with figuring out minimum number of migrations from 3.6 to reach 5.2? I
> would be grateful if you could point me to some resources
> ___
> 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 5.0 test failures

[Vlad Mihalcea]

This error:

"unexpected exception opening server socket java.net.BindException: Address
already in use (Bind failed)"

I only got it when NVidia driver was stealing the Wildfly port, but that
was never for CriteriaLockingTest.

It's also curious why the  Byteman agent tries to open a socket connection:

at 
org.jboss.byteman.agent.TransformListener.initialize(TransformListener.java:69)


On Tue, Jun 13, 2017 at 9:45 AM, Gail Badner  wrote:

> I just noticed that there were a couple of failures in the CI tests:
> http://ci.hibernate.org/view/ORM/job/hibernate-orm-5.0-h2/
> lastCompletedBuild/testReport/
>
> Both failures are from timeouts due to:
> java.net.BindException: Address already in use (Bind failed)
>
> It passes locally for me.
>
> This sounds vaguely familiar to me. Did this happen on other branches? If
> so, what was the fix?
>
> Thanks!
>
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-11791

[Vlad Mihalcea]

Hi,

Wouldn't that require all entities be compiled with?

javac -parameters

Vlad

On Mon, Jun 12, 2017 at 10:19 PM, Christian Bongiorno <
christian.bongio...@gmail.com> wrote:

> Now that java 8 supports named parameters it becomes possible (potentially
> preferrable) to use constructor injection instead of circumventing
> encapsulation to set values on private fields.
>
> This shows itself as a potential win when integrating with Kotlin with
> disallows the circumvention quite forcefully. Meaning: without constructor
> injection the object needs setters. And, if it has setters then it's
> mutable which is against best practices.
>
> I propose optionally using constructor injection when marshalling an object
> from data sources in a DB. I am willing to make the changes if I know they
> can/will be incorporated.
>
> Thoughts? Here is the ticket
> https://hibernate.atlassian.net/browse/HHH-11791
> ___
> 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] SqlTypeDescriptor bind by name limitation

[Vlad Mihalcea]

>
> A CallableStatement is also a PreparedStatement so we already know how to
> bind positionally against both PreparedStatement (and CallableStatement,
> since they are PreparedStatement).  And only for CallableStatement does
> JDBC define additional support for binding by name.


I followed the call stack to this, and I think it's fine since the user has
the choice of using positional binding instead of name-based stored
procedure parameter binding:

if ( this.procedureCall.getParameterStrategy() ==
ParameterStrategy.NAMED && canDoNameParameterBinding() ) {
   ((ProcedureParameterNamedBinder) typeToUse).nullSafeSet(
 statement,
 null,
 this.getName(),
 session()
   );
}

Vlad

On Wed, Jun 7, 2017 at 6:39 PM, Steve Ebersole  wrote:

> Ignoring some poor wording in the Javadocs by me :)
>
> On Wed, Jun 7, 2017 at 10:38 AM Steve Ebersole 
> wrote:
>
>> I'm not sure what you mean when you say that SqlTypeDescriptor only
>> supports binding by name.  On both 5.2 and 6.0 I see :
>>
>> /**
>>  * Bind a value to a prepared statement.
>>  *
>>  * @param st The prepared statement to which to bind the value.
>>  * @param value The value to bind.
>>  * @param index The position at which to bind the value within the prepared 
>> statement
>>  * @param options The options.
>>  *
>>  * @throws SQLException Indicates a JDBC error occurred.
>>  */
>> public void bind(PreparedStatement st, X value, int index, WrapperOptions 
>> options) throws SQLException;
>>
>> /**
>>  * Bind a value to a CallableStatement.
>>  *
>>  * @param st The prepared statement to which to bind the value.
>>  * @param value The value to bind.
>>  * @param name The name to bind the value within the prepared statement
>>  * @param options The options.
>>  *
>>  * @throws SQLException Indicates a JDBC error occurred.
>>  */
>> public void bind(CallableStatement st, X value, String name, WrapperOptions 
>> options) throws SQLException;
>>
>>
>>
>> Which is what you'd expect.  I'm not really following what you are
>> saying.  A CallableStatement is also a PreparedStatement so we already know
>> how to bind positionally against both PreparedStatement (and
>> CallableStatement, since they are PreparedStatement).  And only for
>> CallableStatement does JDBC define additional support for binding by name.
>>
>> And 6.0 is going to bind by position, but that's what all other versions
>> of Hibernate have done.  The change in 6.0 you are thinking about is
>> *reading* values back (from ResultSets, CallableStatement params, etc).
>>
>> On Wed, Jun 7, 2017 at 9:13 AM Vlad Mihalcea 
>> wrote:
>>
>>> Hi,
>>>
>>> While writing an example for a custom Hibernate Type which supports
>>> PostgreSQL arrays,
>>> I realized that the SqlTypeDescriptor only supports bind by name:
>>>
>>> @Override
>>> protected void doBind(CallableStatement st, X value, String name,
>>> WrapperOptions options)
>>> throws SQLException {
>>> }
>>>
>>> However, for the java.sql.Array, we only have a bind by index method in
>>> java.sql.Statement:
>>>
>>> void setArray (int parameterIndex, Array x) throws SQLException;
>>>
>>> I remember that 6.0 is going to bind by index, so maybe this issue is
>>> already taken care of in the new version.
>>> Should we provide some fix for 5.x as well?
>>>
>>> Vlad
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Pull request

[Vlad Mihalcea]

There are 100, but that's because some of them are for 4.x or 5.0, 5.1 or
they lack Tets Cases or the user hasn't confirmed the CLA.
We integrate most Pull Requests in a timely fashion.

Vlad

On Wed, Jun 7, 2017 at 6:08 PM, Sanne Grinovero  wrote:

> On 7 June 2017 at 15:46, Vlad Mihalcea  wrote:
> > Hi Sanne,
> >
> > The PR queue has not been neglected at all. The problem was that the
> issue
> > was still marked with the "Requires Changes" label, and I assumed it was
> not
> > done yet.
>
> Great to hear. Sorry, I just assumed it was the case as you've all
> been very busy and there are 100+ of them..
>
> Thanks,
> Sanne
>
> >
> > Vlad
> >
> > On Wed, Jun 7, 2017 at 12:41 PM, Sanne Grinovero 
> > wrote:
> >>
> >> Hi Milo,
> >>
> >> apologies for that. The ORM team had some meetings, travelling, etc..
> >> I guess the PR queue has been temporarily neglected and they'll have
> >> to catch up.
> >>
> >> I don't think you missed something, good idea to call for attention on
> >> the mailing list.
> >>
> >> Thanks,
> >> Sanne
> >>
> >>
> >> On 6 June 2017 at 20:36, Milo van der Zee  wrote:
> >> > Hello,
> >> >
> >> > I submitted a pull request and fixed some issues with it (jUnit test
> and
> >> > formatting) and after that nothing happens. How does this work? Do I
> >> > just have to be patient or do I miss something?
> >> >
> >> > https://github.com/hibernate/hibernate-orm/pull/1906
> >> >
> >> > MAG,
> >> > Milo
> >> >
> >> > ___
> >> > 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