[Nitro] Concerns over Og mandating the form of initialize

[James Britt]

George Moschovitis wrote:
>>If pre-existing objects are to be used, then one has to guard against
>>other processes altering the database.
> 
> 
> I think the constructor should not be called when deserializing the
> object. An object that is serialized in the database is allready
> intialized and in the correct state. I think using klass.allocate is
> the 'right thing',

Say I have an application, a blog, and I'm saving BlogEntries to a 
database.  The Nitro application itself may read and write to tables 
(via Og).  But so can other applications; in fact, I want other 
applications to be able to create or alter data. I see this as a feature.

But this open access means potentially invalid data can get in there.

When my Nitro app reads data and creates objects, I want to be sure the 
created objects are well-constructed.

What would be the overhead of saving an object's properties as simple 
data, but also using an extra field to store a YAML serialization, and 
having a means where client code can either create new objects based on 
values in the database, or revive existing objects from the saved 
serialization?

I can see where saving whole objects, intact, internal state and all, 
can be very handy.  So far, though, I've been thinking in terms of 
creating objects when needed, based on stored data.  If, in my blog app, 
I select a set of entries based on date or content, I do not expect to 
be getting back the same objects as previously created.

There are important differences in an application when it's "objects 
created from table data" versus "objects revived from serialization".

James

> 
> -g.
> 


-- 

http://www.ruby-doc.org
http://www.rubyxml.com
http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com