[Persistence-sig] getting started

[Kevin Jacobs]

On Wed, 10 Jul 2002, John Miller wrote:
> Like others, I expect mainly to lurk. I would appreciate it if someone 
> were willing to explain how the goals of this sig go beyond pickling and 
> shelving.

The major reasons why things are more complex than shelve or pickle are due
to the requirements of more sophisticated back-end data storage mechanisms.
For one, the backend data store may need to be interoperable with other
systems; i.e., relational or object database backends.  Also, the backend
store may be very large, so that loading and updating objects need to be
done incrementally, efficiently, and safely.

Here are some articles/debates about Java's persistent data objects that are
useful, even if you don't agree with them:

  http://www.onjava.com/pub/a/onjava/2002/05/29/jdo.html
  http://www.onjava.com/pub/a/onjava/2002/04/10/jdbc.html

Here is a partial taxonomy of issues I'd like to see addressed.  You'll
notice that many of them are somewhat specific to fixed schema persistent
backends, like some object-relational (OR) systems:

  1) Extensible bi-directional type mapping

     i.e., systems for mapping types from Python to an RDBMS and back in a
           lossless fashion.

  2) Manual Schema specification vs. automatic schema introspection

     i.e., the ability to construct sensible objects from relations depends
           on the schema, but also other information like foreign keys,
           constraints, and possibly other meta-data not available from the
           backend.  Some OR systems require differing amounts of
           user-specified schema information to build appropriate objects.

  3) Foreign key referenced object instantiation

     i.e., how and when to instantiate new objects from attributes another
           object with attributes that can act as foreign keys.

  4) Transactional scoping of object updates

     i.e., multiple OR-mapped objects can be queried from distinct
           transactions, then referentially linked together.  This opens the
           door to several rather nasty situations, some of which can be
           handled, others must be explicitly disallowed.

  5) Systems for tracking of uncommited object updates.

  6) Query language abstraction for building OR frameworks.

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com