Uploaded image for project: 'Couchbase Java Client'
  1. Couchbase Java Client
  2. JCBC-124

Cannot operate on keys with spaces in them

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 1.1-beta
    • Component/s: Core
    • Security Level: Public
    • Labels:
      None

      Description

      The other clients allows keys with spaces in them, such as "test key", but there is no way to operate on these using the Java client.

      myclient.set("test key", 0, "test value");

      java.lang.IllegalArgumentException: Key contains invalid characters: ``test key''
      at net.spy.memcached.util.StringUtils.validateKey(StringUtils.java:79)
      at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:639)
      at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:300)
      at net.spy.memcached.MemcachedClient.set(MemcachedClient.java:733)

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        ingenthr Matt Ingenthron added a comment -

        At the moment, we'll need to see if allowing keys with spaces are intended to be supported. Earlier discussion with folks indicated it was not intended to be supported.

        Show
        ingenthr Matt Ingenthron added a comment - At the moment, we'll need to see if allowing keys with spaces are intended to be supported. Earlier discussion with folks indicated it was not intended to be supported.
        Hide
        aaron Aaron Miller (Inactive) added a comment - - edited

        Well, this is really an issue with spymemcached, as it's incorrectly applying ASCII protocol key restrictions over binary protocol.

        If we have extra key restrictions in Couchbase, those should probably be handled in the Couchbase client. I believe the approach we're using in Couchbase was that you could insert whatever you want, since there are lots of memcached clients out there that will be used, and community libraries and such, and that UTF-8 keys were required for your item to be picked up by views.

        As it stands today the libcouchbase-based clients can insert items that the java client cannot touch, which makes using the java client with other clients in the same system very likely to cause frustration if they run into this problem.

        Show
        aaron Aaron Miller (Inactive) added a comment - - edited Well, this is really an issue with spymemcached, as it's incorrectly applying ASCII protocol key restrictions over binary protocol. If we have extra key restrictions in Couchbase, those should probably be handled in the Couchbase client. I believe the approach we're using in Couchbase was that you could insert whatever you want, since there are lots of memcached clients out there that will be used, and community libraries and such, and that UTF-8 keys were required for your item to be picked up by views. As it stands today the libcouchbase-based clients can insert items that the java client cannot touch, which makes using the java client with other clients in the same system very likely to cause frustration if they run into this problem.
        Hide
        daschl Michael Nitschinger added a comment -

        http://review.couchbase.com/#/c/21323/
        That's a good one Aaron, I'll test that and abandon my changeset.

        Show
        daschl Michael Nitschinger added a comment - http://review.couchbase.com/#/c/21323/ That's a good one Aaron, I'll test that and abandon my changeset.
        Hide
        mikew Mike Wiederhold added a comment -

        Aaron,

        This has been an open argument on the Java SDK for some time. The reason that we don't allow spaces in the key names is so that Java users can switch between ascii and binary connections and still have their applications function correctly. I think the correct thing to do here would be to add an option in the connection factory to enable the use of keys with spaces in binary protocol.

        Show
        mikew Mike Wiederhold added a comment - Aaron, This has been an open argument on the Java SDK for some time. The reason that we don't allow spaces in the key names is so that Java users can switch between ascii and binary connections and still have their applications function correctly. I think the correct thing to do here would be to add an option in the connection factory to enable the use of keys with spaces in binary protocol.
        Hide
        aaron Aaron Miller (Inactive) added a comment -

        That seems silly, because as it stands right now they cannot switch from another language to Java and have it work correctly, nor do what I'm trying to do, which is attempting to interoperate with another piece of software that I did not write that uses a different language's SDK, since the other language SDKs allow spaces. Once we have a JRuby client based on this java client ready, they wouldn't even be able to switch from Ruby to JRuby.

        I don't see a compelling reason for the Java client to behave differently from other clients, and if somebody is tripped up in this manner the fix would be simply to use the binary protocol. It doesn't seem worth breaking interoperability over.

        Show
        aaron Aaron Miller (Inactive) added a comment - That seems silly, because as it stands right now they cannot switch from another language to Java and have it work correctly, nor do what I'm trying to do, which is attempting to interoperate with another piece of software that I did not write that uses a different language's SDK, since the other language SDKs allow spaces. Once we have a JRuby client based on this java client ready, they wouldn't even be able to switch from Ruby to JRuby. I don't see a compelling reason for the Java client to behave differently from other clients, and if somebody is tripped up in this manner the fix would be simply to use the binary protocol. It doesn't seem worth breaking interoperability over.
        Hide
        mikew Mike Wiederhold added a comment -

        Duplicate of SPY-63.

        Show
        mikew Mike Wiederhold added a comment - Duplicate of SPY-63 .

          People

          • Assignee:
            daschl Michael Nitschinger
            Reporter:
            aaron Aaron Miller (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes