In order to work effectively with db4o
you must understand the concept of
Activation. Activation controls the amount
of referenced objects loaded into the memory. There are two main
pitfalls that you must be aware about.
One common pitfall is to access not activate objects. This usually results in null pointer exceptions or invalid values. This happens when you navigate beyond the activated object-graph area. For example, we have a complex relationships and follow them:
Person jodie = QueryForJodie(container); Person julia = jodie.Mother.Mother.Mother.Mother.Mother; // This will print null // Because julia is not activated // and therefore all fields are not set Console.WriteLine(julia.Name); // This will throw a NullPointerException. // Because julia is not activated // and therefore all fields are not set string joannaName = julia.Mother.Name;
Dim jodie As Person = QueryForJodie(container) Dim julia As Person = jodie.Mother.Mother.Mother.Mother.Mother ' This will print null ' Because julia is not activated ' and therefore all fields are not set Console.WriteLine(julia.Name) ' This will throw a NullPointerException. ' Because julia is not activated ' and therefore all fields are not set Dim joannaName As String = julia.Mother.Name
This will result in a exception. Because by default db4o only activates object up the a depth of 5. This means that when you load a object, that object and all object which are reachable via 4 references are activated.
There are multiple solutions to this issue.
Having a high activation-depth makes working with db4o much easier. However activation can take a long time with deeper object graphs and become a serious performance bottleneck. The same applies when using cascade activation on almost all types. To reduce the time spend on activating objects, you need to be more selective about what to activate and what not.