Note: these pages are no longer maintained

Never the less, much of the information is still relevant.
Beware, however, that some of the command syntax is from older versions, and thus may no longer work as expected.
Also: external links, from external sources, inside these pages may no longer function.

	Language bindings: [C/C++, Java, Python, PHP ...]
2011 January 28

Previous Slide

Table of Contents

Both SQLite and SpatiaLite are elementary simple are really lightweight.
So both them are obvious candidates when you are a software developer, and your application absolutely requires a robust and affordable Spatial DBMS support, but you are attempting to keep anything as simple as possible, possibly avoiding at all any unnecessary complexity.

The best fit development language supporting SQLite and SpatiaLite is obviously C [or its ugly duckling son, the C++]
(after all, both SQLite and SpatiaLite are completely written in C language).
Using C/C++ you can directly access the wonderful APIs of both SQLite and SpatiaLite, so to get a full and unconstrained access to any supported feature at the lowest possible level.
And that's not all: using C/C++ you can eventually adopt static linkage, so to embed directly within the executable itself (and with an incredibly small footprint) a fully self-contained DBMS engine.
And such an approach surely gets rid of any installation related headache.

Anyway you are not at all compelled to necessarily use C/C++
SQLite and SpatiaLite are supported as well by many other languages such as Java, Python, PHP (and probably many others).

The basic approach

Any language supporting any generic SQLite driver aka connector can fully support SpatiaLite.
SQLite supports dynamic extension loading; and SpatiaLite simply is such an extension.

SELECT load_extension('path_to_extension_library');

Executing the above SQL statement will load any SQLite's extension: this obviously including SpatiaLite.
Anyway, too much often this is true only in theory, but reality is completely different from this.

Let us quickly examine the main issues actually bringing this simple approach to a complete failure:

SQLite is highly configurable; it supports lots and lots of build-time options.
You can completely disable at all the dynamic extension load mechanism, if you think this one could be a safe option.
Sadly, for many long years this one has been the favorite choice for the vast majority of system packagers.
SQLite is growing very quickly: usually a major update is released every few months.
But many system packagers still continue distributing incredibly obsolete SQLite's versions.
And quite obviously such obsolete versions cannot adequately support SpatiaLite.
Once you are caught in this painful situation (disabled extensions / obsolete SQLite) you cannot do absolutely nothing.
You simply have to give up forgetting SpatiaLite: at least for now.
Anyway, if this is your actual case, doesn't lose heart: things evolves, and usually tends to evolve in the right direction.
Just two years ago very few languages supported SpatiaLite.
Today this isn't any longer true for the most widely used languages (at least, using recently released versions).

You can usefully read the appropriate section corresponding to your beloved language, so to get started in the quickest time.
Each section contains a complete sample program, and contains as well any related system configuration hint, compiler/linker settings and so on:

Previous Slide

Table of Contents

	Author: Alessandro Furieri a.furieri@lqt.it
	This work is licensed under the Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license.

	Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.