[DGD] Persistent Users

[bart at wotf.org]

The one useful way I found to invalidate caches is to use object references,
but that requires destroying and creating new objects whenever data changes.
It works because destroying the object with the outdated data also nils the
references everywhere.

At any rate, for my database code, I do cache the results of expensive
queries, but those are only guaranteed to be valid at the moment you get them,
and are a copy of the data.

Any direct access to data (which uses a much more extensive variation on the
LWO idea we discussed) are directed to the object with the actual data. The
things cached locally are LWOs created as proxy for databases, tables (or
views) or columns, but no actual data is cached in proxy objects. Eventho the
entire system is built around using this interface for any data storage, this
doesn't seem to impact performance much. This being said, code for filtering
through all data is implemented in the storage objects, and hence has direct
access to the data. That removes the for me by far most expensive case.

But.. going back to the account system, unless you allow changing login names,
caching login name and full name and such shouldn't cause an issue I'd think,
and this data might get used more then all other data. 

Bart.


On Fri, 23 Sep 2016 22:10:54 +0100, Gary wrote
> On 23/09/16 21:36, Raymond Jennings wrote:
> > And in general, any savings you could gain by caching will be outranked by
> > any shortfalls caused by corruption.  If your data can become stale,
> > inconsistent, corrupted, or worse sabotaged, its not worth the speed
> > gains.  So generally, security should come first, as all the efficiency in
> > the world won't help you if your data gets compromised.
> 
> Totally agree.
> 
> > Also, consider what would happen if an administrator (or the user) changes
> > the account data and makes any cached copies of it stale.
> >
> 
> I had indeed considered that exact situation as I expect the two main
> cases for account data changes to be via the user or an admin. Which
> would require care and coordination between various objects to ensure
> caches were correctly invalidated. A good enough reason to avoid caching
> unless performance is an issue and why I was not too keen on the idea
> (option 2 in my earlier email) that involved the LWO storing data.
> 
> I generally take the approach safety first, efficiency only when it
> becomes a problem. That is to say, avoiding premature optimisation
> whilst at the same time avoiding premature pessimisation :)
> 
> The account system is unlikely to need caching due to how 
> infrequently I expect it to be accessed for any given users. However,
>  it does make for a useful basis to discuss a more general case of 
> data storage and access for a subsystem that might work in a similar 
> way but be accessed more frequently making avoiding lookups a little 
> more important.
> 
> Regards,
> 
> Gary
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/