isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Cameron <>
Subject Re: caching value objects
Date Thu, 17 Aug 2017 06:40:13 GMT
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 <
> 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

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