On Wednesday, 1 June 2016 at 05:45:49 UTC, Piotrek wrote:
On Tuesday, 31 May 2016 at 22:08:00 UTC, Stefan Koch wrote:
Nice effort. How would you like collaboration with the
Thanks. Correct me if I'm wrong but SQLite-D is a compile time
SQLite3 file reader. If so, I can predict not many common
parts. Maybe the one would be a data deserialization component
however I didn't check how it's done in SQLite-D.
I intend for it to be a complete replacement for SQLite.
Therefore I can see facing many common problems.
Keeping B-Trees roughly balanced.
Providing a nice query interface and so on.
With has similar goals albeit file format compatible to SQLite.
When I was selecting possible file format I was thinking about
SQLite one. I am actually a fan of the SQLite project. However
there are some shortcomings present in current SQlite3 format:
- SQlite3 is not really a one file storage (i.e. journal file)
- it gets fragmented very quickly (check out design goals for
- it's overcomplicated and non deterministic with respect to
real time software
- it has unnecessary overhead because every column is actually
a variant type
Add to this the main goal of replacing SQL with D
This is SQLite-D's goal as well.
In result it turned out it would be great to have an alternate
Well I can see the non-realtime property being a factor for every