* 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 t
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 "da
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 d
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 si
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
> 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 applicati
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
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
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 yo
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
>
SQ
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 oppon
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
-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?
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
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 modul
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
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
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 (
-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
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
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 tha
21 matches
Mail list logo
