XML/Source Persistence (was: Source formatting for long expressions.)

Christopher Armstrong radix at twistedmatrix.com
Tue Jun 11 13:55:12 EDT 2002


>>>>> "Michael" == Michael Gilfix <mgilfix at eecs.tufts.edu> writes:

    Michael> On Tue, Jun 11 @ 10:32, Christopher Armstrong wrote:
    >> XML is a terrible format for object persistence, due to the lack of
    >> robust mappings. Twisted's XML uses attributes in some cases, but that
    >> is only possible when you have string:string mappings. In *any* other
    >> case, you have to resort to children nodes, with such ugly syntax as::

[snip..]
    >> *That* is why I don't just use XML.

    Michael>   I'm not disagreeing with you because I don't think you're wrong
    Michael> in this case and well, XML isn't for everything. I think XML can
    Michael> work here just as well but it's just more work. I'm not sure about
    Michael> the lack of robustness of the mappings - you just have to define
    Michael> them and can use a DTD to verify that your mappings are
    Michael> intact. But you have to write extra code for the mappings that

I meant the mappings that attributes provide. Creating mappings with multiple
tags is overbearingly verbose, no matter if you formalize it or not. (Am I
understanding you correctly?) Perhaps I should've said "flexible" rather
than "robust". BTW, ONX (http://www.seairth.com/web/onx/onx.html) provides
a better type of mapping: string:arbitrary object. It's not
arbitrary object:arbitrary object, but it's a bit better.

    Michael> isn't quite worth it in such a domain specific case. XML costs
    Michael> extra for being general.  Er, you don't have any between
    Michael> version/backwards-compat issues though do you? In which case, have
    Michael> you thought those out thoroughly?  Forgive me if it isn't
    Michael> relavent. Not sure exactly where these will be used.

Versioning the persistent data is pretty much irrelevant wrt the format used --
and yes, I have thought about it. Marmalade right now uses it's own versioned
state-getters/setters (jellyToDOM_X where X is the version number), but AOT
doesn't have its own interface -- it just uses __getstate__/__setstate__ like
pickle. I'm probably going to write a mixin class for versioned state that
supports methods like __getstate_X__ where X is the version of the persisted 
state.

Note that Twisted has a class for versioning state that's orthogonal to
persisted format: twisted.persisted.styles.Versioned. This allows you
to define 'upgradeToVersionX' methods that will be called in order to
upgrade an object to the current version of the code. The only reason
to use versioned state getters/setters as opposed to this is if you want
the format of the persistent state to change for cosmectic reasons.


-- 
                                Chris Armstrong
                         << radix at twistedmatrix.com >>
                http://twistedmatrix.com/users/carmstro.twistd/






More information about the Python-list mailing list