Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Florian Weimer]

* sub sk:

> Somehow no one seems to  have mentioned it on this mailing list so far!?
> Here is the scoop...
>
> On March 23, Oracle announced the latest release of Oracle® Berkeley
> DB - 11g Release 2 -  which introduces a new SQL API, based on lo and
> behold, SQLite v3 API. What this means is that all tools that work
> with SQLite will also work with Oracle Berkeley DB.

How do we resolve the symbol clashes?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Jean-Denis Muys]

On 4/1/10 4:12 , "Neville Franks"  wrote:

> Thursday, April 1, 2010, 12:16:13 PM, you wrote:
> 
> JJD> On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
> JJD>  wrote:
 There were many problems with
 that approach:
>>> ...
 (3) Each table and index is in a
 separate file so your "database" was a directory full of files instead
 of a single file
>>> 
>>> This one is not a problem. Actually I don't see how 1 file is better
>>> than 1 directory. For example mac application is a directory not a
>>> file and no one complains. And with several files database would be
>>> faster (for example dropping a table is instant or fragmentation is
>>> handled by OS without need for vacuuming whole database). Also with
>>> current SQLite implementation only tables would be locked by a
>>> transation not a whole database (a few years ago there were even
>>> document on SQLite website listing  splittnig database to several
>>> files as one way to implement table level locks in SQLite).
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>> 
> 
> JJD> Two reasons I prefer the single file approach:
> 
> JJD> 1. Simpler copy, tables and indexes don't get lost or mismatched.
> > 
> Also from the "end user" perspective it is so much easier for them to
> backup or copy a single file.
> 

These two answers are void in the context of the Wiktor's point who said
"For example mac application is a directory not a file and no one
complains".

The reason no one complains is that an app directory is seen by the user as
a single entity (a "bundle"). S/he doesn't have the option to copy/backup
parts of it. (except through geeky, explicit actions).

Of course, the other operating systems don't care much about such details,
nor about users in general, so your points are valid in general, just not in
Wiktor's context.

I think an interesting point can be made that splitting the database in
several files (or forks, such as provided by HFS or NTFS) really means
deferring parts of the DBMS's job to the file system.

It could even be argued that using files in the first place is already
deferring to the OS!

So at one end of the spectrum the DBMS defers at little as possible to the
OS, while at the other end of the spectrum, every table, or even maybe every
row is in its own file.

There are advantages to storing every row in its own file: the database
becomes compatible by system-wide search facilities for example. This is why
Apple went from a single-file mail database to a scheme where every mail is
in its own file. Now you can use spotlight to search for emails.

And to be clear, I agree that a single-file data format was the right choice
for SQLite :-)

Jean-Denis

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Nicolas Williams]

On Wed, Mar 31, 2010 at 06:16:13PM -0700, Jim "Jed" Dodgen wrote:
> On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
> >> (3) Each table and index is in a
> >> separate file so your "database" was a directory full of files instead
> >> of a single file
> >
> > This one is not a problem. Actually I don't see how 1 file is better
> > than 1 directory. [...]
> 
> Two reasons I prefer the single file approach:
> 
> 1. Simpler copy, tables and indexes don't get lost or mismatched.
> 
> 2. fewer handles to open a database. Lower overhead.

3. One fsync() vs. many (or a full sync()).

Nico
-- 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Neville Franks]

Thursday, April 1, 2010, 12:16:13 PM, you wrote:

JJD> On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
JJD>  wrote:
>>> There were many problems with
>>> that approach:
>> ...
>>> (3) Each table and index is in a
>>> separate file so your "database" was a directory full of files instead
>>> of a single file
>>
>> This one is not a problem. Actually I don't see how 1 file is better
>> than 1 directory. For example mac application is a directory not a
>> file and no one complains. And with several files database would be
>> faster (for example dropping a table is instant or fragmentation is
>> handled by OS without need for vacuuming whole database). Also with
>> current SQLite implementation only tables would be locked by a
>> transation not a whole database (a few years ago there were even
>> document on SQLite website listing  splittnig database to several
>> files as one way to implement table level locks in SQLite).
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>

JJD> Two reasons I prefer the single file approach:

JJD> 1. Simpler copy, tables and indexes don't get lost or mismatched.

JJD> 2. fewer handles to open a database. Lower overhead.

JJD> This still is a small footprint, high-performance, low overhead SQL
JJD> implementation. It does what it needs to do and no more.


Also from the "end user" perspective it is so much easier for them to
backup or copy a single file.


---
Best regards,
  Neville Franks, http://www.surfulater.com http://blog.surfulater.com
 

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Jim "Jed" Dodgen]

On Wed, Mar 31, 2010 at 8:50 AM, Wiktor Adamski
 wrote:
>> There were many problems with
>> that approach:
> ...
>> (3) Each table and index is in a
>> separate file so your "database" was a directory full of files instead
>> of a single file
>
> This one is not a problem. Actually I don't see how 1 file is better
> than 1 directory. For example mac application is a directory not a
> file and no one complains. And with several files database would be
> faster (for example dropping a table is instant or fragmentation is
> handled by OS without need for vacuuming whole database). Also with
> current SQLite implementation only tables would be locked by a
> transation not a whole database (a few years ago there were even
> document on SQLite website listing  splittnig database to several
> files as one way to implement table level locks in SQLite).
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>

Two reasons I prefer the single file approach:

1. Simpler copy, tables and indexes don't get lost or mismatched.

2. fewer handles to open a database. Lower overhead.

This still is a small footprint, high-performance, low overhead SQL
implementation. It does what it needs to do and no more.





-- 
Jim "Jed" Dodgen
j...@dodgen.us
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Wiktor Adamski]

> There were many problems with  
> that approach:
...
> (3) Each table and index is in a  
> separate file so your "database" was a directory full of files instead  
> of a single file

This one is not a problem. Actually I don't see how 1 file is better
than 1 directory. For example mac application is a directory not a
file and no one complains. And with several files database would be
faster (for example dropping a table is instant or fragmentation is
handled by OS without need for vacuuming whole database). Also with
current SQLite implementation only tables would be locked by a
transation not a whole database (a few years ago there were even
document on SQLite website listing  splittnig database to several
files as one way to implement table level locks in SQLite).
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Alexey Pechnikov]

Hello!

On Monday 29 March 2010 22:26:41 D. Richard Hipp wrote:
> I can come up with additional reasons why replacing the existing  
> SQLite backend with TC is not a good idea, but perhaps the above will  
> suffice.

But how about insert/update performance on big indices? When index size
is more than cache_size the inserts/updates in SQLite are stopped by fact.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[D. Richard Hipp]

On Mar 29, 2010, at 1:56 PM, Alexey Pechnikov wrote:

> Hello!
>
> On Monday 29 March 2010 20:22:36 D. Richard Hipp wrote:
>> SQLite version 1 used gdbm for storage.  There were many problems  
>> with
>> that approach:  (1) gdbm is a hash-based system so it could not do
>> range queries (2) gdbm is GPL, (3) Each table and index is in a
>> separate file so your "database" was a directory full of files  
>> instead
>> of a single file, (4) there is no support for transactions, (5) gdbm
>> is highly vulnerable to corruption if a power loss occurs while it is
>> being updated.
>
> May be the Tokyo Cabinet DBMS is more better? BerkeleyDB is required
> administration and it's strange solution in many embedded devices and
> for some desktops and servers too.


(1) Tokyo cabinet did not exist in 2001 when I was looking for an  
alternative to gdbm.

(2) When you configure Tokyo cabinet so that it is robust against  
power loss (so that it doesn't corrupt the database file during a  
power loss) it is about 10x slower than SQLite.

(3) Tokyo cabinet has less concurrency than SQLite.

(4) Tokyo cabinet is not able to put an entire SQL database into a  
single file.  It would require a directory full of files, just as gdbm  
did.

(5) Tokyo cabinet does not support transactions across files, so it  
cannot be used in an SQL engine that is transaction (since at the SQL  
level you must have transactions that span multiple tables.)

I can come up with additional reasons why replacing the existing  
SQLite backend with TC is not a good idea, but perhaps the above will  
suffice.

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Alexey Pechnikov]

Hello!

On Monday 29 March 2010 20:22:36 D. Richard Hipp wrote:
> SQLite version 1 used gdbm for storage.  There were many problems with  
> that approach:  (1) gdbm is a hash-based system so it could not do  
> range queries (2) gdbm is GPL, (3) Each table and index is in a  
> separate file so your "database" was a directory full of files instead  
> of a single file, (4) there is no support for transactions, (5) gdbm  
> is highly vulnerable to corruption if a power loss occurs while it is  
> being updated.

May be the Tokyo Cabinet DBMS is more better? BerkeleyDB is required
administration and it's strange solution in many embedded devices and
for some desktops and servers too.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[D. Richard Hipp]

On Mar 29, 2010, at 12:03 PM, Jay A. Kreibich wrote:

> On Mon, Mar 29, 2010 at 09:15:45AM +0530, Roger Binns scratched on  
> the wall:
>
>> I believe the btree/paging layer is replaced with BDB.
>
>  Didn't SQLite "1" use a dbm library for the storage layer?
>
>  The more things change
>

SQLite version 1 used gdbm for storage.  There were many problems with  
that approach:  (1) gdbm is a hash-based system so it could not do  
range queries (2) gdbm is GPL, (3) Each table and index is in a  
separate file so your "database" was a directory full of files instead  
of a single file, (4) there is no support for transactions, (5) gdbm  
is highly vulnerable to corruption if a power loss occurs while it is  
being updated.

So after less than a year of SQLite 1, I wrote my own b-tree library  
and hooked it up to SQLite, changed the license from GPL to Public  
Domain, and called the result "SQLite version 2".  That was in 2001,  
starting on http://www.sqlite.org/src/timeline? 
c=2001-04-17+20%3a09%3a11 and continuing through 
http://www.sqlite.org/src/timeline?c=2001-09-13+13%3A46%3A56 
  and beyond.

>-j
>
> -- 
> Jay A. Kreibich < J A Y  @  K R E I B I.C H >
>
> "Our opponent is an alien starship packed with atomic bombs.  We have
> a protractor."   "I'll go home and see if I can scrounge up a ruler
> and a piece of string."  --from Anathem by Neal Stephenson
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

D. Richard Hipp
d...@hwaci.com



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Jay A. Kreibich]

On Mon, Mar 29, 2010 at 09:15:45AM +0530, Roger Binns scratched on the wall:

> I believe the btree/paging layer is replaced with BDB.

  Didn't SQLite "1" use a dbm library for the storage layer? 

  The more things change
 
-j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Our opponent is an alien starship packed with atomic bombs.  We have
 a protractor."   "I'll go home and see if I can scrounge up a ruler
 and a piece of string."  --from Anathem by Neal Stephenson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[P Kishor]

On Mon, Mar 29, 2010 at 3:23 AM, Roger Binns  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> P Kishor wrote:
>> thanks for the clarification, but how does the above statement
>> reconcile with "the btree/paging layer is replaced with BDB"? Does
>> that refer to a different version of SQLite being offered by Oracle
>> that includes BDB for storage? I hope that will be called something
>> else... mebbe sqlbdb?
>
> You are thinking about this too hard.  Due to SQLite's license it can be
> combined in any way with proprietary or open source code.  (Technically
> public domain is the absence of a license but you get the point.)
>

You misunderstood my question (or, perhaps my question wasn't clear),
but it is answered now.

1. Essentially, stuff downloaded from sqlite.org is still pure sqlite,
purely and completely in public domain in the US, with nothing from
Oracle within it.

2. Stuff downloaded from elsewhere can of course use sqlite, and may
be subject to its own terms.

What matters to me is #1 above.




> Separately SQLite is trademarked and that trademark is owned by HWACI
> (DRH's company).  I can't find an explicit policy anywhere, but in
> general you can only call the software/download from SQLite.org by the
> name "SQLite".
>
> Roger




-- 
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
---
Assertions are politics; backing up assertions with evidence is science
===
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

P Kishor wrote:
> thanks for the clarification, but how does the above statement
> reconcile with "the btree/paging layer is replaced with BDB"? Does
> that refer to a different version of SQLite being offered by Oracle
> that includes BDB for storage? I hope that will be called something
> else... mebbe sqlbdb?

You are thinking about this too hard.  Due to SQLite's license it can be
combined in any way with proprietary or open source code.  (Technically
public domain is the absence of a license but you get the point.)

Separately SQLite is trademarked and that trademark is owned by HWACI
(DRH's company).  I can't find an explicit policy anywhere, but in
general you can only call the software/download from SQLite.org by the
name "SQLite".

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuwY5YACgkQmOOfHg372QTE9wCfSryo2T34R5wv6nL2nIywOxEW
Jh0AoMUgbl+wRcqS5r8bSOrKffPkCXUf
=xY4d
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Roy Tam]

2010/3/29 P Kishor :
> On Sun, Mar 28, 2010 at 10:50 PM, Dan Kennedy  wrote:
>>
>> On Mar 29, 2010, at 10:48 AM, P Kishor wrote:
>>
>>> On Sun, Mar 28, 2010 at 10:45 PM, Roger Binns
>>>  wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 sub sk79 wrote:
> How So? Is SQLite getting a high concurrency module from BDB in
> exchange for its SQL API?

 I believe the btree/paging layer is replaced with BDB.

>>>
>>>
>>> How does BDB's (or any code from Oracle) inclusion into the SQLite
>>> source tree affect the public domain nature of SQLite? To the extent
>>> that there is any code from Oracle, has that been dedicated to public
>>> domain as well? Am very curious about clarity on this.
>>>
>>> Also, from which version on has Oracle code entered the SQLite tree?
>>
>> No Oracle code has been added to the SQLite tree. SQLite licensing
>> remains unchanged.
>>
>
>
> thanks for the clarification, but how does the above statement
> reconcile with "the btree/paging layer is replaced with BDB"? Does
> that refer to a different version of SQLite being offered by Oracle
> that includes BDB for storage? I hope that will be called something
> else... mebbe sqlbdb?
>

Oracle will release their own version SQLite using BDB as backend called BDBSQL.
Source (Developer blog in Chinese):
http://www.bdbchina.com/2010/03/oracle-berkeley-db-%e6%94%af%e6%8c%81sql%e5%95%a6%ef%bc%81/#more-862

>
>
> --
> Puneet Kishor http://www.punkish.org
> Carbon Model http://carbonmodel.org
> Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
> Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
> Nelson Institute, UW-Madison http://www.nelson.wisc.edu
> ---
> Assertions are politics; backing up assertions with evidence is science
> ===
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[P Kishor]

On Sun, Mar 28, 2010 at 10:50 PM, Dan Kennedy  wrote:
>
> On Mar 29, 2010, at 10:48 AM, P Kishor wrote:
>
>> On Sun, Mar 28, 2010 at 10:45 PM, Roger Binns
>>  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> sub sk79 wrote:
 How So? Is SQLite getting a high concurrency module from BDB in
 exchange for its SQL API?
>>>
>>> I believe the btree/paging layer is replaced with BDB.
>>>
>>
>>
>> How does BDB's (or any code from Oracle) inclusion into the SQLite
>> source tree affect the public domain nature of SQLite? To the extent
>> that there is any code from Oracle, has that been dedicated to public
>> domain as well? Am very curious about clarity on this.
>>
>> Also, from which version on has Oracle code entered the SQLite tree?
>
> No Oracle code has been added to the SQLite tree. SQLite licensing
> remains unchanged.
>


thanks for the clarification, but how does the above statement
reconcile with "the btree/paging layer is replaced with BDB"? Does
that refer to a different version of SQLite being offered by Oracle
that includes BDB for storage? I hope that will be called something
else... mebbe sqlbdb?



-- 
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
---
Assertions are politics; backing up assertions with evidence is science
===
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Roy Tam]

2010/3/29 Roger Binns :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> sub sk79 wrote:
>> How So? Is SQLite getting a high concurrency module from BDB in
>> exchange for its SQL API?
>
> I believe the btree/paging layer is replaced with BDB.
>

Confirmed.
http://twitter.com/gregburd/statuses/10979336891

> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkuwImUACgkQmOOfHg372QT27wCgmiuebBj/sHSDiI6CyemBquW9
> D5AAn0/rBQf2SkYQmJTcJrRsizfNt08S
> =Mocr
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Dan Kennedy]

On Mar 29, 2010, at 10:48 AM, P Kishor wrote:

> On Sun, Mar 28, 2010 at 10:45 PM, Roger Binns  
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> sub sk79 wrote:
>>> How So? Is SQLite getting a high concurrency module from BDB in
>>> exchange for its SQL API?
>>
>> I believe the btree/paging layer is replaced with BDB.
>>
>
>
> How does BDB's (or any code from Oracle) inclusion into the SQLite
> source tree affect the public domain nature of SQLite? To the extent
> that there is any code from Oracle, has that been dedicated to public
> domain as well? Am very curious about clarity on this.
>
> Also, from which version on has Oracle code entered the SQLite tree?

No Oracle code has been added to the SQLite tree. SQLite licensing
remains unchanged.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[P Kishor]

On Sun, Mar 28, 2010 at 10:45 PM, Roger Binns  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> sub sk79 wrote:
>> How So? Is SQLite getting a high concurrency module from BDB in
>> exchange for its SQL API?
>
> I believe the btree/paging layer is replaced with BDB.
>


How does BDB's (or any code from Oracle) inclusion into the SQLite
source tree affect the public domain nature of SQLite? To the extent
that there is any code from Oracle, has that been dedicated to public
domain as well? Am very curious about clarity on this.

Also, from which version on has Oracle code entered the SQLite tree?


> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkuwImUACgkQmOOfHg372QT27wCgmiuebBj/sHSDiI6CyemBquW9
> D5AAn0/rBQf2SkYQmJTcJrRsizfNt08S
> =Mocr
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
---
Assertions are politics; backing up assertions with evidence is science
===
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

sub sk79 wrote:
> How So? Is SQLite getting a high concurrency module from BDB in
> exchange for its SQL API?

I believe the btree/paging layer is replaced with BDB.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuwImUACgkQmOOfHg372QT27wCgmiuebBj/sHSDiI6CyemBquW9
D5AAn0/rBQf2SkYQmJTcJrRsizfNt08S
=Mocr
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Berkeley DB adds SQL using SQLite API !!

[Kees Nuyt]

On Sun, 28 Mar 2010 14:59:15 -0400, sub sk79
 wrote:

>Hi,
>
>Somehow no one seems to  have mentioned it on this mailing list so far!?
>Here is the scoop...
>
>On March 23, Oracle announced the latest release of Oracle® Berkeley
>DB - 11g Release 2 -  which introduces a new SQL API, based on lo and
>behold, SQLite v3 API. What this means is that all tools that work
>with SQLite will also work with Oracle Berkeley DB.
>
>Here is the link to press release:
>http://money.cnn.com/news/newsfeeds/articles/marketwire/0599534.htm

Interesting, thanks!
-- 
  (  Kees Nuyt
  )
c[_]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users