is necessary to call load_extention('mod_spatialite.so') every time we connect to a database?

[Majid Hojati]

Hi,

I am a bit confused, I can connect to sqlite database easily, well I know that I have to load mod_spatialite.so extension and then call select initspatialmetadata() to enable spatialite on database.

well do I need to  load mod_spatialite.so extension every time I create new connection to databae? or it is enough for just one time? 

[mj10777]

On Saturday, 23 September 2017 16:15:31 UTC+2, Majid Hojati wrote:

Hi,

I am a bit confused,

It is very easy to remember, if you what the tools you are working with do/ar

- Sqlite3: is a Database System that supports extensions to it functionality

--> Spatialite is one of the extensions, that you can only use with the Sqlite3-Connection

For each new connection, you must load the extension (spatialite) to that connection, to use that extension.

Mark

[Majid Hojati]

thanks very much but which file do I must add? for example on my ubuntu usr/local/lib there are some files which names mod_rasterlite2.so,mod_rasterlite2.so.1 and so on.. so.1 file does not matter right?? also if I only address load_extentions('mod_spatialite.so') does it works on ubuntu or I should reference  load_extentions('usr/local/lib/mod_spatialite.so')

[a.fu...@lqt.it]

On Sat, 23 Sep 2017 07:57:23 -0700 (PDT), Majid Hojati wrote:
> thanks very much but which file do I must add? for example on my
> ubuntu usr/local/lib there are some files which names
> mod_rasterlite2.so,mod_rasterlite2.so.1 and so on.. so.1 file does
> not
> matter right??
>

Hi Majid,

on Linux any shared library is usually identified by several alias
names; it's a standard platform requirement intended to allow for
the installation of more alternative versions of the same library.

if you check all details, you'll easily discover that:
- /usr/local/lib/mod_rasterlite2.so.1.0.0
this is a physical file and has a size of several MB.
- /usr/local/lib/mod_rasterlite2.so.1
this simply is a symbolic link (aka softlink aka symlink)
referencing the previous one, and has a size of few bytes.
- /usr/local/lib/mod_rasterlite2.so
yet another symlink.

you are usually expected to load 'mod_rasterlite.so' so
to avoid requesting any specific version, and the system
will automatically load the most recent one.

there are obvious exceptions to the above base rule;
sometimes you could be compelled (for any good reason)
to load a specific version, and in this case explicitly
specifying a full module name including version infos
should be required, but it's the exception and not
the rule.

> also if I only address
> load_extentions('mod_spatialite.so') does it works on ubuntu or I
> should reference load_extentions('usr/local/lib/mod_spatialite.so')
>

there is no absolute rule, it depends on the specific
rules adopted by your Linux (that may well be, could be
possibly be modified by some local setting imposed by
your system administrator).

adopting the short form 'mod_spatialite' (note: the
.so suffix isn't strictly required) practically
intends "please system, search this module in all
directories covered by the currently set standard
searching rules for binary executables, by applying
the pre-defined priorities".

the long form intends instead "system, just look
at this file I'm referencing by its relative or
absolute path"

the usual best practice on Linux is to always depend
on system-wide searching rules, but you are obviously
free (under your full responsibility) to act
differently if you think this could be appropriate.

hint: you can eventually extend / change the standard
searching rules for your current shell session by
executing a directive like:

export "LD_LIBRARY_PATH=/usr/local/lib"

this will automatically include "/usr/local/lib"
to the list of directories being searched.

note: when loading _BOTH_ mod_spatialite and
mod_rasterlite2 you should always load RL2 first
and splite second.

bye Sandro

[a.fu...@lqt.it]

Majid,

may be I'm wrong, but I have the strong impression that you're
attempting to develop a C/C++ tool of your own.

if this is true, please notice that there is a specific
mechanism for directly linking and registering both
extensions (SpatiaLite and Rasterlite2) to any C/C++
app without depending on "load_extension()".

this basically requires:
- calling spatialite_init_ex() and/or rl2_init()
immediately after opening a new DB connection
(sqlite3_open_v2)
- calling spatialite_cleanup_ex() and/or rl2_cleanup()
immediately after closing the DB connection
(sqlite3_close)

if you are interested in this you could usefully
read the source code; there are plenty of examples
in the "tests" sources.

another source worth to have a quick look is "Main.cpp"
(spatiaite_gui): search for the code implementation
of "MyFrame::OpenDB()" and "MyFrame::CloseDB()"

bye Sandro

[Majid Hojati]

Thanks very much, In fact I have faced a problem with latest version of rl2, librasterlite2-dc56b55f35, when I try to load mod_rasterlite.so both using sql function "select load_extension('/usr/local/lib/mod_rasterlite2.so')" or using sqlite3 api I get error, while I was using sqlite browser it crashed and in its report I saw an error referring rl2_internal_data.c line 79, I have checked with earlier versions,librasterlite2-1.0.0-devel, and they work fine, I tried to load mod_rasterlite first or second but the problem persists, Is there any kind of bugs?or I am doing sth wrong?

[Majid Hojati]

Yes In fact I am working on an input plugin  for mapnik and I am learning, this is why I am asking a lot of questions, well It seems I really need to look at those functions as I need to create new databases, not for input plugin but for my own learnings.

thanks

[Majid Hojati]

So you mean I just need to call these functions and they will load extentions?It is great I'll check that, thanks

On Saturday, September 23, 2017 at 8:59:05 PM UTC+3:30, sandro furieri wrote:

[Majid Hojati]

Dear Sandro,

Well using your method ,rl2_init() , I could load rl2 with librasterlite2-dc56b55f35 version but still when I use query it does not work. 

[a.fu...@lqt.it]

On Sat, 23 Sep 2017 10:31:10 -0700 (PDT), Majid Hojati wrote:
> Thanks very much, In fact I have faced a problem with latest version
> of rl2, librasterlite2-dc56b55f35, when I try to load
> mod_rasterlite.so both using sql function "select
> load_extension('/usr/local/lib/mod_rasterlite2.so')" or using sqlite3
> api I get error, while I was using sqlite browser it crashed and in
> its report I saw an error referring rl2_internal_data.c line 79, I
> have checked with earlier versions,librasterlite2-1.0.0-devel, and
> they work fine, I tried to load mod_rasterlite first or second but
> the
> problem persists, Is there any kind of bugs?or I am doing sth wrong?
>

Hi Majid,

you are absolutely right; there was an unexpected bug (possibly
causing a fatal crash) while loading mod_rasterlite2.
the real cause was a premature call to one of the SQLite's API
(sqlite3_randomness) before completely initializing the
extension being loaded.

it was inadvertently introduced on 2017-09-12, and this fully
explains why all previous versions worked without any trouble.

this issue is now definitely fixed on the latest version of
the sources available on the Fossil repository.

thanks for noticing and reporting.

bye Sandro

[a.fu...@lqt.it]

On Sat, 23 Sep 2017 07:57:23 -0700 (PDT), Majid Hojati wrote:
> which file do I must add? for example on my
> ubuntu usr/local/lib there are some files which names
> mod_rasterlite2.so,mod_rasterlite2.so.1 and so on.. so.1 file does
> not
> matter right?? also if I only address
> load_extentions('mod_spatialite.so') does it works on ubuntu or I
> should reference load_extentions('usr/local/lib/mod_spatialite.so')
>

On Sat, 23 Sep 2017 10:34:16 -0700 (PDT), Majid Hojati wrote:
> Yes In fact I am working on an input plugin  for mapnik
>

Hi Makid,

if you are planning to develop a plugin for mapnik then you
necessarily have to pay close attention to carefully avoid
to introduce in your code any possible factor potentially
posing cross-portability issues.

your plugin will be obviously expected to nicely work not
only on Ubuntu, but also on Fedora, Debian, ArchLinux,
openSUSE, Slackware and on any other Linux.
and it should work on Windows, Apple MacOSX, FreeBSD/OpenBSD
and, may be, on Android too.

rule #1:
========
defining a module name as "mod_spatialite.so" would definitely
be a very bad idea, because the ".so" suffix is only valid on
Linux and Unix platforms.
but Windows strictly requires referencing "mod_spatialite.dll".

hint: SQLite has the capability to automatically append the
most appropriate suffix for each platform. so just referencing
"mod_spatialite" (with no explicit suffix) will greatly
improve the portability of the code you are developing.


rule #2:
========
carefully avoid to reference your modules being loaded by
passing an hard-wired path.
it could be that "/usr/local/lib" works on your development
PC, but it's very probable that it will not work on any
"production" Linux box; and it will certainly not work
on MacOsX or Windows.

hint: once again, always using the simple module name as
"mod_spatialite" so to just rely on the standard platform
searching rules is the smarter choice you can adopt and
will surely improve the portability of your code.
you could eventually adjust at run-time the system-specific
searching rules by defining some appropriate system variable
(LD_LIBRARY_PATH on Linux and Unix, PATH on Windows etc).


rule #3:
========
never reference a specific module version.
any request referencing e.g. "mod_rasterlite2.so.1"
will surely fail in the future when more advanced
versions of RasterLite2 will be possibly released.
once again, the smarter choice always is the one
to simply reference "mod_spatialite", leaving
full authority to the system for locating the
most recent version.

bye Sandro

[Majid Hojati]

Dear Sandro, Thanks for your reply,

So it is a good choice to reference only the name,

I could also use the second method you told me and it worked too,

Thanks