> > I'd like to know how do you would map the operations to the filesystem. >> >> > one directory per queryset row returned (possibly named by the primary > key), one file per column >
Ok... I read it somewhere in the archives of the list. But I found it a little "inadeguate": - what about multiple fields primary key? - what about transactions? - what data modifications (insert update delete)? 'till now I imagine it so: opening a transaction could be creating a directory on a dbfs/transactions/ each of such directories (like the complete connection) has - a "ctrl" file which accept only COMMIT, ROLLBACK and ABORT - an "error" file - a "notice" file (postgresql has RAISE NOTICE... may be others have it too) - a "data" file (append only in the transaction, but not outside) where the INSERT, UPDATES, DELETE and all the DDL and DCL commands will be written - each SELECT have to be written in a different file (named sequentially): after writing the query, the same file could be read to get the results (in xml...) - on errors, sequents writes fails and error file will be readable > > Query result in a filesystem hierachy would be a pain... xml would be >> better, since you could transform it quickly. >> BTW, there should be an xmlfs project waiting somewhere... >> > > ah xml, the ultimate 2d grid ! I'm missing what you mean. xlmfs is bugged? Giacomo
