commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rami Ojares <rami.oja...@elisa.fi>
Subject [vfs] JDBC FileSystem: planning an implementation
Date Sun, 27 Mar 2005 20:09:39 GMT

> -storing files into databases, including some metadata
> (the easy part)

I would see the mapping from relational model to filesystem:

relation (table) = filesystem (defines a set of files that share the same set 
of attributes).
tuple (row) = file that has the content value and attribute values
attribute = one of the attributes has to be decided as content and the rest
of the attributes are file attributes.

Problems: You have to store the decision of which attribute is to be the 
content attribute in vfs. Messy. It will get lost if it is not in the 
database.

Someone might want to see one database as one filesystem.
Then files in that same filesystem would have completely different
attributes and content stored in different attribute too.

All tables should not contain any duplicates and have key attribute
that would uniquely identify the tuple (row, file).

Unfortunately sql (and current databases) don't enforce this.
If you want to see one database as one filesystem then the path
would be schema/tableName/uniqueId
If one table is one filesystem then the path would be only uniqueId.

I can see the benefit of this project in the possibility of adding
attributes freely to filesystem. But it is going to me a bit "messy"
because of the heterogenous nature of database products, sql dialects,
and jdbc driver implementations. Also relational model is stronger than
simple hierarchical filesystem model so that needs to be kept in mind.

- rami

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message