OK, if everyone if putting down their wish list for 2015, here's mine:
Using the SQLite shell is very convenient for quick retrieval or
modification of data any SQLite database but there are two significant
problems (in my view) that make this of very limited utility, and this
proposed feature would solve (to a 'lite' extent):
Problem 1: Currently, any scripts have to be stored outside the database in
separate files meaning there one-file-holds-everything deal is lost (and
organizing these according to the database they refer also becomes a bit of
an issue), and
Problem 2: Dynamically passing parameters to those scripts is not very easy
without using some kind of external scripting (like Lua, Python, etc.) which
is not likely to exist on someone else's computer, so transferring just the
database file is not enough, as the recipient also need to install other
components besides SQLite3.
Proposal:
Minimal stored procedure functionality -- or, maybe call it stored query or
stored script since I would not expect any new programming constructs like
IF ... THEN ... ELSE
All that is needed is a way to put one or more SQL sentences in a single
file (stored inside the database file in some system table) and call them as
a single statement with optional parameters (e.g., call from shell with
something like @procedure_name parm1, parm2, parm3) where parameters are
simple positional text replacement -- like a simple text replacement macro
processor would do.
Example:
CREATE PROC sample AS (
SELECT table1.* FROM table1,...,tableN
WHERE ... possibly complicated join ...
AND last_name like :1
ORDER BY :2;
);
@sample 'Smith%',tax_id
would become:
SELECT table1.* FROM table1,...,tableN
WHERE ... possibly complicated join ...
AND last_name like 'Smith%'
ORDER BY last_name,tax_id;
(If you don't like CREATE PROC, make it CREATE SCRIPT or something else,
although I think PROC is good enough as it allows for possible future
expansion with more capabilities -- wish lists for 2016 and beyond.)
-----Original Message-----
From: Philip Warner
Sent: Tuesday, December 23, 2014 2:26 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Whish List for 2015
Native UNICODE?
Dates? UUID (stored as bytes, displayed as string)? I know...new data type
representations are unlikely.
Triggers with declared variables that are preserved across invocations?
(...using temp tables is a pita for storing, say, 5 numbers)
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
