October 06, 2012
On 2012-10-06 22:59, Nick Sabalausky wrote:

> DSSS has been dead for a long time, I don't know why an active project
> like GtkD is apparently mentioning it.

DSSS is working just fine for D1. GtkD works both with D1 and D2.

-- 
/Jacob Carlborg
October 06, 2012
On Sat, 06 Oct 2012 23:27:55 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2012-10-06 22:59, Nick Sabalausky wrote:
> 
> > DSSS has been dead for a long time, I don't know why an active project like GtkD is apparently mentioning it.
> 
> DSSS is working just fine for D1.

I don't know about the rest of DSSS as I only ever used the 'rebuild' component. But as for rebuild, there are problems:

For one thing, 0.76 is generally considered to work much better than
0.77 and the final version, 0.78 (I forget the details, but a lot
of people including me have had problems with 0.78 that never showed up
with 0.76). But despite that, read-made builds aren't available for
0.76. As DSSS is dead none of this is likely to get fixed. And
there's no reason to fix rebuild since RDMD is a superior and non-dead
alternative to rebuild.

Also, rebuild is slow, even with "one at a time" disabled. Try
compiling DVM with the included rebuild-based script and the
RDMD-based one. It takes a fair amount of time with rebuild
(even with "one at a time" off), but with RDMD it's almost instant.

There's no reason for anyone to use rebuild anymore, and very few people do.

> GtkD works both with D1 and D2.
> 

So does RDMD, unless I'm mistaken.

October 06, 2012
On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
>> - I looked for a PostgreSQL client library. I found small
> personal hacks and
> dead projects.

https://github.com/denizzzka/dpq2

This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd.

I really need users, comments, suggestions, bug reports and commits.
October 07, 2012
denizzzka wrote:
> https://github.com/denizzzka/dpq2
Thank you very much. I think I haven't seen this project. Would you like to add it to this wiki page?

http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL

Best regards, Thomas Koch
October 07, 2012
On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
> On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
> >> - I looked for a PostgreSQL client library. I found small
> > personal hacks and
> > dead projects.
> 
> https://github.com/denizzzka/dpq2
> 
> This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd.
> 
> I really need users, comments, suggestions, bug reports and commits.

Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.?

From the example I assume that this is just a library for managing connections and that everything else is just string-based SQL statements. Groovy's and Python's lowest level is roughly the same. However on top of these are expression languages in Groovy / Python so as to remove the reliance on string processing, i.e. use an internal DSL to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it will hopefully be GSQL. I am sure Scala and C++ have something similar?

So I guess the question is how to ensure this all works with all SQL systems and how to put an abstraction layer over this to avoid all the error prone string manipulation?


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


October 07, 2012
On Sunday, 7 October 2012 at 09:07:39 UTC, Russel Winder wrote:
> On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
>> On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
>> >> - I looked for a PostgreSQL client library. I found small
>> > personal hacks and
>> > dead projects.
>> 
>> https://github.com/denizzzka/dpq2
>> 
>> This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd.
>> 
>> I really need users, comments, suggestions, bug reports and commits.
>
> Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
> PervasiveSQL, SQLite3, etc.?
>
Probably if someones needs work to be done in ie PostreSQL won't care about other DBMS at the time of being.

There are other projects for Database handling.

- There is SQLd [http://github.com/robik/sqld], that focus on multiple database drivers. Some designs flaws are inherited from SQLAlchemy. Looks promising.
- There is DBMI on DSource. I am not 100% sure if it works with D2 tho (but porting should be rather trivial).
- Many, many other projects like that shattered on Github/BitBucket/DSource(?)

> From the example I assume that this is just a library for managing
> connections and that everything else is just string-based SQL
> statements. Groovy's and Python's lowest level is roughly the same.
> However on top of these are expression languages in Groovy / Python so
> as to remove the reliance on string processing, i.e. use an internal DSL
> to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it
> will hopefully be GSQL. I am sure Scala and C++ have something similar?
>
> So I guess the question is how to ensure this all works with all SQL
> systems and how to put an abstraction layer over this to avoid all the
> error prone string manipulation?
>

Probably because of reason I mentioned before.
But yeah, after first glance it looks like project ready for some bigger tasks

October 07, 2012
On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton Wakeling wrote:
> On 10/06/2012 10:59 PM, Nick Sabalausky wrote:
>> Definitely not. *DSource* is dying, unfortunately, which has lead some
>> people to assume the same of the rest of D. But no, D is going very
>> strong, and has only been getting bigger.
>
> Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org?

+1

Getting tired of people heading to dsource and assuming that D is dead.
October 07, 2012
Russel Winder wrote:
> On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
>> On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
>>>> - I looked for a PostgreSQL client library. I found small
>>> personal hacks and
>>> dead projects.
>>
>> https://github.com/denizzzka/dpq2
>>
>> This is my personal project but it is not dead, and I am
>> determined to see it through. At the moment, it is quite suitable
>> to be used in simple situations. Compiles without warnings by dmd
>> 2.060, also it can be used with rdmd.
>>
>> I really need users, comments, suggestions, bug reports and
>> commits.
>
> Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
> PervasiveSQL, SQLite3, etc.?

I wrote a PostgreSQL client too, but I also want to make MySQL and SQlite clients/wrappers and release them all at once. This is because I want to create uniform DB interface, and it must be suited for all database systems. I started with PostgreSQL because it's most complex of the three, for instance it supports array and struct fields.

>  From the example I assume that this is just a library for managing
> connections and that everything else is just string-based SQL
> statements. Groovy's and Python's lowest level is roughly the same.
> However on top of these are expression languages in Groovy / Python so
> as to remove the reliance on string processing, i.e. use an internal DSL
> to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it
> will hopefully be GSQL. I am sure Scala and C++ have something similar?

As you've said, additional DSL/Abstract layer must be on built on the string based library. We should finish that first.
October 07, 2012
On Sunday, October 07, 2012 11:43:21 Peter Alexander wrote:
> On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton
> 
> Wakeling wrote:
> > On 10/06/2012 10:59 PM, Nick Sabalausky wrote:
> >> Definitely not. *DSource* is dying, unfortunately, which has
> >> lead some
> >> people to assume the same of the rest of D. But no, D is going
> >> very
> >> strong, and has only been getting bigger.
> > 
> > Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org?
> 
> +1
> 
> Getting tired of people heading to dsource and assuming that D is dead.

Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all.

- Jonathan M Davis
October 07, 2012
On Sunday, 7 October 2012 at 09:56:30 UTC, Piotr Szturmaj wrote:
> Russel Winder wrote:
>> On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote:
>>> On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:
>>>>> - I looked for a PostgreSQL client library. I found small
>>>> personal hacks and
>>>> dead projects.
>>>
>>> https://github.com/denizzzka/dpq2
>>>
>>> This is my personal project but it is not dead, and I am
>>> determined to see it through. At the moment, it is quite suitable
>>> to be used in simple situations. Compiles without warnings by dmd
>>> 2.060, also it can be used with rdmd.
>>>
>>> I really need users, comments, suggestions, bug reports and
>>> commits.
>>
>> Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2,
>> PervasiveSQL, SQLite3, etc.?
>
> I wrote a PostgreSQL client too, but I also want to make MySQL and SQlite clients/wrappers and release them all at once. This is because I want to create uniform DB interface, and it must be suited for all database systems. I started with PostgreSQL because it's most complex of the three, for instance it supports array and struct fields.
>

I would also look at commercial DB, otherwise you might still find a few surprises while defining an uniform DB.

I went through that pain back in 1999-2001, when we were defining an abstraction mechanism in TCL/C to bind to multiple databases, akin to ActiveRecord on Ruby.

For example, on those days using only ODBC was not enough for SQL Server 6. We also needed to make use of another binding provided for compatibility with Sybase SQL Server, to be able to offer all the same API when using SQL Server as DB. That took awhile to figure out how to integrate into the existing architecture.

--
Paulo