>
> The naming strategies are giving me a hard time: we used the
> DefaultComponentSafeNamingStrategy before and there is no real equivalent
> in ORM 5.
>
org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl is
the corolary. These may or may not migrate directly due to the *spl
>
> org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl is
>> the corolary. These may or may not migrate directly due to the *split*.
>> The old NamingStrategy actually covered implicit naming, physical naming
>> and logical naming; whereas we have now split these out into dist
This test was originally added for
https://hibernate.atlassian.net/browse/HHH-8497
I guess my first thought is to question is why this test exists at all.
It's really a question of whether we consider the classic HQL translator
"supported". Stuff like this "parameter expected type" was developed
d to the use of the classic translator.
>
> On 17 September 2015 at 18:07, Steve Ebersole wrote:
>
>> This test was originally added for
>> https://hibernate.atlassian.net/browse/HHH-8497
>>
>> I guess my first thought is to question is why this test exists at all.
>
On Wed, Sep 16, 2015 at 8:38 PM Gail Badner wrote:
> Is the only JPA-compliant way to do a multi-level fetch join to use entity
> graphs?
>
> JPA 2.1 does not support fetch joins using an alias at all. JSR 338,
> 4.4.5.3 Fetch Joins says,
>
> "It is not permitted to specify an identification vari
Just a heads up that I finally got enough traction in this work towards
building a "SQL AST" to warrant a push upstream.
The majority of time has been trying to think through the best tree
structure for modeling from clauses especially in regards to
entity/collection persisters that map across mul
Its really a different discussion Hardy. The discussion here is
whether EntityManagerFactory().getProperties() should return values that
were not passed in the Map when building the EntityManagerFactory.
Yes the spec says that ValidatorFactory should be passed as part of the
"configuration Map" w
g through
the current HQL tests and finding the things we want to support and porting
tests is going to have to happen in some form at some point in time.
[1] And I'd like to consider supporting the INSERT-tuple syntax in addition
to the INSERT-SELECT syntax we already support.
On Mon, Sep 21, 20
https://hibernate.atlassian.net/browse/HHH-10121
On Wed, Sep 23, 2015 at 10:19 AM Hardy Ferentschik
wrote:
> Hi,
>
> On Wed, Sep 23, 2015 at 02:36:05PM +0000, Steve Ebersole wrote:
> > Its really a different discussion Hardy. The discussion here is
> > whether
I went back and looked into UPDATE queries.. there are actually some basic
tests. See org.hibernate.test.query.parser.hql.dml.BasicUpdateTests.
On Wed, Sep 23, 2015 at 9:54 AM Steve Ebersole wrote:
> Gunnar, to answer your "what should I work on?" question... there are lots
>
We really no longer maintain ORM 4.x. Yet we still get Jira reports citing
4.x as the affected version. We have been asking the reporter to reproduce
with 5.0.
But in the interim it is easy to lose track of these issues. Ultimately
the "affects version" needs to be updated or the issue rejected
Reference https://hibernate.atlassian.net/browse/HHH-10111
This comes down to the idea of a Type's mutability : can the thing's
internal state be changed? We use this for all kinds of optimizations. If
the internal state is not mutable, we know that "making a deep copy", for
example, is a simple
Petar, I guess it could be. I have not seen that myself nor reports of
that yet though.
On Thu, Sep 24, 2015 at 1:37 PM Petar Tahchiev
wrote:
> Hello,
>
> can someone please confirm this is a bug:
>
> https://hibernate.atlassian.net/browse/HHH-10099
>
> Or perhaps I'm doing something wrong?
>
[1] - https://hibernate.atlassian.net/browse/HHH-10127
On Thu, Sep 24, 2015 at 2:08 PM Steve Ebersole wrote:
> Reference https://hibernate.atlassian.net/browse/HHH-10111
>
> This comes down to the idea of a Type's mutability : can the thing's
> internal state be changed? W
We are again running into problems with hibernate-infinispan tests. We are
seeing false test failures on CI. I cannot reproduce these failures
locally, and even out on CI the test(s) that fil change each time.
http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/
http://ci.hibernate.org/job/
Java sources do not need to be kept in directory corresponding to their
package. It is a in-accurate common belief that that is needed. It is
convention, sure, but not needed. That said, as Gunnar pointed out it is a
regression in the Gradle Antlr parser that I actually reported to them. I
had
t; > org.infinispan.commons.marshall DEBUG
> >
> > (the other two just reduce the verbosity in the parts we don't need). If
> > the build fails in CI and I can get my hands on the log, I can
> investigate.
> >
> > Steve, should I prepare a PR switching the log
Its failing on the second run as well. So for now I am disabling the
hibernate-infinispan tests again.
On Wed, Sep 30, 2015 at 2:01 PM Steve Ebersole wrote:
> So this just bit me (again) doing the release. I get transient test
> failures in hibernate-infinispan trying to run the r
http://in.relation.to/2015/09/30/hibernate-orm-502-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
That is the idea...
On Sun, Sep 27, 2015 at 12:30 AM amit shah wrote:
> Including the dev mailing group to get a few suggestions on my question.
>
> Thanks!
>
> On Wed, Sep 23, 2015 at 4:54 PM, amit shah wrote:
>
> > We are planning to integrate hibernate 4 multi-tenancy feature into our
> > a
Eclipse's compiler does not like the flat style, so it's basically
> impossible to run tests in Eclipse due to the gazillion compile
> errors. So it'd be great to do the update to Gradle 2.7 quickly once
> it's out.
>
> 2015-09-28 14:04 GMT+02:00 Steve Ebersole
That's the idea. The alternative is to create multiple SessionFactory
instances, one per-tenant. So in theory the heap should be reduced.
On Sun, Sep 27, 2015 at 12:30 AM amit shah wrote:
> Including the dev mailing group to get a few suggestions on my question.
>
> Thanks!
>
> On Wed, Sep 23,
Reference HHH-10050[1]. There is a request to incorporate parameterized
type resolution into the decision of whether an auto-apply
AttributeConverter should apply to a given attribute.
For those on the list better at parameter type resolution, is the best
solution here to use ClassMate? Or is th
Reference HHH-9615[1].
The specific request here is to support @Lob together with an
AttributeConverter. But other combinations apply as well. So I want to
address the more generic case, but let's talk in terms of this specific
case.
Ultimately the problem is in SimpleValueBinder and the fact t
nationalized.
This change caused no regressions.
On Sat, Oct 3, 2015 at 9:22 AM Steve Ebersole wrote:
> Reference HHH-9615[1].
>
> The specific request here is to support @Lob together with an
> AttributeConverter. But other combinations apply as well. So I want to
> address t
Bueller..?
Any thoughts?
On Fri, Oct 2, 2015 at 6:59 PM Steve Ebersole wrote:
> Reference HHH-10050[1]. There is a request to incorporate parameterized
> type resolution into the decision of whether an auto-apply
> AttributeConverter should apply to a given attribute.
>
> F
https://github.com/hibernate/hibernate-semantic-query/pull/3
This boils down to an interesting (well, if you find parsers interesting
like me :) discussion about syntactic analysis versus semantic analysis.
___
hibernate-dev mailing list
hibernate-dev@li
:
> On Mon, Oct 05, 2015 at 02:03:54PM +0000, Steve Ebersole wrote:
> > Bueller..?
> >
> > Any thoughts?
>
> I am not familiar of the whole concept of AttributeConverter, but if you
> need
> full type resolution of a generic type, ClassMate is the way to go.
>
> Th
Votes on supporting this?
https://hibernate.atlassian.net/browse/HHH-9807
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
it
> > to be available when loading the entity?
> >
> > Davide
> >
> > On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole
> > wrote:
> >
> > > Votes on supporting this?
> > >
> > > https://hibernate.atlassian.net/browse/HHH-9807
> &g
At the moment the alias registry is global for the whole query. I propose
that we should scope this by "query spec" (combined with parent). The
reason being that reusing the same alias in unrelated subqueries is
perfectly fine.
select ...
from Customer c
where c.id in (
select o.customer.id
>
> > Here the aliases `c` do infringe. In the subquery, we don't really know
> > which reference the `c` alias should resolve to. We *could* here
> assuming
> > that the subquery is uncorrelated. Bu without this rule we really would
> > not know that the subquery is correlated
>
> Out of curios
Yes, but generally speaking Java gives you alternative ways to reference to
hidden/shadowed names, sql/hql/jpql do not.
On Wed, Oct 7, 2015 at 9:42 AM Sanne Grinovero wrote:
> On 7 October 2015 at 15:39, Sanne Grinovero wrote:
> > On 7 October 2015 at 15:27, Steve Eberso
y redesign this alias checking.
On Wed, Oct 7, 2015 at 10:13 AM Sanne Grinovero wrote:
> On 7 October 2015 at 15:41, Sanne Grinovero wrote:
> > On 7 October 2015 at 15:39, Sanne Grinovero wrote:
> >> On 7 October 2015 at 15:27, Steve Ebersole wrote:
> >>>>
>
identification_variable
to be defined twice or for the same result_variable to be defined twice.
However, if the same identification_variable or result_variable exists just
i the parent scope, that is ok.
On Wed, Oct 7, 2015 at 10:31 AM Steve Ebersole wrote:
> Ah, good call. I found this in t
Emmanuel... any idea where the best place in the current annotation binding
code to put such a check?
On Wed, Oct 7, 2015 at 9:26 AM andrea boriero wrote:
> +1
>
> On 7 October 2015 at 14:31, Steve Ebersole wrote:
>
>> I personally don't really see much of a justi
HHH-4440[1] added the read/write fragment support. However, as reported
under HHH-9808[2] that support is not consistent for id column(s).
The first piece is missing write fragment support. The second piece is
inconsistent application of the read fragments in generated SQL.
So as a first questi
Wanted to point out the jandex-binding version in Jira that is the work to
pull the annotation binding and Jandex usage from metamodel into upstream.
I do not plan on pulling over the shared (shared between hbm.xml and
annotations) Binder code from metamodel. This will just be a focus on the
code
Getting some proposals that have been rolling around in my head down on
paper (electronically speaking)..
*Caching SessionFactory state*
The Jira[1] contains the details. The basic gist is to allow for slimming
down the in-memory size of the SessionFactory based on how we store certain
SF-scope
Well first...I am not sure why you are passing a custom RegionFactory.
What does your custom RegionFactory do that is missing in the
hibernate-infinispan impls?
There is a lot to this discussion under the covers.
To re-iterate our discussion from f2f... Hibernate is moving toward being
able to ac
As I outlined in my reply, as things stand accepting a String or Class or
instance causes a lot of internal code duplication that I'd obviously like
to avoid. I'd be ok with this if we made RegionFactory convention to not
accept ctor args.
On Wed, Oct 21, 2015 at 9:49 AM Sanne Grinovero wrote:
You could, but like I mentioned with StrategyRegistration Jipijapa would
need to somehow interject that into the EMFB.
On Wed, Oct 21, 2015, 10:17 AM Sanne Grinovero wrote:
> On 21 October 2015 at 15:59, Steve Ebersole wrote:
> > As I outlined in my reply, as things stand accepting
BTW, I just pushed the work I have done so far on this:
https://github.com/sebersole/hibernate-core
There is one very simple test just to ensure that the basic binding works
properly.
On Fri, Oct 9, 2015 at 12:28 PM Steve Ebersole wrote:
> Wanted to point out the jandex-binding version
Lots of great ideas there. Some covered by the new bytecode work. The
"model metadata" stuff I think is another piece to his bytecode
enhancement; we could consider doing the same in our enhancement; it is
very similar in fact to what we do with the JPA metamodel generator and
populating that at
BTW, the forum link was wrong. I think you meant:
https://forum.hibernate.org/viewtopic.php?f=1&t=1042042
On Thu, Oct 22, 2015 at 7:38 AM Davide D'Alto wrote:
> Hi all,
>
> I just want to mention that
> a user on the Hibernate forum created a framework on top of Hibernate:
>
> https://forum.
Koen, any thoughts on the "mapping model" proposal? FWIW, silence on this
list is taken by me to mean implicit agreement for me to do whatever I want
;)
On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole wrote:
> Getting some proposals that have been rolling around in my head do
les.
> Not sure if this answers your questions?
>
> Cheers,
> Koen
>
> Op 24 okt. 2015, om 20:40 heeft Steve Ebersole het
> volgende geschreven:
>
> Koen, any thoughts on the "mapping model" proposal? FWIW, silence on this
> list is taken by me to mean i
/sebersole/ec53bbc02419fb261825
[2] - https://gist.github.com/sebersole/e6fd42fb2d7b79f7ecc4
[3] - https://gist.github.com/sebersole/ce0a047edc0d4c68bd6e
[4] - https://gist.github.com/sebersole/6676abc04ec1b9266304
On Sun, Oct 25, 2015 at 2:04 PM Steve Ebersole wrote:
> Really its a question a
A reminder that 5.0.3 is slated for 2 days from now. There are currently
10 unresolved issues scheduled for it. If you scheduled an issue for 5.0.3
please make sure it is resolved soon.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https:
I won't be able to attend the triage meeting today. I have a doctor
appointment.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
also have no impact for the current
> tools.
>
> I hope this helps a bit.
>
> Cheers,
> Koen
>
> Op 26 okt. 2015, om 15:49 heeft Steve Ebersole het
> volgende geschreven:
>
> So here are the general proposals per object:
>
> 1) Column - The main change proposed
http://in.relation.to/2015/10/28/hibernate-orm-503-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
I started work on SQM-24 which covers translation of criteria queries into
SQM.
The difficulty with this is that the JPA contracts alone do not give enough
information to really be able to understand the semantics of the query;
there is just not enough information exposed. I can get into specific
The link target is http://www.hibernate.org/issuetracker.html#testcases.
That's not the "JIRA main page".
On Fri, Oct 30, 2015 at 8:44 AM Gunnar Morling wrote:
> Hi,
>
> When creating a new HHH issue, there is a link "...should generally be
> accompanied by a test case" but it directs to the JI
But for some reason it directs me back to JIra. Even just clicking that
link in the email does. I wonder if someone set up a bad redirect on the
hibernate.org website for that?
On Fri, Oct 30, 2015 at 8:52 AM Steve Ebersole wrote:
> The link target is http://www.hibernate.
; in a separate subject.
On Fri, Oct 30, 2015 at 8:53 AM Steve Ebersole wrote:
> But for some reason it directs me back to JIra. Even just clicking that
> link in the email does. I wonder if someone set up a bad redirect on the
> hibernate.org website for that?
>
> On Fri,
But that was not the purpose of the content at the old link. Yes the
templates are nice but that's not the whole picture of what makes a good
test case
On Fri, Oct 30, 2015, 9:41 AM Gunnar Morling wrote:
> 2015-10-30 15:16 GMT+01:00 Steve Ebersole :
> > It looks like that
I have not seen any discussion around "boolean-function-expressions
as predicates" on SQM-15...
On Thu, Sep 10, 2015 at 7:12 AM Steve Ebersole wrote:
> It is true that not all applications use spatial, or even that DB’s
>> support (all) spatial functions. But it would help to
rnate/hibernate-orm/blob/master/migration-guide.adoc
>
>
> On 08/13/2015 08:38 AM, Steve Ebersole wrote:
> > For a lot of your questions, I'd highly suggest reading [1] and [2].
> They
> > are mostly the same content (asciidoc versus docbook).
> >
> > [1]
o approaches:
> Let the criteria objects expose all the required data, make them
> traversable by means of a visitor and have an SQM-specific visitor
> implementation which converts each criteria object into its SQM
> counter-part.
>
> --Gunnar
>
>
>
>
> 2015-10-
te
> > from a test case? I've looked at the github repo but didn't find a
> > matching method.
> >
> > Martijn
> >
> > On Friday, 30 October 2015, Sanne Grinovero wrote:
> >> We should add a page on hibernate.org describing the idea, and from
> &g
Keeping up with the 4 week timebox for 5.0 bugfix releases unfortunately
puts them on bad days with the upcoming holidays.
5.0.4 would hit Nov 25th which is the day before Thanksgiving here in the US
5.0.5 would hit Dec 23rd, 2 days before Christmas
So I propose pushing 5.0.4 forward or back one
That would still put 5.0.5 in the middle of winter break.
Probably we should schedule that for a 3 week timebox too. So:
- 5.0.4 -> November 18th
- 5.0.5 -> December 9th
- 5.0.6 -> January 6th (back to normal 4 week timebox)
I generally prefer shorter cycles
>
I agree, to a point. Bu
At the moment Hibernate builds all of the Loaders that derive from
batchsize when the SessionFactory is built. So practically speaking you'd
have to account for that change in design.
But in general the idea would be ok.
On Wed, Nov 4, 2015 at 12:05 PM Vlad Mihalcea
wrote:
> Hi,
>
> I was bro
Reference https://hibernate.atlassian.net/browse/HHH-10242
I need to make another change in HCANN and pull that new version into ORM.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Personally I see this as a pragmatic versus correct discussion. To me,
once you release a final you should create it's branch. The pragmatism
comes from the fact that following this "correct" approach causes a lot of
"extra work" (extra until there is an actual deviation).
I regularly do this
>>> Sir I wasn't able to focus becoz of my university exams , soon I'll
>>> start fixing your bugs. Please keep me throughout . Please help me in all
>>> the possible ways . I want to contribute to your community to my full
>>> extent. How
to be
converted to use the Hibernate testing framework[2].
[1] https://hibernate.atlassian.net/browse/HHH-9540?filter=17060
[2] https://github.com/hibernate/hibernate-test-case-templates
On Thu, Nov 5, 2015 at 8:57 AM Steve Ebersole wrote:
> I am not really sure what you are asking.
>
On Mon, Nov 9, 2015 at 2:52 PM Karel Maesen wrote:
> Hi Steve,
>
>
> > On 02 Nov 2015, at 16:16, Steve Ebersole wrote:
> >
> > Any further thoughts?
> >
> > I looked over the link you gave in regards to literals, but did not
> fully understand. I'
I won't be able to make the triage meeting tomorrow
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
I have been noticing that the "GitHub link" in Jira is no longer
automatically performing syncs. I have asked Atlassian about it. In the
meantime, if you use that feature (commit linking, PR linking, etc) you
will have to manually force a sync in Jira
_
I think it makes sense to host these on hibernate.org *after* we figure out
the version-specific content issues I brought up in Barcelona.
However, I am kind of torn. Unless I misunderstand that would mean moving
the sources out of the upstream projects into the hibernate.org git repo.
I worry ab
I'd like to more formally deprecate the legacy bytecode enhancement
starting in 5.0.4 and remove it in 5.1.
The new code is superior and already feature compatible back to 5.0 Final.
Any objections?
___
hibernate-dev mailing list
hibernate-dev@lists.jbo
As I work on HHH-10267, a thought that keeps coming up in my head is that
it would be great to avoid Map lookups in the enhancement and interception
code.
As an example of what I mean, consider the reader for a String field named
`name` which roughly looks like:
public String $$_hibernate_read_na
ed to persisters et al. for enhanced entities.
>
> Not sure whether it's doable or how complex it'd be, just throwing out the
> idea.
>
> --Gunnar
>
>
> 2015-11-11 21:37 GMT+01:00 Steve Ebersole :
> > As I work on HHH-10267, a thought that keeps coming up i
But I think that just redefines the same problem. Just that now instead of
String->Integer we need some Integer->Integer resolution. Not sure that
really gains us anything.
On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole wrote:
> I have no estimate as to how much this would help. Ma
t; attributes in the order as determined by the enhancer. Then at
> runtime, upon getter/setter invocation, the index values passed from
> the enhanced code would be used as is for array index access in
> persisters.
>
> 2015-11-12 15:30 GMT+01:00 Steve Ebersole :
> > But I thin
https://hibernate.atlassian.net/browse/HHH-10280
https://hibernate.atlassian.net/browse/HHH-10281
On Wed, Nov 11, 2015 at 12:15 PM andrea boriero wrote:
> no objections
>
> On 11 November 2015 at 17:55, Steve Ebersole wrote:
>
>> I'd like to more formally deprec
On Thu, Nov 12, 2015 at 2:44 PM Sanne Grinovero wrote:
> Sounds like a very interesting patch, I agree with you that there's
> much potential.
> Although Steve from your description it seems like you don't think it can
> work?
>
Not sure I follow. You agree with the potential of the idea I am
p
Well I like this idea (additional flag on @Filter) better the actual
request (multi-valued config setting). And what about for the
@FilterDef(inition)?
One concern I have is, e.g., getting a collection with a filter enabled,
now disabling a filter and then initializing the collection. That seems
remove the old approach.
>
> Thanks,
>
> --Gunnar
>
>
> 2015-11-12 17:46 GMT+01:00 Sanne Grinovero :
> > +1
> >
> > On 12 November 2015 at 16:39, Steve Ebersole
> wrote:
> >> https://hibernate.atlassian.net/browse/HHH-10280
> >> https:
Hmm, looks like I might have been mistaken about the "external Hibernate
Maven plugin". The only one I can find (cannot remember if this is the one
I was thinking of) just does schema export.
On Fri, Nov 13, 2015 at 8:11 AM Steve Ebersole wrote:
> For runtime enhancement there
t guys now and they ask if hibernate
> allows you to specify the filters to activate in a property file. I guess
> they are interested in adding this functionality to spring-boot too.
>
> 2015-11-13 16:13 GMT+02:00 Steve Ebersole :
>
>> Well not sure I said it is valid ;) There
Forgot to address this part...
5.1 will include the ability to define lazy attribute fetch groups, the
development of which requires a lot of changes to the contracts called from
bytecode enhancement. So rather than retrofit these changes back into the
legacy enhancement code, I chose to simply
In reworking some of the support for bytecode-enhanced laziness, I started
thinking deeper about this idea of partial caching of such entities.
First and foremost, why do we even allow this? Essentially what happens is
that we allow a user to partially load an entity, and then stick that
partial
attribute names. As it
stands now, this boolean needs to become a Collection of Strings (attribute
names) which is a big change perf wise. This affects one of the classes we
have worked hard to minimize in recent months: EntityEntry.
On Fri, Nov 13, 2015 at 11:08 AM Steve Ebersole wrote:
>
On Fri, Nov 13, 2015 at 3:30 PM Hardy Ferentschik
wrote:
> Hi,
>
> On Wed, Nov 11, 2015 at 02:36:13PM +0000, Steve Ebersole wrote:
> > I think it makes sense to host these on hibernate.org *after* we figure
> out
> > the version-specific content issues I brought up in Ba
n Fri, Nov 13, 2015 at 11:15 AM Steve Ebersole wrote:
> Gah, hit send too soon :)
>
> This comes up because I am working on the idea of lazy attribute fetch
> groups. This means that the simple boolean that we used to store is no
> longer going to be sufficient. This ties in w
may end up simply completely removing it from there.
[1]
https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html#performance-cache-mapping
On Fri, Nov 13, 2015 at 3:41 PM Steve Ebersole wrote:
> I worry that this stuff may just not work too. The tests that tested thi
Regarding HHH-10267...
5.1 will include a new feature allowing users to specify groups for
(bytecode enhanced) lazy attribute loading. In the original support
accessing one of these lazy attributes forced them all to be loaded[1].
For example...
@Entity
public class Company {
...
@Basic(
It was to work around certain containers (not just EE containers) that
implement "resource containment" checks. The Hibernate Session defers
getting a JDBC Connection until it actually needs one, which can lead to
cases like the following where 2 beans share a Session/EM:
Bean1: get Session, but
the lazy fetch profiles. Previously it
> > required the Blob to be moved to a different table.
> >
> > Vlad
> >
> >
> >
> > Vlad
> >
> > On Mon, Nov 16, 2015 at 11:09 PM, Steve Ebersole
> > wrote:
> >
> >> Regarding HHH-10267
This is a list for the discussion of HIbernate development. Your question
is not a Hibernate development discussion, its a user question. In the
future, please refrain from asking usage questions on a developer list.
Thanks.
I will address this one quickly though...
Unfortunately that method is
As John pointed out the 39 are from attempting to apply a perf patch to
5.0.
The hibernate-infinispan tests have been an ongoing issue, which is why I
disabled them. In fact I think after 5.0.4 we ought to stop accepting
patches against hibernate-infinispan until the tests are fixed.
On Wed, Nov
On Wed, Nov 18, 2015 at 6:08 AM Vlad Mihalcea
wrote:
> Hi Gunnar,
>
> The best article on this subject is this one:
>
>
> http://www.anyware.co.uk/2005/2012/11/12/the-false-optimism-of-gorm-and-hibernate/
To be honest I stop reading after I read things like
This is because Hibernate caches th
So if I understand correctly, I just inverted the 2 booleans arguments when
trying to apply this to 5.0?
On Wed, Nov 18, 2015 at 4:27 AM John O'Hara wrote:
> Gail,
>
> Tests on hibernate-core in 5.0 branch are failing due to
>
> https://github.com/hibernate/hibernate-orm/commit/7633d2fce540a979
omething that
> was there for quite some time.
>
> If anyone (Galder?) is willing to look into it, please feel free to play
> with [1].
>
> Radim
>
> [1] ci.hibernate.org/job/hibernate-orm-infinispan-testsuite-rvansa
>
> On 11/18/2015 03:20 PM, Steve Ebersole wrote:
> In the tests where lazyPropertiesAreUnfetched is set to true, the
> disableVersionIncrement was inadvertently being set to true for
> MutableEntitEntry's and therefore the version was not being incremented.
> That was causing the tests to fail as the Entity version was not
> incremented during the tes
NT.
> I'll keep you posted with the final results.
>
> Do you think we should update the docs to explain that this is rather
> required by Java EE containers, and it might be fine with stand-along JTA
> transaction managers?
>
> Vlad
>
>
>
> On Wed, Nov 18, 2015
vious state
> is lost and so you won't be able to use the previous state in the WHERE
> clause so to detect an entity change. One workaround is the EXTENDED
> PersistenceContext, but that's usually associated o Java EE (Spring doesn't
> really offer it right out of the box).
801 - 900 of 1361 matches
Mail list logo