[Zodb-checkins] CVS: Packages/bsddb3Storage - FullImplementation.txt:1.3

[barry@digicool.com]

Update of /cvs-repository/Packages/bsddb3Storage
In directory korak:/tmp/cvs-serv12670

Modified Files:
	FullImplementation.txt 
Log Message:
Some minor updates, typo fixes, and extra notes.  This really needs to
be sync'd with the nomenclature being used in the new Full.py.



--- Updated File FullImplementation.txt in package Packages/bsddb3Storage --
--- FullImplementation.txt	2000/11/09 16:47:31	1.2
+++ FullImplementation.txt	2001/03/30 00:17:36	1.3
@@ -21,11 +21,17 @@
 
     record -- {(oid, tid) -> (vid, nv, data, pre)}
 
-       Data record meta-data.
+       Data record meta-data.  metadata about a revision ("defined:
+       object & a serial number, aka transaction id").
 
        (oid, tid) -- 8-byte object id and 8 byte transaction id
                      (timestamp)
 
+       (vid  -
+        nv   - non-version transaction id
+	data - transaction id of the transaction that wrote the data
+	       in the most recent, live, pickle
+
        (vid, nv, data, pre) -- 8-byte version id, 8-byte previous-record
           transaction id, 8-byte non-version-record transaction id, 8-byte 
           pickle transaction id.  
@@ -46,27 +52,35 @@
 
     versions -- {vid -> version}
 
-       Version id to version index
+       Version id to version strings index
 
        vid -- 8-byte version id
 
        version --> version name
 
-    vidss -- {version -> vid}
+    vids -- {version -> vid}
 
-       Version to version id index
+       Version strings to version id index
 
     current -- {oid -> tid}
 
        Current-records.
 
     currentVersions -- (vid --> [oid])
+
+       Which oids have been modified in a version.
+
+    ObjectReferenceCount -- (oid -> count)
 
-       Whic oids have been modified in a version.
+    pickleReferenceCount -- ((oid, tid) -> count)
 
+    references -- ((oid, tid) -> [oid])
+
+	Pickle references (is it cheaper to pickle sniff?)
+
   Transaction strategy
 
-    ZODB has it's own time-stamp-based transaction system. I will
+    ZODB has its own time-stamp-based transaction system. I will
     be using Berkeley DB's transaction system to implement the storage's
     responsibilities wrt atomicity.
 
@@ -134,6 +148,47 @@
         "unsupported" Berkeley DB with some pitfalls that I'm unaware of.
 
     Initially, I will pursue option 1.
+
+------------------------------
 
-    
+when looking for an object, we get an oid and a version string
 
+    - lookup vid from version string (vid == 0, then version string == '')
+    - lookup in the current table, get the tid for the oid for the
+      most recent change for the object
+    - then given oid+tid, get the "record" data which gives us among
+      other things, the vid for the current change
+    - if current change vid == argument vid, then the object has been
+      changed in that version, so look up pickle using the `data' tid
+      and the oid, and return that pickle
+    - else, the object hasn't been changed in that version, so return
+      the non-version pickle by getting the `nv' tid and lookup that
+      record in the pickle table.
+
+Note: is it worth doing the indirection of non-version tid to pickle
+table.  Right now, nv is a pointer back to the record table and it
+might make sense to unwrap that level of indirection and point
+directly to the pickle table.  UPDATE: we can't do this because we
+need to return the serial number of the non-version and that's only in
+the metadata record.  Jim is going to review the contract to see if
+that's strictly necessary.  For now, keep it the way it is.
+
+Note: undo currently deletes records but (eventually) it should undo
+by writing a new record.  Also makes packing easier, re-do, lot of
+other benefits.  Unfortunately requires an API change -- pushed off to
+"ZODB4".
+
+The DB_DUP tables are this way because they implement lists of things,
+like lists of oids, by duplicate records.
+
+Q: Should referenceCount table maintain the number of "record"s that
+point the object or the number of pickles that point to the object,
+given that multiple records can point to the same pickle.  JF: thinks
+it ought to be the number of pickles, but doesn't know for sure.
+Won't know for sure until we address GC.
+
+Note: the "references" table is a cache of object references in a
+record (maybe it should be the orefs in a pickle).  Jim also thinks he
+did an analysis that indicated pickle sniffing was faster than db
+lookup.  Should check that -- he didn't change Packless and thought he
+would have.