Thorsten Ottosen wrote:
Rene Rivera wrote:
Sure... But we could use that same argument to propose that we write C++ programs by writing an abstraction on top of C++ compilers in Python so that we can remove the incompatibilities in the various C++ implementations.
I guess you could do that. Like C++, porting can be a major problem.
Note, however, that is not an argument against having portible SQL DSL.
True :-) But it's an argument that a portable SQL DSL is not a great advantage.
Having had the displeasure of dealing with PL/SQL there is one serious drawback to the language embedded approach, it ties ones to the capabilities of the abstraction.
Right. The SQL library should provide a backdoor so you can still use string queries if you need to be non-portable or cutting egde etc.
I some of our company tools, we support multiple server backends: at least oracle, mssql and mysql. I'm surpised just how diffucult it is to write portable SQL (even for very very simple queries).
If you want to use different functions, there's a pretty good change they are different on different systems. I have end up writing my own abstractionlayer in php to compensate.
That drives into what I think is the core problem I have with an SQL DSL. It doesn't provide an abstraction that has compelling advantages, other than syntactic sugar. What I would find way more useful would be an abstraction that removes the SQL language itself, i.e. a relational database library. That would have some advantages: * Better coherence with C++ data types. * Possibility to support non-SQL relational databases. * Make it easier to construct object/relational translation abstractions. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo