[Nitro] Concerns over Og mandating the form of initialize
james_b at neurogami.com
Wed Apr 13 10:35:42 EDT 2005
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
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".
More information about the Nitro-general