On 13-9-2014 19:45, Simon Slavin wrote:
On 13 Sep 2014, at 6:16pm, Tim Streater <t...@clothears.org.uk> wrote:
On 13 Sep 2014 at 16:39, Richard Hipp <d...@sqlite.org> wrote:
I say that a filesystem is an eventually-consistent key/value database.
The keys are the filenames and the values are all big BLOBs, specifically
the file content. Filesystems also have a hierarchical keyspace, which is
an extension from the usual key/value concept, but it is still key/value.
Key Example value
--- -------------
filename somefile.txt
creation date <seconds since the epoch>
file type text
opens with textwrangler.app
content <lines of text>
...
and so on.
That's not what I meant. That's the file as a database. What I want is the
entire volume as a database. It would be something like
Key Example value
--- -------------
/robots.txt/path /
/robots.txt/filename robots.txt
/robots.txt/creationdate whatever
/robots.txt/filetype text
/robots.txt/creatorapp /Applications/textwrangler.app
/robots.txt/content BLOB
/index.html /
/index.html/filename /index.html
/index.html/creationdate whatever
...
The actual primary key would be a a two column index, of course.
Simon.
My question will than be:
Would the primary index not be the i-node number (in case of ext3/ext4
filesystem), or the sectornr in case of FAT
Files on disk (did?) get fragmented, but for a database this should not
have influence on the 'i-node' where a file is stored.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
