Re: Ddb needs a maintainer
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();
Re: Ddb needs a maintainer
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
Re: Ddb needs a maintainer
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);
Re: Ddb needs a maintainer
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?
Re: Ddb needs a maintainer
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?
Re: Ddb needs a maintainer
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[])
Re: Ddb needs a maintainer
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.
Re: Ddb needs a maintainer
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.
Re: Ddb needs a maintainer
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
Re: Ddb needs a maintainer
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.
Re: Ddb needs a maintainer
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.
Re: Ddb needs a maintainer
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.
Re: Ddb needs a maintainer
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
Re: Ddb needs a maintainer
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.
Re: Ddb needs a maintainer
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.
Re: Ddb needs a maintainer
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.
Re: Ddb needs a maintainer
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. >
Re: Ddb needs a maintainer
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
Re: Ddb needs a maintainer
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
Re: Ddb needs a maintainer
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
Re: Ddb needs a maintainer
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
Re: Ddb needs a maintainer
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 ;)
Re: Ddb needs a maintainer
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.
Ddb needs a maintainer
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
