SQLite Export in Worgle
In addition to tangling org code, Worgle is capable of exporting lots of metadata to the SQLite format. This metadata can be used to create more dynamic structures for navigating program structure. SQLite metadata, for example is used by the loom to dynamically split up sections into pages and produce a table of contents (via worgmap).
Database export can be done in the following way:
worgle -n -p 0 -d a.db foo.orgWhere: "-n" disables tangling, "-p 0" sets the program id used in the database to be 0, "-d a.db" writes the database output to "a.db" and "foo.org" is the name of the file.
The follow tables in the sqlite database are created:
The file files table keeps track of all tangled files
a particular literate program program produces. The
top value points to the top-level codeblock;
next-file will point to the next file in the file-list,
if there is one. Otherwise, this value is set to the
id value.
CREATE TABLE files(
program INTEGER,
id INTEGER,
filename TEXT,
top INTEGER,
next_file INTEGER
);headers lists all the org headers. The section is
a generated string that displays the section number
in a "1.2.3" format.
The top_level is an integer value for the top-level
section (in the example above, it would be 1), and
the level value shows the number of nest sections deep
the current section is in (in this case, 3).
name stores the title of the header.
filename and linum store the file name and line number
where the header is located is the original org file.
next is a value that points to the next resource in
the org file. Typically, this is a content block.
CREATE TABLE headers(
program INTEGER,
id INTEGER,
section TEXT,
level INTEGER,
top_level INTEGER,
name TEXT,
filename TEXT,
linum INTEGER,
next INTEGER
);The blkref table stores references to code blocks, and
their relative position in the org document.
segoff stores the starting segment position relative
to the block. Subtracting the segoff value from the
next subblock (with id next) will obtain the number
of segments in the current subblock. I do not recall
what makes a segment a "segment", but I believe it has
to do with the way a block strings together strings
and embedded name code blocks together.
The pos value is a relative position id in the block.
In Org, if a named block is created that already
exists, it is appended to the end of that code block.
The section value is the numerical section that the
block is located in using a 1.2.3 format
(this value automatically created).
The prev_lastseg value is the id of the last segment
of the previous block, and it is negative if it doesn't
exist. Peaking at the next id of this segment gets the
first segment of the subblock.
CREATE TABLE blkref(
program INTEGER,
id INTEGER,
ref INTEGER,
pos INTEGER,
segoff INTEGER,
prev_lastseg INTEGER,
section TEXT,
filename TEXT,
linum INTEGER,
next INTEGER
);content.
CREATE TABLE content(
program INTEGER,
id INTEGER,
section TEXT,
filename TEXT,
linum INTEGER,
content TEXT,
next INTEGER
);pglist is a view that only shows the top-level headers.
Anything that gets parsed as a unit of data has a
reference that is placed in the resources table. Each
entry has a id value that is unique relative to the
program id value. The type value determines which
table the data is stored in.
reslist is a table view that uses human readable names
types instead of integers from the resources table.
CREATE TABLE resources(
program INTEGER,
id INTEGER,
type INTEGER
);blocks.
CREATE TABLE blocks(program INTEGER,
id INTEGER,
head_segment INTEGER,
name TEXT,
nblocks INTEGER,
nsegs INTEGER
);orglist is another view. This only selects org
components and not code componens: header, content,
block reference.
CREATE TABLE segments(
program INTEGER,
id INTEGER,
type INTEGER,
str TEXT,
linum INTEGER,
filename TEXT,
next_segment INTEGER
);