[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