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


October 09, 2012
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


October 10, 2012
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
October 10, 2012
Many thanks Jonathan, that greatly clarifies the situation...
October 16, 2012
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.
1 2 3 4 5
Next ›   Last »