For some often used types db4o implements a special type-handling. This can inflict some issues.
The java.sql.Date extends the standard java.util.Date-type. The date-type is treated like other value-types such as strings, integers etc. Unfortunatly this isn't true for the java.sql.Date-type. This also means that the SQL-date type cannot be store correctly. When you retrieve a SQL-Date type it will contain the wrong date.
The solution is to use only the normal JDK-Date. Theirs no reason to use the java.sql.Date-type.
db4o uses special type-handlers for collections to improve efficiency. This also means that db4o makes some assumptions about the collection. It assumes that all collection-methods are implemented and work properly. This isn't true for special collections like the JDK unemployable collections or maybe for you own special collection.
For example this simple collection which doesn't implement all methods:
class MyFixedSizeCollection<E> extends AbstractCollection<E>{ private E[] items; public MyFixedSizeCollection(E[] items) { this.items = items; } @Override public Iterator<E> iterator() { return Arrays.asList(items).iterator(); } @Override public int size() { return items.length; } }
This collection will create exceptions when you try to load it. Because db4o uses the clear and add-methods on the collection.
try { ObjectSet<CollectionHolder> holders = container.query(CollectionHolder.class); MyFixedSizeCollection<String> collection = holders.get(0).getNames(); } catch (Exception e) { // this will fail! The db4o collection-storage // assumes that collections support all operations of the collection interface. // db4o uses the regular collection-methods to restore the instance. e.printStackTrace(); }