www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Ddb needs a maintainer

reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Ddb is a relational database client for D [1]. Currently it only 
supports PostgreSQL but is not limited to it. It could be extended to 
support other backends.

Built-in postgres client is a native implementation, that is it does not 
depend on libpq. Instead it communicates directly with the server 
avoiding text serialization and parsing overhead (PostgreSQL protocol is 
stable and well documented).

I don't use it and I don't work on it anymore. Simply because I'm busy 
with other things and that things don't involve any RDBMS support.

It has some user base, few contributors and 22 forks on github. 
Unfortunately, I could not handle pull requests and issues in a 
reasonable time and that's why I'm posting this here. I hope someone 
could take over this project and improve it.

If you are interested, please either respond here or email me.

[1] https://github.com/pszturmaj/ddb
Feb 12 2016
next sibling parent reply Eugene Wissner <belka caraus.de> writes:
On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj 
wrote:

 Ddb is a relational database client for D [1]. Currently it 
 only supports PostgreSQL but is not limited to it. It could be 
 extended to support other backends.

 Built-in postgres client is a native implementation, that is it 
 does not depend on libpq. Instead it communicates directly with 
 the server avoiding text serialization and parsing overhead 
 (PostgreSQL protocol is stable and well documented).

 I don't use it and I don't work on it anymore. Simply because 
 I'm busy with other things and that things don't involve any 
 RDBMS support.

 It has some user base, few contributors and 22 forks on github. 
 Unfortunately, I could not handle pull requests and issues in a 
 reasonable time and that's why I'm posting this here. I hope 
 someone could take over this project and improve it.

 If you are interested, please either respond here or email me.

 [1] https://github.com/pszturmaj/ddb


Hey. I'm interested. I'm a web developer and PostgreSQL is my 
database of choice. I also like the idea of a native 
implementation.
The only problem is that I'm currently a beginner in D 
programming (but not a beginner in PostgreSQL).
But since I'll need some kind of D <-> PostgreSQL bindings for my 
new project, I would be glad if I could help.
Feb 13 2016
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 13.02.2016 um 11:03 schrieb Eugene Wissner:

 On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj wrote:

 Ddb is a relational database client for D [1]. Currently it only
 supports PostgreSQL but is not limited to it. It could be extended to
 support other backends.

 Built-in postgres client is a native implementation, that is it does
 not depend on libpq. Instead it communicates directly with the server
 avoiding text serialization and parsing overhead (PostgreSQL protocol
 is stable and well documented).

 I don't use it and I don't work on it anymore. Simply because I'm busy
 with other things and that things don't involve any RDBMS support.

 It has some user base, few contributors and 22 forks on github.
 Unfortunately, I could not handle pull requests and issues in a
 reasonable time and that's why I'm posting this here. I hope someone
 could take over this project and improve it.

 If you are interested, please either respond here or email me.

 [1] https://github.com/pszturmaj/ddb


 Hey. I'm interested. I'm a web developer and PostgreSQL is my database
 of choice. I also like the idea of a native implementation.
 The only problem is that I'm currently a beginner in D programming (but
 not a beginner in PostgreSQL).
 But since I'll need some kind of D <-> PostgreSQL bindings for my new
 project, I would be glad if I could help.


BTW, I'd recommend to start a new organization on GitHub for this, which 
makes it much easier to manage ownership changes later on, if necessary. 
It also gives the main repository a more official appearance.
Feb 13 2016
parent reply Eugene Wissner <belka caraus.de> writes:
On Saturday, 13 February 2016 at 12:57:50 UTC, Sönke Ludwig wrote:

 Am 13.02.2016 um 11:03 schrieb Eugene Wissner:

 On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj 
 wrote:

 Ddb is a relational database client for D [1]. Currently it 
 only
 supports PostgreSQL but is not limited to it. It could be 
 extended to
 support other backends.

 Built-in postgres client is a native implementation, that is 
 it does
 not depend on libpq. Instead it communicates directly with 
 the server
 avoiding text serialization and parsing overhead (PostgreSQL 
 protocol
 is stable and well documented).

 I don't use it and I don't work on it anymore. Simply because 
 I'm busy
 with other things and that things don't involve any RDBMS 
 support.

 It has some user base, few contributors and 22 forks on 
 github.
 Unfortunately, I could not handle pull requests and issues in 
 a
 reasonable time and that's why I'm posting this here. I hope 
 someone
 could take over this project and improve it.

 If you are interested, please either respond here or email me.

 [1] https://github.com/pszturmaj/ddb


 Hey. I'm interested. I'm a web developer and PostgreSQL is my 
 database
 of choice. I also like the idea of a native implementation.
 The only problem is that I'm currently a beginner in D 
 programming (but
 not a beginner in PostgreSQL).
 But since I'll need some kind of D <-> PostgreSQL bindings for 
 my new
 project, I would be glad if I could help.


 BTW, I'd recommend to start a new organization on GitHub for 
 this, which makes it much easier to manage ownership changes 
 later on, if necessary. It also gives the main repository a 
 more official appearance.


Indeed. I have a fresh organization where I maintain D code: 
https://github.com/caraus-ecms. I could move it there and add 
pszturmaj to the organization.
Feb 13 2016
next sibling parent reply Adil Baig via Digitalmars-d-announce writes:
Hey Eugene,

Caraus seems like an interesting project. How do you plan to build it out
and differentiate it from vibe.d?


On Sat, Feb 13, 2016 at 5:11 PM, Eugene Wissner via Digitalmars-d-announce =
<
digitalmars-d-announce puremagic.com> wrote:


 On Saturday, 13 February 2016 at 12:57:50 UTC, S=C3=B6nke Ludwig wrote:


 Am 13.02.2016 um 11:03 schrieb Eugene Wissner:


 On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj wrote:


 Ddb is a relational database client for D [1]. Currently it only
 supports PostgreSQL but is not limited to it. It could be extended to
 support other backends.

 Built-in postgres client is a native implementation, that is it does
 not depend on libpq. Instead it communicates directly with the server
 avoiding text serialization and parsing overhead (PostgreSQL protocol
 is stable and well documented).

 I don't use it and I don't work on it anymore. Simply because I'm busy
 with other things and that things don't involve any RDBMS support.

 It has some user base, few contributors and 22 forks on github.
 Unfortunately, I could not handle pull requests and issues in a
 reasonable time and that's why I'm posting this here. I hope someone
 could take over this project and improve it.

 If you are interested, please either respond here or email me.

 [1] https://github.com/pszturmaj/ddb


 Hey. I'm interested. I'm a web developer and PostgreSQL is my database
 of choice. I also like the idea of a native implementation.
 The only problem is that I'm currently a beginner in D programming (but
 not a beginner in PostgreSQL).
 But since I'll need some kind of D <-> PostgreSQL bindings for my new
 project, I would be glad if I could help.


 BTW, I'd recommend to start a new organization on GitHub for this, which
 makes it much easier to manage ownership changes later on, if necessary.=




 It

 also gives the main repository a more official appearance.


 Indeed. I have a fresh organization where I maintain D code:
 https://github.com/caraus-ecms. I could move it there and add pszturmaj
 to the organization.
Feb 13 2016
parent reply Eugene Wissner <belka caraus.de> writes:
On Saturday, 13 February 2016 at 14:52:46 UTC, Adil Baig wrote:

 Hey Eugene,

 Caraus seems like an interesting project. How do you plan to 
 build it out and differentiate it from vibe.d?



Difficult to explain it in a few sentences in a foreign language, 
but I'll try. Just don't hesitate to ask if you have any 
questions. I'm also not very familiar with vibe.d, I've just seen 
a few examples and read about it a bit; so Sönke should excuse or 
correct me if I say nonsense :).

It should be a framework for easy building and maintaining of 
websites. The applications built on it would follow MVC (or 
MVC-like) pattern by default, but since the framework is thought 
as a set of reusable components/modules it should be possible to 
use it for everything else like micro-webframework for small 
projects with custom structure. The whole framework should ship 
an abstraction over HTTP(S), mail sending (sendmail, smtp), 
session handling with a possibility to implement an own storage 
(file system, redis, memcached, PostgreSQL...), dependency 
injection, router and so on.

It is a very common description. Now I make a few examples 
showing what I think the framework should be able to do.

1) Creating a website should be as simple as creating a 
Controller and a router configuration (YAML  or database for 
example), that assigns some route to this controller. Think of 
something like this:

class IndexController
{
   indexAction(Request request)
   {
     int contentId = 
this.getDatabase().getContentModel().getPageById(5);

     this.render("myTemplate.tpl", ["content": contentId]);
   }
}

2) Form handling. You create a register form. So you create a 
class User:
class User
{
   int username;
   string password;
}

and that class with some additional information should be 
rendered to a web form. There are should be also routins to help 
to verify the form (helpers for checking for email, length of the 
input, phone number) and persist it to a database. Whereby I 
don't think on ORM here, I'm not a big fan of ORMs. For my 
projects I would implement a rich domain model with domain 
objects, mappers... But it should be possible to use ORM as well 
if this is available. Dependency Injection would make such 
freedom possible. Btw. I think I won't write a DIc, 
https://github.com/mbierlee/poodinis looks very promissing for 
me. I would use any tools that meet requirements.

So it should help web developers in their daily job and should 
make the web development pleasant.
It doesn't mean that I implement 10 session handlers from the 
beginning. I will slowly implement things that I need for my 
projects and will accept contributions if there are some 
contributers one day.
And I can't promise that everything will be ready tomorrow. It is 
very time consuming. But I got a new project last week that may 
grow in the future. So I will begin to use these tools for my 
work (I'm pretty free what I'm writing in and how I do it).

It can overlap with vibe.d here and there, but I think it is more 
a continuation of vibe.d's http submodule. There were already few 
attempts to create a similar framework on top of vibe.d, see: 
https://github.com/CarbonComputed/carb.d or 
https://github.com/Skadi-d/Skadi.d for example. But I want to 
make it independent of the underlying platform (vibe.d, SCGI, 
FastCGI).
So far....
Feb 13 2016
parent reply notna <notna.remove.this ist-einmalig.de> writes:
On Saturday, 13 February 2016 at 19:06:46 UTC, Eugene Wissner 
wrote:

 On Saturday, 13 February 2016 at 14:52:46 UTC, Adil Baig wrote:

 Hey Eugene,

 Caraus seems like an interesting project. How do you plan to 
 build it out and differentiate it from vibe.d?



 Difficult to explain it in a few sentences in a foreign 
 language, but I'll try. Just don't hesitate to ask if you have 
 any questions. I'm also not very familiar with vibe.d, I've 
 just seen a few examples and read about it a bit; so Sönke 
 should excuse or correct me if I say nonsense :).

 It should be a framework for easy building and maintaining of 
 websites. The applications built on it would follow MVC (or 
 MVC-like) pattern by default, but since the framework is 
 thought as a set of reusable components/modules it should be 
 possible to use it for everything else like micro-webframework 
 for small projects with custom structure. The whole framework 
 should ship an abstraction over HTTP(S), mail sending 
 (sendmail, smtp), session handling with a possibility to 
 implement an own storage (file system, redis, memcached, 
 PostgreSQL...), dependency injection, router and so on.

 It is a very common description. Now I make a few examples 
 showing what I think the framework should be able to do.

 1) Creating a website should be as simple as creating a 
 Controller and a router configuration (YAML  or database for 
 example), that assigns some route to this controller. Think of 
 something like this:

 class IndexController
 {
   indexAction(Request request)
   {
     int contentId = 
 this.getDatabase().getContentModel().getPageById(5);

     this.render("myTemplate.tpl", ["content": contentId]);
   }
 }

 2) Form handling. You create a register form. So you create a 
 class User:
 class User
 {
   int username;
   string password;
 }

 and that class with some additional information should be 
 rendered to a web form. There are should be also routins to 
 help to verify the form (helpers for checking for email, length 
 of the input, phone number) and persist it to a database. 
 Whereby I don't think on ORM here, I'm not a big fan of ORMs. 
 For my projects I would implement a rich domain model with 
 domain objects, mappers... But it should be possible to use ORM 
 as well if this is available. Dependency Injection would make 
 such freedom possible. Btw. I think I won't write a DIc, 
 https://github.com/mbierlee/poodinis looks very promissing for 
 me. I would use any tools that meet requirements.

 So it should help web developers in their daily job and should 
 make the web development pleasant.
 It doesn't mean that I implement 10 session handlers from the 
 beginning. I will slowly implement things that I need for my 
 projects and will accept contributions if there are some 
 contributers one day.
 And I can't promise that everything will be ready tomorrow. It 
 is very time consuming. But I got a new project last week that 
 may grow in the future. So I will begin to use these tools for 
 my work (I'm pretty free what I'm writing in and how I do it).

 It can overlap with vibe.d here and there, but I think it is 
 more a continuation of vibe.d's http submodule. There were 
 already few attempts to create a similar framework on top of 
 vibe.d, see: https://github.com/CarbonComputed/carb.d or 
 https://github.com/Skadi-d/Skadi.d for example. But I want to 
 make it independent of the underlying platform (vibe.d, SCGI, 
 FastCGI).
 So far....


my five cents on that topic...

 Eugene:
 From my point of view, it would be great if you could bring in 
all your ideas, wishes, changes, additions and new stuff into 
vibe_d and help to grow and extend it and make it more usable...

Don't get me wrong, I thinks it's great if developers have 
various choices in general to pick from, but especially in Dlang 
"core tools" some of the existing stuff needs more 
contributors/help... like vibe_d, dub (both from Sönke & team) 
dfmt, ...

You and Sönke share the same native language (German) and also 
the same time zone (Munich/Berlin)... and as it seems also the 
same interest in "Web stuff/Frameworks", right? It shouldn't be 
that difficult for you guys to alighn and team-up to build an 
even better "Dlang Web tools/Framework development team"...
Feb 14 2016
parent Eugene Wissner <belka caraus.de> writes:
 my five cents on that topic...

  Eugene:
 From my point of view, it would be great if you could bring in 
 all your ideas, wishes, changes, additions and new stuff into 
 vibe_d and help to grow and extend it and make it more usable...

 Don't get me wrong, I thinks it's great if developers have 
 various choices in general to pick from, but especially in 
 Dlang "core tools" some of the existing stuff needs more 
 contributors/help... like vibe_d, dub (both from Sönke & team) 
 dfmt, ...

 You and Sönke share the same native language (German) and also 
 the same time zone (Munich/Berlin)... and as it seems also the 
 same interest in "Web stuff/Frameworks", right? It shouldn't be 
 that difficult for you guys to alighn and team-up to build an 
 even better "Dlang Web tools/Framework development team"...


My native language is Russian, but my German is anyway better 
than my English, it's true :)

Yes, I actually understand your point. I thought about it already 
and it could be really more productive. I think I have to look in 
vibe more closely. Maybe I'll just look into open issues on 
github, maybe I'll be able to find a few easy issues, I could try 
to fix - it could be the best way for me to get know vibe.d 
internally better.
Feb 14 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-02-13 14:11, Eugene Wissner wrote:


 Indeed. I have a fresh organization where I maintain D code:
 https://github.com/caraus-ecms. I could move it there and add pszturmaj
 to the organization.


I don't see anything with the things you don't like about vibe.d going 
against vibe.d. It's just the default settings/choices that don't match 
what you want/need.

"vibe.d is a framework to develop servers, network applications, it 
isn't really something you would usually use to develop a simple webpage 
or a blog or a forum."

There are some abstractions on top of vibe.d [1] [2].

"I don't like Diet-Jade templates. I prefer templating engines like 
Mustache or Smarty."

There are several Mustache packages for available through Dub [3] [4] [5].

"I don't like the choice of databases. Ok, I actually could write a 
driver for another database... I would go for PostgreSQL for the first 
time and it is still unsupported by default."

Ddb, you already know about that one.

"I want to learn D. PHP or Java may have too many frameworks, but it is 
still good to have a few of them, so people can choose what they like more."

If you don't like any of the packages you can write your own on top of 
vibe.d.

What I mean is that you don't need to start from scratch and write a 
completely new web framework.

[1] http://code.dlang.org/packages/action-pack
[2] http://code.dlang.org/packages/zeal

[3] http://code.dlang.org/packages/semitwistweb
[4] http://code.dlang.org/packages/mustache-d
[5] http://code.dlang.org/packages/jax

-- 
/Jacob Carlborg
Feb 14 2016
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 14.02.2016 um 13:01 schrieb Jacob Carlborg:

 On 2016-02-13 14:11, Eugene Wissner wrote:


 Indeed. I have a fresh organization where I maintain D code:
 https://github.com/caraus-ecms. I could move it there and add pszturmaj
 to the organization.


 I don't see anything with the things you don't like about vibe.d going
 against vibe.d. It's just the default settings/choices that don't match
 what you want/need.

 "vibe.d is a framework to develop servers, network applications, it
 isn't really something you would usually use to develop a simple webpage
 or a blog or a forum."

 There are some abstractions on top of vibe.d [1] [2].


The approach of the vibe.web package is also already very similar to 
that IndexController mentioned in the other post.
Feb 14 2016
prev sibling next sibling parent reply Suliman <evermind live.ru> writes:
On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj 
wrote:

 Ddb is a relational database client for D [1]. Currently it 
 only supports PostgreSQL but is not limited to it. It could be 
 extended to support other backends.

 Built-in postgres client is a native implementation, that is it 
 does not depend on libpq. Instead it communicates directly with 
 the server avoiding text serialization and parsing overhead 
 (PostgreSQL protocol is stable and well documented).

 I don't use it and I don't work on it anymore. Simply because 
 I'm busy with other things and that things don't involve any 
 RDBMS support.

 It has some user base, few contributors and 22 forks on github. 
 Unfortunately, I could not handle pull requests and issues in a 
 reasonable time and that's why I'm posting this here. I hope 
 someone could take over this project and improve it.

 If you are interested, please either respond here or email me.

 [1] https://github.com/pszturmaj/ddb


But we already have ddbc, that work pretty fine. Its better to 
force developing of it
Feb 13 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-02-13 16:20, Suliman wrote:


 But we already have ddbc, that work pretty fine. Its better to force
 developing of it


ddb is a Postgres client completely written in D. It does not use libpg, 
which ddbc does. It's also compatible with the IO model of vibe.d. I 
would say that any database library that is not compatible with vibe.d 
is not interesting.

-- 
/Jacob Carlborg
Feb 13 2016
prev sibling parent reply Eugene Wissner <belka caraus.de> writes:
On Saturday, 13 February 2016 at 15:20:26 UTC, Suliman wrote:

 But we already have ddbc, that work pretty fine. Its better to 
 force developing of it


I also looked into ddbc  before. And it is a great thing since it 
is similar to the well known jdbc. I didn't like that it just 
wraps C-functions to access the postgresql. But I don't see the 
vibe.d incompatibility as a problem. Would be really greate to 
merge ddbc and ddb ;)
Feb 13 2016
parent reply Dicebot <public dicebot.lv> writes:
On 02/13/2016 09:33 PM, Eugene Wissner wrote:

 On Saturday, 13 February 2016 at 15:20:26 UTC, Suliman wrote:

 But we already have ddbc, that work pretty fine. Its better to force
 developing of it


 
 I also looked into ddbc  before. And it is a great thing since it is
 similar to the well known jdbc. I didn't like that it just wraps
 C-functions to access the postgresql. But I don't see the vibe.d
 incompatibility as a problem. Would be really greate to merge ddbc and
 ddb ;)


It isn't specifically vibe.d incompatibility that is a problem but
general lack of support of async I/O model which is a showstopper for
using such solution in any serious network application. Ideally ddb
should be built on top of ddbc wrapping it into fiber-friendly async API
but I don't know if this is possible with ddbc design.
Feb 13 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-02-14 00:32, Dicebot wrote:


 Ideally ddb should be built on top of ddbc wrapping it into fiber-friendly
async API
 but I don't know if this is possible with ddbc design.


It looks like libpg has support for asynchronous calls [1] but ddbc does 
not use them. Also, although libpg provides asynchronous calls I'm not 
sure if that automatically means it will be compatible with the IO model 
used by vibe.

It seems both ddb and ddbc had the same idea, building a library 
accessing databases independently of the kind of database. The 
difference is that ddb does not seem to have the abstraction making it 
database independent and only works for Postgres. ddbc on the other hand 
does support multiple databases and have the abstraction layer. So at 
this point ddb is basically a Postgres driver and nothing more.

I like that ddb is completely written in D and doesn't depend on any C 
libraries. It's also compatible with the IO model of vibe.

Ideally a database library would consist separate projects for the 
different database drivers. These would be fully usable on their own. 
The database library would build a database independent layer on top of 
the drivers. Everything should be compatible with the IO model of vibe.

I would go with ddb and mysql-native for the drivers.

[1] http://www.postgresql.org/docs/current/static/libpq-async.html

-- 
/Jacob Carlborg
Feb 14 2016
next sibling parent Eugene Wissner <belka caraus.de> writes:
 Ideally a database library would consist separate projects for 
 the different database drivers. These would be fully usable on 
 their own. The database library would build a database 
 independent layer on top of the drivers. Everything should be 
 compatible with the IO model of vibe.


+1. It would be really great.

Does anybody know something about dpq2? It doesn't use 
C-interface directly, but uses libpq's shared library (.so, .dll 
or .lib). It claims to support async queries and is most actively 
maintained in this time as I see. And it cares only about 
PostgreSQL.
Feb 14 2016
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
On 2016-02-14 12:48, Jacob Carlborg wrote:

 It seems both ddb and ddbc had the same idea, building a library
 accessing databases independently of the kind of database. The
 difference is that ddb does not seem to have the abstraction making it
 database independent and only works for Postgres. ddbc on the other hand
 does support multiple databases and have the abstraction layer. So at
 this point ddb is basically a Postgres driver and nothing more.


ddb was written with multiple databases in mind, mostly postgres, mysql 
and sqlite. db.d (DBRow definition) is database independent. postgres.d 
contains PGConnection, PGCommand, etc. Other backends should provide 
their own classes like MySqlConnection, MySqlCommand and so on. Then 
it's trivial to add an abstraction layer that chooses between different 
backends depending on the connection string for example.

Regarding ddb maintainability, thank you for your interest, I can add 
you both (Jacob and Eugene) to my repository as collaborators, you will 
have full access to repo, pull requests and issues. If I will ever need 
ddb in some of my project I would still have access to my repo to make 
some changes. If the project will grow bigger than expected we could 
move it to the new repo later. Is that okay for you?
Feb 14 2016
next sibling parent reply Eugene Wissner <belka caraus.de> writes:
On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj wrote:

 On 2016-02-14 12:48, Jacob Carlborg wrote:

 It seems both ddb and ddbc had the same idea, building a 
 library
 accessing databases independently of the kind of database. The
 difference is that ddb does not seem to have the abstraction 
 making it
 database independent and only works for Postgres. ddbc on the 
 other hand
 does support multiple databases and have the abstraction 
 layer. So at
 this point ddb is basically a Postgres driver and nothing more.


 ddb was written with multiple databases in mind, mostly 
 postgres, mysql and sqlite. db.d (DBRow definition) is database 
 independent. postgres.d contains PGConnection, PGCommand, etc. 
 Other backends should provide their own classes like 
 MySqlConnection, MySqlCommand and so on. Then it's trivial to 
 add an abstraction layer that chooses between different 
 backends depending on the connection string for example.

 Regarding ddb maintainability, thank you for your interest, I 
 can add you both (Jacob and Eugene) to my repository as 
 collaborators, you will have full access to repo, pull requests 
 and issues. If I will ever need ddb in some of my project I 
 would still have access to my repo to make some changes. If the 
 project will grow bigger than expected we could move it to the 
 new repo later. Is that okay for you?


yes, it is for sure ok for me. It can be a good start.

I think may be we should discuss if we can/should change 
something in ddb. I think there were some interesting and 
promising ideas in this discussion. Maybe split the PostgreSQL 
driver and develop it seperately and use an interface more 
similar to JDBC. Maybe some kind of coworking with ddbc is 
possible to get more developers together; maybe Suliman has some 
thoughts on it.
Feb 14 2016
next sibling parent Suliman <evermind live.ru> writes:
On Sunday, 14 February 2016 at 19:48:34 UTC, Eugene Wissner wrote:

 On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj 
 wrote:

 On 2016-02-14 12:48, Jacob Carlborg wrote:

 It seems both ddb and ddbc had the same idea, building a 
 library
 accessing databases independently of the kind of database. The
 difference is that ddb does not seem to have the abstraction 
 making it
 database independent and only works for Postgres. ddbc on the 
 other hand
 does support multiple databases and have the abstraction 
 layer. So at
 this point ddb is basically a Postgres driver and nothing 
 more.


 ddb was written with multiple databases in mind, mostly 
 postgres, mysql and sqlite. db.d (DBRow definition) is 
 database independent. postgres.d contains PGConnection, 
 PGCommand, etc. Other backends should provide their own 
 classes like MySqlConnection, MySqlCommand and so on. Then 
 it's trivial to add an abstraction layer that chooses between 
 different backends depending on the connection string for 
 example.

 Regarding ddb maintainability, thank you for your interest, I 
 can add you both (Jacob and Eugene) to my repository as 
 collaborators, you will have full access to repo, pull 
 requests and issues. If I will ever need ddb in some of my 
 project I would still have access to my repo to make some 
 changes. If the project will grow bigger than expected we 
 could move it to the new repo later. Is that okay for you?


 yes, it is for sure ok for me. It can be a good start.

 I think may be we should discuss if we can/should change 
 something in ddb. I think there were some interesting and 
 promising ideas in this discussion. Maybe split the PostgreSQL 
 driver and develop it seperately and use an interface more 
 similar to JDBC. Maybe some kind of coworking with ddbc is 
 possible to get more developers together; maybe Suliman has 
 some thoughts on it.


I like idea to have one good driver instead of two of not 
finished, and would like that it ships as vibe-d module. For my 
regret I have not enough so experience to help with developing. 
But if you will decide to collaborate with ddbc developer (he is 
also russian-speaker) it will be very cool.
Feb 14 2016
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
On 2016-02-14 20:48, Eugene Wissner wrote:

 I think may be we should discuss if we can/should change something in
 ddb. I think there were some interesting and promising ideas in this
 discussion. Maybe split the PostgreSQL driver and develop it seperately
 and use an interface more similar to JDBC. Maybe some kind of coworking
 with ddbc is possible to get more developers together; maybe Suliman has
 some thoughts on it.


I added you and Jacob as collaborators. Please do what you think is 
right. Thanks.
Feb 15 2016
parent reply Suliman <evermind live.ru> writes:
On Monday, 15 February 2016 at 22:50:56 UTC, Piotr Szturmaj wrote:

 On 2016-02-14 20:48, Eugene Wissner wrote:

 I think may be we should discuss if we can/should change 
 something in
 ddb. I think there were some interesting and promising ideas 
 in this
 discussion. Maybe split the PostgreSQL driver and develop it 
 seperately
 and use an interface more similar to JDBC. Maybe some kind of 
 coworking
 with ddbc is possible to get more developers together; maybe 
 Suliman has
 some thoughts on it.


 I added you and Jacob as collaborators. Please do what you 
 think is right. Thanks.


Could anybody help me to understand how to get data as ubyte?

I found this places in sources.
https://github.com/pszturmaj/ddb/commit/29070ef90ba8f8d658be50a5da4aa3c96d0cdd5a
https://github.com/pszturmaj/ddb/commit/a66ff5a6aa7008235f28cce167d0ae42cc4f4df3

But I can't understand how to use it.

My code is next:

	auto cmd = new PGCommand(conn);
	
	cmd.query = `SELECT name, userblob FROM "USERS" ;`;
	
	ubyte [] x;
	
	try {
        auto result = cmd.executeQuery;
	
	   foreach (row; result)
	   {
		writeln(row[0]);
		x = row[1].get!(ubyte);
	   }
	
     }
     catch (ServerErrorException e) {
         // Probably table does not exist - ignore
     }


But I am getting error:

source\app.d(28,13): Error: cannot implicitly convert expression 
(( VariantN!20u __tmpfordtor3893 = row.opIndex(1u);
  , __tmpfordtor3893).get()) of type ubyte to ubyte[]
dmd failed with exit code 1.
Apr 12 2016
parent reply Rory McGuire via Digitalmars-d-announce writes:
On Tue, Apr 12, 2016 at 10:31 AM, Suliman via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On Monday, 15 February 2016 at 22:50:56 UTC, Piotr Szturmaj wrote:


 On 2016-02-14 20:48, Eugene Wissner wrote:


 I think may be we should discuss if we can/should change something in
 ddb. I think there were some interesting and promising ideas in this
 discussion. Maybe split the PostgreSQL driver and develop it seperately
 and use an interface more similar to JDBC. Maybe some kind of coworking
 with ddbc is possible to get more developers together; maybe Suliman has
 some thoughts on it.


 I added you and Jacob as collaborators. Please do what you think is
 right. Thanks.


 Could anybody help me to understand how to get data as ubyte?

 I found this places in sources.

 https://github.com/pszturmaj/ddb/commit/29070ef90ba8f8d658be50a5da4aa3c96d0cdd5a

 https://github.com/pszturmaj/ddb/commit/a66ff5a6aa7008235f28cce167d0ae42cc4f4df3

 But I can't understand how to use it.

 My code is next:

         auto cmd = new PGCommand(conn);

         cmd.query = `SELECT name, userblob FROM "USERS" ;`;

         ubyte [] x;

         try {
        auto result = cmd.executeQuery;

            foreach (row; result)
            {
                 writeln(row[0]);
                 x = row[1].get!(ubyte);
            }

     }
     catch (ServerErrorException e) {
         // Probably table does not exist - ignore
     }


 But I am getting error:

 source\app.d(28,13): Error: cannot implicitly convert expression ((
 VariantN!20u __tmpfordtor3893 = row.opIndex(1u);
  , __tmpfordtor3893).get()) of type ubyte to ubyte[]
 dmd failed with exit code 1.


Hi,

In your example x is a ubyte[] and you get!(ubyte).

x should be a ubyte, however from your sql query I'd assume you actually
mean to use .get!(ubyte[])
Apr 12 2016
parent reply Suliman <evermind live.ru> writes:
On Tuesday, 12 April 2016 at 08:47:43 UTC, Rory McGuire wrote:

 On Tue, Apr 12, 2016 at 10:31 AM, Suliman via 
 Digitalmars-d-announce < digitalmars-d-announce puremagic.com> 
 wrote:


 On Monday, 15 February 2016 at 22:50:56 UTC, Piotr Szturmaj 
 wrote:


 On 2016-02-14 20:48, Eugene Wissner wrote:


 I think may be we should discuss if we can/should change 
 something in ddb. I think there were some interesting and 
 promising ideas in this discussion. Maybe split the 
 PostgreSQL driver and develop it seperately and use an 
 interface more similar to JDBC. Maybe some kind of coworking 
 with ddbc is possible to get more developers together; maybe 
 Suliman has some thoughts on it.


 I added you and Jacob as collaborators. Please do what you 
 think is right. Thanks.


 Could anybody help me to understand how to get data as ubyte?

 I found this places in sources.

 https://github.com/pszturmaj/ddb/commit/29070ef90ba8f8d658be50a5da4aa3c96d0cdd5a

 https://github.com/pszturmaj/ddb/commit/a66ff5a6aa7008235f28cce167d0ae42cc4f4df3

 But I can't understand how to use it.

 My code is next:

         auto cmd = new PGCommand(conn);

         cmd.query = `SELECT name, userblob FROM "USERS" ;`;

         ubyte [] x;

         try {
        auto result = cmd.executeQuery;

            foreach (row; result)
            {
                 writeln(row[0]);
                 x = row[1].get!(ubyte);
            }

     }
     catch (ServerErrorException e) {
         // Probably table does not exist - ignore
     }


 But I am getting error:

 source\app.d(28,13): Error: cannot implicitly convert 
 expression ((
 VariantN!20u __tmpfordtor3893 = row.opIndex(1u);
  , __tmpfordtor3893).get()) of type ubyte to ubyte[]
 dmd failed with exit code 1.


 Hi,

 In your example x is a ubyte[] and you get!(ubyte).

 x should be a ubyte, however from your sql query I'd assume you 
 actually
 mean to use .get!(ubyte[])



I need to get binary blob. It's storage in PG as `bytea`. Could 
you show example how to get data from this field?
Apr 12 2016
parent reply Suliman <evermind live.ru> writes:
This code compile and run:

try {
        auto result = cmd.executeQuery;
	
	   foreach (row; result)
	   {
		writeln(row[0]);
		x = row[1].get!(ubyte[]);
	   }
	
     }
     catch (ServerErrorException e) {
         // Probably table does not exist - ignore
     }




But I am getting error:

core.exception.OutOfMemoryError src\core\exception.d(679): Memory 
allocation failed

Is there any hack that can prevent this error?
Apr 12 2016
parent reply Rory McGuire via Digitalmars-d-announce writes:
On Tue, Apr 12, 2016 at 11:30 AM, Suliman via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 This code compile and run:

 try {
        auto result = cmd.executeQuery;

            foreach (row; result)
            {
                 writeln(row[0]);
                 x = row[1].get!(ubyte[]);
            }

     }
     catch (ServerErrorException e) {
         // Probably table does not exist - ignore
     }




 But I am getting error:

 core.exception.OutOfMemoryError src\core\exception.d(679): Memory
 allocation failed

 Is there any hack that can prevent this error?


Would need to see the full exception stack trace that was printed out.
Could you perhaps have an infinite recursion bug in there somewhere?
You should be able to see if you are getting the right type out of the
Variant by using something like:
writeln(row[1].type);
Apr 12 2016
parent reply Suliman <evermind live.ru> writes:
On Tuesday, 12 April 2016 at 09:52:53 UTC, Rory McGuire wrote:

 On Tue, Apr 12, 2016 at 11:30 AM, Suliman via 
 Digitalmars-d-announce < digitalmars-d-announce puremagic.com> 
 wrote:


 This code compile and run:

 try {
        auto result = cmd.executeQuery;

            foreach (row; result)
            {
                 writeln(row[0]);
                 x = row[1].get!(ubyte[]);
            }

     }
     catch (ServerErrorException e) {
         // Probably table does not exist - ignore
     }




 But I am getting error:

 core.exception.OutOfMemoryError src\core\exception.d(679): 
 Memory
 allocation failed

 Is there any hack that can prevent this error?


 Would need to see the full exception stack trace that was 
 printed out.
 Could you perhaps have an infinite recursion bug in there 
 somewhere?
 You should be able to see if you are getting the right type out 
 of the
 Variant by using something like:
 writeln(row[1].type);


I am getting Out of memory exception even on this code:
writeln(row[0].type);

writeln(row[0]); // -- works fine
Apr 12 2016
parent Etienne <etcimon gmail.com> writes:
On Tuesday, 12 April 2016 at 09:58:22 UTC, Suliman wrote:

 On Tuesday, 12 April 2016 at 09:52:53 UTC, Rory McGuire wrote:

 On Tue, Apr 12, 2016 at 11:30 AM, Suliman via 
 Digitalmars-d-announce < digitalmars-d-announce puremagic.com> 
 wrote:


[...]


 Would need to see the full exception stack trace that was 
 printed out.
 Could you perhaps have an infinite recursion bug in there 
 somewhere?
 You should be able to see if you are getting the right type 
 out of the
 Variant by using something like:
 writeln(row[1].type);


 I am getting Out of memory exception even on this code:
 writeln(row[0].type);

 writeln(row[0]); // -- works fine


writeln(row[0]) is fine.

However, you need to close the result set and destroy the 
PGCommand.

result.close();
cmd.destroy();
Apr 12 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-02-14 17:53, Piotr Szturmaj wrote:


 ddb was written with multiple databases in mind, mostly postgres, mysql
 and sqlite. db.d (DBRow definition) is database independent. postgres.d
 contains PGConnection, PGCommand, etc. Other backends should provide
 their own classes like MySqlConnection, MySqlCommand and so on. Then
 it's trivial to add an abstraction layer that chooses between different
 backends depending on the connection string for example.

 Regarding ddb maintainability, thank you for your interest, I can add
 you both (Jacob and Eugene) to my repository as collaborators, you will
 have full access to repo, pull requests and issues. If I will ever need
 ddb in some of my project I would still have access to my repo to make
 some changes. If the project will grow bigger than expected we could
 move it to the new repo later. Is that okay for you?


Fine by me.

-- 
/Jacob Carlborg
Feb 15 2016
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Sun, 14 Feb 2016 12:48:49 +0100, Jacob Carlborg wrote:


 On 2016-02-14 00:32, Dicebot wrote:
 

 Ideally ddb should be built on top of ddbc wrapping it into
 fiber-friendly async API but I don't know if this is possible with ddbc
 design.


 
 It looks like libpg has support for asynchronous calls [1] but ddbc does
 not use them. Also, although libpg provides asynchronous calls I'm not
 sure if that automatically means it will be compatible with the IO model
 used by vibe.


If you have asynchronous calls that you can poll, you can make it work 
with vibe.d, albeit awkwardly. (Start request, poll+yield, return when 
there's a result.) If you only have synchronous calls, you'd have to 
introduce IO threads and synchronization.

It's awkward to make things compatible with vibe.d and Phobos IO. The APIs 
are rather dissimilar, so you can't just, for instance, have different 
imports under a version() block.
Feb 14 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-02-13 06:02, Piotr Szturmaj wrote:

 Ddb is a relational database client for D [1]. Currently it only
 supports PostgreSQL but is not limited to it. It could be extended to
 support other backends.

 Built-in postgres client is a native implementation, that is it does not
 depend on libpq. Instead it communicates directly with the server
 avoiding text serialization and parsing overhead (PostgreSQL protocol is
 stable and well documented).

 I don't use it and I don't work on it anymore. Simply because I'm busy
 with other things and that things don't involve any RDBMS support.

 It has some user base, few contributors and 22 forks on github.
 Unfortunately, I could not handle pull requests and issues in a
 reasonable time and that's why I'm posting this here. I hope someone
 could take over this project and improve it.

 If you are interested, please either respond here or email me.

 [1] https://github.com/pszturmaj/ddb


I'm very interested in ddb, not sure if I can be the maintainer. It 
depends if I can use D for a project that needs to access Postgres. If I 
can't use D for that project I don't have so much interest.

-- 
/Jacob Carlborg
Feb 13 2016