Updating an object can be a very comlicated task. Let's take an example to understand what is happening:
Let's use a simple class User with 2 attributes :
- a name (String)
- a date of birth (Date)
The type date has a fixed size : it can be represented as long but the size of the type String depends on its content!
Suppose we insert a new User("Olivier",new Date()) in the database.
Now we want to update the name of the user to Olivier Smadja.
We first need to load the user
User user = odb.getObjects(new CriteriaQuery(User.class,Restrictions.equals("name","Olivier"));
Then we sets the new name
user.setName("Olivier Smadja");
And then call the odb.store method
odb.store(user);
ODB will detect that it must execute an update as the object user is its cache.
The problem is that the String name is much bigger now, and there is no more space in the file to change the value of the attribute name without overlapping another object in the file. So we should rewrite the entire object at the end of the file and mark the current as deleted. But this is very costly to do that. So we try to apply In Place Update when possible.
In Place Update
In Place Update is a strategy to write only object modifications instead of rewriting the entire object. This is done by writing in the original position of the objects. In Place Update is easy when modifications are done on fixed size types like Dates and numbers.
To try to apply this strategy to String, when writnig a String, ODB always reserve some extra space to allow later in place update. The factor of the extra space can be configured using org.neodatis.odb.core.Configuration.setStringSpaceReserveFactor and it can not be changed after the creation of the database.
The default value is 3. So, when writing a String, if its size in bytes is 8, ODB will reserve 24 bytes. So in place updates will be allowed for string with a size (in bytes) up to 24.
In place update stategy turns update operations much more faster. The drawback is that objects uses much more space!
In Place update can be enable/disable using Configuration.setInPlaceUpdate(true / false). The default value is true.
Perhaps TrueZip might help with this issue or this goal.
It seems like having a per-class, per-virtual file of fixed sized blockjects might ease the abstraction(s) somewhat.
It does tar archives too so compression is optional, not required.