{"action":"created","issue":{"url":"https://api.github.com/repos/frictionlessdata/specs/issues/495","repository_url":"https://api.github.com/repos/frictionlessdata/specs","labels_url":"https://api.github.com/repos/frictionlessdata/specs/issues/495/labels{/name}","comments_url":"https://api.github.com/repos/frictionlessdata/specs/issues/495/comments","events_url":"https://api.github.com/repos/frictionlessdata/specs/issues/495/events","html_url":"https://github.com/frictionlessdata/specs/issues/495","id":243402006,"number":495,"title":"Do we really need polymorphic JSON fields?","user":{"login":"danielfireman","id":8951363,"avatar_url":"https://avatars1.githubusercontent.com/u/8951363?v=4","gravatar_id":"","url":"https://api.github.com/users/danielfireman","html_url":"https://github.com/danielfireman","followers_url":"https://api.github.com/users/danielfireman/followers","following_url":"https://api.github.com/users/danielfireman/following{/other_user}","gists_url":"https://api.github.com/users/danielfireman/gists{/gist_id}","starred_url":"https://api.github.com/users/danielfireman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danielfireman/subscriptions","organizations_url":"https://api.github.com/users/danielfireman/orgs","repos_url":"https://api.github.com/users/danielfireman/repos","events_url":"https://api.github.com/users/danielfireman/events{/privacy}","received_events_url":"https://api.github.com/users/danielfireman/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2017-07-17T13:50:48Z","updated_at":"2017-07-19T11:05:45Z","closed_at":"2017-07-17T14:00:09Z","body":"Disclaimer: If you've already had this conversation, please point to that and close this issue.\r\n\r\nContext: Implementation of [primary key](https://specs.frictionlessdata.io/table-schema/#primary-key) field validation in a statically typed language (Go). I am calling a field _polymorphic_ if users can assign it to values of two (or more) different types, depending on the usage. As an example, the \"primaryKey\" field.\r\n\r\nI started implementing this in Go and the code would end up being much more complicated (probably much slower as well) than a version based on one type. I also believe this is much easier to read by a human. So, I am asking if we really need or this feature or if it is possible to make it a list, which will work in conjunction with #494 to making the semantic/readability of those fields clearer. The same for foreign key polymorphic fields.\r\n\r\nI know that we must not drive important decisions on implementation details, but I am seeing this feature as syntax sugar. "},"comment":{"url":"https://api.github.com/repos/frictionlessdata/specs/issues/comments/316351066","html_url":"https://github.com/frictionlessdata/specs/issues/495#issuecomment-316351066","issue_url":"https://api.github.com/repos/frictionlessdata/specs/issues/495","id":316351066,"user":{"login":"danielfireman","id":8951363,"avatar_url":"https://avatars1.githubusercontent.com/u/8951363?v=4","gravatar_id":"","url":"https://api.github.com/users/danielfireman","html_url":"https://github.com/danielfireman","followers_url":"https://api.github.com/users/danielfireman/followers","following_url":"https://api.github.com/users/danielfireman/following{/other_user}","gists_url":"https://api.github.com/users/danielfireman/gists{/gist_id}","starred_url":"https://api.github.com/users/danielfireman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danielfireman/subscriptions","organizations_url":"https://api.github.com/users/danielfireman/orgs","repos_url":"https://api.github.com/users/danielfireman/repos","events_url":"https://api.github.com/users/danielfireman/events{/privacy}","received_events_url":"https://api.github.com/users/danielfireman/received_events","type":"User","site_admin":false},"created_at":"2017-07-19T11:05:45Z","updated_at":"2017-07-19T11:05:45Z","body":"Super! Learnt lot reading it."}}
{"actor":{"display_login":"danielfireman"}}