SQLite notes: Difference between revisions

From Helpful
Jump to navigation Jump to search
 
Line 311: Line 311:
===CLI admin===
===CLI admin===
<!--
<!--
Note that the CLI is intentionally simple, so
Sometimes even just getting a column name to be readable (in {{inlinecode|.mode column}}) requires trickery bcause
.width auto
just looks at XX so sometimes forcing things like:
.width 10 10 30 10 auto
sqlite> SELECT * FROM sqlite_master;
works a little better.
https://www.sqlite.org/cli.html#changing_output_formats
Vacuum database:
Vacuum database:
  vacuum
  vacuum
Line 320: Line 337:
  SELECT name FROM sqlite_master; -- since 3.33, before that:
  SELECT name FROM sqlite_master; -- since 3.33, before that:
  SELECT name FROM sqlite_schema;
  SELECT name FROM sqlite_schema;
List indexes:
.indexes
-- or
PRAGMA index_list()




Line 337: Line 359:
  SELECT name ,SUM(pgsize)/1024 table_size  FROM "dbstat" GROUP BY name ORDER BY table_size desc;
  SELECT name ,SUM(pgsize)/1024 table_size  FROM "dbstat" GROUP BY name ORDER BY table_size desc;
(note: requires SQLITE_ENABLE_DBSTAT_VTAB)
(note: requires SQLITE_ENABLE_DBSTAT_VTAB)
.schema
.fullschema also adds things like the stat_ tables (the intent seems debugging that recreates the query plan).
.databases - open databases in current connection, where main is your data, and temp seems a tablespace for temporary tables.
.open opens another database file (after closing the current)
.read and .import are for importing data from SQL and CSV files
.dump puts the current database into one UTF string, usually used from the prompt something like
sqlite3 example.db .dump | gzip -c > example_db.sql.gz
As the docs mention this is pure SQL so you ''could'' stream it to another database engine.





Latest revision as of 17:53, 25 March 2024

Database related

More theoretical - thinking about databases:

Everyday-use notes

For some introduction, see Some_databases,_sorted_by_those_types#SQLite

On text coding

On SQLite typing
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

This page mentions a lot of what you want to know.


For contrast: where most RDBMSes are statically typed (converts data to the column's type on storage, fails if it can't)...

...SQLite is more like dynamic typing in that SQLite decides the type from the value you give it, and only somewhat cares about the according column's type.


A little more precisely, the schema defines a type affinity, not a rigid type.

'type affinity' here meaning 'the value may still be of any type, but we prefer this one if that works'

The SQL types map to the affinity of INTEGER, REAL, NUMERIC, TEXT, BLOB, or NULL

e.g. INTEGER is split into seven specific-sized things -- on disk, anyway; in memory all are loaded into int64(verify)
TEXT is stored as UTF-8, UTF-16LE, or UTF-16BE (according to the database encoding) (verify)

For example(verify)

  • if you store into a numeric column, it will do something like
    • if not well formed as an integer or real, it's stored as TEXT
    • if it's a real number (with digit) and store as REAL if (seems like float64 so if there was more precision in the text that will be lost)
    • if it's an integer, and find the smallest integer type that will store it
    • if it's an integer larger than int64 can store, it will try REAL
    • hex is stored as text


Assume that the schema is not used for conversions going out

AFAICT, what you get out is whatever type that got stored, and it is the logic on insert that is interesting.

...at least, that's what synamically typed languages tend to do with it. Statically typed languages (including SQLite's onw API) may get you to convert it, and/or makes you test for it(verify).



On concurrency

Say the writers: "SQLite is not designed to replace Oracle. It is designed to replace fopen()"


That said, it does about as much as it can with what the filesystem provides, which is pretty great on a single device.

...but keep in mind there are limits - and that filesystems vary. In particular some network filesystems do not do enough.


Concurrency from distinct tasks

Multiple threads

There is usually nothing to be gained from distinct threads accessing the same database, so maybe avoid doing this.

Yet if you insist: SQLite can be compiled to be thread-safe, and usually is. (the reason you can compile without is that removing this safety is slightly faster for cases you know will always be single-threaded)

You can query that compile option from the database at runtime if you want to be sure.

This page points out there is a further distinction between multi-threaded (where threads must not share a connection) and serialized (where that appears to be fine).


Some libraries may have their own decisions - e.g. python3's sqlite3 will complain SQLite objects created in a thread can only be used in that same thread, though that seems to be overzealous.


Multiple processes

Multiple processes can access the same database.

Assume that:

  • multiple can read concurrently
  • writes are not concurrent with other writes
  • writes are not concurrent with reads

It is somewhat up to clients to error out, or wait and/or time out(verify)


Things work a little better with a non-standard method, but it comes with more requirements.


Limitations:

  • locking (and the journaling that relies on it) relies on some filesystem semantics
assume this will not work properly over some network filesystems (e.g. NFS, some SMB, a.k.a. windows network mounts).
  • You should not carry an open connection though a fork


More on concurrent operations

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


See also:


CLI admin

OPTIMIZE, ANALYZE, etc

Errors