[Persistence-sig] Is is possible to separate programming API from IDataManager api?

Ernesto Revilla aerd@retemail.es
Fri, 16 Aug 2002 19:37:34 +0200


I'm sorry if my former mail was out of track. I didn't read all the posted
messages, which is really hard. There are a lot of implementation details.

Is it possible to separate programming API from IDataManager API and define
them separate and independently?

Can there be a mechanism to vote about the API, like a Wiki with a voting
mechanism (with dead-lines)?

Could we get a level 1 API, without multi-thread issues and multiple-save
points? (20/80 -> use 20% of resources to solve 80% of use cases, leave
other 15% for level 2 API).

Please, just CRUD (Basic Create, Update, Delete). Transactions with minimum,
i.e. begin, commit and rollback, without nesting.

Please set minimum of metadata, so the resource manager can imagine how to
store the data.

Without observable framework, which can be set later on top of
PersistentObject (ObservablePersistentObject).

Just programming API.

==========================
Some general use cases:
Use case 1: an application wants to use just 1 new relational database for
storing information (relational, because there may be other applications
accessing, especially reporting tools)

Use case 2: the same with ZODB

Use case 3: An application want to access diferent models in the same
database. (The applications integrates two basic applications, each of it
has a independent data model.)

Use case 4: An applications has objects with some of the attributes from
loaded from another storage system. This could be the case of new
applications, which integrate old data, but want to add functionality for
new uses, such as scanned documents, audio, images.
===========================
Request:
Can we have a index to document with interesting links like ZODB4, general
persistence, etc.? (likely on another Wiki page)

===========================
Technical question a bit out of track:
Can objects have back-links so a possible OQL interpreter (borrow code from
castor) could easily do query optimizations? e.g. "SELECT i FROM Invoice i
WHERE i.customer.name LIKE 'Thomson*'"     (would directly jump to customer
objects and go back to Invoice object, that is inverse traversal of
objects).
Does ZODB objects point to their containers?


Erny