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

[Chris Cranford]

See below.

On 1/3/19 10:29 AM, Steve Ebersole wrote:
> [o.h.d.Dialect] (main) HHH000400: Using dialect:
>> org.hibernate.dialect.PostgreSQL95Dialect
>>
>> -> wondering if it has any value to log the dialect? I mean if you don't
>> use the right one, you will definitely have some issues.
>>
> True, but it is probably hard(er) to interpret the true source of the
> issues later on.
>
> However, I think it is reasonable to make this DEBUG.  If you have problems
> the first reasonable thing to do is to crank logging to DEBUG if not TRACE.

I completely agree.

I think its reasonable to make it DEBUG/TRACE but I don't think I want
to necessarily change it such that it is no longer included in log
output at all.  Having it be included is a good first-line of defense on
trying to resolve potential problems not only for us, but even for users
who are doing their own debugging before reporting an issue;
particularly if the error in question implies some Dialect configuration
problem.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] inSession / inTransaction

[Chris Cranford]

I have no objections to exposing them directly rather than being part of
the test infrastructure.

On 12/20/18 5:16 PM, Steve Ebersole wrote:
> On Thu, Dec 20, 2018 at 1:33 PM Gunnar Morling  wrote:
>
>> Hey,
>>
>> When discussing this before, there were some doubts about its actual
>> usefulness in non-testing, real-world code. E.g. you'd typically
>> interact with multiple DAOs/repositories etc. and would have to
>> somehow pass the session to each of them.
>>
> I've written many non-trivial apps in my past that did not use
> "DAO/repositories" etc.  Not sure why we'd choose to not implement
> something that is useful just because not everyone would use it.  To me, if
> something is repeatedly useful in writing tests... it tends to be
> more-or-less generally useful.
>
>
> One other thought is that inTransaction() should allow to return a result
>> value.
>>
> An over-loaded form perhaps, yes I can see that - but non-returning is
> valid as well.  So maybe:
>
> public interface SessionFactory ... {
> ...
> void inSession(Consumer action);
> void inTransaction(Consumer action);
> void inTransaction(Session session, Consumer action);
>
>  T inSession(Function action);
>  T inTransaction(Function action);
>  T inTransaction(Session session, Function action);
> }
>
> and
>
> public interface Session ... {
> void inTransaction(Consumer action);
>
>  T inTransaction(Function action);
> }
> ___
> 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] Wrapping up 5.4.0

[Chris Cranford]

Guillaume

On the topic of PR #2611, I pushed a commit to fix the test failure a
day or two ago
that you pointed out.  At this point, the PR is ready for integration
unless anyone
else wants to review and provide any further input/critique. 

What remains for 5.4 which Andrea and I are working on is to align a few
contracts
with their 6.0 counterparts.  There are somethings we recently changed
in 6.0
that we should prefer to backport for compatibility reasons moving
forward.  This
should be work we can finish before Wednesday.

Chris

> On Mon, Nov 5, 2018 at 12:07 PM Guillaume Smet 
> wrote:
>
>> Hi,
>>
>> If everybody is OK with it, I would like to wrap 5.4.0.CR1 on Wednesday
>> 14th (this is next Wednesday).
>>
>> That means that everything we want in 5.4.0 should be in by then.
>>
>> The big remaining subject IMHO is this one:
>> https://github.com/hibernate/hibernate-orm/pull/2611 . I think we really
>> need that in.
>>
>> Chris, Gail, do you think you can drive this puppy home before then?
>>
>> If you have issues affected to you that you know won't be fixed before next
>> Wednesday, can you please move them to 5.4.1 so that we have a clear vision
>> of the remaining work?
>>
>> Steve, could you please prepare a paragraph about the entity graph work for
>> the announcement? As it's the big new feature of this release, some code
>> showing the improvements made would be welcome, I think.
>>
>> 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] Getting automatically removed from the list for "excessive bounces"?

[Chris Cranford]

I'm also noticing as of today that parts of entire conversations are not
being delivered, but yet my account not suspended.  I'm seeing 5-6
messages sent since Friday, November 2nd never made it into gmail.  As
of now, the only option I have is to review the archives daily to see
what I may I have missed, which is quite frustrating.

Chris

On 10/24/18 9:26 AM, Alessio Stalla wrote:
> Hi,
> I've got the excessive bounces message several times, too, and I'm using
> Gmail.
>
> Alessio
>
> On Wed, 24 Oct 2018 at 15:24, Sanne Grinovero  wrote:
>
>> Hi Jordan,
>>
>> I have an error message from our mail server stating that messages to
>> you (and 8 more people, among them we also have regulars like Vlad and
>> Christian Beikov) have been bouncing back often in the past 2 days. It
>> eventually gave up so you might miss some emails from this list.
>>
>> I'm not sure why; but it's interesting to note that all 9 people on
>> this error message are using gmail. I'll open a support ticket for
>> those managing the mail server but I'm not sure if they will be able
>> to to anything, as it seems it's gmail refusing them.
>>
>> Thanks,
>> Sanne
>> On Wed, 24 Oct 2018 at 11:42, Jordan Gigov  wrote:
>>> I've started getting these every month from this list:
 Your membership in the mailing list hibernate-dev has been disabled
 due to excessive bounces The last bounce received from you was dated
 24-Oct-2018.  You will not get any more messages from this list until
 you re-enable your membership.  You will receive 3 more reminders like
 this before your membership in the list is deleted.
>>> Otherwise messages from the list come in normally in my inbox and not
>>> marked as spam.
>>>
>>> Does this only affect me, all GMail subscribers, or an even wider
>> audience?
>>> ___
>>> 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] JIRA self-registration of users

[Chris Cranford]

Sanne -

Same here, I haven't changed anything.

Chris

On 11/2/18 7:14 AM, Yoann Rodiere wrote:
> I didn't change the settings recently.
>
> On Fri, 2 Nov 2018 at 12:03, Sanne Grinovero  wrote:
>
>> Hi all,
>>
>> I'm receiving requests to approve people who are creating accounts on JIRA.
>>
>> While it's good to see lots of people interested in registering, I've
>> never had to approve these before.
>>
>> Did someone change settings or should I report this to Atlassian?
>>
>> Thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] Jira - edit comments

[Chris Cranford]

Steve -

I have the option for my user.  Is the ellipsis button not showing up
for you on the comment?

On 10/17/18 9:12 AM, Steve Ebersole wrote:
> Did someone remove the ability to edit one's comments?  I added a comment I
> would like to adjust syntax (code fragment), but Jira will not let me
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] How to enable Javassist when running a WildFly unit test?

[Chris Cranford]

Technically the -D parameter should work; however I know a
hibernate.properties file works.

On 08/24/2018 11:54 PM, Gail Badner wrote:
> I tried running:
>
> mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
> -Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
>
> The result is a permissions failure, and ByteBuddy is in the stacktrace.
>
> I also tried adding the property to the StandardServiceRegistryBuilder
> built by SFSBHibernateSFNaturalId, and that didn't work either.
>
> Is there some other way to enable javassist?
>
> 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] ORM progress: tricky branch state

[Chris Cranford]

+1 from me as well.

On 07/02/2018 05:43 PM, andrea boriero wrote:
> +1 for 5.3 branch
>
> On Mon, 2 Jul 2018, 19:05 Gail Badner,  wrote:
>
>> +1 on creating a 5.3 branch, with master being used for 5.4 (or 6.0).
>>
>> On Mon, Jul 2, 2018 at 9:43 AM, Sanne Grinovero 
>> wrote:
>>
>>> On Mon, 2 Jul 2018 at 17:34, Steve Ebersole  wrote:
 I don't mind creating a 5.3 branch, and having master for "after 5.3"
>>> development with 6.0 hopefully merged in there soon.
>>>
>>> +1 that sounds like the best option we have. It's not extremely
>>> urgent, we can do this after 5.3.2 ?
>>>
>>> Just making sure we tighten up the process a bit when we start merging
>>> all "compatibility fixes" in WildFly 14, yet not too soon to not waste
>>> too much time backporting everything.
>>>
>>> Thanks!
>>> Sanne
>>>
 On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole 
>>> wrote:
> I think I have pointed out before that such a schedule is already
>>> posted : https://github.com/sebersole/hibernate-core/blob/wip/6.0/
>>> design/6.0-todo.adoc#alpha1
> The important part remaining is really collection support.
>
> There are a few listed there that we'd be willing to push to the next
>>> Alpha
> On Mon, Jul 2, 2018 at 10:42 AM 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
>>
> ___
> 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?

[Chris Cranford]

I'm fine postponing the release for another week or 2 if that helps,
Christian. 

On 06/06/2018 08:26 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.
>

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

Re: [hibernate-dev] Health check status API

[Chris Cranford]

See inline

On 06/01/2018 03:00 AM, Yoann Rodiere wrote:
>> We could do it via the Statistics mechanism which can be made available
> via
> JMX.
>
> >From what I understand it would be an explicit call from the user
> (OpenShift in this case) that would trigger an active check, like a request
> to the database. Not sure the statistics are the best place to put such a
> thing.
I don't believe so either, although data from the Statistics may be what
we do expose.

Perhaps a service placed into the StandardServiceRegistry that operates
as a
SessionFactoryObserver would work in this case allowing us to support
the use case
where an application spins up multiple SessionFactory configurations.

> Or is it about us doing periodic checks on our own, and displaying the
> results somewhere for anyone to see if something is wrong? That sounds
> unnecessarily complex.

We either do it periodically or we do it at the time the health check
endpoint is called?
> Sure. I wonder about the granularity though: if we have multiple
> connections (multiple Elasticsearch cluster, a Lucene cluster with JGroups
> or JMS, ...), what would these OpenShift people want us to expose? One big
> "everything is fine/something is wrong" status, potentially returning a
> specific error message to tell what part is wrong exactly? Or finer-grained
> statuses, like "backend X: OK, backend Y: OK, Backend Z/JGroups: OK, ..."?
I haven't looked at OpenShift specifically as-of-yet but I would guess
it is something
akin to my experience with Eureka where the caller is effectively
checking 2 things

1. Can I reach the endpoint (if not, its definitely OFFLINE)
2. The value of the "status" named value in the root of the JSON response.

So I would expect we'd had some type of structure similar to this JSON
response

{
  "status": "UP"
  "backend_X": {
    "status": "UP",
    ...
  },
  "backend_Y": {
    "status": "UP",
    ...
  }
}

> Also, I suppose we would expose our own APIs/SPIs, right? Not implement
> some OpenShift-specific SPIs? I'd rather avoid that...
+1
> On Fri, 1 Jun 2018 at 01:36 Vlad Mihalcea  wrote:
>
>> 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Chris Cranford]

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 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 5.3.1.Final has been released

[Chris Cranford]

For details:
http://in.relation.to/2018/05/28/hibernate-orm-531-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Starting 5.3.1 release

[Chris Cranford]

Please do not push anything to master branch.
Thanks,
Chris
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 Design Doc

[Chris Cranford]

In case anyone tries to locate this file more recently, its now under:
https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/design/sql-engine.adoc

On 05/23/2018 01:55 PM, Steve Ebersole wrote:
> Andrea and I have spent some time getting the SQL execution design doc
> up-to-date.  Would be nice to get any feedback.  Thanks :)
>
> https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/sql-engine-design.adoc
> ___
> 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] Preparing the 5.3.1 release

[Chris Cranford]

I already mentioned to Sanne I'd handle it. 

I might run into some publishing issues and might need to recruit some
help as needed since it'll be my first attempt, but we'll see.

Chris

On 05/23/2018 06:25 PM, Sanne Grinovero wrote:
> we'll draft a "volunteer" :)
>
> Thanks!
>
> On 23 May 2018 at 23:20, Steve Ebersole  wrote:
>> If someone can do the release, +1 from me
>>
>> On Wed, May 23, 2018 at 5:11 PM Sanne Grinovero  wrote:
>>> Hi Steve,
>>>
>>> are we free to release a 5.3.1 this weekend?
>>>
>>> As I mentioned in the parallel thread "WildFly 14 requirements for
>>> Hibernate libraries", we can still get some fixes for WildFly 13 but
>>> the deadline is this weekend.
>>>
>>> I think you and Andrea can keep the focus on the ORM6 meeting;
>>> everyone else chipped in some fixes already.
>>>
>>> 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] Simplify SQL function registration when bootstrapping via JPA

[Chris Cranford]

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

Re: [hibernate-dev] Analyzing the ORM testsuite

[Chris Cranford]

The entire build process under OpenJDK 8 here:

BUILD SUCCESSFUL in 47m 26s
251 actionable tasks: 233 executed, 18 up-to-date

The only thing I noticed was that while executing the hibernate-core
tests, the memory consumption seemed quite high toward the end of the
test suite, particularly ~3.5GB memory consumed just to run the
hibernate-core tests alone and that FindBugs complained about some magic
numbers on some zip files while inspecting hibernate-osgi. 

Any idea if any substantial amount of that memory consumption related to
the test framework tracking the output/errors of those executed tests? 

On 04/19/2018 05:20 PM, Sanne Grinovero wrote:
> On 19 April 2018 at 21:47, Chris Cranford <ch...@hibernate.org> wrote:
>> Sanne -
>>
>> Are you running the build task or are you executing other more specific
>> tasks and noticing the slowness?
> Just running "gradle clean build" from the root. I had the same
> results with OpenJDK 8 and 9, twice. Getting exactly the same failures
> as before.
>
> Thanks!
>
>> On 04/19/2018 04:25 PM, Steve Ebersole wrote:
>>
>> Nothing off the top of my head.  The build time is in normal range on my
>> machine as of this morning (8 - 10 minutes).
>>
>> You mentioned a specific commit.  Is that just when you noticed a change,
>> or do you suspect something in that commit?
>>
>> I'm not at computer right now, but when I get back I will check out that
>> commit and see if anything is strange locally.
>>
>>
>>
>> On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero <sa...@hibernate.org> wrote:
>>
>> Hi all,
>>
>> I'm trying to analyze the memory usage of current master of Hibernate
>> ORM; I started looking because of OOM errors on the PostgreSQL
>> testsuite (as mentioned in another thread).
>>
>> So far I've seen that Mockito is allocating a "lot of stuff"; I might
>> be able to improve some things in that area but it's a distraction
>> from my goal as clearly we use Mockito even when not running the
>> PostgreSQL backed tests and that seems to run fine. But it's polluting
>> the data reports so making it hard (and slow!) to verify if there is a
>> real issue.
>>
>> I could use some help to verify some tangential issues though; when
>> running the testsuite locally it's taking much longer than what I've
>> been used to see for the same testsuite some weeks ago, and I have
>> some failures - regularly seeing the same failures.
>>
>> These are triggered by running a default build, on H2:
>>
>> Task :hibernate-core:test
>>
>> org.hibernate.test.criteria.CriteriaLockingTest >
>>
>> testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue
>> FAILED
>> org.junit.runners.model.TestTimedOutException
>>
>> org.hibernate.test.criteria.CriteriaLockingTest >
>>
>> testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue
>> FAILED
>> java.lang.Exception
>>
>> org.hibernate.test.criteria.CriteriaLockingTest >
>> org.hibernate.test.criteria.CriteriaLockingTest FAILED
>> java.lang.Exception
>>
>> org.hibernate.test.locking.warning.LockNoneWarmingTest >
>> org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED
>> java.lang.Exception
>>
>> 6307 tests completed, 4 failed, 327 skipped
>>
>> Yet the puzzling point: on ci.hibernate.org I don't see these failures
>> happening, nor the testsuite time seems to have increased of any
>> significant amount (it regularly completes in somewhere between 15 and
>> 20 minutes). It takes me more than an hour to get this result on a
>> machine which would normally complete the testsuite in 8 minutes, and
>> I got the same 4 failures when re-running it a second time.
>>
>> Could other developers also please checkout master - specifically at
>> commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if
>> it works allright for you and if the build time is consistent with the
>> usual times for your machine? I need to understand what might be
>> different between my workstation and the CI server.
>>
>> I might even have some great improvements ready to reduce the
>> testsuite time, but I'm not comfortable in committing them in this
>> context.
>>
>> Thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] Analyzing the ORM testsuite

[Chris Cranford]

Sanne -

Are you running the build task or are you executing other more specific
tasks and noticing the slowness?

On 04/19/2018 04:25 PM, Steve Ebersole wrote:
> Nothing off the top of my head.  The build time is in normal range on my
> machine as of this morning (8 - 10 minutes).
>
> You mentioned a specific commit.  Is that just when you noticed a change,
> or do you suspect something in that commit?
>
> I'm not at computer right now, but when I get back I will check out that
> commit and see if anything is strange locally.
>
>
>
> On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero  wrote:
>
>> Hi all,
>>
>> I'm trying to analyze the memory usage of current master of Hibernate
>> ORM; I started looking because of OOM errors on the PostgreSQL
>> testsuite (as mentioned in another thread).
>>
>> So far I've seen that Mockito is allocating a "lot of stuff"; I might
>> be able to improve some things in that area but it's a distraction
>> from my goal as clearly we use Mockito even when not running the
>> PostgreSQL backed tests and that seems to run fine. But it's polluting
>> the data reports so making it hard (and slow!) to verify if there is a
>> real issue.
>>
>> I could use some help to verify some tangential issues though; when
>> running the testsuite locally it's taking much longer than what I've
>> been used to see for the same testsuite some weeks ago, and I have
>> some failures - regularly seeing the same failures.
>>
>> These are triggered by running a default build, on H2:
>>
>>> Task :hibernate-core:test
>> org.hibernate.test.criteria.CriteriaLockingTest >
>>
>> testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue
>> FAILED
>> org.junit.runners.model.TestTimedOutException
>>
>> org.hibernate.test.criteria.CriteriaLockingTest >
>>
>> testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue
>> FAILED
>> java.lang.Exception
>>
>> org.hibernate.test.criteria.CriteriaLockingTest >
>> org.hibernate.test.criteria.CriteriaLockingTest FAILED
>> java.lang.Exception
>>
>> org.hibernate.test.locking.warning.LockNoneWarmingTest >
>> org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED
>> java.lang.Exception
>>
>> 6307 tests completed, 4 failed, 327 skipped
>>
>> Yet the puzzling point: on ci.hibernate.org I don't see these failures
>> happening, nor the testsuite time seems to have increased of any
>> significant amount (it regularly completes in somewhere between 15 and
>> 20 minutes). It takes me more than an hour to get this result on a
>> machine which would normally complete the testsuite in 8 minutes, and
>> I got the same 4 failures when re-running it a second time.
>>
>> Could other developers also please checkout master - specifically at
>> commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if
>> it works allright for you and if the build time is consistent with the
>> usual times for your machine? I need to understand what might be
>> different between my workstation and the CI server.
>>
>> I might even have some great improvements ready to reduce the
>> testsuite time, but I'm not comfortable in committing them in this
>> context.
>>
>> Thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] Defaultable service strategies

[Chris Cranford]

+1

Makes sense to me.

On 03/21/2018 02:42 PM, 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] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method

[Chris Cranford]

Sanne -

On 03/07/2018 07:58 PM, Sanne Grinovero wrote:
>  # Fix some pending problem with Envers: it's no longer compiling as a
> non-abstract extension of Session doesn't implement getFlushMode;
> might be tricky or not, I've not looked yet.
I assume this is due to
o.h.envers.internal.entities.mapper.relation.lazy.ToOneDelegateSessionImplementor
?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?

[Chris Cranford]

On 03/05/2018 08:26 AM, Sanne Grinovero wrote:
> On 5 March 2018 at 12:27, Guillaume Smet 
> wrote:
>> Hi, So far we had 4 duplicate reports of
>> https://hibernate.atlassian.net/browse/HHH-12332 (so not counting the
>> users having seen the bug and not opening a new one). I think this
>> issue qualifies as "we should really get a hotfix release soon".
> +1 that would be nice, and the most effective way to prevent further
> noise and pain.
I also would agree.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Removing dom4j?

[Chris Cranford]

Another alternative (at least for Envers) might be to incorporate the
JAXB work I did into 5.3 rather than wait for 6.0.

Steve/Andrea, either of you have a preference one way or another?

On 02/21/2018 10:52 AM, Chris Cranford wrote:
> See inline
>
> On 02/20/2018 10:52 AM, Jordan Gigov wrote:
>> Well, it took longer than expected as the source of the failures
>> became more obscure, but here it is, done on the master (5.3) branch.
>>
>> https://github.com/coladict/hibernate-orm/tree/dom4j-removal
>> It's in the dom4j-removal branch.
>>
>> The tests for entity-mode dom4j have been removed, but it might be a
>> better idea to write new ones that expect an error.
>> Also the hibernate-mapping-4.0.xsd schema hasn't been valid since
>> dom4j entity-mode was removed in 2011
>> (4a4f636caf9ecc62fe0d230f422ad3eab2517db0) but I haven't touched it.
>>
>> You could wait for 6.0, but there is time to review this for 5.3.
>>
> The biggest difference between what you did and my own for Envers is
> that I decided to use the JAXB binding classes directly rather than
> replace dom4j with another XML abstraction.  Using JAXB binding
> classes directly gives several noticeable benefits:
>
>  * Better maintainability - cleaner and easier to read code
>  * Better performance - less in-memory string manipulation and cloning
>  * Most important - compile-time schema compliance.
>
> The replacement of dom4j with the w3c equivalents is likely fine for
> 5.3; however, the long-term goal is to do away with the XML
> manipulation all together in Envers.
>
>> I have only passed a `clean build` using JDK8 and the default H2
>> database. Maybe other databases could expose errors, but it's highly
>> unlikely.
>> JDK9 is a bit more likely to expose an incompatibility.
>>
>> On 19 February 2018 at 17:03, Chris Cranford <ch...@hibernate.org
>> <mailto:ch...@hibernate.org>> wrote:
>>
>> See below
>>
>> On 02/18/2018 11:38 AM, Steve Ebersole wrote:
>> > On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov
>> <colad...@gmail.com <mailto:colad...@gmail.com>> wrote:
>> >
>> >> I think transitioning to automatic bindings via JAXB will
>> result in error
>> >> messages on wrong configurations becoming far too vague to be
>> useful to the
>> >> users.
>> >>
>> > I'm not understanding... we've used jaxb since 4.0
>> >
>> > I am just talking about envers and how it integrates with
>> hibernate-core.
>> > At the moment it directly uses dom4j - we'd like to eventualy
>> have it use
>> > the jaxb model instead
>>
>> There is a JIRA [1] that specifically targets this work from an
>> Envers
>> perspective. 
>>
>> I have a working implementation based on Hibernate 5.x but this is
>> planned to be integrated in Hibernate 6.  I'd expect to see this get
>> integrated once we get a bit more development finalized around
>> Hibernate
>> Core in 6.
>>
>> [1]: https://hibernate.atlassian.net/browse/HHH-11483
>> <https://hibernate.atlassian.net/browse/HHH-11483>
>>
>> Thanks,
>> Chris
>>
>>
>

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

Re: [hibernate-dev] Removing dom4j?

[Chris Cranford]

See inline

On 02/20/2018 10:52 AM, Jordan Gigov wrote:
> Well, it took longer than expected as the source of the failures
> became more obscure, but here it is, done on the master (5.3) branch.
>
> https://github.com/coladict/hibernate-orm/tree/dom4j-removal
> It's in the dom4j-removal branch.
>
> The tests for entity-mode dom4j have been removed, but it might be a
> better idea to write new ones that expect an error.
> Also the hibernate-mapping-4.0.xsd schema hasn't been valid since
> dom4j entity-mode was removed in 2011
> (4a4f636caf9ecc62fe0d230f422ad3eab2517db0) but I haven't touched it.
>
> You could wait for 6.0, but there is time to review this for 5.3.
>
The biggest difference between what you did and my own for Envers is
that I decided to use the JAXB binding classes directly rather than
replace dom4j with another XML abstraction.  Using JAXB binding classes
directly gives several noticeable benefits:

 * Better maintainability - cleaner and easier to read code
 * Better performance - less in-memory string manipulation and cloning
 * Most important - compile-time schema compliance.

The replacement of dom4j with the w3c equivalents is likely fine for
5.3; however, the long-term goal is to do away with the XML manipulation
all together in Envers.

> I have only passed a `clean build` using JDK8 and the default H2
> database. Maybe other databases could expose errors, but it's highly
> unlikely.
> JDK9 is a bit more likely to expose an incompatibility.
>
> On 19 February 2018 at 17:03, Chris Cranford <ch...@hibernate.org
> <mailto:ch...@hibernate.org>> wrote:
>
> See below
>
> On 02/18/2018 11:38 AM, Steve Ebersole wrote:
> > On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov <colad...@gmail.com
> <mailto:colad...@gmail.com>> wrote:
> >
> >> I think transitioning to automatic bindings via JAXB will
> result in error
> >> messages on wrong configurations becoming far too vague to be
> useful to the
> >> users.
> >>
> > I'm not understanding... we've used jaxb since 4.0
> >
> > I am just talking about envers and how it integrates with
> hibernate-core.
> > At the moment it directly uses dom4j - we'd like to eventualy
> have it use
> > the jaxb model instead
>
> There is a JIRA [1] that specifically targets this work from an Envers
> perspective. 
>
> I have a working implementation based on Hibernate 5.x but this is
> planned to be integrated in Hibernate 6.  I'd expect to see this get
> integrated once we get a bit more development finalized around
> Hibernate
> Core in 6.
>
> [1]: https://hibernate.atlassian.net/browse/HHH-11483
> <https://hibernate.atlassian.net/browse/HHH-11483>
>
> Thanks,
> Chris
>
>

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

Re: [hibernate-dev] Removing dom4j?

[Chris Cranford]

See below

On 02/18/2018 11:38 AM, Steve Ebersole wrote:
> On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov  wrote:
>
>> I think transitioning to automatic bindings via JAXB will result in error
>> messages on wrong configurations becoming far too vague to be useful to the
>> users.
>>
> I'm not understanding... we've used jaxb since 4.0
>
> I am just talking about envers and how it integrates with hibernate-core.
> At the moment it directly uses dom4j - we'd like to eventualy have it use
> the jaxb model instead

There is a JIRA [1] that specifically targets this work from an Envers
perspective. 

I have a working implementation based on Hibernate 5.x but this is
planned to be integrated in Hibernate 6.  I'd expect to see this get
integrated once we get a bit more development finalized around Hibernate
Core in 6.

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

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

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

[Chris Cranford]

Gunnar -

I don't particularly see a reason why we cannot as it seems we're
handling the CALLBACK mode with no BV provider present earlier in the
code path.  I'm fine changing it.

Chris


On 02/04/2018 07:21 AM, Gunnar Morling wrote:
> Hi,
>
> If the JPA validation mode is set to CALLBACK, BV constraints such as
> @NotNull, @Size etc. are not reflected in the DDL created by ORM.
>
> Instead, in TypeSafeActivator, the BV constraints are only considered for
> DDL if the validation mode is DDL or AUTO [1].
>
> CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
> silently ignoring it if no BV provider is present), so it's the setting I
> usually recommend. I think constraints should also be propagated to DDL in
> this mode, so I'm wondering whether there a specific reason for the current
> behaviour or wether we can change it?
>
> Thanks,
>
> --Gunnar
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146
> ___
> 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

[Chris Cranford]

I have no strong preference either way.

On 01/30/2018 05:00 PM, Steve Ebersole wrote:
> Wanted to remind everyone that tomorrow is the next time-boxed release for
> 5.3.
>
> I wanted to get everyone's opinions about the version number, whether this
> should be Beta2 or CR1.  IMO It depends how you view the remaining
> challenges with the JPA TCK, with CR1 being the optimistic view.
> ___
> 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-12172 - Bintray v. OSSRH

[Chris Cranford]

Fine with me.

On 01/24/2018 11:23 AM, Guillaume Smet wrote:
> Sure you can get rid of it.
>
> The only versions of OGM there is a very old one people shouldn't use.
>
> Thanks!
>
> On Wed, Jan 24, 2018 at 4:58 PM, andrea boriero 
> wrote:
>
>> no objection
>>
>> On 24 January 2018 at 15:51, Steve Ebersole  wrote:
>>
>>> Do y'all mind then if I get rid of the hibernate/bundles[1] repo?  It's a
>>> "generic" Artifactory repo meant to hold release bundles.  ORM[2] and
>>> OGM[3] both have played with it, as we both have versions published there.
>>> But for ORM at least those are also on SourceForge and its not important
>>> that I keep this around.
>>>
>>> [1] https://bintray.com/hibernate/bundles
>>> [2] https://bintray.com/hibernate/bundles/hibernate-orm
>>> [3] https://bintray.com/hibernate/bundles/hibernate-ogm
>>>
>>>
>>> On Fri, Jan 19, 2018 at 10:38 AM Guillaume Smet >> wrote:
>>>
 On Fri, Jan 19, 2018 at 5:33 PM, Steve Ebersole 
 wrote:

> yessir
>
 Nice, thanks for confirming.


>>> ___
>>> 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] About the WildFly bootstrap errors in Hibernate ORM / master

[Chris Cranford]

Thanks Sanne.

On 01/24/2018 10:01 AM, Sanne Grinovero wrote:
> This is fixed now: HHH-12250
>
> You should all be free to remove JBoss Nexus from your settings.xml
> again, if you prefer.
>
> Thanks
>
>
> On 24 January 2018 at 13:33, Sanne Grinovero  wrote:
>> That's right :(
>>
>> Including it in the build script gets our provioning plugin to know how to
>> resolve things, and all works fine in the phase of creating the server copy.
>>
>> But next the produced Wildfly server starts in a new JVM, entirely new
>> context, and expects to find the dependencies "as configured" for Maven, for
>> the current user. If the current user's configuration doesn't list the JBoss
>> nexus it will ignore the locally cached artifacts, even if we made sure to
>> download them during provisioning.
>>
>> I'm looking for settings we might use today, if I fail I'll revert it.
>>
>> On 24 Jan 2018 13:17, "Steve Ebersole"  wrote:
>>
>> I'm confused.  You're saying it's not enough to include it in the Gradle
>> script?
>>
>>
>> On Wed, Jan 24, 2018, 5:05 AM Sanne Grinovero  wrote:
>>> Hi all,
>>> especially Chris, and anyone else having problems with the integration
>>> tests using WildFly,
>>>
>>> the problem seems to be caused by not having the JBoss Nexus
>>> repository enabled in your *Maven* configuration. (Yes, even though we
>>> use Gradle..)
>>>
>>> For the time being could you create a ~/.m2/settings.xml
>>>
>>> having the content you can copy from:
>>>  -
>>> https://raw.githubusercontent.com/hibernate/hibernate-search/8f7e87bf282877a7a5554035abb709cc9813fec2/settings-example.xml
>>>
>>> This is just a temporary solution so that you're not stuck today,
>>> while I'm looking for a better fix.
>>>
>>> For details, see:
>>>  - http://lists.jboss.org/pipermail/wildfly-dev/2018-January/006335.html
>>>
>>> Thanks, and sorry for the inconvenience!
>>>
>>> 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] Realising the JavaDoc jars as well

[Chris Cranford]

I agree with Andrea.

On 12/29/2017 09:14 AM, andrea boriero wrote:
> +1 for filtering out internal packages.
>
> not a strong opinion on grouping
>
> On 24 December 2017 at 14:23, Steve Ebersole  wrote:
>
>> Sure, but the question remains :P  It just adds another one:
>>
>>
>>1. Should internal packages be generated into the javadocs (individual
>>and/or aggregated)?
>>2. Should the individual javadocs (only intended for publishing to
>>Central) group the packages into api/spi(/internal) the way we do for
>> the
>>aggregated javadocs?
>>
>> Personally I think filtering out internal packages is a great idea.
>>
>> Regarding grouping packages, I think its not worth the effort for the
>> individual ones - just have an overview for these that just notes this
>> distinction.
>>
>> On Sat, Dec 23, 2017 at 6:53 AM Sanne Grinovero 
>> wrote:
>>
>>> On 22 December 2017 at 18:16, Steve Ebersole 
>> wrote:
 I wanted to get everyone's opinion about the api/spi/internal package
 grouping we do in the aggregated Javadoc in regards to the per-module
 javadocs.  Adding this logic adds significant overhead to the process
>> of
 building the Javadoc, to the point where I am considering not
>> performing
 that grouping there.

 Thoughts?
>>> For Hibernate Search we recently decided to not produce javadocs at
>>> all for "internal"; everything else is just documented as a single
>>> group.
>>>
>>> That cuts on the "need to know" complexity of end users. Advanced
>>> users who could have benefitted from knowing more about the internals
>>> will likely have sources.
>>>
 On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea <
>> mihalcea.v...@gmail.com>
 wrote:
> 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 <
>> mihalcea.v...@gmail.com>
>> 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 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] JPA Compliance

[Chris Cranford]

That seems fine to me.

On 11/27/2017 04: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.3 it's still fine to rely on isJpaBootstrap may be
 documenting that a SF obtained  from unwrapping an EMF will conform to the
 JPA spec in term of exceptions.

 On 16 November 2017 at 21:09, Vlad Mihalcea 
 wrote:

> 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 

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

[Chris Cranford]

Sounds reasonable to me.

On 11/25/2017 12:45 PM, Steve Ebersole wrote:
> I just updated the text for the Jira[1].
>
> Specifically, in the section on SEQUENCE and TABLE, at the moment I have
> kept the legacy behavior of using "hibernate_sequence" as the name of the
> table/sequence - users must opt-in to the behavior of using
> `@GeneratedValue#generator` as the sequence/table name.  I'm thinking I'd
> like to change this though - instead having the default behavior be using
> `@GeneratedValue#generator` as the sequence/table name, and migrators
> opting-out for the old behavior.  I think that is more consistent with how
> I generally view these kind of migration settings.
>
> Any objections to making that switch?
>
> [1] https://hibernate.atlassian.net/browse/HHH-12125
>
>
> On Sat, Nov 25, 2017 at 10:59 AM Vlad Mihalcea 
> wrote:
>
>> 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

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

Re: [hibernate-dev] New layout for in.relation.to

[Chris Cranford]

Was curious if we would carry the new style to in.relation.to. 
It looks superb.

Chris

On 09/29/2017 01:57 PM, Guillaume Smet wrote:
> Hi!
>
> I converted in.relation.to to the new layout and pushed it to
> http://staging.in.relation.to/ .
>
> Please take a look at it so that we can make progress quickly.
>
> Note that I still have some work to do on the mobile side. Will do once the
> dust has settled and we agree on the layout.
>
> The home page:
> http://staging.in.relation.to/
>
> The blog post page: the idea here is to just present the content in a very
> minimal way:
> http://staging.in.relation.to/2017/09/25/hibernate-community-newsletter-2017-18/
>
> While it's not validated, please be careful when cherry-picking your new
> blog post to production, don't merge my commits by mistake!
>
> Note that it doesn't change anything to the blog posts so business can
> continue as usual and you can safely cherry-pick your blog post from
> staging to production.
>
> Looking forward to your feedback.
>

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

Re: [hibernate-dev] New layout for the website

[Chris Cranford]

Guillaume -

If we must keep a background color, I think the new color you've changed
on staging
feels like it flows much more than the gold and is far more appealing to
the eye, imo.

Chris

On 09/28/2017 09:32 AM, Guillaume Smet wrote:
> On Thu, Sep 28, 2017 at 3:23 PM, Guillaume Smet 
> wrote:
>
>> On Thu, Sep 28, 2017 at 2:11 PM, Steve Ebersole 
>> wrote:
>>
>>> Overall the new design looks amazing.  I do agree with Andrea about the
>>> gold backgrounds - that looks anything but modern and does not match the
>>> rest of the site design imo.
>>>
>> Frankly, it feels weird without. So if anyone has a proposition, maybe a
>> different color.
>>
>> My initial inspiration for this was: http://wildfly-swarm.io/ .
>>
>> I personally very much like it and fought with Davide about keeping it :).
>>
> Pushed a different version to http://staging.hibernate.org/search/ using
> something softer for the main title.
>
> Personally, I prefer the golden version.
>
> And I disagree it's not modern by the way. Backgrounds are coming back \o/.
>

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

Re: [hibernate-dev] ORM FAQ

[Chris Cranford]

I would agree.

The performance gain here should highlight caching while the other
points more closely align with reduction of development time.

On 08/07/2017 02:09 AM, andrea boriero wrote:
> it looks really good to me, the only little doubt is related with the
> example in the "how Hibernate is useful" Performance subsection, the
> example looks to me more appropriate for the "Developer time" subsection.
>
>
>
> On 4 August 2017 at 21:09, Vlad Mihalcea  wrote:
>
>> 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
>>
> ___
> 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?

[Chris Cranford]

Personally I would stick to using @Deprecated and be explicit in the
javadoc. 

On 06/28/2017 05: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

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

Re: [hibernate-dev] Pull request

[Chris Cranford]

Vlad / Milo -

I've got it on my todo list for today unless Vlad beats me to it :).

Chris

On 06/07/2017 12:09 AM, Vlad Mihalcea wrote:
> Hi,
>
> If Chris is busy, I can review it for you.
>
> Vlad
>
> On Tue, Jun 6, 2017 at 10:36 PM, 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

Re: [hibernate-dev] 6.0 - concept naming

[Chris Cranford]

Option 3.

On 05/03/2017 10:01 AM, Steve Ebersole wrote:
> To circle back to this... I mentioned possibly keeping a reference to the
> foreign-key defining the join predicate between the root table and the
> secondary table.  ATM however we do not model FKs in the runtime
> metamodel (either in 6 or before).  So that will not work unless we start
> to do that.
>
> Another possibility is to simply keep the list of columns from the
> secondary table that are used in the join predicate.  This would work
> because of an explicit rule followed by both Hibernate and JPA - namely
> that secondary tables (and joined inheritance tables btw) join back to the
> PK columns of the root table.  In other words, we implicitly know the "left
> hand side" portion of the join predicate.
>
> So we have 3 options total for modeling this join predicate:
>
>1. Maintain a predicate tree as part of this SecondaryTableBinding.  ATM
>we have no such concept of this either in the runtime metamodel, so we
>would need to add this if we choose this option.  This would mean adding
>the concept of conjunction/disjunction and relational-operators in some
>form to the runtime metamodel.  Personally, this is my least favorite
>option.
>2. Maintain the join predicate on SecondaryTableBinding via a FK
>reference.  Again, this would mean adding a new concept/class to model the
>FK as part of the runtime metamodel.  I am not against this option so long
>as we deem it has similar benefits in other parts of the codebase - I'd
>prefer to not add such a concept just to handle this case.
>3. Follow the assumption regarding the "left hand side" of these joins
>and just keep a list of the columns from the secondary table that link to
>the entity's root table's PK columns.
>
>
> FWIW, both Hibernate and JPA also assume that the same holds true for
> joined inheritance tables.  Whatever we decide here for secondary tables,
> we should apply to modeling joined inheritence for consistency - perhaps
> even to the point of a shared contract (NonRootTableBinding?).
>
> Opinions?
>
> On Wed, Apr 19, 2017 at 8:35 AM Steve Ebersole  wrote:
>
>> On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov <
>> christian.bei...@gmail.com> wrote:
>>
>>> Sounds good. I hope the secondary table stuff is getting defined on a
>>> higher level(EntityPersister/AbstractEntityPersister). I had problems
>>> implementing OneToOne-JoinTable support for
>>> TablePerClass(UnionSubclassPersister) a while ago and I guess that was
>>> because there is no notion of secondary tables in the EntityPersister. I
>>> guess that issue would be solved then? :)
>>>
>> Not sure what you mean by "higher level".  The design here specifically
>> shows secondary tables modeled as top-level concepts (
>> SecondaryTableBinding).  So I think, again iiuc, that the design already
>> shows secondary tables "defined on a higher level".
>>
> ___
> 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 lock hints misunderstanding

[Chris Cranford]

Per our discussion on HipChat, +1.

On 03/23/2017 06:53 AM, Vlad Mihalcea wrote:
> --works
> select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> processe2_0_ from BatchJob abstractsk0_ with (updlock, rowlock, readpast)
>
> --fails
> select TOP(?) abstractsk0_.id as id1_0_, abstractsk0_.processed as
> processe2_0_ from BatchJob abstractsk0_ with (holdlock, rowlock, readpast)
>
> Hi,
>
> While working on this issue which adds support for SKIP_LOCKED for SQL
> server:
>
> https://hibernate.atlassian.net/browse/HHH-10654
>
> I came to question the way we use the lock hints based on the JPA or
> Hibernate LockMode(Type).
>
> Currently, we do like this:
>
> - PESSIMISTIC_WRITE -> UPDLOCK
> - PESSIMISTIC_READ  -> HOLDLOCK
>
> That's surprising since the HOLDLOCK is actually more restrictive than
> UPDLOCK.
>
> According to the officiala documentation  (
> https://msdn.microsoft.com/en-us/library/ms187373.aspx ) :
>
> UPDLOCK:
>
> "
> Specifies that update locks are to be taken and held until the transaction
> completes.
> UPDLOCK takes update locks for read operations only at the row-level or
> page-level.
> If UPDLOCK is combined with TABLOCK,
> or a table-level lock is taken for some other reason, an exclusive (X) lock
> will be taken instead.
> "
>
> HOLDLOCK:
>
> "
> Is equivalent to SERIALIZABLE. For more information, see SERIALIZABLE later
> in this topic.
> HOLDLOCK applies only to the table or view for which it is specified
> and only for the duration of the transaction defined by the statement that
> it is used in.
> "
>
> Now, the difference between these two is that UPDLOCK takes shared
> row-level locks while
> HOLDLOCK goes byond that and takes range locks as well.
>
> This assumption is backed by these StackOverflow answers:
>
> http://stackoverflow.com/questions/7843733/confused-about-updlock-holdlock
>
> http://stackoverflow.com/questions/42580238/why-does-sql-server-explicit-predicate-locking-disallow-insert-statements-outsid
>
> For SKIP_LOCKED, which is READPAST in SQL Server, we can't use HOLDLOCK at
> all so we need to use UPDLOCK instead.
>
> Now, I think that both PESSIMISTIC_READ and PESSIMISTIC_WRITE should use
> HOLDLOCK,
> and only if we specify SKIP_LOCKED, we then switch to UPDLOCK instead.
>
> 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

Re: [hibernate-dev] 6.0 - Proposed org.hibernate.mapping changes

[Chris Cranford]

I don't have a strong lean either way too.

Either way, this gives integrators and tooling stability on these
contracts while allowing our team to retain some flexibility.  As I
mentioned on HipChat, I've often seen o.h.mapping as a Hibernate
internals only package (even as a user), and so exposing something with
a bit more "guaranteed lifespan" is certainly not a bad idea.  I could
allow Koen, other tooling, and integrations to remain compatible longer
or at least bridge the gap so their release stream doesn't necessarily
have to be absolutely in accordance with our own.

At the very least an SPI would be useful.  I think an API has the best
ROI for tooling/integrators long-term.

On 03/23/2017 05:54 AM, andrea boriero wrote:
> I do not have a strong opinion about it, but I'm leaning towards defining
> this as an SPI
>
> On 22 March 2017 at 18:15, Steve Ebersole  wrote:
>
>> Coming back to this to see if people see this as an API concern, of if we
>> should define this as an SPI.
>>
>> One potential argument for making it an API is that it is *conceivable*
>> that this model could potentially be walked by the same visitors as
>> described in another thread regarding "model navigation". I would not say
>> that this is likely, as it would probably hamper the usefulness of this
>> navigation when applied to the runtime model which is where I think we
>> really want to focus our attention regarding navigation.
>>
>> On Mon, Feb 27, 2017 at 9:51 AM Steve Ebersole 
>> wrote:
>>
>>> No replies, so changing...
>>>
>>> On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole 
>>> wrote:
>>>
>>> For 6.0, what do y'all think of these changes proposed below to the
>>> org.hibernate.mapping package?
>>>
>>> *Koen, this affects tools so really would like your thoughts...*
>>>
>>> Mostly this comes from the definition of a `#finishInitialization` method
>>> on ManagedTypeImplementor (which covers mapped-superclass, entity and
>>> embeddable/embedded).  Currently this method takes its supertype as
>>> PersistentClass; however PersistentClass is generally understood to model
>>> an entity and tooling certainly uses it as such.  Keeping this in mind to
>>> hopefully minimize impact I propose the following:
>>>
>>>
>>>1. Define a new org.hibernate.mapping.ManagedTypeMapping that
>>>represents mappings for any "managed type" in the normal JPA meaning
>> of
>>>that term (mapped-superclass, entity, embeddable)
>>>2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending
>>>ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we
>> split
>>>EmbeddableTypeMapping and "EmbeddedMapping"?
>>>3. Define a new org.hibernate.mapping.IdentifiableTypeMapping
>>>extending ManagedTypeMapping
>>>4. Define a new org.hibernate.mapping.MappedSuperclassTypeMapping
>>>extending IdentifiableTypeMapping
>>>5. Define a new org.hibernate.mapping.EntityTypeMapping extending
>>>IdentifiableTypeMapping
>>>6. Make PersistentClass extend EntityTypeMapping and deprecate
>>>7. Make Composite extend EmbeddedTypeMapping and deprecate
>>>8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and
>>>deprecate
>>>9. Re-work the hierarchies here to better fit this new model
>>>
>>>
>>> /**
>>>  * ...
>>> *
>>> * @todo (6.0) Use ManagedTypeMapping here as super-type rather than
>>> PersistentClass
>>> */
>>> void finishInitialization(
>>> ManagedTypeImplementor superType,
>>> PersistentClass entityBinding,
>>> PersisterCreationContext creationContext);
>>>
>>>
>>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] [hibernate-demos] PR and issues and what to do about it

[Chris Cranford]

You'll never know ;)

On 02/27/2017 08:54 AM, Gunnar Morling wrote:
> Not sure whether you are joking or not, so just in case :)
>
> You'll get notifications on new PRs when "watching" a repo:
>
> https://help.github.com/articles/watching-repositories/
>
> --Gunnar
>
>
> 2017-02-27 14:22 GMT+01:00 Chris Cranford <ch...@hibernate.org>:
>> Emmanuel -
>>
>> I don't mind.  It's simple enough to check the PR tab couple times daily :).
>>
>> On 02/27/2017 07:39 AM, Emmanuel Bernard wrote:
>>> There has been an effort to collect demos under a single repo.
>>> https://github.com/hibernate/hibernate-demos
>>>
>>> The good news is that people seem to like it enough that they send pull 
>>> requests and issue reports to improve it. The bad news is that we did not 
>>> reply to them. I think it’s because no one is notified of these. Can anyone 
>>> enlist and be the guardian or even just the dispatcher for this kind of 
>>> feedback?
>>>
>>> I’ve cleaned up and applied a couple of pull requests today.
>>>
>>> Emmanuel
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] [hibernate-demos] PR and issues and what to do about it

[Chris Cranford]

Emmanuel -

I don't mind.  It's simple enough to check the PR tab couple times daily :).

On 02/27/2017 07:39 AM, Emmanuel Bernard wrote:
> There has been an effort to collect demos under a single repo.
> https://github.com/hibernate/hibernate-demos
>
> The good news is that people seem to like it enough that they send pull 
> requests and issue reports to improve it. The bad news is that we did not 
> reply to them. I think it’s because no one is notified of these. Can anyone 
> enlist and be the guardian or even just the dispatcher for this kind of 
> feedback?
>
> I’ve cleaned up and applied a couple of pull requests today.
>
> Emmanuel
> ___
> 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] MariaDB-specific Dialects

[Chris Cranford]

+1 for both

On 02/06/2017 08:19 AM, Steve Ebersole wrote:
> Fwiw Dialect discovery is far and away the preferred solution for
> "specifying" Dialect.  That said, I am ok with splitting off Dialect(s)
> specific to MariaDB.
>
> Relatedly, I wonder if we should begin to remove the Dialects we have
> marked as deprecated and whether we should consider a  "legacy" repo where
> we can dump these (as well as other removed features - Javassist support
> e.g.).  The expectation would be no continued development, but would make
> them  more readily available to users who still needed them as opposed to
> simply dropping them completely.  We could even alter the license of those
> classes to be less restrictive than LGPL in terms of contributing back
> changes.
>
> On Mon, Feb 6, 2017, 6:47 AM Sanne Grinovero  wrote:
>
>> +1 to split them. I don't expect people to consider them "the same"
>> anymore..
>>
>> We probably should have split them even if there had been no technical
>> differences, just to make it clear which one needs to be configured.
>>
>> On 6 February 2017 at 12:37, Vlad Mihalcea 
>> wrote:
>>> Hi,
>>>
>>> I've had a very interesting discussion on Twitter regarding MarisDB:
>>>
>>> https://twitter.com/bobbytank42/status/828529312731013121
>>>
>>> And, since MySQL and MariaDB have gone in different directions, we might
>>> want to provide MariaDB Dialects as well.
>>>
>>> For instance, it's not very intuitive for a Hibernate user to figure out
>>> that they need to use the MySQLInnoDb57Dialect to handle Timestamps with
>>> microsecond precision which have been available since MariaDB 5.3:
>>>
>>> https://mariadb.com/kb/en/mariadb/microseconds-in-mariadb/
>>>
>>> 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 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] Extended KEY expression support

[Chris Cranford]

My thoughts


On 01/28/2017 06:00 AM, Christian Beikov wrote:
> I created an issue for this feature:
> https://hibernate.atlassian.net/browse/HHH-11433
>
>
> Am 27.01.2017 um 23:58 schrieb Steve Ebersole
>> I personally would vote to *not* make this change in 5.x even in terms
>> of making it configurable.  The grammar there is fugly enough already
>> and this is the kind of thing (especially making branches of it
>> configurable) that takes that fugliness to a new level.
> I gave that another thought and don't think that requiring the user to
> do a separate join is a good idea anymore. We can actually infer if a
> join is required and when using the ANSI parenthesis join syntax the
> join type does not really matter. If we stick to the join rendering
> style we have, we should just use the collection tables join type.
>
> Do you think it makes sense to implement support for "JOIN
> KEY(m).association" in 5.2 or just leave it as it is? I would implement
> that if you give your ok.
>
> What do you think about all that so far?
>
I'd say we likely shouldn't be putting significant effort into adding 
**new features*** *into 5.2.  I'd recommend adding it into the 6.0 
branch and if/when we decide to consider a 5.3 branch release as a 
further stepping stone to 6.0, perhaps we back-port this feature to that 
branch if the team feels its relevant to do so.

But that's just my perspective :).

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

Re: [hibernate-dev] Query#iterate

[Chris Cranford]

+1 to remove as well


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

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


 Am 27.01.2017 um 19:01 schrieb Steve Ebersole:

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

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


 ScrollableResults do not meet that need?



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


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



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


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

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



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

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

Re: [hibernate-dev] 6.0 - Session#createFilter

[Chris Cranford]

+1


On 01/03/2017 10:02 AM, andrea boriero wrote:
> +1 for removing createFilter()
>
> On 3 January 2017 at 15:54, Gunnar Morling  wrote:
>
>> 2017-01-03 15:28 GMT+01:00 Steve Ebersole :
>>
>>> On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling 
>>> wrote:
>>>
 2017-01-02 15:27 GMT+01:00 Steve Ebersole :
 I realize now that Session#createFilter() is only geared towards
 collections. So are you suggesting to only remove that method, but keep
 @Filter/@FilterDef?

>>>
>>> Correct.   @Filter and @FilterDef are in NO WAY related to
>>> Session#createFilter
>>>
>> Ok. then +1 from my side for removing createFilter() .
>> ___
>> 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] ScrollableResults and 6.0

[Chris Cranford]

Steve -

I'm inclined to agree that changing signatures makes the most sense at 
this point.

Chris


On 12/27/2016 04:02 PM, Steve Ebersole wrote:
> FWIW my inclination is to just change the existing signatures.  6.0 is a
> major release with major changes already wrt querying.
>
>
> On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole  wrote:
>
>> For 6.0 I'd like to also make ScrollableResults parameterized wrt the "row
>> type".  E.g.
>>
>> ScrollableResults sr = session.createQuery( ..., Person.class
>> ).scroll();
>>
>> However that changes the signature of its methods returning a "row"
>> (currently always defined as Object[]).
>>
>> How would everyone prefer we handle this?  Do I just change the signatures
>> of the existing methods?  Or add new methods?
>>
> ___
> 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] RH Summit 2017 CFP

[Chris Cranford]

Vlad -

Do we have anyone who would like to present the talk?

Chris


On 11/28/2016 09:43 AM, Vlad Mihalcea wrote:
> Hi,
>
> I've talked to Steve about this topic, and I remember that we 
> concluded that we should send a presentation proposal on the following 
> two topics:
>
> - What's new in Hibernate 6.0
> - Hibernate Performance Tuning Tips
>
> Vlad
>
> On Mon, Nov 28, 2016 at 4:40 PM, Chris Cranford <ch...@hibernate.org 
> <mailto:ch...@hibernate.org>> wrote:
>
> The Red Hat Summit 2017 CFP is closing on December 16th and I would
> recommend we try and submit our abstracts this week if we could. 
>  From
> the ORM side, is there any particular topics we'd care to present or
> anyone who would like to present?
>
> Chris
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>

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

[hibernate-dev] RH Summit 2017 CFP

[Chris Cranford]

The Red Hat Summit 2017 CFP is closing on December 16th and I would 
recommend we try and submit our abstracts this week if we could.   From 
the ORM side, is there any particular topics we'd care to present or 
anyone who would like to present?

Chris

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

Re: [hibernate-dev] NativeQuery and parameters

[Chris Cranford]

+1


On 09/20/2016 08:59 PM, Steve Ebersole wrote:
> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only defines support for "JDBC-style parameters" as valid for native
> SQL queries:
> {quote}
> It is assumed that for native queries the parameters themselves use the SQL
> syntax (i.e., “?”, rather than “?1”).
> {quote}
>
> Furthermore Hibernate does not support a native query using both positional
> parameters and JDBC-style parameters in the same query because it causes a
> non-determinism wrt the positions.
>
> I assume we want to continue to support that full complement of parameter
> types, with the positional/JDBC-style caveat.
>
> Further I assume we will hook up the use of any non-JDBC-style parameters
> in with the "strict JPA compliance" checking and throw an error when
> indicated.
>
> Anyone have objections to any of that?
> ___
> 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 Envers > link between to auditable entities

[Chris Cranford]

Tarek -

See inline.

On 09/01/2016 10:11 AM, Dev Stack wrote:
> Hi Chris,
>
> Thank you for your answer.
>
> 1) yes, we can use Set<>
> 2) When we load an offer we have to load also the associated product.
> So, we have to keep the link from offer to product.
> the link from product to offer is not needed for now.
What I meant here was more along the lines of keeping the bidirectional 
relation,
but instead of the @ManyToOne being the owner of the mapping, we'd 
invert it so
that the @OneToMany owned the relationship.  The mapping would then be:

@Entity
@Audited
public class Product {
   ...
   @OneToMany
   @JoinColumn(name = "product_offer")
   @AuditMappedBy(mappedBy = "product")
   private Set offers;
   ...
}

@Entity
@Audited
public class Offer {
   ...
   @ManyToOne
   @JoinColumn(name = "product_offer", insertable = false, updatable = 
false)
   private Product product;
   ...
}

We want to do this to take advantage of Envers' 
REVISION_ON_COLLECTION_CHANGE.
See below in your point 2 as to why.

> Thanks,
> Tarek
>
> 2016-09-01 15:55 GMT+02:00 Chris Cranford <cranc...@gmail.com 
> <mailto:cranc...@gmail.com>>:
>
> Tarek -
>
> There are a few ways we can tackle what you want all within the
> scope of Envers,
> but some of it highly depends upon details specific to the
> relationship between
> Product (P) and Offer (O).
>
> 1. What is the collection type used in Product for the related offers?
>If this happens to be a List<>, would it be possible to use a
> Set<> instead?
>
> 2. Is there a requirement that Offer should own the relationship
> with Product?
>In other words, is it possible to invert the relationship such
> that the
>collection side is the owner instead?
>
> Chris
>
>
> On 09/01/2016 06:14 AM, Dev Stack wrote:
>
> Hello,
>
> we have in our model entity P (product) and entity O (offer).
> The two
> entities have a link.
> one instance of P can have one or many O instances.
> an instance O has a reference to only one instance of P.
> The link is managed in the O side.
>
> P and O are revisioned by Hibernate Envers.
>
> Two use cases to cover:
> 1) If P instance is updated (new revision) we want that O keep
> the link
> with the old revision of P.
>
You get this by default.

Regardless of which side owns the relationship, any change made 
specifically to a
Product that does not change the associated Offer instances, only a 
revision is
triggered for Product, allowing Offer instances to point to the older 
versions of a
Product when they're queried.

If we assume a Product and Offer were created in revision 1 and 
subsequently the
Product was modified in revision 2, the following are true:

   auditReader.getRevisions( Offer.class, offerId ) = [1]
   auditReader.getRevisions( Product.class, productId) = [1, 2]

So querying Offer at revision 1 would give you the product instance at 
revision 1

   Offer offer = auditReader.find( Offer.class, offerId, 1 );
   offer.getProduct() = Product at revision 1

> 2) When I update O instance, I will move the reference to the
> last revision
> of O instance.
>
> What we did is, inside O class we added to attributes P.id and
> P.revision.
> So when we load the object P we use these to fields to load
> manually (O DAO
> has reference P DAO).
>
I think it makes more sense to enforce this through Envers than 
polluting the domain
model, but that's just my opinion ;).

The cleanest way is to invert the relationship as I described above and 
change the
collection type to a Set<>.  The setting REVISION_ON_COLLECTION_CHANGE will
take affect since Product now owns the relationship and any change you 
make to
an Offer, the owning entity (Product) will be revised automatically.

In other words, changes to an Offer will force Product to update and so 
the revision
number query logic from 1) holds true and helps us here too.

NOTE: Just be sure you implement the appropriate equals/hashCode logic 
for Offer
so that changes are properly detected.

If you decide you don't want to use REVISION_ON_COLLECTION_CHANGE and invert
the relationship between Product and Offer, the only other partial 
Envers' solution
I see might be to introduce some attribute on Product that is audited 
that your
business tier couldchange when an offer is modified, causing the Product to
be audited like the following:

   entityManager.getTransaction().begin();
   changedOffer.setCode( "NEWCODE" );
   changedOffer.getProduct().pulse(); // updates a field to trigger revision
   entityManager.merge( changedOffer );
   entityManager.getTransaction().commit();

Hope this helps.
Chris


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

Re: [hibernate-dev] Hibernate Envers > link between to auditable entities

[Chris Cranford]

Tarek -

There are a few ways we can tackle what you want all within the scope of 
Envers,
but some of it highly depends upon details specific to the relationship 
between
Product (P) and Offer (O).

1. What is the collection type used in Product for the related offers?
If this happens to be a List<>, would it be possible to use a Set<> 
instead?

2. Is there a requirement that Offer should own the relationship with 
Product?
In other words, is it possible to invert the relationship such that the
collection side is the owner instead?

Chris

On 09/01/2016 06:14 AM, Dev Stack wrote:
> Hello,
>
> we have in our model entity P (product) and entity O (offer). The two
> entities have a link.
> one instance of P can have one or many O instances.
> an instance O has a reference to only one instance of P.
> The link is managed in the O side.
>
> P and O are revisioned by Hibernate Envers.
>
> Two use cases to cover:
> 1) If P instance is updated (new revision) we want that O keep the link
> with the old revision of P.
> 2) When I update O instance, I will move the reference to the last revision
> of O instance.
>
> What we did is, inside O class we added to attributes P.id and P.revision.
> So when we load the object P we use these to fields to load manually (O DAO
> has reference P DAO).
>
> Is there a better way to do it?
> Should we keep the reference of P in O instance as auditable and Envers
> will manage?
>
> Thanks,
> Tarek
> ___
> 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] Needing and ORM 5.1.1.Final

[Chris Cranford]

Sanne -

I'm under the impression that Gail has plans to do a 5.0.10 / 5.1.1 late 
this week if all goes according to plan.

Chris


On 07/20/2016 04:36 AM, Sanne Grinovero wrote:
> Hi all,
> we're still needing a release of Hibernate ORM 5.1.1 for Hibernate OGM..
>
> could we plan for one soon please?
>
> 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] "Awaiting Testcase" transition

[Chris Cranford]

+1
On 07/17/2016 05:52 PM, Brett Meyer wrote:
> +1!
>
> On 07/17/2016 10:54 AM, Steve Ebersole wrote:
>> I see folks using a generic "template" for the comment added to an issue
>> when they transition it to the "Awaiting Testcase" status.  If we all
>> agree, we could make that a post-function of the transition - meaning that
>> comment would be added automatically.
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] HIbernate ORM CI builds

[Chris Cranford]

+1

I think (1) and (2) on each push still makes sense with (3) being nightly.

Chris


On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> We have been having a lot of timeouts on the ORM CI builds.  Mainly this is
> due to ancillary tasks.  Currently the ORM jobs execute:
>
> 1. clean
> 2. test
> 3. check
> 4. :documentation:aggregateJavadocs
> 5. publish
>
> A huge chunk of the time is taken up in (3) which performs (a) checkstyle
> and (b) findbugs.  Also, I am not sure of the benefit of building
> aggregated javadocs for each and every CI build.  So I propose we break
> these up as follows:
>
>
> 1. A check job
> 2. A clean/test/publish job
> 3. (?) aggregated javadocs job (?)
>
> This would allow us to split the cost of the Job timeout across the jobs.
> In fact we might even consider making some of these into nightly job(s).
> Initially in setting up this server we decided to just have singular,
> all-encompassing jobs because moving to a new dedicated set of hardware
> (dedicated to Hibernate team) was supposed to free us from jobs fighting
> for resources.  But as our jobs have grown on the dedicated hardware we are
> seeing some of the same.  For certain we want a clean/test/publish job that
> is run on every push.  To me the others are more flexible in terms of
> scheduling.  We could have a separate check job that is run on each push,
> or it could be a nightly job.  We might even decide to leave off building
> aggregated javadocs as an automated job/task, or we might decide to make it
> a nightly job as well (maybe even with full documentation builds).
>
> WDYT?
> ___
> 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] Regarding release versioning

[Chris Cranford]

+1 for the hybrid approach if we feel we need minor release CRs.


On 06/08/2016 09:06 AM, Steve Ebersole wrote:
> back to this then I vote that we also go for a hybrid approach to this
> where Final is an approximation of the "approved CR", likely with
> additional fixes.
>

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

Re: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager

[Chris Cranford]

On 04/25/2016 10:34 AM, Steve Ebersole wrote:
> I'd add this as well...
>
> I believe that in most of the cases here we are talking about (passing in a
> bad query, closing a closed Session, etc) these exceptions are of the
> "checked" sort, meaning they are easily identifiable prior to deployment.
> Which IMO helps mitigate somewhat the difficulty handling a change in
> exception type
+1

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

Re: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager

[Chris Cranford]

On 04/25/2016 12:04 AM, Vlad Mihalcea wrote:
> 1. "calling EntityManager#close on a closed EntityManager should result in an
> exception;" - that's a reasonable default and shouldn't cause too much
> trouble.
> 2. "Another change in expectation is in regards to operations outside of a
> transaction" - in JPA we can execute queries outside a transaction, but any
> write will fail if there is no transactional context, which is reasonable
> for me too. If Hibernate allows writes outside of a transactional context,
> that's definitely a thing we should not support anyway.
> 3. "Asking a Session if is contains (Session/EntityManager#contains) a
>   non-entity" - we can handle this with the separate exception handler
> strategies to retain both JPA and Hibernate behaviors.
> 4. "Accessing Session/EntityManager#getTransaction.  JPA says that is
> only allowed
> for JDBC transactions.  Hibernate always allows it." - I'd choose the
> Hibernate behavior because I don;t see how it can cause any issue and it's
> an enhancement as well.
+1
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted!

[Chris Cranford]

Welcome aboard, Mincong!!

On Sat, Apr 23, 2016 at 3:39 AM, Gunnar Morling 
wrote:

> Hi Mincong,
>
> Congrats and welcome to this year's GSoC! Looking forward to the project
> and your contributions very much!
>
> @Everyone: Please join me in welcoming Mincong to the team! He is a student
> living in France and as part of Google Summer of Code he will be working on
> an alternative for mass indexing entities in Hibernate Search based on the
> JSR 352 for batch applications (see [1] for the project proposal). I'll be
> mentoring him.
>
> @Mincong: All the best for your GSoC! I'd say for now enjoy the weekend
> before the action begins and then let's get a discussion on the details
> started.
>
> Onwards,
>
> --Gunnar
>
> [1] https://summerofcode.withgoogle.com/serve/5594702887780352/
>
>
>
> 2016-04-22 23:20 GMT+02:00 Mincong Huang :
>
> > Hi everybody,
> >
> > Thanks for accepting my application of GSoC !! Really excited to having
> > chance to work the hibernate team. I'm so happy to see this email. It's
> > just
> > like a dream, can't believe it is true !! Thanks for choosing me. I'll
> try
> > my
> > best to accomplish this mission !! Happy coding and good night :-)
> >
> > Cheers,
> > Mincong
> >
> > On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code <
> > summerofcode-nore...@google.com> wrote:
> >
> >> [image: Google Summer of Code]
> >>
> >> Hi mincongh,
> >>
> >> Welcome to GSoC 2016!
> >>
> >> Your proposal Hibernate Search: JSR 352 batch job for re-indexing
> >> entities
> >> <
> https://summerofcode.withgoogle.com/dashboard/student/proposal/5244068401512448/
> >
> >> has been accepted!
> >>
> >> We look forward to seeing the great things you will accomplish this
> >> summer with JBoss Community.
> >>
> >> This email contains important information about your participation in
> >> GSoC this year. Please read it carefully.
> >>
> >> Over the next month you will take part in the Community Bonding period
> >> with your organization. This period is for you to become familiar with
> the
> >> organization's code base, version control and other infrastructure. You
> >> will be getting to know the community and its practices, as well as
> working
> >> with your mentor on milestones for the summer.
> >>
> >> Complete all of these steps as soon as you can:
> >>
> >>1. Read the Accepted Student Information
> >><
> https://developers.google.com/open-source/gsoc/help/accepted-students>
> >>2. Upload  your tax
> >>form *before May 16, 2016 at 19:00 UTC*
> >>3. Read the Student Payment Information
> >>
> >>4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC
> >>5. Verify your shipping address, promotional materials, and t-shirt
> >>information on your profile
> >>.
> >>
> >> If you have questions about anything in this email, please email the
> >> Google GSoC support team at gsoc-supp...@google.com. Don’t email the
> >> student list with tax or payment issues.
> >>
> >> Have a great summer!
> >>
> >> Google Open Source Programs team
> >>
> >> This email was sent to mincon...@gmail.com.
> >>
> >> You are receiving this email because of your participation in Google
> >> Summer of Code 2016.
> >> https://summerofcode.withgoogle.com
> >>
> >> To leave the program and stop receiving all emails, you can go to your
> >> profile  and
> >> request deletion of your program profile.
> >>
> >> For any questions, please contact gsoc-supp...@google.com. Replies to
> >> this message go to an unmonitored mailbox.
> >>
> >> © 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043,
> >> USA
> >>
> >
> >
> ___
> 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] Master

[Chris Cranford]

+1 for 5.2

On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole <st...@hibernate.org> wrote:

> As a follow up to this...
>
> Sanne had a great suggestion on HipChat.  What about turning all this work
> (sans SQM, etc) into a 5.2 as an "end of line for 5.0.  The idea would be
> 5.2 would include:
>
>1. Move to Java 8
>2. Consolidation of hibernate-entitymanager into hibernate-core
>3. Deprecations, lots of deprecations :)
>
>
> The idea is that then we could start 6.0 off "clean" by removing all the
> deprecations and layering in SQM work.
>
>
>
> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea <mihalcea.v...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Until the merge is done, I'll take a break integrating the PRs that are
>> also relevant to the master branch.
>>
>> Vlad
>>
>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole <st...@hibernate.org>
>> wrote:
>>
>>> I agree that would be best.  If everyone agrees to stop pushing to master
>>> for the time being to allow me to finish this consolidation then I can
>>> not
>>> rush it as much
>>>
>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford <cranc...@gmail.com>
>>> wrote:
>>>
>>> > I have to concur with Sanne, a hold on master pushes until this merge
>>> of
>>> > artifacts is complete makes the most sense from an all around logistics
>>> > perspective.
>>> >
>>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero <sa...@hibernate.org>
>>> > wrote:
>>> >
>>> > > Sounds reasonable. Do you think it will be unstable, i.e. should we
>>> > > temporarily disable complaint emails from Jenkins, or even the full
>>> > > build tasks?
>>> > >
>>> > > Also, this implies that any future backport becomes similarly harder,
>>> > > so you could also simply ask others to hold pushing on master, then
>>> > > have people forward-port when it's done.. it's the same really but
>>> > > that's why I mention it: as the complexity is interchangeable it's a
>>> > > fair request, with the difference you have:
>>> > >  - others help you port the other patches forward rather than doing
>>> it
>>> > all
>>> > > alone
>>> > >  - the authors of the original patch doing it, that should make it a
>>> bit
>>> > > simpler
>>> > >
>>> > >
>>> > >
>>> > > On 6 April 2016 at 17:15, Steve Ebersole <st...@hibernate.org>
>>> wrote:
>>> > > > Obviously consolidating hibernate-entitymanager into
>>> hibernate-core is
>>> > a
>>> > > > fairly big effort.  And I am getting concerned about the continuing
>>> > > pushes
>>> > > > to master in the meantime, many of which I know touch on code I
>>> have
>>> > > > changed.  My concern is obviously getting done all this refactoring
>>> > work
>>> > > > and then having to sift through all of the changes that have been
>>> > pushed
>>> > > in
>>> > > > the interim and attempting to work out the proper integration
>>> strategy.
>>> > > >
>>> > > > Long story short... I am contemplating pushing to master sooner
>>> rather
>>> > > than
>>> > > > later even though my refactoring may not be completely finished,
>>> > > especially
>>> > > > as we get towards the end of the week.
>>> > > > ___
>>> > > > hibernate-dev mailing list
>>> > > > hibernate-dev@lists.jboss.org
>>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > > ___
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev@lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >
>>> > ___
>>> > hibernate-dev mailing list
>>> > hibernate-dev@lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Master

[Chris Cranford]

I have to concur with Sanne, a hold on master pushes until this merge of
artifacts is complete makes the most sense from an all around logistics
perspective.

On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero  wrote:

> Sounds reasonable. Do you think it will be unstable, i.e. should we
> temporarily disable complaint emails from Jenkins, or even the full
> build tasks?
>
> Also, this implies that any future backport becomes similarly harder,
> so you could also simply ask others to hold pushing on master, then
> have people forward-port when it's done.. it's the same really but
> that's why I mention it: as the complexity is interchangeable it's a
> fair request, with the difference you have:
>  - others help you port the other patches forward rather than doing it all
> alone
>  - the authors of the original patch doing it, that should make it a bit
> simpler
>
>
>
> On 6 April 2016 at 17:15, Steve Ebersole  wrote:
> > Obviously consolidating hibernate-entitymanager into hibernate-core is a
> > fairly big effort.  And I am getting concerned about the continuing
> pushes
> > to master in the meantime, many of which I know touch on code I have
> > changed.  My concern is obviously getting done all this refactoring work
> > and then having to sift through all of the changes that have been pushed
> in
> > the interim and attempting to work out the proper integration strategy.
> >
> > Long story short... I am contemplating pushing to master sooner rather
> than
> > later even though my refactoring may not be completely finished,
> especially
> > as we get towards the end of the week.
> > ___
> > 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] Java 8 default methods as a refactoring tool

[Chris Cranford]

+1

Echo the same as others have said.
On Mar 30, 2016 5:52 AM, "andrea boriero"  wrote:

> +1
>
> in my opinion at some point we will have to move to java8 and Hibernate 6.0
> for me is a good candidate.
>
> On 30 March 2016 at 12:40, Vlad Mihalcea  wrote:
>
> > +1
> >
> > Same opinion. Hibernate 6.0 should use Java 8 too. Most projects already
> > use Java 1.8, and most important the new ones that are started are using
> > Java 1.8 anyway.
> > Other frameworks are doing the move too, Spring 5.0 will use Java 1.8.
> >
> > Vlad
> >
> > On Wed, Mar 30, 2016 at 1:25 PM, Sanne Grinovero 
> > wrote:
> >
> > > +1
> > > My personal opinion is that we should switch to Java8 for our next-gen
> > > platform.
> > >
> > > On top of the cool point on default methods you mention, it should
> > > also make it easier to start polishing our APIs to have end users take
> > > advantage of Java8 features.
> > >
> > > Not least, next version of Apache Lucene will require Java8, and some
> > > components of OGM require Java8 (like ORM's 2nd level cache where
> > > Infinispan is involved).
> > >
> > > I'm pretty sure that there will be Hibernate users stuck on Java7, 6,
> > > 5 .. for a while yet but I suspect that this is the same population
> > > still using Hibernate 2, 3, 4, .. maybe 5 now, but I doubt they will
> > > be willing to take ORM.next (6?) and yet be in the old-JVM category.
> > >
> > > -- Sanne
> > >
> > >
> > >
> > > On 29 March 2016 at 21:04, Steve Ebersole  wrote:
> > > > One question we have discussed but never really answered with regard
> to
> > > ORM
> > > > as we work on SQM has to do with the version of Java we would
> baseline
> > > on.
> > > > Currently ORM 5.0 and 5.1 continue the tradition of still running in
> > > Java 6
> > > > runtimes.  Java 8 has since come along and offered some JDK "goodies"
> > > and a
> > > > new update of JDBC.  So the question was whether we stick with Java 6
> > > > support or look to leverage and take advantage of these new Java 8
> > > features?
> > > >
> > > > Another argument for switching to Java 8 on top of those we have
> > already
> > > > discussed is that Java 8's "default methods" feature would allow us
> to
> > > > continue to develop major changes but in a possibly less disruptive
> > way.
> > > > In a lot of cases anyway.  Say I am adding a new method on a public
> API
> > > > interface (org.hibernate.type.Type, e.g.).  That breaks all
> > implementors
> > > of
> > > > that interface, until they provide an implementation of that new
> > > interface
> > > > method.  We've seen this in the past with bootstrapping in ORM and
> OGM,
> > > > where ORM being able to define default implementations of the methods
> > on
> > > > the interface.. tat just makes it easier for seamless updating of
> > > Hibernate
> > > > versions.  We handled that in the ORM/OGM bootstrapping case by means
> > of
> > > > introducing an implementation of that interface that OGM would then
> > > extend,
> > > > as opposed to just implementing the interface.
> > > > ___
> > > > hibernate-dev mailing list
> > > > hibernate-dev@lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev