Hmm, I read that there are the autoCompleteRepository and autoCompleteAction attributes for the @DomainObject annotation. I should be making use of these! However, does this obviate the need for my ClientIdentity class completely?
With a cached list of identity objects shared by all users maybe I can avoid database queries completely and avoid the need to instanciate any of the big linked class until a choice is made. The big class may be big in the sense of having lots of children. I note that DataNucleus uses identity classes for classes with a complex primary key value, I've not gone there yet. On Thu, Aug 17, 2017 at 3:41 PM, Stephen Cameron <[email protected] > wrote: > Related to the discussion of value objects, they would seem to provide an > opportunity to cache lists of such values in domain service 'repositories', > (particularly if they are immutable and never deleted from a database?). > Something like a list of suburbs that is of restricted size but used > frequently would seem to be a good case for this. > > So my question is how best to do such caching? > > A similar caching question has arisen for me but not with value objects > instead with 'identity' objects. I created such an identity class as a > means of providing faster look-up of clients in a system. This is the most > common task for the users: to find a person/client and read/change some > aspect of their record. As the Client class is quite big, creating a list > of all clients just to choose one of them was too slow. So, I created a > 'ClientIdentity' class that has just the client id and the name of the > client, the latter to present to the user via a choicesN.... method, and > once that single ClientIdentity object has been chosen the related Client > class is retrieved and used. > > I would seem that such identity objects would also be a good candidate for > domain service caching. > > Just maybe this is not a good idea. > > Steve > > > > >
