{"action":"opened","issue":{"url":"https://api.github.com/repos/tripal/tripal/issues/70","repository_url":"https://api.github.com/repos/tripal/tripal","labels_url":"https://api.github.com/repos/tripal/tripal/issues/70/labels{/name}","comments_url":"https://api.github.com/repos/tripal/tripal/issues/70/comments","events_url":"https://api.github.com/repos/tripal/tripal/issues/70/events","html_url":"https://github.com/tripal/tripal/issues/70","id":218679703,"number":70,"title":"Genetic_code, so and frange PostgreSQL schemata ownership when using multi-chado instances","user":{"login":"spficklin","id":1719352,"avatar_url":"https://avatars3.githubusercontent.com/u/1719352?v=3","gravatar_id":"","url":"https://api.github.com/users/spficklin","html_url":"https://github.com/spficklin","followers_url":"https://api.github.com/users/spficklin/followers","following_url":"https://api.github.com/users/spficklin/following{/other_user}","gists_url":"https://api.github.com/users/spficklin/gists{/gist_id}","starred_url":"https://api.github.com/users/spficklin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/spficklin/subscriptions","organizations_url":"https://api.github.com/users/spficklin/orgs","repos_url":"https://api.github.com/users/spficklin/repos","events_url":"https://api.github.com/users/spficklin/events{/privacy}","received_events_url":"https://api.github.com/users/spficklin/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-04-01T08:17:28Z","updated_at":"2017-04-01T08:17:28Z","closed_at":null,"body":"Copied from Drupal issue: https://www.drupal.org/node/2825357\r\n\r\nFrom @guignonv:\r\n\r\nWhen using several Chado instances using the Multi-Chado module, on installation of a new instance the common schemata 'genetic_code', 'so' and 'frange' are dropped and re-created.\r\nThe PostgreSQL user account used to create the new Chado instance will be the owner of those schemata. The default Drupal account or event other PostgreSQL account used for other instances may not be allowed to access those schemata anymore.\r\nThis appends in tripal_core/includes/tripal_core.chado_install.inc:tripal_core_reset_chado_schema().\r\n\r\nI don't have the best solution yet but I see several ways to fix it...\r\n\r\n#1: we keep those schemata if they exist but then, updating Chado may be an issue if those schema are not updated.\r\n\r\n#2: after installation of a new Chado instance, we reassign the ownership to Drupal default user. Then comes the \"how do we know a new installation is done?\". I'm thinking of 2 possible hooks to solve that: one would be to simply add a \"hook_chado_installed\" when the installation process is done. Another more flexible possibility would be to add a hook to Tripal jobs API to make it fire hooks when a job is completed so other modules can do some post-processing. Here the Multi-Chado module would reassign the appropriate ownership if the job run was a successful creation of a new Chado instance.\r\n\r\n#3: Give a way to alter those common schemata names so the original ones won't be removed by the installation process and the installation SQL scripts could also be altered to they reflect those changes. For instance, if I install Chado in a \"private_chado\" schema, I would make its PostgreSQL functions use the schemata private_genetic_code, and such...\r\n\r\nOther point of views are welcome!"}}
{"actor":{"display_login":"spficklin"}}