[YLUG] Parsable Rack Diagrams

[Robert Hulme]

> I'm probably missing something here
I don't think you are. I think we're all guessing what is a good match
for what Alex wants :P (or rather what his task masters require)

>  but if you're doing that, why
> not just use the ORM with sqlite and miss out all the faffing with
> dumping/creating objects? After all, isn't that what the orm is
> for?
I suppose I had thought that they might want to do funky things with
pulling older versions of racks / servers / something out of the
version control system possibly, and might not want to store the
sqlite DB in the version control system.

If you just use the sqlite DB then you can't recreate the system from
the diffable files which I assume (for no particularly good reason I
suppose) they might want to do. I also wonder if they might want to
tinker with the files directly (of course you could do that with
sqlite too, but I'd argue that for this kind of thing bashing in some
changes in emacs / vi / ed is probably easier than writing SQL).

> If diffable files are essential, then dump the sql to a format
> that diffs easily on a per rack basis, but keep the master data
> in sql. In a sort of python orm syntax:
I think an issue is what format to use for outputting the objects in.
Some special new format for definition of racks would be nice but
would require non zero work, while serialisation code for JSON / YAML
/ XML *shudder* is already out there.

-Rob

-- 
http://www.robhulme.com/
http://robhu.livejournal.com/

Doublethink means the power of holding two contradictory beliefs in
one's mind simultaneously, and accepting both of them.
-- George Orwell