Re: [hibernate-dev] HHH-9329

hat question ^^ > Well then I'll try upgrading to 5.2 and hope for the best :) > > So are you considering merging that to 5.2 then? > > > > Am 23.09.2016 um 18:36 schrieb Steve Ebersole: > > Nope. You asked: > > Are the problems with Hibernate 5.1+ and Infinispan

Re: [hibernate-dev] HHH-9329

some other "Hibernate 5.1+ and Infinispan" problem, then I guess you could have been more specific ;) On Fri, Sep 23, 2016 at 11:33 AM Christian Beikov < christian.bei...@gmail.com> wrote: > Wrong thread? > > > Am 23.09.2016 um 17:53 schrieb Steve Ebersole: &

Re: [hibernate-dev] HHH-9329

ov > > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > > > Thanks, I know that it's a beauty ^^ > > Hope this can get into all 5.x branches? > > > > Regards, > > Christian > > Am 20.09.2

Re: [hibernate-dev] NativeQuery and parameters

iguredBase; Personally I think it should be the latter. It is pretty normal for legacy app upgrading to have to set some "use legacy behavior" flags. What do y'all think? [1] https://gist.github.com/sebersole/b13c11a9f7d55b84be6b4371e0259bc5 On Wed, Sep 21, 2016 at 2:03 PM Steve Ebersole

Re: [hibernate-dev] JPA Jira project

It is so... :) On Thu, Sep 22, 2016, 3:11 PM Gail Badner <gbad...@redhat.com> wrote: > +1 > > On Thu, Sep 22, 2016 at 6:30 AM, andrea boriero <and...@hibernate.org> > wrote: > >> +1 >> >> On 22 September 2016 at 14:18, Steve Ebersole <st...@hi

[hibernate-dev] JPA Jira project

I propose that we limit who has the ability to create issues in the Hibernate Jira JPA project. Users routinely create issues there incorrectly, rather than the ORM (HHH) project. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org

Re: [hibernate-dev] NativeQuery and parameters

Well therein lies (yet another) minor rub On Thu, Sep 22, 2016 at 7:06 AM Steve Ebersole <st...@hibernate.org> wrote: > Well therein lies a minor rub in having split SQM out from ORM. > Specifically if the "compliance violation" occurs in the HQL/JPQL/Criteria > quer

Re: [hibernate-dev] NativeQuery and parameters

, so they can find the solution easier. > > 2016-09-21 22:03 GMT+03:00 Steve Ebersole <st...@hibernate.org>: > >> One additional thing we might consider is possibly unifying this 0- and >> 1- based mismatch wrt JDBC-style parameters. >> >> In Hibernate's APIs these

Re: [hibernate-dev] NativeQuery and parameters

at 1:40 PM Steve Ebersole <st...@hibernate.org> wrote: > I never said anything about dropping support for named and positional > parameters in native queries. > > I simply mentioned leveraging the new "JPA strict compliance" stuff I am > adding to 6.0. The

Re: [hibernate-dev] NativeQuery and parameters

ers are only required to support > positional, but not forbidden from supporting other. > > 2016-09-21 3:59 GMT+03:00 Steve Ebersole <st...@hibernate.org>: > >> In the interest of questioning everything, just to make sure we are all on >> the same page, Hibernate's support

Re: [hibernate-dev] Limited history in HipChat

> The multi client including phone is an awesome feature for my flow for > example. > > I’ve contacted Samuel and he offered options to give it a shot. > > Emmanuel > > > > On 21 Sep 2016, at 15:20, Steve Ebersole <st...@hibernate.org> wrote: > > > > I t

Re: [hibernate-dev] Build time downloads of ORM itself during an ORM clean build?

gradle#L22 > > 2016-09-21 17:59 GMT+03:00 Steve Ebersole <st...@hibernate.org>: > >> By "package buildscripts" do you mean the buildSrc module? That should >> not be the case. >> >> If not, what do yo mean by "package buildscripts"?

Re: [hibernate-dev] Build time downloads of ORM itself during an ORM clean build?

By "package buildscripts" do you mean the buildSrc module? That should not be the case. If not, what do yo mean by "package buildscripts"? On Wed, Sep 21, 2016 at 9:47 AM Jordan Gigov wrote: > Well, the CI would generally have a local snapshot to use, instead of >

Re: [hibernate-dev] Cannot build branch 5.1

<paranoia...@gmail.com> wrote: > Yes, clean worked. Thank you Steve and sorry about the noise - I'm not > very familiar with gradle. > > 2016-09-21 17:28 GMT+03:00 Steve Ebersole <st...@hibernate.org>: > >> Try a clean? >> >> >> On Wed, Sep 21, 20

Re: [hibernate-dev] Cannot build branch 5.1

Try a clean? On Wed, Sep 21, 2016 at 9:23 AM Petar Tahchiev <paranoia...@gmail.com> wrote: > Yeah really strange - branch 5.0 and master (5.2.3) I can build without a > problem, but 5.1 shows that error. > > 2016-09-21 17:17 GMT+03:00 Steve Ebersole <st...@hiberna

Re: [hibernate-dev] Cannot build branch 5.1

Strange. It is working in CI: http://ci.hibernate.org/view/ORM/job/hibernate-orm-5.1-h2/ On Wed, Sep 21, 2016 at 9:03 AM Petar Tahchiev wrote: > Hi guys, > > I'm trying to build the 5.1 branch with "./gradlew publishToMavenLocal" but > I get the following error: > >

Re: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and Transaction status

non-JTA environment. I guess we need to think > what should we do with the transaction status because now it's still > active, but if we try to rollback, we'll get an exception because the > connection was closed. > > Vlad > > On Wed, Sep 21, 2016 at 4:30 PM, Steve Ebersole &

Re: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and Transaction status

Sorry, *was* only valid for JTA. As you mentioned we handle this differently today. On Wed, Sep 21, 2016 at 8:29 AM Steve Ebersole <st...@hibernate.org> wrote: > DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc. > > On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihal

Re: [hibernate-dev] AvailableSettings.DISCARD_PC_ON_CLOSE and Transaction status

DISCARD_PC_ON_CLOSE, as a concept, is only valid for JTA iirc. On Wed, Sep 21, 2016 at 8:11 AM Vlad Mihalcea wrote: > Hi, > > While reviewing and adding a test case for > https://hibernate.atlassian.net/browse/HHH-11120, > I realized that if we enable the

Re: [hibernate-dev] Limited history in HipChat

I thought we had some sort of non-basic license already. Isn't that why we need to explicitly invite people to be non-Guest? Anyway, I agree wrt HipChat being more or less useless. I've been saying that for a while now. Yes the GitHub and Jira and social integrations *can be* nice (they can

Re: [hibernate-dev] HHH-9329

I took a quick look. I'd prefer to see better solution as we migrate to SQM; but for 5.x, given how Hibernate generates SQL there, I am not sure how else you would possibly do this On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea wrote: > Thanks, > > I'm going to review

Re: [hibernate-dev] Lambda usage to run a code block in an isolated transaction

n isolated, boolean transacted); And then, Executor defines: T doInSession(Function<Session,T> work) so all-told: factory.getExecutor( true, true ).doInSession( session -> ... ) As Sanne says though we need a better name for Executor On Wed, Sep 14, 2016 at 3:17 PM Steve Ebersole <st..

Re: [hibernate-dev] Lambda usage to run a code block in an isolated transaction

Also, why do you keep defining this in terms of Session, rather than SessionFactory? On Wed, Sep 14, 2016 at 3:01 PM Steve Ebersole <st...@hibernate.org> wrote: > "Better" according to whom? ;) > > I personally very much dislike the kind of API explosion t

Re: [hibernate-dev] Lambda usage to run a code block in an isolated transaction

The problem with "execute in isolation" here is that the "isolation" aspect refers to being isolated from any current transaction. It says nothing about whether that stuff-to-execute should itself be transacted. This is why, for example, you see IsolationDelegate accept a `transacted` boolean

Re: [hibernate-dev] Usage of Session#getTransaction() being banned from the Hibernate Search code

That would be my personal opinion. On Wed, Sep 14, 2016 at 11:24 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 14 September 2016 at 17:16, Steve Ebersole <st...@hibernate.org> wrote: > > To be clear, I mean "never end the transaction locally". It's

Re: [hibernate-dev] Usage of Session#getTransaction() being banned from the Hibernate Search code

To be clear, I mean "never end the transaction locally". It's like any resource handling... if you start/begin/open something you should stop/end/close it. IMHO. On Wed, Sep 14, 2016 at 11:15 AM Steve Ebersole <st...@hibernate.org> wrote: > Yes, it was intentional. As yo

Re: [hibernate-dev] Usage of Session#getTransaction() being banned from the Hibernate Search code

from you if this was intentional as you seemed to suggest > over chat that the accessTransaction() method was to be a drop-in > replacement for the previous semantics of getTransaction. > > Secondarily, when it comes to the "transaction.commit()" I'm having no > exception and it seems

Re: [hibernate-dev] 6.0 - ResultTransformer

BTW... https://hibernate.atlassian.net/browse/HHH-11104 On Tue, Sep 13, 2016 at 7:05 PM Steve Ebersole <st...@hibernate.org> wrote: > Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both > expect to get the root selection aliases and would naturally expect thos

Re: [hibernate-dev] 6.0 - ResultTransformer

gher precedence" (it defines the result type) it ought to win that battle. But then that is inconsistent for TupleTransformer. IMO either we let Tuple consume the aliases or we disallow this combo. On Tue, Sep 13, 2016 at 6:00 PM Steve Ebersole <st...@hibernate.org> wrote: > So he

Re: [hibernate-dev] 6.0 - ResultTransformer

is. In fact, in 6.0 a dynamic-instantiation is no different that other selectable expressions. On Tue, Sep 13, 2016 at 9:19 AM Steve Ebersole <st...@hibernate.org> wrote: > So again, this all boils down to the interplay with > (Result|Tuple|ResultList)Transformer, dynamic instantiations,

Re: [hibernate-dev] Usage of Session#getTransaction() being banned from the Hibernate Search code

NIce! I never knew of this plugin, but there is a Gradle plugin for it as well. On Tue, Sep 13, 2016 at 9:33 AM Sanne Grinovero wrote: > Since Hibernate ORM 5.2, the method getTransaction() on Session needs > to behave according to EntityManager spec, which implies that it

Re: [hibernate-dev] 6.0 - ResultTransformer

leTransformer returns. Any other specific combos we should clarify? [1] I am using the new TupleTransformer and ResultListTransformer breakdowns I have defined on 6.0 : https://gist.github.com/sebersole/bc721caa20a5e4a97cbde44567b0b2ea On Tue, Sep 13, 2016 at 8:52 AM Steve Ebersole <st...@hib

Re: [hibernate-dev] 6.0 - ResultTransformer

On Tue, Sep 13, 2016 at 5:23 AM Emmanuel Bernard wrote: > My preference would be to keep some form of resultTransformer around, > especially the first method that is redundant. > > And it's mainly because it is very easy to write one and plug. The HQL > based

Re: [hibernate-dev] 6.0 - ResultTransformer

On Tue, Sep 13, 2016 at 2:26 AM Gunnar Morling wrote: > > Between dynamic-instantiation, Tuple-handling... > > To be sure, WDYM by "tuple-handling"? > javax.persistence.Tuple So I gave just one example earlier of how all of these things do not necessarily fit together in

Re: [hibernate-dev] 6.0 - ResultTransformer

ransformer( () -> ... ) ... And what if they dont match necessarily, like: session.createQuery( "select new DTO(...) ...", Tuple.class ) .setTupleTransformer( () -> ... ) On Mon, Sep 12, 2016 at 9:17 AM Steve Ebersole <st...@hibernate.org> wrote: > Gail, IIRC o

Re: [hibernate-dev] 6.0 - ResultTransformer

Gail, IIRC one of these methods causes problems with regards to query result caching. Do I remember that correctly? And if so, do you remember which one? I'd guess #transformTuples, but I forget the details. On Mon, Sep 12, 2016 at 6:36 AM Steve Ebersole <st...@hibernate.org> wrote:

Re: [hibernate-dev] 6.0 - ResultTransformer

a Recursive CTE and I wanted the results to > be assembled back in a N-level hierarchy, starting from a Root node. > > On Mon, Sep 12, 2016 at 1:58 PM, Steve Ebersole <st...@hibernate.org> > wrote: > >> The former though is specifically what I see no use for. Do you have

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

uch about this change. > > Vlad > > On Mon, Sep 12, 2016 at 6:02 AM, Steve Ebersole <st...@hibernate.org> > wrote: > >> Another method I'd like to drop is Session#createFilter. This is method >> is >> easy enough to replace with a call to createQuery instead.

Re: [hibernate-dev] 6.0 - ResultTransformer

not > possible today. > > Vlad > > On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole <st...@hibernate.org> > wrote: > >> Another legacy concept I'd like to revisit as we move to 6.0 is the >> Hibernate ResultTransformer. I'd argue that ResultTransformer is no >

[hibernate-dev] 6.0 - Session#createFilter

Another method I'd like to drop is Session#createFilter. This is method is easy enough to replace with a call to createQuery instead. Longer term I can also see Stream or DSL support from our persistent collections to provide the similar capabilities. But for now its just no real benefit for

[hibernate-dev] 6.0 - ResultTransformer

Another legacy concept I'd like to revisit as we move to 6.0 is the Hibernate ResultTransformer. I'd argue that ResultTransformer is no longer needed, especially in it's current form. Specifically, ResultTransformer defines 2 distinct ways to transform the results of a query: 1.

Re: [hibernate-dev] Continue "parameter list" support?

her: 1. validate that on the ORM side 2. provide some "object view" of a function to SQM (via ConsumerContext) to check that. (2) is nice because it would also allow us to understand the result-type of a function also. On Sat, Sep 10, 2016 at 10:02 AM Steve Ebersole <s

Re: [hibernate-dev] Continue "parameter list" support?

used as argument to not allow multi-values, .. ); sqmFunctionArgumentParameter.allowMultiValues( false ); } } On Sat, Sep 10, 2016 at 9:53 AM Steve Ebersole <st...@hibernate.org> wrote: > We are actually getting close to being able to wholly determine FUNCTION > syntacti

Re: [hibernate-dev] Continue "parameter list" support?

eter is multi-valued or not. > If you want to make the semantics independent of the functions, then you > must introduce a syntax of course. I was just trying to suggest > something that is mostly compatible to the way it is right now. > > Am 10.09.2016 um 16:10 schrieb Steve Ebersole: > &

Re: [hibernate-dev] Continue "parameter list" support?

Just to follow up on something I said below... On Sat, Sep 10, 2016 at 9:27 AM Steve Ebersole <st...@hibernate.org> wrote: > Right, that would mean adjusting SQLFunction to report whether the > arguments are "varargs". I plan on looking to change the SQLFunction > con

Re: [hibernate-dev] Continue "parameter list" support?

On Sat, Sep 10, 2016 at 9:08 AM Christian Beikov wrote: > Will there be a way in SQM to specify the argument types of a function? > We have that today. Not so much the "varargs" aspect, but if the user registered that function as a SQLFunction then we would

Re: [hibernate-dev] Continue "parameter list" support?

WRT the "double caches"... yes there will be a few caches. I'm not understanding what that has to do with defining a clear semantic for a particular language element. Look, to me this whole thing boils down to the fact that JPA defines specific/limited support for this "collection valued

Re: [hibernate-dev] Continue "parameter list" support?

ches e.g. > > * SQMCache<HQL, SQMQuery> > * SQLCache<SQMQuery, Cache<ParameterMetadata, SQLString>> > > Can you please elaborate what you think is problematic about something > like that? > > Am 09.09.2016 um 23:39 schrieb Steve Ebersole: > >

Re: [hibernate-dev] Continue "parameter list" support?

; wrote: > Hmm I think I understand what you mean now. How would you do parameter > expansion in SQM? Or will the result after a parameter expansion not be > cached? > > > Am 09.09.2016 um 23:35 schrieb Steve Ebersole: > > Not any particular reason, HHH-10502 or otherwise.

Re: [hibernate-dev] Continue "parameter list" support?

of the language so that as much semantic as possible is available statically (from the Query itself, and from Session/SessionFactory). On Fri, Sep 9, 2016 at 4:35 PM Steve Ebersole <st...@hibernate.org> wrote: > Not any particular reason, HHH-10502 or otherwise. Its more a general > ques

Re: [hibernate-dev] Continue "parameter list" support?

uld probably be even > more work because then you would have to exectue the query multiple times. > > I just don't think that removing this feature will bring any benefits. > > Regards, > Christian > > Am 09.09.2016 um 22:30 schrieb Steve Ebersole: > > BTW, JPA

Re: [hibernate-dev] Continue "parameter list" support?

BTW, JPA really requires that we support accepting multi-valued bindings for parameters through #setParameter. Yet another reason to do away with #setParameterList. On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole <st...@hibernate.org> wrote: > WRT the "collection_valued_input_

Re: [hibernate-dev] Continue "parameter list" support?

gt; On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero <and...@hibernate.org> > wrote: > >> I am also not able to figure out another use case than the IN predicate so >> I am for always considering IN predicates as multi-valued. >> >> On 9 September 2016 at 14:20,

[hibernate-dev] Continue "parameter list" support?

To be clear, this is the feature that lets you define a query like: select ... from Person p where p.name in (:names) And then bind varied multiple values into that single parameter holder: query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe" } ); query.setParameterList(

Re: [hibernate-dev] Hibernate mapping deprecation

Yes that will happen: https://github.com/hibernate/hibernate-orm/wiki/Roadmap7.0 But not any time soon. Basically we will support an "extended" version of the JPA orm.xml schema that introduces Hibernate specific concepts. Historically we stayed away from that because IMO it really is against

Re: [hibernate-dev] Java 9 upgraded on CI : build b134

We could update to a WF snapshot supporting Java 9 and possibly re-enable those tests. I have not kept up with Javassist which is the other one we have issue with in ORM, both directly and through Hikari CP On Mon, Sep 5, 2016, 3:13 PM Sanne Grinovero wrote: > Hi all, > >

Re: [hibernate-dev] Hibernate ORM repository using modules?

> > > https://github.com/hibernate/hibernate-orm/commit/e75b017a4664d158e1197d19dca204273c4a2d66#diff-b82723dbef3c19115685625a04d6071dR1 > > I guess it's a mistake... I'll delete it soon, ping me if I shouldn't. > > Thanks, > Sanne > > > On 1 September 2016 at 22:37, Steve E

Re: [hibernate-dev] Hibernate ORM repository using modules?

Nope On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero wrote: > Hi all, > the Infinispan/Hibernate integration test - which is run by the > Infinispan team and uses TeamCity instead of Jenkins - is failing with > the below cryptic error. > > Did the ORM switch to using Git

Re: [hibernate-dev] Centralized access to "bootstrap only" resources

i.SessionFactoryServiceInitiator impls > > Yes, OGM does. Though I'm not too concerned about such change, it should > be easy for us to adjust and at this point we don't aim > for compatibility with several ORM (major) versions. > > 2016-09-01 4:09 GM

Re: [hibernate-dev] Supporting timezone in Timestamp Type

ered why in the last email discussion we had about this a few months ago. Now your app could do all this... map the @Temporal and then map the TZ and apply them in memory. On Thu, Sep 1, 2016 at 5:52 AM Steve Ebersole <st...@hibernate.org> wrote: > I think your example is actua

Re: [hibernate-dev] Centralized access to "bootstrap only" resources

at 5:18 AM andrea boriero <and...@hibernate.org> wrote: > I'm fine with combining native and JPA events handling, about the second > point, ideally I would change the signature but due to the problems you > listed I vote for the in-line solution. > > On 30 August 2016 at 19:2

Re: [hibernate-dev] Supporting timezone in Timestamp Type

We discussed this on HipChat, but for the benefit of all on this discussion... Part of this (the original report) speaks to a difference in how we map (org.hibernate.type.Type) java.time temporal versus a java.util temporal - specifically java.util.Calendar. When we are passed a Calendar (the

Re: [hibernate-dev] HHH-10478 : OperationContext

before I integrate, or should I > integrate as is? > > Thanks, > Gail > > On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole <st...@hibernate.org> > wrote: > >> I do like the proposal. Awesome job on the gist. I'll look over the >> code over the next few d

Re: [hibernate-dev] Centralized access to "bootstrap only" resources

ue, Aug 30, 2016 at 8:50 AM Steve Ebersole <st...@hibernate.org> wrote: > On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero <sa...@hibernate.org> > wrote: > >> On 30 August 2016 at 10:09, Emmanuel Bernard <emman...@hibernate.org> >> wrote: >> > I am

Re: [hibernate-dev] Centralized access to "bootstrap only" resources

On Tue, Aug 30, 2016 at 6:27 AM Sanne Grinovero wrote: > On 30 August 2016 at 10:09, Emmanuel Bernard > wrote: > > I am not sure if that is still relevant but in the past, either HSEARCH > > or HV were keeping the ReflectionManager around to use it

Re: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated on native-enum supporting datastores

Aug 26, 2016 at 7:49 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 26 August 2016 at 12:51, Steve Ebersole <st...@hibernate.org> wrote: > > PGSQL has some enum support I know. The problem has always been that > they > > are mapped to "special" ty

Re: [hibernate-dev] Mapping JPA's @MapKeyEnumerated and @Enumerated on native-enum supporting datastores

PGSQL has some enum support I know. The problem has always been that they are mapped to "special" type codes (think java.sql.Types) which makes it difficult to work with in ORM. On Fri, Aug 26, 2016 at 6:18 AM Gunnar Morling wrote: > > I guess we could, but it's sad

Re: [hibernate-dev] 5.3?

your time plan for releasing 6.0? In other words, how much > longer would people have to way for the Money support if it wouldn't be > released as part of another 5.x release? > > 2016-08-18 21:54 GMT+02:00 Steve Ebersole <st...@hibernate.org>: > >> Especially because it is h

Re: [hibernate-dev] 5.3?

<and...@hibernate.org> wrote: > I would prefer to postpone JavaMoney/Moneta integration to 6.0. > In case this is not possible I agree with including also the CDI work. > > On 17 Aug 2016 21:56, "Steve Ebersole" <st...@hibernate.org> wrote: > >> For whatev

Re: [hibernate-dev] 5.3?

ure dev on top of... not backwards... not to multiple places... [1] https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team On Thu, Aug 18, 2016 at 7:42 AM Scott Marlow <smar...@redhat.com> wrote: > > On 08/17/2016 03:54 PM, Steve Ebersole wrote: > > For whate

[hibernate-dev] 5.3?

For whatever reason discussion about JavaMoney/Moneta support has heated up again the past few days. Is this important enough to warrant a 5.3 release? If we are going to cut a 5.3 I'd also suggest we include the recent work I did in regards to CDI support as well[1]. [1]

Re: [hibernate-dev] Locale to/from String

We could also redo our toString support to support "__ch123" if we want. I just think its better to standardize if we are talking externalizations. On Fri, Aug 12, 2016 at 8:47 PM Steve Ebersole <st...@hibernate.org> wrote: > I have had a comment in LocaleType for quite s

[hibernate-dev] Locale to/from String

I have had a comment in LocaleType for quite some time to convert fromString handling to use the Locale.Builder introduced in Java 7. As part of the 6.0 work I took a quick look at this. I think we handle this incorrectly for certain cases currently. Currently we implement toString(Locale) via

Re: [hibernate-dev] Build failure when building 5.1.1.Final

n 25.40-b25) > OS: Linux 3.19.8-100.fc20.x86_64 amd64 > > > On Fri, Aug 12, 2016 at 3:16 PM, Steve Ebersole <st...@hibernate.org> > wrote: > >> Which version of Gradle are you using? >> >> On Fri, Aug 12, 2016 at 4:51 PM Gail Badner <gbad...@r

Re: [hibernate-dev] Build failure when building 5.1.1.Final

Which version of Gradle are you using? On Fri, Aug 12, 2016 at 4:51 PM Gail Badner wrote: > I'm getting a build failure. [1] > > Unless someone gets back to me shortly to help, I will have to postpone > releasing 5.1.1.Final until Monday. > > Regards, > Gail > > [1] > POM

[hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-h2-JDK9 #317

ter-h2-JDK9 #317 To: <and...@hibernate.org>, <st...@hibernate.org>, <ch...@hibernate.org> See <http://ci.hibernate.org/job/hibernate-orm-master-h2-JDK9/317/changes> Changes: [Steve Ebersole] HHH-11024 - Exception still thrown when dropping schema with a managed [Steve E

Re: [hibernate-dev] Treat support

Hey Christian, In general terms, one of the items on the docket for SQM is better TREAT support; but there is a lot that goes into that statement. One aspect is what we support in the parser properly in terms of recognition. Another is how this translates into the generates SQL query. All of

Re: [hibernate-dev] 6.0 - Type redesign

some last week, and Chris and Andrea agreed in principle. I am going to play around with this approach some this week. On Fri, Jul 22, 2016 at 2:22 PM Steve Ebersole <st...@hibernate.org> wrote: > On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emman...@hibernate.org> > wrote:

Re: [hibernate-dev] SchemaCreatorImpl always creating a poolable sequence

, 2016 at 7:11 AM Steve Ebersole <st...@hibernate.org> wrote: > Moving this functionality into the Exporter is the correct answer. > Eventually those DIalect methods will go away. > > > On Sat, Jul 30, 2016 at 3:32 AM Mark Rotteveel <m...@lawinegevaar.nl> > wrote:

Re: [hibernate-dev] Preparing for 5.0.10 and 5.1.1 releases

Do you need me to do anything in regards to HHH-10896 for these? On Fri, Jul 29, 2016 at 6:55 PM Gail Badner wrote: > I'm wrapping things up to release 5.0.10 and possibly 5.1.1 this weekend. > > Please do not push any commits to 5.0 or 5.1 branches. > > Thanks, > Gail >

Re: [hibernate-dev] SchemaCreatorImpl always creating a poolable sequence

Moving this functionality into the Exporter is the correct answer. Eventually those DIalect methods will go away. On Sat, Jul 30, 2016 at 3:32 AM Mark Rotteveel <m...@lawinegevaar.nl> wrote: > On 28-7-2016 18:07, Steve Ebersole wrote: > > I do think this is an error. I think

Re: [hibernate-dev] SchemaCreatorImpl always creating a poolable sequence

I do think this is an error. I think the proper fix is to first make use of Exporter#getSqlCreateStrings via Dialect#getSequenceExporter. >From there, either: 1. Change the standard Exporter to look at Dialect#supportsPooledSequences and deciding which Dialect#getCreateSequenceStrings

Re: [hibernate-dev] multiLoad support

it this way to also handle de-duplication which is a related, reported bug. On Mon, Jul 25, 2016 at 3:01 PM Sanne Grinovero <sa...@hibernate.org> wrote: > On 25 July 2016 at 19:55, Steve Ebersole <st...@hibernate.org> wrote: > > See inline... > > > > > > On Mon, Jul

[hibernate-dev] multiLoad support

I wanted to start a consolidated discussion about multi-load support. This relates to a few Jiras, questioning a few different aspects of its current behavior: https://hibernate.atlassian.net/browse/HHH-10984 https://hibernate.atlassian.net/browse/HHH-10617 Basically this comes down to the

Re: [hibernate-dev] 6.0 - Type redesign

On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard wrote: An alternative that I can think of is as follows. I'm assuming that the > data that needs to be contextualized by the path is mapping in nature or > at least not at all represented in the JPA types. > Each (JPA) type

Re: [hibernate-dev] 6.0 - Type redesign

's not the case. > > On Fri 2016-07-22 14:59, Steve Ebersole wrote: > > Some preliminary thoughts are inline. Like I said in the earlier reply I > > am still trying to distill this in total. > > > > On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard <emman...@hibe

Re: [hibernate-dev] 6.0 - Type redesign

Some preliminary thoughts are inline. Like I said in the earlier reply I am still trying to distill this in total. On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard wrote: > The good news is that I am following you :D > > I think one of the option is some API to which

Re: [hibernate-dev] 6.0 - Type redesign

> int span = esa.getPhysicalInfo().getColumnSpan(); > > } > > } > >} > > } > > > > Hopefully, JPA does not mandate == between different types. > > > > A question I have is how navigable and easy such API would be for a >

Re: [hibernate-dev] 6.0 - Type redesign

Vlad and I already spoke about some form of native (or at least more easily user defined) support for SQL ARRAY types. However, I do not know that that will extend to ARRAYs of entities. That said... all the methods to read a value on Type will be passed a Session. I think that was a mistake in

Re: [hibernate-dev] 6.0 - Type redesign

Put another way, I think the problem (and probably the solution) here is similar to JPA's Bindable (and Path) concept. On Thu, Jul 21, 2016 at 2:27 PM Steve Ebersole <st...@hibernate.org> wrote: > One goal of the redesign is to build more friendly, easy-to-follow > contrac

Re: [hibernate-dev] 6.0 - Type redesign

well as an "Attribute" without mapping information. I will be working on some proposals for ways to do this over the next week or so. And maybe y'all see a solution easier than I do (I fear I may not be seeing the forest through the trees atm). On Thu, Jul 21, 2016 at 7:49 AM Steve

Re: [hibernate-dev] 6.0 - Type redesign

I am working on a larger response to some current challenges, but here is a quick response to your specific points... On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard wrote: > > BasicType does not handle multiple column and compositeType is the > mebedded case. How

Re: [hibernate-dev] "Awaiting Testcase" transition

something I just wrote. On Sun, Jul 17, 2016 at 9:27 PM Chris Cranford <ch...@hibernate.org> wrote: > +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 "

Re: [hibernate-dev] 6.0 persister redesign

BTW, I started a design proposal wiki for this work: https://github.com/hibernate/hibernate-orm/wiki/6.0-persister-redesign ATM this is very basic initial thoughts. On Sat, Jul 16, 2016 at 7:55 AM Steve Ebersole <st...@hibernate.org> wrote: > Along with the Type redesign in 6.0 we

[hibernate-dev] "Awaiting Testcase" transition

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] 6.0 persister redesign

Along with the Type redesign in 6.0 we will need to do some redesigning of the persister contracts. I'd like to start collaborating on those changes with the ongoing 6.0 wip work. I plan on having a design meeting in the "Hibernate ORM" HipcHat room on Monday around 12 pm Central US time for

Re: [hibernate-dev] Can an attribute annotated with @PrimaryKeyJoinColumn be optional?

You mean nullable? If so, no. On Mon, Jul 11, 2016 at 5:21 PM Gail Badner wrote: > I know that a simple ID cannot be optional. Can attributes making up a > composite ID be optional? > > HHH-10929 concerns an optional attribute annotated with > @PrimaryKeyJoinColumn. Is this

Re: [hibernate-dev] Starting 5.1.0 release

Also, does anyone know if creating symlinks via sftp works against the doc server? On Fri, Jul 8, 2016 at 10:16 AM Steve Ebersole <st...@hibernate.org> wrote: > Reviving this to finish the discussion about creation of the `current` > symlink... > > I think we can actually

Re: [hibernate-dev] Starting 5.1.0 release

leases too). For example: 5.2.0.Final, 6.0.0.Final, 6.1.0.Final, etc. WDYT? On Wed, Feb 10, 2016 at 4:25 PM Steve Ebersole <st...@hibernate.org> wrote: > Maybe the better option is to have the build simply upload to the > versioned docs dir (orm/5.0, orm/5.1, etc) and to manage the `curr

Re: [hibernate-dev] "matching" table/column names (and naming strategies)

On Thu, Jul 7, 2016 at 3:58 AM andrea boriero <and...@hibernate.org> wrote: > On 6 July 2016 at 21:01, Steve Ebersole <st...@hibernate.org> wrote: > >> >> One option is that they need to match exactly (maybe with some simple >> handling of quoted versus cas

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