They have not been "merged" in the same way we merged
hibernate-entitymanager into hibernate-core.So at the moment using
hibernate-core e.g. does not require geolatte to be present. geolatte is
only required if using hibernate-spatial (isolated transitive dep).
Karel, what are your thoughts o
Ok, I need to move forward on this and I have gotten enough affirmative
feedback to ahead.
On Fri, Jun 24, 2016 at 6:24 PM Steve Ebersole wrote:
> This is all part of the to-be-decided read/write part of the new Type
> contract. I propose, as discussed in the wiki, that we have Type
;> Regards,
>>
>> Karel
>>
>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
>> able to resume the exchange before July 20.
>>
>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole
>> wrote:
>>
>> &
to correct Types (with the correct
> SqlTypeDescriptors) for the SpatialDialect.
>
> On Tue, Jun 28, 2016 at 3:40 PM, Steve Ebersole
> wrote:
>
>> I agree. I think keeping these separate makes the most sense.
>>
>> @Karel, we already have that capability wrt Types (see
>>
e? I.e. is BasicType meant as a
> generic contract across SQL/NoSQL backends or just specific for SQL?
> * I like the proposal of not passing in Mapping to getColumnMapping() et
> al.
>
> --Gunnar
>
>
>
> 2016-06-28 15:24 GMT+02:00 Steve Ebersole :
>
>> Ok, I need
ial dialects.
>
>
> On Tue, Jun 28, 2016 at 5:19 PM, Steve Ebersole
> wrote:
>
>> Thanks for the clarification.
>>
>> However, all told I am not sure what you are suggesting. Are you
>> suggesting that we somehow make Dialect itself expandable/mutable and
&g
That is the intent of
https://github.com/hibernate/hibernate-orm/wiki/Migration-Guides. We just
have to collect the other legacy guide links together there.
On Wed, Jun 29, 2016 at 3:14 AM Vlad Mihalcea
wrote:
> Hi,
>
> I've seen questions on our forum and SO related to migration from 3.x to
>
That was just the latest when we updated those for JPA 2.1
On Thu, Jun 30, 2016 at 6:02 AM Gunnar Morling wrote:
> Hi,
>
> I noticed that a preview release of CDI is specified as dependency for the
> ORM core module: "javax.enterprise:cdi-api:1.1-PFD [1].
>
> Is there a reason for using this spe
As it is an addition of a method to an SPI interface, then no it will not
be breaking applications.
It may or may not affect integrations. The only implementations of
EnhancementContext
I know of are our implementations. So, certainly you could say that it
potentially breaks integrations. But
I think that is just an oversight back to the original impl of the JPA
metamodel. I cannot speak for the tests. I can definitely see the
argument for PluralAttribute#isAssociation logically returning false for @
ElementCollection.
The spec is very unclear about it unfortunately. WRT entities ac
That is an ongoing argument with Atlassian. So yes, there is a way. It
means disabling the GitHub integration. I personally find the solution
worse than the problem. Also realize that it is always available via the
SCM'ed changelog file:
https://github.com/hibernate/hibernate-orm/blob/master/ch
I'm ok with this. That is no longer a real requirement.
Any disagree?
On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero wrote:
> Hi all,
> today creating a unit test I was greeted by this "old friend":
>
> > org.hibernate.MappingException: Composite-id class must implement
> Serializable:
>
> shal
This is something that has been bothering me for a long time. HHH-6328[1]
is a specific example. Basically we are very inconsistent in how we
attempt to match up table and column names, especially when there are
naming strategies involved. We see this with secondary tables,
@org.hibernate.annota
, Emmanuel Bernard
> wrote:
> > > +1, one less people will complain about :)
> > >
> > > On Tue 2016-07-05 17:28, Steve Ebersole wrote:
> > >> I'm ok with this. That is no longer a real requirement.
> > >>
> > >> Any disagree?
>
Actually, I correct myself. The spec does say that composite keys must be
Serializable (section 2.4).
I'd say that we cover this under our "portability/compliance guidelines"
like we do for other JPA requirements that we "softly" require.
On Wed, Jul 6, 2016 at 5:23
On Thu, Jul 7, 2016 at 3:58 AM andrea boriero wrote:
> On 6 July 2016 at 21:01, Steve Ebersole wrote:
>
>>
>> One option is that they need to match exactly (maybe with some simple
>> handling of quoted versus case-insensitive, similar to Identifier#equals
>
> Personally, I think using straight String comparisons is the main
>> problem. If you look at the code for Identifier#equals that is really
>> exactly what we need already.
>>
>> We cannot just drop the quotes for an accurate comparison. "`MY_TABLE`"
>> and "`my_table`" are different tables to
ases 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 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 `current`
> symlink by hand.
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 wrote:
> Reviving this to finish the discussion about creation of the `current`
> symlink...
>
> I think we can actually script this update to the `curr
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 a valid use case?
>
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
anyo
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.
___
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 wrote:
> Along with the Type redesign in 6.0 we will need to do some redesign
something I just wrote.
On Sun, Jul 17, 2016 at 9:27 PM Chris Cranford 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 "template" for the comment
y the
> devil is in the details so this might need a little prototyping.
> Thanks for the meeting heads up, I'll be there.
>
> Thanks,
> Sanne
>
> On 17 July 2016 at 15:56, Steve Ebersole wrote:
> > BTW, I started a design proposal wiki for this work:
> >
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 would multi-column types woul
On Thu, Jul 21, 2016 at 6:36 AM Guillaume Smet
wrote:
>
> @ORM: interested in me pursuing this for ORM too? It will probably be
> a lot more work as the structure of the docs got changed a lot.
>
I would definitely be interested in a solution that finally allows us to
fix this. If you are willi
information as 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
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 wrote:
> One goal of the redesign is to build more friendly, easy-to-follow
> contract for access to this metadata
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
tColumnSpan();
> > }
> > }
> >}
> > }
> >
> > Hopefully, JPA does not mandate == between different types.
> >
> > A question I have is how navigable and easy such API would be for a
> > persister. But that's someth
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 you can pass the (JPA)
> Ty
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 >
> > wrote:
> >
> > > Th
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 instance would be inhere
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 follo
See inline...
On Mon, Jul 25, 2016 at 1:06 PM Sanne Grinovero wrote:
> some comments inline:
>
> On 25 July 2016 at 18:27, Steve Ebersole wrote:
> > I wanted to start a consolidated discussion about multi-load support.
> This
> > relates to a few Jiras, questioning a
way to also handle de-duplication which is a related,
reported bug.
On Mon, Jul 25, 2016 at 3:01 PM Sanne Grinovero wrote:
> On 25 July 2016 at 19:55, Steve Ebersole wrote:
> > See inline...
> >
> >
> > On Mon, Jul 25, 2016 at 1:06 PM Sanne Grinovero
> wrote:
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 f
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 wrote:
> On 28-7-2016 18:07, Steve Ebersole wrote:
> > I do think this is an error. I think the proper fix is to first
>
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
> ___
, 2016 at 7:11 AM Steve Ebersole 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
> wrote:
>
>> On 28-7-2016 18:07, Steve Ebersole wrote:
>&
pChat 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 wrote:
> On Fri, Jul 22, 2016 at 4:14 AM Emmanuel Bernard
> wrote:
>
> An alternative that I can think of i
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 th
: , ,
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 Ebersole] HHH-11024 - Exception still thrown when dropping schema
with a m
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 relocation to an other
Linux 3.19.8-100.fc20.x86_64 amd64
>
>
> On Fri, Aug 12, 2016 at 3:16 PM, Steve Ebersole
> wrote:
>
>> 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
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 L
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 wrote:
> I have had a comment in LocaleType for quite some time to convert
> fro
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]
https://github.com/seb
s new feature 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 wrote:
>
> On 08/17/2016 03:54 PM, Steve Ebersole wrote:
> > For whatever reason discussi
riero 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" wrote:
>
>> For whatever reason discussion about JavaMoney/Moneta support ha
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 :
>
>> Especially because it is hitting directly an area (type sy
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 that we'd still have to de
+evil
On Fri, Aug 26, 2016 at 7:49 AM Sanne Grinovero wrote:
> On 26 August 2016 at 12:51, Steve Ebersole wrote:
> > 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 make
We have a number of resources whose references are valid only during
bootstrap. This includes things like:
- ClassmateContext
- JPA temp ClassLoader
- Scanner and related
- HCANN ReflectionManager (eventually Jandex)
- etc
The problem is that as currently handled (via
MetadataBuil
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 at runtime
> > (either because metadata was loa
it?
On Tue, Aug 30, 2016 at 8:50 AM Steve Ebersole wrote:
> 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
>> >
> integrate as is?
>
> Thanks,
> Gail
>
> On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole
> wrote:
>
>> I do like the proposal. Awesome job on the gist. I'll look over the
>> code over the next few days.
>>
>> On Thu, Mar 31, 2016 at 3:05
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 mod
5:18 AM andrea boriero 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:20, Steve Ebersole wrote:
perator in Hamburg (at CET) could see a
> delivery
> > > was brought in in Austin at 8:32 CST.
> > >
> > > Something like that would still be my preference for handling TZ-bound
> > > types such as ZonedDateTime: store the UTC timestamp in one column and
&
s. We covered 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 wrote:
> I think your example is actually a perfect exam
ryServiceInitiator 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 GMT+02:00 Steve Ebersole :
>
>> O
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 modules?
>
> Error collecti
b.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 Ebersole wr
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,
>
> I just upgraded all of
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 the
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( "name
On Fri, Sep 9, 2016 at 4:03 PM, andrea boriero
> 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, Steve Ebersole wrote:
>>
&
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 wrote:
> WRT the "collection_valued_input_parameter" bit, that is l
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 really requires that
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 wrote:
> Not any particular reason, HHH-10502 or otherwise. Its more a general
> question as I am integrating SQM and t
> 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. Its more a gene
QMCache
> * SQLCache>
>
> Can you please elaborate what you think is problematic about something
> like that?
>
> Am 09.09.2016 um 23:39 schrieb Steve Ebersole:
> > Although, thinking about it some more, SQM itself already exposes some
> > of the things QueryPlan
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 in
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 understand the
type(s) of arguments i
Just to follow up on something I said below...
On Sat, Sep 10, 2016 at 9:27 AM Steve Ebersole wrote:
> Right, that would mean adjusting SQLFunction to report whether the
> arguments are "varargs". I plan on looking to change the SQLFunction
> contract quite a bit already
f 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:
> > WRT the "double caches&
on [%s] used as argument to not allow multi-values, ..
);
sqmFunctionArgumentParameter.allowMultiValues( false );
}
}
On Sat, Sep 10, 2016 at 9:53 AM Steve Ebersole wrote:
> We are actually getting close to being able to wholly determine FUNCTION
> syntactically. So adding su
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 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 longer
needed, especially in it's current form.
Specifically, ResultTransformer defines 2 distinct ways to transform the
results of a query:
1. `#transformTu
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
the
gt; Vlad
>
> On Mon, Sep 12, 2016 at 5:49 AM, Steve Ebersole
> 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
>> longer
>> needed, especially in it&#
.
>
> Vlad
>
> On Mon, Sep 12, 2016 at 6:02 AM, Steve Ebersole
> 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. Longer term I
>> can a
ore.getId(),
> commentScore);
> return commentScore;
> }
>
> @Override
> public List transformList(List collection) {
> return roots;
> }
> }
>
> The results were fetched using a Recursive CTE and I wanted the results to
> be asse
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 wrote:
> So your example
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 wrote:
> Gail, IIRC one of these methods causes problems w
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 inherently obvious ways
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 instantiation is fine when you use it
er 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 wrote:
> On Tue, Sep 13, 2016 at 2:26
It is still a WIP and is not yet buildable. But you can follow the
progress: https://github.com/sebersole/hibernate-core/tree/wip/6.0
On Tue, Sep 13, 2016 at 9:10 AM Christian Beikov
wrote:
> Is there a more or less stable version of Hibernate 6 that can be used
> for early testing?
> I'd like
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 has
> to throw an exc
. 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 wrote:
> So again, this all boils down to the interplay with
> (Result|Tuple|ResultList)Transformer, dynamic instantiations, and
> result-types.
>
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 wrote:
> So here is the path I am foll
BTW... https://hibernate.atlassian.net/browse/HHH-11104
On Tue, Sep 13, 2016 at 7:05 PM Steve Ebersole wrote:
> Hmmm there is an interesting aspect to Tuple + TupleTransformer.. both
> expect to get the root selection aliases and would naturally expect those
> to match in length to t
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 seem
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 wrote:
> Yes, it was intentional. As you say it is totally r
That would be my personal opinion.
On Wed, Sep 14, 2016 at 11:24 AM Sanne Grinovero
wrote:
> On 14 September 2016 at 17:16, Steve Ebersole wrote:
> > To be clear, I mean "never end the transaction locally". It's like any
> > resource handling... if you start/b
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
arg
ction (SPI) issue you already
discovered. Perhaps it could be reasonable to either expect the function
to cast to SessionImplementor or to define this based on SessionImplementor
rather than Session; dunno.
On Wed, Sep 14, 2016 at 2:32 PM Steve Ebersole wrote:
> The problem with "execute
1201 - 1300 of 1661 matches
Mail list logo
