On Sat, May 12, 2007 at 11:25:58PM +0200, Ivan Voras wrote:
> Kris Kennaway wrote:
> 
> > First figure out what specific problems need to be solved, then figure
> > out how to solve them, not the other way around.  So far I have seen
> > little discussion of how SQLite is necessary and sufficient for fixing
> > fundamental issues.  The argument in favour of SQL seems to boil down
> > to "It's SQL!  You can do more complex queries...if you wanted to".
> 
> I've posted some general ideas (resulting from my experience using the
> package / port system, not developing for it):
> 
> 1. speed and simplicity of querying (single query vs traversing a tree
> of text files)
> 2. formal data constraints (UNIQUE, CHECK)
> 3. transaction safety (a consequence of which is the ability to run
> concurrent installs / updates)
> 4. easy interface for 3d party tools
> 
> I admit again that I didn't develop anything with the package / ports
> subsystems, so there might be other, bigger problems not solvable by
> sqlite, but I believe the features above could at least solve
> performance problems.

That is the "sufficient" part but not the "necessary part".  1) and 3)
are solvable using existing tools.  2 and 4 not so much, but you
haven't described what problems they solve.

Homework for SQLite advocates: write a 1-page essay on the following
topic.

"Rewriting the package tools to use SQLite will solve problem(s) ____
that exist in the current system.  Compare and contrast to other
possible solutions including Berkeley DB."

> (I also agree there's no point in changing the ports infrastructure
> itself, just the package tracking database in base system).

Well, I was talking about both.

Kris

Attachment: pgp11ldGGTXHR.pgp
Description: PGP signature

Reply via email to