Here it goes :) - JIRA: https://issues.apache.org/jira/browse/CALCITE-1527 - PR: https://github.com/apache/calcite/pull/334
Seems bit more involving than expected. In addition to the Sql implementation, it requires changes on the SQL parsing side as well as the handling for the non-ResultSet responses. There are still some open questions like the handling of source expressions for UPDATE with sub-query. On 30 November 2016 at 23:15, Julian Hyde <[email protected]> wrote: > “Unfortunate” is one word for it. If Calcite were complete it would be > considerably more expensive. :) > > You figured out how to implement OVER, so I’d look in a similar place for > DML. > > Julian > > > On Nov 30, 2016, at 1:42 PM, Christian Tzolov <[email protected]> > wrote: > > > > Thanks Julian, this is unfortunate as it undermines the idea of having > jdbc > > wrapper in front of HAWQ. > > > > I will log Jira tickets. How difficult do you think would be to provide > DML > > support for the JDBC adapter? If i am to take a look at it where should > > look first? > > > > Cheers, > > Christian > > > > On 30 November 2016 at 19:23, Julian Hyde <[email protected]> wrote: > > > >> It’s a missing feature. The JDBC adapter does not currently do DML. Can > >> you please log a JIRA case to track. > >> > >> Julian > >> > >> > >>> On Nov 30, 2016, at 7:56 AM, Christian Tzolov <[email protected]> > >> wrote: > >>> > >>> A test to reproduce the problem: > >>> > >>> @Test public void testJdbcAdapterInsert() { > >>> > >>> CalciteAssert.model(JdbcTest.FOODMART_MODEL) > >>> .enable(CalciteAssert.DB == POSTGRESQL) > >>> .query("INSERT INTO \"foodmart\".\"expense_fact\"(\n" + > >>> " \"store_id\", \"account_id\", \"exp_date\", > >>> \"time_id\"," + > >>> " \"category_id\", \"currency_id\", > >> \"amount\")\n" + > >>> " VALUES (666, 666, TIMESTAMP '1997-01-01 00:00:00', 666, > >> '666', > >>> 666, 666)") > >>> .runs(); > >>> } > >>> > >>> Run with -Dcalcite.test.db=postgresql > >>> > >>> > >>> On 30 November 2016 at 15:37, Christian Tzolov <[email protected]> > >> wrote: > >>> > >>>> Hi, > >>>> > >>>> The insert statement via the JdbcAdapter fails with > >>>> "rel#78:Subset#1.ENUMERABLE.[]] could not be implemented;" > >>>> > >>>> I'm testing SQL inserts using the foodmart dataset and postgresql > >>>> configured as a backend. > >>>> > >>>> Following insert works find on postgresql but fails when run through > the > >>>> jdbc adapter: > >>>> > >>>> "INSERT INTO "foodmart"."expense_fact"("store_id", "account_id", > >>>> "exp_date", "time_id", "category_id", "currency_id", "amount") VALUES > >> (666, > >>>> 666, TIMESTAMP '1997-01-01 00:00:00', 666, '666', 666, 666); > >>>> > >>>> The jdbc-adapter error: > >>>> > >>>> Error: Error while executing SQL "INSERT INTO > >> "foodmart"."expense_fact"("store_id", > >>>> "account_id", "exp_date", "time_id", "category_id", "currency_id", > >>>> "amount") VALUES (666, 666, TIMESTAMP '1997-01-01 00:00:00', 666, > '666', > >>>> 666, 666)": Node [rel#78:Subset#1.ENUMERABLE.[]] could not be > >>>> implemented; planner state: > >>>> > >>>> It looks like error occurs before the JdbcTableModificationRule# > covert > >> is > >>>> reached. > >>>> > >>>> Is this a limitation or bug? > >>>> > >>>> Thanks, > >>>> Christian > >>>> > >>> > >> > >> > > -- Christian Tzolov <http://www.linkedin.com/in/tzolov> | Solution Architect, EMEA Practice Team | Pivotal <http://pivotal.io/> [email protected]|+31610285517
