[ZODB-Dev] Unofficial AdaptableStorage Wiki

[Shane Hathaway]

Phillip J. Eby wrote:
> It sounds to me like the principal difference between what you're doing 
> here and what I'm doing in PEAK, is that you want all oids (keychains) 
> to be de-referenceable through a single point of access.  In PEAK, I 
> assume that you give an oid directly to a DM that knows what it is.

Yes, that's a good way to put it.  The single point of access makes it 
so I only need one data manager.  ZODB doesn't (yet) make it easy to 
use multiple data managers without the application knowing about the 
multiple DMs.  Also, I'm targeting more than just ZODB, and I'd like 
cross-database references independently of ZODB.

> So, let's take your example above.  If I have the ZCatalog stored in 
> Postgres, its key is 45, accessed from the DM that does that 
> processing.  That DM would be responsible for knowing that (for example) 
> the BTree objects of the ZCatalog's state should be retrieved from 
> ZODB.  ZODB then has its own oid, the 8 byte string, which would have to 
> have been stored with the ZCatalog's state.
> 
> It seems like the idea in AdaptableStorage is that you want to decouple 
> that knowledge, so that a particular serializer doesn't have to know who 
> to give a particular reference to.  For my target application realm, 
> this isn't particularly useful because in practice, legacy databases 
> won't store arbitrary keys anyway.  :)  To put it another way, if I 
> understand correctly, the only time a keychain is helpful as an object 
> reference is if you can store one that has arbitrary length and 
> contents.  Is that correct?

Pretty much.  You could make a component that knows how to intepret and 
store specific kinds of keychains.

>> I think keychains are quite valuable, but since I haven't actually 
>> made much use of them yet, I don't have evidence to back it up.  I'm 
>> very open to better names for "keychain" and "domain mapper".  I'm 
>> also open to the idea that keychains and domain mappers should be 
>> scrapped. :-)
> 
> 
> They sound to me like things that are useful in the context of Zope and 
> pickle-ish backends.  That is, if you're using an RDBMS in The Way God 
> Intended (i.e. using columns for domain attributes as opposed to shoving 
> pickles into it), then it doesn't seem to buy you much.  In order to set 
> up the database, you have to know what the keys are going to be, and 
> what object will be responsible for dereferencing those keys, so why 
> worry about having a dynamic mapping from the key?  This seems much more 
> meaningful in the website construction/management sphere (with the 
> occasional jump out to an RDBMS for certain kinds of objects) than in 
> the realm of web-based applications that are more RDBMS-focused.

I'm not sure what pickles have to do with it... keychains aren't 
arbitrary.  But I do agree that purely RDBMS focused software might have 
little need for keychains.

> But of course it may be that I have missed your point entirely.  :)
> 
> Looking at the AdaptableStorage wiki has given me some ideas for 
> possibly adding "aspect serializers" to PEAK in some form.  It may be 
> that I have not understood what you actually mean by that, but I know 
> what *I* mean by that, and it's useful, so it was good to get the idea, 
> even if it's not your idea, if you know what I mean.  :)

I understand fully. :-)  I stole the word "aspect".  An aspect 
serializer (de)serializes specific parts of an object, which nearly 
always means that it (de)serializes a set of known attributes.  Object 
serializers delegate all work to a set of aspect serializers.  I could 
call them "atom serializers" and rename object serializers to "molecule 
serializers", but then when science turns atomic theory on its head 
again, I'll be out of luck. ;-)

Shane