Topic on Talk:Requests for comment/DataStore

Right now this looks a lot like how we interact with memcache which is probably good -- but one of the nice things about use a database is that we know what's going to be coming back; and what the defaults are when we push partial data in. It is also possible with a DB to do simple upgrades to complex datatypes (e.g. add/modify columns).

I feel like this needs some sort of method to perform migrations & the ability to set default values at install time (much like our database updater.)

We may wish to enforce typing as well with something similar to ContentHandler such that we know what is currently in a key.

No, this completely contradicts the purpose of my proposal - it's intentionally schemaless. If a more structured storage is needed, it's outside of this RFC's scope.

OK; but it's persistent data -- therefore it's expected to always be there; there shouldn't be a huge amount of boilerplate around making sure the value exists and if not filling it in like you would have in memcache. Therefore you have to manage it across versions -- how would you do a multiversion upgrade with this if you don't know what's in the key? How do you ensure the data is initially populated? How do we ensure that this doesn't explode with eventually unused keys? IMO, there must be some method of managing it in software.

I guess what I'm really trying to push here is that if you really just want to use the same API and the same boilerplate requirements as we have around memcache -- this should just transparently come into play when we specify a TTL of 0; there should be no need for the programmer to manage this.

We'll still have all the problems of managing the keyspace with ttl's of zero though.