>
> 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