Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
Re: SQL working [ was Re: The sorry state of the D stack? ]
Many thanks Jonathan, that greatly clarifies the situation...
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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 :).
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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?
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
Re: SQL working [ was Re: The sorry state of the D stack? ]
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
Re: SQL working [ was Re: The sorry state of the D stack? ]
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?
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sun, 07 Oct 2012 18:54:17 +0200 Joseph Rushton Wakeling joseph.wakel...@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.)
Re: SQL working [ was Re: The sorry state of the D stack? ]
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.
