notes

   1 Data::Store.
   2
   3 everything has to be a capability.
   4
   5 and, more fun, everything has to be a parameterised capability.
   6
   7 the reason for this is that different stores are going to be able to handle different levels of querying. so.
   8
   9 basic functions -
  10
  11   insert $data
  12
  13   update $selector, $changes
  14
  15   delete $selector
  16
  17   search $selector
  18
  19 note that the data spec for insert has to be a single one - some stores may need to extend the api to allow extra info to it and I don't want to stop them. for the same reason, we want
  20
  21   insert_multi \@data
  22
  23 rather than just taking an array. while that only allows extension to a single modifier AFAICS at least that way it's possible to provide an option in the modifier that says "actually @data consists of pairs of [ $data, $modifiers ]" or similar.
  24
  25 note also that the types of each $selector don't have to be the same. some stores will be able to search by more complex things than they can update or delete by. now, admittedly, you can paper over that if it's a by-id thing by doing search then an update by that id or whatever but there may be layers at which we want to know that. I -don't- want to lose information that can have a substantial performance impact (XXX try and figure out what weird cases here are).
  26
  27 basically, the logic currently existing within storage moves to be a per-table thing. We will have to vary this a bit when we deal with things like joins - I think basically the store becomes the equivalent of the entire FROM clause in that case ... not entirely sure how that works. My gut feeling is there should be a type constraint that covers what a particular store operates on - though the Kioku driver will probably have a type of Object ;)