[jira] [Updated] (CASSANDRA-4103) Add stress tool to binaries
[ https://issues.apache.org/jira/browse/CASSANDRA-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay updated CASSANDRA-4103: - Attachment: 0001-CASSANDRA-4103.patch With the patch, an user can do ./tools/stress/bin/stress to execute the stress tool from cassandra_home. > Add stress tool to binaries > --- > > Key: CASSANDRA-4103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4103 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Rick Branson >Assignee: Vijay >Priority: Minor > Attachments: 0001-CASSANDRA-4103.patch > > > It would be great to also get the stress tool packaged along with the > binaries. Many people don't even know it exists because it's not distributed > with them. -- 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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243242#comment-13243242
]
Sylvain Lebresne commented on CASSANDRA-4093:
-
Wow, that seems to get so out of proportion and I so don't understand why.
What happpened is this: currently (i.e. in all released version), a
ColumnDefinition name refers to the CF column name, i.e. one must use the
column comparator to decode it. In all currently released version,
CompositeType is a normal comparator and that rule applies to it, and for
anyone that will use thrift in 1.1+, for all intent and purposes CompositeType
will still be a normal comparator like all the other ones and so the natural
thing will still be that the ColumDefinition name applies to CT comparator
entirely.
Now when I wrote the CQL3 patch (the initial one), I realised that we needed a
new feature, the need to be able to have ColumnDefinitions whose name refers to
only one of the component of the CT comparator. And while we currently only
need to refer to the last component (because we don't yet support secondary
indexes on CT), we *will* need to have ColumnDefinition whose name refer to
*any* of the CT components as soon as we support secondary indexes on CT
(CASSANDRA-3680). In other words, the introduction of composite_index (this
patch) is just the first part CASSANDRA-3680. We *will* have to add it soon
enough. It is *hardly* something added *just* for backward compatibility.
Anyway while I was writting the CQL3 patch, instead of properly handling that
new case, I introduced a *bug* consisting of changing the behavior of
ColumnDefinition for CT so that by default they refer to the last component of
the CT, not the comparator itself anymore. I.e. I changed the default behavior
to an incompatible one. I'm sorry I did that, I shouldn't have and the goal of
that patch is to restore the default behavior and introduce a new info to
ColumnDefinition to allow switching to the new behavior. Again, I think it is
incorrect to say that this patch is just 'in the name of backward
compatibility'. If I had mistakefully changed the subcolumn comparator of super
column to apply to column names instead of super columns names, we wouldn't
call fixing that 'supporting a misfeature in the name of backward
compatibilty'. But yes, this bug happens to break backward compatibility and I
do have a big problem with that part.
On the thrift side. Yes this does add a new field to ColumnDef. But:
# It's untrue that column_aliases and value_alias were 'added before we had
cqlsh'. They would be added in the exact same version as this patch, so I think
that using that argument against component_index is unfair.
# I'm not sure this will be so very confusing to users. Again, for thrift
users, CT is a comparator like any other. The confusing thing would be for a
ColumnDef to apply to the last component rather than the full CT. Why would CT
be suddenly special (again, on the thrift side) and why the last component? It
would random and thus confusing. On the contrary, if you have component_index,
then you can say that the default is the one you'd expect, i.e the one that
apply to all other comparator, but that we've added the new ability to make
ColumnDef apply to other component.
# As soon as CASSANDRA-3680 is done, it will be usefull to allow creating
secondary indexes on CT component on the thrift side. Why wouldn't we allow
CASSANDRA-3680 on the thrift if it only cost us the addition of a simple int
field in ColumnDef?
{quote}
The upgrade path requires some effort but is conceptually simple:
# update your application to no longer use the CT column index
# upgrade
{quote}
My problem is that step 1 will be *super* painfull. Because before upgrading,
you don't have any reasonable alternative for whatever you were doing with the
CT column index (tagging rows for instance). So you have to write manual code
to do the same manual indexing. And then you have to write a map reduce job to
reconstruct this new manual index for existing rows. In real life situations
where you must do that without downtime, it's a pain in the ass.
And yes I know, you don't believe anyone uses that. But I have the weakness to
think that we do not know what everyone user is doing. And yes, I have a *big*
problem with screwing up even 1 user (especially after we've said we were
serious about not breaking the thrift API). And yes, even if that force us to
write a little bit more code now and/or later.
bq. is worth the upside of getting to a clean data model in 1.2 without the
distractions of legacy features like this. The danger is that the longer we
preserve features like this, the more potential there is for new users to start
using them which makes it more difficult for us to drop them later
Ok, I understand the argument in principle but in practice wha
[jira] [Commented] (CASSANDRA-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243200#comment-13243200
]
Pavel Yaskevich commented on CASSANDRA-4093:
I'm fine fixing it just for CLI then.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243196#comment-13243196
]
Jonathan Ellis commented on CASSANDRA-4093:
---
"Presumably if you're using column aliases in your own CFs, you're using a
sufficiently up to date client already."
In other words, your upgrade path is
# upgrade C* to 1.1
# upgrade cli to 1.1
# start creating CQL3 CFs
In particular, 3 doesn't work before 1, at which point 2 is trivial.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243189#comment-13243189
]
Pavel Yaskevich commented on CASSANDRA-4093:
Would that assumption still hold when users are going to start creating CFs
using CQL3?
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243183#comment-13243183
]
Jonathan Ellis commented on CASSANDRA-4093:
---
bq. The problem with that it's not only about CLI it is also about all other
possible clients too because users expect comparator to be able to
{de-}serialize column names correctly
But this is only a problem if you're trying to show the schema for the System
keyspace. (Presumably if you're using column aliases in your own CFs, you're
using a sufficiently up to date client already.)
I'm willing to accept that "to introspect the system keyspace, you need to be
using a 1.1-aware cli."
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243179#comment-13243179
]
Jonathan Ellis commented on CASSANDRA-4093:
---
bq. If you're referring to me saying that we could later consider allowing
index on a full composite in CQL3, then I'm sorry, let's forget about that for
now. This patch does not force us at all to do that.
My problem is that by supporting this misfeature from thrift in the name of
backwards compatibility, we're only pushing the problem into the future: the
next step is for someone to say, "you support this in Thrift, so I should be
able to do it in CQL too." I'd rather just draw a line and say, "allowing this
was a bad idea and we don't support it anymore."
bq. while it is true that we don't yet use that generalization
My point is that I'm pretty sure this is a generalization I don't want to
support at all. This is a case where exposing every detail of your storage
engine is a bad idea.
bq. Anyone that use an index on a CT currently won't be able to upgrade ever
The upgrade path requires some effort but is conceptually simple:
# update your application to no longer use the CT column index
# upgrade
(If you respond that updating your application is not acceptable, then why are
you bothering to upgrade? Stay on the stable version that you built against in
the first place, there is nothing wrong with that.)
My claim is that inflicting this on a small handful of users (possibly as small
as zero, and I would bet money not more than one) is worth the upside of
getting to a clean data model in 1.2 without the distractions of legacy
features like this. The danger is that the longer we preserve features like
this, the more potential there is for new users to start using them which makes
it more difficult for us to drop them later. So I'd rather make a clean break
now, than drag it out.
That said, if you are fundamentally opposed to not dropping any feature no
matter how obscure without some warning, which I admit is at least a consistent
position, I would be okay with supporting this in 1.1 with a clear intention to
drop it in 1.2. (Which would imply to me that we leave the thrift interface
alone.) This would give us a full release to make sure we have alternatives to
whatever use cases people may have for the CT index (e.g. indexing the sparse
columns for the tag scenario).
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243177#comment-13243177
]
Pavel Yaskevich commented on CASSANDRA-4093:
bq. Granted, which is why we need to make the cli aware of column aliases.
The problem with that it's not only about CLI it is also about all other
possible clients too because users expect comparator to be able to
{de-}serialize column names correctly. So we should make it very clear how to
work with this type of situation without making any special cases (e.g. for CT).
bq. Because we added those before we had cqlsh, so the cli was the only way to
configure them. In retrospect, not a great idea.
I also don't think that having aliases in Thrift really justifies this
situation.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243173#comment-13243173
]
Jonathan Ellis commented on CASSANDRA-4093:
---
bq. Ok but it's only useful with CQL3 because all others wouldn't be able to
query that correctly like CLI because of the way column metadata is stored
right now.
Granted, which is why we need to make the cli aware of column aliases.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243171#comment-13243171
]
Jonathan Ellis commented on CASSANDRA-4093:
---
bq. the field is useful internally in ColumnDefinition so not adding it to
ColumnDef (to say avoid confusing thrift user) would imo be a bit dangerous
Here's what I don't get. We're adding this to support backwards compatibility,
and yet we need to change the interface to do it? Clearly a 0.8 or 1.0 client
isn't going to be aware of this new field.
bq. All the aliases (key_alias, column_aliases, value_alias) are only useful to
CQL3 but yet have been added on the thrift side
Because we added those before we had cqlsh, so the cli was the only way to
configure them. In retrospect, not a great idea.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243169#comment-13243169
]
Pavel Yaskevich commented on CASSANDRA-4093:
bq. I'm still convinced that part is worth it to be able to query schema
information without thrift describe_ methods.
Ok but it's only useful with CQL3 because all others wouldn't be able to query
that correctly like CLI because of the way column metadata is stored right now.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243167#comment-13243167
]
Jonathan Ellis commented on CASSANDRA-4093:
---
bq. Sounds like it wasn't a good time to make schema_* CFs to use CQL3 style
metadata
I'm still convinced that part is worth it to be able to query schema
information without thrift describe_ methods.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243161#comment-13243161
]
Pavel Yaskevich commented on CASSANDRA-4093:
Sounds like it wasn't a good time to make schema_* CFs to use CQL3 style
metadata which breaks all other parties and causes half-hacky field (dispute
the fact that it is not even useful yet) to be added to the thrift structure
just to support correct data display even if that is ambiguous for users
how/when to correctly use it...
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243146#comment-13243146
]
Sylvain Lebresne commented on CASSANDRA-4093:
-
Because the system CFs are using CQL3 style metadata so that we can display
them nicely when queried with CQL3. So typically the CLI (or anyone else) needs
that info to be able to correctly decode and display the system table
definitions.
Besides, when we add the ability to index the components of a CT, the fact that
component_index is exposed through thrift means that the thrift user will be
able to use that new functionality, which while probably not a priori is still
nice.
Lastly, the field is useful internally in ColumnDefinition so not adding it to
ColumnDef (to say avoid confusing thrift user) would imo be a bit dangerous (it
would make using both thrift and CQL3 at the same time difficult, which may be
useful for people transitioning to CQL3). Overall I really don't think adding
the new field is such a big deal. It is true that is is currently mildly useful
for pure thrift user, but it's not like it's something new. All the aliases
(key_alias, column_aliases, value_alias) are only useful to CQL3 but yet have
been added on the thrift side. This is not really different.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-4097) Classes in org.apache.cassandra.deps:avro:1.4.0-cassandra-1 clash with core Avro classes
[
https://issues.apache.org/jira/browse/CASSANDRA-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243140#comment-13243140
]
Jonathan Ellis commented on CASSANDRA-4097:
---
look for avro in the lib dir
> Classes in org.apache.cassandra.deps:avro:1.4.0-cassandra-1 clash with core
> Avro classes
>
>
> Key: CASSANDRA-4097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4097
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Affects Versions: 0.7.0
>Reporter: Andrew Swan
>Priority: Minor
>
> Cassandra has this dependency:
> {code:title=build.xml}...
> version="1.4.0-cassandra-1">
> ...{code}
> Unfortunately this JAR file contains classes in the {{org.apache.avro}}
> package that are incompatible with classes of the same fully-qualified name
> in the current release of Avro. For example, the inner class
> {{org.apache.avro.Schema$Parser}} found in Avro 1.6.1 is missing from the
> Cassandra version of that class. This makes it impossible to have both
> Cassandra and the latest Avro version on the classpath (my use case is an
> application that embeds Cassandra but also uses Avro 1.6.1 for unrelated
> serialization purposes). A simple and risk-free solution would be to change
> the package declaration of Cassandra's Avro classes from {{org.apache.avro}}
> to (say) {{org.apache.cassandra.avro}}, assuming that the above dependency is
> only used by Cassandra and no other projects (which seems a reasonable
> assumption given its name).
--
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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243139#comment-13243139
]
Pavel Yaskevich commented on CASSANDRA-4093:
If users are never required to set it for everything to work, what is the
benefit of adding new field at the first place?
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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] [Issue Comment Edited] (CASSANDRA-3990) cqlsh support for CQL 3
[
https://issues.apache.org/jira/browse/CASSANDRA-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243127#comment-13243127
]
Christoph Tavan edited comment on CASSANDRA-3990 at 3/31/12 12:57 PM:
--
So we finally also end up at the question whether the cqlsh which gets shipped
alongside C* is supposed to work with whatever CQL version that existed up to
that point in time? If so, I think it must definitely be possible to specify
the exact CQL version and cqlsh should default to the CQL version that was the
default in the C* version it got shipped with.
Providing shorthands like {{--cql2/--cql3}} that activate the most recent
matching CQL minor version would be handy I guess.
was (Author: ctavan):
So we finally also end up at the question whether the cqlsh which gets
shipped alongside C* is supposed to work with whatever CQL version that existed
up to that point in time? If so, I think it must definitely be possible to
specify the exact CQL version and cqlsh should default to the CQL version that
was the default in the C* version it got shipped with.
Providing shorthands like --cql2/--cql3 that activate the most recent matching
CQL minor version would be handy I guess.
> cqlsh support for CQL 3
> ---
>
> Key: CASSANDRA-3990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3990
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
>Reporter: Sylvain Lebresne
>Assignee: Eric Evans
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt,
> v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt
>
>
> Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to
> choose the cql version at launch time.
--
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-3990) cqlsh support for CQL 3
[ https://issues.apache.org/jira/browse/CASSANDRA-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243127#comment-13243127 ] Christoph Tavan commented on CASSANDRA-3990: So we finally also end up at the question whether the cqlsh which gets shipped alongside C* is supposed to work with whatever CQL version that existed up to that point in time? If so, I think it must definitely be possible to specify the exact CQL version and cqlsh should default to the CQL version that was the default in the C* version it got shipped with. Providing shorthands like --cql2/--cql3 that activate the most recent matching CQL minor version would be handy I guess. > cqlsh support for CQL 3 > --- > > Key: CASSANDRA-3990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3990 > Project: Cassandra > Issue Type: Sub-task > Components: API >Reporter: Sylvain Lebresne >Assignee: Eric Evans >Priority: Minor > Fix For: 1.1.0 > > Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, > v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt > > > Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to > choose the cql version at launch time. -- 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-4093) schema_* CFs do not respect column comparator which leads to CLI commands failure.
[
https://issues.apache.org/jira/browse/CASSANDRA-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243120#comment-13243120
]
Sylvain Lebresne commented on CASSANDRA-4093:
-
bq. Meaning there will be C* versions which support both?
Only if 1) they use thrift and 2) they ever want to define a ColumnDef that
apply to one of the component of a CT. Currently, 2) doesn't have any interest
on the thrift side, except maybe as a preparation if you're going to switch to
cql3.
In other word, you will never be *required* to set the field.
> schema_* CFs do not respect column comparator which leads to CLI commands
> failure.
> --
>
> Key: CASSANDRA-4093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4093
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.1.0
>Reporter: Dave Brosius
>Assignee: Sylvain Lebresne
> Fix For: 1.1.0
>
> Attachments: 4093.txt, CASSANDRA-4093-CD-changes.patch
>
>
> ColumnDefinition.{ascii, utf8, bool, ...} static methods used to initialize
> schema_* CFs column_metadata do not respect CF comparator and use
> ByteBufferUtil.bytes(...) for column names which creates problems in CLI and
> probably in other places.
> The CompositeType validator throws exception on first column
> String columnName = columnNameValidator.getString(columnDef.name);
> Because it appears the composite type length header is wrong (25455)
> AbstractCompositeType.getWithShortLength
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Buffer.java:247)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:139)
> at
> org.apache.cassandra.cli.CliClient.describeColumnFamily(CliClient.java:2046)
> at
> org.apache.cassandra.cli.CliClient.describeKeySpace(CliClient.java:1969)
> at
> org.apache.cassandra.cli.CliClient.executeShowKeySpaces(CliClient.java:1574)
> (seen in trunk)
--
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-3990) cqlsh support for CQL 3
[ https://issues.apache.org/jira/browse/CASSANDRA-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243119#comment-13243119 ] Sylvain Lebresne commented on CASSANDRA-3990: - bq. Meaning there will be C* versions which support both? No. But it is possible even for the same user to have a cluster with mixed C* versions. And yes 3.1.0 will be backward compatible with 3.0.0. But 3.1.0 may have feature that doesn't work with 3.0.0. So if someone wants to use 3.1.0 explicitly, he ought to be able to say so (and if the C* server is an old one that only know about 3.0.0, it will refuse the connection). It is true that you would be safe to always set the version to 3.0.0, even when the server will be on 3.1.0, but what I mean is that the server does some fine grained version check, so if we don't expose the ability to choose which version of CQL exactly we want, we loose a bit of flexibility. We may consider that fine for cqlsh though, I don't know. > cqlsh support for CQL 3 > --- > > Key: CASSANDRA-3990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3990 > Project: Cassandra > Issue Type: Sub-task > Components: API >Reporter: Sylvain Lebresne >Assignee: Eric Evans >Priority: Minor > Fix For: 1.1.0 > > Attachments: v1-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt, > v2-0001-CASSANDRA-3990-cqlsh-support-for-CQL-3.txt > > > Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to > choose the cql version at launch time. -- 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-4097) Classes in org.apache.cassandra.deps:avro:1.4.0-cassandra-1 clash with core Avro classes
[
https://issues.apache.org/jira/browse/CASSANDRA-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243101#comment-13243101
]
Andrew Swan commented on CASSANDRA-4097:
Hi Jonathan,
I've checked out the source from
http://git-wip-us.apache.org/repos/asf/cassandra.git, and there's no
{{lib/avro}} directory. There's a {{lib}} directory, but the only sub-directory
it contains is "licenses". Am I looking in the right place?
> Classes in org.apache.cassandra.deps:avro:1.4.0-cassandra-1 clash with core
> Avro classes
>
>
> Key: CASSANDRA-4097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4097
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Affects Versions: 0.7.0
>Reporter: Andrew Swan
>Priority: Minor
>
> Cassandra has this dependency:
> {code:title=build.xml}...
> version="1.4.0-cassandra-1">
> ...{code}
> Unfortunately this JAR file contains classes in the {{org.apache.avro}}
> package that are incompatible with classes of the same fully-qualified name
> in the current release of Avro. For example, the inner class
> {{org.apache.avro.Schema$Parser}} found in Avro 1.6.1 is missing from the
> Cassandra version of that class. This makes it impossible to have both
> Cassandra and the latest Avro version on the classpath (my use case is an
> application that embeds Cassandra but also uses Avro 1.6.1 for unrelated
> serialization purposes). A simple and risk-free solution would be to change
> the package declaration of Cassandra's Avro classes from {{org.apache.avro}}
> to (say) {{org.apache.cassandra.avro}}, assuming that the above dependency is
> only used by Cassandra and no other projects (which seems a reasonable
> assumption given its name).
--
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
