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 <d...@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...@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 > > >
