Re: [Objectbridge-jdo-dev] Introduction

[Joel S. <jo...@ik...>]

On Sun, 2002-04-07 at 04:42, Thomas Mahler wrote:
> > It has some things I don't like though, which is
> > why I started Sparrow instead of just working with Ozone.
> > 
> 
> What exactly is there in Ozone that you don't like?

It's paradigm is everything runs in the db server. Client objects are
only proxies that send all requests to the server. That means every call
has network overhead (unless Ozone is in the same VM--but even then I
think I saw that objects are serialized).

This was one of the fundamental problems I had with entity EJBs. You had
to create separate value objects. You just doing all this work building
an entity bean, and now you have to create another class for a value
object. Crazy. A maintenance nightmare. Eventually you get to the point
of 2-3 classes for every object you want stored in the db.

I want one class and that's it. Let's keep it simple. If you want
business logic to run in a separate server, use a session bean.

> Do you know DB40 (http://www.db4o.com)? it's a commercial OODBMS with a 
> liberal licence for personal use. The db4o people are trying to 
> establish lighweight statndard API for OO data access 
> (http://www.odbms.org). OJB provides support for their S.O.D.A API 
> already. The ultimate aim is to allow free choice of the persistent 
> media (ODBMS or RDBMS).

I've heard of db4o but can't remember what I thought of it. I probably
didn't look at it too close as I was focusing on open source
alternatives.

> > The bare minimum I see is:
> > 
> > 1) JDO front end with pluggable store
> > 2) O/R mapping store
> > 3) Object db store
> 
> 1) and 2) are exactly the scope of OJB-JDO
> So their is really a large potential in joining our efforts!
> 
> This picture also looks very similar to the original JDO RI by sun.
> 
> I have an additional idea: what about using the OJB PersisteneBroker API 
> as the store API? going this way we will have the following picture:
> 
> 1.) JDO and ODMG front ends, both working against a PersistenceBroker 
> kernel internally
> 2.) several PersistenceBroker implementations:
> - for RDBMS (already implemented)
> - for LDAP (partially implemented)
> - for XML storage (some people already working on it)
> - for OODB (to be done by Sparrow)
> 
> This would be a kind of "rosetta stone" of object persistence!

Sounds good... What would be the quickest way for me to digest your
PersistenceBroker API?

> > My goal is to get to as close as:
> >  - Drop in one or two jars and poof, you can now have persistent
> > objects. That's all it takes.
> > 
> > The ideal might not be perfectly attainable, but I think it's possible
> > to come at least very very close.
> 
> With a pure ODBMS approach this should be possible.
> With a O/R approach it won't be that easy. (You must tell the RDBMS 
> about primary keys, foreign keys and indexes which is not so easy to 
> deduce from an object model...)
> But it's not impossible to reach.

Right. I have some crazy ideas about adaptable indexing and stuff so the
data store would handle indexing/tuning/optimization for you. I hope I
have some time eventually to try it out when we get there.
-- 
Joel Shellman
Comprehensive Internet Solutions -- Building business dreams.
[ web design | database | e-commerce | hosting | marketing ]
iKestrel, Inc.  http://www.ikestrel.com/