Re: [ANN] sql-serialize 0.0.3

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

that would help people like us out *alot*

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

there are a number of data types that I could not easily port to sql.
Booleans for instance, mysql haven't really got a boolean datatype, but
dbd_mysql returns the strings "1" or "0" in stead of true and false, so
I couldn't store booleans as columns in the same table as the rest of
the attributes. I want, like you, to have integers, floats and strings
as columns in a table representing a class. Files, booleans, Exceptions
(and anything derived from Exception), and Bignums are some of the
datatypes I had to treat differently. I put them in separate tables with
references to the class table.

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

I have a pseudo-EER diagram (most of my modelling knowledge is kinda
rusty after working in a company for a long time that didn't have the
time for such stuff!!) here:

http://rsqlserial.sf.net/overview.png

The general idea is to have a sql_ids table which holds the id and class
name (identical to the class name) of all objects stored in the
database. If an object has (for instance) an array of other objects as
an attribute, then that will be stored in the Classname_array table,
which has symbol, index, and value id as columns. value id is a foreign
key to sql_ids from which I can find the table name and column for each
object in the array. Am I making sense? The implementation is very
simple (I think so, at least) and very fleksible, but I have some
difficulty actually describing it to others.

Aside from the sql schema I have some trouble serializing a lot of the
built in classes. I'd rather not have to use Marshal to store the built
in classes (it kind of defeats the purpose of having a sql database) but
File for instance needs a path, position and open mode, which means that
it cannot be stored with any conventional sql data type. Other built in
classes (Binding for instance) are a bit harder (for me at least) to
describe and therefore to serialize. How are you accomplishing this?

/Anders