www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D Embedded Database v0.1 Released

reply Piotrek <piotrek unknownuniverse.net> writes:
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
May 28 2016
next sibling parent reply Dmitri <deemok gmail.com> writes:
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.
May 31 2016
parent Piotrek <piotrek unknownuniverse.net> writes:
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
Jun 01 2016
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
May 31 2016
parent reply Piotrek <piotrek unknownuniverse.net> writes:
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
May 31 2016
next sibling parent reply Piotrek <piotrek unknownuniverse.net> writes:
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
May 31 2016
parent reply Suliman <evermind live.ru> writes:
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.
May 31 2016
parent Piotrek <piotrek unknownuniverse.net> writes:
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
Jun 01 2016
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jun 01 2016
parent reply Piotrek <piotrek unknownuniverse.net> writes:
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
Jun 01 2016
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 1 June 2016 at 16:03:09 UTC, Piotrek wrote:
 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)?
I hope to get by without a DSL. And instead to something nice with UFCS.
Jun 01 2016