From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Fri, 21 Nov 2008 18:05:08 +0100 From: "Giacomo Tesio" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <4926D977.2080900@proweb.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_95116_2619837.1227287108307" References: <3d61afbea6c3d54d8371a08214902949@9netics.com> <4926A19F.9030409@proweb.co.uk> <326364c20811210601s14485430x386788a4205da23b@mail.gmail.com> <4926C6E2.5050900@proweb.co.uk> <4926D977.2080900@proweb.co.uk> Subject: Re: [9fans] web-based plan 9? Topicbox-Message-UUID: 4f6550b4-ead4-11e9-9d60-3106f5b1d025 ------=_Part_95116_2619837.1227287108307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > 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 ------=_Part_95116_2619837.1227287108307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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
------=_Part_95116_2619837.1227287108307--