[jira] [Created] (CALCITE-1672) schema name alias doesn't work in INSERT INTO
Lei Wei created CALCITE-1672:
Summary: schema name alias doesn't work in INSERT INTO
Key: CALCITE-1672
URL: https://issues.apache.org/jira/browse/CALCITE-1672
Project: Calcite
Issue Type: Bug
Reporter: Lei Wei
Assignee: Julian Hyde
Priority: Minor
Hi, I setup calcite connecting with posgresql db, and starting avatica to take
jdbc connectivities. I used alias on the schemas that added to the root schema.
I'm able to run select statements using alias schema, but it doesn't work in
INSERT and UPDATE.
Exception: ExampleExceptionFormatter: exception message was: Error -1 (0) :
Error while executing SQL "update LEI_DEMO_SANDBOX2.test_table set
no='111'": Remote driver error: RuntimeException: while executing SQL
[UPDATE "LEI_DEMO_SANDBOX2"."test_table" SET "no" = '111'] ->
PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist
ExampleExceptionFormatter: exception message was: Error -1 (0) : Error
while executing SQL "insert into LEI_DEMO_SANDBOX2.test_table(no) values
('111')": Remote driver error: RuntimeException: while executing SQL
[INSERT INTO "LEI_DEMO_SANDBOX2"."test_table" ("no")
VALUES ('111')] -> PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does
not exist
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1672) schema name alias doesn't work in INSERT INTO
[
https://issues.apache.org/jira/browse/CALCITE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899838#comment-15899838
]
Julian Hyde commented on CALCITE-1672:
--
Well, what is the schema name in PostgreSQL? What SQL should Calcite be
generating?
> schema name alias doesn't work in INSERT INTO
> -
>
> Key: CALCITE-1672
> URL: https://issues.apache.org/jira/browse/CALCITE-1672
> Project: Calcite
> Issue Type: Bug
>Reporter: Lei Wei
>Assignee: Julian Hyde
>Priority: Minor
>
> Hi, I setup calcite connecting with posgresql db, and starting avatica to
> take jdbc connectivities. I used alias on the schemas that added to the root
> schema. I'm able to run select statements using alias schema, but it doesn't
> work in INSERT and UPDATE.
> Exception: ExampleExceptionFormatter: exception message was: Error -1 (0)
> : Error while executing SQL "update LEI_DEMO_SANDBOX2.test_table set
> no='111'": Remote driver error: RuntimeException: while executing SQL
> [UPDATE "LEI_DEMO_SANDBOX2"."test_table" SET "no" = '111'] ->
> PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist
> ExampleExceptionFormatter: exception message was: Error -1 (0) : Error
> while executing SQL "insert into LEI_DEMO_SANDBOX2.test_table(no) values
> ('111')": Remote driver error: RuntimeException: while executing SQL
> [INSERT INTO "LEI_DEMO_SANDBOX2"."test_table" ("no")
> VALUES ('111')] -> PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does
> not exist
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1673) Order by or group by on timestamp column throwing exception
Gangadhar created CALCITE-1673: -- Summary: Order by or group by on timestamp column throwing exception Key: CALCITE-1673 URL: https://issues.apache.org/jira/browse/CALCITE-1673 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.11.0 Reporter: Gangadhar Assignee: Julian Hyde Getting below error while executing the 'order by' or 'group by' queries with timestamp data type column. Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column 76: No applicable constructor/method found for actual parameters "java.lang.Object"; candidates are: "public static java.sql.Timestamp org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)", "public static java.sql.Timestamp org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)" I could able to reproduce this problem in CsvTests. Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you will see test failing with exception. Root cause and fix: The fix for this to overload the SqlFunctions.internalToTimestamp() to accept the timestamp or object and return timestamp value. I tested and it's working Stack trace at org.apache.calcite.avatica.Helper.wrap(Helper.java:37) at org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108) at org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233) at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303) at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200) at org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761) at org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617) at org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587) at org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214) at org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595) at org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615) at org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148) ... 29 more Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column 76: No applicable constructor/method found for actual parameters "java.lang.Object"; candidates are: "public static java.sql.Timestamp org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)", "public static java.sql.Timestamp org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)" at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092) at org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506) at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376) at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280) at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850) at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183) at org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251) at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974) at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:3278) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CALCITE-1673) Order by or group by on timestamp column throwing exception
[ https://issues.apache.org/jira/browse/CALCITE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1673: - Labels: (was: orderby timestamp) > Order by or group by on timestamp column throwing exception > --- > > Key: CALCITE-1673 > URL: https://issues.apache.org/jira/browse/CALCITE-1673 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.11.0 >Reporter: Gangadhar Kairi >Assignee: Julian Hyde > Original Estimate: 2h > Remaining Estimate: 2h > > Getting below error while executing the 'order by' or 'group by' queries with > timestamp data type column. > Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column > 76: No applicable constructor/method found for actual parameters > "java.lang.Object"; candidates are: "public static java.sql.Timestamp > org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)", > "public static java.sql.Timestamp > org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)" > I could able to reproduce this problem in CsvTests. > Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you > will see test failing with exception. > Root cause and fix: > The fix for this to overload the SqlFunctions.internalToTimestamp() to accept > the timestamp or object and return timestamp value. I tested and it's working > Stack trace > at org.apache.calcite.avatica.Helper.wrap(Helper.java:37) > at > org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108) > at > org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233) > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303) > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148) > ... 29 more > Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column > 76: No applicable constructor/method found for actual parameters > "java.lang.Object"; candidates are: "public static java.sql.Timestamp > org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)", > "public static java.sql.Timestamp > org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)" > at > org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092) > at > org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506) > at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376) > at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280) > at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850) > at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183) > at > org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251) > at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974) > at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:3278) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1673) Order by or group by on timestamp column throwing exception
[
https://issues.apache.org/jira/browse/CALCITE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899883#comment-15899883
]
Gangadhar Kairi commented on CALCITE-1673:
--
Hi Julian,
See if this fix is useful. new method in SqlFunctions.
public static java.sql.Timestamp internalToTimestamp(Object v) {
if (v == null ) {
return null;
} else if ( v instanceof Timestamp ) {
return (Timestamp)v;
}
throw new RuntimeException(" Invalid type, cannot convert " + v + " to " +
Timestamp.class.getName());
}
Please let me know if you are okay with this fix, so that shall create patch
and pull request.
> Order by or group by on timestamp column throwing exception
> ---
>
> Key: CALCITE-1673
> URL: https://issues.apache.org/jira/browse/CALCITE-1673
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
>Reporter: Gangadhar Kairi
>Assignee: Julian Hyde
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Getting below error while executing the 'order by' or 'group by' queries with
> timestamp data type column.
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> I could able to reproduce this problem in CsvTests.
> Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you
> will see test failing with exception.
> Root cause and fix:
> The fix for this to overload the SqlFunctions.internalToTimestamp() to accept
> the timestamp or object and return timestamp value. I tested and it's working
> Stack trace
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148)
> ... 29 more
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850)
> at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183)
> at
> org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:3278)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1673) Order by or group by on timestamp column throwing exception
[
https://issues.apache.org/jira/browse/CALCITE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899886#comment-15899886
]
Julian Hyde commented on CALCITE-1673:
--
CALCITE-1054 and CALCITE-1427 are similar, and may be related.
But, like CALCITE-1569, I'm not sure the answer is to convert to
java.sql.Timestamp. Internally we should be using {{long}} (or
{{java.lang.Long}}) values for timestamps.
> Order by or group by on timestamp column throwing exception
> ---
>
> Key: CALCITE-1673
> URL: https://issues.apache.org/jira/browse/CALCITE-1673
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
>Reporter: Gangadhar Kairi
>Assignee: Julian Hyde
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Getting below error while executing the 'order by' or 'group by' queries with
> timestamp data type column.
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> I could able to reproduce this problem in CsvTests.
> Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you
> will see test failing with exception.
> Root cause and fix:
> The fix for this to overload the SqlFunctions.internalToTimestamp() to accept
> the timestamp or object and return timestamp value. I tested and it's working
> Stack trace
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148)
> ... 29 more
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850)
> at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183)
> at
> org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:3278)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1673) Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException
[ https://issues.apache.org/jira/browse/CALCITE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1673: - Summary: Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException (was: Order by or group by on timestamp column throwing exception) > Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException > --- > > Key: CALCITE-1673 > URL: https://issues.apache.org/jira/browse/CALCITE-1673 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.11.0 >Reporter: Gangadhar Kairi >Assignee: Julian Hyde > Original Estimate: 2h > Remaining Estimate: 2h > > Getting below error while executing the 'order by' or 'group by' queries with > timestamp data type column. > Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column > 76: No applicable constructor/method found for actual parameters > "java.lang.Object"; candidates are: "public static java.sql.Timestamp > org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)", > "public static java.sql.Timestamp > org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)" > I could able to reproduce this problem in CsvTests. > Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you > will see test failing with exception. > Root cause and fix: > The fix for this to overload the SqlFunctions.internalToTimestamp() to accept > the timestamp or object and return timestamp value. I tested and it's working > Stack trace > at org.apache.calcite.avatica.Helper.wrap(Helper.java:37) > at > org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108) > at > org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233) > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303) > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148) > ... 29 more > Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column > 76: No applicable constructor/method found for actual parameters > "java.lang.Object"; candidates are: "public static java.sql.Timestamp > org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)", > "public static java.sql.Timestamp > org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)" > at > org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092) > at > org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506) > at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376) > at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280) > at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850) > at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183) > at > org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251) > at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974) > at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:3278) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CALCITE-1673) Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException
[
https://issues.apache.org/jira/browse/CALCITE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1673:
-
Description:
Getting below error while executing the 'order by' or 'group by' queries with
timestamp data type column.
{noformat}
Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column 76:
No applicable constructor/method found for actual parameters
"java.lang.Object"; candidates are: "public static java.sql.Timestamp
org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
"public static java.sql.Timestamp
org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
{noformat}
I could able to reproduce this problem in CsvTests.
Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you will
see test failing with exception.
Root cause and fix:
The fix for this to overload the {{SqlFunctions.internalToTimestamp()}} to
accept the timestamp or object and return timestamp value. I tested and it's
working
{noformat}
Stack trace
at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148)
... 29 more
Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column 76:
No applicable constructor/method found for actual parameters
"java.lang.Object"; candidates are: "public static java.sql.Timestamp
org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
"public static java.sql.Timestamp
org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
at
org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092)
at
org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376)
at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850)
at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183)
at
org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251)
at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974)
at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:3278)
{noformat}
was:
Getting below error while executing the 'order by' or 'group by' queries with
timestamp data type column.
Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column 76:
No applicable constructor/method found for actual parameters
"java.lang.Object"; candidates are: "public static java.sql.Timestamp
org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
"public static java.sql.Timestamp
org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
I could able to reproduce this problem in CsvTests.
Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you will
see test failing with exception.
Root cause and fix:
The fix for this to overload the SqlFunctions.internalToTimestamp() to accept
the timestamp or object and return timestamp value. I tested and it's working
Stack trace
at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617)
at
org.apache.calcite.prepare.CalcitePrepareImpl.p
[jira] [Comment Edited] (CALCITE-1673) Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException
[
https://issues.apache.org/jira/browse/CALCITE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899883#comment-15899883
]
Julian Hyde edited comment on CALCITE-1673 at 3/7/17 6:25 PM:
--
Hi Julian,
See if this fix is useful. new method in SqlFunctions.
{code}
public static java.sql.Timestamp internalToTimestamp(Object v) {
if (v == null ) {
return null;
} else if ( v instanceof Timestamp ) {
return (Timestamp)v;
}
throw new RuntimeException(" Invalid type, cannot convert " + v + " to " +
Timestamp.class.getName());
}
{code}
Please let me know if you are okay with this fix, so that shall create patch
and pull request.
was (Author: gkairi):
Hi Julian,
See if this fix is useful. new method in SqlFunctions.
public static java.sql.Timestamp internalToTimestamp(Object v) {
if (v == null ) {
return null;
} else if ( v instanceof Timestamp ) {
return (Timestamp)v;
}
throw new RuntimeException(" Invalid type, cannot convert " + v + " to " +
Timestamp.class.getName());
}
Please let me know if you are okay with this fix, so that shall create patch
and pull request.
> Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException
> ---
>
> Key: CALCITE-1673
> URL: https://issues.apache.org/jira/browse/CALCITE-1673
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
>Reporter: Gangadhar Kairi
>Assignee: Julian Hyde
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Getting below error while executing the 'order by' or 'group by' queries with
> timestamp data type column.
> {noformat}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> {noformat}
> I could able to reproduce this problem in CsvTests.
> Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you
> will see test failing with exception.
> Root cause and fix:
> The fix for this to overload the {{SqlFunctions.internalToTimestamp()}} to
> accept the timestamp or object and return timestamp value. I tested and it's
> working
> {noformat}
> Stack trace
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148)
> ... 29 more
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850)
> at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183)
> at
> org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974)
> at org.codehaus.janino.Uni
[jira] [Commented] (CALCITE-1673) Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException
[
https://issues.apache.org/jira/browse/CALCITE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899895#comment-15899895
]
Julian Hyde commented on CALCITE-1673:
--
[~Gkairi], I'm not sure that the extra function is the right solution. The
compiler seems to think that the value is "internal" format (i.e. {{long}}) but
apparently it is a {{java.sql.Timestamp}}. So your fix might be a band-aid for
a deeper problem. But please submit a pull request with your fix, including
test cases for both GROUP BY and ORDER BY, and we'll see if we can improve it.
> Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException
> ---
>
> Key: CALCITE-1673
> URL: https://issues.apache.org/jira/browse/CALCITE-1673
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
>Reporter: Gangadhar Kairi
>Assignee: Julian Hyde
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Getting below error while executing the 'order by' or 'group by' queries with
> timestamp data type column.
> {noformat}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> {noformat}
> I could able to reproduce this problem in CsvTests.
> Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you
> will see test failing with exception.
> Root cause and fix:
> The fix for this to overload the {{SqlFunctions.internalToTimestamp()}} to
> accept the timestamp or object and return timestamp value. I tested and it's
> working
> {noformat}
> Stack trace
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148)
> ... 29 more
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850)
> at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183)
> at
> org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:3278)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1673) Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException
[
https://issues.apache.org/jira/browse/CALCITE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899905#comment-15899905
]
Gangadhar Kairi commented on CALCITE-1673:
--
Thanks for the quick reply Julian. Yes, your insight is correct these are all
related and the root cause with timestamp conversion to long. Do you have any
insight on where this conversion is going wrong. I can spend sometime to fixing
it because we are getting bunch of issues with this timestamp column.
-Gangadhar
> Query with ORDER BY or GROUP BY on TIMESTAMP column throws CompileException
> ---
>
> Key: CALCITE-1673
> URL: https://issues.apache.org/jira/browse/CALCITE-1673
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
>Reporter: Gangadhar Kairi
>Assignee: Julian Hyde
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Getting below error while executing the 'order by' or 'group by' queries with
> timestamp data type column.
> {noformat}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> {noformat}
> I could able to reproduce this problem in CsvTests.
> Fire a test with query "select * from \"DATE\" order by \"JOINTIMES\"" you
> will see test failing with exception.
> Root cause and fix:
> The fix for this to overload the {{SqlFunctions.internalToTimestamp()}} to
> accept the timestamp or object and return timestamp value. I tested and it's
> working
> {noformat}
> Stack trace
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:108)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1233)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:303)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:200)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:761)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:617)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:587)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:595)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:615)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:148)
> ... 29 more
> Caused by: org.codehaus.commons.compiler.CompileException: Line 11, Column
> 76: No applicable constructor/method found for actual parameters
> "java.lang.Object"; candidates are: "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(java.lang.Long)",
> "public static java.sql.Timestamp
> org.apache.calcite.runtime.SqlFunctions.internalToTimestamp(long)"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:10092)
> at
> org.codehaus.janino.UnitCompiler.findMostSpecificIInvocable(UnitCompiler.java:7506)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7376)
> at org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:7280)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:3850)
> at org.codehaus.janino.UnitCompiler.access$6900(UnitCompiler.java:183)
> at
> org.codehaus.janino.UnitCompiler$10.visitMethodInvocation(UnitCompiler.java:3251)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:3974)
> at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:3278)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1672) schema name alias doesn't work in INSERT INTO
[
https://issues.apache.org/jira/browse/CALCITE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899955#comment-15899955
]
Lei Wei commented on CALCITE-1672:
--
Thanks Julian for quick responding.
The real schema name is "dis_20170216103138602" which is code generated. It has
a logic/alias schema name "LEI_DEMO_SANDBOX2". I am using Calcite 1.11.0 and I
love the alias function. I am able to run SELECT query against alias name, but
it doesn't work for INSERT and UPDATE.
select * from LEI_DEMO_SANDBOX2.test_table; // this works fine, and returns
resultset
insert into LEI_DEMO_SANDBOX2.test_table(no) values ('111'); // this
doesn't work (PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist)
update LEI_DEMO_SANDBOX2.test_table set no='111'; // this doesn't work
(PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist)
Thanks
> schema name alias doesn't work in INSERT INTO
> -
>
> Key: CALCITE-1672
> URL: https://issues.apache.org/jira/browse/CALCITE-1672
> Project: Calcite
> Issue Type: Bug
>Reporter: Lei Wei
>Assignee: Julian Hyde
>Priority: Minor
>
> Hi, I setup calcite connecting with posgresql db, and starting avatica to
> take jdbc connectivities. I used alias on the schemas that added to the root
> schema. I'm able to run select statements using alias schema, but it doesn't
> work in INSERT and UPDATE.
> Exception: ExampleExceptionFormatter: exception message was: Error -1 (0)
> : Error while executing SQL "update LEI_DEMO_SANDBOX2.test_table set
> no='111'": Remote driver error: RuntimeException: while executing SQL
> [UPDATE "LEI_DEMO_SANDBOX2"."test_table" SET "no" = '111'] ->
> PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist
> ExampleExceptionFormatter: exception message was: Error -1 (0) : Error
> while executing SQL "insert into LEI_DEMO_SANDBOX2.test_table(no) values
> ('111')": Remote driver error: RuntimeException: while executing SQL
> [INSERT INTO "LEI_DEMO_SANDBOX2"."test_table" ("no")
> VALUES ('111')] -> PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does
> not exist
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CALCITE-1672) schema name alias doesn't work in INSERT INTO
[
https://issues.apache.org/jira/browse/CALCITE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899955#comment-15899955
]
Lei Wei edited comment on CALCITE-1672 at 3/7/17 7:07 PM:
--
Thanks Julian for quick responding.
The real schema name is "dis_20170216103138602" which is code generated. It has
a logic/alias schema name "LEI_DEMO_SANDBOX2". I am using Calcite 1.11.0 and I
love the alias function. I am able to run SELECT query against alias name, but
it doesn't work for INSERT and UPDATE.
select * from LEI_DEMO_SANDBOX2.test_table; // this works fine, and returns
resultset
Calcite generates: select * from dis_20170216103138602.test_table;
insert into LEI_DEMO_SANDBOX2.test_table(no) values ('111'); // this
doesn't work (PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist)
update LEI_DEMO_SANDBOX2.test_table set no='111'; // this doesn't work
(PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist)
Looks like Calcite is not using alias schema name in INSERT and UPDATE. I
haven't tried DETELE and CREATE TABLE.
Thanks
was (Author: davy-wei):
Thanks Julian for quick responding.
The real schema name is "dis_20170216103138602" which is code generated. It has
a logic/alias schema name "LEI_DEMO_SANDBOX2". I am using Calcite 1.11.0 and I
love the alias function. I am able to run SELECT query against alias name, but
it doesn't work for INSERT and UPDATE.
select * from LEI_DEMO_SANDBOX2.test_table; // this works fine, and returns
resultset
insert into LEI_DEMO_SANDBOX2.test_table(no) values ('111'); // this
doesn't work (PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist)
update LEI_DEMO_SANDBOX2.test_table set no='111'; // this doesn't work
(PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist)
Thanks
> schema name alias doesn't work in INSERT INTO
> -
>
> Key: CALCITE-1672
> URL: https://issues.apache.org/jira/browse/CALCITE-1672
> Project: Calcite
> Issue Type: Bug
>Reporter: Lei Wei
>Assignee: Julian Hyde
>Priority: Minor
>
> Hi, I setup calcite connecting with posgresql db, and starting avatica to
> take jdbc connectivities. I used alias on the schemas that added to the root
> schema. I'm able to run select statements using alias schema, but it doesn't
> work in INSERT and UPDATE.
> Exception: ExampleExceptionFormatter: exception message was: Error -1 (0)
> : Error while executing SQL "update LEI_DEMO_SANDBOX2.test_table set
> no='111'": Remote driver error: RuntimeException: while executing SQL
> [UPDATE "LEI_DEMO_SANDBOX2"."test_table" SET "no" = '111'] ->
> PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does not exist
> ExampleExceptionFormatter: exception message was: Error -1 (0) : Error
> while executing SQL "insert into LEI_DEMO_SANDBOX2.test_table(no) values
> ('111')": Remote driver error: RuntimeException: while executing SQL
> [INSERT INTO "LEI_DEMO_SANDBOX2"."test_table" ("no")
> VALUES ('111')] -> PSQLException: ERROR: schema "LEI_DEMO_SANDBOX2" does
> not exist
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1674) LIKE Operator with % does not match when column contains newline
Mark Payne created CALCITE-1674: --- Summary: LIKE Operator with % does not match when column contains newline Key: CALCITE-1674 URL: https://issues.apache.org/jira/browse/CALCITE-1674 Project: Calcite Issue Type: Bug Components: core Reporter: Mark Payne Assignee: Julian Hyde If I have a column where some rows contain a newline, then using a % does not match as it should. For example, if I have a column named 'foo' where a row contains 'My\nValue' then the following query I would expect to match: SELECT * FROM MyTable WHERE foo LIKE 'M%' However, this row is not returned by the above query. This appears to be a bug in the regex generated by the org.apache.calcite.runtime.Like class, as it generates '.*' for the %, but in Java the dot character does not match newlines unless it is compiled in dot-all mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1674) LIKE Operator with % does not match when column contains newline
[ https://issues.apache.org/jira/browse/CALCITE-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900033#comment-15900033 ] Mark Payne commented on CALCITE-1674: - I created a PR that works for my use case. I'm not sure how to really create a unit test for this, but I've verified it manually. Let me know if I'm off base here, and this is not how this should work. Thanks! -Mark > LIKE Operator with % does not match when column contains newline > > > Key: CALCITE-1674 > URL: https://issues.apache.org/jira/browse/CALCITE-1674 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Mark Payne >Assignee: Julian Hyde > > If I have a column where some rows contain a newline, then using a % does not > match as it should. For example, if I have a column named 'foo' where a row > contains 'My\nValue' then the following query I would expect to match: > SELECT * FROM MyTable WHERE foo LIKE 'M%' > However, this row is not returned by the above query. This appears to be a > bug in the regex generated by the org.apache.calcite.runtime.Like class, as > it generates '.*' for the %, but in Java the dot character does not match > newlines unless it is compiled in dot-all mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CALCITE-1674) LIKE Operator with % does not match when column contains newline
[ https://issues.apache.org/jira/browse/CALCITE-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1674: - Fix Version/s: 1.12.0 > LIKE Operator with % does not match when column contains newline > > > Key: CALCITE-1674 > URL: https://issues.apache.org/jira/browse/CALCITE-1674 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Mark Payne >Assignee: Julian Hyde > Fix For: 1.12.0 > > > If I have a column where some rows contain a newline, then using a % does not > match as it should. For example, if I have a column named 'foo' where a row > contains 'My\nValue' then the following query I would expect to match: > SELECT * FROM MyTable WHERE foo LIKE 'M%' > However, this row is not returned by the above query. This appears to be a > bug in the regex generated by the org.apache.calcite.runtime.Like class, as > it generates '.*' for the %, but in Java the dot character does not match > newlines unless it is compiled in dot-all mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1674) LIKE Operator with % does not match when column contains newline
[
https://issues.apache.org/jira/browse/CALCITE-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900443#comment-15900443
]
Julian Hyde commented on CALCITE-1674:
--
Can you add one or two tests to {{SqlOperatorBaseTest.testLikeOperator}}?
> LIKE Operator with % does not match when column contains newline
>
>
> Key: CALCITE-1674
> URL: https://issues.apache.org/jira/browse/CALCITE-1674
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Mark Payne
>Assignee: Julian Hyde
> Fix For: 1.12.0
>
>
> If I have a column where some rows contain a newline, then using a % does not
> match as it should. For example, if I have a column named 'foo' where a row
> contains 'My\nValue' then the following query I would expect to match:
> SELECT * FROM MyTable WHERE foo LIKE 'M%'
> However, this row is not returned by the above query. This appears to be a
> bug in the regex generated by the org.apache.calcite.runtime.Like class, as
> it generates '.*' for the %, but in Java the dot character does not match
> newlines unless it is compiled in dot-all mode.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1675) Two-level column name cannot be resolved in ORDER BY
Maryann Xue created CALCITE-1675:
Summary: Two-level column name cannot be resolved in ORDER BY
Key: CALCITE-1675
URL: https://issues.apache.org/jira/browse/CALCITE-1675
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.11.0
Reporter: Maryann Xue
Assignee: Maryann Xue
Priority: Minor
For example, {{select f1.c1 from struct.t order by f0.c1}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1675) Two-level column name cannot be resolved in ORDER BY
[
https://issues.apache.org/jira/browse/CALCITE-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900461#comment-15900461
]
Maryann Xue commented on CALCITE-1675:
--
Could you please take a look at https://github.com/apache/calcite/pull/391,
[~julianhyde]?
> Two-level column name cannot be resolved in ORDER BY
>
>
> Key: CALCITE-1675
> URL: https://issues.apache.org/jira/browse/CALCITE-1675
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Minor
> Labels: phoenix
>
> For example, {{select f1.c1 from struct.t order by f0.c1}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1675) Two-level column name cannot be resolved in ORDER BY
[
https://issues.apache.org/jira/browse/CALCITE-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900474#comment-15900474
]
Julian Hyde commented on CALCITE-1675:
--
Looks good, but why did you remove the {{@Override}} keyword?
> Two-level column name cannot be resolved in ORDER BY
>
>
> Key: CALCITE-1675
> URL: https://issues.apache.org/jira/browse/CALCITE-1675
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Minor
> Labels: phoenix
>
> For example, {{select f1.c1 from struct.t order by f0.c1}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1665) Aggregates and HAVING cannot be combined
[
https://issues.apache.org/jira/browse/CALCITE-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900487#comment-15900487
]
Julian Hyde commented on CALCITE-1665:
--
[~jbal...@gmail.com], Can please you review and commit? (I make a remark on the
PR about formatting changes but I haven't done a proper review.)
> Aggregates and HAVING cannot be combined
>
>
> Key: CALCITE-1665
> URL: https://issues.apache.org/jira/browse/CALCITE-1665
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.11.0
>Reporter: David Evans
>Assignee: Zhiqiang He
>
> The example on the main docs page: https://calcite.apache.org/docs/ will
> generate the following SQL when run against a JDBC Schema (specifically, with
> a PostgreSQL target database):
> {code}
> SELECT "deptno", MIN("emps"."empid")
> FROM (SELECT "depts"."deptno", MIN("emps"."empid"), COUNT(*) AS "$f2"
> FROM "hr"."depts"
> INNER JOIN "hr"."emps" ON "depts"."deptno" = "emps"."deptno"
> GROUP BY "depts"."deptno") AS "t"
> WHERE "t"."$f2" > 1
> {code}
> This fails since the "emps" table only exists inside the inner select. It
> should be aliasing that result in the inner select and using the outer select
> as a simple pass-through. This appears to be a general issue when combining
> aggregates with `HAVING`
> For an MCVE:
> In postgres: (create a database named "test1"):
> {code}
> CREATE SCHEMA hr;
> CREATE TABLE hr.depts (deptno SERIAL NOT NULL PRIMARY KEY); CREATE TABLE
> hr.emps (empid SERIAL NOT NULL PRIMARY KEY, deptno INT NOT NULL REFERENCES
> hr.depts (deptno));
> INSERT INTO hr.depts VALUES (1), (2);
> INSERT INTO hr.emps (deptno) VALUES (1), (1), (2);
> {code}
> Java:
> {code}
> import org.apache.calcite.adapter.jdbc.JdbcSchema;
> import org.apache.calcite.jdbc.CalciteConnection;
> import org.apache.calcite.schema.Schema;
> import org.apache.calcite.schema.SchemaPlus;
> import org.apache.commons.dbcp.BasicDataSource;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import java.util.Properties;
> public class Main {
> public static class Employee {
> public int EMPID;
> public int DEPTNO;
> }
> public static class Department {
> public int DEPTNO;
> }
> public static class HrSchema {
> public final Employee[] EMPS = null;
> public final Department[] DEPTS = null;
> }
> public static void main(String[] argv) throws Exception {
> System.out.println("Setup");
> Class.forName("org.apache.calcite.jdbc.Driver");
> Class.forName("org.postgresql.Driver");
> BasicDataSource dataSource = new BasicDataSource();
> dataSource.setUrl("jdbc:postgresql://localhost:5432/test1");
> dataSource.setUsername("myUsername"); // change as required
> dataSource.setPassword("");
> Connection pgConnection = dataSource.getConnection();
> Statement statement = pgConnection.createStatement();
> ResultSet results = statement.executeQuery("select d.deptno,
> min(e.empid)\n"
> + "from hr.emps as e\n"
> + "join hr.depts as d\n"
> + " on e.deptno = d.deptno\n"
> + "group by d.deptno\n"
> + "having count(*) > 1");
> System.out.println("Direct to postgres results:");
> while(results.next()) {
> System.out.println(results.getInt(1) + " : " + results.getInt(2));
> }
> System.out.println("Done");
> results.close();
> statement.close();
> pgConnection.close();
> System.out.println("Closed");
> Properties info = new Properties();
> info.setProperty("lex", "JAVA");
> Connection calConnection =
> DriverManager.getConnection("jdbc:calcite:", info);
> CalciteConnection calciteConnection =
> calConnection.unwrap(CalciteConnection.class);
> SchemaPlus rootSchema = calciteConnection.getRootSchema();
> Schema schema = JdbcSchema.create(rootSchema, "hr", dataSource, null,
> "hr");
> rootSchema.add("hr", schema);
> statement = calciteConnection.createStatement();
>results = statement.executeQuery(
> "select d.deptno, min(e.empid)\n"
> + "from hr.emps as e\n"
> + "join hr.depts as d\n"
> + " on e.deptno = d.deptno\n"
> + "group by d.deptno\n"
> + "having count(*) > 1");
> System.out.println("Via calcite results:");
> while(results.next()) {
> System.out.println(results.getInt(1) + " : " + results.getInt(2));
>
[jira] [Updated] (CALCITE-1666) Support for modifiable views with extended columns
[
https://issues.apache.org/jira/browse/CALCITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1666:
-
Fix Version/s: 1.12.0
> Support for modifiable views with extended columns
> --
>
> Key: CALCITE-1666
> URL: https://issues.apache.org/jira/browse/CALCITE-1666
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.11.0
>Reporter: Kevin Liew
>Assignee: Julian Hyde
> Labels: validator, view
> Fix For: 1.12.0
>
>
> The changes for this PR is to:
> - propagate extended columns (already parsed into namespaces in the
> validator) through to the planner
> - validate {{INSERT}} and {{UPDATE}} operations against the constraints of
> the modifiable view
> [~maryannxue], [~rajeshbabu], [~jamestaylor]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1676) In file adapter, scan directory for .csv, .json and .gz files
Julian Hyde created CALCITE-1676:
Summary: In file adapter, scan directory for .csv, .json and .gz
files
Key: CALCITE-1676
URL: https://issues.apache.org/jira/browse/CALCITE-1676
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
Fix For: 1.12.0
File adapter should scan the directory for .csv and .json files and convert
each into a table. If the files have a .gz suffix they are assumed to be
gzip-compressed files.
The first line of a .csv file is the column headers. If the file is empty, the
file adapter gives the table a single column, {{EmptyFileHasNoColumns BOOLEAN}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1677) 2 copies of avatica docs on the website
Francis Chuang created CALCITE-1677: --- Summary: 2 copies of avatica docs on the website Key: CALCITE-1677 URL: https://issues.apache.org/jira/browse/CALCITE-1677 Project: Calcite Issue Type: Bug Reporter: Francis Chuang Assignee: Julian Hyde There appears to be 2 different copies of the avatica docs on the website. For example, for the protobuf docs, there are 2 copies: - https://calcite.apache.org/avatica/docs/protobuf_reference.html - https://calcite.apache.org/docs/avatica_protobuf_reference.html The ones hosted directly at https://calcite.apache.org/docs do not appear to be identical to the ones at https://calcite.apache.org/avatica/docs. It might be better to 1 copy of the docs and point the links to them. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CALCITE-1675) Two-level column name cannot be resolved in ORDER BY
[
https://issues.apache.org/jira/browse/CALCITE-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900745#comment-15900745
]
Maryann Xue commented on CALCITE-1675:
--
Because I removed {{findQualifyingTables}} from its super class
{{DelegatingScope}} and thus {{findQualifyingTables}} is now a utility method
in {{ListScope}} only. {{DelegatingScope#fullyQualify}} now calls
{{findQualifyingTableNames}} for both simple qualifiers and compound qualifiers.
> Two-level column name cannot be resolved in ORDER BY
>
>
> Key: CALCITE-1675
> URL: https://issues.apache.org/jira/browse/CALCITE-1675
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.11.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Minor
> Labels: phoenix
>
> For example, {{select f1.c1 from struct.t order by f0.c1}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1678) Support expressions as insert values to constrained columns in modifiable views
Kevin Liew created CALCITE-1678:
---
Summary: Support expressions as insert values to constrained
columns in modifiable views
Key: CALCITE-1678
URL: https://issues.apache.org/jira/browse/CALCITE-1678
Project: Calcite
Issue Type: Improvement
Affects Versions: 1.11.0
Reporter: Kevin Liew
Assignee: Julian Hyde
Priority: Minor
The following statement fails to validate against the constraint of {{deptno =
20}}
{code:sql}
insert into EMP_MODIFIABLEVIEW2 (deptno, empno, ename) values (^19+1^, 100,
'Lex')
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1679) Schemas.path does not traverse schemas with empty-string name
Kevin Liew created CALCITE-1679:
---
Summary: Schemas.path does not traverse schemas with empty-string
name
Key: CALCITE-1679
URL: https://issues.apache.org/jira/browse/CALCITE-1679
Project: Calcite
Issue Type: Improvement
Affects Versions: 1.11.0
Reporter: Kevin Liew
Assignee: Julian Hyde
Priority: Minor
{{Schemas.path}} does not traverse schemas with empty-string name but the
parsed schema path may be relative to some nested schema with an empty name
rather than been relative to the input root-schema.
ie.
{{rootSchema}} is {{CATALOG}}
the view table full-path is {{CATALOG."".VIEW}} (the schema name is empty)
{{names}} is {{("VIEW")}}
{{Schemas.path}} will fail as it tries to find {{VIEW}} relative to
{{rootSchema}} but does not try to traverse the intermediate schema.
If the first value in {{names}} is not found, we should try to traverse all
prepending schema with empty-string name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CALCITE-1679) Schemas.path does not traverse schemas with empty-string name
[
https://issues.apache.org/jira/browse/CALCITE-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Liew updated CALCITE-1679:
Description:
{{Schemas.path}} does not traverse schemas with empty-string name but the
parsed schema path may be relative to some nested schema with an empty name
rather than been relative to the input root-schema.
ie.
{{rootSchema}} is {{"CATALOG"}}
the view table full-path is {{"CATALOG".""."VIEW"}} (the schema name is empty)
{{names}} is {{("VIEW")}}
{{Schemas.path}} will fail as it tries to find {{"VIEW"}} relative to
{{rootSchema}} but does not try to traverse the intermediate schema.
If the first value in {{names}} is not found, we should try to traverse all
prepending schema with empty-string name.
was:
{{Schemas.path}} does not traverse schemas with empty-string name but the
parsed schema path may be relative to some nested schema with an empty name
rather than been relative to the input root-schema.
ie.
{{rootSchema}} is {{CATALOG}}
the view table full-path is {{CATALOG."".VIEW}} (the schema name is empty)
{{names}} is {{("VIEW")}}
{{Schemas.path}} will fail as it tries to find {{VIEW}} relative to
{{rootSchema}} but does not try to traverse the intermediate schema.
If the first value in {{names}} is not found, we should try to traverse all
prepending schema with empty-string name.
> Schemas.path does not traverse schemas with empty-string name
> -
>
> Key: CALCITE-1679
> URL: https://issues.apache.org/jira/browse/CALCITE-1679
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.11.0
>Reporter: Kevin Liew
>Assignee: Julian Hyde
>Priority: Minor
> Labels: view
>
> {{Schemas.path}} does not traverse schemas with empty-string name but the
> parsed schema path may be relative to some nested schema with an empty name
> rather than been relative to the input root-schema.
> ie.
> {{rootSchema}} is {{"CATALOG"}}
> the view table full-path is {{"CATALOG".""."VIEW"}} (the schema name is empty)
> {{names}} is {{("VIEW")}}
> {{Schemas.path}} will fail as it tries to find {{"VIEW"}} relative to
> {{rootSchema}} but does not try to traverse the intermediate schema.
> If the first value in {{names}} is not found, we should try to traverse all
> prepending schema with empty-string name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CALCITE-1666) Support for modifiable views with extended columns
[
https://issues.apache.org/jira/browse/CALCITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900840#comment-15900840
]
Kevin Liew commented on CALCITE-1666:
-
Thanks for the review [~julianhyde]. I made the suggested changes.
> Support for modifiable views with extended columns
> --
>
> Key: CALCITE-1666
> URL: https://issues.apache.org/jira/browse/CALCITE-1666
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.11.0
>Reporter: Kevin Liew
>Assignee: Julian Hyde
> Labels: validator, view
> Fix For: 1.12.0
>
>
> The changes for this PR is to:
> - propagate extended columns (already parsed into namespaces in the
> validator) through to the planner
> - validate {{INSERT}} and {{UPDATE}} operations against the constraints of
> the modifiable view
> [~maryannxue], [~rajeshbabu], [~jamestaylor]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CALCITE-1666) Support for modifiable views with extended columns
[
https://issues.apache.org/jira/browse/CALCITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900840#comment-15900840
]
Kevin Liew edited comment on CALCITE-1666 at 3/8/17 7:28 AM:
-
Thanks for the review [~julianhyde]. I made changes based on your suggestions.
was (Author: kliew):
Thanks for the review [~julianhyde]. I made the suggested changes.
> Support for modifiable views with extended columns
> --
>
> Key: CALCITE-1666
> URL: https://issues.apache.org/jira/browse/CALCITE-1666
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.11.0
>Reporter: Kevin Liew
>Assignee: Julian Hyde
> Labels: validator, view
> Fix For: 1.12.0
>
>
> The changes for this PR is to:
> - propagate extended columns (already parsed into namespaces in the
> validator) through to the planner
> - validate {{INSERT}} and {{UPDATE}} operations against the constraints of
> the modifiable view
> [~maryannxue], [~rajeshbabu], [~jamestaylor]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CALCITE-1680) Optimization for RelDataTypeImpl.getField
Kevin Liew created CALCITE-1680:
---
Summary: Optimization for RelDataTypeImpl.getField
Key: CALCITE-1680
URL: https://issues.apache.org/jira/browse/CALCITE-1680
Project: Calcite
Issue Type: Improvement
Reporter: Kevin Liew
Assignee: Julian Hyde
Priority: Minor
{{RelDataTypeImpl.getField}} is implemented as a loop and is often called in a
loop. We can store a {{HashMap}} from column-name to {{fieldList}} index when
instantiating {{RelDataTypeImpl}} to improve performance. One of the call
hierarchies involves {{SqlToRelConverter.convertIdentifier}} which is called
often.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
