1/vrischmann/sqlite v0.65
Thin SQLite wrapper
zig-sqlite
This package is a thin wrapper around sqlite's C API.
Status
While the core functionality works right now, the API is still subject to changes.
If you use this library, expect to have to make changes when you update the code.
Zig release support
zig-sqlite
only supports Zig master (as can be found here). The plan is to support releases once Zig 1.0 is released but this can still change.
The Zig self-hosted/stage2 compiler is now the default however currently it can't be used with zig-sqlite
due to bugs.
Eventually zig-sqlite
will only support stage2 but until a point I feel comfortable doing that, the master
branch will stay compatible with stage1 and all work for stage2 will happen in the stage2
branch.
Table of contents
Requirements
Zig master is the only required dependency.
For sqlite, you have options depending on your target:
- On Windows the only supported way at the moment to build
zig-sqlite
is with the bundled sqlite source code file. - On Linux we have two options:
- use the system and development package for sqlite (
libsqlite3-dev
for Debian and derivatives,sqlite3-devel
for Fedora) - use the bundled sqlite source code file.
- use the system and development package for sqlite (
Features
- Preparing, executing statements
- comptime checked bind parameters
- user defined SQL functions
Installation
There are two primary ways to include zig-sqlite
in your project:
- using the zigmod package manager
- using a git submodule
zigmod
Add this to your zig.mod
file:
dependencies:
- src: git https://github.com/vrischmann/zig-sqlite branch-master
Note that if you're building an executable and not a library you should use dev_dependencies
instead.
Next run zigmod fetch
; it should create a deps.zig
file.
Now in your build.zig
you can access the package like this:
const deps = @import("deps.zig");
...
deps.addAllTo(exe);
This is the easiest way to add zig-sqlite
because it uses the bundled source code, avoiding all sorts of linking problems.
Git submodule
If you don't want to use a package manager you can simply add this repository as a git submodule.
Then you need to chose if you want to use the system sqlite library or the bundled source code.
Using the system sqlite library
If you want to use the system sqlite library, add the following to your build.zig
target(s):
exe.linkLibC();
exe.linkSystemLibrary("sqlite3");
exe.addPackage(.{ .name = "sqlite", .path = "third_party/zig-sqlite/sqlite.zig" });
Using the bundled sqlite source code file
If you want to use the bundled sqlite source code file, first you need to add it as a static library in your build.zig
file:
const sqlite = b.addStaticLibrary("sqlite", null);
sqlite.addCSourceFile("third_party/zig-sqlite/c/sqlite3.c", &[_][]const u8{"-std=c99"});
sqlite.linkLibC();
If you need to define custom compile-time options for sqlite, modify the flags (second argument to addCSourceFile
).
Now it's just a matter of linking your build.zig
target(s) to this library instead of the system one:
exe.linkLibrary(sqlite);
exe.addPackagePath("sqlite", "third_party/zig-sqlite/sqlite.zig");
exe.addIncludeDir("third_party/zig-sqlite/c");
If you're building with glibc you must make sure that the version used is at least 2.28.
You can do that in your build.zig
file:
var target = b.standardTargetOptions(.{});
target.setGnuLibCVersion(2, 28, 0);
exe.setTarget(target);
Or with -Dtarget
:
$ zig build -Dtarget=native-linux-gnu.2.28
Usage
Import zig-sqlite
like this:
const sqlite = @import("sqlite");
Initialization
You must create and initialize an instance of sqlite.Db
:
var db = try sqlite.Db.init(.{
.mode = sqlite.Db.Mode{ .File = "/home/vincent/mydata.db" },
.open_flags = .{
.write = true,
.create = true,
},
.threading_mode = .MultiThread,
});
The init
method takes a InitOptions
struct which will be used to configure sqlite.
Only the mode
field is mandatory, the other fields have sane default values.
Preparing a statement
Common use
sqlite works exclusively by using prepared statements. The wrapper type is sqlite.Statement
. Here is how you get one:
const query =
\\SELECT id, name, age, salary FROM employees WHERE age > ? AND age < ?
;
var stmt = try db.prepare(query);
defer stmt.deinit();
The Db.prepare
method takes a comptime
query string.
Diagnostics
If you want failure diagnostics you can use prepareWithDiags
like this:
var diags = sqlite.Diagnostics{};
var stmt = db.prepareWithDiags(query, .{ .diags = &diags }) catch |err| {
std.log.err("unable to prepare statement, got error {}. diagnostics: {s}", .{ err, diags });
return err;
};
defer stmt.deinit();
Executing a statement
For queries which do not return data (INSERT
, UPDATE
) you can use the exec
method:
const query =
\\UPDATE foo SET salary = ? WHERE id = ?
;
var stmt = try db.prepare(query);
defer stmt.deinit();
try stmt.exec(.{
.salary = 20000,
.id = 40,
});
See the section "Bind parameters and resultset rows" for more information on the types mapping rules.
Reuse a statement
You can reuse a statement by resetting it like this:
const query =
\\UPDATE foo SET salary = ? WHERE id = ?
;
var stmt = try db.prepare(query);
defer stmt.deinit();
var id: usize = 0;
while (id < 20) : (id += 1) {
stmt.reset();
try stmt.exec(.{
.salary = 2000,
.id = id,
});
}
Reading data
For queries which return data you have multiple options:
Statement.all
which takes an allocator and can allocate memory.Statement.one
which does not take an allocator and cannot allocate memory (aside from what sqlite allocates itself).Statement.oneAlloc
which takes an allocator and can allocate memory.
Type parameter
All these methods take a type as first parameter.
The type represents a "row", it can be:
- a struct where each field maps to the corresponding column in the resultset (so field 0 must map to column 1 and so on).
- a single type, in that case the resultset must only return one column.
The type can be a pointer but only when using the methods taking an allocator.
Not all types are allowed, see the section "Bind parameters and resultset rows" for more information on the types mapping rules.
Non allocating
Using one
:
const query =
\\SELECT name, age FROM employees WHERE id = ?
;
var stmt = try db.prepare(query);
defer stmt.deinit();
const row = try stmt.one(
struct {
name: [128:0]u8,
age: usize,
},
.{},
.{ .id = 20 },
);
if (row) |row| {
std.log.debug("name: {}, age: {}", .{std.mem.spanZ(&row.name), row.age});
}
Notice that to read text we need to use a 0-terminated array; if the name
column is bigger than 127 bytes the call to one
will fail.
If the length of the data is variable then the sentinel is mandatory: without one there would be no way to know where the data ends in the array.
However if the length is fixed, you can read into a non 0-terminated array, for example:
const query =
\\SELECT id FROM employees WHERE name = ?
;
var stmt = try db.prepare(query);
defer stmt.deinit();
const row = try stmt.one(
[16]u8,
.{},
.{ .name = "Vincent" },
);
if (row) |id| {
std.log.debug("id: {s}", .{std.fmt.fmtSliceHexLower(&id)});
}
If the column data doesn't have the correct length a error.ArraySizeMismatch
will be returned.
The convenience function sqlite.Db.one
works exactly the same way:
const query =
\\SELECT age FROM employees WHERE id = ?
;
const row = try db.one(usize, query, .{}, .{ .id = 20 });
if (row) |age| {
std.log.debug("age: {}", .{age});
}
Allocating
Using all
:
const query =
\\SELECT name FROM employees WHERE age > ? AND age < ?
;
var stmt = try db.prepare(query);
defer stmt.deinit();
const names = try stmt.all([]const u8, allocator, .{}, .{
.age1 = 20,
.age2 = 40,
});
for (names) |name| {
std.log.debug("name: {s}", .{ name });
}
Using oneAlloc
:
const query =
\\SELECT name FROM employees WHERE id = ?
;
var stmt = try db.prepare(query);
defer stmt.deinit();
const row = try stmt.oneAlloc([]const u8, allocator, .{}, .{
.id = 200,
});
if (row) |name| {
std.log.debug("name: {}", .{name});
}
Iterating
Another way to get the data returned by a query is to use the sqlite.Iterator
type.
You can only get one by calling the iterator
method on a statement.
The iterator
method takes a type which is the same as with all
, one
or oneAlloc
: every row retrieved by calling next
or nextAlloc
will have this type.
Iterating is done by calling the next
or nextAlloc
method on an iterator. Just like before, next
cannot allocate memory while nextAlloc
can allocate memory.
next
or nextAlloc
will either return an optional value or an error; you should keep iterating until null
is returned.
Non allocating
var stmt = try db.prepare("SELECT age FROM user WHERE age < ?");
defer stmt.deinit();
var iter = try stmt.iterator(usize, .{
.age = 20,
});
while (try iter.next(.{})) |age| {
std.debug.print("age: {}\n", .{age});
}
Allocating
var stmt = try db.prepare("SELECT name FROM user WHERE age < ?");
defer stmt.deinit();
var iter = try stmt.iterator([]const u8, .{
.age = 20,
});
while (true) {
var arena = std.heap.ArenaAllocator.init(allocator);
defer arena.deinit();
const name = (try iter.nextAlloc(arena.allocator(), .{})) orelse break;
std.debug.print("name: {}\n", .{name});
}
Bind parameters and resultset rows
Since sqlite doesn't have many types only a small number of Zig types are allowed in binding parameters and in resultset mapping types.
Here are the rules for bind parameters:
- any Zig
Int
orComptimeInt
is treated as aINTEGER
. - any Zig
Float
orComptimeFloat
is treated as aREAL
. []const u8
,[]u8
is treated as aTEXT
.- the custom
sqlite.Blob
type is treated as aBLOB
. - the custom
sqlite.Text
type is treated as aTEXT
. - the
null
value is treated as aNULL
. - non-null optionals are treated like a regular value, null optionals are treated as a
NULL
.
Here are the rules for resultset rows:
INTEGER
can be read into any ZigInt
provided the data fits.REAL
can be read into any ZigFloat
provided the data fits.TEXT
can be read into a[]const u8
or[]u8
.TEXT
can be read into any array ofu8
with a sentinel provided the data fits.BLOB
follows the same rules asTEXT
.NULL
can be read into any optional.
Note that arrays must have a sentinel because we need a way to communicate where the data actually stops in the array, so for example use [200:0]u8
for a TEXT
field.
Custom type binding and reading
Sometimes the default field binding or reading logic is not what you want, for example if you want to store an enum using its tag name instead of its integer value or if you want to store a byte slice as an hex string.
To accomplish this you must first define a wrapper struct for your type. For example if your type is a [4]u8
and you want to treat it as an integer:
pub const MyArray = struct {
data: [4]u8,
pub const BaseType = u32;
pub fn bindField(self: MyArray, _: std.mem.Allocator) !BaseType {
return std.mem.readIntNative(BaseType, &self.data);
}
pub fn readField(_: std.mem.Allocator, value: BaseType) !MyArray {
var arr: MyArray = undefined;
std.mem.writeIntNative(BaseType, &arr.data, value);
return arr;
}
};
Now when you bind a value of type MyArray
the value returned by bindField
will be used for binding instead.
Same for reading, when you select into a MyArray
row or field the value returned by readField
will be used instead.
NOTE: when you do allocate in bindField
or readField
make sure to pass a std.heap.ArenaAllocator
-based allocator.
The binding or reading code does not keep tracking of allocations made in custom types so it can't free the allocated data itself; it's therefore required to use an arena to prevent memory leaks.
Note about complex allocations
Depending on your queries and types there can be a lot of allocations required. Take the following example:
const User = struct {
id: usize,
first_name: []const u8,
last_name: []const u8,
data: []const u8,
};
fn fetchUsers(allocator: std.mem.Allocator, db: *sqlite.Db) ![]User {
var stmt = try db.prepare("SELECT id FROM user WHERE id > $id");
defer stmt.deinit();
return stmt.all(User, allocator, .{}, .{ .id = 20 });
}
This will do multiple allocations:
- one for each id field in the
User
type - one for the resulting slice
To facilitate memory handling, consider using an arena allocator like this:
var arena = std.heap.ArenaAllocator.init(allocator);
defer arena.deinit();
const users = try fetchUsers(arena.allocator(), db);
_ = users;
This is especially recommended if you use custom types that allocate memory since, as noted above, it's necessary to prevent memory leaks.
Comptime checks
Prepared statements contain comptime metadata which is used to validate every call to exec
, one
and all
at compile time.
Check the number of bind parameters.
The first check makes sure you provide the same number of bind parameters as there are bind markers in the query string.
Take the following code:
var stmt = try db.prepare("SELECT id FROM user WHERE age > ? AND age < ? AND weight > ?");
defer stmt.deinit();
const rows = try stmt.all(usize, .{}, .{
.age_1 = 10,
.age_2 = 20,
});
_ = rows;
It fails with this compilation error:
/home/vincent/dev/perso/libs/zig-sqlite/sqlite.zig:738:17: error: number of bind markers not equal to number of fields
@compileError("number of bind markers not equal to number of fields");
^
/home/vincent/dev/perso/libs/zig-sqlite/sqlite.zig:817:22: note: called from here
self.bind(values);
^
/home/vincent/dev/perso/libs/zig-sqlite/sqlite.zig:905:41: note: called from here
var iter = try self.iterator(Type, values);
^
./src/main.zig:19:30: note: called from here
const rows = try stmt.all(usize, allocator, .{}, .{
^
./src/main.zig:5:29: note: called from here
pub fn main() anyerror!void {
Assign types to bind markers and check them.
The second (and more interesting) check makes sure you provide appropriately typed values as bind parameters.
This check is not automatic since with a standard SQL query we have no way to know the types of the bind parameters, to use it you must provide theses types in the SQL query with a custom syntax.
For example, take the same code as above but now we also bind the last parameter:
var stmt = try db.prepare("SELECT id FROM user WHERE age > ? AND age < ? AND weight > ?");
defer stmt.deinit();
const rows = try stmt.all(usize, .{ .allocator = allocator }, .{
.age_1 = 10,
.age_2 = 20,
.weight = false,
});
_ = rows;
This compiles correctly even if the weight
field in our user
table is of the type INTEGER
.
We can make sure the bind parameters have the right type if we rewrite the query like this:
var stmt = try db.prepare("SELECT id FROM user WHERE age > ? AND age < ? AND weight > ?{usize}");
defer stmt.deinit();
const rows = try stmt.all(usize, .{ .allocator = allocator }, .{
.age_1 = 10,
.age_2 = 20,
.weight = false,
});
_ = rows;
Now this fails to compile:
/home/vincent/dev/perso/libs/zig-sqlite/sqlite.zig:745:25: error: value type bool is not the bind marker type usize
@compileError("value type " ++ @typeName(struct_field.field_type) ++ " is not the bind marker type " ++ @typeName(typ));
^
/home/vincent/dev/perso/libs/zig-sqlite/sqlite.zig:817:22: note: called from here
self.bind(values);
^
/home/vincent/dev/perso/libs/zig-sqlite/sqlite.zig:905:41: note: called from here
var iter = try self.iterator(Type, values);
^
./src/main.zig:19:30: note: called from here
const rows = try stmt.all(usize, allocator, .{}, .{
^
./src/main.zig:5:29: note: called from here
pub fn main() anyerror!void {
The syntax is straightforward: a bind marker ?
followed by {
, a Zig type name and finally }
.
There are a limited number of types allowed currently:
- all integer types.
- all arbitrary bit-width integer types.
- all float types.
- bool.
- strings with
[]const u8
or[]u8
. - strings with
sqlite.Text
. - blobs with
sqlite.Blob
.
It's probably possible to support arbitrary types if they can be marshaled to a sqlite type. This is something to investigate.
NOTE: this is done at compile time and is quite CPU intensive, therefore it's possible you'll have to play with @setEvalBranchQuota to make it compile.
To finish our example, passing the proper type allows it compile:
var stmt = try db.prepare("SELECT id FROM user WHERE age > ? AND age < ? AND weight > ?{usize}");
defer stmt.deinit();
const rows = try stmt.all(usize, .{}, .{
.age_1 = 10,
.age_2 = 20,
.weight = @as(usize, 200),
});
_ = rows;
User defined SQL functions
sqlite supports user-defined SQL functions which come in two types:
- scalar functions
- aggregate functions
In both cases the arguments are sqlite3_values and are converted to Zig values using the following rules:
TEXT
values can be eithersqlite.Text
or[]const u8
BLOB
values can be eithersqlite.Blob
or[]const u8
INTEGER
values can be any Zig integerREAL
values can be any Zig float
Scalar functions
You can define a scalar function using db.createScalarFunction
:
try db.createScalarFunction(
"blake3",
struct {
fn run(input: []const u8) [std.crypto.hash.Blake3.digest_length]u8 {
var hash: [std.crypto.hash.Blake3.digest_length]u8 = undefined;
std.crypto.hash.Blake3.hash(input, &hash, .{});
return hash;
}
}.run,
.{},
);
const hash = try db.one([std.crypto.hash.Blake3.digest_length]u8, "SELECT blake3('hello')", .{}, .{});
Each input arguments in the function call in the statement is passed on to the registered run
function.
Aggregate functions
You can define a scalar function using db.createAggregateFunction
:
const MyContext = struct {
sum: u32,
};
var my_ctx = MyContext{ .sum = 0 };
try db.createAggregateFunction(
"mySum",
&my_ctx,
struct {
fn step(ctx: *MyContext, input: u32) void {
ctx.sum += input;
}
}.step,
struct {
fn finalize(ctx: *MyContext) u32 {
return ctx.sum;
}
}.finalize,
.{},
);
const result = try db.one(usize, "SELECT mySum(nb) FROM foobar", .{}, .{});
Each input arguments in the function call in the statement is passed on to the registered step
function.
The finalize
function is called once at the end.
The context (2nd argument of createAggregateFunction
) can be whatever you want; both step
and finalize
function must
have their first argument of the same type as the context.
Package Contents
- c/sqlite3.h
- c/sqlite3.c
- gyro.zzz
- .gitattributes
- zigmod.lock
- LICENSE
- .github/workflows/main.yml
- .dockerignore
- query.zig
- build.zig
- errors.zig
- .builds/alpine-edge-amd64.yml
- .builds/freebsd-latest-amd64.yml
- .builds/debian-stable-aarch64.yml
- fuzz/LICENSE.apache2
- fuzz/main.zig
- fuzz/sql.dict
- fuzz/README.md
- fuzz/inputs/empty_string_crash
- fuzz/inputs/schema.sql
- c.zig
- README.md
- zig.mod
- sqlite.zig
- .gitignore
History
Published On | Tree @ Commit | Size | |
---|---|---|---|
v0.157 | Sun, 08 Dec 2024 14:01:32 UTC | Tree | 10.331 MB |
v0.156 | Sun, 08 Dec 2024 13:58:56 UTC | Tree | 10.331 MB |
v0.155 | Sun, 08 Dec 2024 13:54:04 UTC | Tree | 10.334 MB |
v0.154 | Sun, 08 Dec 2024 13:49:53 UTC | Tree | 10.335 MB |
v0.153 | Sun, 08 Dec 2024 11:45:18 UTC | Tree | 10.336 MB |
v0.152 | Sun, 08 Dec 2024 11:35:44 UTC | Tree | 10.335 MB |
v0.151 | Sun, 08 Dec 2024 11:35:06 UTC | Tree | 10.358 MB |
v0.150 | Sun, 08 Dec 2024 11:17:15 UTC | Tree | 10.358 MB |
v0.149 | Sat, 07 Dec 2024 21:41:04 UTC | Tree | 10.358 MB |
v0.148 | Sat, 30 Nov 2024 21:00:34 UTC | Tree | 10.358 MB |
v0.147 | Sat, 30 Nov 2024 21:00:06 UTC | Tree | 10.358 MB |
v0.146 | Sun, 17 Nov 2024 00:26:16 UTC | Tree | 10.235 MB |
v0.145 | Wed, 30 Oct 2024 22:40:42 UTC | Tree | 10.234 MB |
v0.144 | Sat, 07 Sep 2024 19:37:40 UTC | Tree | 10.233 MB |
v0.143 | Sat, 31 Aug 2024 18:04:00 UTC | Tree | 10.054 MB |
v0.142 | Thu, 29 Aug 2024 15:49:10 UTC | Tree | 10.054 MB |
v0.141 | Mon, 29 Jul 2024 08:53:10 UTC | Tree | 10.054 MB |
v0.140 | Sun, 14 Jul 2024 20:51:25 UTC | Tree | 10.054 MB |
v0.139 | Sun, 23 Jun 2024 16:56:29 UTC | Tree | 10.054 MB |
v0.138 | Sun, 02 Jun 2024 16:02:50 UTC | Tree | 10.053 MB |
v0.137 | Mon, 13 May 2024 08:11:00 UTC | Tree | 10.053 MB |
v0.136 | Sun, 28 Apr 2024 17:58:37 UTC | Tree | 10.053 MB |
v0.135 | Sat, 20 Apr 2024 13:03:59 UTC | Tree | 10.053 MB |
v0.134 | Tue, 16 Apr 2024 20:42:26 UTC | Tree | 10.053 MB |
v0.133 | Tue, 16 Apr 2024 20:07:17 UTC | Tree | 10.054 MB |
v0.132 | Sun, 14 Apr 2024 18:50:49 UTC | Tree | 10.054 MB |
v0.131 | Sun, 14 Apr 2024 16:27:30 UTC | Tree | 10.055 MB |
v0.130 | Sun, 14 Apr 2024 16:06:07 UTC | Tree | 10.053 MB |
v0.129 | Wed, 07 Feb 2024 21:47:36 UTC | Tree | 10.053 MB |
v0.128 | Sun, 28 Jan 2024 12:58:04 UTC | Tree | 10.053 MB |
v0.127 | Sat, 23 Dec 2023 20:17:44 UTC | Tree | 10.052 MB |
v0.126 | Sat, 23 Dec 2023 20:16:47 UTC | Tree | 10.052 MB |
v0.125 | Tue, 19 Dec 2023 12:16:33 UTC | Tree | 10.052 MB |
v0.124 | Mon, 18 Dec 2023 18:01:31 UTC | Tree | 10.052 MB |
v0.123 | Wed, 06 Dec 2023 21:45:05 UTC | Tree | 10.051 MB |
v0.122 | Sat, 02 Dec 2023 21:03:26 UTC | Tree | 10.051 MB |
v0.121 | Wed, 29 Nov 2023 21:14:53 UTC | Tree | 10.051 MB |
v0.120 | Sun, 26 Nov 2023 16:22:52 UTC | Tree | 10.051 MB |
v0.119 | Wed, 22 Nov 2023 17:23:39 UTC | Tree | 10.028 MB |
v0.118 | Tue, 21 Nov 2023 09:49:15 UTC | Tree | 9.961 MB |
v0.117 | Fri, 03 Nov 2023 23:11:54 UTC | Tree | 9.960 MB |
v0.116 | Mon, 30 Oct 2023 09:12:55 UTC | Tree | 9.960 MB |
v0.115 | Wed, 20 Sep 2023 22:26:27 UTC | Tree | 9.960 MB |
v0.114 | Wed, 20 Sep 2023 14:13:55 UTC | Tree | 9.960 MB |
v0.113 | Wed, 20 Sep 2023 14:05:09 UTC | Tree | 9.960 MB |
v0.112 | Mon, 18 Sep 2023 20:11:04 UTC | Tree | 9.960 MB |
v0.111 | Mon, 18 Sep 2023 20:06:27 UTC | Tree | 9.960 MB |
v0.110 | Sun, 17 Sep 2023 21:44:29 UTC | Tree | 9.959 MB |
v0.109 | Sun, 17 Sep 2023 21:40:15 UTC | Tree | 9.959 MB |
v0.108 | Fri, 15 Sep 2023 15:57:19 UTC | Tree | 9.961 MB |
v0.107 | Fri, 01 Sep 2023 21:28:46 UTC | Tree | 9.961 MB |
v0.106 | Thu, 17 Aug 2023 06:49:16 UTC | Tree | 9.661 MB |
v0.105 | Sat, 05 Aug 2023 16:04:44 UTC | Tree | 9.661 MB |
v0.104 | Mon, 31 Jul 2023 19:55:06 UTC | Tree | 9.661 MB |
v0.103 | Mon, 10 Jul 2023 11:39:51 UTC | Tree | 9.660 MB |
v0.102 | Fri, 07 Jul 2023 19:48:44 UTC | Tree | 9.660 MB |
v0.101 | Thu, 06 Jul 2023 11:56:01 UTC | Tree | 9.660 MB |
v0.100 | Sun, 02 Jul 2023 13:29:52 UTC | Tree | 9.660 MB |
v0.99 | Thu, 22 Jun 2023 20:40:43 UTC | Tree | 9.661 MB |
v0.98 | Tue, 20 Jun 2023 22:53:50 UTC | Tree | 9.661 MB |
v0.97 | Sun, 18 Jun 2023 20:38:27 UTC | Tree | 9.660 MB |
v0.96 | Sun, 18 Jun 2023 20:36:20 UTC | Tree | 9.660 MB |
v0.95 | Sun, 18 Jun 2023 20:35:43 UTC | Tree | 9.660 MB |
v0.94 | Sun, 04 Jun 2023 14:17:17 UTC | Tree | 9.660 MB |
v0.93 | Wed, 31 May 2023 21:07:04 UTC | Tree | 9.660 MB |
v0.92 | Wed, 31 May 2023 21:06:14 UTC | Tree | 9.660 MB |
v0.91 | Wed, 31 May 2023 20:57:51 UTC | Tree | 9.660 MB |
v0.90 | Wed, 31 May 2023 20:55:58 UTC | Tree | 9.660 MB |
v0.89 | Wed, 31 May 2023 20:53:25 UTC | Tree | 9.660 MB |
v0.88 | Wed, 31 May 2023 20:45:25 UTC | Tree | 9.660 MB |
v0.87 | Wed, 31 May 2023 20:40:06 UTC | Tree | 9.659 MB |
v0.86 | Mon, 29 May 2023 06:46:28 UTC | Tree | 9.659 MB |
v0.85 | Wed, 17 May 2023 19:32:50 UTC | Tree | 9.659 MB |
v0.84 | Wed, 17 May 2023 19:30:03 UTC | Tree | 9.659 MB |
v0.83 | Sat, 18 Mar 2023 20:23:24 UTC | Tree | 9.659 MB |
v0.82 | Sat, 11 Mar 2023 17:36:38 UTC | Tree | 9.659 MB |
v0.81 | Tue, 07 Mar 2023 22:13:26 UTC | Tree | 9.659 MB |
v0.80 | Mon, 26 Dec 2022 09:47:35 UTC | Tree | 9.658 MB |
v0.79 | Mon, 19 Dec 2022 12:00:10 UTC | Tree | 9.658 MB |
v0.78 | Sun, 11 Dec 2022 15:31:19 UTC | Tree | 9.658 MB |
v0.77 | Fri, 09 Dec 2022 12:47:47 UTC | Tree | 9.658 MB |
v0.76 | Fri, 09 Dec 2022 12:46:15 UTC | Tree | 9.658 MB |
v0.75 | Tue, 06 Dec 2022 21:57:52 UTC | Tree | 9.658 MB |
v0.74 | Thu, 01 Dec 2022 21:55:55 UTC | Tree | 9.658 MB |
v0.73 | Sun, 06 Nov 2022 13:32:57 UTC | Tree | 9.658 MB |
v0.72 | Tue, 01 Nov 2022 01:26:18 UTC | Tree | 9.658 MB |
v0.71 | Tue, 01 Nov 2022 01:07:04 UTC | Tree | 9.658 MB |
v0.70 | Wed, 26 Oct 2022 20:14:52 UTC | Tree | 9.658 MB |
v0.69 | Thu, 29 Sep 2022 08:09:25 UTC | Tree | 9.658 MB |
v0.68 | Sun, 18 Sep 2022 19:10:16 UTC | Tree | 9.658 MB |
v0.67 | Sun, 18 Sep 2022 18:11:40 UTC | Tree | 9.658 MB |
v0.66 | Sun, 18 Sep 2022 00:30:23 UTC | Tree | 9.613 MB |
v0.65 | Sat, 17 Sep 2022 23:08:16 UTC | Tree | 8.957 MB |
v0.64 | Sat, 17 Sep 2022 21:18:38 UTC | Tree | 8.957 MB |
v0.63 | Sat, 17 Sep 2022 21:06:54 UTC | Tree | 8.957 MB |
v0.62 | Sat, 17 Sep 2022 15:44:05 UTC | Tree | 8.955 MB |
v0.61 | Sat, 17 Sep 2022 15:43:21 UTC | Tree | 8.955 MB |
v0.60 | Tue, 13 Sep 2022 20:55:56 UTC | Tree | 8.955 MB |
v0.59 | Sun, 11 Sep 2022 15:12:35 UTC | Tree | 8.955 MB |
v0.58 | Sat, 03 Sep 2022 20:05:40 UTC | Tree | 8.955 MB |
v0.57 | Sat, 03 Sep 2022 19:53:17 UTC | Tree | 8.873 MB |
v0.56 | Wed, 31 Aug 2022 12:36:04 UTC | Tree | 8.873 MB |
v0.55 | Mon, 29 Aug 2022 21:08:07 UTC | Tree | 8.872 MB |
v0.54 | Mon, 29 Aug 2022 07:52:00 UTC | Tree | 8.872 MB |
v0.53 | Sun, 21 Aug 2022 12:27:17 UTC | Tree | 8.872 MB |
v0.52 | Sun, 21 Aug 2022 12:19:38 UTC | Tree | 8.871 MB |
v0.51 | Sun, 21 Aug 2022 12:12:25 UTC | Tree | 8.871 MB |
v0.50 | Sun, 21 Aug 2022 10:15:24 UTC | Tree | 8.870 MB |
v0.49 | Sat, 20 Aug 2022 15:47:47 UTC | Tree | 8.870 MB |
v0.48 | Wed, 17 Aug 2022 07:20:53 UTC | Tree | 8.869 MB |
v0.47 | Mon, 15 Aug 2022 13:47:23 UTC | Tree | 8.869 MB |
v0.46 | Sat, 13 Aug 2022 22:48:43 UTC | Tree | 8.869 MB |
v0.45 | Fri, 05 Aug 2022 23:46:38 UTC | Tree | 8.869 MB |
v0.44 | Fri, 05 Aug 2022 21:07:47 UTC | Tree | 8.869 MB |
v0.43 | Fri, 05 Aug 2022 19:17:16 UTC | Tree | 8.869 MB |
v0.42 | Thu, 04 Aug 2022 10:46:20 UTC | Tree | 8.869 MB |
v0.41 | Thu, 04 Aug 2022 07:26:21 UTC | Tree | 8.868 MB |
v0.40 | Tue, 02 Aug 2022 21:36:53 UTC | Tree | 8.868 MB |
v0.39 | Tue, 02 Aug 2022 16:30:28 UTC | Tree | 8.868 MB |
v0.38 | Tue, 02 Aug 2022 16:30:10 UTC | Tree | 8.868 MB |
v0.37 | Tue, 02 Aug 2022 16:18:54 UTC | Tree | 8.868 MB |
v0.36 | Tue, 26 Jul 2022 18:40:43 UTC | Tree | 8.868 MB |
v0.35 | Sat, 23 Jul 2022 08:27:16 UTC | Tree | 8.868 MB |
v0.34 | Thu, 14 Jul 2022 15:04:28 UTC | Tree | 8.868 MB |
v0.33 | Sun, 26 Jun 2022 16:05:21 UTC | Tree | 8.864 MB |
v0.32 | Mon, 23 May 2022 22:49:34 UTC | Tree | 8.864 MB |
v0.31 | Tue, 17 May 2022 18:46:33 UTC | Tree | 8.864 MB |
v0.30 | Sun, 15 May 2022 01:02:44 UTC | Tree | 8.865 MB |
v0.29 | Sat, 14 May 2022 19:25:55 UTC | Tree | 8.865 MB |
v0.28 | Mon, 02 May 2022 22:53:56 UTC | Tree | 8.863 MB |
v0.27 | Mon, 02 May 2022 18:16:08 UTC | Tree | 8.862 MB |
v0.26 | Mon, 02 May 2022 16:14:08 UTC | Tree | 8.861 MB |
v0.25 | Fri, 29 Apr 2022 19:08:53 UTC | Tree | 8.861 MB |
v0.24 | Sun, 24 Apr 2022 09:27:35 UTC | Tree | 8.861 MB |
v0.23 | Sun, 24 Apr 2022 09:22:46 UTC | Tree | 8.862 MB |
v0.22 | Sat, 23 Apr 2022 16:53:36 UTC | Tree | 8.860 MB |
v0.21 | Sat, 23 Apr 2022 13:23:25 UTC | Tree | 8.855 MB |
v0.20 | Sat, 23 Apr 2022 13:05:57 UTC | Tree | 8.855 MB |
v0.19 | Thu, 21 Apr 2022 21:47:46 UTC | Tree | 8.853 MB |
v0.18 | Thu, 21 Apr 2022 21:00:46 UTC | Tree | 8.851 MB |
v0.17 | Thu, 21 Apr 2022 20:42:35 UTC | Tree | 8.850 MB |
v0.16 | Thu, 21 Apr 2022 20:19:41 UTC | Tree | 8.849 MB |
v0.15 | Mon, 18 Apr 2022 12:11:25 UTC | Tree | 8.849 MB |
v0.14 | Sat, 16 Apr 2022 23:53:29 UTC | Tree | 8.849 MB |
v0.13 | Sat, 16 Apr 2022 23:52:05 UTC | Tree | 8.849 MB |
v0.12 | Sat, 16 Apr 2022 23:50:51 UTC | Tree | 8.849 MB |
v0.11 | Sat, 16 Apr 2022 23:45:11 UTC | Tree | 8.848 MB |
v0.10 | Sat, 16 Apr 2022 23:21:11 UTC | Tree | 8.847 MB |
v0.9 | Sat, 16 Apr 2022 19:51:33 UTC | Tree | 8.841 MB |
v0.8 | Sat, 16 Apr 2022 14:03:30 UTC | Tree | 8.840 MB |
v0.7 | Sun, 03 Apr 2022 01:15:41 UTC | Tree | 8.840 MB |
v0.6 | Fri, 01 Apr 2022 23:32:48 UTC | Tree | 8.828 MB |
v0.5 | Fri, 01 Apr 2022 20:54:52 UTC | Tree | 8.828 MB |
v0.4 | Tue, 22 Mar 2022 14:28:37 UTC | Tree | 8.828 MB |
v0.3 | Sun, 27 Feb 2022 14:24:25 UTC | Tree | 8.828 MB |
v0.2 | Sat, 05 Feb 2022 00:53:14 UTC | Tree | 8.745 MB |
v0.1 | Sat, 05 Feb 2022 00:16:02 UTC | Tree | 8.744 MB |