Thanks for the feedback. I will review the comments in the ticket Source expressions with sub-query are hard. Maybe you can represent them > using RexSubQuery; and maybe RelDecorrelator can help; I’m not sure. In any > case, I think you should defer them to another case. >
Indeed it will be nice if we can defer the update-sub-query into separate ticket as it seem it would requires more digging. Shall i submit a new dedicated ticket for this or shall we postpone it for after committing current work? In this case, it seems that you have implemented INSERT … VALUES but not > INSERT … SELECT. Can you clarify whether you intend to do the latter? > Yes I have implemented already the INSERT ... SELECT along with support for INSERT VALUES (ROW1, ROW2 ..). Will commit it in the next hour. Cheers, Christian > Julian > > > > On Dec 5, 2016, at 2:21 AM, Christian Tzolov <[email protected]> wrote: > > > > 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 > > -- Christian Tzolov <http://www.linkedin.com/in/tzolov> | Solution Architect, EMEA Practice Team | Pivotal <http://pivotal.io/> [email protected]|+31610285517
