ports/125004: databases/sqlite3 with column metadata
Lapo Luchini
lapo at lapo.it
Thu Jun 26 08:10:03 UTC 2008
>Number: 125004
>Category: ports
>Synopsis: databases/sqlite3 with column metadata
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Jun 26 08:10:02 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Lapo Luchini
>Release: FreeBSD 6.3-PRERELEASE amd64
>Organization:
>Environment:
System: FreeBSD motoko.lapo.it 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #8: Thu Dec 13 09:33:49 CET 2007 root at motoko.lapo.it:/usr/obj/usr/src/sys/MOTOKO amd64
>Description:
SQLite3 has a compile option to store some (more) metadata in every query result.
Normally the "sqlite3_stmt" (the structure that contains a single statement) contains 2*N columns per row: the column name and the column value.
With this option the row gets 5*N columns, the extras being database name, table name and origin name.
Refer to <http://www.sqlite.org/c3ref/column_database_name.html> for a longer description.
My proposal is to use that option by default.
Pros:
- some language bindings (e.g. the Sqlite JDBC port I prepared yesterday) need that to implement some of the necessary features of the language (JDBC's ResultSetMetadata.getTableName(int) in Java's case)
- very little overhead: 3*N more names in RAM (only once per query, as only one row is fetched at any time), so assuming a database with "normal" names under 20 bytes some 60 bytes per column (I guess something that can run FreeBSD, even if a small embedded, don't bother about that little RAM)
- some more ports (probably) could use libsqlite3.so instead of compiling a local version themselves
Cons:
- unnecessary to most users except when analyzing the result of an unknown query or when implementing a database abstraction interface
- libsqlite3.so increases in size by 1460 bytes
Another option could be to have that as a (default on) OPTION, but given the very low overhead, I'd simply go for it personally.
>How-To-Repeat:
>Fix:
diff -ruN sqlite3.orig/Makefile sqlite3/Makefile
--- sqlite3.orig/Makefile 2008-06-25 10:45:43.000000000 +0200
+++ sqlite3/Makefile 2008-06-26 09:50:27.000000000 +0200
@@ -7,6 +7,7 @@
PORTNAME= sqlite3
PORTVERSION= 3.5.6
+PORTREVISION= 1
CATEGORIES= databases
MASTER_SITES= http://www.sqlite.org/
DISTNAME= sqlite-${PORTVERSION}
@@ -33,6 +34,8 @@
.include <bsd.port.pre.mk>
+CFLAGS+= -DSQLITE_ENABLE_COLUMN_METADATA=1
+
.if defined(WITH_DEBUG)
CONFIGURE_ARGS+= --enable-debug
.endif
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list