Storage 4.0 Design Considerations

Last modified by Caleb James DeLisle on 2011/04/09 13:09

Goals

  • Faster more scalable storage engine.
  • Freedom from relational database model.
  • More features in Object/Class system.

Open Questions

  • Should nesting of classes be allowed? This is a desirable feature because it would allow us to define XWikiDocument, space and even wiki all as user defined classes and we get nested spaces and only need one load/store system for documents and objects.
  • Should classes be able to have methods? Currently, XClasses are not classes but structures.
  • Should we allow interfaces?
  • Should we allow inheritance?

Use Cases (what if's)

  1. User defines a class, instantiates an object of that class, then decides to add a property.
  • Does the object get a property added?

2. User defines a class, instantiates an object of that class, then decides to remove a property.

  • What happens to the value of the property in the object?

3. User defines a class, instantiates an object of that class, removes a property, then decides to add another property of a different type but with the same name.

4. User defines a class, instantiates an object of that class, removes a property, then looking at an object, realizes he really needs the value of that (now gone) property so he decides to try reverting the object.

  • Can he get the missing property back?
  • What is the class of the object which he has reverted?

5. User defines a class, instantiates an object of that class, removes a property, decides it was all a silly idea and reverts the class.

  • Do the objects get their property back?
  • If so, do the objects get the property back with the value they had to begin with?

6. User defines a class, instantiates and object of that class, then decides to move/rename the class.

  • Do the objects get modified?
  • Does reverting the objects bring back the old class?

7. User defines a class, instantiates and object of that class, then decides to delete the class.

  • Does reverting the objects bring back the old class?
  • What happens if the user defines another class with the same name?

Possible Solutions

A. Using classes and automatically modifying objects

  1. User defines a class, instantiates an object of that class, then decides to add a property.
  • User is allowed to edit the class in "scratch space" until they are satisfied and they are presented with a commit button to make it permanent. When they click commit they are prompted that X number of objects will have to be updated at the same time.
  • When they click OK, all objects of the class are modified and saved new versions of the objects are created
  • The class is saved separately so the new and old versions both exist on the system.

2. User defines a class, instantiates an object of that class, then decides to remove a property.

  • Same process as adding a property, new versions of the objects are saved with the property removed.

3. User defines a class, instantiates an object of that class, removes a property, then decides to add another property of a different type but with the same name.

  • Upon committing, the objects are all updated as per 1 and 2.

4. User defines a class, instantiates an object of that class, removes a property, then looking at an object, realizes he really needs the value of that (now gone) property so he decides to try reverting the object.

  • When he reverts the object, the object's class changes back to the old version of the class and thus the property is once again available.
  • User is warned that he is changing the class of this particular object so it will no-longer be the same class as other objects of the same class.

5. User defines a class, instantiates an object of that class, removes a property, decides it was all a silly idea and reverts the class.

  • Same as adding a property, the user is prompted that he will be changing X number of objects and just as a new version of the class is created, new versions of the objects are created.
  • Does it make sense to bring back the old values for the property? The object may have been significantly modified in the mean time and the old value may no longer have any meaning.

6. User defines a class, instantiates and object of that class, then decides to move/rename the class.

  • The history of a class must never be moved. Every object/document has an ID which never changes throughout it's life, objects reference this ID.

7. User defines a class, instantiates and object of that class, then decides to delete the class.

  • To delete the class and it's full history means deleting all objects. This will cause permissions issues.
Tags:
   

Get Connected