On Jun 29, 2007, at 8:34 AM, Mark Hatle wrote:
For the case w/o db3 header being available, there is the "db_emu.h"
file. Put that value in there, and it is supposed to be picked up
if db
items are not defined.
Before we go off and reinvent the wheel again again again ...
I realize y'all hate Berkeley DB.
But so far there are only 2 usage cases for rpm w/o Berkeley DB:
1) licensing. certain companies are too cheap to buy a license
2) embedded tool chains.
There is plain and simply no other justifiable usage case for rpm w/o
Berkeley DB that I have heard.
The current sqlite implementation "works", but the schema is a total
hack,
the implementation was never finished to handle essential flags like
temporary databases, the configuration parameters have never been
seriously,
explored, and there are serious design issues buckling a sql database
underneath the durrent dbiFoo() vectors.
All of which you know well.
So can we please start from a design POV rather than hacks on hacks
on hacks?
FIrst of all, what is the usage case?
Putting a rpmdb on NFS? sunrpc does that, so does using fcntl locking.
Avoiding the "horrors" of NPTL? Sorry, NPTL is here to stay on linux,
and posix shared mutexes are "standard" and hence likely to be more
portable than any other locking scheme.
Name your usage case(s) please.
73 de Jeff
--Mark
Ralf S. Engelschall wrote:
On Thu, Jun 28, 2007, Mark Hatle wrote:
Is "TEMPORARY TABLE" something special? I knew about the :memory:
before, but not the other.
Excerpt from http://www.sqlite.org/lang_createtable.html:
If the "TEMP" or "TEMPORARY" keyword occurs in between "CREATE"
and "TABLE" then the table that is created is only visible within
that same database connection and is automatically deleted when
the
database connection is closed. Any indices created on a temporary
table are also temporary. Temporary tables and indices are
stored in
a separate file distinct from the main database file.
Otherwise this looks good to me. It may even speed things up
slightly.
But before I can commit I at least wish to find a better approach for
the DB_PRIVATE value. The current hack is not the best since sliced
bread:
+#if defined(WITH_SQLITE) && !defined(DB_PRIVATE)
+#define DB_PRIVATE 0x0200000 /* shameless hack for shared
option */
+#endif
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
_____________________________________________________________________
_
RPM Package Manager http://
rpm5.org
Developer Communication List rpm-
[EMAIL PROTECTED]
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
