[jira] [Commented] (CALCITE-2485) Missing Object-to-String convertion in ElasticsearchEnumerators.convert(Object o, Class clazz)
[
https://issues.apache.org/jira/browse/CALCITE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591140#comment-16591140
]
Hongze Zhang commented on CALCITE-2485:
---
[~a.aseev] Thanks!, the fix works for me.
But I have another question about this: returning the value of the map entry
rather than the map it self in method singletonGetter() would make the output
format change from a "\{city_str=[city1]}" to "city1", I personally prefer the
later one, but was the "\{city_str=[city1]}" intentional? I believe the SQL
like "SELECT _MAP['city'] FROM table" is very common, and could be wildly used
already.
> Missing Object-to-String convertion in
> ElasticsearchEnumerators.convert(Object o, Class clazz)
> --
>
> Key: CALCITE-2485
> URL: https://issues.apache.org/jira/browse/CALCITE-2485
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.17.0
>Reporter: Hongze Zhang
>Assignee: Julian Hyde
>Priority: Major
>
> SQL text:
> {code:sql}
> SELECT a."city_str", b."col" FROM (SELECT cast(_MAP['city'] AS VARCHAR(20))
> AS "city_str" FROM ES_SCHEMA."es_table" LIMIT 10) a CROSS JOIN (SELECT "col"
> FROM DRUID_SCHEMA."druid_table" LIMIT 10) b;
> {code}
> Explain plan:
> {code:java}
> EnumerableCalc(expr#0..1=[{inputs}], city_str=[$t1], field5=[$t0])
> EnumerableJoin(condition=[true], joinType=[inner])
> EnumerableInterpreter
> DruidQuery(table=[[DRUID_SCHEMA, druid_table]],
> intervals=[[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z]],
> projects=[[$11]], fetch=[10])
> ElasticsearchToEnumerableConverter
> ElasticsearchProject(city_str=[CAST(ITEM($0, 'city')):VARCHAR(20)
> CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary"])
> ElasticsearchSort(fetch=[10])
> ElasticsearchTableScan(table=[[ES_SCHEMA, es_table]])
> {code}
> Run into exception:
> {code:java}
> :58, ClassCastException (java.lang)
> apply:-1, Baz$2
> toLookup_:2662, EnumerableDefaults (org.apache.calcite.linq4j)
> toLookup:2652, EnumerableDefaults (org.apache.calcite.linq4j)
> toLookup:2628, EnumerableDefaults (org.apache.calcite.linq4j)
> toLookup:705, DefaultEnumerable (org.apache.calcite.linq4j)
> enumerator:1074, EnumerableDefaults$6 (org.apache.calcite.linq4j)
> :-1, Baz$4$1
> enumerator:-1, Baz$4
> iterator:33, AbstractEnumerable (org.apache.calcite.linq4j)
> createCursor:90, MetaImpl (org.apache.calcite.avatica)
> execute:184, AvaticaResultSet (org.apache.calcite.avatica)
> execute:64, CalciteResultSet (org.apache.calcite.jdbc)
> execute:43, CalciteResultSet (org.apache.calcite.jdbc)
> execute:667, AvaticaConnection$1 (org.apache.calcite.avatica)
> prepareAndExecute:566, CalciteMetaImpl (org.apache.calcite.jdbc)
> prepareAndExecuteInternal:675, AvaticaConnection
> (org.apache.calcite.avatica)
> executeInternal:156, AvaticaStatement (org.apache.calcite.avatica)
> execute:217, AvaticaStatement (org.apache.calcite.avatica)
> execute:823, Commands (sqlline)
> sql:733, Commands (sqlline)
> dispatch:795, SqlLine (sqlline)
> begin:668, SqlLine (sqlline)
> start:373, SqlLine (sqlline)
> main:265, SqlLine (sqlline)
> {code}
> Reason:
> # The logic of CAST function is actually to be done in method
> ElasticsearchEnumerators.convert(Object o, Class clazz) in Elasticsearch
> Adaptor;
> # Map-to-String convertion is missing in that method;
> # Because of 1 and 2, the hit map returned from
> ElasticsearchEnumerators.singletonGetter is directly returned to join
> enumerator;
> # The implementation of EnumerableJoin could perform a forcible type casting
> on select keys via method PhysType.generateAccessor(List fields);
> # The casting is from raw type to derived type of RexNode, which means
> EnumerableJoin forces a Map-to-String casting in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng reopened CALCITE-2484:
--
Sorry for reopening the issue.
After cherry-picking the commit to my own repository, I didn't experience the
test failure on the cluster of my company yesterday.
But this morning I discover that it's just because the "timing" of the tests
are changed. To trigger this bug, two test methods using the same table name
must run concurrently, so the "timing" condition is quite strict to trigger
this bug in the current test set.
I carefully read the changes in CALCITE 2435 and I discover that, although
{{cache}} no longer exists in {{SqlTestFactory}}, {{catalogReader}} is now a
method in {{SqlTestFactory}}. As the test cases still use the same instance of
the factory, they still have access to the same catalog reader. So the problem
still exists.
I construct two mock test classes to trigger this bug stably. The two test
classes are the same except for their names. One of the test class is listed as
follows:
{code:java}
public class MockSqlValidatorTest1 extends SqlValidatorTestCase {
// Member definition omitted.
@Test
public void testDynamicStar1() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar2() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
// 296 more test cases
@Test
public void testDynamicStar299() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
@Test
public void testDynamicStar300() {
final String sql = "select newid from (\n"
+ " select *, NATION.N_NATION + 100 as newid\n"
+ " from \"DYNAMIC\".NATION, \"DYNAMIC\".CUSTOMER)";
sql(sql).type("RecordType(ANY NEWID) NOT NULL");
}
{code}
You can check these two test classes
[here|https://paste.ubuntu.com/p/rcWYjMzMjf/] and
[here|https://paste.ubuntu.com/p/Tb2VTz74Xv/] so you can try them out.
If we use
{code}
mvn -T 4 -Dtest=MockSqlValidatorTest* test -pl core
{code}
to run these two test classes concurrently, the bug will occur.
But if we use
{code}
mvn -Dsurefire.parallel= -Dtest=MockSqlValidatorTest* test -pl core
{code}
to let them run one by one, the bug will not occur.
So we still need to remove the single {{INSTANCE}} of {{SqlTestFactory}}. Each
test class should create and use their own instance of {{SqlTestFactory}} when
they want to use it.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running concurrently and using the same table
> name may read and modify the same row type instance, causing the result of
> the test to be incorrect, thus the failure of the test.
> What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
> every test class use a
[jira] [Commented] (CALCITE-2483) Druid adapter, when querying Druid segment metadata, throws when row number is larger than Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591105#comment-16591105
]
Hongze Zhang commented on CALCITE-2483:
---
[~julianhyde] Thanks for your reply, I have changed the commit comment as you
suggested.
{quote}Is a test case feasible?
{quote}
IMHO, feasible, but not necessary enough. Since the exception came inside the
[deserialization|https://github.com/apache/calcite/blob/master/druid/src/main/java/org/apache/calcite/adapter/druid/DruidConnectionImpl.java#L578],
any test for this issue should start with mocking a original JSON text
including a large rowNumber, then pass it to Druid adapter, and assert no
deserialization error thrown. A test like this is mostly like testing the
Jackson lib itself, which should be already covered by Jackson source. What do
you think?
{quote}Have you checked that usages of those fields are also long values?
{quote}
Yes, I had checked the usage before submitting the PR, I am afraid that the two
changed fields are not used in Calcite code currently.
> Druid adapter, when querying Druid segment metadata, throws when row number
> is larger than Integer.MAX_VALUE
>
>
> Key: CALCITE-2483
> URL: https://issues.apache.org/jira/browse/CALCITE-2483
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.17.0
>Reporter: Hongze Zhang
>Assignee: Julian Hyde
>Priority: Major
>
> Calcite sends "merge" segment metadata query to Druid to fetch table schema,
> in the response if the value of "numRows" is beyound Integer.MAX_VALUE, it
> will fail JSON deserialization.
>
> {code:java}
> com.google.common.util.concurrent.UncheckedExecutionException:
> java.lang.RuntimeException:
> com.fasterxml.jackson.databind.JsonMappingException: Numeric value
> (19629299194) out of range owf int
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 26]
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 15] (through reference chain:
> java.util.ArrayList[0]->org.apache.calcite.adapter.druid.DruidConnectionImpl$JsonSegmentMetadata["numRows"])
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2207)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3953)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3957)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4875)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4881)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.apply(LocalCache.java:4899)
> at com.google.common.collect.Maps$AsMapView.get(Maps.java:805)
> at
> org.apache.calcite.schema.impl.AbstractSchema.getTable(AbstractSchema.java:89)
> at
> org.apache.calcite.jdbc.CachingCalciteSchema.getImplicitTable(CachingCalciteSchema.java:137)
> at org.apache.calcite.jdbc.CalciteSchema.getTable(CalciteSchema.java:288)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.lambda$tables$8(CalciteMetaImpl.java:383)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$11$1.current(EnumerableDefaults.java:1871)
> at
> org.apache.calcite.linq4j.Linq4j$CompositeEnumerable$1.current(Linq4j.java:498)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$24.moveNext(EnumerableDefaults.java:2767)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$13$1.moveNext(EnumerableDefaults.java:1948)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$24.moveNext(EnumerableDefaults.java:2766)
> at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:685)
> at org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
> at sqlline.IncrementalRows.hasNext(IncrementalRows.java:65)
> at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
> at sqlline.SqlLine.print(SqlLine.java:1648)
> at sqlline.Commands.metadata(Commands.java:199)
> at sqlline.Commands.tables(Commands.java:332)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Caused by: java.lang.RuntimeException:
> com.fasterxml.jackson.databind.JsonMappingException: Numeric
[jira] [Updated] (CALCITE-2483) Druid adapter, when querying Druid segment metadata, throws when row number is larger than Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-2483:
--
Description:
Calcite sends "merge" segment metadata query to Druid to fetch table schema, in
the response if the value of "numRows" is beyound Integer.MAX_VALUE, it will
fail JSON deserialization.
{code:java}
com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.RuntimeException:
com.fasterxml.jackson.databind.JsonMappingException: Numeric value
(19629299194) out of range owf int
at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
line: 241, column: 26]
at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
line: 241, column: 15] (through reference chain:
java.util.ArrayList[0]->org.apache.calcite.adapter.druid.DruidConnectionImpl$JsonSegmentMetadata["numRows"])
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2207)
at com.google.common.cache.LocalCache.get(LocalCache.java:3953)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3957)
at
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4875)
at
com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4881)
at
com.google.common.cache.LocalCache$LocalLoadingCache.apply(LocalCache.java:4899)
at com.google.common.collect.Maps$AsMapView.get(Maps.java:805)
at
org.apache.calcite.schema.impl.AbstractSchema.getTable(AbstractSchema.java:89)
at
org.apache.calcite.jdbc.CachingCalciteSchema.getImplicitTable(CachingCalciteSchema.java:137)
at org.apache.calcite.jdbc.CalciteSchema.getTable(CalciteSchema.java:288)
at
org.apache.calcite.jdbc.CalciteMetaImpl.lambda$tables$8(CalciteMetaImpl.java:383)
at
org.apache.calcite.linq4j.EnumerableDefaults$11$1.current(EnumerableDefaults.java:1871)
at
org.apache.calcite.linq4j.Linq4j$CompositeEnumerable$1.current(Linq4j.java:498)
at
org.apache.calcite.linq4j.EnumerableDefaults$24.moveNext(EnumerableDefaults.java:2767)
at
org.apache.calcite.linq4j.EnumerableDefaults$13$1.moveNext(EnumerableDefaults.java:1948)
at
org.apache.calcite.linq4j.EnumerableDefaults$24.moveNext(EnumerableDefaults.java:2766)
at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:685)
at org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
at org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
at sqlline.IncrementalRows.hasNext(IncrementalRows.java:65)
at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
at sqlline.SqlLine.print(SqlLine.java:1648)
at sqlline.Commands.metadata(Commands.java:199)
at sqlline.Commands.tables(Commands.java:332)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:791)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
Caused by: java.lang.RuntimeException:
com.fasterxml.jackson.databind.JsonMappingException: Numeric value
(19629299194) out of range of int
at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
line: 241, column: 26]
at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
line: 241, column: 15] (through reference chain:
java.util.ArrayList[0]->org.apache.calcite.adapter.druid.DruidConnectionImpl$JsonSegmentMetadata["numRows"])
at
org.apache.calcite.adapter.druid.DruidConnectionImpl.metadata(DruidConnectionImpl.java:617)
at org.apache.calcite.adapter.druid.DruidSchema.table(DruidSchema.java:85)
at
org.apache.calcite.adapter.druid.DruidSchema.lambda$getTableMap$0(DruidSchema.java:74)
at
com.google.common.cache.CacheLoader$FunctionToCacheLoader.load(CacheLoader.java:149)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3542)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2323)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2286)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2201)
... 32 more
Caused by: com.fasterxml.jackson.databind.JsonMappingException: Numeric value
(19629299194) out of range of int
at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
line: 241, column: 26]
at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
line: 241, column: 15] (through reference chain:
java.util.ArrayList[0]->org.apache.calcite.adapter.druid.DruidConnectionImpl$JsonSegmentMetadata["numRows"])
at
[jira] [Commented] (CALCITE-2481) NameSet assumes lowercase characters have greater codes which does not hold for certain characters
[
https://issues.apache.org/jira/browse/CALCITE-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591013#comment-16591013
]
Julian Hyde commented on CALCITE-2481:
--
[~vlsi], I have a partial solution here:
https://github.com/julianhyde/calcite/tree/2481-non-latin-NameSet. The idea is,
given a name, compute its floor and ceil, that are the minimum and maximum
strings that are equal ignoring case. But my algorithm has a flaw - see the
failure in UtilTest.testNameSet. I'm not sure it's correct to use
StringBuilder.appendCodePoint. Can you fix it?
> NameSet assumes lowercase characters have greater codes which does not hold
> for certain characters
> --
>
> Key: CALCITE-2481
> URL: https://issues.apache.org/jira/browse/CALCITE-2481
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Vladimir Sitnikov
>Assignee: Julian Hyde
>Priority: Major
>
> {code:java} @Test public void lowerCaseWithLowerCode() {
> for (int i = 0; i < 0x; i++) {
> char c = (char) i;
> if (!Character.isLetter(c)) {
> continue;
> }
> char lc = Character.toLowerCase(c);
> char uc = Character.toUpperCase(c);
> if (lc < uc) {
> System.out.println(c + ": (" + ((int) lc) + ") " + lc + " < " + uc +
> " (" + ((int) uc) + ")");
> }
> }
> }
> {code}
> {noformat}
> µ: (181) µ < Μ (924)
> ÿ: (255) ÿ < Ÿ (376)
> İ: (105) i < İ (304)
> Ÿ: (255) ÿ < Ÿ (376)
> ƀ: (384) ƀ < Ƀ (579)
> ƕ: (405) ƕ < Ƕ (502)
> ƚ: (410) ƚ < Ƚ (573)
> ƞ: (414) ƞ < Ƞ (544)
> ƿ: (447) ƿ < Ƿ (503)
> Ƕ: (405) ƕ < Ƕ (502)
> Ƿ: (447) ƿ < Ƿ (503)
> Ƞ: (414) ƞ < Ƞ (544)
> Ƚ: (410) ƚ < Ƚ (573)
> ȿ: (575) ȿ < Ȿ (11390)
> ɀ: (576) ɀ < Ɀ (11391)
> Ƀ: (384) ƀ < Ƀ (579)
> ɐ: (592) ɐ < Ɐ (11375)
> ɑ: (593) ɑ < Ɑ (11373)
> ɒ: (594) ɒ < Ɒ (11376)
> ɜ: (604) ɜ < Ɜ (42923)
> ɡ: (609) ɡ < Ɡ (42924)
> ɥ: (613) ɥ < Ɥ (42893)
> ɦ: (614) ɦ < Ɦ (42922)
> ɪ: (618) ɪ < Ɪ (42926)
> ɫ: (619) ɫ < Ɫ (11362)
> ɬ: (620) ɬ < Ɬ (42925)
> ɱ: (625) ɱ < Ɱ (11374)
> ɽ: (637) ɽ < Ɽ (11364)
> ʇ: (647) ʇ < Ʇ (42929)
> ʝ: (669) ʝ < Ʝ (42930)
> ʞ: (670) ʞ < Ʞ (42928)
> ͻ: (891) ͻ < Ͻ (1021)
> ͼ: (892) ͼ < Ͼ (1022)
> ͽ: (893) ͽ < Ͽ (1023)
> ϲ: (1010) ϲ < Ϲ (1017)
> ϴ: (952) θ < ϴ (1012)
> Ϲ: (1010) ϲ < Ϲ (1017)
> Ͻ: (891) ͻ < Ͻ (1021)
> Ͼ: (892) ͼ < Ͼ (1022)
> Ͽ: (893) ͽ < Ͽ (1023)
> ᲈ: (7304) ᲈ < Ꙋ (42570)
> ᵹ: (7545) ᵹ < Ᵹ (42877)
> ᵽ: (7549) ᵽ < Ᵽ (11363)
> ẞ: (223) ß < ẞ (7838)
> ἀ: (7936) ἀ < Ἀ (7944)
> ἁ: (7937) ἁ < Ἁ (7945)
> ἂ: (7938) ἂ < Ἂ (7946)
> ἃ: (7939) ἃ < Ἃ (7947)
> ἄ: (7940) ἄ < Ἄ (7948)
> ἅ: (7941) ἅ < Ἅ (7949)
> ἆ: (7942) ἆ < Ἆ (7950)
> ἇ: (7943) ἇ < Ἇ (7951)
> Ἀ: (7936) ἀ < Ἀ (7944)
> Ἁ: (7937) ἁ < Ἁ (7945)
> Ἂ: (7938) ἂ < Ἂ (7946)
> Ἃ: (7939) ἃ < Ἃ (7947)
> Ἄ: (7940) ἄ < Ἄ (7948)
> Ἅ: (7941) ἅ < Ἅ (7949)
> Ἆ: (7942) ἆ < Ἆ (7950)
> Ἇ: (7943) ἇ < Ἇ (7951)
> ἐ: (7952) ἐ < Ἐ (7960)
> ἑ: (7953) ἑ < Ἑ (7961)
> ἒ: (7954) ἒ < Ἒ (7962)
> ἓ: (7955) ἓ < Ἓ (7963)
> ἔ: (7956) ἔ < Ἔ (7964)
> ἕ: (7957) ἕ < Ἕ (7965)
> Ἐ: (7952) ἐ < Ἐ (7960)
> Ἑ: (7953) ἑ < Ἑ (7961)
> Ἒ: (7954) ἒ < Ἒ (7962)
> Ἓ: (7955) ἓ < Ἓ (7963)
> Ἔ: (7956) ἔ < Ἔ (7964)
> Ἕ: (7957) ἕ < Ἕ (7965)
> ἠ: (7968) ἠ < Ἠ (7976)
> ἡ: (7969) ἡ < Ἡ (7977)
> ἢ: (7970) ἢ < Ἢ (7978)
> ἣ: (7971) ἣ < Ἣ (7979)
> ἤ: (7972) ἤ < Ἤ (7980)
> ἥ: (7973) ἥ < Ἥ (7981)
> ἦ: (7974) ἦ < Ἦ (7982)
> ἧ: (7975) ἧ < Ἧ (7983)
> Ἠ: (7968) ἠ < Ἠ (7976)
> Ἡ: (7969) ἡ < Ἡ (7977)
> Ἢ: (7970) ἢ < Ἢ (7978)
> Ἣ: (7971) ἣ < Ἣ (7979)
> Ἤ: (7972) ἤ < Ἤ (7980)
> Ἥ: (7973) ἥ < Ἥ (7981)
> Ἦ: (7974) ἦ < Ἦ (7982)
> Ἧ: (7975) ἧ < Ἧ (7983)
> ἰ: (7984) ἰ < Ἰ (7992)
> ἱ: (7985) ἱ < Ἱ (7993)
> ἲ: (7986) ἲ < Ἲ (7994)
> ἳ: (7987) ἳ < Ἳ (7995)
> ἴ: (7988) ἴ < Ἴ (7996)
> ἵ: (7989) ἵ < Ἵ (7997)
> ἶ: (7990) ἶ < Ἶ (7998)
> ἷ: (7991) ἷ < Ἷ (7999)
> Ἰ: (7984) ἰ < Ἰ (7992)
> Ἱ: (7985) ἱ < Ἱ (7993)
> Ἲ: (7986) ἲ < Ἲ (7994)
> Ἳ: (7987) ἳ < Ἳ (7995)
> Ἴ: (7988) ἴ < Ἴ (7996)
> Ἵ: (7989) ἵ < Ἵ (7997)
> Ἶ: (7990) ἶ < Ἶ (7998)
> Ἷ: (7991) ἷ < Ἷ (7999)
> ὀ: (8000) ὀ < Ὀ (8008)
> ὁ: (8001) ὁ < Ὁ (8009)
> ὂ: (8002) ὂ < Ὂ (8010)
> ὃ: (8003) ὃ < Ὃ (8011)
> ὄ: (8004) ὄ < Ὄ (8012)
> ὅ: (8005) ὅ < Ὅ (8013)
> Ὀ: (8000) ὀ < Ὀ (8008)
> Ὁ: (8001) ὁ < Ὁ (8009)
> Ὂ: (8002) ὂ < Ὂ (8010)
> Ὃ: (8003) ὃ < Ὃ (8011)
> Ὄ: (8004) ὄ < Ὄ (8012)
> Ὅ: (8005) ὅ < Ὅ (8013)
> ὑ: (8017) ὑ < Ὑ (8025)
> ὓ: (8019) ὓ < Ὓ (8027)
> ὕ: (8021) ὕ < Ὕ (8029)
> ὗ: (8023) ὗ < Ὗ (8031)
> Ὑ: (8017) ὑ < Ὑ (8025)
> Ὓ: (8019) ὓ < Ὓ (8027)
> Ὕ: (8021) ὕ < Ὕ (8029)
> Ὗ: (8023) ὗ < Ὗ (8031)
> ὠ: (8032) ὠ < Ὠ (8040)
> ὡ: (8033) ὡ < Ὡ (8041)
> ὢ: (8034) ὢ < Ὢ (8042)
> ὣ: (8035) ὣ < Ὣ (8043)
> ὤ: (8036) ὤ < Ὤ (8044)
> ὥ: (8037) ὥ < Ὥ (8045)
> ὦ: (8038) ὦ < Ὦ (8046)
> ὧ: (8039) ὧ < Ὧ (8047)
> Ὠ: (8032) ὠ < Ὠ (8040)
> Ὡ: (8033) ὡ < Ὡ (8041)
> Ὢ: (8034) ὢ < Ὢ (8042)
> Ὣ: (8035) ὣ < Ὣ (8043)
[jira] [Commented] (CALCITE-2485) Missing Object-to-String convertion in ElasticsearchEnumerators.convert(Object o, Class clazz)
[
https://issues.apache.org/jira/browse/CALCITE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590971#comment-16590971
]
Andrei Sereda commented on CALCITE-2485:
[~zhztheplayer] can you please check if
[PR801|https://github.com/apache/calcite/pull/801] fixes the issue ?
> Missing Object-to-String convertion in
> ElasticsearchEnumerators.convert(Object o, Class clazz)
> --
>
> Key: CALCITE-2485
> URL: https://issues.apache.org/jira/browse/CALCITE-2485
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.17.0
>Reporter: Hongze Zhang
>Assignee: Julian Hyde
>Priority: Major
>
> SQL text:
> {code:sql}
> SELECT a."city_str", b."col" FROM (SELECT cast(_MAP['city'] AS VARCHAR(20))
> AS "city_str" FROM ES_SCHEMA."es_table" LIMIT 10) a CROSS JOIN (SELECT "col"
> FROM DRUID_SCHEMA."druid_table" LIMIT 10) b;
> {code}
> Explain plan:
> {code:java}
> EnumerableCalc(expr#0..1=[{inputs}], city_str=[$t1], field5=[$t0])
> EnumerableJoin(condition=[true], joinType=[inner])
> EnumerableInterpreter
> DruidQuery(table=[[DRUID_SCHEMA, druid_table]],
> intervals=[[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z]],
> projects=[[$11]], fetch=[10])
> ElasticsearchToEnumerableConverter
> ElasticsearchProject(city_str=[CAST(ITEM($0, 'city')):VARCHAR(20)
> CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary"])
> ElasticsearchSort(fetch=[10])
> ElasticsearchTableScan(table=[[ES_SCHEMA, es_table]])
> {code}
> Run into exception:
> {code:java}
> :58, ClassCastException (java.lang)
> apply:-1, Baz$2
> toLookup_:2662, EnumerableDefaults (org.apache.calcite.linq4j)
> toLookup:2652, EnumerableDefaults (org.apache.calcite.linq4j)
> toLookup:2628, EnumerableDefaults (org.apache.calcite.linq4j)
> toLookup:705, DefaultEnumerable (org.apache.calcite.linq4j)
> enumerator:1074, EnumerableDefaults$6 (org.apache.calcite.linq4j)
> :-1, Baz$4$1
> enumerator:-1, Baz$4
> iterator:33, AbstractEnumerable (org.apache.calcite.linq4j)
> createCursor:90, MetaImpl (org.apache.calcite.avatica)
> execute:184, AvaticaResultSet (org.apache.calcite.avatica)
> execute:64, CalciteResultSet (org.apache.calcite.jdbc)
> execute:43, CalciteResultSet (org.apache.calcite.jdbc)
> execute:667, AvaticaConnection$1 (org.apache.calcite.avatica)
> prepareAndExecute:566, CalciteMetaImpl (org.apache.calcite.jdbc)
> prepareAndExecuteInternal:675, AvaticaConnection
> (org.apache.calcite.avatica)
> executeInternal:156, AvaticaStatement (org.apache.calcite.avatica)
> execute:217, AvaticaStatement (org.apache.calcite.avatica)
> execute:823, Commands (sqlline)
> sql:733, Commands (sqlline)
> dispatch:795, SqlLine (sqlline)
> begin:668, SqlLine (sqlline)
> start:373, SqlLine (sqlline)
> main:265, SqlLine (sqlline)
> {code}
> Reason:
> # The logic of CAST function is actually to be done in method
> ElasticsearchEnumerators.convert(Object o, Class clazz) in Elasticsearch
> Adaptor;
> # Map-to-String convertion is missing in that method;
> # Because of 1 and 2, the hit map returned from
> ElasticsearchEnumerators.singletonGetter is directly returned to join
> enumerator;
> # The implementation of EnumerableJoin could perform a forcible type casting
> on select keys via method PhysType.generateAccessor(List fields);
> # The casting is from raw type to derived type of RexNode, which means
> EnumerableJoin forces a Map-to-String casting in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-2488) Samza SQL : Support all the timestamp functions from calcite
[ https://issues.apache.org/jira/browse/CALCITE-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srinivasulu Punuru closed CALCITE-2488. --- Resolution: Invalid Opened this in wrong project. > Samza SQL : Support all the timestamp functions from calcite > > > Key: CALCITE-2488 > URL: https://issues.apache.org/jira/browse/CALCITE-2488 > Project: Calcite > Issue Type: Bug >Reporter: Srinivasulu Punuru >Assignee: Julian Hyde >Priority: Major > > Samza SQL right now supports just the current_timestamp, We need to support > all the other calcite timestamp functions that are referenced here > https://calcite.apache.org/docs/reference.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2488) Samza SQL : Support all the timestamp functions from calcite
Srinivasulu Punuru created CALCITE-2488: --- Summary: Samza SQL : Support all the timestamp functions from calcite Key: CALCITE-2488 URL: https://issues.apache.org/jira/browse/CALCITE-2488 Project: Calcite Issue Type: Bug Reporter: Srinivasulu Punuru Assignee: Julian Hyde Samza SQL right now supports just the current_timestamp, We need to support all the other calcite timestamp functions that are referenced here https://calcite.apache.org/docs/reference.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2483) Druid adapter, when querying Druid segment metadata, throws when row number is larger than Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/CALCITE-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2483:
-
Summary: Druid adapter, when querying Druid segment metadata, throws when
row number is larger than Integer.MAX_VALUE (was: Exception thrown when row
number out of int range in Druid segment metadata query.)
> Druid adapter, when querying Druid segment metadata, throws when row number
> is larger than Integer.MAX_VALUE
>
>
> Key: CALCITE-2483
> URL: https://issues.apache.org/jira/browse/CALCITE-2483
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.17.0
>Reporter: Hongze Zhang
>Assignee: Julian Hyde
>Priority: Major
>
> Calcite sends "merge" segment metadata query to Druid to fetch table schema,
> in the response if the value of "numRows" is beyound Integer.MAX_VALUE, it
> will fail JSON deserialization.
>
> {code:java}
> com.google.common.util.concurrent.UncheckedExecutionException:
> java.lang.RuntimeException:
> com.fasterxml.jackson.databind.JsonMappingException: Numeric value
> (19629299194) out of range of int
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 26]
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 15] (through reference chain:
> java.util.ArrayList[0]->org.apache.calcite.adapter.druid.DruidConnectionImpl$JsonSegmentMetadata["numRows"])
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2207)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3953)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3957)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4875)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4881)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.apply(LocalCache.java:4899)
> at com.google.common.collect.Maps$AsMapView.get(Maps.java:805)
> at
> org.apache.calcite.schema.impl.AbstractSchema.getTable(AbstractSchema.java:89)
> at
> org.apache.calcite.jdbc.CachingCalciteSchema.getImplicitTable(CachingCalciteSchema.java:137)
> at org.apache.calcite.jdbc.CalciteSchema.getTable(CalciteSchema.java:288)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.lambda$tables$8(CalciteMetaImpl.java:383)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$11$1.current(EnumerableDefaults.java:1871)
> at
> org.apache.calcite.linq4j.Linq4j$CompositeEnumerable$1.current(Linq4j.java:498)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$24.moveNext(EnumerableDefaults.java:2767)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$13$1.moveNext(EnumerableDefaults.java:1948)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$24.moveNext(EnumerableDefaults.java:2766)
> at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:685)
> at org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
> at sqlline.IncrementalRows.hasNext(IncrementalRows.java:65)
> at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
> at sqlline.SqlLine.print(SqlLine.java:1648)
> at sqlline.Commands.metadata(Commands.java:199)
> at sqlline.Commands.tables(Commands.java:332)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Caused by: java.lang.RuntimeException:
> com.fasterxml.jackson.databind.JsonMappingException: Numeric value
> (19629299194) out of range of int
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 26]
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 15] (through reference chain:
> java.util.ArrayList[0]->org.apache.calcite.adapter.druid.DruidConnectionImpl$JsonSegmentMetadata["numRows"])
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.metadata(DruidConnectionImpl.java:617)
> at org.apache.calcite.adapter.druid.DruidSchema.table(DruidSchema.java:85)
> at
> org.apache.calcite.adapter.druid.DruidSchema.lambda$getTableMap$0(DruidSchema.java:74)
> at
>
[jira] [Commented] (CALCITE-2483) Exception thrown when row number out of int range in Druid segment metadata query.
[
https://issues.apache.org/jira/browse/CALCITE-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590824#comment-16590824
]
Julian Hyde commented on CALCITE-2483:
--
Is a test case feasible?
Have you checked that usages of those fields are also {{long}} values?
Please change the commit comment. 'Fix' goes without saying when a commit
references a bug. So just use the bug description.
> Exception thrown when row number out of int range in Druid segment metadata
> query.
> --
>
> Key: CALCITE-2483
> URL: https://issues.apache.org/jira/browse/CALCITE-2483
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Affects Versions: 1.17.0
>Reporter: Hongze Zhang
>Assignee: Julian Hyde
>Priority: Major
>
> Calcite sends "merge" segment metadata query to Druid to fetch table schema,
> in the response if the value of "numRows" is beyound Integer.MAX_VALUE, it
> will fail JSON deserialization.
>
> {code:java}
> com.google.common.util.concurrent.UncheckedExecutionException:
> java.lang.RuntimeException:
> com.fasterxml.jackson.databind.JsonMappingException: Numeric value
> (19629299194) out of range of int
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 26]
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 15] (through reference chain:
> java.util.ArrayList[0]->org.apache.calcite.adapter.druid.DruidConnectionImpl$JsonSegmentMetadata["numRows"])
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2207)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3953)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3957)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4875)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4881)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.apply(LocalCache.java:4899)
> at com.google.common.collect.Maps$AsMapView.get(Maps.java:805)
> at
> org.apache.calcite.schema.impl.AbstractSchema.getTable(AbstractSchema.java:89)
> at
> org.apache.calcite.jdbc.CachingCalciteSchema.getImplicitTable(CachingCalciteSchema.java:137)
> at org.apache.calcite.jdbc.CalciteSchema.getTable(CalciteSchema.java:288)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.lambda$tables$8(CalciteMetaImpl.java:383)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$11$1.current(EnumerableDefaults.java:1871)
> at
> org.apache.calcite.linq4j.Linq4j$CompositeEnumerable$1.current(Linq4j.java:498)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$24.moveNext(EnumerableDefaults.java:2767)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$13$1.moveNext(EnumerableDefaults.java:1948)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$24.moveNext(EnumerableDefaults.java:2766)
> at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:685)
> at org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
> at sqlline.IncrementalRows.hasNext(IncrementalRows.java:65)
> at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
> at sqlline.SqlLine.print(SqlLine.java:1648)
> at sqlline.Commands.metadata(Commands.java:199)
> at sqlline.Commands.tables(Commands.java:332)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Caused by: java.lang.RuntimeException:
> com.fasterxml.jackson.databind.JsonMappingException: Numeric value
> (19629299194) out of range of int
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 26]
> at [Source: (sun.net.www.protocol.http.HttpURLConnection$HttpInputStream);
> line: 241, column: 15] (through reference chain:
> java.util.ArrayList[0]->org.apache.calcite.adapter.druid.DruidConnectionImpl$JsonSegmentMetadata["numRows"])
> at
> org.apache.calcite.adapter.druid.DruidConnectionImpl.metadata(DruidConnectionImpl.java:617)
> at org.apache.calcite.adapter.druid.DruidSchema.table(DruidSchema.java:85)
> at
> org.apache.calcite.adapter.druid.DruidSchema.lambda$getTableMap$0(DruidSchema.java:74)
> at
>
[jira] [Commented] (CALCITE-2459) Add implementation of From_Base64 to SqlFunctions
[ https://issues.apache.org/jira/browse/CALCITE-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590823#comment-16590823 ] Julian Hyde commented on CALCITE-2459: -- Decode is a perfect example - it has a totally different meaning in Oracle and PostgreSQL. So, it would not make sense to enable both at the same time. Best thing might be to place functions in "packages", and someone could choose to run SQL with "standard,oracle" as their default packages. They could still use functions in other packages, by qualifying with package name, e.g. "postgres.decode(..., 'base64')". The [fun connect-string parameter|https://calcite.apache.org/apidocs/org/apache/calcite/config/CalciteConnectionProperty.html#FUN] is a step in that direction. > Add implementation of From_Base64 to SqlFunctions > - > > Key: CALCITE-2459 > URL: https://issues.apache.org/jira/browse/CALCITE-2459 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: vinoyang >Assignee: Julian Hyde >Priority: Minor > > refer to mysql FROM_BASE64 function : > [https://dev.mysql.com/doc/refman/5.6/en/string-functions.html#function_from-base64] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2459) Add implementation of From_Base64 to SqlFunctions
[ https://issues.apache.org/jira/browse/CALCITE-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590812#comment-16590812 ] Julian Hyde edited comment on CALCITE-2459 at 8/23/18 9:06 PM: --- [~vlsi], Yes, probably. I don't feel very strongly about it. But we should make it easy for people to run in a "pure" standard SQL or Oracle environment if they so choose. In our [function documentation|https://calcite.apache.org/docs/reference.html], we should list which functions are only available in particular compatibility modes. FROM_BASE64 is one. DECODE, GREATEST, LEAST, LTRIM, RTRIM, NVL and 3-argument TRANSLATE are Oracle-specific. Currently those do not even appear in the doc. was (Author: julianhyde): [~vlsi], Yes, probably. I don't feel very strongly about it. But we should make it easy for people to run in a "pure" standard SQL or Oracle environment if they so choose. > Add implementation of From_Base64 to SqlFunctions > - > > Key: CALCITE-2459 > URL: https://issues.apache.org/jira/browse/CALCITE-2459 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: vinoyang >Assignee: Julian Hyde >Priority: Minor > > refer to mysql FROM_BASE64 function : > [https://dev.mysql.com/doc/refman/5.6/en/string-functions.html#function_from-base64] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2459) Add implementation of From_Base64 to SqlFunctions
[
https://issues.apache.org/jira/browse/CALCITE-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590816#comment-16590816
]
Vladimir Sitnikov commented on CALCITE-2459:
The sad thing is standard seems to miss certain useful functions, and
MySQL/PostgreSQL have different ways of doing the same thing.
For instance, in PostgreSQL one uses {{decode(..., 'base64')}} or {{decode(...,
'hex')}}.
I've no idea if we should add both flavours to Calcite or use a canonical
function and translate it appropriately when sending query downstream.
> Add implementation of From_Base64 to SqlFunctions
> -
>
> Key: CALCITE-2459
> URL: https://issues.apache.org/jira/browse/CALCITE-2459
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: vinoyang
>Assignee: Julian Hyde
>Priority: Minor
>
> refer to mysql FROM_BASE64 function :
> [https://dev.mysql.com/doc/refman/5.6/en/string-functions.html#function_from-base64]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2459) Add implementation of From_Base64 to SqlFunctions
[ https://issues.apache.org/jira/browse/CALCITE-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590812#comment-16590812 ] Julian Hyde commented on CALCITE-2459: -- [~vlsi], Yes, probably. I don't feel very strongly about it. But we should make it easy for people to run in a "pure" standard SQL or Oracle environment if they so choose. > Add implementation of From_Base64 to SqlFunctions > - > > Key: CALCITE-2459 > URL: https://issues.apache.org/jira/browse/CALCITE-2459 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: vinoyang >Assignee: Julian Hyde >Priority: Minor > > refer to mysql FROM_BASE64 function : > [https://dev.mysql.com/doc/refman/5.6/en/string-functions.html#function_from-base64] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2487) Upgrade Apache parent POM to version 21
[ https://issues.apache.org/jira/browse/CALCITE-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2487. -- Resolution: Invalid Fix Version/s: (was: 1.18.0) (was: avatica-1.13.0) Oops - I pressed "create" twice. See CALCITE-2486. > Upgrade Apache parent POM to version 21 > --- > > Key: CALCITE-2487 > URL: https://issues.apache.org/jira/browse/CALCITE-2487 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > > Apache parent POM 21 has [just been > released|https://s.apache.org/asf-pom-21]. It generates .sha512 checksums > during release with Maven Release Plugin. > We should investigate using it for the next release (1.18). Also investigate > upgrading Avatica for its next release (1.13). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2486) Upgrade Apache parent POM to version 21
Julian Hyde created CALCITE-2486: Summary: Upgrade Apache parent POM to version 21 Key: CALCITE-2486 URL: https://issues.apache.org/jira/browse/CALCITE-2486 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Fix For: avatica-1.13.0, 1.18.0 Apache parent POM 21 has [just been released|https://s.apache.org/asf-pom-21]. It generates .sha512 checksums during release with Maven Release Plugin. We should investigate using it for the next release (1.18). Also investigate upgrading Avatica for its next release (1.13). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2487) Upgrade Apache parent POM to version 21
Julian Hyde created CALCITE-2487: Summary: Upgrade Apache parent POM to version 21 Key: CALCITE-2487 URL: https://issues.apache.org/jira/browse/CALCITE-2487 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Fix For: avatica-1.13.0, 1.18.0 Apache parent POM 21 has [just been released|https://s.apache.org/asf-pom-21]. It generates .sha512 checksums during release with Maven Release Plugin. We should investigate using it for the next release (1.18). Also investigate upgrading Avatica for its next release (1.13). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2271) Join of two views with window aggregates produces incorrect results or NPE
[
https://issues.apache.org/jira/browse/CALCITE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590799#comment-16590799
]
Vladimir Sitnikov commented on CALCITE-2271:
I have reviewed the patch, and it looks like:
1) The bug is there.
2) It is caused by
org.apache.calcite.adapter.enumerable.EnumerableJoin#implement +
org.apache.calcite.linq4j.tree.BlockBuilder#append(java.lang.String,
org.apache.calcite.linq4j.tree.BlockStatement)
In other words, EnumerableJoin#implement implements left side of the join, then
right side of the join, then calls {{join}}.
The problem is "left" and "right" part of the join might *unintentionally*
share variables/expressions.
Alexey suggests to make variable names more unique, so it passes through,
however I think we'd better augment {{BlockBuilder#append}} logic.
Below you can find the code for the test case in the description (just in case),
{{BlockBuilder#append}} combines both blocks in a single one, and it might
cause variable names to collide.
I suggest to update {{#append(BasicBlock)}} so it uses the following (==I
suggest {{BlockBuilder}} to keep nested braces to avoid namespace clash between
two sides of the join):
{code:java}
...
var leftOutput;
{ // code for left block
leftOutput = ...;
}
var rightOutput;
{ // code for the right block
rightOutput = ...
}
{code}
[~julianhyde], is it ok with you?
{code:java}
// LeftPartOfTheJoin.java
{
final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
org.apache.calcite.linq4j.Linq4j.asEnumerable(new Integer[] {
0});
final org.apache.calcite.linq4j.AbstractEnumerable child = new
org.apache.calcite.linq4j.AbstractEnumerable(){
public org.apache.calcite.linq4j.Enumerator enumerator() {
return new org.apache.calcite.linq4j.Enumerator(){
public final org.apache.calcite.linq4j.Enumerator
inputEnumerator = _inputEnumerable.enumerator();
public void reset() {
inputEnumerator.reset();
}
public boolean moveNext() {
return inputEnumerator.moveNext();
}
public void close() {
inputEnumerator.close();
}
public Object current() {
final java.util.LinkedHashMap _map = new java.util.LinkedHashMap();
_map.put($L4J$C$Integer_valueOf_1_, $L4J$C$Integer_valueOf_1_);
_map.put($L4J$C$Integer_valueOf_2_, $L4J$C$Integer_valueOf_2_);
return _map;
}
static final Integer $L4J$C$Integer_valueOf_1_ = Integer.valueOf(1);
static final Integer $L4J$C$Integer_valueOf_2_ = Integer.valueOf(2);
};
}
};
int prevStart0;
int prevEnd0;
final java.util.Comparator comparator = new java.util.Comparator(){
public int compare(org.apache.calcite.runtime.FlatLists.ComparableList v0,
org.apache.calcite.runtime.FlatLists.ComparableList v1) {
final int c;
c =
org.apache.calcite.runtime.Utilities.compare(org.apache.calcite.runtime.SqlFunctions.toInt(v0.get(0)),
org.apache.calcite.runtime.SqlFunctions.toInt(v1.get(0)));
if (c != 0) {
return c;
}
return 0;
}
public int compare(Object o0, Object o1) {
return this.compare((org.apache.calcite.runtime.FlatLists.ComparableList)
o0, (org.apache.calcite.runtime.FlatLists.ComparableList) o1);
}
};
final java.util.List tempList = (java.util.List)
child.selectMany(org.apache.calcite.runtime.SqlFunctions.flatProduct(new int[] {
2}, false, new
org.apache.calcite.runtime.SqlFunctions.FlatProductInputType[] {
org.apache.calcite.runtime.SqlFunctions.FlatProductInputType.MAP})).into(new
java.util.ArrayList());
final java.util.Iterator iterator =
org.apache.calcite.runtime.SortedMultiMap.singletonArrayIterator(comparator,
tempList);
final java.util.ArrayList _list = new java.util.ArrayList(
tempList.size());
final org.apache.calcite.linq4j.function.Function1 _keySelector0 = new
org.apache.calcite.linq4j.function.Function1() {
public int apply(org.apache.calcite.runtime.FlatLists.ComparableList v) {
return org.apache.calcite.runtime.SqlFunctions.toInt(v.get(0));
}
public Object apply(Object v) {
return apply(
(org.apache.calcite.runtime.FlatLists.ComparableList) v);
}
}
;
final java.util.Comparator _keyComparator0 =
org.apache.calcite.linq4j.function.Functions.nullsComparator(false, false);
long DENSE__RANKa0s0w0;
Long DENSE__RANKa0w0 = (Long) null;
DENSE__RANKa0s0w0 = 0L;
while (iterator.hasNext()) {
final Object[] _rows = (Object[]) iterator.next();
prevStart0 = -1;
prevEnd0 = 2147483647;
for (int i = 0; i < _rows.length; ++i) {
final org.apache.calcite.runtime.FlatLists.ComparableList row =
(org.apache.calcite.runtime.FlatLists.ComparableList) _rows[i];
final int end =
[jira] [Updated] (CALCITE-2485) Missing Object-to-String convertion in ElasticsearchEnumerators.convert(Object o, Class clazz)
[
https://issues.apache.org/jira/browse/CALCITE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hongze Zhang updated CALCITE-2485:
--
Description:
SQL text:
{code:sql}
SELECT a."city_str", b."col" FROM (SELECT cast(_MAP['city'] AS VARCHAR(20)) AS
"city_str" FROM ES_SCHEMA."es_table" LIMIT 10) a CROSS JOIN (SELECT "col" FROM
DRUID_SCHEMA."druid_table" LIMIT 10) b;
{code}
Explain plan:
{code:java}
EnumerableCalc(expr#0..1=[{inputs}], city_str=[$t1], field5=[$t0])
EnumerableJoin(condition=[true], joinType=[inner])
EnumerableInterpreter
DruidQuery(table=[[DRUID_SCHEMA, druid_table]],
intervals=[[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z]],
projects=[[$11]], fetch=[10])
ElasticsearchToEnumerableConverter
ElasticsearchProject(city_str=[CAST(ITEM($0, 'city')):VARCHAR(20)
CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary"])
ElasticsearchSort(fetch=[10])
ElasticsearchTableScan(table=[[ES_SCHEMA, es_table]])
{code}
Run into exception:
{code:java}
:58, ClassCastException (java.lang)
apply:-1, Baz$2
toLookup_:2662, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:2652, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:2628, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:705, DefaultEnumerable (org.apache.calcite.linq4j)
enumerator:1074, EnumerableDefaults$6 (org.apache.calcite.linq4j)
:-1, Baz$4$1
enumerator:-1, Baz$4
iterator:33, AbstractEnumerable (org.apache.calcite.linq4j)
createCursor:90, MetaImpl (org.apache.calcite.avatica)
execute:184, AvaticaResultSet (org.apache.calcite.avatica)
execute:64, CalciteResultSet (org.apache.calcite.jdbc)
execute:43, CalciteResultSet (org.apache.calcite.jdbc)
execute:667, AvaticaConnection$1 (org.apache.calcite.avatica)
prepareAndExecute:566, CalciteMetaImpl (org.apache.calcite.jdbc)
prepareAndExecuteInternal:675, AvaticaConnection (org.apache.calcite.avatica)
executeInternal:156, AvaticaStatement (org.apache.calcite.avatica)
execute:217, AvaticaStatement (org.apache.calcite.avatica)
execute:823, Commands (sqlline)
sql:733, Commands (sqlline)
dispatch:795, SqlLine (sqlline)
begin:668, SqlLine (sqlline)
start:373, SqlLine (sqlline)
main:265, SqlLine (sqlline)
{code}
Reason:
# The logic of CAST function is actually to be done in method
ElasticsearchEnumerators.convert(Object o, Class clazz) in Elasticsearch
Adaptor;
# Map-to-String convertion is missing in that method;
# Because of 1 and 2, the hit map returned from
ElasticsearchEnumerators.singletonGetter is directly returned to join
enumerator;
# The implementation of EnumerableJoin could perform a forcible type casting
on select keys via method PhysType.generateAccessor(List fields);
# The casting is from raw type to derived type of RexNode, which means
EnumerableJoin forces a Map-to-String casting in this case.
was:
SQL text:
{code:sql}
SELECT a."city_str", b."col" FROM (SELECT cast(_MAP['city'] AS VARCHAR(20)) AS
"city_str" FROM ES_SCHEMA."es_table" LIMIT 10) a CROSS JOIN (SELECT "col" FROM
DRUID_SCHEMA."druid_table" LIMIT 10) b;
{code}
Explain plan:
{code}
EnumerableCalc(expr#0..1=[{inputs}], city_str=[$t1], field5=[$t0])
EnumerableJoin(condition=[true], joinType=[inner])
EnumerableInterpreter
DruidQuery(table=[[DRUID_SCHEMA, druid_table]],
intervals=[[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z]],
projects=[[$11]], fetch=[10])
ElasticsearchToEnumerableConverter
ElasticsearchProject(city_str=[CAST(ITEM($0, 'city')):VARCHAR(20)
CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary"])
ElasticsearchSort(fetch=[10])
ElasticsearchTableScan(table=[[ES_SCHEMA, es_table]])
{code}
Run into exception:
{code}
:58, ClassCastException (java.lang)
apply:-1, Baz$2
toLookup_:2662, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:2652, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:2628, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:705, DefaultEnumerable (org.apache.calcite.linq4j)
enumerator:1074, EnumerableDefaults$6 (org.apache.calcite.linq4j)
:-1, Baz$4$1
enumerator:-1, Baz$4
iterator:33, AbstractEnumerable (org.apache.calcite.linq4j)
createCursor:90, MetaImpl (org.apache.calcite.avatica)
execute:184, AvaticaResultSet (org.apache.calcite.avatica)
execute:64, CalciteResultSet (org.apache.calcite.jdbc)
execute:43, CalciteResultSet (org.apache.calcite.jdbc)
execute:667, AvaticaConnection$1 (org.apache.calcite.avatica)
prepareAndExecute:566, CalciteMetaImpl (org.apache.calcite.jdbc)
prepareAndExecuteInternal:675, AvaticaConnection (org.apache.calcite.avatica)
executeInternal:156, AvaticaStatement (org.apache.calcite.avatica)
execute:217, AvaticaStatement (org.apache.calcite.avatica)
execute:823, Commands (sqlline)
sql:733, Commands (sqlline)
dispatch:795, SqlLine (sqlline)
begin:668, SqlLine
[jira] [Created] (CALCITE-2485) Missing Object-to-String convertion in ElasticsearchEnumerators.convert(Object o, Class clazz)
Hongze Zhang created CALCITE-2485:
-
Summary: Missing Object-to-String convertion in
ElasticsearchEnumerators.convert(Object o, Class clazz)
Key: CALCITE-2485
URL: https://issues.apache.org/jira/browse/CALCITE-2485
Project: Calcite
Issue Type: Bug
Components: elasticsearch-adapter
Affects Versions: 1.17.0
Reporter: Hongze Zhang
Assignee: Julian Hyde
SQL text:
{code:sql}
SELECT a."city_str", b."col" FROM (SELECT cast(_MAP['city'] AS VARCHAR(20)) AS
"city_str" FROM ES_SCHEMA."es_table" LIMIT 10) a CROSS JOIN (SELECT "col" FROM
DRUID_SCHEMA."druid_table" LIMIT 10) b;
{code}
Explain plan:
{code}
EnumerableCalc(expr#0..1=[{inputs}], city_str=[$t1], field5=[$t0])
EnumerableJoin(condition=[true], joinType=[inner])
EnumerableInterpreter
DruidQuery(table=[[DRUID_SCHEMA, druid_table]],
intervals=[[1900-01-01T00:00:00.000Z/3000-01-01T00:00:00.000Z]],
projects=[[$11]], fetch=[10])
ElasticsearchToEnumerableConverter
ElasticsearchProject(city_str=[CAST(ITEM($0, 'city')):VARCHAR(20)
CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary"])
ElasticsearchSort(fetch=[10])
ElasticsearchTableScan(table=[[ES_SCHEMA, es_table]])
{code}
Run into exception:
{code}
:58, ClassCastException (java.lang)
apply:-1, Baz$2
toLookup_:2662, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:2652, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:2628, EnumerableDefaults (org.apache.calcite.linq4j)
toLookup:705, DefaultEnumerable (org.apache.calcite.linq4j)
enumerator:1074, EnumerableDefaults$6 (org.apache.calcite.linq4j)
:-1, Baz$4$1
enumerator:-1, Baz$4
iterator:33, AbstractEnumerable (org.apache.calcite.linq4j)
createCursor:90, MetaImpl (org.apache.calcite.avatica)
execute:184, AvaticaResultSet (org.apache.calcite.avatica)
execute:64, CalciteResultSet (org.apache.calcite.jdbc)
execute:43, CalciteResultSet (org.apache.calcite.jdbc)
execute:667, AvaticaConnection$1 (org.apache.calcite.avatica)
prepareAndExecute:566, CalciteMetaImpl (org.apache.calcite.jdbc)
prepareAndExecuteInternal:675, AvaticaConnection (org.apache.calcite.avatica)
executeInternal:156, AvaticaStatement (org.apache.calcite.avatica)
execute:217, AvaticaStatement (org.apache.calcite.avatica)
execute:823, Commands (sqlline)
sql:733, Commands (sqlline)
dispatch:795, SqlLine (sqlline)
begin:668, SqlLine (sqlline)
start:373, SqlLine (sqlline)
main:265, SqlLine (sqlline)
{code}
Reason:
# The logic of CAST function is actually to be done in method
ElasticsearchEnumerators.convert(Object o, Class clazz) in Elasticsearch
Adaptor;
# Map-to-String convertion is missing in that method;
# Because of 1 and 2, the hit map returned from
ElasticsearchEnumerators.singletonGetter is directly returned to join
enumerator;
# The implementation of EnumerableJoin performs a forcible type casting on
select keys via method PhysType.generateAccessor(List fields);
# The casting is from raw type to derived type of RexNode, which means
EnumerableJoin forces a Map-to-String casting in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589978#comment-16589978
]
Caizhi Weng commented on CALCITE-2484:
--
[~vladimirsitnikov] This issue will only present when the cache still exists.
As cache is removed in CALCITE 2435, this problem doesn't exist any more. Sorry
I didn't notice that commit.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running concurrently and using the same table
> name may read and modify the same row type instance, causing the result of
> the test to be incorrect, thus the failure of the test.
> What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
> every test class use a new instance of the factory, so that we can solve the
> concurrent modification problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Affects Version/s: 1.17.0
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running concurrently and using the same table
> name may read and modify the same row type instance, causing the result of
> the test to be incorrect, thus the failure of the test.
> What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
> every test class use a new instance of the factory, so that we can solve the
> concurrent modification problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589959#comment-16589959
]
Vladimir Sitnikov commented on CALCITE-2484:
[~TsReaper], DefaultSqlTestFactory does not exists anymore. Could you please
re-check if the issue is still present?
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running concurrently and using the same table
> name may read and modify the same row type instance, causing the result of
> the test to be incorrect, thus the failure of the test.
> What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
> every test class use a new instance of the factory, so that we can solve the
> concurrent modification problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Description:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same factory instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases running concurrently and using the same table
name may read and modify the same row type instance, causing the result of the
test to be incorrect, thus the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
was:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same factory instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases using the same table name may read and modify the
same row type instance, causing the result of the test to be incorrect, thus
the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases running
[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
[
https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caizhi Weng updated CALCITE-2484:
-
Description:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same factory instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases using the same table name may read and modify the
same row type instance, causing the result of the test to be incorrect, thus
the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
was:
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type, as every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases using the same table name may read and modify the
same row type instance, causing the result of the test to be incorrect, thus
the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
> Dynamic table tests give wrong results when running tests concurrently.
> ---
>
> Key: CALCITE-2484
> URL: https://issues.apache.org/jira/browse/CALCITE-2484
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Caizhi Weng
>Assignee: Julian Hyde
>Priority: Major
>
> When running tests on the cluster of my company, I always experience the
> failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
> investigation, I discover that it is triggered by the cache in
> {{DefaultSqlTestFactory}} introduced in [this
> commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a
> {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
> every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
> actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares
> the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog
> reader, table is stored in root schema, and row type is stored in table,
> every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use
> doesn't exist, two test cases using the same table name may read and modify
[jira] [Created] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.
Caizhi Weng created CALCITE-2484:
Summary: Dynamic table tests give wrong results when running tests
concurrently.
Key: CALCITE-2484
URL: https://issues.apache.org/jira/browse/CALCITE-2484
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Caizhi Weng
Assignee: Julian Hyde
When running tests on the cluster of my company, I always experience the
failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After
investigation, I discover that it is triggered by the cache in
{{DefaultSqlTestFactory}} introduced in [this
commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
The failure of the test case is because:
# In the current implementation, when a test class wants to use a
{{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so
every class using this factory actually shares the same instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class
actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type, as every class shares the
same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog
reader, table is stored in root schema, and row type is stored in table, every
class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use
doesn't exist, two test cases using the same table name may read and modify the
same row type instance, causing the result of the test to be incorrect, thus
the failure of the test.
What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let
every test class use a new instance of the factory, so that we can solve the
concurrent modification problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null'
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583330#comment-16583330 ] pengzhiwei edited comment on CALCITE-2469 at 8/23/18 7:31 AM: -- [~julianhyde] and [~vladimirsitnikov] I have changed the description to '(not x) is null'. And the PR is updated to [PR 796|https://github.com/apache/calcite/pull/796] was (Author: pzw2018): [~julianhyde] and [~vladimirsitnikov] I have change the description to '(not x) is null'. And the PR is updated to [PR 796|https://github.com/apache/calcite/pull/796] > RexSimplify should not optimize '(not x) is null' to 'x is not null' > > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
