On 12/19/2018 10:02, Jens Alfke wrote:
On Dec 18, 2018, at 7:46 PM, Roger Schlueter <se...@cox.net> wrote:

I am starting work on a prototype application so this might be an excellent 
opportunity to use SQLite for my application file format.  Part of this would 
be the saving and restoring of GUI elements such as window positions and sizes, 
control states, themes, etc.
IMHO something like JSON is a good format for such config/preference data, 
instead of having a table with a column for every pref. During development 
you’ll often be adding new prefs, and it’s a pain to have to update a CREATE 
TABLE statement every time you add one. It’s even more of a pain to have to 
handle a schema change with ALTER TABLE in an app upgrade that adds a new pref. 
If you use JSON you just have to come up with a new string to use as the key 
for each pref. It’s also easy to have structured values like arrays or nested 
objects. (FWIW, his is essentially the way that Apple OS’s manage app prefs via 
the NSUserDefaults class.)

   JSON or XML: Two sides of the same coin.  If I wanted to go the
   separate file approach, I'd just use the settings class of Visual
   Studio since all the required plumbing is already in place.

   More importantly, as I noted this is a prototype (read: test)
   application so it is a good opportunity for me to get my feet wet
   with SQLite since I'm a n00b with it.

Of course you can save the JSON in the database file. Just create a ‘prefs’ 
table with one blob column for the JSON.

A related solution is to store each named pref as a row in the ‘prefs’ table, 
identified by a ‘key’ column.

   In fact, this statement makes the concerns you raised in the first
   paragraph moot.  A simple table with four columns:

    1. Window name
    2. Control name
    3. Control property
    4. Property value

   covers all the possibilities, no ALTER table necessary.  If I want
   to enable per user values, I'd just add a User column.

In short, the design part is easy IMO.  I'm still hoping to see some examples since, surely, I'm not the first person to go this route.

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

Reply via email to