From: Anders Borch <spam@...>
Date: 2003-06-11T01:26:12+09:00
Subject: Re: [ANN] sql-serialize 0.0.3

Oliver Bolzer wrote:
> 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
> 

hmm... how are you maintaining the dirty state? using #hash at 
store-time compared to #hash now? Or something similar?

> 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
> 

and, if im not wrapping my "munich.altitude = 550" in a transaction will 
it then be committed immediately to the database, or when you call 
#insert next time? can the developer choose to autocommit an object to 
database after each change? how do you detect changes?

I'm trying to find out how to implement this in a way that interferes as 
little as possible with the application code. I'd hate to restrict the 
developer from overriding #hash for instance.

oh, btw. if you detect that Vapor::StaleTransactionError, why not just 
ignore the #commit call? If you check that an instance has been changed 
before commiting it to the database, why then the error? I could of 
cause rescue your exception and do nothing about it, but what purpose 
does it serve in the first place? (I'm trying to determine if I should 
implement something similar)

>>>- 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.
> 

hmmm... I'm trying to store data in my database in a way that lets the 
developer change the metadata and have that reflected in the database 
without having to involve the developer. Hopefully the developer will be 
able to change the number of attributes and associated classes in an 
object at any time and have this reflected in the database too.

> 
>>>- 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.
> 

no need to declare an attribute as a reference in my library. If you 
have an instance variable that points to another object (well, all do, 
but you know what I mean) that reference is reflected in the database 
automagically.

> 
>>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.
> 
> 

You indeed did document that nicely :)

Im trying to do this as well... I have a test.rb that I use to test my 
code as I develop it. This test also serves as documentation of how to 
use my library. Still there is more to documentation than examples. 
Evolving from examples to tutorials takes some work (for me at least, 
you seem to be doing fine).

/Anders