Storage Dispatch Design Doc
Document Actions
A description of the changes that will be covered with some new work on storage dispatch functionality
Motivation
Much or our repository and storage code has always been a bit
crufty. For example, some places it looks for an index.cnxml file
or handles objects differently if their id starts with "m" vs. "col".
This has become much more important to fix recently, though, because we
are trying to add in support for other types of modules, like
OMDoc. To increase support for other document types, we need to
refactor our code so that the storage mechanism depends on the type of
the object, and so that new types can be added without changing code in
the repository.
New Functionality
To Connexions users, this should show absolutely no changes. All modifictions are on the backend of the system and should not effect the way the system looks at all. For Rhaptos users/developers, though, the API of RhaptosRepository and RhaptosModuleStorage should be cleaned up and much easier to use. This will make new document types much easier to suppose and new features easier to program.One new piece of functionality will be that every module will have a persistent object in the ZODB, instead of being completely transient. This will make new features easier because the ModuleStub object in the ZODB will can be used for some purposes that used to require access to the CVS or Postgres backends.
Location
All the changes are in the RhaptosRepository and RhaptosModuleStorage products. They will live on the storage-dispatch branch of SVN. The user should not see any changes to interface.Impact
This should impact other products by speeding up some accesses to modules by keeping some data stored in the ZODB. This will also make new development for supporting OMDoc much easier.Implementation Steps
- Write Unit tests to test the new code.
- Generate new storage interface files to use a better API than our current implementation.
- Write a StorageManager in RhaptosRepository that will handle type-base storages.
- Refactor ModuleVersionFolder into ModuleVersionStub, which will persist in the ZODB.
- Refactor ModuleVersionFactory into ModuleVersionStorage, which will know to use type-based storage.
- Refactor RhaptosRepository to use the type-based storages.
- Test
- Rollout
- Change existing code to make use of the ModuleVersionStub and other performance increases
- Test
- Rollout
Last modified 2006-06-15 11:15
