{"action":"created","issue":{"url":"https://api.github.com/repos/dimagi/commcare-hq/issues/5990","labels_url":"https://api.github.com/repos/dimagi/commcare-hq/issues/5990/labels{/name}","comments_url":"https://api.github.com/repos/dimagi/commcare-hq/issues/5990/comments","events_url":"https://api.github.com/repos/dimagi/commcare-hq/issues/5990/events","html_url":"https://github.com/dimagi/commcare-hq/pull/5990","id":63705899,"number":5990,"title":"Fix UCR repeat data bug","user":{"login":"NoahCarnahan","id":2117127,"avatar_url":"https://avatars.githubusercontent.com/u/2117127?v=3","gravatar_id":"","url":"https://api.github.com/users/NoahCarnahan","html_url":"https://github.com/NoahCarnahan","followers_url":"https://api.github.com/users/NoahCarnahan/followers","following_url":"https://api.github.com/users/NoahCarnahan/following{/other_user}","gists_url":"https://api.github.com/users/NoahCarnahan/gists{/gist_id}","starred_url":"https://api.github.com/users/NoahCarnahan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/NoahCarnahan/subscriptions","organizations_url":"https://api.github.com/users/NoahCarnahan/orgs","repos_url":"https://api.github.com/users/NoahCarnahan/repos","events_url":"https://api.github.com/users/NoahCarnahan/events{/privacy}","received_events_url":"https://api.github.com/users/NoahCarnahan/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/dimagi/commcare-hq/labels/No%20lint%20errors","name":"No lint errors","color":"bfe5bf"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2015-03-23T11:58:39Z","updated_at":"2015-04-05T20:50:01Z","closed_at":"2015-04-05T13:16:52Z","pull_request":{"url":"https://api.github.com/repos/dimagi/commcare-hq/pulls/5990","html_url":"https://github.com/dimagi/commcare-hq/pull/5990","diff_url":"https://github.com/dimagi/commcare-hq/pull/5990.diff","patch_url":"https://github.com/dimagi/commcare-hq/pull/5990.patch"},"body":"When referencing repeated data in a `base_item_expression`, only one row (for the last item of the repeat) would exist in the database. This is demonstrated in the added test.\r\n\r\nThis was happening because, for each document in the repeat, we deleted all existing rows with the given doc id. Since repeat questions all have the same doc id, all previous entries for the repeat in the table were being deleted before saving each subsequent item. This PR fixes that by only deleting existing rows once per document, instead of once per repeat item.\r\n\r\nThis PR also removes the primary key constraint on the `doc_id` column of data source tables. Otherwise, rows for repeat questions can't be inserted, because they all have the same doc id. @czue @snopoke, will removing the primary key have any adverse effects that you know of? I know it's generally considered bad practice to not have a pk on every table. Should we give data source tables a separate id column? Maybe making a compound key out of doc id and repeat iteration, or something like that, is a better approach. Thoughts?\r\n"},"comment":{"url":"https://api.github.com/repos/dimagi/commcare-hq/issues/comments/89848823","html_url":"https://github.com/dimagi/commcare-hq/pull/5990#issuecomment-89848823","issue_url":"https://api.github.com/repos/dimagi/commcare-hq/issues/5990","id":89848823,"user":{"login":"snopoke","id":249606,"avatar_url":"https://avatars.githubusercontent.com/u/249606?v=3","gravatar_id":"","url":"https://api.github.com/users/snopoke","html_url":"https://github.com/snopoke","followers_url":"https://api.github.com/users/snopoke/followers","following_url":"https://api.github.com/users/snopoke/following{/other_user}","gists_url":"https://api.github.com/users/snopoke/gists{/gist_id}","starred_url":"https://api.github.com/users/snopoke/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/snopoke/subscriptions","organizations_url":"https://api.github.com/users/snopoke/orgs","repos_url":"https://api.github.com/users/snopoke/repos","events_url":"https://api.github.com/users/snopoke/events{/privacy}","received_events_url":"https://api.github.com/users/snopoke/received_events","type":"User","site_admin":false},"created_at":"2015-04-05T20:50:01Z","updated_at":"2015-04-05T20:50:01Z","body":":+1:\nOn 5 Apr 2015 15:12, \"Cory Zue\" <notifications@github.com> wrote:\n\n> from here\n> http://www.postgresql.org/docs/8.2/static/indexes-multicolumn.html\n>\n> ```A multicolumn GiST index can be used with query conditions that involve\n> any subset of the index's columns. Conditions on additional columns\n> restrict the entries returned by the index, but the condition on the first\n> column is the most important one for determining how much of the index\n> needs to be scanned. A GiST index will be relatively ineffective if its\n> first column has only a few distinct values, even if there are many\n> distinct values in additional columns.\n>\n>\n> so since `doc_id` is the first column i think we're good\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/dimagi/commcare-hq/pull/5990#issuecomment-89769622>.\n>\n"}}