Re: Does Python 2.5.2's embedded SQLite support full text searching?

[Daniel Fetchinson]

Does Python 2.5.2's embedded SQLite support full text searching?

>
Any recommendations on a source where one can find out which SQLite
features are enabled/disabled in each release of Python? I'm trying to
figure out what's available in 2.5.2 as well as what to expect in 2.6
and 3.0.

Sqlite itself is not distributed with python. Only a python db api
compliant wrapper is part of the python stdlib and as such it is
completely independent of the sqlite build. In other words, if your
sqlite build supports full text searching you can use it through the
python sqlite wrapper (that is part of the stdlib) and if it doesn't
then not. This is true for any sqlite feature though.

So if you need an sqlite feature just go ahead and build your own
sqlite with that feature enabled and use that feature with the stock
python sqlite wrapper that comes with the stdlib.

HTH,
Daniel

[Diez B. Roggisch]

Re: Does Python 2.5.2's embedded SQLite support full text searching?

Daniel Fetchinson schrieb:

>Does Python 2.5.2's embedded SQLite support full text searching?
>>
>Any recommendations on a source where one can find out which SQLite
>features are enabled/disabled in each release of Python? I'm trying to
>figure out what's available in 2.5.2 as well as what to expect in 2.6
>and 3.0.

>
Sqlite itself is not distributed with python. Only a python db api
compliant wrapper is part of the python stdlib and as such it is
completely independent of the sqlite build. In other words, if your
sqlite build supports full text searching you can use it through the
python sqlite wrapper (that is part of the stdlib) and if it doesn't
then not. This is true for any sqlite feature though.
>
So if you need an sqlite feature just go ahead and build your own
sqlite with that feature enabled and use that feature with the stock
python sqlite wrapper that comes with the stdlib.

I doubt that. This would mean that Python comes with a mechanism to
dynamically load different libs for the same module, opening a buttload
full of error-conditions regarding library versions & changing semantics
depending on system configuration.

Instead, the sqlite standard lib comes with its own version of sqlite.
If you want something other, you need to

- install sqlite on your system, including library & headers
- compile the pysqlite extension module

it will be available in a different module path to prevent confusion.

THe same is true for ElementTree, btw.

Diez

[Diez B. Roggisch]

Re: Does Python 2.5.2's embedded SQLite support full text searching?

Diez B. Roggisch schrieb:

Daniel Fetchinson schrieb:

>>Does Python 2.5.2's embedded SQLite support full text searching?
>>>
>>Any recommendations on a source where one can find out which SQLite
>>features are enabled/disabled in each release of Python? I'm trying to
>>figure out what's available in 2.5.2 as well as what to expect in 2.6
>>and 3.0.

>>
>Sqlite itself is not distributed with python. Only a python db api
>compliant wrapper is part of the python stdlib and as such it is
>completely independent of the sqlite build. In other words, if your
>sqlite build supports full text searching you can use it through the
>python sqlite wrapper (that is part of the stdlib) and if it doesn't
>then not. This is true for any sqlite feature though.
>>
>So if you need an sqlite feature just go ahead and build your own
>sqlite with that feature enabled and use that feature with the stock
>python sqlite wrapper that comes with the stdlib.

>
I doubt that. This would mean that Python comes with a mechanism to
dynamically load different libs for the same module, opening a buttload
full of error-conditions regarding library versions & changing semantics
depending on system configuration.

And Paul Melis showed me that exactly that is the case. Sorry for the noise.

Diez

[Daniel Fetchinson]

Re: Does Python 2.5.2's embedded SQLite support full text searching?

Does Python 2.5.2's embedded SQLite support full text searching?

>
Any recommendations on a source where one can find out which SQLite
features are enabled/disabled in each release of Python? I'm trying to
figure out what's available in 2.5.2 as well as what to expect in 2.6
and 3.0.

Sqlite itself is not distributed with python. Only a python db api
compliant wrapper is part of the python stdlib and as such it is
completely independent of the sqlite build. In other words, if your
sqlite build supports full text searching you can use it through the
python sqlite wrapper (that is part of the stdlib) and if it doesn't
then not. This is true for any sqlite feature though.

So if you need an sqlite feature just go ahead and build your own
sqlite with that feature enabled and use that feature with the stock
python sqlite wrapper that comes with the stdlib.

>
I doubt that. This would mean that Python comes with a mechanism to
dynamically load different libs for the same module, opening a buttload
full of error-conditions regarding library versions & changing semantics
depending on system configuration.

That mechanism is called dynamical shared object loading. The wrapper
_sqlite3.so uses libsqlite3.so (which is the sqlite library itself,
independently of python) and so if you want to use a custom sqlite
which behaves the same as the original sqlite only it adds, for
example, a new SQL keyword that can be used in queries, all you need
to do is compile it and replace libsqlite3.so with your custom build.
If you pass the new SQL keyword in a query from python through the db
api it will travel to the part of the wrapper that is implemented in
python then to the C wrapper (_sqlite3.so) and then to your new
libsqlite3.so which interprets the new keyword correctly. Of course
you can not change the sqlite C api in this way for that you would
need to rebuild _sqlite3.so as well.

Cheers,
Daniel

Instead, the sqlite standard lib comes with its own version of sqlite.
If you want something other, you need to
>
- install sqlite on your system, including library & headers
- compile the pysqlite extension module
>
it will be available in a different module path to prevent confusion.
>
THe same is true for ElementTree, btw.