Can the usual ORM solutions interact with OO databases?

Question

For example, can Hibernate handle CouchDb?

What about support for other OO databases in other ORM solutions?

One of the (not that important) benefits of an ORM solution is the possible ability to swap one database vendor for another. What if you swap a relational database for an object oriented one?

[edit] if you feel like giving the question a downvote please explain why.

Answer 1

My understanding (usual caveats of "could be wrong" here) is that ORM solutions do not work with Object Oriented databases, as OO databases remove the need for the ORM solution.

In general, an ORM is used to help abstract the relational model, and abstract away from the logic of the code the mismatch of the relational model to the object-oriented system. It also allows for usage of traditional databases that are often required for legacy systems to continue working, but gives you the freedom to handle the relationships in a OO fashion.

The abstraction is the real benefit, imo, of using an ORM. Swapping database vendors is not as easy as some would make it out to be, especially is you are switching from or to a database like Oracle, where there are lots of custom operations and custom behavior in the JDBC drivers.

Another element to your question is that it is unlikely that you would want to use the same baseline database model from a relational database to an object-oriented database. I would think that such a paradigm shift would recommend, if not require, a rethinking of the logic and connection behavior of the underlying core system.

Answer 2

The "R" in "ORM" stands for "relational", so I don't think they apply to ODBMS at all.

The whole point of using an object database is being able to persist objects. If you have them, what do you need mapping for?

I think the kind of swapping you're talking about is accomplished by having a persistence interface that's implementation agnostic. If you can do that, you can swap out relational and object databases. Maybe something like this:

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    T find(K id);
    List<T> find();
    List<T> find(T example);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

Answer 3

"What about support for other OO databases in other ORM solutions?"

Object-Relational Mapping (ORM) is a solution to this problem.

1. Objects in the program.

2. A Relational Database.

Unless you have BOTH parts (OO program, Relational database) you cannot use ORM because you don't have a problem.

If you're writing C programs, you can't use ORM -- you don't have any objects to map to.

If you're not using a relational database, you can't use ORM -- you don't have any relational database to map to.

There's no need for ORM with OODB. There's no problem to solve.

Answer 4

What if you swap a relational database for an object oriented one?

I think that this should be possible with JDO. Actually, in my memory, JDO was elaborated and promoted by OODMBS vendors and I see this standard as a kind of unified way to interact with OODBMS (and the master plan was in two steps: first, Dear customer, use my JDO implementation for persistence and then Dear customer, replace your Oracle/Sybase/Whatever database with my Versant database).

But I wouldn't define JDO as an "ORM", it's more a transparent object persistence standard (that can act as an ORM tool when the storage system is a relational - the R in ORM - database).

Answer 5

Working with JSON, depending on your language, is easier that working with class instances.

IMHO an ORM is a step backwards from just using JSON serialization objects and pushing them to any NoSQL database that was smart enough to use JSON as their storage format.