In that case, if you are already tied to Oracle why not just use their tools rather than something like this? Oracle's tools will hopefully work in lock-step with their releases and there should be no support lag.
This looks neat, but why add another layer of lock-in to yet another vendor with the uncertainty that entails?
I thought that was a clear and honest question.
The remainder, the "piping" syntax, is pretty easy to implement (Takes about 30-40 lines of ruby on top of Arel, speaking from experience).
So then, is this just a matter of wrapping a library in a web page and calling it SAAS? Or am I just totally missing the point?
on Oracle:
http://docs.oracle.com/cd/E11882_01/server.112/e10592/statem...
on SQL Server: http://msdn.microsoft.com/en-us/library/ms175972.aspx
As useful as SQL is in so many ways, as a piece of language design it's a total bloody travesty. I'm delighted to see any movement towards a query language that keeps the nice declarative dataflow property that complex SQL queries can have, but provides better means of abstraction, and the possibility to write more intention-revealing code.
In Oracle's implementation WITH is more like a VIEW.
Edit: BTW, this is not an accident or oversight on the part of Postgres. This is in the spec!
Currently, all ORMs that I've seen try to mimic the declarative SQL syntax, which doesn't always look pretty.
Layers are just hiding things, and when you hide it, bad things happen.
But I don't have any real world experience writing software that actually ends up being used with different databases.
I may use all these abstractions, but really we just use Postgres or MySQL in the end.
In 99% of cases you don't need to write SQL in order to deliver business functionality. Just like we don't need to write low level machine code in 99% of cases.
One benefit a layer can add is the ability to optimize post compilation. Most of the fancy pants Hadoop libraries are doing this one way or another.
I did quite a bit of SQL in my last job, and I can't think of a single case where I wish I had a pipeline operator. If I wanted to do something similar to the example on your homepage the simplest way is just to use subqueries.
Here's a rewrite of your query in T-SQL...
------------------------------------------------------
SELECT EMP.Country, EMP.LastName, EMP.FirstName, OD.OrderID, ORD.ShippedDate, OD.SaleAmount
FROM (SELECT TOP 10 T1.OrderID, T1.ORDSUM FROM (SELECT OrderID, SUM(UnitPrice * Quantity * (1 - Discount)) AS SaleAmount FROM "Order Details" GROUP BY OrderID) AS T1 ORDER BY T1.ORDSUM DESC) AS OD
LEFT JOIN Orders AS ORD ON OD.OrderID = ORD.OrderID
LEFT JOIN Employees AS EMP ON ORD.EmployeeID = EMP.EmployeeID
------------------------------------------------------
That's fairly concise, and was quick to bash out. I'd wager it could be made even smaller if I used LINQ instead of SQL. Perhaps your method has some advantages in other types of query? How do you see it?
So when your Oracle rep calls and says "bad news, your license costs went up by 150% this year. What are you going to do, switch databases? Hahahaha!" you can reply "well you know, we can actually flip a switch and run on Postgres now. We'll get back to you."
Yeah, it never quite works out that easily in practice. But by using products from a selection of vendors that support other ecosystems than just one, you're reducing your vendor lock-in.
And your risk of finding that all the code you've created using a proprietary tool that runs on top of a proprietary platform owned by another entity is greater than just using the tools provided by the platform vendor who controls "the stack" of software below any other vendor providing an add-on.
Basically, (in this case) Oracle can break 3rd party add-on tools and programs anytime they want or make them operate in a suboptimal way by changing their product below. Oracle, Microsoft and other platform vendors have repeated done this in the past.
So buying cloud based or closed source tools that run on top of other closed source products controlled by another entity is a poor bet.
To an application developer, this looks like nothing more than a code generator. Generated code is not source code and it should not be edited directly. Rather, you should change the generated code's source code and then re-generate it. While it may not be a layer between the app and the database, it's definitely an extra step in your build chain.
You'd be foolish to tie your application's build process to a cloud service that may disappear without warning. No sane developer would do such a thing. I don't see how this is any use to developers in any form other than a standalone compiler.