Re: [hibernate-dev] AttributeConverter and internally mutable domain types

2015-09-25 Thread Sanne Grinovero
Hi Steve,
this could be a case for a marker interface?

We could introduce an "ImmutableAttributeConverter", to be implemented
by the safe ones, so that it doesn't break any existing converter.

On 24 September 2015 at 22:54, Steve Ebersole  wrote:
> I went ahead and resolved HHH-10111 to be correct in the mutable cases as
> well.  I created a new Jira[1] to continue the discussion related to
> allowing the user to indicate that the type is immutable (as an
> optimization), so let's move discussion of those follow-on steps to that
> Jira.
>
>
> [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?  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 matter of just returning the original.  It also
>> affects how we dirty check it, how we (2nd level) cache it, etc.
>>
>> So far we have assumed that types mapped using AttributeConverters are
>> immutable.  However, this Jira is an example of where that breaks down.
>>
>> I think for now we will have to assume that the AttributeConverter entity
>> type is mutable and build an appropriate MutabilityPlan.  Moving forward I
>> think we should consider a means to allow developers
>> using AttributeConverter along with immutable state (which seems to be the
>> majority case) the option to somehow indicate that the converted-to type is
>> immutable which allows us to apply the more efficient plan.  Thoughts on
>> the best way to achieve this latter part?  I am initially thinking an
>> optional contract for the AttributeConverter impl itself to implement:
>>
>> @Converter
>> class MyAttributeConverter
>> implements AttributeConverter,
>> HibernateAttributeConverter {
>> // normal AttributeConverter methods
>>
>> /**
>>  * HibernateAttributeConverter
>>  */
>> @Override
>> public boolean isMutable() {
>> return true;
>> }
>> }
>>
>> Another option is to develop some annotations that are applied to the
>> AttributeConverter impl (much like the javax.persistence.Converter itself):
>>
>> @Converter
>> @org.hibernate.annotations.MutableConvertedState(true|false)
>> class MyAttributeConverter implements AttributeConverter {
>> // normal AttributeConverter methods
>> }
>>
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


[hibernate-dev] hibernate-infinispan tests - part... oh I've lost track

2015-09-25 Thread Steve Ebersole
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/hibernate-orm-master-h2/1122/
http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/

Are 3 job runs showing what I mean.  There is no code change between any of
these runs.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] hibernate-infinispan tests - part... oh I've lost track

2015-09-25 Thread Radim Vansa
Since we can't reproduce the test on local machine (I was once runnning 
the testsuite whole night again and again and did not get any crash), 
the only option I can think of is running hibernate-infinispan with 
verbose logging in CI.
To properly diagnose what has happened, we should set up
org.jgroups TRACE
org.infinispan TRACE
org.infinispan.marshall DEBUG
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 level when running 
testsuite, or could you do that only in the CI?

Radim

On 09/25/2015 04:28 PM, Steve Ebersole wrote:
> 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/hibernate-orm-master-h2/1122/
> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/
>
> Are 3 job runs showing what I mean.  There is no code change between any of
> these runs.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa 
JBoss Performance Team

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev