On Mon, Nov 24, 2008 at 11:58 AM, matt <mattmobile@proweb.co.uk> wrote:

>
>  That's exactly what constraints, rules in SQL etc are for. Maybe some
>> similar ruling system for filesystems would be fine :)
>> (any suggestions ?)
>>
>>
> That's what I was driving at. To map SQL <> FS you end up replicating lots
> of SQL logic in your client FS. Reads are *always* out of date. Writes can
> happen across tables but need to be atomic and able to roll back.
>

Probably I was not clear on what I'm thinking about.

I think that rebuild a relational database on a filesystem is (quite)
pointless.


What I'm proposing is to design/develop the interface to interact with
(any?) rdbms through a filesystem.

A kind of "proxy" to the db with a filesystem interface.

A "draft" could be (even if I've already found some problems in it):


>    - 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
>
> The problems:

   - transaction -> directory conversion require creating a new connection
   to the backend (if I'm right thinking that transaction are connection wide)
   - xml output of fetchable results (SELECT, FETCH, SHOW...) require a tool
   to easily query such an output. It seem Plan 9 miss such a tool. xmlfs
   actually is unsuitable.
   (I'm thinking about an xpath command accepting xml in stdin and the xpath
   query as an argument, and return to stdout the results)


Giacomo