notes file

diff --git a/notes b/notes
new file mode 100644 (file)
index 0000000..b4e0155
--- /dev/null
+++ b/notes
@@ -0,0 +1,27 @@
+Data::Store.
+
+everything has to be a capability.
+
+and, more fun, everything has to be a parameterised capability.
+
+the reason for this is that different stores are going to be able to handle different levels of querying. so.
+
+basic functions -
+
+  insert $data
+
+  update $selector, $changes
+
+  delete $selector
+
+  search $selector
+
+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
+
+  insert_multi \@data
+
+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.
+
+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).
+
+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 ;)