sqlite-lines can be used as a run-time loadable extension. Depending on your machine's operating system, you can download either the .dylib (MacOS) or .so (Linux) shared library files (from either the TODO or building yourself) and dynamically load it in your codebase.

The default build will load all scalar and table functions available and documented under API Reference.

If you want to statically link sqlite-lines utilities into your own SQLite application, or if you want to build sqlite-lines for a different architecture, you'll need to build it yourself.

Building anything will require a gcc compiler and a MacOS/Linux machine (Windows not supported).

git clone [email protected]:asg017/sqlite-lines.git
cd sqlite-lines

make loadable

This will create a dist/html0.dylib (MacOS) or dist/html0.so (Linux)[runtime-loadable extension[(https://www.sqlite.org/loadext.html).

To test, which requires python3:

make test-loadable

make sqlite3
make test-sqlite3

make cli
make test-cli

Requires emscripten.

make sqljs

# will start a local server and open tests/test-sqljs.html for manual testing
make test-sqljs

You have a few options. You only really need the sqlite-lines.h and sqlite-lines.c, so you could copy+paste those files into your own C/C++ application and bundle like that.

Additionally, you can run make dist/lines0.o to create an object file, and use that to link to your application.

If you want to load sqlite-lines functions/tables into a SQLite connection by default, look into the sqlite3_auto_extension() API and the SQLITE_EXTRA_INIT SQLite compile-time option (this project's Makefile has a few examples).

Returns the version string of the version of sqlite-lines the database connection is using. sqlite-lines uses Semantic Versioning.

> select lines_version();
v0.0.0

Returns a string with debugging information for sqlite-lines, including the version of sqlite-line, the commit hash of the main sqlite-lines repo that the build was made on, and the date it was built.

> select lines_debug();
Version: v0.0.0
Date: 2022-05-15T16:57:23Z-0700
Commit: c87a67c6e76
NO FILESYSTEM

The last "NO FILESYSTEM" line is only present in builds that use SQLITE_LINES_DISABLE_FILESYSTEM that removes the lines_read() function.

create table lines(
  line text,
  document blob hidden, -- 1st input parameter: text or blob of document to read
  delimeter char hidden -- 2nd input parameter: option 1-character to split on
);

A table function that reads in the given document (a TEXT or BLOB value) into memory, and generates a single row for every "line" in the document.

The generated rows have two usable columns - the first is line, which is a text value of the split "line" that was found. The second, rowid, is the line number of the line in the document, starting at 1.

The default delimiter is the newline character \n. However, sqlite-lines will also strip away the carriage return character \r if it appears at the end of a line, to support CRLF files. You can specifier a different delimiter as the second parameter to lines(), but it must only be a single character.

Since lines() requires reading the full document into memory, the lines_read table function is prefered whenever possible.

select rowid, line from lines('a
b
c');
/*
rowid|line
1|a
2|b
3|c
*/

create table lines_read(
  line text,
  path text hidden,     -- 1st input parameter: text or blob of document to read
  delimeter char hidden -- 2nd input parameter: option 1-character to split on
);

A table function that reads the file at the given path, and generates a single row for every "line" in that file.

The API and generated rows are the same as the lines() function - except this function will read from the filesystem, by-passing SQLite's 1GB limit.

select * from lines_read("my-file.txt");

select
  line -> '$.id'   as id,
  line -> '$.name' as name
from lines_read("my-file.ndjson");