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

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.

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.

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.

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ö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.
>

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

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

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

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....

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 ;)