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
pgp11ldGGTXHR.pgp
Description: PGP signature
