In many situations there are already applications running for quite some time and the question arises if it is worth to switch over to MonetDB/e for the improved performance. In those cases, the effort required should be kept to a minimum. Note that MonetDB/e provides a wealth of SQL features derived from MonetDB directly, i.e. enriched base types, controlled parallelism, persistent stored modules, UDFs,… which are not necessarily available in the systems mentioned below. Using such features may improve the performance of you program, but also could hinder a reversion from a MonetDB/e application into your hitherto favored system. An extensive description of the functionality can be found on the MonetDB website.
Porting C programs¶
Applications written in C using the MonetDB API unfortunately need some reworking. The MonetDB/e API is a subset of the old API and contains an interface geared at an embedded situation.
The repository MonetDBe example contain a series of examples written in MonetDBe and C to learn the API by example.
If the application program uses multiple concurrent client-side threads to interact with the embedded database, each concurrent API consuming thread must use a non-shared monetdbe_database handle for its API calls. In other words monetdbe_database handles are not thread-safe. See the concurrent.c source file in the MonetDBe example repository for an example of a correct implementation of concurrent access to an embedded database.
Porting SQLite3 programs¶
A plethora of programs are written in SQLite 3 and its website contains an extensive account on the particulars.
Migration starts with replacing all occurrences of the sqlite3 with monetdbe in the Python program.
The following functionality is not supported by MonetDB/e or contains syntax/semantic differences.
SQLite works with a single file / archive, MonetDB/e works with a directory/folder.
SQLite is based on manifest typing, MonetDB/e on rigid types.
SQLite allows current access to the same local database using file-based locking?
No cross platform data exchange format (big- little- endians)
Thread safety no specific control.
Copy statement delimiters may be different.
INTEGER PRIMARY KEY should be mapped to the SERIAL type in MonetDB/e.
VACUUM is not supported. Garbage collection is implicit.
EXPLAIN is based on the MonetDB abstract machine.
PRAGMAs are not recognized.
ON CONFLICT not supported.
REPLACE not supported
ATTACH and DETACH replaced by connect().
FTS5 not supported.
Rtree not supported.
We highly appreciate user feed back for migrations undertaken in the MonetDB/e issue tracker on GitHub or stackoverflow. Both as a warning and best practices for those who follow, but also to assess the need for features hitherto not available in MonetDB/e
We welcome migration advice for other (embedded) database systems. Features needed can be left behind in the issue tracker.