[YLUG] Parsable Rack Diagrams
Noah Slater
nslater at gmail.com
Tue Aug 7 21:57:51 BST 2007
> When the app starts it would load all the objects from disk and
> recreate them in the in memory sqlite DB.
Yes - this is a very valid improvement suggestion. If the application
knows how to dump the database into JSON/CSV/XML/FooBarBaz format and
also knows how to read it and recreate the database this is ideal.
>From the user's point of view the data file is a
JSON/CSV/XML/FooBarBaz file and can be tweeked, edited, studied,
backed up, versioned, transformed, transmogrified, framed on the wall
or tattooed on their forehead.
The point is - as long as the process is transparent to the user it
doesn't matter much and you get the best of both worlds.
Also - like Rob points out - if you use Django's ORM or SQLAlchemy you
literally have one method to call to object.transform_to_foo_format
and you're done - all the conversion/marshalling/pickling code has
been written for you...
... and if you can't see where this is going yet - you can be agnostic
to the output format as long as you provide options to read/write what
ever the user chooses.
Imagine:
$ rackgraph --load my_rack.json
$ rackgraph --load my_rack.csv
$ rackgraph --load my_rack.xml
$ rackgraph --load my_rack.foo
In each case you sniff the file type, convert on the fly and bob's yer uncle.
--
"Creativity can be a social contribution, but only in so
far as society is free to use the results." - R. Stallman
More information about the York
mailing list