Anders Borch wrote:

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

Couldn't find a way to automagically detect that instance variables have
changed. The default #hash doesn't reflect state change inside the object.
Till I find a better way, Persistable#mark_dirty has to be called on the
persistent object, either externally or from a setter of the object itself.
This is something I really want to eliminate without performance penalty.
 
> 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?

There is an Auto-Commit mode where all changes (things like #make_persistent
and #delete_persistent and when #mark_dirty is called, for now) are
instantly flushed to the Datastore. If Autocommit-Mode is turned off and no
transaction is active, an exception is raised. 

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

Matz is thinking to add a method to add "before" or "after"-hooks to methods
without needing to alias the original method under a different name and
then defining one's own method that calls the original. It might make sense
to hook all methods that might change an instance variable.
I've thinking about redefining attr_writter, attr_accessor to call
#mark_dirty, coo.
 
> 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)

Good point. Havn't tought this part much out yet. Maybe I should not
require that a transaction is explicty started.

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

One of my goals is to make the SQL schema as similar to the original classes
as possible. Each class has it's own table and each attribute it's own
columns. Because SQL has types and I want to use native SQL-types for things
like String, Integer and Float, I can't be that flexible. I don't want to
ALTER TABLE during normal operation. It was a requirement for this project
that manual manipulation in the RDBMS by the admin or read-only access with
traditionaly reporting tools is not too complicated. 

Guess I really need to look at the SQL schema used by sql-serialize before
commenting further...