From: Oliver Bolzer <bolzer@...>
Date: 2003-06-10T19:04:21+09:00
Subject: Re: [ANN] sql-serialize 0.0.3

Hi!

# had no access to news over the weekend+holyday

Anders Borch wrote:

>> - support for transactions
> 
> how is this going to show in your api? In my implementation
> inserting/updating/deleting a class and all associated classes is
> wrapped in a transaction. When calling insert() on a persistent class

I'm currently working on transactions with optimistic locking. (done except
rollback :-) 

A code snipped would look like

# Transaction as a block
@pmgr.transaction{|t|
  munich.altitude          # => 530
  munich.altitude = 550
  munich.altitude          # => 550
  munich.state             # => Vapor::Persistable::DIRTY
  t.rollback
}
munich.altitude            # => 530
munich.state               # => Vapor::Persistable::PERSISTENT

If any exception is raised inside the block, the transaction is
automatically rolled-back and the state before the transaction restored.

Alternatively transactions can be done outside a block, in which case
you must make sure yourself that the transaction is rolled back.

# using an Transaction-object
   t = @pmgr.transaction
   t.begin
     munich.make_persistent
   t.commit
   t.commit                   # => Vapor::StaleTransactionError

>> - XML metadata (database independence again)
> 
> what are you storing in this xml document? I seem to achieve database
> independence just fine without any xml metadata. Maybe I'm missing
> something?

First, I didn't want to "pollute" the class's code with this metadata.
But mainly, I don't want it to change too easily and don't want the
developer to believe that changing the metadata definition (in-class)
automatically ajusts the Repository to it. To not need to keep the XML
files around, I store the metadata in the Datastore using an utility
that reads the XML files and populates the Repository.

>> - support for relationships transparent for developer (I'm not sure if
> uhm... my library has this. If you have a an object that has an
> associated object, then this association will persist without having to
> write a single line of code. The programmer doesn't even have to make
> any add_to_relationship(), my persistence library will notice all
> associations when insert/update is called.
 
Mine too. If an attribute is declared as of type "Reference" is the metadata
definition and the actual reference points to a class that include's
Vapor::Persistable and is known to the Repository, the job gets done.

> I know this one... that's a *really* though one... imho rdoc helps out a
> lot here :)

The best API documentation helps nothing, if one doesn't know which methods
to look for. I find it essential, that simple code snippets are included
as documentation. Most likely such snippets are written during API design
anyway to see how the API would feel. Why don't just collect them ?
I've done so in
http://www.cip.informatik.uni-muenchen.de/~bolzer/vapor/example.html
an will eventually evolve this into a tutorial.