g the tests
On 18/11/15 14:34, Steve Ebersole wrote:
> 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-cor
/job/hibernate-orm-5.0-h2/11/testReport/
> [2] http://pastebin.com/LHppW5jm
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
John O'Hara
joh...@redhat.com
JBoss,
ird party
> projects which use Hibernate, maybe like Teiid.
> It might be more complex for anyone generating HQL programmatically to
> deal with such strict scoping rules.
>
> It might be far-fetched, I don't really know how common that could be,
> nor how easily such i
e
> working on this. Sanne,
> Gunnar... I know y'all have a vested interest and
> a desire to work on it.
> John, I know the same is true for you. Andrea?
> Have you had a chan
as soon as I can to see what impact this has on cpu. This change
only impacts ImmutableEntityEntry, and not MutableEntityEntry
Thanks
John
--
John O'Hara
joh...@redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
Windsor, Berkshire
On 09/06/15 15:30, Sanne Grinovero wrote:
> On 9 June 2015 at 13:50, John O'Hara wrote:
>> On 09/06/15 13:14, Sanne Grinovero wrote:
>>> There are lots of setters on EntityEntry, but sharing it would require
>>> at least the implementation to be fully immutable
h my thoughts but I can not find
my response to that question. Should clarify this in the javadoc. I
think that ImmutbaleEntityEntry should refer to the Entity being immutable.
Thanks,
John
>
> Thanks,
> Sanne
>
> On 9 June 2015 at 13:03, John O'Hara wrote:
>> For
already
have an EntityEntry cached, can we re-use the EntityEntry between
sessions? This would reduce the allocation rate of EntityEntry in our
use case by ~50%.
--
John O'Hara
joh...@redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod S
Invalid publication 'mavenJava': artifact file does not exist:
> '/mnt/ssd/work/hibernate5/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.1-SNAPSHOT-karaf.xml'
> "
>
> _______
> hibernate-dev mailing list
&g
_
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
John O'Hara
joh...@redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
Windsor, Berks
gt;
>
> On Mon, Apr 13, 2015 at 5:37 AM, John O'Hara <mailto:joh...@redhat.com>> wrote:
>
> I think there are two factors to consider, when the entity is
> marked as Immutable, and when the EntityEntry can be shared
> between sessions.
>
> Our u
your use-case. But you never replied to that.
>
>
>
> On Fri, Apr 10, 2015 at 9:26 AM, John O'Hara <mailto:joh...@redhat.com>> wrote:
>
> I have updated my current branch:
> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>
04:51, Steve Ebersole wrote:
>
>
> On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <mailto:joh...@redhat.com>> wrote:
>
> Steve,
>
> I have pushed a proposal for HHH-9701 to:
> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>
>
simply set the LockMode on the ImmutableEntityEntry to NONE/READ_ONLY
when setLockMode is called?
Thanks
John
--
John O'Hara
joh...@redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
Windsor, Berkshire, SI4 1TE, United Kingdom.
Register
before we potentially
> start using these in situations they were not designed for.
>
--
John O'Hara
joh...@redhat.com
JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK an
optimise Read Only entities
>
> @Steve, I guess we're looking at you for advice on what needs to be
> done for the Lock state. I'm understanding that needs to be addressed
> right?
>
> Thanks,
> Sanne
>
>
>
>
> On 27 March 2015 at 11:42, John O'Ha
asonable to have the EntityPersister
> determine the "EntityEntry builder" to use. That also eliminates
> needing to develop yet-another-extension-point because if we
> expose it from EntityPersister OGM already swaps EntityPersister
> impls so this would Just
factories to use custom EntityEntry
> implementations -
> requirements are not fully clear at this point but it
> seems likely.
>
> The priority being to define the API as that would be a
> blocker for
> 5.0, we have
d-only. The second kind can. The first kind should be the only
> case where we use ImmutableEntityEntry, because in the second case
> that entity can later become mutable and as you say we would then need
> to "promote" its corresponding ImmutableEntityEntry to a
> MutableEntityEntry (eve
s likely.
>
> The priority being to define the API as that would be a blocker for
> 5.0, we have then better choices to leave more smarter and advanced
> EntityEntry implementations for the future; we'd still need to
> implement at least the essential ones to make sure the API
20 matches
Mail list logo
