2002-04-02 version 2.0 |
- db4o now provides Client/Server functionality. See Db4o.openServer() and
Db4o.openClient(). - db4o now comes with clean transaction support. Disk write operations were rewritten to ensure 100% fail-safety and clean ACID behaviour. ObjectContainer#commit() now commits the transaction associated with the ObjectContainer. ObjectContainer#rollback() was newly added. - One single db4o.jar can now be run on all JDKs from 1.1.x to 1.4.x. The engine adjusts it's functionality to the available API methods automatically. - Thread-safety was completely reengineered. - The main API was refactored and split into two packages: com.db4o and com.db4o.ext. This allows the addition of an unlimited number of new features to com.db4o.ext while retaining lucidity in com.db4o. The ext() methods allow casting the respective Interface to full extended functionality. - Every ObjectContainer can now be configured individually with Ext ObjectContainer#configure() . Upon
creation of an ObjectContainer with any of the open statements, the global Configuration context is
copied to the new ObjectContainer.- db4o can now also be run on in-memory files. See the documentation to ExtDb4o.openMemoryFile(). db4o operates approximately three times as fast on memory files than in normal RandomAccessFile mode. The feature may be useful to store db4o byte data to other databases or media. - Cascaded activation, update and delete is now configurable per class and per field of a class. - The servlet functionality has moved to ExtObjectContainer.objectContainer(). - The update depth can now be configured globally. - Configuration#exceptionsOnNotStorable() can be turned on to analyse, if objects have storage problems due to a missing usable constructor or constructor code side events. - Configuration#setClassLoader() allows the use of a custom class loader for stored classes. - Configuration#refreshClasses() can be used to tell db4o to analyze all classes again in a running session. - ExtObjectContainer#bind(Object object, long internalID) allows the association of an object in memory with the id of a stored object. The mechanism can be used to replace stored objects and to reassociate objects in a running session with their stored equivalents. - The method setOut(PrintStream) was moved from the Db4o class to the
Configuration class. Use Db4o.configure().setOut(PrintStream)
or ObjectContainer#configure().setOut(PrintStream) .- The emergency shutdown mechanism now uses a JDK 1.3 shutDownHook instead of a response to finalize. This ensures a clean shutdown on CTRL + C. On JDKs 1.1.x and 1.2.x a shutdown is attempted in the finalizer. - Classes implementing java.util.Collection would loose null elements. Fixed. The change will cause null objects to be contained in Collections if member elements are deleted independantly. - Self references in member arrays could lead to exceptions. Fixed. - Updating objects of classes derived from java.util.AbstractMap would leave over one object of the translated type com.db4o.config.Entry for every entry. Fixed. - Endless loops were possible if callback events would call eachother. The behaviour was modified. Only one call on one callback method per object will be executed. - A timing problem in the engine shutdown could lead to the message "The database file is locked by another process." in a subsequent open. Fixed. - com.db4o.samples now contains another subfolder "constructors" to demonstrate, how db4o decides, which constructor to use. - ...and many, many more new features can be found in the JavaDocs. |
2001-11-29 version 1.5 |
- Version 1.5 required a file format change. Conversion of old 0.4x to 1.4x
database files takes place automatically upon opening a file for the first time.
Since the modified files are not backward compatible to earlier versions, please back up
your database files. - db4o is now available in four versions: - mobile edition (was: JDK 1.1.x) - community edition (was: standard edition) - professional edition (new) - dotnet edition for Microsoft's .NET platform - db4o no longer needs to create a lock file. Locking takes place internally within the database file. For performance reasons, the mobile edition does not lock files. It is the responsibility of mobile developers to ensure that only one thread in one VM accesses a db4o database file. - The new methods ObjectContainer#getID(Object) and
ObjectContainer#getByID(long) allow the use of the very performant internal db4o
IDs.- db4o now distinguishes between Unicode and non-Unicode database files automatically. To store strings in the more performant and less space consuming ISO8859-1 format, call Db4o.configure().unicode(false) before
creating a database
file with the first call to Db4o.openFile() .- The new method ObjectContainer#isClosed() allows to determine if an
ObjectContainer instance was closed by a previous call or
a possible emergency condition like an OutOfMemoryError .- The following deprecated methods were removed: - ObjectContainer#activate(Object) Use: ObjectContainer#activate(Object, depth) - ObjectContainer#deactivate(Object) Use: ObjectContainer#deactivate(Object, depth) - ObjectSet#current() You need to cache the result of ObjectSet#next() manually.- ObjectSet#isEmpty() Use: ObjectSet#size() == 0 - Db4o.echo(boolean) Use: Db4o.configure().messageLevel(level) - ObjectContainer#freeMemory() was renamed to ObjectContainer#purge() .- ObjectContainer#purge(Object) was added to allow more efficient
memory management in the mobile edition version. - Synchronisation was removed from the JDK 1.1.x version (now mobile edition) to provide maximum performance. - Upon an unexpected shutdown (typical: OutOfMemoryException ) a subsequent call to
Db4o.openFile() within the same JVM session could return the closed
ObjectContainer . Fixed.- Storing member objects explicitely with ObjectContainer#set() in
objectOnNew callback methods (not necessary, since db4o recurses automatically)
could lead to exceptions. Fixed.- Storing objects with references to classes derived from themselves would lead to exceptions. Fixed. - The db4o.jar format could not be used with Jikes and VAJ without unzipping it. Fixed. - The professional edition comes with the following new features: - encryption - password protection - a servlet framework |
2001-09-09 version 1.40 |
- JDK2 versions only: Memory management was greatly improved by switching to
WeakReferences. - Performance is not affected in a negative manner, since other improvements compensate the change easily. Performance should even appear to improve in most cases. The JDK 1.x versions also benefit from these changes. - ObjectContainer#freeMemory() now allows to discard all clean object indices
from memory. A call after ObjectContainer#commit() will achieve the lowest
memory footprint possible.- Using many commit() calls previously lead to more fragmentation of the database file than necessary. Fixed. As a result applications will produce drastically smaller database files. - ObjectContainer#deactivate(Object, depth) can now be used to set all fields of
any object to null / zero, even if the object is not stored to the
ObjectContainer. This allows to use
"naked" objects for queries, in spite of constructor or initialisation
side effects, that set member variables.
|
2001-08-08 version 1.30 |
- Automatic activation to the respective default activation depth is now
triggered by ObjectSet#next() . Applications that do not necessarily
iterate through all results of ObjectSets may encounter drastic performance and
memory usage improvements. Deactivating objects from within the iterator loop
may be used to keep memory usage at a very low level. Note
that the new lazy activation behaviour requires the ObjectContainer to remain open while the
ObjectSet is used. - ObjectContainer#deactivate(Object, depth) now allows to cascade deactivation
conveniently to any depth.- ObjectContainer#deactivate(Object) is deprecated. ObjectContainer#deactivate(Object,
1) can be used instead.- com.db4o.tools.Statistics can be used to print statistics about the used database file to System.out. All tools are distributed as sourcecode and they are not included in db4o.jar. - com.db4o.tools.Defragment is a new tool to defragment database files. Read the documentation thoroughly and backup database files before using this tool. - Configuration.messageLevel(int) now allows to specify, how
detailed db4o is to log events. Possible levels are 0 to 3. Use Db4o.configure().messageLevel(3) for
very detailed messages during debugging and to learn what is happening.- Configuration.callbacks(boolean) now allows to turn
ObjectCallback events off temporarily. This may be desirable for
maintenance operations. The Defragment tool operates with callbacks turned off.- Activation depth was partially inconsistent. Fixed. - ObjectContainer#activate(Object, depth) and ObjectContainer#deactivate(Object,
depth)
now also lead to the desired effect, if an array is passed as an argument.- Exception handling was modified to prevent successful shutdowns on fatal errors like OutOfMemoryError or StackOverflowError. - A major bug that could lead to database file corruption on the above fatal errors, CTRL + C and other abnormal database engine process terminations was fixed. - Multidimensional arrays containing empty ( [] ) or zero ([0] )
dimensions would produce exceptions. Fixed.- ObjectClass#rename() was only possible, if an old version of
the class was present. Fixed.- com.db4o.samples now contains the subfolders "activate", "callbacks" and "update" with examples to explain activation and callback methods and the update behaviour of ObjectContainer#set() .
|
2001-07-06 version 1.20 |
- All ObjectContainer methods are now threadsafe. Usage of db4o
in Java Server Pages and servlets is now possible without additional
synchronisation efforts.- Db4o.openFile() now allows multiple calls with the same file name.
Every call will return the same ObjectContainer . Every openFile()
needs a corresponding ObjectContainer#close() . db4o will close the respective
ObjectContainer on the last call.- An additional file locking mechanism provides more safety in concurrency environments. - Exception handling was enhanced to provide more developer information, for instance on using a closed ObjectContainer or on not being able
to find a class in the CLASSPATH.- All db4o versions now run on Tomcat. A special CLASSPATH issue: It is recommended to place db4o.jar in the WEB-INF\lib of your webapp and not to include db4o.jar in the global CLASSPATH. - The RandomAccessFile patch for EPOC is now incorporated into the JDK 1.x standard versions. Accordingly a special EPOC version is not necessary anymore. - JDK2 Collection classes would produce problems on certain JDKs. Fixed. Storing TreeMap and TreeSet objects now also persists possible custom Comparators. - If not all previously used applications classes were accessible with Class.forName(className) , some
methods like ObjectContainer#get(null) would throw exceptions. Fixed. db4o now
marks classes as unusable during startup and ignores objects of unavailable classes.- The new ObjectConstructor extension of ObjectTranslator allows writing
custom translators that construct the object.- A translator that uses Java serialisation is now built into the engine. It can be optionally used to quickly implement persistence for classes with problematic constructors. - The sourcecode of all built-in translators is delivered with the download in ../com/db4o/samples/translators. - To ensure future compatibility with C# keywords, 2 ObjectTranslator method names were
renamed:ObjectTranslator#in() >> ObjectTranslator#onStore() ObjectTranslator#out() >> ObjectTranslator#onActivate() - The methods ObjectContainer#activate(object), ObjectSet#current() and ObjectSet#isEmpty() and Db4o.echo(boolean) are deprecated. See the documentation for replacements. |
2001-06-07 version 1.10 |
- automatic activation on querying objects changed to preconfigured depth of 5, independent of
the QBE example object, configurable globally and class-specific. - additional ObjectContainer#activate(Object, depth) method to activate a tree
of any size with one call.- explicit commit() method for checkpoints.- support for simple type wrappers in Object variables.- support for multi-dimensional arrays. - query evaluation mode changed to "contains" for arrays. - support for Vector and Hashtable including "contains" queries. - JDK 2 specific: - support for all Collection classes including
"contains" queries.- support for private or parameterised constructors. - support for inner classes. - ObjectCallback methods to allow code execution upon storage events. Examples of
use: cascaded delete, cascaded copy and cascaded update.- Configuration interface for - refactoring classnames and fieldnames. - customized activation depths. - customized update depths. - activation events. - translation of objects on storage and instantiation. - configurable storage of transient members. - ignoring fields in queries. - automatic schema evolution now allows to change the data type of members. - db4o used to store and restore static members and use them for query evaluation. Fixed. - extreme regression tests allowed to find and fix some rare bugs that could occur on the deletion of objects. - Java Web Start problem fixed. - additional security handling to prevent user application code to open a database file twice. - performance improvements > 10%. - regression test code is included with the download. |
2001-01-31 version 1.0 |
- completely revised interface. - Smart reflection allows the storage of objects without any modifications to their class files. - A JDK 2 version enables the storage of private and protected members. - Unicode version. - A dedicated EPOC version contains a workaround for an EPOC JVM bug. - members of class Object are stored.- Interface members are stored.- storage wrapper for java.util.Date |
2000-12-11 version 0.40 |
- fully revised architecture and file format. - x50 performance boost. - x50 decrease of database file size. - x50 decrease in resource consumption. - delete() is implemented. - 20 samples allow a quick start. - messages are off and can be turned on with echo() |
2000-10-22 version 0.20 |
- The new db4o JDBC interface completely exports and imports object data. The
mechanism allows the migration of db4o data in case of future changes to the db4o
file format. The jdbc documentation provides further
information. - The provided sourcecode packages were revised. - Fixes 0.11 to 0.13 are included. |
2000-09-18 version 0.10 |
- db4o was repackaged. All classes are now found in com.db4o.*. - The interface naming was streamlined. PersistentHandle >> DbHandle. getPersistentHandle() >> db(). - db4o is now distributed as a jar. - Navigation through member links is now possible with PersistentObject.db().activate() - Instantiation logic was rewritten to support this feature. - The storage format was improved for less space consumption and better performance. |
2000-08-20 | - Support for inheritance. - Test routines in com.db4o.test.Test.java ensure a consistent stability of implemented features. |
2000-08-08 | - db4o opens the public mailing list db4o@egroups.com. |
2000-08-05 | - Support for arrays. - The schema updating mechanism is started automatically with every start of the engine. |
2000-07-18 | The indexing mechanism is implemented with a red-black binary tree. A test with the benchmark database showed an improvement by more than 500%. |
2000-07-08 | - The read algorithm now only reads objects, which are actually needed. - First concept of the db4o query interface |
2000-07-06 | First JDBC import run on an SQL database with 1 MB size. Large amounts of data are now available for testing and performance analysis. |
2000-06-30 | - Support for Double, double, Float, float, Short, short, Character, char, Boolean, boolean, Byte, byte. - Rewrite of YapVariables to implement a clean structure instead of two objects per data type. |
2000-06-23 | Support for Long, long, Integer, int, Boolean and boolean. |
2000-06-17 | - Update is implemented. db4o.set(object) forces a depth(1) equality check on all members. - Address indirection is implemented. see YapProxy for details - Extensions of com.db4o.collection.Comparator avoid reflection in comparisons. |
2000-06-15 | joss is renamed to db4o. Thanks to Christian Runte for the suggestion. |
2000-05-28 | get() and set() are implemented. Java classes with String- and Object-Members can be stored and retrieved. |
2000-05-28 | Begin of this log. |
2000-04-04 | Thanks to Brian Lee Price for the contribution of ideas to yap. |
2000-01-01 | The first line of code. |
2001-12-7 version 1.5.03 |
- Community and Professional edition only: A bug in the new threaded 1.5 file locking
mechanism would prevent access to the database file from other JVM sessions or
java.io.File even after ObjectContainer#close()
was called. Fixed. - ObjectTranlator handling was modified to allow use and translation of classes not present in the current JVM session. |
2001-10-27 version 1.45 |
- An addition to the fix for version 1.43, specifically for classes derived from the JDK collection classes. |
2001-10-25 version 1.44 |
- Deleting objects derived from java.util.Date could lead to exceptions during delete. Fixed. |
2001-10-22 version 1.43 |
- Storing new objects in objectOnNew callback methods could produce exceptions, if these objects were also declared as members in the class the callback method was invoked on. Fixed. |
2001-10-03 version 1.42 |
- Automatic cascaded delete for String, Array and simple type members would not
execute, if more than one attribute was changed. Fixed. As a result the database
file will grow slower. - Automatic cascaded delete for simple types and Strings stored to untyped Object
Arrays was implemented. - Database file freespace defragmentation management was further improved. This will also lead to a more compact database file. - Portions of the object update mechanism were rewritten. The speed of updates should be observed to improve considerably. |
2001-10-02 version 1.41 |
Extending java.util.Date would lead to NullPointerExceptions. Fixed. Note: The Date of such objects is still not used as a constraint in query evaluation. |
2001-08-15 version 1.30.02 |
Lazy activation was not perfectly threadsafe. Fixed. Null pointer exceptions during ObjectSet#next() were the typical symptom, possibly forcing an emergency shutdown of the engine. |
2001-08-11 version 1.30.01 |
Using multiple database files, closing one would prevent subsequent duplicate open calls on the remaining open files. Fixed. |
2001-07-15 version 1.25.03 |
- ObjectContainer#get(null) would fail, due to an error in our deploy script. Introduced with
version 1.25. Fixed. Surprisingly ObjectContainer#get(null) was not part of the
regression tests. Added. - Automatic activation on retrieval was broken. Introduced with the 1.25 deep-stack-feature. Fixed. |
2001-07-14 version 1.25.01 |
Updating simple type wrappers or strings stored to untyped (Object) array variables would throw exceptions. The problem typically occured on updating HashMaps or TreeMaps. Fixed. |
2001-07-12 version 1.25 |
- On VMs that do not provide unique System.identityHashCode() values, object
references could be lost in high traffic applications. All sorts of symptoms
were possible. Typically new objects were created, instead of updating
existing ones. - Bidirectionally linked code could produce stack exceptions on set(). Fixed. - Large custom linked lists (1000 objects or more) would lead to stack exceptions. Fixed. Code was rewritten to replace recursion with loops. - Collections deriving from Map were not stored. Fixed. - Update performance speed was drastically improved, especially for arrays. Depending on applications a factor 10 improvement or more may be noticeable. - ObjectField#rename did not work. Fixed. - Code to document how to rename classes and fields is supplied in com.db4o.samples.rename. |
2001-06-15 version 1.11 |
The QBE query optimizer could omit certain results in certain n-to-n relationship- and data-combinations. Fixed. |
2001-03-06 version 1.04 |
- Db4o.use(javax.jnlp.JNLPRandomAccessFile) was implemented to allow
the usage of db4o within a Java Web Start
application.
|
2001-02-26 version 1.03 |
- ObjectContainer.get(null) would result in a NullPointerException
if empty classes were present in the data file. Introduced in 1.01. Fixed.- Enhanced benchmark code. |
2001-02-09 version 1.02 |
- A file memory leak introduced in 1.0 caused continuous growth of the data
file on updates. Fixed. - Performance improvement with the great help of a coding contest in the German Java newsgroup de.comp.lang.java. |
2001-02-02 version 1.01 |
- Unicode versions only: String query-by example would not produce any
results. Fixed. - ObjectContainer.get(null) dump was accelerated and is now
independent of
possible constructor side effects.
|
2000-12-16 version 0.43 |
Fix for simple type array bug and array update. |
2000-12-14 version 0.42 |
- delete() inconsistency and crash fixed - Db4o.delete(null) no longer crashes. - numerous SQLImport() fixes |
2000-12-12 version 0.41 |
Performance update only. |
2000-11-15 version 0.22 |
Javadocs were generated for version 0.21 to satisfy the request from the mailing list. |
2000-10-25 version 0.21 |
The finalize() function in Db4o now enforces that the engine is shut down correctly with Db4o.down(). System.runFinalizersOnExit(true) is set for the moment, in spite of the potential errors on some VMs. A better method will be implemented in the near future. |
2000-10-20 version 0.13 |
- A second call to Db4o.set() would not update descendant values. Fixed. - A workaround for an EPOC JDK bug is included. |
2000-10-08 version 0.12 |
Query evaluation fix. Ancestor values are no longer ignored. |
2000-10-06 version 0.11 |
- Major speed enhancement - Fix to automatic schema recognition. Descendant changes no longer produce exceptions. |
2000-08-28 | - String updating reenabled. - Test routine now includes update and more array features. - Null values are possible in arrays. - A file format change was necessary for arrays. |