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
>>                                        rse@engelschall.com
>>                                        www.engelschall.com
>>
>> _____________________________________________________________________ 
>> _
>> 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