Native queries will run out of the box in any environment. This optimization is turned on by default. Native queries will be converted to SODA where this is possible. This allows 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 the bytecode is 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:
ObjectSet<Pilot> result = container.query(new Predicate<Pilot>() { @Override public boolean match(Pilot pilot) { return pilot.getName().equals("John"); } });
First the signature of the given class is analyzed to find out the types. This is used to constrain the type in the SODA-query. Then the bytecode of query is analyzed to find out was it does. When the operations a simple and easy to convert, it will be transformed to complete SODA query:
final Query query = container.query(); query.constrain(Pilot.class); query.descend("name").constrain("John"); final ObjectSet<Object> result = query.execute();
Native query optimization on Java requires db4onqopt.jar and bloat.jar to be present in the classpath. See "Dependency Overview". Current optimization supports the following constructs well:
Note that the current implementation doesn't support polymorphism and multiline methods yet.
db4o for Java supplies three different possibilities to run optimized native queries. By default native queries are optimized at runtime when the query runs the first time. This is the most convenient way because it doesn't need any preparations.
On certain environments (embedded runtimes, older java releases) this runtime optimization doesn't work. In such cases there are two alternatives. The compile time optimization and the class load time optimization. See "Enhancement Tools"
For more information on native queries optimization see Monitoring Optimization.