Re: [hibernate-dev] Refactor MySQL Dialects

That is a good solution for now. Ultimately I think we still want to add some capability for Dialects to configure either themselves or the things they return based on Connection, env, etc. It's something we have discussed for some time. On Wed, Feb 8, 2017 at 1:01 AM Vlad Mihalcea

Re: [hibernate-dev] Form-feed (\f 0x0C) in generated SQL

>From which job? The JDK 9 one? Those failures you can ignore On Tue, Feb 7, 2017, 11:52 AM Mark Rotteveel wrote: > Thanks! > I just received a build failure notification with an > ExceptionInInitialiserError, but I can't see how my PR would introduce that > error. > >

Re: [hibernate-dev] MariaDB-specific Dialects

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

Re: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId

https://hibernate.atlassian.net/browse/HHH-11444 On Tue, Jan 31, 2017 at 12:52 AM Christian Beikov < christian.bei...@gmail.com> wrote: > Sounds good to me. +1 > > Am 30.01.2017 um 17:31 schrieb Steve Ebersole: > > Relatedly, I have been thinking whether we want to renam

Re: [hibernate-dev] Query#iterate

gt; > > > On 01/27/2017 01:50 PM, Sanne Grinovero wrote: > > > +1 to remove > > > > > > On 27 January 2017 at 18:34, Vlad Mihalcea <mihalcea.v...@gmail.com> > > wrote: > > >> I'm for removing it even if it didn't complicate the query parser. >

Re: [hibernate-dev] Behaviour of validation mode "auto" in case of error during validator factory bootstrap

+1 fof fail-fast in regards to bootstrap problems whenever possible On Wed, Feb 1, 2017 at 5:12 AM Sanne Grinovero wrote: > +1 for fail fast > > I think we generally aim for that as a good practice - when doable - > and I suspect people expect it. > > On 1 February 2017 at

Re: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts)

s core and typically another module with the NoSQL/indexing > backend (hence I like "hibernate-ogm-core" there). > > > > 2017-01-30 17:31 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > > Relatedly, I have been thinking whether we want to rename the ORM > artifa

Re: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts)

The underlying problem is still unfixed[1]. There is a work around we could try. [1] https://issues.gradle.org/browse/GRADLE-2966 -> https://github.com/gradle/gradle/issues/1061 On Wed, Feb 1, 2017 at 11:43 AM Steve Ebersole <st...@hibernate.org> wrote: > Most likely it is the c

Re: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts)

e I like the more concise "hibernate-orm" id (similar to > "hibernate-validator"). It's a bit different for OGM and HSEARCH where > one needs core and typically another module with the NoSQL/indexing > backend (hence I like "hibernate-ogm-core" there). > &

[hibernate-dev] Hibernate ORM 6.0 groupId/artifactId (was: Re: NoORM - New groupId and relocation artifacts)

` 2. rename all the artifacts following the pattern `hibernate-orm-${1}`, e.g. `hibernate-orm-core`, `hibernate-orm-osgi`, etc. On Mon, Jan 30, 2017 at 10:26 AM Steve Ebersole <st...@hibernate.org> wrote: > Well let's investigate what this consistency means across projects first. &

Re: [hibernate-dev] Hibernate Commons project

Disclaimer : I have not yet looked at the Asciidoc style. Again I promise to look at it when I come back from PTO. That said I want to make certain that the developed style matches the new ORM documentation style. The design team at Red Hat spent a lot of time helping us develop that.

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

Well let's investigate what this consistency means across projects first. As Sanne mentions, if it makes it building ORM more difficult then I'd be -1 it too. But I promise to take a peek when I get back from PTO in a few days. Or maybe Andrea can in the next few days as he already has worked on

Re: [hibernate-dev] Extended KEY expression support

FWIW = for what it is worth. TBH, to me it is not worth much ;) I don't do things "just because EclipseLink does it". On Fri, Jan 27, 2017 at 2:33 PM Christian Beikov wrote: > Fwiw EclipseLink supports both syntaxes "JOIN KEY(m) k" and also "JOIN >

Re: [hibernate-dev] Extended KEY expression support

My initial thoughts... On Fri, Jan 27, 2017 at 1:29 PM Christian Beikov wrote: > I have a little proposal for supporting the use of a KEY expression in > the FROM clause and I'd like to hear your opinions on that. > Unfortunately the JPA spec does not support that,

Re: [hibernate-dev] boolean type support

> Nevertheless, the current implementation is nice as well. We have a single > Java descriptor and multiple Sql descriptors to cover various DB column > types or column values. > > Vlad > On Fri, Jan 27, 2017 at 8:28 PM, Steve Ebersole <st...@hibernate.org> > wro

Re: [hibernate-dev] boolean type support

Correction : If they have not done that either, we'd simply *ask* the Dialect. On Fri, Jan 27, 2017 at 12:24 PM Steve Ebersole <st...@hibernate.org> wrote: > On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov < > christian.bei...@gmail.com> wrote: > > Am 27.01.2017 um 17:3

Re: [hibernate-dev] Query#iterate

ctually 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 < > chris

Re: [hibernate-dev] boolean type support

On Fri, Jan 27, 2017 at 10:46 AM Christian Beikov < christian.bei...@gmail.com> wrote: > Am 27.01.2017 um 17:31 schrieb Steve Ebersole: > > Obviously that only works if there is not already an AttributeConverter > > applied to to the attribute. I cannot imag

Re: [hibernate-dev] Query#iterate

On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov wrote: > I just know of people that are using iterate() now for efficient > incremental processing, but I guess any other approach(streams maybe?) > to do incremental processing would be good enough for these users. > >

[hibernate-dev] boolean type support

Another thing we run into in 6.0 dev is handling booleans, specifically in regards to dealing with the database representation (0 or 1, versus 'T' of 'F', versus ...). The way we handle this today (pre-6.0) is to "fake it" by registering a JavaTypeDescriptor for each representation combo[1]. We

[hibernate-dev] Query#iterate

I know I started a discussion of this somewhere with some of you, but I cannot find it anymore. I had suggested we consider getting rid of this Query#iterate method. I just wanted to get everyone's opinions of this. Specifically, getting of it in 6.0. If anyone has dug much into the current

Re: [hibernate-dev] 6.0 - ResultTransformer

On Tue, Sep 13, 2016 at 9:55 PM Gail Badner wrote: > Sorry for the late response. I've been looking through the fix for > HHH-5163 [1] to jog my memory. > > Here are some reasons why CacheableResultTransformer is important when > caching query results: > > 1) The same SQL can

Re: [hibernate-dev] 6.0 - Type system

gt; I see no reason why we should keep it indefinitely. I'd say we > deprecate it > >> in 5.x, and remove it later (6.0 or 6.1). > >> Migrating a custom UserType to using Java and SQL descriptor is not > >> difficult, and we could just write a blog post for a

Re: [hibernate-dev] 6.0 - Type system

ustom-type Vlad On Mon, Jan 23, 2017 at 3:37 PM, Steve Ebersole <st...@hibernate.org> wrote: Right, and that exactly lines up with what I am proposing. If the intent of "customize" is to describe new Java types (e.g. Java 8 temporals prior to our explicit support) the tht is

Re: [hibernate-dev] 6.0 - Type system

as before: database types that are not universally supported by all RDBMS. Vlad On Thu, Jan 19, 2017 at 9:55 PM, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote: There's a lot to dig in here. I'll have to get the branch and study the changes, to come back with some opinions. Vlad On Thu, Jan 19,

Re: [hibernate-dev] Hibernate ORM Project - Getting Started on "SuitableForNewContributors" Jira Issues

Hi Valerie! Just comment on the issue that you are giving it a try and work on it in a branch on your fork of hibernate-orm repo. When you are done, send us a pull request. Thanks for your interest On Thu, Jan 19, 2017, 9:57 AM Valerie Arena wrote: > Hello, > > I

[hibernate-dev] 6.0 - Type system

We are getting pretty far along on the 6.0 changes and I wanted to start a(nother) discussion about Types in 6.0 to get feedback and thoughts on a few topics. First a quick break down of JavaTypeDescriptors, SqlTypeDescriptors, Types and "persisters"... (a lot of this is the same from pre-6.0,

[hibernate-dev] 6.0 - BasicType resolution

Love to get people's thoughts on https://hibernate.atlassian.net/browse/HHH-11391?focusedCommentId=88935=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-88935 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org

Re: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories

rling <gun...@hibernate.org> > wrote: > > > >> +1 The source JARs are the important thing here. > >> > >> Just tried out the JavaDoc view in Eclipse for the first time as > >> you're mentioning it. Can't say I find it overly useful nor that I've >

Re: [hibernate-dev] MultiCollectionOwnerIdentifierLoadAccess?

& attached > collection? > > Thanks, > Sanne > > > On 14 January 2017 at 20:21, Steve Ebersole <st...@hibernate.org> wrote: > > I'm curious if anyone sees value in > > a MultiCollectionOwnerIdentifierLoadAccess variant (or some more concise > > na

Re: [hibernate-dev] ORM 5.2.x: Deprecation of some Query methods?

Well to be clear these methods are "deprecated" simply by the fact that org.hibernate.Query itself being deprecated. All that said... - #scroll is not going away - #iterate I already started a discussion about earlier on the dev list. I personally would like to do away with it, but that needs

Re: [hibernate-dev] [Hibernate ORM] Javadoc missing in Maven repositories

I personally think that publishing Javadocs per artifact is silly so I do not do it for ORM. Its a limiting view. We already publish an "aggregated" Javadoc that (again imo) is far better. As you point out Sanne, we do publish sources to repo which at the IDE level is MUCH better On Mon, Jan

[hibernate-dev] Unbound type parameters and JPA metamodel

We are having an interesting discussion on https://github.com/hibernate/hibernate-orm/pull/1723 in regards to ${subject} I do think this is something we need to clarify within the EG. One thing I'd like to do is to have a public poll to see how people tend to view this. The main reason being

[hibernate-dev] MultiCollectionOwnerIdentifierLoadAccess?

I'm curious if anyone sees value in a MultiCollectionOwnerIdentifierLoadAccess variant (or some more concise name) of MultiIdentifierLoadAccess for bulk initializing a collection role based on their owner ids? ___ hibernate-dev mailing list

Re: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules

e same app using the later version will fail unless you rebuild the app. >>> BTW is Javassist Shadable, some of these libs can’t due to string referencing classnames and other fun tricks like that. >>> >>> Emmanuel >>> >>>> On 11 Jan 2017, at 17:35, Scott

Re: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules

I think the best option in terms of supporting legacy ORM version users would be to incorporate a change in those branches to shade/shadow Javassist into ORM specific packages (in hibernate-core). As I understand it, it is always ORM that does the enhancement, right Scott? On Wed, Jan 11, 2017

Re: [hibernate-dev] ScrollableResults and 6.0

Inline... On Tue, Jan 3, 2017 at 5:39 AM Gunnar Morling wrote: > 2017-01-03 11:57 GMT+01:00 Sanne Grinovero : > > Btw. we'd one Tuple type per number of returns, i.e. Tuple2, Tuple3 etc., > each with the right number of type arguments. As said I'm

Re: [hibernate-dev] ScrollableResults and 6.0

Inline... On Tue, Jan 3, 2017 at 4:58 AM Sanne Grinovero wrote: > It sounds great but I'm not sure it's possible? > No idea what this means. Its more than possible. In fact its already largely done. What do you mean? For example how would this handle projections?

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

if that might be unacceptable to people mapping very > large collections. > > Thanks, > Sanne > > > On 2 January 2017 at 15:41, Steve Ebersole <st...@hibernate.org> wrote: > > Christian and I chatted on HipChat. It seems his confusion stems > partially >

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

On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling <gun...@hibernate.org> wrote: > 2017-01-02 15:27 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > I realize now that Session#createFilter() is only geared towards > collections. So are you suggesting to only remove that metho

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

until 6.x. 6.0 is already getting beyond its initial scope and I's much rather get 6.0 released earlier and "oftener" :) On Mon, Jan 2, 2017 at 9:11 AM Steve Ebersole <st...@hibernate.org> wrote: > Well stop and think about it... What do you expect session.filter( new >

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

o mentioned, I > guess not. > I'd expect the collection or array to be filtered and projected in-memory > if possible, thus not executing a query unless needed for a lazy collection > or additional from clause. > > If that understanding is wrong, please help me understand what the p

Re: [hibernate-dev] ScrollableResults and 6.0

sorry for the noise. > > > Yoann Rodière <yo...@hibernate.org> > Hibernate NoORM Team > > On 2 January 2017 at 12:42, Steve Ebersole <st...@hibernate.org> wrote: > > org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2, > so it already has b

Re: [hibernate-dev] ScrollableResults and 6.0

duce an incompatible signature? > Not sure there would be many reactions, judging by the low activity on the > ticket, but who knows... > > Yoann Rodière <yo...@hibernate.org> > Hibernate NoORM Team > > On 27 December 2016 at 22:02, Steve Ebersole <st...@hibernate.org&g

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

n.createFilter(collection, "field = > 'abc%'").getResultList(); > > See my point? Since Hibernate can access the field directly, this works, > but with streams you'd need to expose the field via a getter so you can > filter for it. > > > Am 02.01.2017 um 09:25 sc

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

does when you consider that there might be no getter for a field. > With createFilter you could still filter the result list without exposing > direct access to the field via a getter. > > Am 02.01.2017 um 08:52 schrieb Steve Ebersole: > > Field-access would have zero bearing on t

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

s > strategy, but that could be a reason for keeping it around. > > Regards, > > Christian > > > Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > > As I have not been hearing hardly any feedback on these 6.0 design > > questions I have been trying to start, I'll be

Re: [hibernate-dev] 6.0 - Query literal rendering

seem ok, but how does that affect > subqueries? The same way? Or are subqueries the exception? > > Regards, > > Christian > > Am 31.12.2016 um 15:25 schrieb Steve Ebersole: > > Currently in 6.0 I have code in place to render query literals as > > PreparedStatement para

[hibernate-dev] 6.0 - Session#createFilter

As I have not been hearing hardly any feedback on these 6.0 design questions I have been trying to start, I'll be doing something different in this and any additional emails.. I'll state what I propose to do and if anyone has issue with it they can make a counter proposal. Otherwise I plan on

[hibernate-dev] 6.0 - Query literal rendering

Currently in 6.0 I have code in place to render query literals as PreparedStatement parameters, but only outside the SELECT clause. Many DBs require special handling for parameters defined in the SELECT clause general requiring to wrap in cast functions calls. I think it may be beneficial to

[hibernate-dev] AttributeConverter - 6.0

When I first added support for AttributeConverter I incorporated it into BasicType because that was really the only option at the time. As we move into 6.0 though I would like to consider moving this to the new Attribute model. What this means practically speaking is that we'd move

[hibernate-dev] ScrollableResults and 6.0

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

Re: [hibernate-dev] SQM - PoC design doc

:42 AM Steve Ebersole <st...@hibernate.org> wrote: > I should have been more clear as to why this is a problem :) > > The columns are resolved as the persisters are built. Later as we build > the SQL AST part of that process is resolving ColumnBindings. To do that > the Column

Re: [hibernate-dev] SQM - PoC design doc

Christian what do you mean by "case where returning the union-query as table would enable optimizations". On Wed, Dec 21, 2016 at 7:42 AM Steve Ebersole <st...@hibernate.org> wrote: > I should have been more clear as to why this is a problem :) > > The columns are r

Re: [hibernate-dev] SQM - PoC design doc

"duplicate" column objects? > > Am 21.12.2016 um 07:28 schrieb andrea boriero: > > I think it should return the Columns > > that reports the physical Table for its Table. > > > > On 20 Dec 2016 22:02, "Steve Ebersole" <st...@hibernate.or

Re: [hibernate-dev] SQM - PoC design doc

n Fri, Dec 16, 2016 at 10:15 PM Steve Ebersole <st...@hibernate.org> wrote: > I have pushed a newly updated version of the design.adoc bringing the > discussions up-to-date with the latest code/design. > > This PoC work is getting very far along and I really have not had

[hibernate-dev] SQM - PoC design doc

I have pushed a newly updated version of the design.adoc bringing the discussions up-to-date with the latest code/design. This PoC work is getting very far along and I really have not had much feedback. My concern is that this code is only going to become harder to review (more to look at) as

Re: [hibernate-dev] EntityGraph query spaces not applied to Query (HHH-11213)

It likely is not an issue. Query spaces only come into play with regards to restrictions. Since the EntityGraph is not part of the query proper restrictions cannot be based on it. That would be a scenario to try though... create a query restricting results based on some joined attribute and

Re: [hibernate-dev] Testing DB lock timeouts

ConnectionProvider mocking the Connection? To help there is org.hibernate.testing.jdbc.JdbcMocks On Tue, Dec 13, 2016 at 11:23 AM Radim Vansa wrote: > Hi, > > since hibernate-infinispan testsuite has been set on by default, > recently I've set myself to improve the

Re: [hibernate-dev] Update JDK 9 on ci.hibernate.org: JDK 9 build 148

Is this the build with the "disruptive change"? On Fri, Dec 9, 2016, 7:43 AM Davide D'Alto wrote: Hi, I just wanted to inform that I've updated the JDK 9 version on CI to build 148. Let me know if there are problems. Cheers, Davide

Re: [hibernate-dev] AutoCloseable is great.. what about JPA?

Personally I don't think dynamic-instantiations (ConstructorResults) are hacky at all. In fact I love dynamic-instantiations for all kinds of use cases. I wonder if your concern with them is their limited capabilities. For example, JPA does not define support for nesting dynamic-instantiations

Re: [hibernate-dev] AutoCloseable is great.. what about JPA?

he JPA EG is that there wasn't > any response to emails in months. We could at least create a JIRA issue for > this. My only concern is that the JPA Jira and other resources are hosted > on java.net which will be deactivated on April next year. > > Vlad > > On Fri, Dec 2, 2016 at 6:49 PM, Steve

Re: [hibernate-dev] AutoCloseable is great.. what about JPA?

But on Java 6 there is the hack we used to use. Using Closeable instead and Java 8 recognizing that as well. On Fri, Dec 2, 2016 at 10:48 AM Steve Ebersole <st...@hibernate.org> wrote: > +1 > > we should start collecting a list. And voila: > https://github.com/hibernate/hiber

Re: [hibernate-dev] AutoCloseable is great.. what about JPA?

+1 we should start collecting a list. And voila: https://github.com/hibernate/hibernate-orm/wiki/Post-JPA-2.1-proposals-working-doc :) On Fri, Dec 2, 2016 at 10:31 AM Sanne Grinovero wrote: > We updated several Hibernate APIs to allow using the > try-with-resources

Re: [hibernate-dev] Spring Cache integration

e implementor. > > I guess in an ideal world (or a new framework) you would no longer create a > cache abstraction instead relying on JCache. > > Regards, > Louis > > On Tue, Nov 22, 2016 at 5:41 PM Steve Ebersole <st...@hibernate.org> > wrote: > > &g

Re: [hibernate-dev] Spring Cache integration

rly good solutions they are > today. My fear is that even just to document eventual limitations, > we'd need to study them quite a bit, probably challenge them > empirically, which would require adding many more tests. > > Thanks, > Sanne > > > > On 21 November 2016 at 18

[hibernate-dev] Spring Cache integration

Someone just opened a PR to add support for Spring Cache as a second-level cache provider[1]. They implemented this by adding a new Hibernate module `hibernate-spring-cache` that essentially wraps Spring Cache as a JCache (apparently Spring Cache does not implement the JCache contracts). Part of

Re: [hibernate-dev] Correlating Java 1.8 Streams and ScrollableResults with database cursors

sh results. That too might mitigate some of my concern On Mon, Nov 21, 2016, 12:25 PM Sanne Grinovero <sa...@hibernate.org> wrote: > On 21 November 2016 at 18:17, Steve Ebersole <st...@hibernate.org> wrote: > > I had a discussion about this with Vlad on the PR and privately on > H

Re: [hibernate-dev] Correlating Java 1.8 Streams and ScrollableResults with database cursors

I had a discussion about this with Vlad on the PR and privately on HipChat. I personally am -1 on this as well. As you say Sanne the problem is "if you all think Hibernate should be able to figure this out automatically"... You would never be able to figure this out across all situations. On

[hibernate-dev] SQM - subqueries and order-by

SQL 92, 93 and 99 (i have not checked 2003) all limit order-by to only be allowable in the root query. Unfortunately the current HQL grammar allows subqueries to be ordered. So I wanted to start a discussion of whether we want to support this as we transition to SQM and 6.0. The real problem

Re: [hibernate-dev] Change in DB lock acquisition in ORM?

The change in exception type is new to 5.2 (merging HEM into core). IIRC you did not "see failures in hibernate-infinispan tests" because we had those disabled due to their ongoing intermittent failures. On Mon, Nov 21, 2016 at 5:46 AM Radim Vansa wrote: > Aha, that

Re: [hibernate-dev] Vibur DBCP connection pool

I replied on the Jira. I apologize - for some reason I did not receive notifications from that issue On Thu, Nov 10, 2016 at 6:21 PM Sanne Grinovero wrote: > Hi all, Steve in particular, > > there's a nice and friendly offer to integrate this connection pool in the >

Re: [hibernate-dev] Checkstyle checks in ORM

https://hibernate.atlassian.net/browse/HHH-11235 On Wed, Nov 9, 2016 at 9:22 AM Steve Ebersole <st...@hibernate.org> wrote: > Gradle does not have profiles. So you mean different tasks? > > > On Wed, Nov 9, 2016 at 9:20 AM Vlad Mihalcea <mihalcea.v...@gmail.com> >

Re: [hibernate-dev] Checkstyle checks in ORM

d) > and one for active developers. > > Given that I'm not sure what kind of checkstyle rules we are talking about. > > On Wed, Nov 9, 2016 at 2:15 PM, Steve Ebersole <st...@hibernate.org> > wrote: > > While developing the Byte Buddy Enhancer, Rafael ran into what I thnk

Re: [hibernate-dev] Checkstyle checks in ORM

What do you think about having different profiles? > One for new contributors (more relaxed) > and one for active developers. > > Given that I'm not sure what kind of checkstyle rules we are talking about. > > On Wed, Nov 9, 2016 at 2:15 PM, Steve Ebersole <st...@hibernate.org>

[hibernate-dev] Checkstyle checks in ORM

While developing the Byte Buddy Enhancer, Rafael ran into what I thnk is a valid problem in the ORM build. Namely the fact that we incorporate non-fatal Checktyle checks. In local builds this leads to a situation where it is extremely difficult for new contributors to find out what exactly they

Re: [hibernate-dev] [Hibernate Search] Added a test utility to assert produced log

Sweet. Good to know On Fri, Nov 4, 2016 at 9:30 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 4 November 2016 at 14:27, Steve Ebersole <st...@hibernate.org> wrote: > > I think we should consider creating a set of generic testing utils as a > > sep

Re: [hibernate-dev] [Hibernate Search] Added a test utility to assert produced log

I think we should consider creating a set of generic testing utils as a separate project. Things like LoggerInspectionRule, @ExpectedFailure, @BeforeClassOnce, @AfterClassOnce, @Skip, etc are generally useful I find On Fri, Nov 4, 2016 at 9:16 AM Sanne Grinovero wrote: >

Re: [hibernate-dev] HHH-11155 : problems updating lazy properties in lazy groups

Just be sure to consider custom SQL for loading and updates as it will affect many of the things discussed here. On Wed, Nov 2, 2016 at 8:49 AM Steve Ebersole <st...@hibernate.org> wrote: > It looks like I only adjusted the reading of values (SELECT) for > fetch-groups. > > U

Re: [hibernate-dev] HHH-11155 : problems updating lazy properties in lazy groups

It looks like I only adjusted the reading of values (SELECT) for fetch-groups. Updates should only consider initialized attributes. I had assumed that was already the case. The same is probably true for property-based optimistic locking as well. We should verify that feature as well On Wed,

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

> We can call it a bad deployment, however, at the same time, we don't > want to break application compatibility in a way that requires the > application to be cracked open and modified (even if the fix is just a > simple MANIFEST.MF change). > > On Thu, Oct 27, 2016 at 10:0

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

I would argue that that is a bad deployment. IMO if you supply your own Hibernate jars, you'd be responsible for supplying its dependency jars as well. Javassist is currently a non-optional dependency of ORM. On Thu, Oct 27, 2016 at 8:55 AM Scott Marlow wrote: > I remember

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

On Wed, Oct 26, 2016 at 8:33 PM Scott Marlow wrote: > On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling > wrote: > > Couldn't this be achieved by having the ORM module re-export the > Javassist > > module it depends on (in the module.xml of ORM, that is)?

Re: [hibernate-dev] dynamic instantiation queries

4 PM Sanne Grinovero <sa...@hibernate.org> wrote: > On 24 October 2016 at 21:49, Steve Ebersole <st...@hibernate.org> wrote: > > I'm not sure what you are getting at. This is a feature Hibernate has had > > for close to 15 years. It's not a "new feature", I'm

Re: [hibernate-dev] dynamic instantiation queries

of > any property of Person? > > Also wondering, if we expose query results as streams in the future, > would such a feature not become obsolete? > > > On 24 October 2016 at 20:38, Steve Ebersole <st...@hibernate.org> wrote: > > So Person is your entity, e.g.: &

[hibernate-dev] dynamic instantiation queries

Historically (well before JPA) HIbernate would handle dynamic instantiation queries in cases where one of the arguments being an entity-reference by passing just the entity's identifier rather than a complete reference to the entity. To be clear, I am talking about a query like: select new

Re: [hibernate-dev] 6.0 - Type redesign

To be more clear... I just meant that to date we have not discussed any plans for supporting java.sql.SQLType, not that we discussed it and decided not to support it. On Thu, Oct 20, 2016 at 1:27 PM Steve Ebersole <st...@hibernate.org> wrote: > On Wed, Oct 19, 2016 at 2:29 PM Jor

Re: [hibernate-dev] SQM - encoding type info into the tree

] https://github.com/sebersole/hibernate-orm-sqm-poc/blob/master/src/main/java/org/hibernate/persister/common/internal/DomainMetamodelImpl.java On Thu, Oct 6, 2016 at 12:19 PM Steve Ebersole <st...@hibernate.org> wrote: > Well there is then the ideological argument about this being a

Re: [hibernate-dev] 6.0 - Type redesign

On Wed, Oct 19, 2016 at 2:29 PM Jordan Gigov wrote: > I've been reading the wiki and email archives, and I have some notes > for what needs to be decided before it needs to become retrofitted. > After all, all that retrofitting is what the reason the types need to > be

Re: [hibernate-dev] Adding a Byte Buddy byte code provider to Hibernate

out the gate? On Wed, Oct 12, 2016 at 3:36 PM Steve Ebersole <st...@hibernate.org> wrote: > oops, guess this works better if I send it to the group ;) > > > On Wed, Oct 12, 2016 at 1:09 PM Steve Ebersole <st...@hibernate.org> > wrote: > > Since this is gaini

Re: [hibernate-dev] HBM migration suggestions

Can I take at least a sneak-peek into the tool? > > > > On Monday, October 10, 2016 9:56 AM, Steve Ebersole <st...@hibernate.org> > wrote: > > > Do you have a tool to convert from orm.xml to annotations? The reason I > ask is that we are pretty far along in the develop

Re: [hibernate-dev] HBM migration suggestions

Do you have a tool to convert from orm.xml to annotations? The reason I ask is that we are pretty far along in the development of a hbm.xml -> orm.xml tool, with the caveat that the orm.xml is an "extended" form of the JPA orm.xml weaving in Hibernate-specifics. So it would depend on whether any

Re: [hibernate-dev] SQM - encoding type info into the tree

we lose anything. We'd just do it later. On Thu, Oct 6, 2016 at 9:41 AM andrea boriero <and...@hibernate.org> wrote: > I'm inclined towards the second option but not sure if it can have > limitations compared to the first one. > > On 5 October 2016 at 22:59, Steve Ebersole &l

Re: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project}

the proposed > scheme. > > On Wed, 5 Oct 2016, 23:44 Steve Ebersole, <st...@hibernate.org> wrote: > > The grouping is certainly "nice". But given the possibility of > difficulties renaming the groupId could have for users I'd not make this > change just because i

Re: [hibernate-dev] Dialect#remapSqlTypeDescriptor

Actually I am finding a lot of references online that calling Oracle procs/functions that define PL/SQL BOOLEAN arguments/returns cannot be done via CallableStatement. This is going to take some investigation. On Fri, Sep 30, 2016 at 7:10 PM Steve Ebersole <st...@hibernate.org>

Re: [hibernate-dev] Dialect#remapSqlTypeDescriptor

Specifically, does anyone know how Oracle driver reports ParameterMetaData#getParameterType for CallableStatement arguments that are defined as PL/SQL BOOLEAN types? On Fri, Sep 30, 2016 at 7:02 PM Steve Ebersole <st...@hibernate.org> wrote: > We may be able to look at the procedures

[hibernate-dev] mixing named and positional parameters

The JPA spec specifically says: Either positional or named parameters may be used. Positional and named parameters must not be mixed in a single query. I was thinking about how it does not make sense to mix these in a query (its confusing) and went looking to see what, if anything, the spec

[hibernate-dev] Dialect#remapSqlTypeDescriptor

TLDR: Should we adjust to allow Dialect to know the "context" of where the remapping is requested? Ah Oracle... So this comes from the fact that Oracle does not support a BOOLEAN datatype. Well kind of. It does not support a BOOLEAN datatype in its "SQL engine". However, in PL/SQL it does in

Re: [hibernate-dev] ORM and Java 9

4:49, "Scott Marlow" <smar...@redhat.com> wrote: > >> >> >> On 09/27/2016 08:15 PM, Steve Ebersole wrote: >> > It seems like Shigeru and team have Javassist Java 9 compatible now. >> Per >> > https://issues.jboss.org/browse/JASSIST-261 I ha

Re: [hibernate-dev] HHH-9329

Christian Beikov < christian.bei...@gmail.com> wrote: > Is the fix I proposed in my PR( > https://github.com/hibernate/hibernate-orm/pull/1561) non-compatible? > Did I miss discussion about that somewhere or didn't you have time to > review that yet? > > > Am 23.09

<    2   3   4   5   6   7   8   9   10   11   >