object databases ?

On Sun, 27 Jun 2010 22:55:32 +0200, Marc Weber wrote:

> Doing some research it seems that http://www.db4o.com/ is used often?
> However I found some threads (2007) that Scala bytecode was not
> recognized that time so queries were slow because very often all objects
> were loaded into memory.

I'm also endeared to object databases through my development work on
Plone, which is why I'm now using DB4O. I would also be interested to
look at Neodatis as well.

The bytecode incompatibility problems were only when using
instrumentation and on-the-fly native query optimisation. If you use
DB4O's SODA queries (which is essentially what the other techniques turn
your queries into), you can avoid those problems and achieve very fast
query speeds, albeit with some extra pain - you will find it vast
improvement on Zope though.

If queries are still slow, you probably haven't configured the indexes
correctly, which can be a little difficult.

I haven't checked if the original problems still exist for Scala 2.8 - so
it would be worth reviewing. Let me know if you take a look and get
native optimisation and/or instrumentation working, because that would be
very cool too!

I am using DB4O as the primary database in this work-in-progress Scala/
DB4O/Wicket/JQuery web framework project:

http://uniscala.net/granite/

which is stringly influenced by Zope/Plone. There may be some useful
tools in this - example:

http://uniscala.net/mvn/uniscala-db4o/scaladocs/index.html

that can be used independently of the framework. It allows you to do,
among other things, SODA queries like this:

val db:ObjectContainer = // ... open database
val kwQuery = Query[FoodKeyword]
kwQuery.descend("keyword").startsWithIgnoreCase("bean")
kwQuery in db foreach { res => println(res(db) }

which makes SODA queries less tedious.

The Granite framework itself does other nice things like auto-committing
the database after a web request (or rollback on uncaught exception),
providing an IoC framework for hooking in the database and other
services, and so on. It is designed for smaller/medium-size applications
- not Facebook-sized juggernauts. Contact me if interested.

Cheers,
Sam.

is there a reason not to implement the queries in java?

Sam Stainsby schrieb:
> On Sun, 27 Jun 2010 22:55:32 +0200, Marc Weber wrote:
>
>
>> Doing some research it seems that http://www.db4o.com/ is used often?
>> However I found some threads (2007) that Scala bytecode was not
>> recognized that time so queries were slow because very often all objects
>> were loaded into memory.
>>
>
> I'm also endeared to object databases through my development work on
> Plone, which is why I'm now using DB4O. I would also be interested to
> look at Neodatis as well.
>
> The bytecode incompatibility problems were only when using
> instrumentation and on-the-fly native query optimisation. If you use
> DB4O's SODA queries (which is essentially what the other techniques turn
> your queries into), you can avoid those problems and achieve very fast
> query speeds, albeit with some extra pain - you will find it vast
> improvement on Zope though.
>
> If queries are still slow, you probably haven't configured the indexes
> correctly, which can be a little difficult.
>
> I haven't checked if the original problems still exist for Scala 2.8 - so
> it would be worth reviewing. Let me know if you take a look and get
> native optimisation and/or instrumentation working, because that would be
> very cool too!
>
> I am using DB4O as the primary database in this work-in-progress Scala/
> DB4O/Wicket/JQuery web framework project:
>
> http://uniscala.net/granite/
>
> which is stringly influenced by Zope/Plone. There may be some useful
> tools in this - example:
>
> http://uniscala.net/mvn/uniscala-db4o/scaladocs/index.html
>
> that can be used independently of the framework. It allows you to do,
> among other things, SODA queries like this:
>
> val db:ObjectContainer = // ... open database
> val kwQuery = Query[FoodKeyword]
> kwQuery.descend("keyword").startsWithIgnoreCase("bean")
> kwQuery in db foreach { res => println(res(db) }
>
> which makes SODA queries less tedious.
>
> The Granite framework itself does other nice things like auto-committing
> the database after a web request (or rollback on uncaught exception),
> providing an IoC framework for hooking in the database and other
> services, and so on. It is designed for smaller/medium-size applications
> - not Facebook-sized juggernauts. Contact me if interested.
>
> Cheers,
> Sam.
>
>

On Mon, 28 Jun 2010 06:46:27 +0200, HamsterofDeath wrote:

> is there a reason not to implement the queries in java?

There is nothing to stop you doing that, but I think there'd be a lot of
skipping backward and forward between Java and Scala which could get
messy. The main aim of DB4O is to make using the database as unobtrusive
as possible.

Check out neo4j[1], its not an object database but a graph-database,
but i think its a lot easier to use than a relational database. And if
trees are dominant in your domain its a perfect match. And there
exists mappers that can map from your entities into the graph.

-atle

[1] www.neo4j.org

On Mon, Jun 28, 2010 at 6:54 AM, Sam Stainsby
wrote:
> On Mon, 28 Jun 2010 06:46:27 +0200, HamsterofDeath wrote:
>
>> is there a reason not to implement the queries in java?
>
> There is nothing to stop you doing that, but I think there'd be a lot of
> skipping backward and forward between Java and Scala which could get
> messy. The main aim of DB4O is to make using the database as unobtrusive
> as possible.
>

On 6/27/10 5:18 PM, Sam Stainsby wrote:
> I am using DB4O as the primary database ...
I was going to say "I hope there's a secondary database too, because
DB4O is GPL" but then I checked your license and it's GPL too--which I
guess it would have to be unless there were a "chinese wall" API layer
between your stuff and the database implementation layer. :/

-0xe1a

P.S. IANAL & TINLA

On Mon, 28 Jun 2010 17:07:28 -0700, Alex Cruise wrote:

> On 6/27/10 5:18 PM, Sam Stainsby wrote:
>> I am using DB4O as the primary database ...
> I was going to say "I hope there's a secondary database too, because
> DB4O is GPL" but then I checked your license and it's GPL too--which I
> guess it would have to be unless there were a "chinese wall" API layer
> between your stuff and the database implementation layer. :/

Yes, I believe with GPL v. 3 we are OK there. We are also experimenting
with an "object store" layer in the hope that we can achieve
interchangeable plugins for the object database (Neodatis for example).
This I believe would increase the options for licensing the bulk of our
modules. As a copany, we are looking at mostly bespoke and SAAS
applications, so for us it is not a priority issue.

On Tue, 29 Jun 2010 00:51:17 +0000, Sam Stainsby wrote:

> On Mon, 28 Jun 2010 17:07:28 -0700, Alex Cruise wrote:
>
>> On 6/27/10 5:18 PM, Sam Stainsby wrote:
>>> I am using DB4O as the primary database ...
>> I was going to say "I hope there's a secondary database too, because
>> DB4O is GPL" but then I checked your license and it's GPL too--which I
>> guess it would have to be unless there were a "chinese wall" API layer
>> between your stuff and the database implementation layer. :/
>
>
> Yes, I believe with GPL v. 3 we are OK there.

Actually, it seems that Versant added a much more permissive license for
DB4O in April this year:

http://developer.db4o.com/Blogs/News/tabid/171/entryid/886/Default.aspx

"We recently moved to GPLv3 and now with the addition of the Ms-PL and
CPOL to our dOCL we estimate db4o could potentially be used in 94% of
existing Java and .NET open source projects"

http://www.db4o.com/about/company/legalpolicies/docl.aspx

I'm still going over it.

On Thu, Jul 1, 2010 at 2:08 PM, Sam Stainsby
wrote:
> CPOL to our dOCL we estimate db4o could potentially be used in 94% of
> existing Java and .NET open source projects"

OT, but my knee-jerk reaction to such precision is that they are kinda
jerks or dummies. unless they really tracked down all the existing
such projects on the globe and analyzed them. shyeah, right. or i
guess the "estimate" and "potentially" are meant to convey that they
are kidding and they know where they pulled the number out of. :)

On Thu, 01 Jul 2010 14:18:29 -0700, Raoul Duke wrote:

> OT, but my knee-jerk reaction to such precision is that they are kinda
> jerks or dummies. unless they really tracked down all the existing such
> projects on the globe and analyzed them. shyeah, right. or i guess the
> "estimate" and "potentially" are meant to convey that they are kidding
> and they know where they pulled the number out of. :)

The license that I linked to seems to indicate that DB4O is compatible
with:

"""
a. GNU Library (or "Lesser") General Public License (LGPL), versions 2.0
and 2.1
b. Apache Software License, versions 1.0, 1.1, or 2.0
c. BSD License, as copyrighted on July 22, 1999
d. Eclipse Public License, version 1.0
e. MIT/X11 License
f. Mozilla Public License, version 1.1
g. Microsoft Public License (Ms-PL)
h. Microsoft Reciprocal License (Ms-RL)
i. Code Project Open 1.02 License
"""

> The license that I linked to seems to indicate that DB4O is compatible
> with:

yeah, let's see it in court :)

Hi list,

I've had yet another look at db4o (I'm still a beginner though)
The tutorial talks about three query types:

a) QBE (query by example). You instantiate proto objects and use them to
let db4o create queries. They seem to be limited

b) Native Queries: You use Java (or .net) Code in order to specify
constraints. db4o tries to look at the byte code to find a soda query
If it fails it falls back to load all objects and run the native code.

c) SODA queries, which are no longer typesafe.

Example: (taken from http://www.db4o.com/about/productinformation/resources/db4o-7.4-tutorial...)

Query query=db.query();
query.constrain(Pilot.class); //1
query.descend("name").constrain("Michael Schumacher"); //2
ObjectSeta result=query.execute();
listResult(result);

Because I can't verify that b) works as expected for Scala users
c) seems to be the only reliable way to build something on (?)
Yet the example is very verbose and not very typesafe.

Ideally you'd like Scala to read some information from objects to
generate code which generates queries

So the final interface could look like this:

db.query( QPilot.nameMatch("Michael Schumacher") ).execute

where QPilot is kind of class defining nameMatch which runs code
in lines //1 and //2

Does this make sense? Of course it should be no problem creating a list
val myDBObjects = List(Pilot.class, ... )

and create Scala code from that, should it?
That generated code can be read by an IDEA and you have nice type safe
SODA based queries ?

Or is there a smarter way I've missed?

Are there existing pretty printers or code generators which can ouput
such Scala code?

Yet another question: If you tried modeling graphs using db4o and if you
queried the first object. Would db4o query the whole graph at once then?
This is not always what I want.

class Node {
public Node next; // next node (or list of nodes)
}

Marc Weber