CouchDB
  1. CouchDB
  2. COUCHDB-904

No method to detect view server VM version

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.0.0
    • Component/s: JavaScript View Server
    • Labels:
      None
    • Skill Level:
      Regular Contributors Level (Easy to Medium)

      Description

      There's currently no way to tell what version of the view server is being used. Ie, the JS VM (Or Python, or Ruby, etc) that is being used. Just occurred to me it could be useful for debugging things that work one place and not another.

      A proposed simple fix would be to have the view server protocol dictate that when a server boots up it spits out a line like:

      {"version": OPAQUE_STRING}

      that gets stored in a view_server_versions section in the config or some such.

      1. patch.txt
        5 kB
        Dipesh Patel

        Issue Links

          Activity

          Dave Cottlehuber made changes -
          Link This issue is related to COUCHDB-1743 [ COUCHDB-1743 ]
          Randall Leeds made changes -
          Fix Version/s 2.0 [ 12315572 ]
          Hide
          Randall Leeds added a comment -

          I'm going to say this is a good one for 2.0. Breaks protocol, but also a major version release is a good time to install these sorts of forward-compatibility features.

          Show
          Randall Leeds added a comment - I'm going to say this is a good one for 2.0. Breaks protocol, but also a major version release is a good time to install these sorts of forward-compatibility features.
          Hide
          Randall Leeds added a comment -

          These two tickets are related. At a cursory glance it sounds like the protocol, which is generally request/response initiated by CouchDB, could easily have CouchDB send its version over and receive the view server's version string back in the response.

          Show
          Randall Leeds added a comment - These two tickets are related. At a cursory glance it sounds like the protocol, which is generally request/response initiated by CouchDB, could easily have CouchDB send its version over and receive the view server's version string back in the response.
          Randall Leeds made changes -
          Link This issue is related to COUCHDB-1164 [ COUCHDB-1164 ]
          Hide
          Dipesh Patel added a comment -

          @Paul

          Cool I think I've implemented what you originally envisioned when creating this ticket. If not let me know. There may still be some issues :S

          Thanks for the feedback guys.

          Dip

          Show
          Dipesh Patel added a comment - @Paul Cool I think I've implemented what you originally envisioned when creating this ticket. If not let me know. There may still be some issues :S Thanks for the feedback guys. Dip
          Hide
          Paul Joseph Davis added a comment -

          @Alexander

          That's not a bad idea but its orthogonal from this issue. This issue was due to me debugging something completely random and then figuring out that the person had a weird couchjs installed. So this was just a quick thought on how to make that obvious for future debugging.

          Your idea for having couchdb send its version number to the os processes it opens is a good idea though, you should open another ticket with your latest comment so we have somewhere to track that idea.

          Show
          Paul Joseph Davis added a comment - @Alexander That's not a bad idea but its orthogonal from this issue. This issue was due to me debugging something completely random and then figuring out that the person had a weird couchjs installed. So this was just a quick thought on how to make that obvious for future debugging. Your idea for having couchdb send its version number to the os processes it opens is a good idea though, you should open another ticket with your latest comment so we have somewhere to track that idea.
          Hide
          Alexander Shorin added a comment -

          Yes, a little incorrect(:
          Ok, I'll explain more detail. Imagine that I'm developer of some view server. I'd like to create view server which covers most of CouchDB releases. Each new CouchDB release brings new features, improvements and API changes, some times backward-incompatible (as for 0.9->0.10->0.11->0.11.1) . However, I couldn't solve this task due to there is not way to know about CouchDB version and API that I have to implement. So there are three ways that I have:
          1. develop only "bleeding edge" view server that support only latest version
          2. make separate branch per version
          3. keep "all in one" and pass version as command line argument.
          First one makes to forgot about old releases, second is supporting hell. Last one is more effective, but requires to keep in mind changing argument on server update.

          So CouchDB tells view server about his version, not view server about his.

          Sorry for offtopic, just thoughts about similar idea(: or may be improvement of yours:
          CouchDB pass "version" command to view server with additional value of his version and excepts that view server return his version back. Something like "version exchange".

          Show
          Alexander Shorin added a comment - Yes, a little incorrect(: Ok, I'll explain more detail. Imagine that I'm developer of some view server. I'd like to create view server which covers most of CouchDB releases. Each new CouchDB release brings new features, improvements and API changes, some times backward-incompatible (as for 0.9->0.10->0.11->0.11.1) . However, I couldn't solve this task due to there is not way to know about CouchDB version and API that I have to implement. So there are three ways that I have: 1. develop only "bleeding edge" view server that support only latest version 2. make separate branch per version 3. keep "all in one" and pass version as command line argument. First one makes to forgot about old releases, second is supporting hell. Last one is more effective, but requires to keep in mind changing argument on server update. So CouchDB tells view server about his version, not view server about his. Sorry for offtopic, just thoughts about similar idea(: or may be improvement of yours: CouchDB pass "version" command to view server with additional value of his version and excepts that view server return his version back. Something like "version exchange".
          Hide
          Dipesh Patel added a comment -

          Sorry, you are going to have to explain to it to me a bit more. What you are saying is that the view server spits out a couchdb version that it works on, and we store it? Is that correct? Do I need to do anything else with this value?

          Dip

          Show
          Dipesh Patel added a comment - Sorry, you are going to have to explain to it to me a bit more. What you are saying is that the view server spits out a couchdb version that it works on, and we store it? Is that correct? Do I need to do anything else with this value? Dip
          Hide
          Alexander Shorin added a comment -

          I think that the main problem is quite opposite - how view server get to know with what CouchDB server version it works? That could allows to control implemented features and their behavior from release to release, especially if there would be a major API changes (as it was with list function) without worry about view server "correct" version (just keep it up to dated).

          Show
          Alexander Shorin added a comment - I think that the main problem is quite opposite - how view server get to know with what CouchDB server version it works? That could allows to control implemented features and their behavior from release to release, especially if there would be a major API changes (as it was with list function) without worry about view server "correct" version (just keep it up to dated).
          Dipesh Patel made changes -
          Attachment patch.txt [ 12478633 ]
          Hide
          Dipesh Patel added a comment -

          Hi

          Created a patch for this, its a first pass so let me know what's missing. I think the testing may be a little weak so could do with some pointers on it as well as overall architecture.

          Dip

          Show
          Dipesh Patel added a comment - Hi Created a patch for this, its a first pass so let me know what's missing. I think the testing may be a little weak so could do with some pointers on it as well as overall architecture. Dip
          Paul Joseph Davis made changes -
          Field Original Value New Value
          Skill Level Regular Contributors Level (Easy to Medium)
          Paul Joseph Davis created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Paul Joseph Davis
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development