October 07, 2012
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.
October 07, 2012
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


October 07, 2012
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?
October 07, 2012
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!
October 07, 2012
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.

October 07, 2012
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.

October 07, 2012
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.)

October 08, 2012
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.
October 08, 2012
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
October 08, 2012
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