[jira] [Updated] (CALCITE-1263) Case-insensitive match and null default value for enum properties
[
https://issues.apache.org/jira/browse/CALCITE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1263:
-
Component/s: avatica
> Case-insensitive match and null default value for enum properties
> -
>
> Key: CALCITE-1263
> URL: https://issues.apache.org/jira/browse/CALCITE-1263
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> In ConnectionConfigImpl, we allow properties based on enum classes. The
> getEnum method throws "Required property 'name' not specified" if the default
> value is null, but it should not; we should allow enum properties whose
> default value is null.
> Also, when resolving an enum property we should check the exact string first,
> then look for case-insensitive matches. This will help if people write
> 'p=foo' if 'p' is a property of type enum { FOO, BAZ }.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CALCITE-1263) Case-insensitive match and null default value for enum properties
Julian Hyde created CALCITE-1263:
Summary: Case-insensitive match and null default value for enum
properties
Key: CALCITE-1263
URL: https://issues.apache.org/jira/browse/CALCITE-1263
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
In ConnectionConfigImpl, we allow properties based on enum classes. The getEnum
method throws "Required property 'name' not specified" if the default value is
null, but it should not; we should allow enum properties whose default value is
null.
Also, when resolving an enum property we should check the exact string first,
then look for case-insensitive matches. This will help if people write 'p=foo'
if 'p' is a property of type enum { FOO, BAZ }.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1259) Allow connecting to a single schema without writing a model
[
https://issues.apache.org/jira/browse/CALCITE-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15305660#comment-15305660
]
Julian Hyde commented on CALCITE-1259:
--
Please review
https://github.com/julianhyde/calcite/commit/fe5b0009fdc03aeb255ee5ad86aff50978738a48.
> Allow connecting to a single schema without writing a model
> ---
>
> Key: CALCITE-1259
> URL: https://issues.apache.org/jira/browse/CALCITE-1259
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Allow connecting to a single schema without writing a model. Currently, to
> use a SchemaFactory you need to write a model.json file, but with this
> feature, you could specify the same information as connect string parameters.
> Examples
> 1. JDBC (built-in). Instead of writing a model with
> {code}
> {
> type: 'jdbc',
> name: 'FOODMART',
> jdbcUser: 'FOODMART',
> jdbcPassword: 'FOODMART',
> jdbcUrl: 'jdbc:hsqldb:res:foodmart',
> jdbcSchema: 'foodmart'
> }
> {code}
> use the connect string {{jdbc:calcite:schema_type=jdbc;
> schema.jdbcUser=FOODMART; schema.jdbcPassword=FOODMART;
> schema.jdbcUrl='jdbc:hsqldb:res:foodmart'; schema.jdbcSchema=foodmart}}
> 2. Mongo (user-defined). Instead of writing a model with
> {code}
> {
> type: 'custom',
> name: 'mongo_raw',
> factory: 'org.apache.calcite.adapter.mongodb.MongoSchemaFactory',
> operand: {
> host: 'localhost',
> database: 'test'
> }
> }
> {code}
> use the connect string
> {{jdbc:calcite:schemaFactory=org.apache.calcite.adapter.mongodb.MongoSchemaFactory;
> schema.host=localhost; schema.database=test}}
> 3. Cassandra (user-defined). Instead of writing a model with
> {code}
> {
> type: 'custom',
> name: 'twissandra',
> factory: 'org.apache.calcite.adapter.cassandra.CassandraSchemaFactory',
> operand: {
> host: 'localhost',
> keyspace: 'twissandra'
> }
> }
> {code}
> use the connect string
> {{jdbc:calcite:schemaFactory=org.apache.calcite.adapter.cassandra.CassandraSchemaFactory;
> schema.host=localhost; schema.keyspace=twissandra}}
> You can supply any operand supported by the adapter, as long as you prefix
> its name with "schema.".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1259) Allow connecting to a single schema without writing a model
[
https://issues.apache.org/jira/browse/CALCITE-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-1259:
-
Description:
Allow connecting to a single schema without writing a model. Currently, to use
a SchemaFactory you need to write a model.json file, but with this feature, you
could specify the same information as connect string parameters.
Examples
1. JDBC (built-in). Instead of writing a model with
{code}
{
type: 'jdbc',
name: 'FOODMART',
jdbcUser: 'FOODMART',
jdbcPassword: 'FOODMART',
jdbcUrl: 'jdbc:hsqldb:res:foodmart',
jdbcSchema: 'foodmart'
}
{code}
use the connect string {{jdbc:calcite:schema_type=jdbc;
schema.jdbcUser=FOODMART; schema.jdbcPassword=FOODMART;
schema.jdbcUrl='jdbc:hsqldb:res:foodmart'; schema.jdbcSchema=foodmart}}
2. Mongo (user-defined). Instead of writing a model with
{code}
{
type: 'custom',
name: 'mongo_raw',
factory: 'org.apache.calcite.adapter.mongodb.MongoSchemaFactory',
operand: {
host: 'localhost',
database: 'test'
}
}
{code}
use the connect string
{{jdbc:calcite:schemaFactory=org.apache.calcite.adapter.mongodb.MongoSchemaFactory;
schema.host=localhost; schema.database=test}}
3. Cassandra (user-defined). Instead of writing a model with
{code}
{
type: 'custom',
name: 'twissandra',
factory: 'org.apache.calcite.adapter.cassandra.CassandraSchemaFactory',
operand: {
host: 'localhost',
keyspace: 'twissandra'
}
}
{code}
use the connect string
{{jdbc:calcite:schemaFactory=org.apache.calcite.adapter.cassandra.CassandraSchemaFactory;
schema.host=localhost; schema.keyspace=twissandra}}
You can supply any operand supported by the adapter, as long as you prefix its
name with "schema.".
was:
Allow connecting to a single schema without writing a model. Currently, to use
a SchemaFactory you need to write a model.json file, but with this feature, you
could specify the same information as connect string parameters.
Examples
1. JDBC (built-in). Instead of writing a model with
{code}
{
type: 'jdbc',
name: 'FOODMART',
jdbcUser: 'FOODMART',
jdbcPassword: 'FOODMART',
jdbcUrl: 'jdbc:hsqldb:res:foodmart',
jdbcSchema: 'foodmart'
}
{code}
use the connect string {{jdbc:calcite:schema_type=jdbc;
schema_jdbcUser=FOODMART; schema_jdbcPassword=FOODMART;
schema_jdbcUrl='jdbc:hsqldb:res:foodmart'; schema_jdbcSchema=foodmart}}
2. Mongo (user-defined). Instead of writing a model with
{code}
{
type: 'custom',
name: 'mongo_raw',
factory: 'org.apache.calcite.adapter.mongodb.MongoSchemaFactory',
operand: {
host: 'localhost',
database: 'test'
}
}
{code}
use the connect string
{{jdbc:calcite:schemaFactory=org.apache.calcite.adapter.mongodb.MongoSchemaFactory;
schema_host=localhost; schema_database=test}}
3. Cassandra (user-defined). Instead of writing a model with
{code}
{
type: 'custom',
name: 'twissandra',
factory: 'org.apache.calcite.adapter.cassandra.CassandraSchemaFactory',
operand: {
host: 'localhost',
keyspace: 'twissandra'
}
}
{code}
use the connect string
{{jdbc:calcite:schemaFactory=org.apache.calcite.adapter.cassandra.CassandraSchemaFactory;
schema_host=localhost; schema_keyspace=twissandra}}
> Allow connecting to a single schema without writing a model
> ---
>
> Key: CALCITE-1259
> URL: https://issues.apache.org/jira/browse/CALCITE-1259
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Allow connecting to a single schema without writing a model. Currently, to
> use a SchemaFactory you need to write a model.json file, but with this
> feature, you could specify the same information as connect string parameters.
> Examples
> 1. JDBC (built-in). Instead of writing a model with
> {code}
> {
> type: 'jdbc',
> name: 'FOODMART',
> jdbcUser: 'FOODMART',
> jdbcPassword: 'FOODMART',
> jdbcUrl: 'jdbc:hsqldb:res:foodmart',
> jdbcSchema: 'foodmart'
> }
> {code}
> use the connect string {{jdbc:calcite:schema_type=jdbc;
> schema.jdbcUser=FOODMART; schema.jdbcPassword=FOODMART;
> schema.jdbcUrl='jdbc:hsqldb:res:foodmart'; schema.jdbcSchema=foodmart}}
> 2. Mongo (user-defined). Instead of writing a model with
> {code}
> {
> type: 'custom',
> name: 'mongo_raw',
> factory: 'org.apache.calcite.adapter.mongodb.MongoSchemaFactory',
> operand: {
> host: 'localhost',
> database: 'test'
> }
> }
> {code}
> use the connect string
> {{jdbc:calcite:schemaFactory=org.apache.calcite.adapter.mongodb.MongoSchemaFactory;
> schema.host=localhost; schema.database=test}}
> 3. Cassandra
[jira] [Updated] (CALCITE-1254) Support PreparedStatement.executeLargeBatch
[
https://issues.apache.org/jira/browse/CALCITE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1254:
Priority: Blocker (was: Major)
> Support PreparedStatement.executeLargeBatch
> ---
>
> Key: CALCITE-1254
> URL: https://issues.apache.org/jira/browse/CALCITE-1254
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Julian Hyde
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: avatica-1.8.0
>
>
> In CALCITE-1128 we added support for PreparedStatement.executeBatch. This
> added ExecuteBatchResult with a field {{int[] updateCounts}}.
> I think that field should have been {{long[]}} instead. Elsewhere we have
> been converting update counts from {{int}} to {{long}}, in line with changes
> to the JDBC API.
> If changing this field from {{int[]}} to {{long[]}} will be a breaking change
> we should consider halting 1.8 to get this in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CALCITE-1227) Add streaming CSV table
[
https://issues.apache.org/jira/browse/CALCITE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhen wang updated CALCITE-1227:
---
Comment: was deleted
(was: thanks [~julianhyde], will clean up the PR once fished the remaining
bits, reduce code repetitions.
I still haven't figured out how to check for cancel. the new CsvStreamReader is
pretty much isolated from other parts of the query, where can it get that query
is cancelled ? AvaticaResultSet.java seems just ignore the cancel request.
another thing if the block waiting is done at Reader. which means moveNext()
method in Enumerator will block, which in turn prevents the last row being
emitted. not sure if I miss anything.
during testing, when continuous output is being emitted to console, CTRL+C did
mange to stop the execution. so I will probably dig more to find out. but if
you have the clue, let me know. )
> Add streaming CSV table
> ---
>
> Key: CALCITE-1227
> URL: https://issues.apache.org/jira/browse/CALCITE-1227
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Add a variant of CsvTable that can be streamed. It would serve as an example
> of how to write stream adapters.
> It would be like the CSV adapter, but watches a file and reports records
> added to the end of the file (like the tail command).
> You’d have to change {{CsvTable}} to implement {{StreamableTable}}, and
> implement the {{Table stream()}} method to return a variant of the table that
> is in “follow” mode.
> It would probably be implemented by a variant of CsvEnumerator, but it is
> getting its input in bursts, as the file is appended to.
> You would still be able to use this adapter to read historical data from the
> CSV file. Appending records to the file would make a nice demo.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1227) Add streaming CSV table
[
https://issues.apache.org/jira/browse/CALCITE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15305448#comment-15305448
]
zhen wang commented on CALCITE-1227:
thanks [~julianhyde], will clean up the PR once fished the remaining bits,
reduce code repetitions.
I still haven't figured out how to check for cancel. the new CsvStreamReader is
pretty much isolated from other parts of the query, where can it get that query
is cancelled ? AvaticaResultSet.java seems just ignore the cancel request.
another thing if the block waiting is done at Reader. which means moveNext()
method in Enumerator will block, which in turn prevents the last row being
emitted. not sure if I miss anything.
during testing, when continuous output is being emitted to console, CTRL+C did
mange to stop the execution. so I will probably dig more to find out. but if
you have the clue, let me know.
> Add streaming CSV table
> ---
>
> Key: CALCITE-1227
> URL: https://issues.apache.org/jira/browse/CALCITE-1227
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Add a variant of CsvTable that can be streamed. It would serve as an example
> of how to write stream adapters.
> It would be like the CSV adapter, but watches a file and reports records
> added to the end of the file (like the tail command).
> You’d have to change {{CsvTable}} to implement {{StreamableTable}}, and
> implement the {{Table stream()}} method to return a variant of the table that
> is in “follow” mode.
> It would probably be implemented by a variant of CsvEnumerator, but it is
> getting its input in bursts, as the file is appended to.
> You would still be able to use this adapter to read historical data from the
> CSV file. Appending records to the file would make a nice demo.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
