db4o 7.0 has been released as a beta for the Java development community. The final release will be in Q1 2008, after community signoff and support for .NET has been added. The new version (download here) adds transparent activation, a new caching mechanism, better exception handling, unique constraints, and client/server enhancements. The "transparent activation" feature enhances performance by only loading the absolute minimum object tree that the application requires. db4o saves an object tree, of course, by walking the set of references an object contains. Loading an object tree back in can be detrimental, however, if the object tree is quite large. Thus, older db4o releases allowed programmers to manually set how far down the object tree should be loaded (i.e., one level, or three, or all levels.) The new transparent activation feature alters the load feature by only loading elements of the tree as it's required. While this was introduced as a feature back in db4o 6.3, the 7.0 release adds Java collection support, build-time instrumentation, and support for mixed-cases (transparent activation plus manual activation.) Performance has also been improved through the use of a new cache, batching of asynchronous messages, and the use of a new BTree algorithm that results in lower memory consumption at runtime. Prior versions of db4o limited exposure of exceptions, because the design was meant to "always work." Since this limited the ability of programmers to debug issues, db4o now has a complete exception handling implementation. Unique constraints for objects are also now supported, in response to "the RDMS guys' whining for unique constraint support". One normally doesn't look for unique constraints in an object database, but if it's desired, db4o now supports it. Client/Server mode has also been drastically enhanced. Instead of marshalling and unmarshalling objects, it now passes objects directly between client and server if embedded mode is used. The TCP/IP mode still has to marshal the objects, but the normative use db4objects expects is through the embedded container. That said, the client/server mode provides concurrent transactions in a single VM, and the networked mode - while slower - provides the capability for multiple VMs, a requirement for scalable systems of record. Starting a server is very easy:/* start a background thread, listening on port */ ObjectServer server = Db4o.openServer(config, port); /* provides access to username/password */ server.grantAccess(user, password);Connecting to the server is just as easy:ObjectContainer container=Db4o.openClient(hostName, port, user, password);TCP/IP mode supports all of the same functionality that the embedded mode does, with the caveats being that speed is affected (because objects do have to be marshalled) and object identity is also changed (because identity at the object level is handled on a per-VM basis.) This is a major release for db4o, and the enhancements make it far more suitable for traditional Enterprise Java environments.

Good work as usual. Three questions: 1) Is the dubious concurrency model fixed (read committed just doesn't cut it for all applications - ours range from mostly read to extremely hot spot write intense) 2) LINQ support? 3) Any improvements in the way object graphs are projected (i.e. fetch depth varies in parts of the graph... would be nice to have some expressiveness...) Good luck.

Hi! With regards to the second question there's a community initiative to provide LINQ support for db4o: http://projects.db4o.com/LINQ_To_Db4o Best regards!

update table1 a ,( select c.key1, c.key2, c.key3, c.key4 as period, max(last_period) as last_period, b.value as last_value from (select key1, key2, key3, key4 from table1 where cast(date_format(created,''%Y%m%d%H%i%s'') AS UNSIGNED) between 2007010112000000 and 20070102112000000 or updated between 2007010112000000 and 20070102112000000 group by key1, key2, key3, key4) c left join (select key1, key2, key3, max(key4) as last_period, value from table1 group by key1, key2, key3, key4) b on c.key1 = b.key1 and c.key2 = b.key2 and c.key3=b.key3 and b.last_period < c.key4 group by c.key1, c.key2, c.key3, last_period) d set a.ow_delta = a.value - d.last_value where a.key1 = d.key1 and a.key2=d.key2 and a.key3=d.key3 and a.key4 = d.period

The benefits of using object-orientation: - You can write reusable code. Which part of your SQL statement is reusable? - Relations between objects are defined by fields in your classes, by collections or direct references. It is not necessary to deal with joins like your SQL code apparently needs them. - Pure Java code would be completely compile-time checked. - Individual methods and subsets of functionality are testable. How would you test that the select you are updating from your SQL code returns the right tuples? - Business logic that changes fields can be written as readable and reusable methods. From a quick look at your SQL code it is not at all visible what it intends to do. I dare say that a pure Java equivalent would be very well readable. If you want to continue writing SQL hacks then db4o is probably not the right database for you. If you have a legacy SQL database where you have to fight the original unrefactorable table design with views and views on top views then db4o is probably also not the right database for you. Object-orientation would help you to write code that you can maintain and reuse together with a big team. Consider doing things right and efficient for your next project that you start from scratch. Would you plan SQL statements like the one you wrote as integral parts for a project that you would start for the Android Developer Challenge? Probably not. That would be an opportunity to try out db4o.

Way to go, team! :-) I'm glad to see this catches on. It's a fresh wind in the boring RDBMS space. It's also good to see the platform is extending. Not only a Java impl but also a .Not one, and last week I read a DB4O Repo for Google's Android platform was successfully built, I thought that was a very interesting move! Has anyone considered building a JCR (JSR 170 or better: JSR 283 for the time being) implementation on top of DB4O? I don't think it would be too hard as DB4O and JCR already share a lot. (e.g. the fact you can just like that, extend an object and that the DS will ransparntly adapt to the change, is a concept the 2 share) As both JRC and DB4O are gaining serious momentum, (also evidenced by the fact Spring supports both through their sub projects) I think that would entail a synergetic effect. :-) -Wolf

See, that's what I meant with "boring" - I'm so glad I can leave that behind and focus on business logic! Your statement gave me the exact same feeling as when I see assembler turn up again, after a few peaceful years ;-) Peace, -Wolf

It is plain wrong syntax. None of the existing RDBMS would supports it.

update table1 a ,(
select c.key1, c.key2, c.key3,
c.key4 as period, max(last_period) as last_period,
b.value as last_value
from
(select key1, key2, key3, key4
from table1
where cast(date_format(created,''%Y%m%d%H%i%s'') AS UNSIGNED)
between 2007010112000000 and 20070102112000000 or updated between 2007010112000000 and 20070102112000000
group by key1, key2, key3, key4) c
left join
(select key1, key2, key3,
max(key4) as last_period, value
from table1
group by key1, key2, key3, key4) b
on c.key1 = b.key1 and
c.key2 = b.key2 and
c.key3=b.key3 and
b.last_period group by c.key1, c.key2,
c.key3, last_period) d
set a.ow_delta = a.value - d.last_value
where a.key1 = d.key1 and
a.key2=d.key2 and
a.key3=d.key3 and
a.key4 = d.period

I think the heart and soul of your application resides in Relational Database that you access through SQL. Db4o is meant for applications whose heart and soul reside in object-oriented language such as Java. Both have their own place. Yours is the legacy one, Db4o is a brave new world. No one is trying to take away yours.