Re: [sqlite] Version 3.3.0 (alpha)

[Brett Wilson]

Does anybody know if there anything special we have to do to get the
new boolean optimization? Does it apply to any 0/1 integer values you
put in a cell, or does the column have to be declared as BOOLEAN?

Thanks,
Brett

On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> SQLite version 3.3.0 is now available on the website
>
>http://www.sqlite.org/
>
> Version 3.3.0 incorporates many enhancements and changes.
> Among the changes in this release:
>
>*  CHECK constraints are now enforced.
>
>*  The IF [NOT] EXISTS syntax of MySQL is now recognized on
>   CREATE/DROP TABLE/INDEX statements.
>
>*  DESC indices really are descending now.  The DESC keyword
>   on index definitions used to be ignored.
>
>*  The database file format has changed slightly to more
>   compactly represent boolean values and to support DESC
>   indices.  Version 3.3.0 will read and write all prior
>   version 3 databases.  But new databases created by
>   version 3.3.0 will not be readable by older versions
>   of SQLite.  If this is a problem for your application,
>   compile SQLite using
>
>  -DSQLITE_DEFAULT_FILE_FORMAT=1
>
>   and then version 3.3.0 will create new databases in
>   the legacy format understood by all prior versions of
>   SQLite.  DESC indices only work in the new format.
>
>*  SQLite now distinguishes between REAL and INTEGER columns
>   and attempts to make appropriate conversions.
>
>*  The OS-interface layer has been modified for greater
>   flexibility and control of custom ports and implementations.
>
>*  SQLite now responses better to out-of-memory errors.  The
>   library will recover and reset itself automatically.  There
>   is no longer a need to call sqlite3_global_recover().  The
>   new sqlite3_enable_memory_management() API can be used to put
>   SQLite into a mode where it will automatically try to reduce
>   its database cache size when it comes under memory pressure.
>
>*  The database cache and parsed schema information can now
>   optionally be shared between two or more database connections.
>   This can be used to reduce I/O and to improve concurrency.
>   On a database using a shared cache, you can specify
>   READ UNCOMMITTED isolation as an option (the default is
>   SERIALIZABLE).  With READ UNCOMMITTED, a reader will not
>   block or be blocked by a writer and you will never get
>   an SQLITE_BUSY error on a read.
>
> There have been many internal changes to SQLite.  The library
> passed a full regression test with no errors prior to this
> release, but even so you can expect to find a few bugs.
> Please report them. Consider this release to be an alpha.
>
> --
> D. Richard Hipp <[EMAIL PROTECTED]>
>
>

Re: [sqlite] Version 3.3.0 (alpha)

[Weissmann Markus]

On 21.01.2006, at 20:41, [EMAIL PROTECTED] wrote:


Weissmann Markus <[EMAIL PROTECTED]> wrote:


oh, well - thanks for this hint! Nevertheless sqlite 3.3.1 (still)
does not complain:

SQLite version 3.1.3
sqlite> create table t (a integer primary key, b integer, check(b  
> 0));

sqlite> insert into t(b) values(-19);
sqlite> select * from t;
1|-19



You example is from version 3.1.3, not 3.3.1.  Version 3.1.3
does not enforce check constraints.  Version 3.3.1 does.



o.k. - then I do have a build problem:
I'm building on OS X 10.4 where sqlite3 3.1.3 comes with the OS.
Whatever I do, I get a sqlite3 binary that claims to be version 3.1.3.
The installed header file, configure & the Makefile all carry version
3.3.1 And also the binary is linked to my new libsqlite3, not the
system's.

I first thought the build would somehow grab the version from the
system's sqlite3.h, but after moving it aside and rebuilding, I still
get a binary with version 3.1.3.

Are the sources messed up or the build mechanism? I can't find
occurrences of 3.1.3 in the sources... any hints appreciated!




Here is a screen scrap from where I just tried your test:

   SQLite version 3.3.1
   Enter ".help" for instructions
   sqlite> create table t (a integer primary key, b integer, check 
(b>0));

   sqlite> insert into t(b) values(-19);
   SQL error: constraint failed
   sqlite> select * from t;
   sqlite>


cool - as soon as I get 3.3.1 to run, I'll check this out!


-Markus

---
Markus W. Weissmann
http://www.mweissmann.de/
http://www.opendarwin.org/~mww/

Re: [sqlite] Version 3.3.0 (alpha)

[drh]

Weissmann Markus <[EMAIL PROTECTED]> wrote:
> 
> oh, well - thanks for this hint! Nevertheless sqlite 3.3.1 (still)  
> does not complain:
> 
> SQLite version 3.1.3
> sqlite> create table t (a integer primary key, b integer, check(b > 0));
> sqlite> insert into t(b) values(-19);
> sqlite> select * from t;
> 1|-19
> 

You example is from version 3.1.3, not 3.3.1.  Version 3.1.3
does not enforce check constraints.  Version 3.3.1 does.
Here is a screen scrap from where I just tried your test:

   SQLite version 3.3.1
   Enter ".help" for instructions
   sqlite> create table t (a integer primary key, b integer, check(b>0));
   sqlite> insert into t(b) values(-19);
   SQL error: constraint failed
   sqlite> select * from t;
   sqlite> 

--
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] Does anyone know how I would uninstall sqlite?

[twoeyedhuman]

I think it worked!  I tried to the make -n install method and found this:
/usr/bin/install -c -d /usr/local/lib
./libtool --mode=install /usr/bin/install -c libsqlite3.la /usr/local/lib
/usr/bin/install -c -d /usr/local/bin
./libtool --mode=install /usr/bin/install -c sqlite3 /usr/local/bin
/usr/bin/install -c -d /usr/local/include
/usr/bin/install -c -m 0644 sqlite3.h /usr/local/include
/usr/bin/install -c -d /usr/local/lib/pkgconfig;
/usr/bin/install -c -m 0644 sqlite3.pc /usr/local/lib/pkgconfig;

So since everything about sqlite3 had *sql* in it, i just did $ su -c "rm
*sql*" for those directories.  Good as new!

On 1/21/06, Nathan Kurz <[EMAIL PROTECTED]> wrote:
>
> > twoeyedhuman wrote:
> > > I have the latest version of sqlite3 on my debian box and I'd like
> > > to uninstall it because I keep getting this error through bash:
> > > sqlite3: error while loading shared libraries: libsqlite3.so.0:
> > > cannot open shared obje ct file: No such file or directory I'm
> > > actually running xandros linux and I just want to find where all
> > > the files were installed so I can delete them manually and install
> > > sqlite through a debian package.  Is this possible?
>
> I missed the original post, so I apologize if these were already
> suggested, but some possibilities for finding this out include:
>
> 1) If you installed from source, try 'make -n install' from the source
>directory.  This is simulate the 'install' command without actually
>doing anything.  Look through the results to see where things go.
>
> 2) Many Linux systems have a command called 'locate' (also called
>'slocate').  If you system has this, trying 'locate sqlite' will
>probably show you what you need to remove.
>
> 3) Linux sometimes needs the command 'ldconfig' to be run as root when
>shared libraries are updated.  It's possible that running this will
>get rid of your error and let you use the new version.
>
> 4) 'ldd' and 'strace' are useful commands for figuring out which
>shared libraries are being used and where they are located.  Trying
>'ldd /usr/local/bin/sqlite3' or 'strace sqlite3' might help you.
>
> Good luck!
>
> --nate
>



--
-TwoEyedHuman
tech support d00d at Glenkirk
www.glenkirk.org
my home: greenguy41.csoft.net
linux user 39

Re: [sqlite] Re: Version 3.3.0 (alpha)

[Weissmann Markus]

On 21.01.2006, at 19:01, Igor Tandetnik wrote:


Weissmann Markus <[EMAIL PROTECTED]> wrote:

could someone please elaborate on this one?

sqlite> create table t (a int primary key, b int, check(0 insert into t(b) values(1);

does not complain, so what checks exactly can we do now?


check(0 create table t (a integer primary key, b integer, check(b > 0));
sqlite> insert into t(b) values(-19);
sqlite> select * from t;
1|-19


-Markus

---
Markus W. Weissmann
http://www.mweissmann.de/
http://www.opendarwin.org/~mww/

[sqlite] Re: Version 3.3.0 (alpha)

[Igor Tandetnik]

Weissmann Markus <[EMAIL PROTECTED]> wrote:

could someone please elaborate on this one?

sqlite> create table t (a int primary key, b int, check(0 insert into t(b) values(1);

does not complain, so what checks exactly can we do now?


check(0

Re: [sqlite] Version 3.3.0 (alpha)

[Weissmann Markus]

On 11.01.2006, at 02:55, [EMAIL PROTECTED] wrote:


SQLite version 3.3.0 is now available on the website

   http://www.sqlite.org/

Version 3.3.0 incorporates many enhancements and changes.
Among the changes in this release:

   *  CHECK constraints are now enforced.



could someone please elaborate on this one?

sqlite> create table t (a int primary key, b int, check(0 insert into t(b) values(1);

does not complain, so what checks exactly can we do now?
I couldn't find anything about this on the website.


thanks,

-Markus

---
Markus W. Weissmann
http://www.mweissmann.de/
http://www.opendarwin.org/~mww/

Re: [sqlite] Does anyone know how I would uninstall sqlite?

[Nathan Kurz]

> twoeyedhuman wrote:
> > I have the latest version of sqlite3 on my debian box and I'd like
> > to uninstall it because I keep getting this error through bash:
> > sqlite3: error while loading shared libraries: libsqlite3.so.0:
> > cannot open shared obje ct file: No such file or directory I'm
> > actually running xandros linux and I just want to find where all
> > the files were installed so I can delete them manually and install
> > sqlite through a debian package.  Is this possible?

I missed the original post, so I apologize if these were already
suggested, but some possibilities for finding this out include:

1) If you installed from source, try 'make -n install' from the source
   directory.  This is simulate the 'install' command without actually
   doing anything.  Look through the results to see where things go.

2) Many Linux systems have a command called 'locate' (also called
   'slocate').  If you system has this, trying 'locate sqlite' will
   probably show you what you need to remove.

3) Linux sometimes needs the command 'ldconfig' to be run as root when
   shared libraries are updated.  It's possible that running this will
   get rid of your error and let you use the new version.

4) 'ldd' and 'strace' are useful commands for figuring out which
   shared libraries are being used and where they are located.  Trying
   'ldd /usr/local/bin/sqlite3' or 'strace sqlite3' might help you.

Good luck!

--nate

RE: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

[Fred Williams]

I think if you will closely read you own analysis of your efforts you
will realize that all of the "down side" issues you have enumerated
relate directly to the implementation language and not the database or
its structure.  In Java there is no such thing as AnythingLite, IMHO.
Java, like so many other languages has grown well beyond its initial
intent, small, simple applets imbedded on a web page.

With all of our advances in programming we still have not evolved that
"perfect" language, and most likely never will.  I spite of what those
"C" guys tell you :-)

Fred

> -Original Message-
> From: Steve O'Hara [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 21, 2006 7:37 AM
> To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
> Subject: [sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java
>
>
>
> I did loads of research on this and even tinkered with a c to Java
> converter, which got me a little bit further forward.  However, I
> realised that I would be facing a huge effort to create the code base
> and then have to support it within our projects.  So despite being an
> SQLite zealot, I had to reluctantly nail my colours to one of the
> existing Java tools.
>
> I chose HSQLDB, after trying out most of the others, this was the only
> one that got close to the file distribution format of SQLite i.e.
> database in a file.  It took quite a bit of tinkering to get the right
> mix of CACHED and MEMORY tables so that performance on start-up was
> good.  Also, I had terrible trouble with mass imports causing memory
> (what a surprise - Java) problems and it took a good few runs
> to get it
> to properly index etc.  Also, I had to be much more specific about the
> column definitions than with SQLite, otherwise my database files grew
> horribly.  Also, you can only interact with HSQLDB via JDBC, not a big
> problem in Java obviously.  Performance was nowhere near as good as
> SQLite.
>
> However, the upside is that HSQLDB is free, simple to deploy, has
> standalone/server/servlet/in-memory deployment versions and is
> reasonably perfomant.
>
> Hope this helps,
>
> Steve
>
> p.s. I'd still prefer a Java SQLite but there you are
>
>
>
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:sqlite-users-return-9982-sohara=pivotal-solutions.co.u
[EMAIL PROTECTED]
rg] On Behalf Of Ran
Sent: 19 January 2006 14:13
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: [RBL] Re: [sqlite] Sqlite and Java

If I am not mistaken, the following thread might be relevant:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg11005.html

Ran

On 1/19/06, Nilo Paim <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Does anybody here knows something about a port of sqlite to java?
>
> Please, note that I'm not talking about java calling sqlite via JNI,
but
> about a real rewrite of sqlite using java. Obviously, a second step
> would be the writing of a JDBC driver.
>
> Would be useful that port?
>
> Comments? Suggestions?
>
> Thanks to all.
>
> Nilo
> Porto Alegre - Brasil
>

[sqlite] RE: [RBL] Re: [sqlite] Sqlite and Java

[Steve O'Hara]

I did loads of research on this and even tinkered with a c to Java
converter, which got me a little bit further forward.  However, I
realised that I would be facing a huge effort to create the code base
and then have to support it within our projects.  So despite being an
SQLite zealot, I had to reluctantly nail my colours to one of the
existing Java tools.

I chose HSQLDB, after trying out most of the others, this was the only
one that got close to the file distribution format of SQLite i.e.
database in a file.  It took quite a bit of tinkering to get the right
mix of CACHED and MEMORY tables so that performance on start-up was
good.  Also, I had terrible trouble with mass imports causing memory
(what a surprise - Java) problems and it took a good few runs to get it
to properly index etc.  Also, I had to be much more specific about the
column definitions than with SQLite, otherwise my database files grew
horribly.  Also, you can only interact with HSQLDB via JDBC, not a big
problem in Java obviously.  Performance was nowhere near as good as
SQLite.

However, the upside is that HSQLDB is free, simple to deploy, has
standalone/server/servlet/in-memory deployment versions and is
reasonably perfomant.

Hope this helps,

Steve

p.s. I'd still prefer a Java SQLite but there you are

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
rg] On Behalf Of Ran
Sent: 19 January 2006 14:13
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: [RBL] Re: [sqlite] Sqlite and Java

If I am not mistaken, the following thread might be relevant:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg11005.html

Ran

On 1/19/06, Nilo Paim <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Does anybody here knows something about a port of sqlite to java?
>
> Please, note that I'm not talking about java calling sqlite via JNI,
but
> about a real rewrite of sqlite using java. Obviously, a second step
> would be the writing of a JDBC driver.
>
> Would be useful that port?
>
> Comments? Suggestions?
>
> Thanks to all.
>
> Nilo
> Porto Alegre - Brasil
>

Re: [sqlite] Does anyone know how I would uninstall sqlite?

[Clay Dowling]

twoeyedhuman wrote:
> I have the latest version of sqlite3 on my debian box and I'd like to
> uninstall it because I keep getting this error through bash:
> 
> sqlite3: error while loading shared libraries: libsqlite3.so.0: cannot open
> shared obje ct file: No such file or directory
> 
> I'm actually running xandros linux and I just want to find where all the
> files were installed so I can delete them manually and install sqlite through
> a debian package.  Is this possible?

First, find out where your system has installed these libraries.  By
default libsqlite3.so installs in /usr/local/lib, but Linux
distributions don't like to put much of anything there.  sqlite3 itself
installs to /usr/local/bin by default, but again don't assume that's
where it's gotten to.  The last file you'll need to delete will be
sqlite3.h, which by default goes to /usr/local/include.

A typical Linux distribution trick is to move these from /usr/local to
/usr.  Also be aware that if you didn't install the development package,
you might not have sqlite3.h, but hunt it out and be sure.  If it's
installed in /usr/include and you don't delete it, you're going to be in
for a rough ride when you try to built SQLite based software.

Clay Dowling