[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[ https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13702018#comment-13702018 ] Rick Shaw commented on CASSANDRA-4495: -- LGTM. Should be no problem to incorporate into client side work. Thanks for the enhancements! Don't tie client side use of AbstractType to JDBC - Key: CASSANDRA-4495 URL: https://issues.apache.org/jira/browse/CASSANDRA-4495 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Carl Yeksigian Priority: Minor Fix For: 2.0 Attachments: 4495.patch, 4495-v2.patch, 4495-v3.patch We currently expose the AbstractType to java clients that want to reuse them though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL and will never be). Typically, there is a fair amount of the JDBC standard that cannot be implemented with C*, and there is a number of specificity of C* that are not in JDBC (typically the set and maps collections). So I propose to extract simple type classes with just a compose and decompose method (but without ties to jdbc, which would allow all the jdbc specific method those types have) in the purpose of exporting that in a separate jar for clients (we could put that in a org.apache.cassandra.type package for instance). We could then deprecate the jdbc classes with basically the same schedule than CQL2. Let me note that this is *not* saying there shouldn't be a JDBC driver for Cassandra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[
https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682282#comment-13682282
]
Rick Shaw commented on CASSANDRA-4495:
--
Can't you just move the {{validate()}} method in the classes in {{o.a.c.types}}
from the ones on {{o.a.c.db.marshal}}? Then the collections classes in
{{o.a.c.types}} will have access to them.
Don't tie client side use of AbstractType to JDBC
-
Key: CASSANDRA-4495
URL: https://issues.apache.org/jira/browse/CASSANDRA-4495
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Carl Yeksigian
Priority: Minor
Fix For: 2.0
Attachments: 4495.patch
We currently expose the AbstractType to java clients that want to reuse them
though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC
standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL
and will never be). Typically, there is a fair amount of the JDBC standard
that cannot be implemented with C*, and there is a number of specificity of
C* that are not in JDBC (typically the set and maps collections).
So I propose to extract simple type classes with just a compose and decompose
method (but without ties to jdbc, which would allow all the jdbc specific
method those types have) in the purpose of exporting that in a separate jar
for clients (we could put that in a org.apache.cassandra.type package for
instance). We could then deprecate the jdbc classes with basically the same
schedule than CQL2.
Let me note that this is *not* saying there shouldn't be a JDBC driver for
Cassandra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[
https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13676376#comment-13676376
]
Rick Shaw edited comment on CASSANDRA-4495 at 6/5/13 9:38 PM:
--
Could this solution be enhanced to address the collection types? (List, Set,
and Map). This is really awkward to do on the client side.
{{getType()}} in each class would also be handy when you are passed the
AbstractType.
Is there a reason you did not remove the {{o.a.c.cql.jdbc}} package from the
build?
Great job BTW...
was (Author: ardot):
Could this solution be enhanced to address the collection types? (List,
Set, and Map). This is really awkward to do on the client side.
{{getType()}} in each class would also be handy when you are passed the
AbstractType.
Is there a reason you did not remove the {{o.a.c.cql.jdbc}} package from the
build?
Don't tie client side use of AbstractType to JDBC
-
Key: CASSANDRA-4495
URL: https://issues.apache.org/jira/browse/CASSANDRA-4495
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Carl Yeksigian
Priority: Minor
Fix For: 2.0
Attachments: 4495.patch
We currently expose the AbstractType to java clients that want to reuse them
though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC
standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL
and will never be). Typically, there is a fair amount of the JDBC standard
that cannot be implemented with C*, and there is a number of specificity of
C* that are not in JDBC (typically the set and maps collections).
So I propose to extract simple type classes with just a compose and decompose
method (but without ties to jdbc, which would allow all the jdbc specific
method those types have) in the purpose of exporting that in a separate jar
for clients (we could put that in a org.apache.cassandra.type package for
instance). We could then deprecate the jdbc classes with basically the same
schedule than CQL2.
Let me note that this is *not* saying there shouldn't be a JDBC driver for
Cassandra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[
https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13676376#comment-13676376
]
Rick Shaw commented on CASSANDRA-4495:
--
Could this solution be enhanced to address the collection types? (List, Set,
and Map). This is really awkward to do on the client side.
{{getType()}} in each class would also be handy when you are passed the
AbstractType.
Is there a reason you did not remove the {{o.a.c.cql.jdbc}} package from the
build?
Don't tie client side use of AbstractType to JDBC
-
Key: CASSANDRA-4495
URL: https://issues.apache.org/jira/browse/CASSANDRA-4495
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Carl Yeksigian
Priority: Minor
Fix For: 2.0
Attachments: 4495.patch
We currently expose the AbstractType to java clients that want to reuse them
though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC
standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL
and will never be). Typically, there is a fair amount of the JDBC standard
that cannot be implemented with C*, and there is a number of specificity of
C* that are not in JDBC (typically the set and maps collections).
So I propose to extract simple type classes with just a compose and decompose
method (but without ties to jdbc, which would allow all the jdbc specific
method those types have) in the purpose of exporting that in a separate jar
for clients (we could put that in a org.apache.cassandra.type package for
instance). We could then deprecate the jdbc classes with basically the same
schedule than CQL2.
Let me note that this is *not* saying there shouldn't be a JDBC driver for
Cassandra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5443) Add CAS CQL support
[ https://issues.apache.org/jira/browse/CASSANDRA-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629462#comment-13629462 ] Rick Shaw commented on CASSANDRA-5443: -- With regard to the result, it would be cosistent with SQL to return a count of affected logical rows; not a boolean. Add CAS CQL support --- Key: CASSANDRA-5443 URL: https://issues.apache.org/jira/browse/CASSANDRA-5443 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5443) Add CAS CQL support
[ https://issues.apache.org/jira/browse/CASSANDRA-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629462#comment-13629462 ] Rick Shaw edited comment on CASSANDRA-5443 at 4/11/13 10:12 PM: With regard to the result, it would be consistent with SQL to return a count of affected logical rows; not a boolean. was (Author: ardot): With regard to the result, it would be cosistent with SQL to return a count of affected logical rows; not a boolean. Add CAS CQL support --- Key: CASSANDRA-5443 URL: https://issues.apache.org/jira/browse/CASSANDRA-5443 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Sylvain Lebresne Fix For: 2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4693) CQL Protocol should allow multiple PreparedStatements to be atomically executed
[ https://issues.apache.org/jira/browse/CASSANDRA-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13538246#comment-13538246 ] Rick Shaw commented on CASSANDRA-4693: -- The JDBC spec has a well tested solution to this problem. The subject is covered in section 14.1.4 : PreparedStatement Objects under Batch Updates. It is probably worth a look. The summary is that it makes a list of prepared statement entries and their associated parameters and keeps it under a controlling statement. A C* implementation might be to create a list of both the prepared statement token and its list of binding values. Keeping the list of bound values tightly coupled with each prepared statement token greatly simplifies the binding alignment when the number of operations is large. CQL Protocol should allow multiple PreparedStatements to be atomically executed --- Key: CASSANDRA-4693 URL: https://issues.apache.org/jira/browse/CASSANDRA-4693 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Michaël Figuière Labels: cql, protocol Currently the only way to insert multiple records on the same partition key, atomically and using PreparedStatements is to use a CQL BATCH command. Unfortunately when doing so the amount of records to be inserted must be known prior to prepare the statement which is rarely the case. Thus the only workaround if one want to keep atomicity is currently to use unprepared statements which send a bulk of CQL strings and is fairly inefficient. Therefore CQL Protocol should allow clients to send multiple PreparedStatements to be executed with similar guarantees and semantic as CQL BATCH command. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4945) CQL3 does handle List append or prepend with a Prepared list
Rick Shaw created CASSANDRA-4945:
Summary: CQL3 does handle List append or prepend with a Prepared
list
Key: CASSANDRA-4945
URL: https://issues.apache.org/jira/browse/CASSANDRA-4945
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 2
Environment: CQL3 Thrift methods (new)
Reporter: Rick Shaw
Priority: Minor
I can successfully update a List using the literal syntax:
{code}
UPDATE testcollection SET L = [98,99,100] + L WHERE k = 1;
{code}
And I can successfully upset a List using the Prepared syntax:
{code}
UPDATE testcollection SET L = ? WHERE k = 1
{code}
by providing a decoded ListInteger in the bind values.
But using the prepared syntax for an prepend like:
{code}
UPDATE testcollection SET L = ? + L WHERE k = 1
{code}
fails with the following message:
{code}
java.sql.SQLSyntaxErrorException: InvalidRequestException(why:line 1:33
mismatched input '+' expecting K_WHERE)
at
org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
...
...
{code}
and an append of a prepared syntax like:
{code}
UPDATE testcollection SET L = L + ? WHERE k = 1
{code}
fails as follows:
{code}
java.sql.SQLSyntaxErrorException: InvalidRequestException(why:invalid operation
for non commutative columnfamily testcollection)
at
org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
...
...
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4945) CQL3 does handle List append or prepend with a Prepared list
[
https://issues.apache.org/jira/browse/CASSANDRA-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-4945:
-
Description:
I can successfully update a List using the literal syntax:
{code}
UPDATE testcollection SET L = [98,99,100] + L WHERE k = 1;
{code}
And I can successfully upsert a List using the Prepared syntax:
{code}
UPDATE testcollection SET L = ? WHERE k = 1
{code}
by providing a decoded ListInteger in the bind values.
But using the prepared syntax for an prepend like:
{code}
UPDATE testcollection SET L = ? + L WHERE k = 1
{code}
fails with the following message:
{code}
java.sql.SQLSyntaxErrorException: InvalidRequestException(why:line 1:33
mismatched input '+' expecting K_WHERE)
at
org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
...
...
{code}
and an append of a prepared syntax like:
{code}
UPDATE testcollection SET L = L + ? WHERE k = 1
{code}
fails as follows:
{code}
java.sql.SQLSyntaxErrorException: InvalidRequestException(why:invalid operation
for non commutative columnfamily testcollection)
at
org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
...
...
{code}
was:
I can successfully update a List using the literal syntax:
{code}
UPDATE testcollection SET L = [98,99,100] + L WHERE k = 1;
{code}
And I can successfully upset a List using the Prepared syntax:
{code}
UPDATE testcollection SET L = ? WHERE k = 1
{code}
by providing a decoded ListInteger in the bind values.
But using the prepared syntax for an prepend like:
{code}
UPDATE testcollection SET L = ? + L WHERE k = 1
{code}
fails with the following message:
{code}
java.sql.SQLSyntaxErrorException: InvalidRequestException(why:line 1:33
mismatched input '+' expecting K_WHERE)
at
org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
...
...
{code}
and an append of a prepared syntax like:
{code}
UPDATE testcollection SET L = L + ? WHERE k = 1
{code}
fails as follows:
{code}
java.sql.SQLSyntaxErrorException: InvalidRequestException(why:invalid operation
for non commutative columnfamily testcollection)
at
org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
...
...
{code}
CQL3 does handle List append or prepend with a Prepared list
--
Key: CASSANDRA-4945
URL: https://issues.apache.org/jira/browse/CASSANDRA-4945
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 2
Environment: CQL3 Thrift methods (new)
Reporter: Rick Shaw
Priority: Minor
I can successfully update a List using the literal syntax:
{code}
UPDATE testcollection SET L = [98,99,100] + L WHERE k = 1;
{code}
And I can successfully upsert a List using the Prepared syntax:
{code}
UPDATE testcollection SET L = ? WHERE k = 1
{code}
by providing a decoded ListInteger in the bind values.
But using the prepared syntax for an prepend like:
{code}
UPDATE testcollection SET L = ? + L WHERE k = 1
{code}
fails with the following message:
{code}
java.sql.SQLSyntaxErrorException: InvalidRequestException(why:line 1:33
mismatched input '+' expecting K_WHERE)
at
org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
...
...
{code}
and an append of a prepared syntax like:
{code}
UPDATE testcollection SET L = L + ? WHERE k = 1
{code}
fails as follows:
{code}
java.sql.SQLSyntaxErrorException: InvalidRequestException(why:invalid
operation for non commutative columnfamily testcollection)
at
org.apache.cassandra.cql.jdbc.CassandraPreparedStatement.init(CassandraPreparedStatement.java:92)
...
...
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4878) No entry in TypesMap for InetAddressType
Rick Shaw created CASSANDRA-4878:
Summary: No entry in TypesMap for InetAddressType
Key: CASSANDRA-4878
URL: https://issues.apache.org/jira/browse/CASSANDRA-4878
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.2.0 beta 1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Fix For: 1.2.0 beta 2
{{InetAddressType}} was added to {{o.a.c.db.marshal}} and {{JdbcInetAddress}}
was added to {{o.a.c.cql.jdbc}} but no bridging entry was made for it in the
{{o.a.c.cql.jdbc.TypesMap}} Class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4878) No entry in TypesMap for InetAddressType
[
https://issues.apache.org/jira/browse/CASSANDRA-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-4878:
-
Attachment: 4878-v1.text
No entry in TypesMap for InetAddressType
Key: CASSANDRA-4878
URL: https://issues.apache.org/jira/browse/CASSANDRA-4878
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.2.0 beta 1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Fix For: 1.2.0 beta 2
Attachments: 4878-v1.text
{{InetAddressType}} was added to {{o.a.c.db.marshal}} and {{JdbcInetAddress}}
was added to {{o.a.c.cql.jdbc}} but no bridging entry was made for it in the
{{o.a.c.cql.jdbc.TypesMap}} Class.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[
https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450782#comment-13450782
]
Rick Shaw commented on CASSANDRA-4495:
--
I would suggest adding {{getString(ByteBuffer bytes)}} and {{getType()}} as
well. The JDBC specific stuff like {{isCurrency()}} and {{isSigned()}} are of
course easily moved over to client side.
Don't tie client side use of AbstractType to JDBC
-
Key: CASSANDRA-4495
URL: https://issues.apache.org/jira/browse/CASSANDRA-4495
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.3
We currently expose the AbstractType to java clients that want to reuse them
though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC
standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL
and will never be). Typically, there is a fair amount of the JDBC standard
that cannot be implemented with C*, and there is a number of specificity of
C* that are not in JDBC (typically the set and maps collections).
So I propose to extract simple type classes with just a compose and decompose
method (but without ties to jdbc, which would allow all the jdbc specific
method those types have) in the purpose of exporting that in a separate jar
for clients (we could put that in a org.apache.cassandra.type package for
instance). We could then deprecate the jdbc classes with basically the same
schedule than CQL2.
Let me note that this is *not* saying there shouldn't be a JDBC driver for
Cassandra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4623) Revise contents of clientutil.jar to reflect needs of new native protocol on client side
Rick Shaw created CASSANDRA-4623:
Summary: Revise contents of clientutil.jar to reflect needs of new
native protocol on client side
Key: CASSANDRA-4623
URL: https://issues.apache.org/jira/browse/CASSANDRA-4623
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.0
Reporter: Rick Shaw
Priority: Minor
The introduction of the native transport protocol in 1.2 will introduce the
need for many additional classes and methods to be visible from the Server side
jars in the form of the {{clientutil.jar}} in order to not require the full
Cassandra server dependancy tree.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418439#comment-13418439
]
Rick Shaw commented on CASSANDRA-4448:
--
I understand Jonathan's point, but I agree with Sylvain at least in the JDBC
case. It is especially true for a client like JDBC which really is not designed
to have any DB specific controls. It relies on the DBs implementation of
feature extensions in the script (CQL in this case). We are kinda stuck with
the design of the existing interfaces which would not offer much leeway in this
case.
CQL3: allow to define a per-cf default consistency level
Key: CASSANDRA-4448
URL: https://issues.apache.org/jira/browse/CASSANDRA-4448
Project: Cassandra
Issue Type: New Feature
Reporter: Sylvain Lebresne
Labels: cql3
Fix For: 1.2
One of the goal of CQL3 is that client library should not have to parse
queries to provide a good experience. In particular, that means such client
(that don't want to parse queries) won't be able to allow the user to define
a specific default read/write consistency level per-CF, forcing user to
specific the consistency level with every query, which is not very user
friendly.
This ticket suggests the addition of per-cf default read/write consitency
level. Typically the syntax would be:
{noformat}
CREATE TABLE foo (...)
WITH DEFAULT_READ_CONSISTENCY = QUORUM
AND DEFAULT_WRITE_CONSISTENCY = QUORUM
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
[ https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407449#comment-13407449 ] Rick Shaw commented on CASSANDRA-2478: -- The client community typically only uses cassandra-thrift and cassandra-clientutil.jar as well as some required dependencies like guava.jar. It appears as though there is no addition to the cassandra-clientutils jar (yet) to allow for client only access to the new transport libraries. It also appears that there are some thrift exceptions in the new code methods. Is there a plan to run the new native CQL protocol without the thrift libraries? Custom CQL protocol/transport - Key: CASSANDRA-2478 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Minor Labels: cql Fix For: 1.2 Attachments: cql_binary_protocol, cql_binary_protocol-v2 A custom wire protocol would give us the flexibility to optimize for our specific use-cases, and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would be significantly better). Additionally, RPC is bad fit here, and we'd do better to move in the direction of something that natively supports streaming. I don't think this is as daunting as it might seem initially. Utilizing an existing server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects would probably get us 80% of the way there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3647) Support set and map value types in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295111#comment-13295111
]
Rick Shaw commented on CASSANDRA-3647:
--
Why isn't the discard syntax as simple as:
{code}
SET L = L - [2, 3]
SET S = S - {4, 5}
SET M = M - {'asdf'}
{code}
I assume BTW that braces ([) are signifying a _position_ in an ordered list,
and Brackets ({) are signifying a _value_ (or label) and not a position.
Support set and map value types in CQL
--
Key: CASSANDRA-3647
URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Labels: cql
Fix For: 1.2
Composite columns introduce the ability to have arbitrarily nested data in a
Cassandra row. We should expose this through CQL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3647) Support set and map value types in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295178#comment-13295178
]
Rick Shaw commented on CASSANDRA-3647:
--
{quote}
But if you mean to use '-' for discard (of list and sets) and keep the DELETE
L[4] for the discard_idx (for list) and discard_by_key (for map), then I'm
good with that.
{quote}
I think DELETE L[4] makes sense for removing a list item by position (in this
context).
But I think in its Map context,
{code}
SET M = M - {'asdf'}
SET M = M - {'asdf', 'ghkl'}
{code}
seems appropriate to discard a Map entry by label.
I don't see any reason to remove map entries by position?
Support set and map value types in CQL
--
Key: CASSANDRA-3647
URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Assignee: Sylvain Lebresne
Labels: cql
Fix For: 1.2
Composite columns introduce the ability to have arbitrarily nested data in a
Cassandra row. We should expose this through CQL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3707) Add KeyspaceChange CqlResultType
[ https://issues.apache.org/jira/browse/CASSANDRA-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291015#comment-13291015 ] Rick Shaw commented on CASSANDRA-3707: -- Returning in a special type that only gets set when the script calls USE really only tells you what the DEFAULT KS is. Not what KS was used in the request (other than USE of course). That is because you can say SELECT x,y from KS.CF where key=10; now; where KS can override the currently set default from USE. Add KeyspaceChange CqlResultType Key: CASSANDRA-3707 URL: https://issues.apache.org/jira/browse/CASSANDRA-3707 Project: Cassandra Issue Type: Sub-task Components: API Reporter: Jonathan Ellis Assignee: satish babu krishnamoorthy Labels: cql Fix For: 1.1.2 High level clients want to handle failover and load balancing transparently to the application, which means not just connection pooling but moving an existing connection to another server if necessary. When this happens, the client needs to know what the active keyspace was before failover, so it can set it to the same one in the new connection. Currently some clients handle this by checking for SET KEYSPACE queries, which violates the design principle that clients shouldn't have to parse CQL. Adding a new CqlResultType (that is set in response to a SET KEYSPACE command) would make this unnecessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
[ https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13283664#comment-13283664 ] Rick Shaw commented on CASSANDRA-2478: -- My personal opinion is we will never get to a point where we need multiple KSs. But Multiple CFs (Tables) yes. The point is now in the current state of the returned meta-data we do not know _which_ KS or CF, even if there is only one, and I contend we have client calls that want to know that info. bikesheding on my part will now end. :) Custom CQL protocol/transport - Key: CASSANDRA-2478 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Minor Labels: cql Attachments: cql_binary_protocol A custom wire protocol would give us the flexibility to optimize for our specific use-cases, and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would be significantly better). Additionally, RPC is bad fit here, and we'd do better to move in the direction of something that natively supports streaming. I don't think this is as daunting as it might seem initially. Utilizing an existing server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects would probably get us 80% of the way there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
[ https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13283703#comment-13283703 ] Rick Shaw commented on CASSANDRA-2478: -- Much of the pressure in the corporate world I live in is from teams that are trying to use JDBC driver for C* in the same fashion and with the same BI, ETL and statistics tools (Talend, Informatica, Datastage, SPSS, SAS) as they do for relational solutions. Many of these tools are quite comprehensive in the information they can display and use, so they are heavy users of the metadata features of the driver. Returning no data for some functions often causes the tooling to just give up, not to use what they have. Custom CQL protocol/transport - Key: CASSANDRA-2478 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Minor Labels: cql Attachments: cql_binary_protocol A custom wire protocol would give us the flexibility to optimize for our specific use-cases, and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would be significantly better). Additionally, RPC is bad fit here, and we'd do better to move in the direction of something that natively supports streaming. I don't think this is as daunting as it might seem initially. Utilizing an existing server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects would probably get us 80% of the way there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
[ https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280986#comment-13280986 ] Rick Shaw commented on CASSANDRA-2478: -- Please consider returning the KS (schema) and CF (table) in the metadata returned with rows and a prepare. This will facilitate clients reporting this information in metadata commands from the client side for tools and the like. This information can not really be known without the fragile method of scanning the CQL because the context is always passed withing the script itself. And with the addition of KS.CF notation in CQL for the selected CF you can't really use the state of a USE to tell what the applicable KS is within the currently returned information. Custom CQL protocol/transport - Key: CASSANDRA-2478 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Eric Evans Assignee: Sylvain Lebresne Priority: Minor Labels: cql Attachments: cql_binary_protocol A custom wire protocol would give us the flexibility to optimize for our specific use-cases, and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would be significantly better). Additionally, RPC is bad fit here, and we'd do better to move in the direction of something that natively supports streaming. I don't think this is as daunting as it might seem initially. Utilizing an existing server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects would probably get us 80% of the way there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13281064#comment-13281064
]
Rick Shaw commented on CASSANDRA-2478:
--
re: KS/CF meetadata. As you say, JDBC/SQL can have resultset information from
many tables, which is why you can acquire that metadata information at the
column level. The {{ResultSetMetaData}} interface provides methods for
{{getSchemaName(column)}} and {{getTableName}} on a column by column basis. The
point is tools use these interfaces and methods heavily to deliver their
functionality.
Custom CQL protocol/transport
-
Key: CASSANDRA-2478
URL: https://issues.apache.org/jira/browse/CASSANDRA-2478
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Minor
Labels: cql
Attachments: cql_binary_protocol
A custom wire protocol would give us the flexibility to optimize for our
specific use-cases, and eliminate a troublesome dependency (I'm referring to
Thrift, but none of the others would be significantly better). Additionally,
RPC is bad fit here, and we'd do better to move in the direction of something
that natively supports streaming.
I don't think this is as daunting as it might seem initially. Utilizing an
existing server framework like Netty, combined with some copy-and-paste of
bits from other FLOSS projects would probably get us 80% of the way there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-2478) Custom CQL protocol/transport
[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13281064#comment-13281064
]
Rick Shaw edited comment on CASSANDRA-2478 at 5/22/12 5:42 PM:
---
re: KS/CF metadata. As you say, JDBC/SQL can have resultset information from
many tables, which is why you can acquire that metadata information at the
column level. The {{ResultSetMetaData}} interface provides methods for
{{getSchemaName(column)}} and {{getTableName(column)}} on a column-by-column
basis. The point is tools use these interfaces and methods heavily to deliver
their functionality and we will improve adoption of the Server and the Driver
if we can make the interface process for these tools deliver as much
information as practical.
was (Author: ardot):
re: KS/CF meetadata. As you say, JDBC/SQL can have resultset information
from many tables, which is why you can acquire that metadata information at the
column level. The {{ResultSetMetaData}} interface provides methods for
{{getSchemaName(column)}} and {{getTableName}} on a column by column basis. The
point is tools use these interfaces and methods heavily to deliver their
functionality.
Custom CQL protocol/transport
-
Key: CASSANDRA-2478
URL: https://issues.apache.org/jira/browse/CASSANDRA-2478
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Eric Evans
Assignee: Sylvain Lebresne
Priority: Minor
Labels: cql
Attachments: cql_binary_protocol
A custom wire protocol would give us the flexibility to optimize for our
specific use-cases, and eliminate a troublesome dependency (I'm referring to
Thrift, but none of the others would be significantly better). Additionally,
RPC is bad fit here, and we'd do better to move in the direction of something
that natively supports streaming.
I don't think this is as daunting as it might seem initially. Utilizing an
existing server framework like Netty, combined with some copy-and-paste of
bits from other FLOSS projects would probably get us 80% of the way there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4217) Easy access to column timestamps (and maybe ttl) during queries
[
https://issues.apache.org/jira/browse/CASSANDRA-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13267742#comment-13267742
]
Rick Shaw commented on CASSANDRA-4217:
--
Could this be the tipping point for a proposal to add functions to the CQL3
grammar and a plugin mechanism to define function methods?
Easy access to column timestamps (and maybe ttl) during queries
---
Key: CASSANDRA-4217
URL: https://issues.apache.org/jira/browse/CASSANDRA-4217
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 1.1.0
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.1.1
It would be interesting to allow accessing the timestamp/ttl of a column
though some syntax like
{noformat}
SELECT key, value, timestamp(value) FROM foo;
{noformat}
and the same for ttl.
I'll note that currently timestamp and ttl are returned in the resultset
because it includes thrift Column object, but adding such syntax would make
our future protocol potentially simpler as we wouldn't then have to care
about timestamps explicitely (and more compact in general as we would only
return timestamps when asked)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3244) JDBC CassandraConnection may lead to memory leak when used in a pool
[
https://issues.apache.org/jira/browse/CASSANDRA-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13113452#comment-13113452
]
Rick Shaw commented on CASSANDRA-3244:
--
Creating a {{Statement}} every time you need one is unnecessary but not
illegal. The assumption is the {{Statement}} is closed when Spring is done,
which should be just fine. The problem is the list in {{Connection}} _should_
be a list of open {{Statements}}. The implecation being that closing a
{{Statement}} removes itself from that list. Unfortunately this is not being
done.
The list is necessary. But it needs to be maintained by {{Statement}} because
only it knows when it is asked to close.
As a note this has nothing to do with pooling. The JDBC driver pooling
({{PooledConnection}}) will handle the issues around {{Statement}} creation and
does not engage the physical {{Connection}} so the connection can be reused
because none of that state is placed at the physical level and is therefore
reusable without closing it.
Thanks for catching this bug. I'll create a fix for this.
JDBC CassandraConnection may lead to memory leak when used in a pool
Key: CASSANDRA-3244
URL: https://issues.apache.org/jira/browse/CASSANDRA-3244
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 1.0.0
Reporter: Patricio Echague
Priority: Minor
I may be wrong here but I noticed that the implementations of
CassandraConnection#createStatement() and
CassandraConnection#prepareStatement() keep(cache) the created
Statement/PrepareStatement internally in a List.
They list is freed up only during CassandraConnection.close() which makes me
think that, if the connection object is used in a pool implementation, it
will lead to a memory leak as it will hold every single statement that is
used to interact with the DB until the connection gets closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3244) JDBC CassandraConnection may lead to memory leak when used in a pool
[
https://issues.apache.org/jira/browse/CASSANDRA-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13113452#comment-13113452
]
Rick Shaw edited comment on CASSANDRA-3244 at 9/23/11 2:04 PM:
---
Creating a {{Statement}} every time you need one is unnecessary but not
illegal. The assumption is the {{Statement}} is closed when Spring is done,
which should be just fine. The problem is the list in {{Connection}} _should_
be a list of open {{Statements}}. The implication being that closing a
{{Statement}} removes itself from that list. Unfortunately this is not being
done.
The list is necessary. But it needs to be maintained by {{Statement}} because
only it knows when it is asked to close.
As a note this has nothing to do with pooling. The JDBC driver pooling
({{PooledConnection}}) will handle the issues around {{Statement}} creation and
does not engage the physical {{Connection}} so the connection can be reused
because none of that state is placed at the physical level and is therefore
reusable without closing it.
Thanks for catching this bug. I'll create a fix for this.
was (Author: ardot):
Creating a {{Statement}} every time you need one is unnecessary but not
illegal. The assumption is the {{Statement}} is closed when Spring is done,
which should be just fine. The problem is the list in {{Connection}} _should_
be a list of open {{Statements}}. The implecation being that closing a
{{Statement}} removes itself from that list. Unfortunately this is not being
done.
The list is necessary. But it needs to be maintained by {{Statement}} because
only it knows when it is asked to close.
As a note this has nothing to do with pooling. The JDBC driver pooling
({{PooledConnection}}) will handle the issues around {{Statement}} creation and
does not engage the physical {{Connection}} so the connection can be reused
because none of that state is placed at the physical level and is therefore
reusable without closing it.
Thanks for catching this bug. I'll create a fix for this.
JDBC CassandraConnection may lead to memory leak when used in a pool
Key: CASSANDRA-3244
URL: https://issues.apache.org/jira/browse/CASSANDRA-3244
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 1.0.0
Reporter: Patricio Echague
Priority: Minor
I may be wrong here but I noticed that the implementations of
CassandraConnection#createStatement() and
CassandraConnection#prepareStatement() keep(cache) the created
Statement/PrepareStatement internally in a List.
They list is freed up only during CassandraConnection.close() which makes me
think that, if the connection object is used in a pool implementation, it
will lead to a memory leak as it will hold every single statement that is
used to interact with the DB until the connection gets closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3244) JDBC CassandraConnection may lead to memory leak when used in a pool
[
https://issues.apache.org/jira/browse/CASSANDRA-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13113452#comment-13113452
]
Rick Shaw edited comment on CASSANDRA-3244 at 9/23/11 2:11 PM:
---
Creating a {{Statement}} every time you need one is unnecessary but not
illegal. The assumption is the {{Statement}} is closed when Spring is done,
which should be just fine. The problem is the list in {{Connection}} _should_
be a list of open {{Statements}}. The implication being that closing a
{{Statement}} removes itself from that list. Unfortunately this is not being
done.
The list is necessary. But it needs to be maintained by {{Statement}} because
only it knows when it is asked to close.
Thanks for catching this bug. I'll create a fix for this.
was (Author: ardot):
Creating a {{Statement}} every time you need one is unnecessary but not
illegal. The assumption is the {{Statement}} is closed when Spring is done,
which should be just fine. The problem is the list in {{Connection}} _should_
be a list of open {{Statements}}. The implication being that closing a
{{Statement}} removes itself from that list. Unfortunately this is not being
done.
The list is necessary. But it needs to be maintained by {{Statement}} because
only it knows when it is asked to close.
As a note this has nothing to do with pooling. The JDBC driver pooling
({{PooledConnection}}) will handle the issues around {{Statement}} creation and
does not engage the physical {{Connection}} so the connection can be reused
because none of that state is placed at the physical level and is therefore
reusable without closing it.
Thanks for catching this bug. I'll create a fix for this.
JDBC CassandraConnection may lead to memory leak when used in a pool
Key: CASSANDRA-3244
URL: https://issues.apache.org/jira/browse/CASSANDRA-3244
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 1.0.0
Reporter: Patricio Echague
Priority: Minor
I may be wrong here but I noticed that the implementations of
CassandraConnection#createStatement() and
CassandraConnection#prepareStatement() keep(cache) the created
Statement/PrepareStatement internally in a List.
They list is freed up only during CassandraConnection.close() which makes me
think that, if the connection object is used in a pool implementation, it
will lead to a memory leak as it will hold every single statement that is
used to interact with the DB until the connection gets closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3241) CQL JDBC doesn't work with groovy.sql.Sql
[ https://issues.apache.org/jira/browse/CASSANDRA-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13112742#comment-13112742 ] Rick Shaw commented on CASSANDRA-3241: -- Could you please provide an example of its failing? What are the symptoms? What was the CQL (NOT SQL) that caused a failure? What results did you get using Java rather than Groovy? CQL JDBC doesn't work with groovy.sql.Sql - Key: CASSANDRA-3241 URL: https://issues.apache.org/jira/browse/CASSANDRA-3241 Project: Cassandra Issue Type: Bug Components: API Reporter: M Chen Priority: Minor Apparently there's something that groovy.sql.Sql doesn't like about the CQL JDBC driver. That seems a shame given how simple it is to use -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3240) CQL JDBC can only specify one host, thus doesn't support failover
[ https://issues.apache.org/jira/browse/CASSANDRA-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13112758#comment-13112758 ] Rick Shaw commented on CASSANDRA-3240: -- +1. Good addition to the nice to have list for next release. (after release coinsiding with 1.0.0 of server) CQL JDBC can only specify one host, thus doesn't support failover - Key: CASSANDRA-3240 URL: https://issues.apache.org/jira/browse/CASSANDRA-3240 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 0.8.6 Reporter: M Chen The CQL JDBC driver takes a connection string of the form jdbc:cassandra:user/pass@thrifthost:thriftport but 1. only one value for thrifthost is supported, 2. CQL JDBC does not appear to allow access to the ring members (e.g. so that as long as the specified host was alive long enough to get the ring, from then on some other logic can try different host:port values if needed). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3244) JDBC CassandraConnection may lead to memory leak when used in a pool
[
https://issues.apache.org/jira/browse/CASSANDRA-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13113139#comment-13113139
]
Rick Shaw commented on CASSANDRA-3244:
--
It keeps them on a list because {{Statement}} structures are associated with
the creating {{Connection}}. Closing the {{Connection}} closes all
{{Statement}} items. {{Statement}} structures are re-usable; you _usually_
only open one or maybe a few. But it does keep track of all you create. I
don't see how that implies a memory leak?
JDBC CassandraConnection may lead to memory leak when used in a pool
Key: CASSANDRA-3244
URL: https://issues.apache.org/jira/browse/CASSANDRA-3244
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 1.0.0
Reporter: Patricio Echague
Priority: Minor
I may be wrong here but I noticed that the implementations of
CassandraConnection#createStatement() and
CassandraConnection#prepareStatement() keep(cache) the created
Statement/PrepareStatement internally in a List.
They list is freed up only during CassandraConnection.close() which makes me
think that, if the connection object is used in a pool implementation, it
will lead to a memory leak as it will hold every single statement that is
used to interact with the DB until the connection gets closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3140) Expose server, api versions to CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107597#comment-13107597 ] Rick Shaw commented on CASSANDRA-3140: -- This approach seems very special case with positional keywords not handled in the parser/lexer. And introducing DUAL also seems out of C* character? What happened to functions? This will not be the only need for functions in CQL. I suggest we introduce functions to the CQL syntax where terms can occur and provide a plug-in way to handle their introduction similar to the way data types are handled. Expose server, api versions to CQL -- Key: CASSANDRA-3140 URL: https://issues.apache.org/jira/browse/CASSANDRA-3140 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Priority: Minor Fix For: 1.0.1 Attachments: 3140-patch.diff Need to expose the CQL api version; might as well include the server version while we're at it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3089:
-
Attachment: add-rowid-support-v3.txt
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Attachments: add-rowid-support-v2.txt, add-rowid-support-v3.txt,
add-rowid-support.txt
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3089:
-
Attachment: add-rowid-support-v4.txt
Right on both counts.
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Attachments: add-rowid-support-v2.txt, add-rowid-support-v3.txt,
add-rowid-support-v4.txt, add-rowid-support.txt
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3153) Add support for BigDecimal Java data type to JDBC ResultSet
Add support for BigDecimal Java data type to JDBC ResultSet
---
Key: CASSANDRA-3153
URL: https://issues.apache.org/jira/browse/CASSANDRA-3153
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Fix For: 0.8.6
This patch adds support for {{BigDecimal}} to the {{ResultSet}} using the
recently added {{DecimalType}} data type.
It supports translation from a column that contained the following Java (CQL)
datatypes:
- {{Long - (bigint)}}
- {{Double - (double)}}
- {{BigInteger - (varint)}}
- {{BigDecimal - (decimal)}}
- {{String - (ascii,text,varchar)}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3153) Add support for BigDecimal Java data type to JDBC ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3153:
-
Attachment: ResultSet-support-for-BigDecimal-v1.txt
Add support for BigDecimal Java data type to JDBC ResultSet
---
Key: CASSANDRA-3153
URL: https://issues.apache.org/jira/browse/CASSANDRA-3153
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC,
Fix For: 0.8.6
Attachments: ResultSet-support-for-BigDecimal-v1.txt
This patch adds support for {{BigDecimal}} to the {{ResultSet}} using the
recently added {{DecimalType}} data type.
It supports translation from a column that contained the following Java (CQL)
datatypes:
- {{Long - (bigint)}}
- {{Double - (double)}}
- {{BigInteger - (varint)}}
- {{BigDecimal - (decimal)}}
- {{String - (ascii,text,varchar)}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3153) Add support for BigDecimal Java data type to JDBC ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3153:
-
Issue Type: Sub-task (was: Improvement)
Parent: CASSANDRA-2876
Add support for BigDecimal Java data type to JDBC ResultSet
---
Key: CASSANDRA-3153
URL: https://issues.apache.org/jira/browse/CASSANDRA-3153
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC,
Fix For: 0.8.6
Attachments: ResultSet-support-for-BigDecimal-v1.txt
This patch adds support for {{BigDecimal}} to the {{ResultSet}} using the
recently added {{DecimalType}} data type.
It supports translation from a column that contained the following Java (CQL)
datatypes:
- {{Long - (bigint)}}
- {{Double - (double)}}
- {{BigInteger - (varint)}}
- {{BigDecimal - (decimal)}}
- {{String - (ascii,text,varchar)}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2883) Add Support for BigDecimal Java data type as the NumericType AbstractType
[
https://issues.apache.org/jira/browse/CASSANDRA-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2883:
-
Attachment: add-decimaltype-v1.txt
Add Support for BigDecimal Java data type as the NumericType AbstractType
---
Key: CASSANDRA-2883
URL: https://issues.apache.org/jira/browse/CASSANDRA-2883
Project: Cassandra
Issue Type: Sub-task
Components: Core
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: CQL, JDBC,, lhf
Fix For: 0.8.6
Attachments: add-decimaltype-v1.txt
The JDBC Driver suite needs support for {{BigDecimal}} to complete it's data
type support for {{ResultSet}} and {{PreparedStatement}}. This datatype could
also be used to represent numeric (non-integer) counter values. This is a
very simple addition to the collection of data types supported by Cassandra.
It is quite versatile like {{BigInteger}}. It can represent decimal numbers
of virtually any precision and scale. It is represented in Java as an
arbitrary precision integer unscaled value ( think {{IntegerType}} )and a
32-bit integer scale factor, which could be represented as a {{IntegerType}}
as well. This could share much of the logic from the {{BigInteger}}
({{IntegerType}}) implementation.
CQL would need to add a datatype (numeric?). Decimal literal support is
already provided in CQL.
This is low hanging fruit.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2883) Add Support for BigDecimal Java data type as the DecimalType AbstractType
[
https://issues.apache.org/jira/browse/CASSANDRA-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2883:
-
Description:
The JDBC Driver suite needs support for {{BigDecimal}} to complete it's data
type support for {{ResultSet}} and {{PreparedStatement}}. This datatype could
also be used to represent numeric (non-integer) counter values. This is a very
simple addition to the collection of data types supported by Cassandra. It is
quite versatile like {{BigInteger}}. It can represent decimal numbers of
virtually any precision and scale. It is represented in Java as an arbitrary
precision integer unscaled value ( think {{IntegerType}} )and a 32-bit integer
scale factor, which could be represented as a {{IntegerType}} as well. This
could share much of the logic from the {{BigInteger}} ({{IntegerType}})
implementation.
CQL would need to add a datatype (decimal?). Decimal literal support is already
provided in CQL.
This is low hanging fruit.
was:
The JDBC Driver suite needs support for {{BigDecimal}} to complete it's data
type support for {{ResultSet}} and {{PreparedStatement}}. This datatype could
also be used to represent numeric (non-integer) counter values. This is a very
simple addition to the collection of data types supported by Cassandra. It is
quite versatile like {{BigInteger}}. It can represent decimal numbers of
virtually any precision and scale. It is represented in Java as an arbitrary
precision integer unscaled value ( think {{IntegerType}} )and a 32-bit integer
scale factor, which could be represented as a {{IntegerType}} as well. This
could share much of the logic from the {{BigInteger}} ({{IntegerType}})
implementation.
CQL would need to add a datatype (numeric?). Decimal literal support is already
provided in CQL.
This is low hanging fruit.
Summary: Add Support for BigDecimal Java data type as the DecimalType
AbstractType (was: Add Support for BigDecimal Java data type as the
NumericType AbstractType)
Add Support for BigDecimal Java data type as the DecimalType AbstractType
---
Key: CASSANDRA-2883
URL: https://issues.apache.org/jira/browse/CASSANDRA-2883
Project: Cassandra
Issue Type: Sub-task
Components: Core
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: CQL, JDBC,, lhf
Fix For: 0.8.6
Attachments: add-decimaltype-v1.txt
The JDBC Driver suite needs support for {{BigDecimal}} to complete it's data
type support for {{ResultSet}} and {{PreparedStatement}}. This datatype could
also be used to represent numeric (non-integer) counter values. This is a
very simple addition to the collection of data types supported by Cassandra.
It is quite versatile like {{BigInteger}}. It can represent decimal numbers
of virtually any precision and scale. It is represented in Java as an
arbitrary precision integer unscaled value ( think {{IntegerType}} )and a
32-bit integer scale factor, which could be represented as a {{IntegerType}}
as well. This could share much of the logic from the {{BigInteger}}
({{IntegerType}}) implementation.
CQL would need to add a datatype (decimal?). Decimal literal support is
already provided in CQL.
This is low hanging fruit.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2883) Add Support for BigDecimal Java data type as the DecimalType AbstractType
[
https://issues.apache.org/jira/browse/CASSANDRA-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13098398#comment-13098398
]
Rick Shaw commented on CASSANDRA-2883:
--
I store a full 32 bit integer encoding for the scale part of the data into C*,
which is what the Java class {{BigDecimal}} supports. but for a scale factor
that is crazy huge. I could easily be talked into using just a byte to support
128 or 256 scale. that is still 256 digits after the decimal... The unscaled
value is stored like {{IntegerType}}.
Add Support for BigDecimal Java data type as the DecimalType AbstractType
---
Key: CASSANDRA-2883
URL: https://issues.apache.org/jira/browse/CASSANDRA-2883
Project: Cassandra
Issue Type: Sub-task
Components: Core
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: CQL, JDBC,, lhf
Fix For: 0.8.6
Attachments: add-decimaltype-v1.txt
The JDBC Driver suite needs support for {{BigDecimal}} to complete it's data
type support for {{ResultSet}} and {{PreparedStatement}}. This datatype could
also be used to represent numeric (non-integer) counter values. This is a
very simple addition to the collection of data types supported by Cassandra.
It is quite versatile like {{BigInteger}}. It can represent decimal numbers
of virtually any precision and scale. It is represented in Java as an
arbitrary precision integer unscaled value ( think {{IntegerType}} )and a
32-bit integer scale factor, which could be represented as a {{IntegerType}}
as well. This could share much of the logic from the {{BigInteger}}
({{IntegerType}}) implementation.
CQL would need to add a datatype (decimal?). Decimal literal support is
already provided in CQL.
This is low hanging fruit.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3089:
-
Attachment: add-rowid-support.txt
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Attachments: add-rowid-support.txt
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13098595#comment-13098595
]
Rick Shaw commented on CASSANDRA-3089:
--
Dh... Must have looked right past it...
v2 coming up.
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Attachments: add-rowid-support.txt
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3089:
-
Attachment: add-rowid-support-v2.txt
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Attachments: add-rowid-support-v2.txt, add-rowid-support.txt
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13098600#comment-13098600
]
Rick Shaw commented on CASSANDRA-3089:
--
I need a {{byte[]} returned as part of the interface so that is the immutable
value I take in as the constructor arg. But in hindsight I guess I could have
made that arg a BB; and then wrapped it in the getter call. Is that what you
are suggesting? (sorry to be thick).
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Attachments: add-rowid-support-v2.txt, add-rowid-support.txt
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13098600#comment-13098600
]
Rick Shaw edited comment on CASSANDRA-3089 at 9/7/11 5:23 AM:
--
I need a {{byte[]}} returned as part of the interface so that is the immutable
value I take in as the constructor arg. But in hindsight I guess I could have
made that arg a BB; and then wrapped it in the getter call. Is that what you
are suggesting? (sorry to be thick).
was (Author: ardot):
I need a {{byte[]} returned as part of the interface so that is the
immutable value I take in as the constructor arg. But in hindsight I guess I
could have made that arg a BB; and then wrapped it in the getter call. Is that
what you are suggesting? (sorry to be thick).
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Attachments: add-rowid-support-v2.txt, add-rowid-support.txt
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097178#comment-13097178
]
Rick Shaw commented on CASSANDRA-3091:
--
Let's close this in deference to CASSANDRA-2734, and get that into trunk.
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.6
Attachments: move-metadata-for decoder-to-statement-level-v1.txt,
move-metadata-for-decoder-to-statement-level-v2.txt
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen
to be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3140) Expose server, api versions to CQL
[ https://issues.apache.org/jira/browse/CASSANDRA-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097660#comment-13097660 ] Rick Shaw commented on CASSANDRA-3140: -- +1 for this approach. A generalized interface for methods that can occur as a pseudo-column would worth discussing. Expose server, api versions to CQL -- Key: CASSANDRA-3140 URL: https://issues.apache.org/jira/browse/CASSANDRA-3140 Project: Cassandra Issue Type: New Feature Reporter: Jonathan Ellis Priority: Minor Fix For: 1.0 Need to expose the CQL api version; might as well include the server version while we're at it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3135) Tighten class accessibility in JDBC Suite
[
https://issues.apache.org/jira/browse/CASSANDRA-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3135:
-
Attachment: (was: tighten-accessability.txt)
Tighten class accessibility in JDBC Suite
-
Key: CASSANDRA-3135
URL: https://issues.apache.org/jira/browse/CASSANDRA-3135
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC
Fix For: 0.8.5
Attachments: tighten-accessability.txt
Tighten up class accessibility by making classes in the suite that are not
intended to be instantiated by a client directly remove the {{public}}
modifier. In addition make abstract named classes use the {{abstract}}
modifier. And finally make methods that are not part of public interfaces but
shared in the package be marked {{protected}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3135) Tighten class accessibility in JDBC Suite
[
https://issues.apache.org/jira/browse/CASSANDRA-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3135:
-
Attachment: tighten-accessability.txt
Tighten class accessibility in JDBC Suite
-
Key: CASSANDRA-3135
URL: https://issues.apache.org/jira/browse/CASSANDRA-3135
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC
Fix For: 0.8.5
Attachments: tighten-accessability.txt
Tighten up class accessibility by making classes in the suite that are not
intended to be instantiated by a client directly remove the {{public}}
modifier. In addition make abstract named classes use the {{abstract}}
modifier. And finally make methods that are not part of public interfaces but
shared in the package be marked {{protected}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096915#comment-13096915
]
Rick Shaw commented on CASSANDRA-2474:
--
The keyword AS may be a bit confusing to SQL users. It is a optional keyword
that signifies that that the following word is to be taken has an alias for the
first word. In CQL context it would more appropriately be used for giving a
text label to a numeric (or whatever) column name. I readily admit I do not
really understand how this feature works. Even if it is used, it would seem you
would declare it in the reverse order? Like:
{code}
SELECT column_name AS alias FROM CF;
{code}
Could WITH be a substitute for AS in this compound context?
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.0
Attachments: screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[ https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096921#comment-13096921 ] Rick Shaw commented on CASSANDRA-2474: -- My point is that the familiar usage would be that the alias is the manufactured name that does not actually exist in the row and so it should be after the AS as opposed to before. Note too that in SQL the AS is optional, the alias is recognized positionally as following the column identifier if present. CQL support for compound columns Key: CASSANDRA-2474 URL: https://issues.apache.org/jira/browse/CASSANDRA-2474 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Assignee: Pavel Yaskevich Labels: cql Fix For: 1.0 Attachments: screenshot-1.jpg, screenshot-2.jpg For the most part, this boils down to supporting the specification of compound column names (the CQL syntax is colon-delimted terms), and then teaching the decoders (drivers) to create structures from the results. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095979#comment-13095979
]
Rick Shaw commented on CASSANDRA-2936:
--
+1
Lets get this baby in Trunk.
improve dependency situation between JDBC driver and Cassandra
--
Key: CASSANDRA-2936
URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Affects Versions: 0.8.1
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 1.0
Attachments:
v3-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt,
v3-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt,
v3-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt,
v3-0004-make-better-reuse-of-new-classes.txt, v3-0005-create-jar-file.txt
The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
despite the fact that it only (directly) uses a handful of Cassandra's
classes. In a perfect world, we'd break those classes out into their own jar
which both the JDBC driver and Cassandra (ala
{{apache-cassandra-$version.jar}}) could depend on. However, the classes
used directly don't fall out to anything that makes much sense
organizationally (short of creating a
{{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
when you take into account all of the transitive dependencies.
See CASSANDRA-2761 for more background, in particular
([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
and
[this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2474) CQL support for compound columns
[
https://issues.apache.org/jira/browse/CASSANDRA-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096100#comment-13096100
]
Rick Shaw commented on CASSANDRA-2474:
--
Star (*) would be better... And ? would conflict with {{PreparedStatement}}
type data binding.
CQL support for compound columns
Key: CASSANDRA-2474
URL: https://issues.apache.org/jira/browse/CASSANDRA-2474
Project: Cassandra
Issue Type: Sub-task
Components: API, Core
Reporter: Eric Evans
Assignee: Pavel Yaskevich
Labels: cql
Fix For: 1.0
Attachments: screenshot-1.jpg, screenshot-2.jpg
For the most part, this boils down to supporting the specification of
compound column names (the CQL syntax is colon-delimted terms), and then
teaching the decoders (drivers) to create structures from the results.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095489#comment-13095489
]
Rick Shaw commented on CASSANDRA-2936:
--
Sure.
improve dependency situation between JDBC driver and Cassandra
--
Key: CASSANDRA-2936
URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Affects Versions: 0.8.1
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 1.0
Attachments:
v2-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt,
v2-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt,
v2-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt,
v2-0004-make-better-reuse-of-new-classes.txt, v2-0005-create-jar-file.txt
The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
despite the fact that it only (directly) uses a handful of Cassandra's
classes. In a perfect world, we'd break those classes out into their own jar
which both the JDBC driver and Cassandra (ala
{{apache-cassandra-$version.jar}}) could depend on. However, the classes
used directly don't fall out to anything that makes much sense
organizationally (short of creating a
{{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
when you take into account all of the transitive dependencies.
See CASSANDRA-2761 for more background, in particular
([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
and
[this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095544#comment-13095544
]
Rick Shaw commented on CASSANDRA-2936:
--
These patches do not seem to be based on the SVN trunk?
all the files in the patches seem to start: ...b/src/java/org/apache/... not
...b/java/src/org/apache/...
Do I need to substitute the proper target path in all the patch files? (sorry
to the novice in patching question)
improve dependency situation between JDBC driver and Cassandra
--
Key: CASSANDRA-2936
URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Affects Versions: 0.8.1
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 1.0
Attachments:
v2-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt,
v2-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt,
v2-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt,
v2-0004-make-better-reuse-of-new-classes.txt, v2-0005-create-jar-file.txt
The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
despite the fact that it only (directly) uses a handful of Cassandra's
classes. In a perfect world, we'd break those classes out into their own jar
which both the JDBC driver and Cassandra (ala
{{apache-cassandra-$version.jar}}) could depend on. However, the classes
used directly don't fall out to anything that makes much sense
organizationally (short of creating a
{{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
when you take into account all of the transitive dependencies.
See CASSANDRA-2761 for more background, in particular
([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
and
[this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095551#comment-13095551
]
Rick Shaw commented on CASSANDRA-2936:
--
An up to date C* source tree would have the directory format
trunk/drivers/src/java/... not java/src?
improve dependency situation between JDBC driver and Cassandra
--
Key: CASSANDRA-2936
URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Affects Versions: 0.8.1
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 1.0
Attachments:
v2-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt,
v2-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt,
v2-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt,
v2-0004-make-better-reuse-of-new-classes.txt, v2-0005-create-jar-file.txt
The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
despite the fact that it only (directly) uses a handful of Cassandra's
classes. In a perfect world, we'd break those classes out into their own jar
which both the JDBC driver and Cassandra (ala
{{apache-cassandra-$version.jar}}) could depend on. However, the classes
used directly don't fall out to anything that makes much sense
organizationally (short of creating a
{{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
when you take into account all of the transitive dependencies.
See CASSANDRA-2761 for more background, in particular
([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
and
[this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095558#comment-13095558
]
Rick Shaw commented on CASSANDRA-2936:
--
I am trying to do it in Eclipse from the SVN plugin. I guess I'll switch to
CLI. But I thought there would be a shortcut to substitute my specific target
path for the apparent git path. And I was concerned that the current patch set
seems to have a different path near the root: using src/java not java/src.
Sorry to take up valuable time. I'll work through in... Thanx.
improve dependency situation between JDBC driver and Cassandra
--
Key: CASSANDRA-2936
URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Affects Versions: 0.8.1
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 1.0
Attachments:
v2-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt,
v2-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt,
v2-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt,
v2-0004-make-better-reuse-of-new-classes.txt, v2-0005-create-jar-file.txt
The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
despite the fact that it only (directly) uses a handful of Cassandra's
classes. In a perfect world, we'd break those classes out into their own jar
which both the JDBC driver and Cassandra (ala
{{apache-cassandra-$version.jar}}) could depend on. However, the classes
used directly don't fall out to anything that makes much sense
organizationally (short of creating a
{{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
when you take into account all of the transitive dependencies.
See CASSANDRA-2761 for more background, in particular
([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
and
[this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2936) improve dependency situation between JDBC driver and Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095567#comment-13095567
]
Rick Shaw commented on CASSANDRA-2936:
--
Thats what I needed. Sorry for my naivete. I'll get on it immediately.
improve dependency situation between JDBC driver and Cassandra
--
Key: CASSANDRA-2936
URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Affects Versions: 0.8.1
Reporter: Eric Evans
Assignee: Eric Evans
Priority: Minor
Labels: cql
Fix For: 1.0
Attachments:
v2-0001-CASSANDRA-2936-create-package-for-CQL-term-marshaling.txt,
v2-0002-convert-drivers-and-tests-to-o.a.c.cql.term.txt,
v2-0003-remove-extraneous-methods-from-o.a.c.db.marshal-classe.txt,
v2-0004-make-better-reuse-of-new-classes.txt, v2-0005-create-jar-file.txt
The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
despite the fact that it only (directly) uses a handful of Cassandra's
classes. In a perfect world, we'd break those classes out into their own jar
which both the JDBC driver and Cassandra (ala
{{apache-cassandra-$version.jar}}) could depend on. However, the classes
used directly don't fall out to anything that makes much sense
organizationally (short of creating a
{{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
when you take into account all of the transitive dependencies.
See CASSANDRA-2761 for more background, in particular
([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
and
[this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2734) JDBC driver assumes schema is constant for the duration of the connection
[
https://issues.apache.org/jira/browse/CASSANDRA-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094103#comment-13094103
]
Rick Shaw commented on CASSANDRA-2734:
--
Are you saying you would return a JDBC {{ResultSet}} interface from a CQL call,
or enough schema information to let {{Statement}} and {{ResultSet}} do a more
complete job on the client side?
JDBC driver assumes schema is constant for the duration of the connection
-
Key: CASSANDRA-2734
URL: https://issues.apache.org/jira/browse/CASSANDRA-2734
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8.0
Reporter: Cathy Daw
Assignee: Jonathan Ellis
Priority: Minor
Labels: cql
Fix For: 1.0
*The following statement fails when used with a Statement or
PreparedStatement*
{code}
res = stmt.executeQuery(SELECT bar FROM users);
res.next();
{code}
*Error Message*
{code}
[junit] Testcase: simpleSelect(com.datastax.cql.reproBugTest):Caused
an ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at
org.apache.cassandra.cql.jdbc.ColumnDecoder.makeKeyColumn(ColumnDecoder.java:136)
[junit] at
org.apache.cassandra.cql.jdbc.CResultSet.next(CResultSet.java:388)
[junit] at
com.datastax.cql.reproBugTest.simpleSelect(reproBugTest.java:57)
[junit]
[junit]
[junit] Test com.datastax.cql.reproBugTest FAILED
{code}
*Here is a quick repro. Showing that res.next() works with other statements
but not select.*
_Also notice that ResultSet.getMetaData().getColumnCount() always returns
zero._
_I noticed in the existing driver tests similar test cases, so not sure the
issue._
*Steps to run script*
* you will need to drop this in your test directory
* change the package declaration
* ant test -Dtest.name=reproBugTest
{code}
package com.datastax.cql;
import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.junit.Test;
public class reproBugTest {
@Test
public void simpleSelect() throws Exception {
Connection connection = null;
ResultSet res;
Statement stmt;
int colCount = 0;
try {
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
// Check create keyspace
connection =
DriverManager.getConnection(jdbc:cassandra:root/root@127.0.0.1:9160/default);
stmt = connection.createStatement();
try {
System.out.println(Running DROP KS Statement);
res = stmt.executeQuery(DROP KEYSPACE ks1);
res.next();
System.out.println(Running CREATE KS Statement);
res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
res.next();
} catch (SQLException e) {
if (e.getMessage().startsWith(Keyspace does not exist))
{
res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
}
}
connection.close();
// Run Test
connection =
DriverManager.getConnection(jdbc:cassandra:root/root@127.0.0.1:9160/ks1);
stmt = connection.createStatement();
System.out.print(Running CREATE CF Statement);
res = stmt.executeQuery(CREATE COLUMNFAMILY users (KEY varchar
PRIMARY KEY, password varchar, gender varchar, session_token varchar, state
varchar, birth_year bigint));
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.next();
System.out.print(Running INSERT Statement);
res = stmt.executeQuery(INSERT INTO users (KEY, password) VALUES
('user1', 'ch@nge'));
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.next();
System.out.print(Running SELECT Statement);
res = stmt.executeQuery(SELECT bar FROM users);
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.getRow();
res.next();
connection.close();
[jira] [Commented] (CASSANDRA-2734) JDBC driver assumes schema is constant for the duration of the connection
[
https://issues.apache.org/jira/browse/CASSANDRA-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094112#comment-13094112
]
Rick Shaw commented on CASSANDRA-2734:
--
Cool!
JDBC driver assumes schema is constant for the duration of the connection
-
Key: CASSANDRA-2734
URL: https://issues.apache.org/jira/browse/CASSANDRA-2734
Project: Cassandra
Issue Type: Sub-task
Components: API
Affects Versions: 0.8.0
Reporter: Cathy Daw
Assignee: Jonathan Ellis
Priority: Minor
Labels: cql
Fix For: 1.0
*The following statement fails when used with a Statement or
PreparedStatement*
{code}
res = stmt.executeQuery(SELECT bar FROM users);
res.next();
{code}
*Error Message*
{code}
[junit] Testcase: simpleSelect(com.datastax.cql.reproBugTest):Caused
an ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at
org.apache.cassandra.cql.jdbc.ColumnDecoder.makeKeyColumn(ColumnDecoder.java:136)
[junit] at
org.apache.cassandra.cql.jdbc.CResultSet.next(CResultSet.java:388)
[junit] at
com.datastax.cql.reproBugTest.simpleSelect(reproBugTest.java:57)
[junit]
[junit]
[junit] Test com.datastax.cql.reproBugTest FAILED
{code}
*Here is a quick repro. Showing that res.next() works with other statements
but not select.*
_Also notice that ResultSet.getMetaData().getColumnCount() always returns
zero._
_I noticed in the existing driver tests similar test cases, so not sure the
issue._
*Steps to run script*
* you will need to drop this in your test directory
* change the package declaration
* ant test -Dtest.name=reproBugTest
{code}
package com.datastax.cql;
import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.junit.Test;
public class reproBugTest {
@Test
public void simpleSelect() throws Exception {
Connection connection = null;
ResultSet res;
Statement stmt;
int colCount = 0;
try {
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
// Check create keyspace
connection =
DriverManager.getConnection(jdbc:cassandra:root/root@127.0.0.1:9160/default);
stmt = connection.createStatement();
try {
System.out.println(Running DROP KS Statement);
res = stmt.executeQuery(DROP KEYSPACE ks1);
res.next();
System.out.println(Running CREATE KS Statement);
res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
res.next();
} catch (SQLException e) {
if (e.getMessage().startsWith(Keyspace does not exist))
{
res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
}
}
connection.close();
// Run Test
connection =
DriverManager.getConnection(jdbc:cassandra:root/root@127.0.0.1:9160/ks1);
stmt = connection.createStatement();
System.out.print(Running CREATE CF Statement);
res = stmt.executeQuery(CREATE COLUMNFAMILY users (KEY varchar
PRIMARY KEY, password varchar, gender varchar, session_token varchar, state
varchar, birth_year bigint));
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.next();
System.out.print(Running INSERT Statement);
res = stmt.executeQuery(INSERT INTO users (KEY, password) VALUES
('user1', 'ch@nge'));
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.next();
System.out.print(Running SELECT Statement);
res = stmt.executeQuery(SELECT bar FROM users);
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.getRow();
res.next();
connection.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092862#comment-13092862
]
Rick Shaw commented on CASSANDRA-3091:
--
It is cached in the statement as well so it will do the fetch one time when the
statement is first created and then just check the cache to make sure the
metadata is there and attempt a reload only if it does not find it. Once you
acquire a statement you usually hold on to it for the duration of your task. So
not significantly more than if you acquired a connection.
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.5
Attachments: move-metadata-for decoder-to-statement-level-v1.txt,
move-metadata-for-decoder-to-statement-level-v2.txt
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen
to be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092869#comment-13092869
]
Rick Shaw commented on CASSANDRA-3091:
--
In JDBC you can pool both!
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.5
Attachments: move-metadata-for decoder-to-statement-level-v1.txt,
move-metadata-for-decoder-to-statement-level-v2.txt
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen
to be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092877#comment-13092877
]
Rick Shaw commented on CASSANDRA-3091:
--
This approach puts the caller in better control of when the refreshed data is
acquired. It is easy to close one statement and reacquire. If you do with a
pooled resource it will not reacquire until the physical connection goes stale
from no use. On a busy system and when the app acquires the connection itself
infrequently, it may be a long time before you see a new refreshed set of data
in a new connection.
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.5
Attachments: move-metadata-for decoder-to-statement-level-v1.txt,
move-metadata-for-decoder-to-statement-level-v2.txt
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen
to be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092904#comment-13092904
]
Rick Shaw commented on CASSANDRA-3091:
--
I think (in retrospect) I would clear the cache upon close for either approach
so it would force a reload on acquisition, so that may be a red herring. I
think the only issue is: is doing it in the statement any more expensive in
time vs the advantage of a more current set of metadata? If the general usage
pattern is to open a lot of statements vs opening connections, then it is
undeniably more time intensive to do in statement but the benefit is you would
SELDOM have mismatch with the state of the server. If the average use is to
open a connection and then open a statement and do all accesses on the
statement then its not really a penalty in time and the additional ability to
do a reload on demand when needed in the statement (at the price of the boolean
check for CF metadata) is a win.
If you think this is ill advised having said all that :) we can close the
ticket, and I'll put some of the additional cleanup of the {{ColumnDecoder}} in
another related patch at a later date. I could also look to see if I could get
the check for missing metadata against the data hanging off connection, but
that's along way from {{ColumnDecoder}} where the info is needed.
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.5
Attachments: move-metadata-for decoder-to-statement-level-v1.txt,
move-metadata-for-decoder-to-statement-level-v2.txt
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen
to be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2884) CQL processing engine should provide server side data binding to pre-compiled CQL scripts
[ https://issues.apache.org/jira/browse/CASSANDRA-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093372#comment-13093372 ] Rick Shaw commented on CASSANDRA-2884: -- Yes. Seems like it to me as well. CQL processing engine should provide server side data binding to pre-compiled CQL scripts - Key: CASSANDRA-2884 URL: https://issues.apache.org/jira/browse/CASSANDRA-2884 Project: Cassandra Issue Type: New Feature Components: API Affects Versions: 0.8.1 Reporter: Rick Shaw Labels: API, CQL Fix For: 1.0 The notion of Prepared statements is derived from JDBC lore, but is equally useful for the other supported clients of CQL. In order to support server-side binding and pre-compiled code referenceable from the client side, the API (currently Thrift based) will need to be enhanced to pass both script (CQL) and the binding arguments to the server. In addition the parser will need to recognize the place holders for the bound variables (?). And the product of the parse will need to be savable and a reference or handle will need to be returned to the client side caller. The execution of C* API calls will need to be moved from the parsers action routines where it is currently executed as the script is parsed, and moved to another execution engine that calls API methods and uses the bound variables and the stored pre-compiled code to drive the process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3091:
-
Attachment: move-metadata-for-decoder-to-statement-level-v2.txt
v2 of patch adds better clarity to the non-interface methods of
{{CassandraConnection}} by making them package {{protected}}.
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.5
Attachments: move-metadata-for decoder-to-statement-level-v1.txt,
move-metadata-for-decoder-to-statement-level-v2.txt
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen
to be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2664) JDBC driver for CQL works only with Strings
[
https://issues.apache.org/jira/browse/CASSANDRA-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092517#comment-13092517
]
Rick Shaw commented on CASSANDRA-2664:
--
This appears closable... There is no such method in the current code and all
current methods in the {{PreparedStatement}} unit test succeed.
JDBC driver for CQL works only with Strings
---
Key: CASSANDRA-2664
URL: https://issues.apache.org/jira/browse/CASSANDRA-2664
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 0.8.0 beta 2
Environment: It happens to JDBC driver for both: 0.8.0 beta version
and 0.8.0-rc1
Reporter: Roman Kuzmin
Labels: cql, jdbc
Original Estimate: 4h
Remaining Estimate: 4h
CassandraPreparedStatement.java
Line 141:
String stringParam = makeCqlString(type.toString(param));
It crashes with ClassCastException for all parameters that are not Strings.
It is because, when the method applyDualBindings is called from makeUpdate it
ALWAYS get one and the same type as parameter. In fact it is a comparator
of columnfamily itself.
In my case it is UTF8Type. And UTF8Type.toString() method expects only
Strings.
I think it must be column-dependent.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2883) Add Support for BigDecimal Java data type as the NumericType AbstractType
[
https://issues.apache.org/jira/browse/CASSANDRA-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw reassigned CASSANDRA-2883:
Assignee: Rick Shaw
Add Support for BigDecimal Java data type as the NumericType AbstractType
---
Key: CASSANDRA-2883
URL: https://issues.apache.org/jira/browse/CASSANDRA-2883
Project: Cassandra
Issue Type: Sub-task
Components: Core
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: CQL, JDBC,, lhf
Fix For: 0.8.5
The JDBC Driver suite needs support for {{BigDecimal}} to complete it's data
type support for {{ResultSet}} and {{PreparedStatement}}. This datatype could
also be used to represent numeric (non-integer) counter values. This is a
very simple addition to the collection of data types supported by Cassandra.
It is quite versatile like {{BigInteger}}. It can represent decimal numbers
of virtually any precision and scale. It is represented in Java as an
arbitrary precision integer unscaled value ( think {{IntegerType}} )and a
32-bit integer scale factor, which could be represented as a {{IntegerType}}
as well. This could share much of the logic from the {{BigInteger}}
({{IntegerType}}) implementation.
CQL would need to add a datatype (numeric?). Decimal literal support is
already provided in CQL.
This is low hanging fruit.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092324#comment-13092324
]
Rick Shaw commented on CASSANDRA-3089:
--
The JDBC {{RowId}} assumes it can be compared with another {{RowId}} for
identity. The stated specification says that they are the same if they have the
same logical/physical identity and they come from the same Table and Dataset.
This implies the same CF and KS as well as the matching row index value. To
illustrate: if a rows in two CFs A, and B had {{Integer}} indexes, it could
easily happen that both CFs had a row with the index value of integer 1. But a
{{RowId}} from CF A containing 1 and a {{RowId}} containing 1 from CF B
should not report being equal because they come from different CFs.
However it is not common practice to store the CF and the KS along with a row
index when creating secondary indexes either ad-hoc or through C* internal
tooling. The KS can be implied as the current KS because it is not useful in C*
for it to be anything but the current KS, although I guess it is _possible_ as
well. But the CF can not really be known unless we create a new {{RowIdType}},
and that seems like it would never really be used in common practice anyway.
The alternative is to document that we do not really comply, and just use
equality of the byte value contents of the contained in the column's value.
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Fix For: 0.8.5
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen to
be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3091:
-
Attachment: move-metadata-for decoder-to-statement-level-v1.txt
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.5
Attachments: move-metadata-for decoder-to-statement-level-v1.txt
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen
to be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build
[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090441#comment-13090441
]
Rick Shaw commented on CASSANDRA-2761:
--
I don't see any driver code in the move? The {{/driver}} sub-directory now
exists but there is nothing underneath?
JDBC driver does not build
--
Key: CASSANDRA-2761
URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
Fix For: 1.0
Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt
Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2926) The JDBC Suite should provide a simple DatabaseMetaData implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13089114#comment-13089114
]
Rick Shaw commented on CASSANDRA-2926:
--
With 176 methods, what are the odds I guess right on all :) So let me say first
off, I be glad to change any values. But here are my excuses...
- allTablesAreSelectable -- references whether the user can use all the tables
returned by {{getTables()}}, which is not currently supported. We return an
empty {{ResultSet}}. Since we did not return any tables in the result from that
method call I went with {{false}}.
- getMaxBinaryLiteralLength
- getMaxCharLiteralLength
Zero (0) implies no limit or the limit was unknown, and as I did not know of
any such limit except practicality I went with zero. I could not find any
documented limits but if I missed them somewhere I will gladly put them in.
- [own|others][Deletes|Inserts|Updates]AreVisible -- no good excuse for them
being {{false}}. I must have been confused by all the questions running
together. I will make them {{true}} in the subsequent patch.
- supportsUnion -- There is no {{UNION}} statement type in CQL? I answered
{{false}}?
The JDBC Suite should provide a simple DatabaseMetaData implementation
--
Key: CASSANDRA-2926
URL: https://issues.apache.org/jira/browse/CASSANDRA-2926
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1, 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: CQL, JDBC
Fix For: 0.8.5
Attachments: add-database-metadata-v1.txt
The {{DatabaseMetaData}} interface provides access to meta-data information
about the JDBC Driver implementation and the DB that it supports. This class
would usually be used by tooling to discover the extended capabilities of the
Driver Suite.
A very basic implementation is planned initially. Non-static metadata about
Keyspaces and Column Families can be provided in enhanced versions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2926) The JDBC Suite should provide a simple DatabaseMetaData implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13089114#comment-13089114
]
Rick Shaw edited comment on CASSANDRA-2926 at 8/22/11 10:57 PM:
With 176 methods, what are the odds I guess right on all :) So let me say first
off, I be glad to change any values. But here are my excuses...
- allTablesAreSelectable -- references whether the user can use all the tables
returned by {{getTables()}}, which is not currently supported. We return an
empty {{ResultSet}}. Since we did not return any tables in the result from that
method call I went with {{false}}.
- getMaxBinaryLiteralLength
- getMaxCharLiteralLength
Zero (0) implies no limit or the limit was unknown, and as I did not know of
any such limit except practicality I went with zero. I could not find any
documented limits but if I missed them somewhere I will gladly put them in.
- [own|others][Deletes|Inserts|Updates]AreVisible -- no good excuse for them
being {{false}}. I must have been confused by all the questions running
together. I will make them {{true}} in the subsequent patch.
- supportsUnion -- There is no {{UNION}} operator in CQL? I answered {{false}}?
was (Author: ardot):
With 176 methods, what are the odds I guess right on all :) So let me say
first off, I be glad to change any values. But here are my excuses...
- allTablesAreSelectable -- references whether the user can use all the tables
returned by {{getTables()}}, which is not currently supported. We return an
empty {{ResultSet}}. Since we did not return any tables in the result from that
method call I went with {{false}}.
- getMaxBinaryLiteralLength
- getMaxCharLiteralLength
Zero (0) implies no limit or the limit was unknown, and as I did not know of
any such limit except practicality I went with zero. I could not find any
documented limits but if I missed them somewhere I will gladly put them in.
- [own|others][Deletes|Inserts|Updates]AreVisible -- no good excuse for them
being {{false}}. I must have been confused by all the questions running
together. I will make them {{true}} in the subsequent patch.
- supportsUnion -- There is no {{UNION}} statement type in CQL? I answered
{{false}}?
The JDBC Suite should provide a simple DatabaseMetaData implementation
--
Key: CASSANDRA-2926
URL: https://issues.apache.org/jira/browse/CASSANDRA-2926
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1, 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: CQL, JDBC
Fix For: 0.8.5
Attachments: add-database-metadata-v1.txt
The {{DatabaseMetaData}} interface provides access to meta-data information
about the JDBC Driver implementation and the DB that it supports. This class
would usually be used by tooling to discover the extended capabilities of the
Driver Suite.
A very basic implementation is planned initially. Non-static metadata about
Keyspaces and Column Families can be provided in enhanced versions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3052) CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3052:
-
Attachment: statement-improper-result.txt
Patch checks to make sure the intended result is returned from the various
{{execute}} method variants.
CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
Key: CASSANDRA-3052
URL: https://issues.apache.org/jira/browse/CASSANDRA-3052
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.4
Reporter: Cathy Daw
Labels: JDBC, cql
Fix For: 0.8.5
Attachments: statement-improper-result.txt
This test script used to work until I upgraded the jdbc driver to 1.0.4.
*CQL 1.0.4*: apache-cassandra-cql-1.0.4-SNAPSHOT.jar build at revision 1158979
*Repro Script*:
* drop in test directory, change package declaration and run: ant test
-Dtest.name=resultSetNPE
* The script gives you a NullPointerException when you uncomment out the
following lines after a CREATE or INSERT statement.
{code}
colCount = res.getMetaData().getColumnCount();
res.next();
{code}
* Please note that there is no need to comment out those lines if a SELECT
statement was run prior.
{code}
package com.datastax.bugs;
import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.junit.Test;
public class resultSetNPE {
@Test
public void createKS() throws Exception {
Connection initConn = null;
Connection connection = null;
ResultSet res;
Statement stmt;
int colCount = 0;
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
// Check create keyspace
initConn =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/default);
stmt = initConn.createStatement();
try {
System.out.println(Running DROP KS Statement);
res = stmt.executeQuery(DROP KEYSPACE ks1);
// res.next();
} catch (SQLException e) {
if (e.getMessage().startsWith(Keyspace does not exist))
{
// Do nothing - this just means you tried to drop something
that was not there.
// res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
}
}
System.out.println(Running CREATE KS Statement);
res = stmt.executeQuery(CREATE KEYSPACE ks1 with strategy_class =
'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
// res.next();
initConn.close();
}
@Test
public void createCF() throws Exception
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
int colCount = 0;
Connection connection =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1);
Statement stmt = connection.createStatement();
System.out.print(Running CREATE CF Statement);
ResultSet res = stmt.executeQuery(CREATE COLUMNFAMILY users (KEY
varchar PRIMARY KEY, password varchar, gender varchar, session_token varchar,
state varchar, birth_year bigint));
//colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
//res.next();
connection.close();
}
@Test
public void simpleSelect() throws Exception
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
int colCount = 0;
Connection connection =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1);
Statement stmt = connection.createStatement();
System.out.print(Running INSERT Statement);
ResultSet res = stmt.executeQuery(INSERT INTO users (KEY, password)
VALUES ('user1', 'ch@nge'));
//colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
//res.next();
System.out.print(Running SELECT Statement);
res = stmt.executeQuery(SELECT KEY, gender, state FROM users);
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.getRow();
res.next();
connection.close();
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
[jira] [Updated] (CASSANDRA-2926) The JDBC Suite should provide a simple DatabaseMetaData implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2926:
-
Attachment: add-database-metadata-v1.txt
Minimal support for JDBC Tooling.
This Class will eventually provide the JDBC support for describing Column
Families and Keyspaces.
The JDBC Suite should provide a simple DatabaseMetaData implementation
--
Key: CASSANDRA-2926
URL: https://issues.apache.org/jira/browse/CASSANDRA-2926
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: CQL, JDBC
Fix For: 0.8.5
Attachments: add-database-metadata-v1.txt
The {{DatabaseMetaData}} interface provides access to meta-data information
about the JDBC Driver implementation and the DB that it supports. This class
would usually be used by tooling to discover the extended capabilities of the
Driver Suite.
A very basic implementation is planned initially. Non-static metadata about
Keyspaces and Column Families can be provided in enhanced versions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3052) CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087995#comment-13087995
]
Rick Shaw commented on CASSANDRA-3052:
--
The spec implies that {{executeUpdate()}} is the correct method for CQL/SQL
commands like {{CREATE, INSERT,UPDATE,DELETE}}.
It also implies that the check is to be done on the returned result. In the
case of {{executeQuery()}} an {{SQLException}} should be thrown if a
{{ResultSet}} is not returned by the server. In the case of {{executeUpdate()}}
return an error if a {{int}} update count is not returned.
We have an inconsistent solution in place and I'm currently working on a patch.
CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
Key: CASSANDRA-3052
URL: https://issues.apache.org/jira/browse/CASSANDRA-3052
Project: Cassandra
Issue Type: Bug
Reporter: Cathy Daw
Labels: cql
This test script used to work until I upgraded the jdbc driver to 1.0.4.
*CQL 1.0.4*: apache-cassandra-cql-1.0.4-SNAPSHOT.jar build at revision 1158979
*Repro Script*:
* drop in test directory, change package declaration and run: ant test
-Dtest.name=resultSetNPE
* The script gives you a NullPointerException when you uncomment out the
following lines after a CREATE or INSERT statement.
{code}
colCount = res.getMetaData().getColumnCount();
res.next();
{code}
* Please note that there is no need to comment out those lines if a SELECT
statement was run prior.
{code}
package com.datastax.bugs;
import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.junit.Test;
public class resultSetNPE {
@Test
public void createKS() throws Exception {
Connection initConn = null;
Connection connection = null;
ResultSet res;
Statement stmt;
int colCount = 0;
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
// Check create keyspace
initConn =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/default);
stmt = initConn.createStatement();
try {
System.out.println(Running DROP KS Statement);
res = stmt.executeQuery(DROP KEYSPACE ks1);
// res.next();
} catch (SQLException e) {
if (e.getMessage().startsWith(Keyspace does not exist))
{
// Do nothing - this just means you tried to drop something
that was not there.
// res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
}
}
System.out.println(Running CREATE KS Statement);
res = stmt.executeQuery(CREATE KEYSPACE ks1 with strategy_class =
'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
// res.next();
initConn.close();
}
@Test
public void createCF() throws Exception
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
int colCount = 0;
Connection connection =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1);
Statement stmt = connection.createStatement();
System.out.print(Running CREATE CF Statement);
ResultSet res = stmt.executeQuery(CREATE COLUMNFAMILY users (KEY
varchar PRIMARY KEY, password varchar, gender varchar, session_token varchar,
state varchar, birth_year bigint));
//colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
//res.next();
connection.close();
}
@Test
public void simpleSelect() throws Exception
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
int colCount = 0;
Connection connection =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1);
Statement stmt = connection.createStatement();
System.out.print(Running INSERT Statement);
ResultSet res = stmt.executeQuery(INSERT INTO users (KEY, password)
VALUES ('user1', 'ch@nge'));
//colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
//res.next();
System.out.print(Running SELECT Statement);
res = stmt.executeQuery(SELECT KEY, gender, state FROM users);
colCount = res.getMetaData().getColumnCount();
[jira] [Commented] (CASSANDRA-3052) CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086748#comment-13086748
]
Rick Shaw commented on CASSANDRA-3052:
--
You are using {{executeQuery()}} on an {{INSERT}} statement which is not
intended to return a {{ResultSet}}. You should be using an {{Execute()}} which
returns a count of the operations (Which CQL always returns as zero).
However NPE is a bad way of reporting the problem. I'll look into, and it
provide an appropriate {{SQLException}} failure outcome.
CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
Key: CASSANDRA-3052
URL: https://issues.apache.org/jira/browse/CASSANDRA-3052
Project: Cassandra
Issue Type: Bug
Reporter: Cathy Daw
Labels: cql
This test script used to work until I upgraded the jdbc driver to 1.0.4.
*CQL 1.0.4*: apache-cassandra-cql-1.0.4-SNAPSHOT.jar build at revision 1158979
*Repro Script*:
* drop in test directory, change package declaration and run: ant test
-Dtest.name=resultSetNPE
* The script gives you a NullPointerException when you uncomment out the
following lines after a CREATE or INSERT statement.
{code}
colCount = res.getMetaData().getColumnCount();
res.next();
{code}
* Please note that there is no need to comment out those lines if a SELECT
statement was run prior.
{code}
package com.datastax.bugs;
import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.junit.Test;
public class resultSetNPE {
@Test
public void createKS() throws Exception {
Connection initConn = null;
Connection connection = null;
ResultSet res;
Statement stmt;
int colCount = 0;
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
// Check create keyspace
initConn =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/default);
stmt = initConn.createStatement();
try {
System.out.println(Running DROP KS Statement);
res = stmt.executeQuery(DROP KEYSPACE ks1);
// res.next();
} catch (SQLException e) {
if (e.getMessage().startsWith(Keyspace does not exist))
{
// Do nothing - this just means you tried to drop something
that was not there.
// res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
}
}
System.out.println(Running CREATE KS Statement);
res = stmt.executeQuery(CREATE KEYSPACE ks1 with strategy_class =
'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
// res.next();
initConn.close();
}
@Test
public void createCF() throws Exception
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
int colCount = 0;
Connection connection =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1);
Statement stmt = connection.createStatement();
System.out.print(Running CREATE CF Statement);
ResultSet res = stmt.executeQuery(CREATE COLUMNFAMILY users (KEY
varchar PRIMARY KEY, password varchar, gender varchar, session_token varchar,
state varchar, birth_year bigint));
//colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
//res.next();
connection.close();
}
@Test
public void simpleSelect() throws Exception
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
int colCount = 0;
Connection connection =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1);
Statement stmt = connection.createStatement();
System.out.print(Running INSERT Statement);
ResultSet res = stmt.executeQuery(INSERT INTO users (KEY, password)
VALUES ('user1', 'ch@nge'));
//colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
//res.next();
System.out.print(Running SELECT Statement);
res = stmt.executeQuery(SELECT KEY, gender, state FROM users);
colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
res.getRow();
res.next();
[jira] [Issue Comment Edited] (CASSANDRA-3052) CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086748#comment-13086748
]
Rick Shaw edited comment on CASSANDRA-3052 at 8/18/11 2:33 AM:
---
You are using {{executeQuery()}} on an {{INSERT}} (or {{UPDATE}}) statement
which is not intended to return a {{ResultSet}}. You should be using an
{{executeUpdate()}} which returns a count of the operations (Which CQL always
returns as zero).
However NPE is a bad way of reporting the problem. I'll look into, and it
provide an appropriate {{SQLException}} failure outcome.
was (Author: ardot):
You are using {{executeQuery()}} on an {{INSERT}} statement which is not
intended to return a {{ResultSet}}. You should be using an {{Execute()}} which
returns a count of the operations (Which CQL always returns as zero).
However NPE is a bad way of reporting the problem. I'll look into, and it
provide an appropriate {{SQLException}} failure outcome.
CQL: ResultSet.next() gives NPE when run after an INSERT or CREATE statement
Key: CASSANDRA-3052
URL: https://issues.apache.org/jira/browse/CASSANDRA-3052
Project: Cassandra
Issue Type: Bug
Reporter: Cathy Daw
Labels: cql
This test script used to work until I upgraded the jdbc driver to 1.0.4.
*CQL 1.0.4*: apache-cassandra-cql-1.0.4-SNAPSHOT.jar build at revision 1158979
*Repro Script*:
* drop in test directory, change package declaration and run: ant test
-Dtest.name=resultSetNPE
* The script gives you a NullPointerException when you uncomment out the
following lines after a CREATE or INSERT statement.
{code}
colCount = res.getMetaData().getColumnCount();
res.next();
{code}
* Please note that there is no need to comment out those lines if a SELECT
statement was run prior.
{code}
package com.datastax.bugs;
import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.junit.Test;
public class resultSetNPE {
@Test
public void createKS() throws Exception {
Connection initConn = null;
Connection connection = null;
ResultSet res;
Statement stmt;
int colCount = 0;
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
// Check create keyspace
initConn =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/default);
stmt = initConn.createStatement();
try {
System.out.println(Running DROP KS Statement);
res = stmt.executeQuery(DROP KEYSPACE ks1);
// res.next();
} catch (SQLException e) {
if (e.getMessage().startsWith(Keyspace does not exist))
{
// Do nothing - this just means you tried to drop something
that was not there.
// res = stmt.executeQuery(CREATE KEYSPACE ks1 with
strategy_class = 'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
}
}
System.out.println(Running CREATE KS Statement);
res = stmt.executeQuery(CREATE KEYSPACE ks1 with strategy_class =
'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options:replication_factor=1);
// res.next();
initConn.close();
}
@Test
public void createCF() throws Exception
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
int colCount = 0;
Connection connection =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1);
Statement stmt = connection.createStatement();
System.out.print(Running CREATE CF Statement);
ResultSet res = stmt.executeQuery(CREATE COLUMNFAMILY users (KEY
varchar PRIMARY KEY, password varchar, gender varchar, session_token varchar,
state varchar, birth_year bigint));
//colCount = res.getMetaData().getColumnCount();
System.out.println( -- Column Count: + colCount);
//res.next();
connection.close();
}
@Test
public void simpleSelect() throws Exception
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
int colCount = 0;
Connection connection =
DriverManager.getConnection(jdbc:cassandra://127.0.0.1:9160/ks1);
Statement stmt = connection.createStatement();
System.out.print(Running INSERT Statement);
ResultSet res = stmt.executeQuery(INSERT INTO users (KEY, password)
VALUES ('user1', 'ch@nge'));
[jira] [Commented] (CASSANDRA-2925) The JDBC Suite should provide a simple DataSource implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13076152#comment-13076152
]
Rick Shaw commented on CASSANDRA-2925:
--
Yes. {{Utils.java}} was modified but not deleted by the last round of patches.
The JDBC Suite should provide a simple DataSource implementation
Key: CASSANDRA-2925
URL: https://issues.apache.org/jira/browse/CASSANDRA-2925
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.3
Attachments: jdbc-add-simple-datasource-v1.txt
The use of a {{DataSource}} is often the preferred method of acquiring JDBC
Connections. The Specification recommends that the driver code provide at
least a simple (non pooled) {{DataSource}} implementation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2925) The JDBC Suite should provide a simple DataSource implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13076238#comment-13076238
]
Rick Shaw commented on CASSANDRA-2925:
--
{{Utils.java}} exists in the C* svn repo?
The JDBC Suite should provide a simple DataSource implementation
Key: CASSANDRA-2925
URL: https://issues.apache.org/jira/browse/CASSANDRA-2925
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.3
Attachments: jdbc-add-simple-datasource-v1.txt
The use of a {{DataSource}} is often the preferred method of acquiring JDBC
Connections. The Specification recommends that the driver code provide at
least a simple (non pooled) {{DataSource}} implementation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2956) JDBC ResultSet improperly handles null column values
JDBC ResultSet improperly handles null column values
Key: CASSANDRA-2956
URL: https://issues.apache.org/jira/browse/CASSANDRA-2956
Project: Cassandra
Issue Type: Bug
Components: Drivers
Affects Versions: 0.8.2
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Fix For: 0.8.3
JDBC {{ResultSet}} getters return built-in datatypes such as {{int, long,
short, byte, boolean}} that are not capable of handling a null value. As a
consequence, it provides a method: {{wasNull}} which returns true if the value
was null. The spec requires a zero numeric value (or false in the case of
{{boolean}} ) is returned by the getter. This was being mis-handled and a null
value was being cast (boxed) to the return value. An NPE would result.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2956) JDBC ResultSet improperly handles null column values
[
https://issues.apache.org/jira/browse/CASSANDRA-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2956:
-
Attachment: jdbc-bugfix-handling-null-values.txt
JDBC ResultSet improperly handles null column values
Key: CASSANDRA-2956
URL: https://issues.apache.org/jira/browse/CASSANDRA-2956
Project: Cassandra
Issue Type: Bug
Components: Drivers
Affects Versions: 0.8.2
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.3
Attachments: jdbc-bugfix-handling-null-values.txt
JDBC {{ResultSet}} getters return built-in datatypes such as {{int, long,
short, byte, boolean}} that are not capable of handling a null value. As a
consequence, it provides a method: {{wasNull}} which returns true if the
value was null. The spec requires a zero numeric value (or false in the case
of {{boolean}} ) is returned by the getter. This was being mis-handled and a
null value was being cast (boxed) to the return value. An NPE would result.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2957) JDBC Unit test failed to run due to spurious character in text and bad YAML entry
JDBC Unit test failed to run due to spurious character in text and bad YAML
entry
-
Key: CASSANDRA-2957
URL: https://issues.apache.org/jira/browse/CASSANDRA-2957
Project: Cassandra
Issue Type: Bug
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Fix For: 0.7.9
Problem #1:
Bad character in the text (line 294, col 1):
{code}
˜PreparedStatement stmt = con.prepareStatement(update JdbcInteger set
?=?, ?=? where key = ?);
{code}
Problem #2:
Outdated YAML directive (line 17):
{code}
commitlog_rotation_threshold_in_mb: 128
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2957) JDBC Unit test failed to run due to spurious character in text and bad YAML entry
[
https://issues.apache.org/jira/browse/CASSANDRA-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2957:
-
Attachment: jdbc-unittest-fix-v1.txt
JDBC Unit test failed to run due to spurious character in text and bad YAML
entry
-
Key: CASSANDRA-2957
URL: https://issues.apache.org/jira/browse/CASSANDRA-2957
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8.2
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Fix For: 0.7.9
Attachments: jdbc-unittest-fix-v1.txt
Problem #1:
Bad character in the text (line 294, col 1):
{code}
˜PreparedStatement stmt = con.prepareStatement(update JdbcInteger
set ?=?, ?=? where key = ?);
{code}
Problem #2:
Outdated YAML directive (line 17):
{code}
commitlog_rotation_threshold_in_mb: 128
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2926) The JDBC Suite should provide a simple DatabaseMetaData implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2926:
-
Attachment: jdbc-add-simple-datasource-v1.txt
The JDBC Suite should provide a simple DatabaseMetaData implementation
--
Key: CASSANDRA-2926
URL: https://issues.apache.org/jira/browse/CASSANDRA-2926
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: CQL, JDBC
Fix For: 0.8.3
Attachments: jdbc-add-simple-datasource-v1.txt
The {{DatabaseMetaData}} interface provides access to meta-data information
about the JDBC Driver implementation and the DB that it supports. This class
would usually be used by tooling to discover the extended capabilities of the
Driver Suite.
A very basic implementation is planned initially. Non-static metadata about
Keyspaces and Column Families can be provided in enhanced versions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2926) The JDBC Suite should provide a simple DatabaseMetaData implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2926:
-
Attachment: (was: jdbc-add-simple-datasource-v1.txt)
The JDBC Suite should provide a simple DatabaseMetaData implementation
--
Key: CASSANDRA-2926
URL: https://issues.apache.org/jira/browse/CASSANDRA-2926
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: CQL, JDBC
Fix For: 0.8.3
The {{DatabaseMetaData}} interface provides access to meta-data information
about the JDBC Driver implementation and the DB that it supports. This class
would usually be used by tooling to discover the extended capabilities of the
Driver Suite.
A very basic implementation is planned initially. Non-static metadata about
Keyspaces and Column Families can be provided in enhanced versions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2925) The JDBC Suite should provide a simple DataSource implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2925:
-
Attachment: jdbc-add-simple-datasource-v1.txt
The JDBC Suite should provide a simple DataSource implementation
Key: CASSANDRA-2925
URL: https://issues.apache.org/jira/browse/CASSANDRA-2925
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.3
Attachments: jdbc-add-simple-datasource-v1.txt
The use of a {{DataSource}} is often the preferred method of acquiring JDBC
Connections. The Specification recommends that the driver code provide at
least a simple (non pooled) {{DataSource}} implementation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2895) add java classpath to cassandra startup logging
[
https://issues.apache.org/jira/browse/CASSANDRA-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069802#comment-13069802
]
Rick Shaw commented on CASSANDRA-2895:
--
This will only be logged once at startup. Why not just put:
{{echo CLASSPATH = $CLASSPATH}}
after the definition of {{CLASSPATH}} in the {{cassandra.in.sh}} file in the
{{/bin}} directory?
add java classpath to cassandra startup logging
---
Key: CASSANDRA-2895
URL: https://issues.apache.org/jira/browse/CASSANDRA-2895
Project: Cassandra
Issue Type: Improvement
Reporter: Jackson Chung
Priority: Minor
Attachments: 2895.diff
this is helpful to determine/verify if the Cassandra is started with the
expected classpath
it's a simple 1-liner addon that are useful... will submit a patch later.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2924) Consolidate JDBC driver classes: Connection and CassandraConnection in advance of feature additions for 1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068927#comment-13068927
]
Rick Shaw commented on CASSANDRA-2924:
--
+1
(lesson learned)
Consolidate JDBC driver classes: Connection and CassandraConnection in
advance of feature additions for 1.1
---
Key: CASSANDRA-2924
URL: https://issues.apache.org/jira/browse/CASSANDRA-2924
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.2
Attachments: 2924-v2.txt, consolidate-connection-v1.txt
For the JDBC Driver suite, additional cleanup and consolidation of classes
{{Connection}} and {{CassandraConnection}} were in order. Those changes drove
a few casual additional changes in related classes {{CResultSet}},
{{CassandraStatement}} and {{CassandraPreparedStatement}} in order to
continue to communicate properly. The class {{Utils}} was also enhanced to
move more static utility methods into this holder class.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2924) Consolidate JDBC driver classes: Connection and CassandraConnection in advance of feature additions for 1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069284#comment-13069284
]
Rick Shaw commented on CASSANDRA-2924:
--
It defines the methods that are to be implemented over and above those required
by the {{java.sql.Connection}} interface; these moved from the
{{o.a.c.cql.jdbc.Connection}}. That class can now be removed. (I did not know
how to do that in the patch?) I thought that seemed like the right thing to do
(defining an interface) but it is not necessary.
Consolidate JDBC driver classes: Connection and CassandraConnection in
advance of feature additions for 1.1
---
Key: CASSANDRA-2924
URL: https://issues.apache.org/jira/browse/CASSANDRA-2924
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.3
Attachments: 2924-v2.txt, consolidate-connection-v1.txt
For the JDBC Driver suite, additional cleanup and consolidation of classes
{{Connection}} and {{CassandraConnection}} were in order. Those changes drove
a few casual additional changes in related classes {{CResultSet}},
{{CassandraStatement}} and {{CassandraPreparedStatement}} in order to
continue to communicate properly. The class {{Utils}} was also enhanced to
move more static utility methods into this holder class.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2761) JDBC driver does not build
[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069353#comment-13069353
]
Rick Shaw commented on CASSANDRA-2761:
--
+1 for the cleanup path
The {{generate-eclipse-files}} seems to be working for me? How does it fail?
JDBC driver does not build
--
Key: CASSANDRA-2761
URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
Fix For: 1.0
Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt
Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2761) JDBC driver does not build
[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069353#comment-13069353
]
Rick Shaw edited comment on CASSANDRA-2761 at 7/22/11 2:08 AM:
---
+1 for the cleanup patch
The {{generate-eclipse-files}} seems to be working for me? How does it fail?
was (Author: ardot):
+1 for the cleanup path
The {{generate-eclipse-files}} seems to be working for me? How does it fail?
JDBC driver does not build
--
Key: CASSANDRA-2761
URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.0
Reporter: Jonathan Ellis
Assignee: Rick Shaw
Fix For: 1.0
Attachments: jdbc-driver-build-v1.txt,
v1-0001-CASSANDRA-2761-cleanup-nits.txt
Need a way to build (and run tests for) the Java driver.
Also: still some vestigal references to drivers/ in trunk build.xml.
Should we remove drivers/ from the 0.8 branch as well?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2924) Consolidate JDBC driver classes: Connection and CassandraConnection in advance of feature additions for 1.1
[
https://issues.apache.org/jira/browse/CASSANDRA-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068375#comment-13068375
]
Rick Shaw commented on CASSANDRA-2924:
--
Thanks for the additions.
Consolidate JDBC driver classes: Connection and CassandraConnection in
advance of feature additions for 1.1
---
Key: CASSANDRA-2924
URL: https://issues.apache.org/jira/browse/CASSANDRA-2924
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.2
Attachments: 2924-v2.txt, consolidate-connection-v1.txt
For the JDBC Driver suite, additional cleanup and consolidation of classes
{{Connection}} and {{CassandraConnection}} were in order. Those changes drove
a few casual additional changes in related classes {{CResultSet}},
{{CassandraStatement}} and {{CassandraPreparedStatement}} in order to
continue to communicate properly. The class {{Utils}} was also enhanced to
move more static utility methods into this holder class.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2859) JDBC connection should catch malformed URLs better
[ https://issues.apache.org/jira/browse/CASSANDRA-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067641#comment-13067641 ] Rick Shaw commented on CASSANDRA-2859: -- I'll pull it all together today... JDBC connection should catch malformed URLs better -- Key: CASSANDRA-2859 URL: https://issues.apache.org/jira/browse/CASSANDRA-2859 Project: Cassandra Issue Type: Improvement Components: Drivers Reporter: Jonathan Ellis Assignee: Jonathan Ellis Attachments: 2859.txt Some problems with the current connection handing: - host-less URLs are assumed to be localhost, when this is more commonly the result of a malformed URL (exhibit A: the current JdbcDriverTest connection) - there is no standard syntax for user/password in the url; attempting to support this will result in more malformed URLs. most (all?) other JDBC drivers force you to use the user/pass or properties constructors instead. - finally, a malformed URL can result in a very confusing InvalidRequestException if you manage to end up with garbage in the path component (which becomes keyspace): we send USE X to the server and if there are non-alphanumeric characters there we will get back a cryptic antlr parse failure (line 1:28 no viable alternative at character 'K') -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2924) Consolidate JDBC driver classes: Connection and CassandraConnection in advance of feature additions for 1.1
Consolidate JDBC driver classes: Connection and CassandraConnection in advance
of feature additions for 1.1
---
Key: CASSANDRA-2924
URL: https://issues.apache.org/jira/browse/CASSANDRA-2924
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Priority: Minor
Fix For: 0.8.2
For the JDBC Driver suite, additional cleanup and consolidation of classes
{{Connection}} and {{CassandraConnection}} were in order. Those changes drove a
few casual additional changes in related classes {{CResultSet}},
{{CassandraStatement}} and {{CassandraPreparedStatement}} in order to continue
to communicate properly. The class {{Utils}} was also enhanced to move more
static utility methods into this holder class.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2925) The JDBC Suite should provide a simple DataSource implementation
The JDBC Suite should provide a simple DataSource implementation
Key: CASSANDRA-2925
URL: https://issues.apache.org/jira/browse/CASSANDRA-2925
Project: Cassandra
Issue Type: New Feature
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Fix For: 0.8.2
The use of a {{DataSource}} is often the preferred method of acquiring JDBC
Connections. The Specification recommends that the driver code provide at least
a simple (non pooled) {{DataSource}} implementation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2925) The JDBC Suite should provide a simple DataSource implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2925:
-
Issue Type: Sub-task (was: New Feature)
Parent: CASSANDRA-2876
The JDBC Suite should provide a simple DataSource implementation
Key: CASSANDRA-2925
URL: https://issues.apache.org/jira/browse/CASSANDRA-2925
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.2
The use of a {{DataSource}} is often the preferred method of acquiring JDBC
Connections. The Specification recommends that the driver code provide at
least a simple (non pooled) {{DataSource}} implementation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2926) The JDBC Suite should provide a simple DatabaseMetaData implementation
The JDBC Suite should provide a simple DatabaseMetaData implementation
--
Key: CASSANDRA-2926
URL: https://issues.apache.org/jira/browse/CASSANDRA-2926
Project: Cassandra
Issue Type: New Feature
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Fix For: 0.8.2
The {{DatabaseMetaData}} interface provides access to meta-data information
about the JDBC Driver implementation and the DB that it supports. This class
would usually be used by tooling to discover the extended capabilities of the
Driver Suite.
A very basic implementation is planned initially. Non-static metadata about
Keyspaces and Column Families can be provided in enhanced versions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2926) The JDBC Suite should provide a simple DatabaseMetaData implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-2926:
-
Issue Type: Sub-task (was: New Feature)
Parent: CASSANDRA-2876
The JDBC Suite should provide a simple DatabaseMetaData implementation
--
Key: CASSANDRA-2926
URL: https://issues.apache.org/jira/browse/CASSANDRA-2926
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: CQL, JDBC
Fix For: 0.8.2
The {{DatabaseMetaData}} interface provides access to meta-data information
about the JDBC Driver implementation and the DB that it supports. This class
would usually be used by tooling to discover the extended capabilities of the
Driver Suite.
A very basic implementation is planned initially. Non-static metadata about
Keyspaces and Column Families can be provided in enhanced versions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2888) CQL support for JDBC DatabaseMetaData
[
https://issues.apache.org/jira/browse/CASSANDRA-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064061#comment-13064061
]
Rick Shaw commented on CASSANDRA-2888:
--
The title of this JIRA and the messages you provide seem to be mismatched?
What exactly are you trying to do? What version of the Driver are you using?
Are you using some sort of call that expects a {{DataSource}}? This is not
supported yet in even the most current available version in the trunk. Support
for a driver provided {{DataSource}} has been proposed as part of the 1.1
roadmap. But the JIRA seems to be looking for support of {{DatabaseMetaData}}.
This too is not currently supported, but it is optional and we reply with the
proper {{SQLException}} in the latest version of the driver in the trunk (build
from source).
Do you think this support is required? What would you use it for? It is
currently thought of as not required but a nice-to-have. Please look at
CASSANDRA-2876 and put it in perspective with the current roadmap. The roadmap
is not cast in stone. But I can tell you for the little I have looked at it,
that it is a big job to support any substantive features in this data structure.
CQL support for JDBC DatabaseMetaData
-
Key: CASSANDRA-2888
URL: https://issues.apache.org/jira/browse/CASSANDRA-2888
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.1
Environment: J2SE 1.6.0_22 x64 on Fedora 15
Reporter: Dave Carlson
Assignee: Rick Shaw
Priority: Minor
Labels: cql, newbie
Original Estimate: 96h
Remaining Estimate: 96h
In order to increase the drop-in capability of CQL to existing JDBC app
bases, CQL must be updated to include at least semi-valid responses to the
JDBC metadata portion.
without enhancement:
com.largecompany.JDBCManager.getConnection(vague Cassandra JNDI
pointer)
Resource has error: java.lang.UnsupportedOperationException: method not
supported
...
with enhancement:
com.largecompany.JDBCManager.getConnection(vague Cassandra JNDI
pointer)
org.apache.cassandra.cql.jdbc.CassandraConnection@1915470e
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
