Managment of virtual folders

In Hyppocampus, folders doesn't exists. Or, to say correctly: are an infinite number, but all are created on the fly.

Each query performed is viewed from applications as a folder containing its result set: requests advanced with an opendir(3) syscall are parsed and, if beginning with the appropriate sequence (see How to ask something to Hyppocampus ), are traslated, submitted to the backend database, and formatted for the final presentation in form of list of files (recoverable with readdir(3) or scandir(3) ). Each result set produces a new temporary directory in the tree described in dirs.c , holding the structure of the final presentation, and is maintained until the directory is not closed with closedir(3).

Similar handling is for VIEWs consultation and requests advanced in the traditional way (with a path expressed as concatenation of directories: /folder/subfolder/subsubfolder ), just because those interrogations are equally queries: the first recall the SQL statement assigned to the VIEW when created (with a mkdir(2) syscall), the second is something like SELECT META_NAME WHERE META_PATH = '/the/requested/path' and is managed only for backword compatibility.

Particular attention is to pay for GROUP BY statements, which are one of the main differences between a relational database and a relational filesystem: in Hyppocampus a GROUP BY request returns a set of directories, one for each value retrived assigned to the files in the result set. Each metadata requested as criteria for the GROUP BY means one more level in the hierarchy of folders returned.
For example: requesting SELECT META_NAME WHERE ... GROUP BY META_UID produces a list of directories, one for each retrived user owning at least one file; into each folder are the references to the items owned by that user.

	        SELECT META_NAME WHERE ... GROUP BY META_UID
	             ________________|_______________
	            /                |               \
	+----------+           +----------+           +----------+
	| user foo |           | user bar |           | user baz |
	+----------+           +----------+           +----------+
	     |                       |                      |
	     |                       |                      |
	list of files          list of files          list of files
	owned by foo           owned by bar           owned by baz

Requesting SELECT META_NAME WHERE ... GROUP BY META_GID, META_UID a list of folders is presented, one for each group owning at least one file; into each folder is another set of folders, one for each user which, with the upper group, is the owner of the item; finally, the third level include the real items.
In this configuration, an item is never present in two different folders.
The construction of all this structure is the motivation of the dedicated large code in dirs.c : the GROUP BY request isn't submitted to the backend database, but is enterely managed into Hyppocampus.
Warning: the whole hierarchy builded against a GROUP BY request is destroyed from the stack when the upper folder, the one which have be opened with the initial query, is closed.

---