Discussions

News: db4o releases version 2.5 with Query API

  1. db4o releases version 2.5 with Query API (6 messages)

    db4o (database for objects) has just released the first final of it's JDO competitor. S.O.D.A. (Simple Object Database Access) object queries attempt to supply more type safety, less memory consumption, greater simplicity and more power than JDOQL.

    The product is free for non-commercial use.

    Check out db4o.

    More info
    ----------------
    For those of you who have never had a look at db4o, here is a short outline.

    db4o is a client/server Java object database with ACID transactions.

    Some points where db4o is different from most other database products:
    - db4o detects the structure of your user classes at runtime and adjusts it's storage scheme automatically, even if you modify your classes. You don't have to worry about managing table schemes or XML mapping files. Simply store your objects.
    - There is no need to modify your classes to be able to persist objects. Since reflection is used and since the reference management system works separately from your user objects, it is possible to run an unlimited number of database file sessions in one VM and to move objects freely between database files.
    - You can persist virtually any Java object, without touching it's sourcecode. db4o "understands" all Java data types, all arrays, all Collection types. For very difficult
    classes that perform initialisation work in constructors it is possible to write your own custom translators.
    - db4o comes in a single 250 kB JAR that needs no further external packages. The small size of the JAR allows deployment in a Java Webstart application or online deployment to mobile phones.
    - db4o runs on all JDKs from 1.1.x to present. It has successfully been tested on PersonalJava, the Symbian VM, Savaje and on the Zaurus. J2ME CDC-compliant VMs will open a great field on tomorrows mobile and handheld platforms.
    - Client or server can be run with a memory footprint well below 10 MB.
    - db4o has built-in servlet session management support. You can drop the JAR to the ../WEB-INF/lib/ folder of your ISP and your database engine is installed.
    - db4o is threadsafe and the IO mechanism was designed to be VM- or OS-crash-resistant with a transaction recovery on restart. Regression tests included with the download allow you to test this yourself.

    The major new feature in release 2.5:
    db4o now comes with the S.O.D.A. (Simple Object Database Access) query interface.
    S.O.D.A. is a powerful, yet simple, query API based on the principle of query-by-example:
    Reuse existing objects in your code to describe, how retrieved objects should look like.
    You can add an unlimited number of objects to the query-template-graph and describe how they should be evaluated against the stored objects: equals, not, smaller, greater, like, by identity. Constraints can be ORed between eachother.
    To make it possible to execute any Java code during query evaluation, S.O.D.A. provides
    a callback feature.
    Well over 500 of our regression tests are included with the db4o download, to demonstrate,
    how S.O.D.A. can be used.

    Here is a simple S.O.D.A. example. It performs a regular expression query for all objects
    in your database file that support the "CanGetName" interface where "getName()" matches "*4o":

    public ObjectSet regularExpression_4o(ObjectContainer db) {
        Query q = db.query();
        q.constrain(CanGetName.class);
        final Pattern pattern = Pattern.compile("*4o");
        q.constrain(new Evaluation() {
            public void evaluate(Candidate candidate) {
                candidate.include(
                    pattern.matcher(
                     ((CanGetName)
                        candidate.getObject()).getName()
                    ).matches());
            }
        });
        return q.execute();
    }


    If you use a client/server setup for the above example, all the code in the "evaluate" method will be executed on the server side.


    S.O.D.A. has been developed in public. If you would like to contribute to future S.O.D.A. versions, here is a link to the S.O.D.A. homepage at SourceForge:
    http://sourceforge.net/projects/sodaquery


    Further modifications in the db4o 2.5 release can be read in the changelog:
    http://www.db4o.com/db4o/changelog.html


    Judging from our benchmark tests, db4o is exceptionally fast for storing data and for navigational and ID access. Please test for yourself. The trial version available from
    the website is fully functional except for a two-month expiration date. Here is a direct download link:
    http://www.db4o.com/db4o/db4o2.5.zip


    db4o is *not* JDO compliant, and we are proud it isn't.
    - No enhancer!
    - No ugly String/API query mixture.
    - Very small footprint, for deployment and in-memory.
    - Runnable on JDK 1.1.x (PersonalJava, J2ME CDC)
    - Store all objects, all arrays, all JDK collection types, just any Java object.
    - Direct control over what you want stored, loaded, instantiated and purged from memory.


    I hope you will enjoy testing db4o.

    Feedback, comments, questions and suggestions are very welcome.
    You are invited to post directly to our newsgroup:
    news://news.db4odev.com/db4o.users


    Kind regards,
    Carl
    --
    Carl Rosenberger
    db4o - database for objects
    http://www.db4o.com

    Threaded Messages (6)

  2. "db4o is *not* JDO compliant, and we are proud it isn't"


    That's really great: Another proprietary technology that works against any "official" specification.

    Regards,
        Dirk
  3. That's really great: Another proprietary

    > technology that works against any "official"
    > specification.

    Check out JDOQL.
    Check out what we have built.
    Compare!
    What do you like more?

    I have been trying to get my thoughts through to JDO throughout the past two years but noone was ever interested. You can scan newsgroups and JavaLobby for some of my past comments.

    So far JDO is only supported by small vendors. None of the huge database companies has jumped in and Oracle is cooking their own soup with TopLink. I don't think that JDO will be successful.
    ...quite similar to EJB.

    I also think it is a bad idea to define a technology to be proprietary to Java.

    Besides that transparent persistency can never work in high-concurrency multi-user environments. I will post a follow-up on this theme here soon.
    ...and I hope, Floyd will let it through.

    Carl
  4. "Another proprietary technology"?

    The S.O.D.A spec does not appear to be exactly proprietary -in fact the intention seems to be just the opposite. It's an open source API designed to handle Query By Example (QBE) in a native OO language (e.g. Java).

    If you don't like native QBE, there are of course many alternatives from OQL to OWL/RDF/N3 and from JDO to SQL3 - which has its own non-native SQL3/QBE.

    But if you want such things, realize they are all in the development phase. I'm not sure it makes a lot of sense yet to be religious about standards at this point with regard to any of the above.

    Also, realize that S.O.D.A is just an interface that is decoupled from the database and not itself a database itself. And since it's open source, it is possible that S.O.D.A could be implemented as an interface for databases other than db4o that provide a similar pattern matching layer to what db4o provides.

    QBE is usually implemented only as a visual interface to some other language. A native OO QBE is programmable with pure objects.

    So in general, object-oriented QBE is a relatively highly programmable query mechanism where queries can be composed of pure objects. This may be desirable for many uses. So I think what Carl is doing with S.O.D.A makes sense and it's very decent computer science.

    Regards,


    Rich Katz
    Java Skyline
    See http://www.javaskyline.com/database.html

    (We now return you to the future - already in progress).
  5. Hello Richard.

    Maybe I was wrong, but as far as I understood I can use the SODA interface only with db4o.

    You are also right that this is an interface that is decoupled from the DB. But you need to implemenent the components that access that interface. So if you intent to write resuable (EJB or non-EJB) components you have a problem here.

    I also agree with Carl that Entity EJBs a really a pain in the ass. But for now its (in my opinion) the only way to realize components that can be reused within several different projects.

    JDO seems to be a better approach (compared to Entity EJBs) but it is not yet finally specified (as far as I know) and also there are not many products at the moment that support this specification.


    Best regards,
        Dirk
  6. <quote>
    Maybe I was wrong, but as far as I understood I can use the SODA interface only with db4o.
    </quote>
    Jakarta OJB does already provide rudimentary support for S.O.D.A.
    The support is not yet complete, but it is one of our aims to provide a full soda implementation.
    (http://jakarta.apache.org/ojb/apidocs/org/apache/ojb/soda/package-summary.html)


    Thomas Mahler
    (OJB architect)
  7. Query by template[ Go to top ]

    The "read" operation in Javaspaces has resemblance to that of a db4o query. You use a template Entry with relevant attributes filled to find similar one(s).