gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Aldrik KLEBER
Subject: Re: [Gnu-arch-users] file system interface to a database
Date: Mon, 9 Jan 2006 19:09:17 +0100
User-agent: KMail/1.9

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.
>
-- 
Cordialement,

Aldrik

Citation de fortune :

If builders built buildings the way programmers wrote programs,
then the first woodpecker to come along would destroy civilization.

Attachment: pgpI9S21F5ZD8.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]