SQLite User Forum

DB Abstraction/validation
Login

DB Abstraction/validation

(1) By Max (11091109) on 2022-06-30 11:31:52 [link] [source]

Hi,

I'm trying to find a tool that can implement additional layer wrapping around the SQLite file. The wrapper is for:

  1. Validation (type,min,max,regex) during UPDATE and INSERT commands.
  2. backup & Roll-back options.
  3. Some kind of visual interface for update.
  4. Validation during SELECT. Using default, if invalid.

1 is the most important feature. 4 is the least important.

Do you have any suggestion?

(2) By Kees Nuyt (knu) on 2022-06-30 12:39:18 in reply to 1 [link] [source]

I don't have an answer on all your requirements.

1 Validation (type,min,max)

I suppose with min and max you mean a range constraint on possible values. That and type can be done by SQLite itself by defining proper column constraints in the schema, and to some extent, with STRICT tables.

2 backup & Roll-back options.

An SQLite database is a file plus (often) a journal file. Any backup/restore/version control mechanism for files will also work for SQLite.

3 Some kind of visual interface for update.

4 Validation during SELECT. Using default, if invalid.

If I needed that, I would write a simple web application.

(3) By Gunter Hick (gunter_hick) on 2022-06-30 12:44:41 in reply to 1 [link] [source]

ad 1) If validation of input values is not done in the presentation layer (user interface), then it should be done in the schema via appropriate constraints

ad 2) There is a backup api, which you could use to save consistent copies of your database that you can easily revert to. You can only rollback the single currently active transaction, albeit to specific sub-transactions.

ad 3) There are numerous GUI tools for viewing and altering SQLite databases.

ad 4) This is properly done in the same place as no 1. If you have proper constraints in the schema, then there can be no "invalid values" and defaults should also be defined if different from NULL.

(4) By Max (11091109) on 2022-06-30 13:32:56 in reply to 1 [source]

I'll explain the context. The database stored in a device running Linux OS. The data saved in the DB is configuration. Few different processes use the database.

  1. The validation is to make sure the different processes don't mess up the data by writing illegal values. The validation is not per-column. I need validation per-row. Imagine that rows are: Serial#, MAC address and IP. Just an easy example.

  2. The backup is to support software update and crashes

  3. The visual tool, I mean for some external process to connect and communicate with the wrapper

(5) By Donal Fellows (dkfellows) on 2022-06-30 13:48:20 in reply to 4 [link] [source]

Per-row validation sounds like a CHECK clause to me, unless you need to cross-reference with other rows and/or tables to do the validation when you'd instead want a TRIGGER (as trigger programs have far fewer restrictions). Either way, putting validation like that in is totally normal, a standard thing to do with a database. Naturally, I advise testing that things do the right thing with validation prior to going to production; it's easy to make silly errors in validation code and you should make sure that failures produce comprehensible errors as they can otherwise be very difficult to debug.

For tools to access it, there are many existing GUI tools or you can write your own that is custom to your application. There are many languages with bindings to SQLite; you have freedom to do what you wish.

(6) By Gunter Hick (gunter_hick) on 2022-06-30 13:51:39 in reply to 4 [link] [source]

As your processes seem to be failing at validation, you need to add it to the schema. CHECK constraints and BEFORE TRIGGERS are the way to go.