AW: [Objectbridge-jdo-dev] Non-JDBC data sources

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Juozas,

>=20
> Hi,
> I work on experimental persistence framework, it is Apache=20
> SimpleStore. It
> has implementation
> for JDBC, XMLDB and file. May be it is possible to merge both=20
> projects ?

Yes this may be interesting for the new db.apache.org project!

> It is nothing bad to have two or more projects about the=20
> same, but I think
> it is good
> to find  something the most usefull and reuse it.

I agree!

> I prefer to have three or more projects at Apache :
> 1) Standard Apache DB API, only interfaces and "large" documentation.

Do we need new persistence APIs? There are standard APIs for
Object-Persistence:
ODMG, JDO, S.O.A.P.
I don't see any requirements for Yet Another Persistence API.

> 2) Implementations and "small" documentation.
>=20
> JDO can be some kind of "standard" API, but it closed for=20
> people like me and
> I prefer Open Standards.
>=20

Where can I find more info on your project?

cheers,

Thomas

>=20
> Hi David,
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: David Zejda [mailto:dv...@at...]
> > Gesendet: Donnerstag, 13. Juni 2002 01:17
> > An: Obj...@li...
> > Betreff: [Objectbridge-jdo-dev] Non-JDBC data sources
> >
> >
> > I know, that OJB's focus sharpness (faq: It's concerned with
> > O/R mapping and
> > nothing else.) is design/manage advantage, but I work on
> > project, where it's
> > crucial to integrate disparate data sources (RDBMS, ODBMS,
> > XML based DBMS,
> > flat-files, vendor specific formats..). I decided not to use =
closed,
> > non-free solutions at all, so OJB (open-source, clearly designed,
> > scalable...), seems to be suitable as a persistency-heart.
> > Could you advise how to get on with OJB?
>=20
>=20
> > 1) use OJB as a single persistency adaptor, manage several ODMG
> > implementations, make some fascade to hide it, e.g. solve=20
> distributed
> > transactions...?
>=20
> If there are existing ODMG Java bindings to you other=20
> datasources this will
> be vers easy.
> Just write litte wrappers that route user request to different ODMG
> implementations.
>=20
> If there is no ODMG API for a given persistent store, you can=20
> implement a
> dedicated PersistenceBroker for this special persistent store.
> This way you can use the OJB ODMG (or JDO if you prefer)=20
> implementation to
> access arbitrary persistent stores.
>=20
> > 2) extent OJB (add persistency adpators to OJB) - if
> > publically useful,
> > release them under LGPL as modular OJB's parts/add-ons?
>=20
> Yes, that's what I'm recommending. have a look at our=20
> persistence kernel
> interface ojb.broker.PersistenceBroker.
> It contains no specifics for RDBMS. It is a generic abstractiion of =
an
> object store.
> There could be implementations for OODBMS, RDBMS, XML=20
> databases, file system
> or Directory Services !
>=20
> You only have to provide a persistent store specific =
PersistenceBroker
> Implementation.
> Than you can use the OJB ODMG or JDO layer to work against=20
> those specific
> brokers.
>=20
> regarding OJB scope:
> As OJB will be one of the foundation projects of the new=20
> db.apache.org site,
> our scope is not longer limited as mentioned in the faq.
> OJB will be a generic object persistence integration platform!
>=20
> Thus having new PersistenceBroker implementations is very=20
> interesting for
> us!
> (especially XML, OODBMS, LDAP, flat-file)
>=20
> As we are moving to Jakarta, we will use the apache licence soon.
>=20
> > 2.1) is this posible without (negative) impact on OJB's=20
> actual design
>=20
> yes no problems!
>=20
> > 3) something else?
> >
> > In the roadmap there is (4me) a bit mysterious  sentence "provide
> > distributed Meta-Object Protocol access through=20
> PersistenceBroker API"
>=20
> This has been implemented a long time ago. OJB comes with a=20
> client/server
> mode. To have fully operational clients it is necessary to=20
> have meta-data on
> the client too. This was not possible in the early days, but=20
> now it is.
>=20
> > Somewhere in OJB doc I read about possibility to build my own
> > PersistenceManager. Does it relate to mentioned problem?
> >
>=20
> No. You simply have to implement the PersistenceBroker=20
> interface to write a
> new storage adaptor.
>=20
> A persistenceManager would be something like your own ODMG or JDO
> implementation. That would be a much more difficult task!
>=20
> cheers,
>=20
> Thomas
>=20
> > Thanks for reply
> > David Zejda
> >
> >
> > PS: I know, I can suck all wanted info from API, but I=20
> thing, you (OJB
> > experts) can answer quickly and painlessly.
> >
> > BTW thanks for OJB, well done!
> >
> >
> >
> >
> > _______________________________________________________________
> >
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -
> > http://devcon.sprintpcs.com/adp/index.cfm?source=3Dosdntextlink
> >
> > _______________________________________________
> > Objectbridge-jdo-dev mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
> >
>=20
> _______________________________________________________________
>=20
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
> http://devcon.sprintpcs.com/adp/index.cfm?source=3Ddntextlink
>=20
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
>=20
>=20
> _______________________________________________________________
>=20
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -=20
> http://devcon.sprintpcs.com/adp/index.cfm?source=3Dosdntextlink
>=20
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
>=20