Hi!

This shounds like a great idea! I will go right ahead and see if you 
made something I can steal and use in my own object persistence library :)

As it seems everyone and his sister is making this we might compare 
notes. There is no need for us all to make the same mistakes... sadly I 
won't have time to look at your library 'till tuesday, but until then: 
please look at my take at this:

sql-serialize (presently in ver. 0.0.3):
sdfhttps://sf.net/rpojects/rsqlserial - project page
http://rsqlserial.sf.net - documentation

my goals are:
* no xml metadata
* almost transparent to persistent classes
* database independent (I started out with mysql but postgresql is
   comming next week)

I made a pseudo-EER-diagram trying to show how I store the data in the 
database: http://rsqlserial.sf.net/overview.png

Some of our mutual competition in the field of transparent persistence:

http://madeleine.sourceforge.net/
db-backend (it's not on the RAA, and a one-second reseach through google 
didn't find it, so I cannot give you an url atm)

madeleine isn't really using a database, but rather marshalls the 
classes, so if you want to have your data stored in a real database 
madeleine isn't the way to go...

db-backend (like your lib) uses xml-metadata, there may be some stuff to 
compare yourself with there.

my own (humble) lib is describing the data by itself in stead of having 
the xml metadata. there are both pros and cons to this approach. For 
instance I need to have an object to model the ddl after for creating 
the tables. The instance variables of this object will be used to figure 
out what columns should be in the tables and which datatypes they should 
have.

as soon as I get a chance to look at your library I will most likely 
have lots of feedback :) it would of cause be nice if you would return 
the favor ;)

/Anders

Oliver M. Bolzer wrote:
> Hi!
> 
> I'm in the process of writing (yet another) persistence framework
> for Ruby that supports versioning and transactions: Vapor.
> The base functionality as an Object Repository is roughly done and
> it has reached a state where it can actually played with, so I'd like to
> release it to the public to get some feedback.
> 
> http://www.cip.informatik.uni-muenchen.de/~bolzer/vapor/
> 
> Vapor is being developed at the University of Munich's Department for
> Informatics as storage backend for an ongoing project to better manage
> network elements (including User and Accounts) of the department network.
> As such, the missing features will definetly be implemented in the next
> months.
> 
> 
> From the README:
> 
> Description
> -----------
> 
>  Vapor is a persistent Object-Repository for Ruby, providing transparent
>  persistence of interrelated Ruby application objects to a PostgreSQL database. 
>  It's goal is to provide developers with an easy-to-use framework for
>  persistence, that is consistent with OO design and does not interfere with
>  the code of classes that are to be persistently stored. Vapor does not require
>  any knowledge about relational databases to be used, so that developers can
>  concentrate on the task of writing their application logic.
>         
>  Some of Vapor's general design was inspired by the JDO (Java Data Objects)
>  standard.
> 
> Features
> --------
> 
>   * Object-Oriented API
>   * transparent to persistable classes
>   * support for inheritance
>   * flexible queries for object retrieval
>   * generation of human-readable RDBMS schema
>   * metadata specification through separate XML markup
>   * concurrent access by multiple users
>   * uniqueness constrains
> 
> Planned:
> 
>   * Transactions (ACID) with rollback support
>   * Versioning with complete audit trail
>   * Long Transactions (for Workflow-support, as branches in versioning)
>   * more backends (other RDBMS, local files,...)
> 
> -------
> 
> It has some dependencies, notably Ruby-DBI from CVS (for Array support
> in DBD::Pg, patch included in Vapor's tar-ball).
> 
> Documentation is still only VERY basic, but Code examples on how to use Vapor 
> are linked to from the web page.
> 
> Any feedback or suggestions will be appreciated.
> 


-- 
dc -e 
4dd*od3*dddn1-89danrn10-dan3+ann6*dan*2*an13dn1+dn2-dn3+5*ddan2/9+an13nap