Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.7.0
    • Component/s: Futon
    • Labels:
      None
    • Skill Level:
      New Contributors Level (Easy)

      Description

      Currently Futon doesn't allow users to trigger replications by doc-IDs.
      This would be a nice addition and a good starting point for new contributors.

      1. COUCHDB-1011.patch
        2 kB
        Nikolai Teofilov

        Activity

        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 2809d2e03fbddf696ed88bf9a575cf59b4b36349 in couchdb-futon's branch refs/heads/master from Nikolai Teofilov
        [ https://git-wip-us.apache.org/repos/asf?p=couchdb-futon.git;h=2809d2e ]

        Replicate only specified document ids

        COUCHDB-1011

        Signed-off-by: Alexander Shorin <kxepal@apache.org>

        Show
        jira-bot ASF subversion and git services added a comment - Commit 2809d2e03fbddf696ed88bf9a575cf59b4b36349 in couchdb-futon's branch refs/heads/master from Nikolai Teofilov [ https://git-wip-us.apache.org/repos/asf?p=couchdb-futon.git;h=2809d2e ] Replicate only specified document ids COUCHDB-1011 Signed-off-by: Alexander Shorin <kxepal@apache.org>
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit fc9ab293cd1a9d74c78f8378b26d1c1a6a9d77e5 in couchdb's branch refs/heads/1.x.x from Nikolai Teofilov
        [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=fc9ab29 ]

        Replicate only specified document ids

        COUCHDB-1011

        Signed-off-by: Alexander Shorin <kxepal@apache.org>

        Show
        jira-bot ASF subversion and git services added a comment - Commit fc9ab293cd1a9d74c78f8378b26d1c1a6a9d77e5 in couchdb's branch refs/heads/1.x.x from Nikolai Teofilov [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=fc9ab29 ] Replicate only specified document ids COUCHDB-1011 Signed-off-by: Alexander Shorin <kxepal@apache.org>
        Hide
        koleto Nikolai Teofilov added a comment -

        Hi Filipe,

        1) I will try your suggestions this days.

        2) I have implemented this on CouchDBX 1.1 trunk 102936 and the replication with doc IDs did not work
        simultaneously with the continuos replication and this was the reason to put separated messages.

        I did following test:

        1. Create two local dbs "test1" and "test2".
        2. In database "test1" created three documents "a", "b", "c"
        3. Started a continuous replication from the new Futon interface:

        The post http header was:

        {"source":"test1","target":"test2","continuous":true,"doc_ids":["a"]}

        The status message was: "Replication2 db9fb: test1 -> test2<0.1280.0>Starting"

        5. Then I changes the document "test1/a" by appending a new filed.

        What I expected was to see this change replicated to the "test2/a" but nothing happened.

        I also tried between my local 1.1 couchdb and my couchone account 1.0.1 continuous replication + doc ID did not work as well.

        One point still is unclear to me: after replication is done the replication session appears under the 'Event' table otherwise
        the default label is shown "No replication". I think there should be new message that indicate the start of continuous replication or
        completing of a replication by doc IDs or the combination of both.

        The question is whether something should be shown under the 'Event' table by triggering the continuous replication or
        replication by doc IDs and if yes what will be the message?

        The _local_id is already shown in the event table and will be redundant to display this twice (as a replication session).
        By triggering the replication by doc ID only, there is no similar information like session ID
        to be shown and the whole response appears in the event table like:

        {"ok":true,"start_time":"Tue, 18 Jan 2011 20:02:01 GMT","end_time":"Tue, 18 Jan 2011 20:02:02 GMT","docs_read":1,"docs_written":1,"doc_write_failures":0}

        .

        It is also strange to show the default message "No replication" since there was one triggered or completed.

        This is why I came up with two messages showing the status of completed replication ("Named document replication" or "Continuous replication") instead the "No replication" message.

        Cheers,
        Nikolai

        Show
        koleto Nikolai Teofilov added a comment - Hi Filipe, 1) I will try your suggestions this days. 2) I have implemented this on CouchDBX 1.1 trunk 102936 and the replication with doc IDs did not work simultaneously with the continuos replication and this was the reason to put separated messages. I did following test: 1. Create two local dbs "test1" and "test2". 2. In database "test1" created three documents "a", "b", "c" 3. Started a continuous replication from the new Futon interface: The post http header was: {"source":"test1","target":"test2","continuous":true,"doc_ids":["a"]} The status message was: "Replication2 db9fb: test1 -> test2<0.1280.0>Starting" 5. Then I changes the document "test1/a" by appending a new filed. What I expected was to see this change replicated to the "test2/a" but nothing happened. I also tried between my local 1.1 couchdb and my couchone account 1.0.1 continuous replication + doc ID did not work as well. One point still is unclear to me: after replication is done the replication session appears under the 'Event' table otherwise the default label is shown "No replication". I think there should be new message that indicate the start of continuous replication or completing of a replication by doc IDs or the combination of both. The question is whether something should be shown under the 'Event' table by triggering the continuous replication or replication by doc IDs and if yes what will be the message? The _local_id is already shown in the event table and will be redundant to display this twice (as a replication session). By triggering the replication by doc ID only, there is no similar information like session ID to be shown and the whole response appears in the event table like: {"ok":true,"start_time":"Tue, 18 Jan 2011 20:02:01 GMT","end_time":"Tue, 18 Jan 2011 20:02:02 GMT","docs_read":1,"docs_written":1,"doc_write_failures":0} . It is also strange to show the default message "No replication" since there was one triggered or completed. This is why I came up with two messages showing the status of completed replication ("Named document replication" or "Continuous replication") instead the "No replication" message. Cheers, Nikolai
        Hide
        fdmanana Filipe Manana added a comment -

        Hi Nikolai,

        I'm not very familiar with Futon neither I am an expert on UIs, but:

        1) For error messages, displaying them under the 'Event' table with a gray/black textcolor gets unnoticed. Perhaps adding the message under or above the input textbox, in red, would be better;

        2) Replication by document IDs can now be continuous in 1.1, so the following change doesn't make sense anymore:

        + $("#records tbody.footer td")
        + .text((resp._local_id)? "Continuous replication" :
        +

        (Note that resp.history will always be defined as well)

        Lets see if someone more familiar/expert with Futon can comment on this and review it

        Show
        fdmanana Filipe Manana added a comment - Hi Nikolai, I'm not very familiar with Futon neither I am an expert on UIs, but: 1) For error messages, displaying them under the 'Event' table with a gray/black textcolor gets unnoticed. Perhaps adding the message under or above the input textbox, in red, would be better; 2) Replication by document IDs can now be continuous in 1.1, so the following change doesn't make sense anymore: + $("#records tbody.footer td") + .text((resp._local_id)? "Continuous replication" : + (Note that resp.history will always be defined as well) Lets see if someone more familiar/expert with Futon can comment on this and review it
        Hide
        koleto Nikolai Teofilov added a comment - - edited

        Thanks for the comments.
        I have modified the patch accordingly to code style convention and correct the typo.
        The point behind the line + if ( resp.history == null || resp._local_id) { is to distinguish between the replication by doc ids and continuos replication and display the the type of the triggered replication on the footer in the event table:
        + .text((resp._local_id)? "Continuous replication" :
        + "Named document replication");
        You can try this next week and if you don't like it i can change it. I think the event messages are a bit more consistent in this way.

        I am somehow not quite sure about the error messages so if you have better idea let me know. I also tried to use the input placeholder for the validation and error messages but this involve more code and somewhat strange user experience.

        Show
        koleto Nikolai Teofilov added a comment - - edited Thanks for the comments. I have modified the patch accordingly to code style convention and correct the typo. The point behind the line + if ( resp.history == null || resp._local_id) { is to distinguish between the replication by doc ids and continuos replication and display the the type of the triggered replication on the footer in the event table: + .text((resp._local_id)? "Continuous replication" : + "Named document replication"); You can try this next week and if you don't like it i can change it. I think the event messages are a bit more consistent in this way. I am somehow not quite sure about the error messages so if you have better idea let me know. I also tried to use the input placeholder for the validation and error messages but this involve more code and somewhat strange user experience.
        Hide
        fdmanana Filipe Manana added a comment -

        Also keep lines up to 80 characters wide, this is part of our convention.

        Show
        fdmanana Filipe Manana added a comment - Also keep lines up to 80 characters wide, this is part of our convention.
        Hide
        fdmanana Filipe Manana added a comment -

        Hi Nikolai,

        thanks, good work.

        Just by looking at the diff:

        1) You have a typo in the error messages: "Invavalid"

        2) Here:

        + if ( resp.history == null || resp._local_id) {

        I think just checking for "resp.ok === true" is enough and covers success for all types of replications (continuous, by doc IDs, filtered)

        I'll try out the patch next week.

        regards

        Show
        fdmanana Filipe Manana added a comment - Hi Nikolai, thanks, good work. Just by looking at the diff: 1) You have a typo in the error messages: "Invavalid" 2) Here: + if ( resp.history == null || resp._local_id) { I think just checking for "resp.ok === true" is enough and covers success for all types of replications (continuous, by doc IDs, filtered) I'll try out the patch next week. regards
        Hide
        koleto Nikolai Teofilov added a comment - - edited

        Filipe,

        Please review the changes and make your comments and suggestions.

        Regards,
        Nikolai

        Show
        koleto Nikolai Teofilov added a comment - - edited Filipe, Please review the changes and make your comments and suggestions. Regards, Nikolai
        Hide
        fdmanana Filipe Manana added a comment -

        Thanks Nikolai.

        You should really expect the input to be a JSON array, because commas (",") and semi-colons (";") are valid characters for a document ID. So splitting the input string by some character is not the way to go.

        Just grab the textbox input, try to JSON.parse() it and if an exception is thrown (or error returned) display an error message, otherwise check the result of JSON.parse() is an array of strings and use it as the value for "repOpts.doc_ids".

        I don't know on top of my head how error reporting is done all over Futon (dunno if it's consistent everywhere), you'll have to check that.

        regards

        Show
        fdmanana Filipe Manana added a comment - Thanks Nikolai. You should really expect the input to be a JSON array, because commas (",") and semi-colons (";") are valid characters for a document ID. So splitting the input string by some character is not the way to go. Just grab the textbox input, try to JSON.parse() it and if an exception is thrown (or error returned) display an error message, otherwise check the result of JSON.parse() is an array of strings and use it as the value for "repOpts.doc_ids". I don't know on top of my head how error reporting is done all over Futon (dunno if it's consistent everywhere), you'll have to check that. regards
        Hide
        koleto Nikolai Teofilov added a comment - - edited

        Initial implementation. The document IDs should be entered as a sequence of names separated by commas or semicolons. The whole entry must not be enclosed in square brackets!

        Example: doc1, doc2; doc3; doc4, doc5 ....

        Show
        koleto Nikolai Teofilov added a comment - - edited Initial implementation. The document IDs should be entered as a sequence of names separated by commas or semicolons. The whole entry must not be enclosed in square brackets! Example: doc1, doc2; doc3; doc4, doc5 ....
        Hide
        fdmanana Filipe Manana added a comment -

        Nikolai, I think to start out, a text box where the user types in a JSON array of strings (doc IDs) is a good way to start. If it's not empty, a replication with the "doc_ids" field set to that JSON array is triggered.

        Show
        fdmanana Filipe Manana added a comment - Nikolai, I think to start out, a text box where the user types in a JSON array of strings (doc IDs) is a good way to start. If it's not empty, a replication with the "doc_ids" field set to that JSON array is triggered.
        Hide
        koleto Nikolai Teofilov added a comment -

        Filipe, this sounds interesting.
        Any thoughts on how the interface should looks like?

        Show
        koleto Nikolai Teofilov added a comment - Filipe, this sounds interesting. Any thoughts on how the interface should looks like?

          People

          • Assignee:
            kxepal Alexander Shorin
            Reporter:
            fdmanana Filipe Manana
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development