RE: [sqlite] like, but not equal?

2004-07-24 Thread David Morel
Le sam 24/07/2004 à 21:23, Steve O'Hara a écrit :
> Also, LIKE doesn't use an index so don't expect great performance

Well, although sqlite doesn't use an index, the performance of the like
clause still is truly amazing to me. I'm talking hundreds of thousands
of rows here, filled with paths and filenames...

By the way, I wonder how indexes can be used on like clauses (design
level), as I guess full-featured rdbms make use of them. But how?
Anybody has a clue? 
-- 
***
[EMAIL PROTECTED]
OpenPGP public key: http://www.amakuru.net/dmorel.asc



signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=


Re: [sqlite] again on sqlite as a standard, was: SQLite and OOo

2004-07-24 Thread koneill
I was wondering if internal functions saving to and from an XML data file
(an XML file dumper?) might be sufficient to export/import from SQLite
standard datafile (I mean without having all the data in the same file, but
having multiple files); in any case, export/import functions might be part
of the SQLite library file or alternatively as part of the program that is
using the library;
You could perhaps have separate XML files for each table or whatever;
Importation of an XML file would have to be within the constraints of the
SQLite data structure in any case;
On the other hand I am not sure why there is really a problem: it might be
simpler just to add SQLite compatibility to any program like OpenOffice if
they want to have SQLite as a standard, it seems to me that SQLite is
appearing on most platforms anyway!

Kevin O'Neill

- Original Message -
From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 24, 2004 11:29 PM
Subject: Re: [sqlite] again on sqlite as a standard, was: SQLite and OOo


> M. Fioretti wrote:
> >
> >>The main drawback of SQLite is that it doesn't support ALTER
> >>TABLE. It's a big limitation for simple users when building a
> >>database. If this fonctionnality (and a few others) could be add in
> >>a near future, SQLite would probably become the first choice for
> >>OOo.
> >>
> >
>
> ALTER TABLE will probably start appearing (in stages) over the
> next several months.  Rename table and rename column will appear
> first.  Then add column and drop column.  Finally add and drop
> constraints.
>
> >
> > 2)
> >
> >>So I hope that SQLite developpers will be able to work together with
> >>OOo developpers to write an embeded OOo driver for SQLite (not
> >>ODBC), and then to store SQLite database in the future OOo base file
> >>format.
> >
>
> Storing an SQLite database as part of a larger file is problematic.
> (1) The SQLite database section needs to be contiguous and it
> needs to be growable. So at the very least, it would need to be
> at the end of the larger file.  (2) If stored as part of a larger
> file, standard tools (such as sqlite3.exe) would not be able to
> read it since they would not know where to look for the start of
> the database.  (3) SQLite needs a separate rollback journal file
> in order to support ACID transactions.  Perhaps these objections
> could be overcome if I better understood the problem.
>
>
> --
> D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
>



[sqlite] sqlite3 crashing on OS X

2004-07-24 Thread dave
I've been digging through a problem I'm having with spontaneous 
crashing with sqlite 3.0.3 on OS X 10.3.4, and finally have it down to 
a small amount of demo code.

First, it doesn't happen if I run the code in the main thread, only 
when I spawn a thread for it--even though it's the only thread that 
touches sqlite, and regardless of whether I compile with 
--enable-threadsafe or not. It always happens at the same place (here, 
on the sixth CREATE TABLE statement), though the location seems to 
depend on the amount of cumulative text in the sqlite3_exec() calls. 
You can reorder them, and it usually crashes around the sixth 
statement.

Here's the stack trace:
#0  0xdc50 in balance_shallower (pPage=0x2804c30) at 
../src/btree.c:3283
#1  0xdbc4 in balance_nonroot (pPage=0xd) at ../src/btree.c:3260
#2  0xdebc in balance_deeper (pPage=0x2804c30) at 
../src/btree.c:3395
#3  0xdf14 in balance (pPage=0x2804c30) at ../src/btree.c:3408
#4  0xe198 in sqlite3BtreeInsert (pCur=0x55e3a0, pKey=0x0, 
nKey=17221830959, pData=0x55e490, nData=201) at ../src/btree.c:3521
#5  0x0003398c in sqlite3VdbeExec (p=0x2808200) at ../src/vdbe.c:3053
#6  0x0001f2d0 in sqlite3_step (pStmt=0x55e340) at ../src/vdbeapi.c:159
#7  0xa36c in sqlite3_exec (db=0xc9, zSql=0x280ac40 "", 
xCallback=0, pArg=0x40dbc, pzErrMsg=0x0) at ../src/legacy.c:79

and here's the code (XCode 1.2 project):
  http://www.opaque.net/~dave/dbtest.tgz
Can another OS X user give this a try, see if it crashes for you? Any 
ideas what's going on?

If you've got a fix for me I'll send you a swank Panic brand t-shirt. 
If it's something really obvious and stupid I've done, two. :)

Thanks,
-Dave


Re: [sqlite] again on sqlite as a standard, was: SQLite and OOo

2004-07-24 Thread M. Fioretti
On Sat, Jul 24, 2004 17:29:22 PM -0400, D. Richard Hipp
([EMAIL PROTECTED]) wrote: 
 
> ALTER TABLE will probably start appearing (in stages) over the
> next several months. 

Duly noted, thanks.

> Storing an SQLite database as part of a larger file is problematic.

Well, even today, an OASIS text file (.sxw) is actually a zip file
which contains a folder with the actual text, XML info,
pictures... all in separate files. grab any sxw file you can find,
unzip it and see what I mean. Maybe what we want is the same thing
*plus* the SQLite file?

Ciao,
Marco F.

-- 
Marco Fiorettimfioretti, at the server mclink.it
Red Hat & Fedora for low memory   http://www.rule-project.org/

A dream will always triumph over reality, once it is given the chance.
Stanislaw Lem


Re: [sqlite] again on sqlite as a standard, was: SQLite and OOo

2004-07-24 Thread D. Richard Hipp
M. Fioretti wrote:

The main drawback of SQLite is that it doesn't support ALTER
TABLE. It's a big limitation for simple users when building a
database. If this fonctionnality (and a few others) could be add in
a near future, SQLite would probably become the first choice for
OOo.

ALTER TABLE will probably start appearing (in stages) over the
next several months.  Rename table and rename column will appear
first.  Then add column and drop column.  Finally add and drop
constraints.
2)
So I hope that SQLite developpers will be able to work together with
OOo developpers to write an embeded OOo driver for SQLite (not
ODBC), and then to store SQLite database in the future OOo base file
format.

Storing an SQLite database as part of a larger file is problematic.
(1) The SQLite database section needs to be contiguous and it
needs to be growable. So at the very least, it would need to be
at the end of the larger file.  (2) If stored as part of a larger
file, standard tools (such as sqlite3.exe) would not be able to
read it since they would not know where to look for the start of
the database.  (3) SQLite needs a separate rollback journal file
in order to support ACID transactions.  Perhaps these objections
could be overcome if I better understood the problem.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


[sqlite] again on sqlite as a standard, was: SQLite and OOo

2004-07-24 Thread M. Fioretti
Greetings, 

I am putting together the final version of my article about sqlite as
a common db standard format between OO.o, KOffice etc...  In this
context, I'd like to know if SQLite developers have further comments
onthe two issues below.

 On Tue, Jul 20, 2004 11:50:03 AM +0200, Yves Chaufour
([EMAIL PROTECTED]) wrote:
 
1)
> The main drawback of SQLite is that it doesn't support ALTER
> TABLE. It's a big limitation for simple users when building a
> database. If this fonctionnality (and a few others) could be add in
> a near future, SQLite would probably become the first choice for
> OOo.
> 

2)
> So I hope that SQLite developpers will be able to work together with
> OOo developpers to write an embeded OOo driver for SQLite (not
> ODBC), and then to store SQLite database in the future OOo base file
> format.

TIA,
Marco Fioretti

-- 
Marco Fiorettimfioretti, at the server mclink.it
Red Hat & Fedora for low memory   http://www.rule-project.org/

None can love freedom heartily but good men; the rest love not freedom
but license.   John Milton


Re: [sqlite] like, but not equal?

2004-07-24 Thread dave
On Jul 24, 2004, at 2:45 AM, Paolo Vernazza wrote:
[EMAIL PROTECTED] wrote:
How can a string be like something that has no wildcards, but not 
equal to it? My hunch is it has something to do with character 
encoding, but is that really how it should work?
Like is not case sensitive...
Hey, I never knew that--I always did LOWER(foo) LIKE '%whatever%', 
unnecessarily.

But the string in the database is definitely all lower-case. And, of 
course, when I try it again now it works correctly, the strings are 
equal and not just like.

Ugh.
-D


Re: [sqlite] OT: Reply-To Munging Considered Useful

2004-07-24 Thread David Morel
Le sam 24/07/2004 à 04:03, Darren Duncan a écrit :
> At 11:49 AM -0500 7/23/04, Greg Miller wrote:
> >There are certainly a few drawbacks to using Reply-To, but I can't 
> >remember the last time I was on a mailing list that didn't make use 
> >of it. Clearly, there's a very solid consensus out there that 
> >Reply-To is the way to go.
> 
> That may be because a large fraction of email lists use something 
> like Yahoogroups, which often uses reply-to-group as a default 
> setting, though thankfully Yahoo lets you turn that option off. -- 
> Darren Duncan

I just checked and, for instance, samba-users and security focus lists
use the classic behaviour: no reply-to munging. So I think it would be
great if it was a user option so everyone could stick to their little
habits.

-- 
***
[EMAIL PROTECTED]
OpenPGP public key: http://www.amakuru.net/dmorel.asc



signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=


[sqlite] like, but not equal?

2004-07-24 Thread dave
I just finished translating my sqlite2 code into sqlite3 and, hey, it 
compiles! But it looks like I've still got some work ahead of me..

Here's my first question: what's going on here (from command line 
sqlite3)?

  sqlite> select count(*) from newsgroups where name = 
'rec.arts.anime.fandom';
  0
  sqlite> select count(*) from newsgroups where name like 
'rec.arts.anime.fandom';
  1

How can a string be like something that has no wildcards, but not equal 
to it? My hunch is it has something to do with character encoding, but 
is that really how it should work?

Thanks,
-Dave