Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Fix Version/s: 1.1.0
    • Component/s: API
    • Labels:

      Description

      Cqlsh needs to add support for CQL3. At a minimum, one needs to be able to choose the cql version at launch time.

        Activity

        Sylvain Lebresne created issue -
        Sylvain Lebresne made changes -
        Field Original Value New Value
        Component/s API [ 12313742 ]
        Eric Evans made changes -
        Eric Evans made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Sylvain Lebresne made changes -
        Assignee paul cannon [ thepaul ] Eric Evans [ urandom ]
        Reviewer thepaul
        Hide
        paul cannon added a comment -

        Cool. Do you think it's worth having an extra shortcut-y parameter like -3 or --cql3 instead of --cqlversion=3.0.0?

        Show
        paul cannon added a comment - Cool. Do you think it's worth having an extra shortcut-y parameter like -3 or --cql3 instead of --cqlversion=3.0.0 ?
        Hide
        Eric Evans added a comment -

        Cool. Do you think it's worth having an extra shortcut-y parameter like -3 or --cql3 instead of --cqlversion=3.0.0?

        Yeah, that probably would be better. I'll update the patch accordingly.

        Show
        Eric Evans added a comment - Cool. Do you think it's worth having an extra shortcut-y parameter like -3 or --cql3 instead of --cqlversion=3.0.0? Yeah, that probably would be better. I'll update the patch accordingly.
        Eric Evans made changes -
        Hide
        Eric Evans added a comment -

        I'll update the patch accordingly.

        Attached as v2

        Show
        Eric Evans added a comment - I'll update the patch accordingly. Attached as v2
        Hide
        Christoph Tavan added a comment -

        I'm probably not enough into the cassandra-side CQL code but in the light of CQL3 becoming default in the future, wouldn't it be more reasonable to add some cql2-flag internally that is being set to true by default and just set it to false if the --cql3 flag is provided? That way we could just drop a few lines of code when making CQL3 the default instead of altering stuff.

        Anyways I'm happy to see this being available in cqlsh soon!

        Show
        Christoph Tavan added a comment - I'm probably not enough into the cassandra-side CQL code but in the light of CQL3 becoming default in the future, wouldn't it be more reasonable to add some cql2-flag internally that is being set to true by default and just set it to false if the --cql3 flag is provided? That way we could just drop a few lines of code when making CQL3 the default instead of altering stuff. Anyways I'm happy to see this being available in cqlsh soon!
        Hide
        paul cannon added a comment -

        You mean, a --cql2/-2 flag that's on by default for now, but can be used in a forward-compatible way as long as cql2 is supported? I like that idea.

        Show
        paul cannon added a comment - You mean, a --cql2/-2 flag that's on by default for now, but can be used in a forward-compatible way as long as cql2 is supported? I like that idea.
        Hide
        Sylvain Lebresne added a comment -

        Some part of me tell me that this may prove limiting. I've actually bothered implementing the semantic versioning server side, so that when for instance when we have cql 3.1.0, if the client asked for 3.1.0 but the server is an old one that only support 3.0.0, an error is returned. So in other words, we will later need to be able to distinguish between 3.0.0 and 3.1.0. Feels like adding a specific flag each time will prove limiting or tedious to upgrade. I'm not sure if that would really matter for cqlsh but just figured I'd mention it.

        Maybe we could still have the option of setting whatever version we want, but then have --cql2 and --cql3 shortcuts that would refer to the more recent known version for instance.

        Show
        Sylvain Lebresne added a comment - Some part of me tell me that this may prove limiting. I've actually bothered implementing the semantic versioning server side, so that when for instance when we have cql 3.1.0, if the client asked for 3.1.0 but the server is an old one that only support 3.0.0, an error is returned. So in other words, we will later need to be able to distinguish between 3.0.0 and 3.1.0. Feels like adding a specific flag each time will prove limiting or tedious to upgrade. I'm not sure if that would really matter for cqlsh but just figured I'd mention it. Maybe we could still have the option of setting whatever version we want, but then have --cql2 and --cql3 shortcuts that would refer to the more recent known version for instance.
        Hide
        paul cannon added a comment -

        So in other words, we will later need to be able to distinguish between 3.0.0 and 3.1.0.

        Meaning there will be C* versions which support both? That seems wrong to me- if there's no major version increment, doesn't that mean 3.1.0 has to be backwards compatible with 3.0.0?

        Show
        paul cannon added a comment - So in other words, we will later need to be able to distinguish between 3.0.0 and 3.1.0. Meaning there will be C* versions which support both? That seems wrong to me- if there's no major version increment, doesn't that mean 3.1.0 has to be backwards compatible with 3.0.0?
        Hide
        Sylvain Lebresne added a comment -

        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.

        Show
        Sylvain Lebresne added a comment - 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.
        Hide
        Christoph Tavan added a comment - - edited

        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.

        Show
        Christoph Tavan added a comment - - edited 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.
        Hide
        paul cannon added a comment -

        Sounds like the best thing is to have --cqlversion=VER along with --cql2 and --cql3 shortcuts.

        Show
        paul cannon added a comment - Sounds like the best thing is to have --cqlversion=VER along with --cql2 and --cql3 shortcuts.
        Hide
        paul cannon added a comment -

        v3 here includes --cqlversion as well as --cql2 and --cql3, and fixes the most glaring problems with cqlsh use with cql3. Namely, allowing double-quoted names, and querying system."Versions" with double-quotes, since cql3 downcases the name by default.

        Show
        paul cannon added a comment - v3 here includes --cqlversion as well as --cql2 and --cql3, and fixes the most glaring problems with cqlsh use with cql3. Namely, allowing double-quoted names, and querying system."Versions" with double-quotes, since cql3 downcases the name by default.
        paul cannon made changes -
        Hide
        paul cannon added a comment -

        And as Eric mentioned, these expect the python-cql version in Cassandra to be updated to 1.0.10. My 3990 branch in github, tagged at:

        https://github.com/thepaul/cassandra/tree/pending/3990

        includes that python-cql update as well as the two commits attached here.

        Show
        paul cannon added a comment - And as Eric mentioned, these expect the python-cql version in Cassandra to be updated to 1.0.10. My 3990 branch in github, tagged at: https://github.com/thepaul/cassandra/tree/pending/3990 includes that python-cql update as well as the two commits attached here.
        Hide
        Christoph Tavan added a comment -

        You patch works great for me, Paul.

        Show
        Christoph Tavan added a comment - You patch works great for me, Paul.
        Hide
        paul cannon added a comment -

        we'll see what Eric thinks.

        Show
        paul cannon added a comment - we'll see what Eric thinks.
        paul cannon made changes -
        Labels cql cqlsh
        Assignee Eric Evans [ urandom ] paul cannon [ thepaul ]
        Reviewer thepaul urandom
        Hide
        Eric Evans added a comment -

        we'll see what Eric thinks.

        Looks good to me. I've merged this to cassandra-1.1 and trunk, I'll leave it to Sylvain's judgement as to whether or not this should be merged to cassandra-1.1.0 as well.

        Thanks.

        Show
        Eric Evans added a comment - we'll see what Eric thinks. Looks good to me. I've merged this to cassandra-1.1 and trunk, I'll leave it to Sylvain's judgement as to whether or not this should be merged to cassandra-1.1.0 as well. Thanks.
        Hide
        Eric Evans added a comment -

        From IRC:

        11:59 < urandom> pcmanus: when you get a sec, let me know whether you think 
                         #3990 should be merged to 1.1.0
        11:59 < CassBotJr> https://issues.apache.org/jira/browse/CASSANDRA-3990 : cqlsh 
                           support for CQL 3
        12:00 < pcmanus> urandom: I'm fine with it (as part of our CQL3 is beta and 
                         excluded of freeze)
        

        So, added to cassandra-1.1.0 as well.

        Show
        Eric Evans added a comment - From IRC: 11:59 < urandom> pcmanus: when you get a sec, let me know whether you think #3990 should be merged to 1.1.0 11:59 < CassBotJr> https://issues.apache.org/jira/browse/CASSANDRA-3990 : cqlsh support for CQL 3 12:00 < pcmanus> urandom: I'm fine with it (as part of our CQL3 is beta and excluded of freeze) So, added to cassandra-1.1.0 as well.
        Eric Evans made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Gavin made changes -
        Workflow no-reopen-closed, patch-avail [ 12655674 ] patch-available, re-open possible [ 12749590 ]
        Gavin made changes -
        Workflow patch-available, re-open possible [ 12749590 ] reopen-resolved, no closed status, patch-avail, testing [ 12754312 ]

          People

          • Assignee:
            paul cannon
            Reporter:
            Sylvain Lebresne
            Reviewer:
            Eric Evans
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development