[rucksack-cvs] CVS rucksack

[alemmens]

Update of /project/rucksack/cvsroot/rucksack
In directory clnet:/tmp/cvs-serv9793

Added Files:
	do.txt done.txt notes.txt 
Log Message:

Add list of things to do, list of things done, and some random notes.




--- /project/rucksack/cvsroot/rucksack/do.txt	2006/08/31 15:53:58	NONE
+++ /project/rucksack/cvsroot/rucksack/do.txt	2006/08/31 15:53:58	1.1
DO: 

- Handle initargs in LOAD-OBJECT and UPDATE-PERSISTENT-...

- Initialize transient slots during LOAD-OBJECT.

- Figure out if there's a better way than
    (eval-when (:compile-toplevel :load-toplevel :execute) ...)
  to make sure that class definitions within a WITH-RUCKSACK are treated
  as top level definitions.

- Maybe signal a continuable error when the in-memory class definition does
  not correspond to the most recent schema.  If the user decides to
  continue, UPDATE-PERSISTENT-INSTANCE-... will be called when necessary.

- What about in-memory persistent instances when the class definition
  changes?  We should make sure that those are updated too.  There seem
  to be three strategies:
  1. Rely on Lisp's normal UPDATE-INSTANCE-FOR-REDEFINED-CLASS mechanism.
     Then the programmer must write methods for both UPDATE-INSTANCE-...
     and UPDATE-PERSISTENT-INSTANCE-... .  That seems error prone.
  2. Remove all instances of the redefined class from the cache.
     Then the objects will be loaded from disk again, and U-P-I-F-R-C will
     be called automatically.  This has the disadvantage that all values
     of transient slots will be gone.
  3. Forbid it and signal some kind of error.

- Get rid of the PROCESS-A-CLASS-OPTION stuff and handle the :INDEX class
  option in a way that's compatible with AMOP.

- I'm not sure that :INCLUDE-SUBCLASSES NIL makes sense for
  RUCKSACK-MAP-SLOT.  Think about this.

- Does indexing in example-1 work correctly if we don't use
  *RUCKSACK* in WITH-RUCKSACK?  Maybe WITH-RUCKSACK should always
  bind *RUCKSACK*?

- There's still a btree bug that's uncovered by the stress test.
  Fix it.

- Check that btrees actually signal an error for duplicate keys.
  Handle those errors correctly for slot indexes.

- Make sure that the GC gets rid of all obsolete object versions.

- Add export/import to s-expression format.  This is necessary
  for migrating existing rucksacks to a new version of Rucksack.

- Give each transaction its own commit file (the name can be generated
  from the transaction id).  That's one step towards avoiding locks
  on transaction commit.

- Deal with CHANGE-CLASS: call UPDATE-PERSISTENT-INSTANCE-FOR-DIFFERENT-CLASS
  when necessary.  (Maybe it's never necessary and we can just use the
  existing UPDATE-INSTANCE-FOR-DIFFERENT-CLASS mechanism?)

--- /project/rucksack/cvsroot/rucksack/done.txt	2006/08/31 15:53:58	NONE
+++ /project/rucksack/cvsroot/rucksack/done.txt	2006/08/31 15:53:58	1.1
* 2006-08-31

- Write test cases for schema updates and user defined methods for
  UPDATE-PERSISTENT-INSTANCE-FOR-REDEFINED-CLASS.

- Indexing: compare the specified slot/class indexes to the indexes that
  exist in the Rucksack, *not* to the indexes specified in the previous
  version of the class definition.  Otherwise we get inconsistencies
  when we recompile class definitions from scratch with a Rucksack that
  already exists.

- Write test case for slots with redefined indexes.  This also tests
  the default method for UPDATE-PERSISTENT-INSTANCE-FOR-REDEFINED-CLASS.

* 2006-08-30

- FINALIZE-INHERITANCE: Compute slot diffs for obsolete schemas.

- More work on UPDATE-PERSISTENT-INSTANCE-FOR-REDEFINED-CLASS.

* 2006-08-29

- Partial implementation of UPDATE-PERSISTENT-INSTANCE-FOR-REDEFINED-CLASS
  & friends.

* 2006-08-29

- Example-1: indexing should still work after recompiling.

- RUCKSACK-UPDATE-SLOT-INDEXES: Remove indexes for old slots that
  don't exist anymore.

- Some work on schema updates.

- Compute persistent slots at the right moment.


* 2006-08-26

- Make sure that indexing works correctly with subclasses.
- Fix some more indexing bugs.


* 2006-08

- The class and slot indexes were normal hash tables, but they should be
  persistent objects like everything else: I replaced them by btrees.

- Get process-lock and process-unlock working on SBCL (thanks to Geoff Cant).


* 2006-08

- Save and load the index tables when closing/opening a rucksack.

- Implement the :UNIQUE slot option.

- Improve predefined slot index specs.


* 2006-08

- Add a SERIAL-TRANSACTION-RUCKSACK class that allows for only one transaction
  at a time (by using a transaction lock).  This allows for a fast track
  towards a working Rucksack implementation.  Then parallel transactions
  can be added later.

- Don't do any GC at all while a transaction is writing objects to disk.
  Instead we keep track of the amount of disk space allocated by the committing
  transaction.  Then we do a (partial) GC immediately after committing the
  transaction.
--- /project/rucksack/cvsroot/rucksack/notes.txt	2006/08/31 15:53:58	NONE
+++ /project/rucksack/cvsroot/rucksack/notes.txt	2006/08/31 15:53:58	1.1
;; $Id: notes.txt,v 1.1 2006/08/31 15:53:57 alemmens Exp $

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Some random notes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

* UPDATE-PERSISTENT-INSTANCE-FOR-REDEFINED-CLASS & friends.

  What should we do when the class has been redefined more than once
  before an instance is loaded?  Example: an instance of class PERSON
  (with schema version 0) was saved.  Now PERSON is redefined twice,
  and the most recent schema for class PERSON has version number 2.
  Ideally, UPDATE-PERSISTENT-INSTANCE-... would be called twice.  But
  that doesn't work in practice, because we can only allocate an instance
  corresponding to the most recent class definition.

  Suppose that version 0 of the PERSON class had an AGE slot, version 1
  discards the AGE slot and adds a YEAR-OF-BIRTH slot, and version 2
  discards the YEAR-OF-BIRTH slot and adds a BIRTH-DATE slot.  Suppose
  also that there are PERSON instances corresponding to version 0,
  instances of version 1 and instances of version 2.

  When loading instances of version 2, we don't need to do anything special
  because version 2 is the most recent version.  For instances of version 1,
  UPDATE-PERSISTENT-INSTANCE-... will be called with BIRTH-DATE as added
  slot, YEAR-OF-BIRTH as discarded slot and the property list (YEAR-OF-BIRTH
  <year-of-birth>).  For instances of version 0, UPDATE-PERSISTENT-INSTANCE-...
  will be called with BIRTH-DATE as added slot, AGE as discarded slot and
  the property list (AGE <age>).

  So UPDATE-PERSISTENT-INSTANCE-... will be called exactly once, and it
  needs to inspect the lists of added/discarded slots if it wants to handle
  multiple version changes.

  Whenever a schema becomes obsolete, we mark it as obsolete and register
  the names of the slots that were added and the slots that were discarded
  (by the most recent version, compared to this version).