[DGD] Persistent Users

[Raymond Jennings]

Considering that you'd need a new birth certificate or a court order...

On Fri, Sep 23, 2016 at 2:49 PM, <bart at wotf.org> wrote:

> 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/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>