www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The sorry state of the D stack?

reply Thomas Koch <thomas koch.ro> writes:
Hi,

the subject refers to my current state of sadness after trying to dig into D 
programming for a few days. I've been very exited after reading "The D 
programming language", but I've doubts now.

- There's no "standard" library to read a single character from the console. 
Instead people write their own personal helper libraries.

- I looked into GtkD, which refers to the build tool DSSS. However DSSS 
seems to be unmaintained for a couple of years. (Why does every new language 
needs its own build tool?)

- I looked for a PostgreSQL client library. I found small personal hacks and 
dead projects.

- I looked at http://www.dsource.org/forums - most forums are dead.

Is it possible that D is a dead language? For a newbie like me it would be 
very helpful to have a list of good, healthy projects for my first steps in 
D instead of finding cadavers all around. Typesafe, the company behind 
Scala, maintains a "Typesafe Stack" of active, recommendable projects.

Please don't be offended by this message. I just wanted to provide feedback 
and will keep trying to get into D. Thank you very much for this wonderful 
language!

Best regards, Thomas Koch
Oct 06 2012
next sibling parent reply "nazriel" <spam dzfl.pl> writes:
On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote:

 Hi,

 the subject refers to my current state of sadness after trying 
 to dig into D
 programming for a few days. I've been very exited after reading 
 "The D
 programming language", but I've doubts now.

 - There's no "standard" library to read a single character from 
 the console.
 Instead people write their own personal helper libraries.


getch()
There is always possibility to add something more high level to 
std.stdio if there will be such need.


 - I looked into GtkD, which refers to the build tool DSSS. 
 However DSSS
 seems to be unmaintained for a couple of years. (Why does every 
 new language
 needs its own build tool?)


There are normal Make files. DSSS is mostly for D1 (GtkD also 
supports D1).
For building on Windows you also got possibility to use bud tool 
(you don't need to play with Make files)


 - I looked for a PostgreSQL client library. I found small 
 personal hacks and
 dead projects.


You want pure C-like headers or Wrapper?
There is for example SQLd : https://github.com/robik/SQLd or 
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/postgres.d

And lots of other projects. To be honest there are TONS of such 
things on Github.

 - I looked at http://www.dsource.org/forums - most forums are 
 dead.


DSource is mostly DEAD space. It should be mentioned somewhere 
that DSource is graveyard for old, mostly D1 abandoned projects.


 Is it possible that D is a dead language?


Nope, it isn't


 For a newbie like me it would be
 very helpful to have a list of good, healthy projects for my 
 first steps in
 D instead of finding cadavers all around.


Yea, I get your point, I was thinking the same at the begging I 
tried D.
But IRC channel, #d   freenode can help a lot if resolving your 
thoughts

 Typesafe, the company behind
 Scala, maintains a "Typesafe Stack" of active, recommendable 
 projects.

 Please don't be offended by this message. I just wanted to 
 provide feedback
 and will keep trying to get into D. Thank you very much for 
 this wonderful
 language!

 Best regards, Thomas Koch
Oct 06 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
nazriel:


 getch()
 There is always possibility to add something more high level to 
 std.stdio if there will be such need.


I think the need for a Phobos portable way to read a char in is 
present.

Bye,
bearophile
Oct 06 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 6 October 2012 at 12:52:36 UTC, bearophile wrote:

 I think the need for a Phobos portable way to read a char in is 
 present.


I just slapped together a very quick Linux struct:

=====

version(Posix):

import core.sys.posix.termios;
import core.sys.posix.unistd;
import core.sys.posix.sys.types;
import core.sys.posix.sys.time;
import core.stdc.stdio;

enum ConsoleInputFlags {
	raw = 0,
	echo = 1
}

struct RealTimeConsoleInput {
	 disable this();
          disable this(this);
	private int fd;
	private termios old;

	this(ConsoleInputFlags flags) {
		this.fd = 0; // stdin
		tcgetattr(fd, &old);
		auto n = old;

		auto f = ICANON;
		if(!(flags & ConsoleInputFlags.echo))
			f |= ECHO;

		n.c_lflag &= ~f;
		tcsetattr(fd, TCSANOW, &n);
	}

	~this() {
		tcsetattr(fd, TCSANOW, &old);
	}

	bool kbhit() {
		timeval tv;
		tv.tv_sec = 0;
		tv.tv_usec = 0;

		fd_set fs;
		FD_ZERO(&fs);

		FD_SET(fd, &fs);
		select(fd + 1, &fs, null, null, &tv);

		return FD_ISSET(fd, &fs);
	}

	char getch() {
		return cast(char) .fgetc(.stdin);
	}
}

===


Usage:



void main() {
         auto input = new 
RealTimeConsoleInput(ConsoleInputFlags.raw);

         while(true) {
                 if(input.kbhit()) { // is a key available?
                         auto c = input.getch(); // get it
                         if(c == 'q' || c == 'Q')
                                 break;
                         printf("%c", c);
                         fflush(stdout);
                 }
                 usleep(10000);
         }
}





IIRC it is very easy to do this on Windows as there's no need to 
change the console mode.
Oct 06 2012
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 6 October 2012 at 14:50:08 UTC, Adam D. Ruppe wrote:

 IIRC it is very easy to do this on Windows as there's no need 
 to change the console mode.


Windows already has getch() in one of its system libraries or C 
runtime, and I'm fairly sure it has kbhit() somewhere too. The 
easiest thing to do would just be to link with those.
Oct 06 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/6/2012 4:54 AM, Thomas Koch wrote:

 - I looked at http://www.dsource.org/forums - most forums are dead.


Most of the D forum action is here.
Oct 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-06 13:54, Thomas Koch wrote:


 - I looked into GtkD, which refers to the build tool DSSS. However DSSS
 seems to be unmaintained for a couple of years. (Why does every new language
 needs its own build tool?)


I would say because it's possible to tune the tool specially for the 
language making it easier to use. Most available tools are either not 
cross-platform or have some kind of dependency that might not be so easy 
to install on all platforms.

-- 
/Jacob Carlborg
Oct 06 2012
prev sibling next sibling parent Jeremy Sandell <jlsandell gmail.com> writes:
On Sat, Oct 6, 2012 at 7:54 AM, Thomas Koch <thomas koch.ro> wrote:


 (Why does every new language
 needs its own build tool?)



They often don't. I seem to recall
http://www.dsource.org/projects/cmaked working
just fine for one of my D2 projects. Not having to globally install it was
pretty nice, too, and since I needed to build C source along side my D2
source (i.e., bindings) it was a perfect fit.

HTH,
Jeremy Sandell
Oct 06 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 06 Oct 2012 13:54:11 +0200
Thomas Koch <thomas koch.ro> wrote:

 
 - I looked into GtkD, which refers to the build tool DSSS. However
 DSSS seems to be unmaintained for a couple of years. 
 


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

The proper tool (equivalent to DSSS's "rebuild") is RDMD, which is
bundled with DMD.


 (Why does every
 new language needs its own build tool?)


Because there aren't any good ones (IMO). They all seem to fall into one
of two categories:

- Something that either *is* make, is a variant of make, or uses make.

- Introduces a requirement of some *other* language. (I don't want to
force people to install or deal with Ruby or Python, and make sure
they're on the right version of it, just to compile my D code.)


 - I looked for a PostgreSQL client library. I found small personal
 hacks and dead projects.
 


SQL lib support is unfortunately one of our weak points ATM. I could
point you to a decent MySQL lib :/


 - I looked at http://www.dsource.org/forums - most forums are dead.
 


Like Walter said, the main, active, D forums are right here.

Also, most D project hosting has moved from DSource to places like
BitBucket and GitHub. 


 Is it possible that D is a dead language?


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.


 For a newbie like me it
 would be very helpful to have a list of good, healthy projects for my
 first steps in D instead of finding cadavers all around. Typesafe,
 the company behind Scala, maintains a "Typesafe Stack" of active,
 recommendable projects.
 


We have a list on the Wiki:

http://www.prowiki.org/wiki4d/wiki.cgi

I don't know how well-maintained that list is. If it isn't
well-maintained, then it certainly needs to be.
Oct 06 2012
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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?
Oct 06 2012
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Oct 07 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Oct 07 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 07 Oct 2012 02:51:42 -0700
Jonathan M Davis <jmdavisProg gmx.com> wrote:


 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:

 
 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.
 


No, I think he'd just been busy. I've seen him around here a few times
lately.
Oct 07 2012
parent reply "jerro" <a a.com> writes:
 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.
 


 No, I think he'd just been busy. I've seen him around here a 
 few times
 lately.


Are you sure about that? There is a guy named Brad Anderson 
posting here, but he doesn't seem to be the Brad Anderson that 
dsource.org is registered to.
Oct 07 2012
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 07 Oct 2012 18:39:16 +0200
"jerro" <a a.com> wrote:


 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.
 


 No, I think he'd just been busy. I've seen him around here a 
 few times
 lately.


 
 Are you sure about that? There is a guy named Brad Anderson 
 posting here, but he doesn't seem to be the Brad Anderson that 
 dsource.org is registered to.


Oh, I guess I don't know. I just noticed the name.
Oct 07 2012
prev sibling parent Brad Anderson <eco gnuk.net> writes:
On Sun, Oct 7, 2012 at 10:39 AM, jerro <a a.com> wrote:


 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.


 No, I think he'd just been busy. I've seen him around here a few times
 lately.


 Are you sure about that? There is a guy named Brad Anderson posting here,
 but he doesn't seem to be the Brad Anderson that dsource.org is
 registered to.


Yeah, I'm not the same guy as the Brad Anderson who runs dsource. Someone
may want to email him directly.

Regards,
Doppelganger
Oct 08 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Oct 06 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Oct 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-07 00:14, Nick Sabalausky wrote:


 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.


I'm still using 0.75, when I'm using it.


 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.


I'm well aware that RDMD is a lot faster than Rebuild.


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


Maybe not only Rebuild, but DSSS offers more than RDMD. DSSS supports 
building libraries, build files, generating documentation and other 
features. With RDMD you must likely need a shell script for the build 
flags. Shell scripts aren't cross-platform which means you need a .bat 
file on Windows. That will result in duplication which is not good.


 So does RDMD, unless I'm mistaken.


Yes, but there are still reasons to use DSSS for D1, see above.

-- 
/Jacob Carlborg
Oct 07 2012
prev sibling parent reply "denizzzka" <4denizzz gmail.com> writes:
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.
Oct 06 2012
next sibling parent reply Thomas Koch <thomas koch.ro> writes:
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
Oct 07 2012
parent reply "denizzzka" <4denizzz gmail.com> writes:
On Sunday, 7 October 2012 at 08:05:10 UTC, Thomas Koch wrote:

 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


I could not register there. :( Who have the opportunity, please 
add https://github.com/denizzzka/dpq2 to this wiki.

Thank you!
Oct 07 2012
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 07 Oct 2012 21:58:49 +0200
"denizzzka" <4denizzz gmail.com> wrote:


 On Sunday, 7 October 2012 at 08:05:10 UTC, Thomas Koch wrote:

 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


 
 I could not register there. :( Who have the opportunity, please 
 add https://github.com/denizzzka/dpq2 to this wiki.
 
 Thank you!


You don't really register there, you just go here:

http://www.prowiki.org/wiki4d/wiki.cgi?action=editprefs&oldid=edit=DatabaseBindings

Enter something UpperCamelCased for username (it requires at least two
words for some odd reason, so "Foobar" won't work, but "FooBar" will),
hit "save preferences", and that's it.
Oct 07 2012
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
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.


=20
 https://github.com/denizzzka/dpq2
=20
 This is my personal project but it is not dead, and I am=20
 determined to see it through. At the moment, it is quite suitable=20
 to be used in simple situations. Compiles without warnings by dmd=20
 2.060, also it can be used with rdmd.
=20
 I really need users, comments, suggestions, bug reports and=20
 commits.


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

=46rom 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?

=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Oct 07 2012
next sibling parent "nazriel" <spam dzfl.pl> writes:
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
Oct 07 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
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.
Oct 07 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Oct 07 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-07 10:55, Russel Winder wrote:


 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?


They do.


 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?


ActiveRecord in Ruby on Rails uses several layers to handle all database 
related functionality. At the highest level there's a DSL which allows 
you to write the SQL queries mostly in Ruby. Another library, ARel, is 
used by ActiveRecord to generate the SQL code from the DSL. ARel handles 
all the differences among all the supported databases. ARel then passes 
the SQL code back to ActiveRecord where a lower layer handles the 
connections to the database and performs the actual query.

Then you have another layer that transforms the response into objects, 
sets up all the relations and so on.

-- 
/Jacob Carlborg
Oct 07 2012
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jacob Carlborg wrote:

 On 2012-10-07 10:55, Russel Winder wrote:


 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?


 They do.


 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?


 ActiveRecord in Ruby on Rails uses several layers to handle all database
 related functionality. At the highest level there's a DSL which allows
 you to write the SQL queries mostly in Ruby. Another library, ARel, is
 used by ActiveRecord to generate the SQL code from the DSL. ARel handles
 all the differences among all the supported databases. ARel then passes
 the SQL code back to ActiveRecord where a lower layer handles the
 connections to the database and performs the actual query.

 Then you have another layer that transforms the response into objects,
 sets up all the relations and so on.


Having distinct layers that don't know each other isn't always a good idea.

In my prostgres client one may specify field types at compile time. If I 
had divided the client into two separate layers it would return a 
Variant[] at first layer, then convert it to user specified tuple at the 
second. For example:

auto cmd = new SqlCommand(connection, "SELECT 1, 'abc'");
auto untypedRow = connection.executeRow(); // return DBRow!(Variant[])
auto typedRow = connection.executeRow!(int, string)(); // returns 
DBRow!(int, string);

Internally executeRow could always take a Variant[], then convert it to 
Tuple!(int, string), but it's suboptimal. Firstly, it must allocate an 
array of two Variants, then each Variant must be coerced to the 
corresponding type.

Instead, the client fills each of the tuple field directly as they come 
from the socket stream. With binary formatting all it has to do is 
swapEndian() on integers and floats (no parsing!). Of course, there's 
one allocation for the string, but if we change field type to char[4], 
there'll be no allocation at all.

Just wanted to illustrate that "layers" shouldn't always be separate.
Oct 07 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
 Having distinct layers that don't know each other isn't always a good idea.



 Just wanted to illustrate that "layers" shouldn't always be separate.


Actually I'm not sure how separate they are in ActiveRecord. I wanted to 
mostly point out that generating the SQL was done by a separate library.

-- 
/Jacob Carlborg
Oct 07 2012
prev sibling parent reply "Thiez" <thiezz gmail.com> writes:
On Sunday, 7 October 2012 at 12:39:35 UTC, Piotr Szturmaj wrote:

 In my prostgres client one may specify field types at compile 
 time. If I had divided the client into two separate layers it 
 would return a Variant[] at first layer, then convert it to 
 user specified tuple at the second. For example:

 auto cmd = new SqlCommand(connection, "SELECT 1, 'abc'");
 auto untypedRow = connection.executeRow(); // return 
 DBRow!(Variant[])
 auto typedRow = connection.executeRow!(int, string)(); // 
 returns DBRow!(int, string);

 Internally executeRow could always take a Variant[], then 
 convert it to Tuple!(int, string), but it's suboptimal. 
 Firstly, it must allocate an array of two Variants, then each 
 Variant must be coerced to the corresponding type.

 Just wanted to illustrate that "layers" shouldn't always be 
 separate.


It's not a very convincing illustration. In practice the overhead 
of those operations would likely be completely insignificant 
compared to performing the actual database query. Avoiding 
intermediate layers for optimality's sake seems like a bad case 
of premature optimization to me.
Oct 07 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Thiez wrote:

 On Sunday, 7 October 2012 at 12:39:35 UTC, Piotr Szturmaj wrote:

 In my prostgres client one may specify field types at compile time. If
 I had divided the client into two separate layers it would return a
 Variant[] at first layer, then convert it to user specified tuple at
 the second. For example:

 auto cmd = new SqlCommand(connection, "SELECT 1, 'abc'");
 auto untypedRow = connection.executeRow(); // return DBRow!(Variant[])
 auto typedRow = connection.executeRow!(int, string)(); // returns
 DBRow!(int, string);

 Internally executeRow could always take a Variant[], then convert it
 to Tuple!(int, string), but it's suboptimal. Firstly, it must allocate
 an array of two Variants, then each Variant must be coerced to the
 corresponding type.

 Just wanted to illustrate that "layers" shouldn't always be separate.


 It's not a very convincing illustration. In practice the overhead of
 those operations would likely be completely insignificant compared to
 performing the actual database query. Avoiding intermediate layers for
 optimality's sake seems like a bad case of premature optimization to me.


In my opinion everything counts. For thousands of rows x thousands of 
clients it certainly _should_ make a difference. And I wouldn't call it 
premature optimization, it's just _designed_ to be fast.
Oct 07 2012
prev sibling parent "Pragma Tix" <bizprac or.fr> writes:
On Sunday, 7 October 2012 at 09:07:39 UTC, Russel Winder wrote:


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


Good question. A wrong approach since we talk about DB support. 
Design the Interface first, would be the solution.
Then decide what you want. DAL, or Active Record. Then create a 
DSL, or LINQ or whatsoever.
Since you are a Python guy, the data access layer from web2py is 
simply excellent. But I doubt that D, respective phobos, will 
ever have more than rudimentary db support.
Oct 07 2012
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/07/2012 10:55 AM, Russel Winder wrote:

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


I don't have sufficient experience with SQL to be able to really make a 
judgement here, but is there a case for a std.sql or std.db that would provide
a 
uniform D interface to the arbitrary DB of choice?

Perhaps better as something in Deimos rather than Phobos, as I imagine it would 
bring in a bunch of external dependencies that the standard library shouldn't 
really have.  Am I right that there's something in Adam Ruppe's web modules 
that's heading in this direction?
Oct 07 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:

 Am I right that there's something in Adam Ruppe's web modules
 that's heading in this direction?


Yeah, though I'm a little biased toward mysql since that's what I 
use every day, so some of the stuff that should be in generic 
database.d are instead in mysql.d.

But my stuff indeed does sql strings which can then be passed to 
a Database class with pretty uniform interface, at least for 
basic queries, for some major dbs.

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff


Among the string manipulation stuff is class DataObject, which 
builds an UPDATE or INSERT query:

auto obj = new DataObject(db, "table_name");
obj.id = 10;
obj.name = "cool";
obj.commitChanges(); /* runs:
   if(db.query("select id from table_name where id = 10").empty)
       db.query("insert into table_name (id, name) values (10, 
'cool')");
    else
       db.query("UPDATE table_name set name = 'cool' where id = 
10");
*/

and also a build data object subclass from sql create table which 
kinda works, ugly mixin stuff.


And there's also a SelectBuilder which does basic concat stuff:

auto query = new SelectBuilder();
query.table = "something";
query.fields ~= "something.*";
query.wheres ~= "id > ?0";

db.query(query.toString(), 10);


expands into

select something.* from something where (id > 10);



Nothing super fancy but it works for me.
Oct 07 2012
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:

 On 10/07/2012 10:55 AM, Russel Winder wrote:

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


 I don't have sufficient experience with SQL to be able to 
 really make a judgement here, but is there a case for a std.sql 
 or std.db that would provide a uniform D interface to the 
 arbitrary DB of choice?

 Perhaps better as something in Deimos rather than Phobos, as I 
 imagine it would bring in a bunch of external dependencies that 
 the standard library shouldn't really have.  Am I right that 
 there's something in Adam Ruppe's web modules that's heading in 
 this direction?


There was a std.database proposal from Steve Teale, but it 
appears to have died.

http://prowiki.org/wiki4d/wiki.cgi?ReviewQueue

It could work like in other languages with OO support.

Everything is interface based and it is up to the respective 
driver to provide proper implementations. Those implementations 
can be provided either as static or dynamic libraries.

The important thing are interfaces, as such you're not bringing 
external dependencies. Unless the D community decides to have the 
drivers as part of the language (comes with batteries kind of 
thing).

--
Paulo
Oct 07 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/7/12 1:06 PM, Paulo Pinto wrote:

 The important thing are interfaces, as such you're not bringing external
 dependencies. Unless the D community decides to have the drivers as part
 of the language (comes with batteries kind of thing).


Yah, this is a chicken-and-egg kind of thing. In many languages it's the 
database providers who provide the drivers, but in order for that to 
happen the language must be widespread enough.

Andrei
Oct 07 2012
parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 7 October 2012 at 19:25:06 UTC, Andrei Alexandrescu 
wrote:

 On 10/7/12 1:06 PM, Paulo Pinto wrote:

 The important thing are interfaces, as such you're not 
 bringing external
 dependencies. Unless the D community decides to have the 
 drivers as part
 of the language (comes with batteries kind of thing).


 Yah, this is a chicken-and-egg kind of thing. In many languages 
 it's the database providers who provide the drivers, but in 
 order for that to happen the language must be widespread enough.

 Andrei


Probably because it's too big an endeavour for a single man. What 
we really want to define here is a good interface, not an 
implementation.

Implementations will come as needed by users.
Oct 15 2012
prev sibling next sibling parent reply "denizzzka" <4denizzz gmail.com> writes:
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
Wakeling wrote:

 On 10/07/2012 10:55 AM, Russel Winder wrote:

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


 I don't have sufficient experience with SQL to be able to 
 really make a judgement here, but is there a case for a std.sql 
 or std.db that would provide a uniform D interface to the 
 arbitrary DB of choice?


Each database engine has a unique distinguishing features that 
make this engine interesting. (for example, different 
implementations of transactions - SQL standard does not describe 
the SQL transactions precisely enough)

So, I do not know is it possible to make a universal interface. 
And why it may need in real life?
Oct 07 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-07 21:53, denizzzka wrote:


 So, I do not know is it possible to make a universal interface. And why
 it may need in real life?


ActiveRecord provides a universal interface for all databases. But you 
can't do all things with a fancy DSL. Sometimes you need to drop down to 
raw SQL if you want to execute some weird SQL function or similar.

-- 
/Jacob Carlborg
Oct 08 2012
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:

 On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
 Wakeling wrote:

 On 10/07/2012 10:55 AM, Russel Winder wrote:

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


 I don't have sufficient experience with SQL to be able to 
 really make a judgement here, but is there a case for a 
 std.sql or std.db that would provide a uniform D interface to 
 the arbitrary DB of choice?


 Each database engine has a unique distinguishing features that 
 make this engine interesting. (for example, different 
 implementations of transactions - SQL standard does not 
 describe the SQL transactions precisely enough)


There are plenty of existing interfaces to base D's design on, 
just a few of them:

Perl - DBI
Python - DB API
C, C++ - ODBC (there is an UNIX variant of it)
C++ - OLE DB (Although Windows specific)
Java - JDBC
.NET - Data Providers
Ruby - DBI
TCL - TDBC
Go - database package
Delphi - Data Access
Haskell - HaskellDB (HDBC)


 So, I do not know is it possible to make a universal interface. 
 And why it may need in real life?



At least in the enterprise world, we tend to write applications 
in a DB independent way.

One reason is to be able to deploy the applications without 
forcing the customers to invest in new DB engines, thus reaching 
a broader client base.

Sometimes inside the same organization different business units 
have different DB engines running (even different versions of the 
same DB).

Finally, to minimize costs when management decides for whatever 
reason, to change the DB licenses being used.

--
Paulo
Oct 08 2012
next sibling parent reply "denizzzka" <4denizzz gmail.com> writes:
On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:

 On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:

 On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
 Wakeling wrote:

 On 10/07/2012 10:55 AM, Russel Winder wrote:

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


 I don't have sufficient experience with SQL to be able to 
 really make a judgement here, but is there a case for a 
 std.sql or std.db that would provide a uniform D interface to 
 the arbitrary DB of choice?


 Each database engine has a unique distinguishing features that 
 make this engine interesting. (for example, different 
 implementations of transactions - SQL standard does not 
 describe the SQL transactions precisely enough)


 There are plenty of existing interfaces to base D's design on, 
 just a few of them:

 Perl - DBI
 Python - DB API
 C, C++ - ODBC (there is an UNIX variant of it)
 C++ - OLE DB (Although Windows specific)
 Java - JDBC
 .NET - Data Providers
 Ruby - DBI
 TCL - TDBC
 Go - database package
 Delphi - Data Access
 Haskell - HaskellDB (HDBC)


 So, I do not know is it possible to make a universal 
 interface. And why it may need in real life?



 At least in the enterprise world, we tend to write applications 
 in a DB independent way.

 One reason is to be able to deploy the applications without 
 forcing the customers to invest in new DB engines, thus 
 reaching a broader client base.

 Sometimes inside the same organization different business units 
 have different DB engines running (even different versions of 
 the same DB).

 Finally, to minimize costs when management decides for whatever 
 reason, to change the DB licenses being used.

 --
 Paulo


For this to work you need to implement an independent way to 
create queries that would work on all database engines the same 
way. I believe that this problem is in principle much more 
complicated than it would have been implemented interfaces to 
databases in separate libs.
Oct 08 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 8 October 2012 at 10:26:35 UTC, denizzzka wrote:

 On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:

 On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:

 On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
 Wakeling wrote:

 On 10/07/2012 10:55 AM, Russel Winder wrote:

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


 I don't have sufficient experience with SQL to be able to 
 really make a judgement here, but is there a case for a 
 std.sql or std.db that would provide a uniform D interface 
 to the arbitrary DB of choice?


 Each database engine has a unique distinguishing features 
 that make this engine interesting. (for example, different 
 implementations of transactions - SQL standard does not 
 describe the SQL transactions precisely enough)


 There are plenty of existing interfaces to base D's design on, 
 just a few of them:

 Perl - DBI
 Python - DB API
 C, C++ - ODBC (there is an UNIX variant of it)
 C++ - OLE DB (Although Windows specific)
 Java - JDBC
 .NET - Data Providers
 Ruby - DBI
 TCL - TDBC
 Go - database package
 Delphi - Data Access
 Haskell - HaskellDB (HDBC)


 So, I do not know is it possible to make a universal 
 interface. And why it may need in real life?



 At least in the enterprise world, we tend to write 
 applications in a DB independent way.

 One reason is to be able to deploy the applications without 
 forcing the customers to invest in new DB engines, thus 
 reaching a broader client base.

 Sometimes inside the same organization different business 
 units have different DB engines running (even different 
 versions of the same DB).

 Finally, to minimize costs when management decides for 
 whatever reason, to change the DB licenses being used.

 --
 Paulo


 For this to work you need to implement an independent way to 
 create queries that would work on all database engines the same 
 way. I believe that this problem is in principle much more 
 complicated than it would have been implemented interfaces to 
 databases in separate libs.


Sure. That is why on top of a DB driver layer, usually you have 
some kind of SQL adaptation layer.

On the TCL/C abstraction layer we implemented for a product 
during the 1999-2001 timeframe, we used standard SQL '92 for all 
data queries, regardless of hand-written or generated from our 
TCL ORM.

Then there was a translation layer that transformed SQL '92 into 
DB specific SQL, before giving it to the corresponding driver.

The only two parts of the application that had DB specific code 
were the SQL transformation layer, and the .so/.dll with the DB 
specific driver.

With the added benefit that any DB fully SQL '92 compliant did 
not need any adaptations in the transformation layer.


--
Paulo
Oct 08 2012
prev sibling next sibling parent "BLM768" <blm768 gmail.com> writes:
I've been thinking about writing an interface inspired by 
ActiveRecord. It would probably be relatively simple and 
lightweight, but it should be enough for simple REST 
applications, and the interface would (hopefully) be extremely 
nice to use.
Of course, with all the other projects I want to do, I'm not sure 
how long this will live :).
Oct 08 2012
prev sibling parent reply "Mark Lamberton" <mark penguinsystems.com.au> writes:
As a D newbie, Thomas' post is quite timely.  I've collected all 
the books on offer and scanned the 'net for anything D related.  
Like Thomas, I was starting to feel that D was going nowhere 
fast.  Some of the comments here have helped dispel this 
impression, but it's true to say that from an outsider's 
perspective the situation is confusing.  I'm still not sure why 
(for example) Tango exists and what is its status relative to the 
D ecosystem.

Per the discussion on SQL, database access is a subject close to 
my heart.  Posters here may be interested in looking at OpenDBX - 
http://www.linuxnetworks.de/doc/index.php/OpenDBX - an open 
source, lightweight, EXTENSIBLE database access library with C 
and CPP interfaces.

I've used OpenDBX with Oracle, Firebird, and MSSQL in commercial 
applications and from what little I know (so far) about D, would 
seem to be at least a viable starting point (maybe even a viable 
end point for some...) for a 'universal' database access facility.

Mark

On Monday, 8 October 2012 at 07:35:13 UTC, Paulo Pinto wrote:

 On Sunday, 7 October 2012 at 20:05:22 UTC, denizzzka wrote:

 On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton 
 Wakeling wrote:

 On 10/07/2012 10:55 AM, Russel Winder wrote:

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


 I don't have sufficient experience with SQL to be able to 
 really make a judgement here, but is there a case for a 
 std.sql or std.db that would provide a uniform D interface to 
 the arbitrary DB of choice?


 Each database engine has a unique distinguishing features that 
 make this engine interesting. (for example, different 
 implementations of transactions - SQL standard does not 
 describe the SQL transactions precisely enough)


 There are plenty of existing interfaces to base D's design on, 
 just a few of them:

 Perl - DBI
 Python - DB API
 C, C++ - ODBC (there is an UNIX variant of it)
 C++ - OLE DB (Although Windows specific)
 Java - JDBC
 .NET - Data Providers
 Ruby - DBI
 TCL - TDBC
 Go - database package
 Delphi - Data Access
 Haskell - HaskellDB (HDBC)


 So, I do not know is it possible to make a universal 
 interface. And why it may need in real life?



 At least in the enterprise world, we tend to write applications 
 in a DB independent way.

 One reason is to be able to deploy the applications without 
 forcing the customers to invest in new DB engines, thus 
 reaching a broader client base.

 Sometimes inside the same organization different business units 
 have different DB engines running (even different versions of 
 the same DB).

 Finally, to minimize costs when management decides for whatever 
 reason, to change the DB licenses being used.

 --
 Paulo
Oct 09 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, October 10, 2012 00:02:50 Mark Lamberton wrote:

 I'm still not sure why
 (for example) Tango exists and what is its status relative to the
 D ecosystem.


It's a historical thing. Phobos in D1 sucked (probably because Walter was 
focused on the compiler and I don't think that there was as much community 
participation in Phobos at the time). So, folks wrote their own libraries. 
Tango was one of these and became the largest 3rd party D library. 
Unfortunately in D1, the runtime was not separate from Phobos, so when the 
Tango folks decided to do their own runtime, it made Phobos and Tango 
incompatible, forcing people to choose, and because Tango was better, they 
almost always chose Tango. This made it so that some people considered Tango 
to be D's standard libray even though this was never technically the case (it 
just got used instead of D's standard library).

For D2, Phobos is much better and has much stronger community support, so 
Tango isn't as necessary. And it wasn't until fairly recently that anyone 
ported Tango to D2 (and it's not even the official Tango devs that did it). So, 
Tango hasn't even been an option for D2 until recently, and I think that for 
the most part, the only people who use it are those who used D1 and want to 
continue to use Tango. So, I suspect that while it does get used for D2, there 
probably aren't very many people use it.

However, since the runtime has been split out from Phobos in D2 (in fact, 
druntime was ported from Tango by one of the Tango developers who continues to 
work on druntime - Sean Kelly), it's possible to mix Phobos and Tango in D2, 
making it so that there's no need to choose exclusively one or the other. But 
they _do_ have very different design philosophies, so you probably wouldn't mix 
them heavily.

The main thing to be aware of about Tango at this point (beyond the basic 
history of why it's there, if you care) is the fact that it uses a more 
restrictive license than Phobos, so you can't port code from Tango to Phobos 
without the permission of the authors of that code, and it's generally advised 
that anyone working on Phobos not look at Tango just to avoid the possibility 
of anyone accusing them of stealing code (not to say that that would happen or 
that anyone would be necessarily be accused of that - but we want to avoid any 
possible misunderstandings).

In the long run, I expect that most of this will be forgotten. Either Tango 
will disappear (which is highly likely unless it gets higher adoption in D2), 
or it will just become another popular 3rd party library with cool stuff that 
you can use, and its status as pseudo-standard library of D1 will be mostly 
forgotten. But it caused enough confusion and strife in the past that many who 
have heard of D but don't know much about it end up asking whether D still has 
two standard libraries and whether any major divisions in the community like 
that still exist.

- Jonathan M Davis
Oct 09 2012
parent "Mark Lamberton" <mark penguinsystems.com.au> writes:
Many thanks Jonathan, that greatly clarifies the situation...
Oct 09 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 07 Oct 2012 18:54:17 +0200
Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:


 On 10/07/2012 10:55 AM, Russel Winder wrote:

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


 
 I don't have sufficient experience with SQL to be able to really make
 a judgement here, but is there a case for a std.sql or std.db that
 would provide a uniform D interface to the arbitrary DB of choice?
 


Probably, yes. But someone needs to build such a lib first and then
propose it as a std.db candidate.


 Perhaps better as something in Deimos rather than Phobos, as I
 imagine it would bring in a bunch of external dependencies that the
 standard library shouldn't really have.


Not necessarily: Steve Teale's "mysqln" is a native D MySQL driver that
connects to the DB server directly and bypasses MySQL's official client
lib entirely. Teale has inexplicably disappeared off the face of the
internet, but Vibe.d has adapted the lib for use with Vibe.d, and
this guy has also made some updates:
https://github.com/simendsjo/mysqln/tree/misc-cleanups

I'm using that with Vibe.d and it seems to be working pretty well.

(I'm not sure if the simendsjo version or the Vibe.d version is more
up-to-date, though.)
Oct 07 2012
parent "simendsjo" <simendsjo gmail.com> writes:
On Sunday, 7 October 2012 at 22:08:45 UTC, Nick Sabalausky wrote:

 Not necessarily: Steve Teale's "mysqln" is a native D MySQL 
 driver that
 connects to the DB server directly and bypasses MySQL's 
 official client
 lib entirely. Teale has inexplicably disappeared off the face 
 of the
 internet, but Vibe.d has adapted the lib for use with Vibe.d, 
 and
 this guy has also made some updates:
 https://github.com/simendsjo/mysqln/tree/misc-cleanups

 I'm using that with Vibe.d and it seems to be working pretty 
 well.

 (I'm not sure if the simendsjo version or the Vibe.d version is 
 more
 up-to-date, though.)


The important updates (compile on x64) is incorporated in vibe.
The other updates in my repo is just code cleanups, but it's a 
WIP, and I don't think I'll finish it unless I need to use 
MySQL+D.
Oct 08 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-07 18:54, Joseph Rushton Wakeling wrote:

 On 10/07/2012 10:55 AM, Russel Winder wrote:

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


 I don't have sufficient experience with SQL to be able to really make a
 judgement here, but is there a case for a std.sql or std.db that would
 provide a uniform D interface to the arbitrary DB of choice?


I think that a uniform database interface with support for different 
database drivers, a DSL, an ORM wrapper and a couple of database drivers 
would be too much to have in Phobos.

-- 
/Jacob Carlborg
Oct 08 2012