Native Queries will run out of the box in any environment. If optimization is turned on (default) Native Queries will be converted to SODA where this is possible, allowing db4o to use indexes and optimized internal comparison algorithms.Otherwise Native Query may be executed by instantiating all objects, using SODA Evaluations. Naturally performance will not be as good in this case.
For Native Query Java bytecode and .NET IL code are analyzed to create an AST-like expression tree. Then the flow graph of the expression tree is analyzed and converted to a SODA query graph.
For example:
.NET:
IList<Pilot> pilots = container.Query<Pilot>(delegate(Pilot pilot) {
return pilot.Name.equals("Michael
Schumacher")
&& pilot.Points == 100;
});
First of all the following code will be extracted:
query#constrain(Pilot)
Then a more complex analysis will be run to convert the contents of the #match method into a SODA-understandable syntax. On a simple example it is easy to see what will happen:
.NET:
return pilot.Name.equals("Michael
Schumacher") && pilot.Points == 100;
easily converts into:
CANDIDATE.name == "Michael Schumacher"
CANDIDATE.points == 100
Native Query optimizer for .NET is supplied in Db4obects.Db4o.Tools.dll. This assembly must be available in your project for successful NQ optimization.
The Native Query optimizer is still under development to eventually "understand" all valid C# constructs. Current optimization supports the following constructs well:
This list will constantly grow with the latest versions of db4o.
Note that the current implementation doesn't support polymorphism yet.
The specifics of Compact Framework platform are explained in NQ Optimization On CF2.0.
An alternative optimization practice can be found in Build-time Optimization For .NET article.
For more information on NQ optimization see Monitoring Optimization.