[Relfs-devel] Pushing towards a library "type-alike" interface to create tables and relations

[Vincenzo a. N. N. <vin...@ya...>]

There are two issues with the way one should create data on the 
database:

1. If I record attributes of a file on the db, the user is (not without 
a reason) tempted to change these attributes directly on the db, e.g. 
to fix a typo in the "author" tag of hundreds of mp3s.

2. If a plugin uses attributes of another plugin they must be called in 
the right order

A possible solution, which pushes hard towards the decision of having a 
library to create datastructures on the database instead of allowing 
plugins to create tables (and this makes one think that having a 
separate user at least for groups of plugins is a good idea), is to 
create triggers on the database for attributes "owned" by plugins, both 
on read and on write:

- Read triggers:

When anybody tries to read an attribute, the database should check 
conditions, declared by plugins and choosen in a limited range (like 
"when the first 100 bytes of the file have changed"), which might have 
invalidated the attribute, and in this case run the appropriate 
indexer. This solves the dependency issue but NOT if there are circular 
dependencies which are a bad thing anyway. Several ways to avoid 
circular dependencies come to mind but none is free from troubles.

- Write triggers:

When anybody tries to write an attribute (except the owner of the 
attribute, which makes the choice "a db user for each plugin" an 
interesting concept) the database should check if there is a plugin 
which has declared itself able to write that attribute, or else return 
an error. 

Conclusion:

we will have to implement a library, possibily easy to call by C and so 
"SWIG"able, which allows to declare "external types". Types should have

- attributes with "DB primitive" types, that are translated to column 	
of a table with the same name of the type

- attributes with "external" types, which are translated using foreign 
keys

- declarations of writeable-ness for attributes, and what to do in the 
case of a write.

Types should be inserted into suitable database schemas to avoid naming 
conflicts, and what db schema to use might be chosen either by letting 
the plugin declare it, or as beerfun said using a fixed set of rules 
(like "what mimetypes do you match" but not limited to mimetypes) that 
group plugins together in a more automatized way.

A last note is worth for "equalization" of attributes i.e. what if two 
plugins use different names for the same thing, and the user notices 
this? She should be enabled to "equalize" the names but I am unsure of 
the implications of equalization even if semantics of name passing is 
one of my favourite topics :) However we should see if this can be 
worked on easily because that would be a great advantage.

Someone willing to criticize this architecture? This will be implemented 
in september because I'll be on vacation in the next two or three 
weeks.

Bye

Vincenzo