{"action":"created","issue":{"url":"https://api.github.com/repos/talis/tripod-php/issues/101","repository_url":"https://api.github.com/repos/talis/tripod-php","labels_url":"https://api.github.com/repos/talis/tripod-php/issues/101/labels{/name}","comments_url":"https://api.github.com/repos/talis/tripod-php/issues/101/comments","events_url":"https://api.github.com/repos/talis/tripod-php/issues/101/events","html_url":"https://github.com/talis/tripod-php/issues/101","id":153962493,"number":101,"title":"Allow views and tables to self-update to the latest config","user":{"login":"robotrobot","id":933278,"avatar_url":"https://avatars.githubusercontent.com/u/933278?v=3","gravatar_id":"","url":"https://api.github.com/users/robotrobot","html_url":"https://github.com/robotrobot","followers_url":"https://api.github.com/users/robotrobot/followers","following_url":"https://api.github.com/users/robotrobot/following{/other_user}","gists_url":"https://api.github.com/users/robotrobot/gists{/gist_id}","starred_url":"https://api.github.com/users/robotrobot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/robotrobot/subscriptions","organizations_url":"https://api.github.com/users/robotrobot/orgs","repos_url":"https://api.github.com/users/robotrobot/repos","events_url":"https://api.github.com/users/robotrobot/events{/privacy}","received_events_url":"https://api.github.com/users/robotrobot/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/talis/tripod-php/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2016-05-10T09:30:09Z","updated_at":"2016-05-14T12:08:11Z","closed_at":null,"body":"At the moment, if a table or view specification changes, it is a manual process to re-run generation and upgrade data to the latest spec.\r\n\r\nInstead, allow tripod to automatically upgrade data when it encounters data not generated with the latest spec.\r\n\r\nIt is acceptable that this is an eventually consistent feature, seeing as views and tables are generally considered eventually consistent."},"comment":{"url":"https://api.github.com/repos/talis/tripod-php/issues/comments/219216873","html_url":"https://github.com/talis/tripod-php/issues/101#issuecomment-219216873","issue_url":"https://api.github.com/repos/talis/tripod-php/issues/101","id":219216873,"user":{"login":"junglebarry","id":242248,"avatar_url":"https://avatars.githubusercontent.com/u/242248?v=3","gravatar_id":"","url":"https://api.github.com/users/junglebarry","html_url":"https://github.com/junglebarry","followers_url":"https://api.github.com/users/junglebarry/followers","following_url":"https://api.github.com/users/junglebarry/following{/other_user}","gists_url":"https://api.github.com/users/junglebarry/gists{/gist_id}","starred_url":"https://api.github.com/users/junglebarry/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/junglebarry/subscriptions","organizations_url":"https://api.github.com/users/junglebarry/orgs","repos_url":"https://api.github.com/users/junglebarry/repos","events_url":"https://api.github.com/users/junglebarry/events{/privacy}","received_events_url":"https://api.github.com/users/junglebarry/received_events","type":"User","site_admin":false},"created_at":"2016-05-14T12:08:11Z","updated_at":"2016-05-14T12:08:11Z","body":"I agree with most of the above.\n\nI have a question, though: Is there only one instance of the code running\nat once?\n\nConsider, for example, you have two machines running the code, and due to\nfailed release - or just a slow rolling release - they reach a state where\nthe spec files have different hashes. Couldn't you get to a state where\neach machine thinks it holds the \"right\" hash, and they enter a\nmutually-recursive loop to \"correct\" hashes generated by the other machine?\n\nIn this case, order provides a natural resolution to the problem, where\ndifference alone does not. That does not magically resolve the other\nproblems of ordering you rightly raise; it just trades some off against\nothers. I'm assuming that the risk of having such a scenario is considered\nlow or impossible, compared to what might arise through versioning (I\nagree: that seems to have more opportunity to fail).\n\nHowever, if it's a possibility we should consider it, at least so we know\nwhat problem scenarios might arise on distribution.\nOn Sat, 14 May 2016 at 11:52, Chris Clarke <notifications@github.com> wrote:\n\n> On hashing and atomic counters - I prefer hashing. Three reasons -\n>\n> 1) the fact that the spec is different matters, not that it is a\n> newer/older version. This seems closer to hashing. To atomically increment\n> everyone needs to be in agreement what the old version was. Typical\n> distributed system hard problem. Unless you need it, avoid. See point 1.\n> 2) Format changes don't increment the hash. For example converting the\n> spec to a php array and hashing that removes a change like whitespace\n> addition or changes from single to double quotes from the equation and\n> means a hash of two semantically equivalent specs with different formatting\n> is the same hash\n> 3) Don't have to rely on someone deciding that a new version is a new\n> version (i.e. a dev). The system decides (via the hash) what a new version\n> is. This automates away the human and is good.\n>\n> —\n> You are receiving this because you commented.\n> Reply to this email directly or view it on GitHub\n> <https://github.com/talis/tripod-php/issues/101#issuecomment-219213924>\n>\n"}}