isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Óscar Bou - GOVERTIS <o....@govertis.com>
Subject Re: Overly complex compareTo()
Date Thu, 26 Nov 2015 11:33:26 GMT
Hi Stephen.

You can also use Guava’s ComparisonChain as detailed in [1].

Cheers,

Oscar

[1] http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/ComparisonChain.html


> El 26 nov 2015, a las 12:30, Stephen Cameron <steve.cameron.62@gmail.com> escribió:
> 
> Hi Again
> 
> Thanks for your thoughts, looks like another silly mistake on my part
> explains the error, I had to override getter in a child class to be able to
> position it differently on the page and did not use
> super.getStartDateTime(). I should use the JSON layouts for that kind of
> thing.
> 
> The bookmarkservice idea is interesting, something I have not delved into
> in any detail. There is so much to learn (my previous Aladdins Cave comment
> was sincere).
> 
> But in terms of speed, I suppose its something to think about when users
> start to complain about performance issues. Not on the eve of an demo.
> 
> On Thu, Nov 26, 2015 at 10:08 PM, Dan Haywood <dan@haywood-associates.co.uk>
> wrote:
> 
>> Only time I've seen these sorts of index issues is when the enhancer didn't
>> run correctly over the entire codebase.
>> 
>> With respect to compareTo implementations, in Estatio we've got away with
>> using the ObjectContracts.compareTo method.  So, for example, in LeaseItem,
>> whose parent is Lease and which is also identified by the leaseType and
>> sequence, the implementation is just
>> 
>>     ObjectContracts.compareTo(this, other, "lease", "type", sequence);
>> 
>> For your Participation entity I would imagine that using
>> 
>>    ObjectContracts.compareTo(this, other, "activity", "participant");
>> 
>> would work.  As I think you allude to, it could end up resolving more data
>> than is necessary, though, in order to do the comparisons of Activity and
>> then Participant within.
>> 
>> ~~~
>> If you wanted faster comparisons, you could denormalize by holding the key
>> fields from the Activity and Participant within Participation.  For
>> example, if Activity is comparable on "name", and Participant on
>> "firstName", "lastName" (say), then the Participation entity could define
>> "activityName", "participantFirstName", "participantLastName".  Then the
>> comparison of Participation will just use data that's already in memory.
>> 
>> Of course, that introduces a related problem of maintaining these derived
>> properties, but for that I would use domain events or lifecycle events.
>> 
>> Alternatively, yes, you could sort by exposing the database Id of the
>> Activity and Participant, though I think you'd still need to derive them
>> down into Participation (I don't know of any way to actually surface the
>> implied foreign key columns into the domain entity).  Perhaps even easier
>> is to grab the Isis OID (which is derived ultimately from the database Id)
>> and store that, using the BookmarkService:
>> 
>>   Participant p = ...;
>>   Bookmark participantBookmark = bookmarkService.bookmarkFor(p);
>>   setParticipantId(participantBookmark.toString());
>> 
>> 
>> 
>> HTH
>> Dan
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 26 November 2015 at 10:46, Stephen Cameron <steve.cameron.62@gmail.com>
>> wrote:
>> 
>>> Hi,
>>> 
>>> I am trying to improve the compareTo() functions that I have written and
>>> ran into the following error.
>>> 
>>> 
>>>   - java.lang.ArrayIndexOutOfBoundsException
>>>   - 31
>>>   -
>>> 
>> org.datanucleus.state.StateManagerImpl#isLoaded(StateManagerImpl.java:2893)
>>> 
>>>   -
>>> 
>> au.com.scds.chats.dom.module.activity.RecurringActivity#getStartDateTime(RecurringActivity.java:-1)
>>> 
>>>   - sun.reflect.GeneratedMethodAccessor75#invoke(null:-1)
>>>   -
>>> 
>> sun.reflect.DelegatingMethodAccessorImpl#invoke(DelegatingMethodAccessorImpl.java:43)
>>> 
>>>   - java.lang.reflect.Method#invoke(Method.java:497)
>>>   -
>>> org.apache.isis.applib.util.Clause#getValueOf(ObjectContracts.java:365)
>>> 
>>>   -
>>> 
>> org.apache.isis.applib.util.ObjectContracts#compare(ObjectContracts.java:70)
>>> 
>>>   -
>>> 
>> org.apache.isis.applib.util.ObjectContracts#compare(ObjectContracts.java:63)
>>> 
>>>   -
>>> 
>> au.com.scds.chats.dom.module.activity.Activity#compareTo(Activity.java:120)
>>> 
>>>   -
>>> 
>> au.com.scds.chats.dom.module.activity.Activity#compareTo(Activity.java:54)
>>> 
>>>   -
>>> 
>> com.google.common.collect.ComparisonChain$1#compare(ComparisonChain.java:76)
>>> 
>>>   -
>>> 
>> au.com.scds.chats.dom.module.participant.Participation#compareTo(Participation.java:206)
>>> 
>>>   -
>>> 
>> au.com.scds.chats.dom.module.participant.Participation#compareTo(Participation.java:31)
>>> 
>>>   - java.util.TreeMap#compare(TreeMap.java:1290)
>>>   - java.util.TreeMap#put(TreeMap.java:538)
>>>   - java.util.TreeSet#add(TreeSet.java:255)
>>>   -
>>> 
>> org.datanucleus.store.types.wrappers.backed.SortedSet#loadFromStore(SortedSet.java:283)
>>> 
>>>   -
>>> 
>> org.datanucleus.store.types.wrappers.backed.SortedSet#iterator(SortedSet.java:477)
>>> 
>>>   -
>>> 
>> com.google.common.collect.Collections2$TransformedCollection#iterator(Collections2.java:269)
>>> 
>>>   -
>>> 
>> org.apache.isis.core.metamodel.facets.collections.CollectionFacetAbstract#iterator(CollectionFacetAbstract.java:46)
>>> 
>>>   -
>>> 
>> org.apache.isis.core.metamodel.facets.collections.CollectionFacetAbstract$1#iterator(CollectionFacetAbstract.java:54)
>>> 
>>>   -
>>> 
>> org.apache.isis.core.metamodel.adapter.ObjectAdapter$Util#visibleAdapters(ObjectAdapter.java:314)
>>> 
>>>   -
>>> 
>> org.apache.isis.core.metamodel.adapter.ObjectAdapter$Util#visibleAdapters(ObjectAdapter.java:302)
>>> 
>>>   -
>>> 
>> org.apache.isis.core.metamodel.facets.collections.accessor.CollectionAccessorFacetViaAccessor#getProperty(CollectionAccessorFacetViaAccessor.java:85)
>>> 
>>>   -
>>> 
>> org.apache.isis.core.metamodel.specloader.specimpl.OneToManyAssociationDefault#get(OneToManyAssociationDefault.java:161)
>>> 
>>> 
>>> I have the comparison for Activity now of startDateTime then name then
>>> region, so the comparison of Participations (a link table between
>> Activity
>>> and Participant) is of Activity first and then Participant. This gets
>> quite
>>> complex in terms of retrieving value graphs which might explain the
>> error.
>>> 
>>> Is there a better way, maybe I can use database id instead as they
>> reflect
>>> order of creation of records, which might be good enough for
>> participation
>>> sorting. I've tried to avoid using generated ID values in OO code but
>> maybe
>>> its a compromise I have to accept occassionally, instead of natural keys.
>>> 
>>> Just raising it for discussion.
>>> 
>>> Thanks
>>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message