1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
Accessing SQLite's symbols:
===========================
Since the addition of Oracle Berkeley DB 5's SQL provider, all the sqlite3_* symbols
can be loaded twice during the execution of a program linked with Libgda. Therefore
how the sqlite3_* functions are called is important, and is the reason of the SQLITE3_CALL()
macro which _MUST_ be used everytime an sqlite3_* function is called.
The shared libraries layout to avoid symbols resolution clashed is outlined in the following
diagram (when SQLite is used from a shared library, if not, then there is no symbol clash):
libgda-4.0.so --(dlopen)--> libsqlite3.so (which exports all the sqlite3_* symbols)
--(dlopen)--> providers/libgda-sqlite.so (which does not export any sqlite3_* symbol)
--(dlopen)--> providers/libgda-bdbsql.so
--(dlopen)--> libdb-5.0.so (which exports all the sqlite3_* symbols)
As the libsqlite3.so and the libdb-5.0.so shared libraries are loaded using the G_MODULE_BIND_LOCAL
flag, their exported symbols don't clash.
Which version of SQLite is used:
================================
When embedded SQLITE is used:
* HAVE_SQLITE is *not* defined
* patch it to add the PRAGMA command
* linked as static
When system SQLITE is used:
* HAVE_SQLITE is defined
* obviously not patched for PRAGMA
* linked as dynamic => override the sqlite3CreateFunc function
* For WIN32 (or MacOSX) we would need to use another mechanism (see lattice.umiacs.umd.edu/files/functions_tr.pdf) => impose embedded static lib
Possible solutions in the future:
1 - make SQLite implement the required PRAGMA (patch proposed)
2 - don't use the required PRAGMA at all, and manage to intercept the sqlite3CreateFunc call
when statically linked (=> modify the source code of SQLite)
BLOB handling in SQLite:
========================
SQLite now supports incremental I/O for BLOBS. Any data in any column can be accessed
with this API.
When writing a blob to the database:
------------------------------------
Opening a blob requires the following information:
* the database name
* the table name
* the column name
* the ROWID
The first 3 pieces of information can be obtained from the INSERT or UPDATE statement
itself.
The ROWID can be obtained using sqlite3_last_insert_rowid() for an INSERT or must be queried
for an UPDATE.
When reading a blob from the database:
--------------------------------------
Opening a blob requires the following information:
* the database name: use sqlite3_column_database_name()
* the table name: use sqlite3_column_table_name()
* the column name: use sqlite3_column_origin_name()
* the ROWID: get it from the SELECT as the last row.
|
