Hi Dominique,

On 16.10.2013 11:40, Dominique Devienne wrote:
We have an SQLite virtual-table heavy application with a lot of the GUI
driven by SQL queries, and often times we have queries of the form


...


create table t (name text, type text, primary key (name, type));
select * from t where type in (%1);


...


If I somehow missed a better work-around to this lack of array-binding, I'm
also interested of course, but obviously I'd prefer real array binding.


I am thinking about a sort of workaround:

attach ':memory:' as gui

create table gui.node(node int primary key, parent int, value);
/* Model for data binding elements with single value - one tree per widget */

create table gui.node_value(node int, typecode int, value);
/* Model for widget elements with multiple values */

create table gui.widget_binding(widget primary key, node int);
/* Current widget binding */

Or more direct alternative:

create table gui.t_based_combo(widget int primary key, label, type text);

Let see the later (for the sake of simplicity)

Variant 1: Ideally you are able to rebind your widgetkit to the inmemory gui DB (replacing your current memory containers). Then we have:

- Populating the widget data: insert into gui.t_based_combo select $widget, .... - Destroying the widget: delete from gui.t_based_combo where widget = $widget - Using widget: select * from t where type in (select type from gui.t_based_combo where widget = $widget)

Variant 2: You are not able (to rebind): Basically the same as Variant 1, but you have to inject triggers in your memory containers to keep them in sync with the gui DB. In this case probably the more general model scheme (the first one - "node" tree) will be appropriate, because you will likely implement the triggers in some base widget class.

After reading the whole tread I suspect that you have already considered the whole thing about the :memory: DB bridging the GUI with the real DB but I am curious why?

Kind Regards,
Alek


_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to