Short description

    A database engine for quick and easy integration into any D program. Full compatibility with D types and ranges.

Design Goals (none is accomplished yet)

    - ACID
    - No external dependencies
    - Single file storage
    - Multithread support
    - Suitable for microcontrollers


Example code:

    import draft.database;

    import std.stdio;

    void main(string[] args)
    {
        static struct Test
        {
            int a;
            string s;
        }

        auto db = DataBase("testme.db");
        auto collection = db.collection!Test("collection_name",true);

        collection.put(Test(1,"Hello DB"));


        writeln(db.collection!Test("collection_name"));
    }


More info for interested at:

    Docs:
    https://gitlab.com/PiotrekDlang/DraftLib/blob/master/docs/database/index.md

    Code:
    https://gitlab.com/PiotrekDlang/DraftLib/tree/master/src

The project is at its early stage of development.

Piotrek

On Saturday, 28 May 2016 at 14:08:18 UTC, Piotrek wrote:
> Short description
>
>     A database engine for quick and easy integration into any D program. Full compatibility with D types and ranges.
>
> Design Goals (none is accomplished yet)
>
>     - ACID
>     - No external dependencies
>     - Single file storage
>     - Multithread support
>     - Suitable for microcontrollers
>
>
> Example code:
>
>     import draft.database;
>
>     import std.stdio;
>
>     void main(string[] args)
>     {
>         static struct Test
>         {
>             int a;
>             string s;
>         }
>
>         auto db = DataBase("testme.db");
>         auto collection = db.collection!Test("collection_name",true);
>
>         collection.put(Test(1,"Hello DB"));
>
>
>         writeln(db.collection!Test("collection_name"));
>     }
>
>
> More info for interested at:
>
>     Docs:
>     https://gitlab.com/PiotrekDlang/DraftLib/blob/master/docs/database/index.md
>
>     Code:
>     https://gitlab.com/PiotrekDlang/DraftLib/tree/master/src
>
> The project is at its early stage of development.
>
> Piotrek

This might provide useful information if you're aiming for something like sqlite (hopefully not offtopic):

https://github.com/cznic/ql

It's an embeddable database engine in Go with goals similar to yours and at an advanced stage.

regards,
dmitri.

On Saturday, 28 May 2016 at 14:08:18 UTC, Piotrek wrote:
> Short description
>
>     A database engine for quick and easy integration into any D program. Full compatibility with D types and ranges.
>
> Design Goals (none is accomplished yet)
>
>     - ACID
>     - No external dependencies
>     - Single file storage
>     - Multithread support
>     - Suitable for microcontrollers
>
>
> More info for interested at:
>
>     Docs:
>     https://gitlab.com/PiotrekDlang/DraftLib/blob/master/docs/database/index.md
>
>     Code:
>     https://gitlab.com/PiotrekDlang/DraftLib/tree/master/src
>
> The project is at its early stage of development.
>
> Piotrek

Nice effort. How would you like collaboration with the SQLite-D project.
With has similar goals albeit file format compatible to SQLite.

On Tuesday, 31 May 2016 at 22:08:00 UTC, Stefan Koch wrote:
> Nice effort. How would you like collaboration with the SQLite-D project.

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.

> 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 SQLite4)
- 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 ranges+algorithms. In result it turned out it would be great to have an alternate format.

BTW. Would someone be so kind and post the above paragraph on Reddit under a comment about Sqlite db. I'm not registered there.

Piotrek

On Wednesday, 1 June 2016 at 05:45:49 UTC, Piotrek wrote:
> BTW. Would someone be so kind and post the above paragraph on Reddit under a comment about Sqlite db. I'm not registered there.

I mean this thread of course:

https://www.reddit.com/r/programming/comments/4lwufi/d_embedded_database_v01_released/

Piotrek

On Wednesday, 1 June 2016 at 05:55:43 UTC, Piotrek wrote:
> On Wednesday, 1 June 2016 at 05:45:49 UTC, Piotrek wrote:
>> BTW. Would someone be so kind and post the above paragraph on Reddit under a comment about Sqlite db. I'm not registered there.
>
> I mean this thread of course:
>
> https://www.reddit.com/r/programming/comments/4lwufi/d_embedded_database_v01_released/
>
> Piotrek

I still think that gitlab is bad place for DB. People prefer look sources at git or in Google. So DB should have site or git mirror to be popular.

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 SQLite-D project.
>
> 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 SQLite4)
> - 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 ranges+algorithms.
This is SQLite-D's goal as well.
> In result it turned out it would be great to have an alternate format.
>
> Piotrek

Well I can see the non-realtime property being a factor for every database.

On Tuesday, 31 May 2016 at 20:31:26 UTC, Dmitri wrote:
> This might provide useful information if you're aiming for something like sqlite (hopefully not offtopic):
>
> https://github.com/cznic/ql
>
> It's an embeddable database engine in Go with goals similar to yours and at an advanced stage.

The key difference is that ql is an SQL database and mine is not. I know it may sound scary, but I think an SQL layer is a burden when the D power is at hand (unless you need a DB running on a separate machine than the rest of the application).

Piotrek

On Wednesday, 1 June 2016 at 06:47:36 UTC, Suliman wrote:
> I still think that gitlab is bad place for DB. People prefer look sources at git or in Google. So DB should have site or git mirror to be popular.

I don't think I fully understand what you mean.

This is a D library not a separate product. Also what is the difference between git mirror and Gitlab?

Piotrek

On Wednesday, 1 June 2016 at 09:41:43 UTC, Stefan Koch wrote:
> Providing a nice query interface and so on.

Do you mean any form of DSL (as it's SQL for SQLite)?

> Well I can see the non-realtime property being a factor for every database.

And this is actually disadvantage of those databases ;)

BTW1. Thank to the one who posted my reply on Reddit :)

BTW2. Somebody on the Reddit suggested the LMDB is an equivalent of this DB. However I fear it's not true. To me, LMDB is a key/value storage backed by a memory-mapped file. However my DB will have more features including:

- internal references (no data replication - aka database normalization)
- indexes
- transparent data compression

and more :)

Piotrek