Re: [sqlite] Linux :Custom build and locking

[Alain Meunier]

Many thanks Simon.

Yes the custom build is in its own dir and the apps are linked to it in the 
code.

I am happy again :D

See you

> From: slav...@bigfraud.org
> Date: Mon, 21 Apr 2014 16:37:15 +0100
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Linux :Custom build and locking
> 
> 
> On 21 Apr 2014, at 2:03pm, Alain Meunier <dec...@hotmail.fr> wrote:
> 
> > I was discussing about the latest sqlite3 version and in the discussion 
> > came the statement that one should not use a custom builds out of the 
> > system one
> 
> SQLite is not a centralised system and isn't wired into the OS at any deep 
> level.  Programmers are meant to include the SQLite source code (.h and .c 
> files) in their own program.  Each programmer should be able to grab whatever 
> version is current when they write their program, include that version in 
> their own program, and there should be no problem with this.
> 
> There are things to avoid, however.  One is that you should avoid replacing 
> the version of SQLite someone else's program uses with another version.  So 
> if, for example, HappyFunApp calls a DLL which includes SQLite version 3.2.1 
> don't replace that DLL because HappyFunApp might depend on a bug in SQLite 
> version 3.2.1 which has been fixed in SQLite version 3.3.3.
> 
> So if Debian includes a DLL and parts of the OS call it, then you shouldn't 
> replace that DLL.  Because some part of Debian might depend on behaviour of 
> whatever version of SQLite that DLL includes.
> 
> But that doesn't cause you a problem.  Grab an up-to-date version of SQLite 
> from the web site, or download or make your own DLL which includes an 
> up-to-date version of SQLite.  Leave the original DLL alone, and keep the new 
> DLL in one of your own folders.  As long as your program doesn't try and open 
> the same database files that the OS is opening, you're okay.  Since SQLite 
> does not involve any centralised server, you could have ten different 
> versions in use at the same time on the same computer without problems.  I 
> once did a scan of an OS X Server computer (fresh installation, no apps 
> added) and found that it included, I think, four different versions of 
> SQLite, each one used by a different network service or part of the OS.
> 
> >  because of access locking/collision.
> 
> This is a puzzling thing.  As far as I'm aware, the protocol used in the 
> "access locking/collision" code in SQLite has not been changed in many years. 
>  If your program can successfully open the database then you're fine.
> 
> Simon.
> ___
> 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] Linux :Custom build and locking

[Simon Slavin]

On 21 Apr 2014, at 2:03pm, Alain Meunier  wrote:

> I was discussing about the latest sqlite3 version and in the discussion came 
> the statement that one should not use a custom builds out of the system one

SQLite is not a centralised system and isn't wired into the OS at any deep 
level.  Programmers are meant to include the SQLite source code (.h and .c 
files) in their own program.  Each programmer should be able to grab whatever 
version is current when they write their program, include that version in their 
own program, and there should be no problem with this.

There are things to avoid, however.  One is that you should avoid replacing the 
version of SQLite someone else's program uses with another version.  So if, for 
example, HappyFunApp calls a DLL which includes SQLite version 3.2.1 don't 
replace that DLL because HappyFunApp might depend on a bug in SQLite version 
3.2.1 which has been fixed in SQLite version 3.3.3.

So if Debian includes a DLL and parts of the OS call it, then you shouldn't 
replace that DLL.  Because some part of Debian might depend on behaviour of 
whatever version of SQLite that DLL includes.

But that doesn't cause you a problem.  Grab an up-to-date version of SQLite 
from the web site, or download or make your own DLL which includes an 
up-to-date version of SQLite.  Leave the original DLL alone, and keep the new 
DLL in one of your own folders.  As long as your program doesn't try and open 
the same database files that the OS is opening, you're okay.  Since SQLite does 
not involve any centralised server, you could have ten different versions in 
use at the same time on the same computer without problems.  I once did a scan 
of an OS X Server computer (fresh installation, no apps added) and found that 
it included, I think, four different versions of SQLite, each one used by a 
different network service or part of the OS.

>  because of access locking/collision.

This is a puzzling thing.  As far as I'm aware, the protocol used in the 
"access locking/collision" code in SQLite has not been changed in many years.  
If your program can successfully open the database then you're fine.

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

[sqlite] Linux :Custom build and locking

[Alain Meunier]

Hello,

I was discussing about the latest sqlite3 version and in the discussion came 
the statement that one should not use a custom builds out of the system one 
because of access locking/collision.

I would understand a bit more about that. I grabbed the latest (and greatest) 
to get cte's.

I run debian stable.

Is there something I should know before it breaks on my face ?
Is it referring to the fact that custom builds cannot manage a queue of 
multiple writers to avoid collision ?

Well I would like some opinions please,

Thanks,

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