Re: [Gnu-arch-users] file system interface to a database

[Milan Cvetkovic]

Aldrik KLEBER wrote:

> tla don't touch the database directly, this is the SQLite engine who
> access the database, SQLite engine is mature.

Let's just say that the probability of corrupting a database while
working with it is much higher than probability of corrupting files
while reading them.

My trust in tla *and* sqlite and together is much smaller than my trust
in tla only (or sqlite only), not because sqlite is not good, but
because my trust (lower than 100% multiplies) with each.

In fact, I would like to see tla make revision directories/files
read/only right after creation. Maybe one day I add such thing to tla...

Milan.


> Le Lundi 09 Janvier 2006 16:23, Milan Cvetkovic a écrit :
> 
>>Andy Tai wrote:
>>
>>>Thanks for the information. It does not look like this is an easy thing
>>>to do, to try to put a tla archive on top of sqlite.  But nontheless I
>>>may try to look into continuing the work you have done when I feel up to
>>>it...
>>
>>Well, I am not too sure if this is the good thing to do, to put tla on
>>top of sqlite (or any database).
>>
>>One of the main reasons why I decided to use tla (and migrate all
>>projects in the company to tla) is that it *never* touches the old files
>>(old revisions). So, you could have portions of your archive on a CD
>>ROM.
> 
> You can't have a part of an archive on CD, and the other part on the hard 
> disk, you need to mirror the archive on CD to hardisk
> 
> 
>>I never tried this, but the thought of "not modifying" the previous 
>>revisions gave me high level of confidence that tla will not corrupt my
>>archive so easy.
>>
> 
> It is not so easy to corrupt a database, sqlite is a transactionnal database.
> 
> 
>>With sqlite, I would imagine that there would be a single database for a
>>number of revisions. Adding a revision would have to modify this
>>database, rather than add a new file (or directory, or whatever tla
>>adds). This means that a bug in tla could easyly corrupt old revisions.
>>
> 
> tla don't touch the database directly, this is the SQLite engine who access 
> the database, SQLite engine is mature.
> 
> 
>>At least, there should be always be an option to use file system instead
>>of sqlite.
>>
> 
> 
> Yes !! Completely agree with  you.
> To implement the use of SQLite, we must add a new notion : backend notion.
> archive and revision library should be able to switch freely between a 
> filesystem backend and a DB backend.
> 
> With this we can have an efficient DB backend, without modifying anything 
> about the actual filesystem backend.
> 
> And because the notion of backend is independant if the implementation we 
> solve the problem of trying to manage a virtual filesystem, wich is not a 
> good approach.
> 
> 
> 
>>Regards, Milan.
>>