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