{"action":"created","issue":{"url":"https://api.github.com/repos/rbanffy/appengine-fixture-loader/issues/3","labels_url":"https://api.github.com/repos/rbanffy/appengine-fixture-loader/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/rbanffy/appengine-fixture-loader/issues/3/comments","events_url":"https://api.github.com/repos/rbanffy/appengine-fixture-loader/issues/3/events","html_url":"https://github.com/rbanffy/appengine-fixture-loader/pull/3","id":56116610,"number":3,"title":"Proposal for supporting ancestor keys in fixtures","user":{"login":"john2x","id":332885,"avatar_url":"https://avatars.githubusercontent.com/u/332885?v=3","gravatar_id":"","url":"https://api.github.com/users/john2x","html_url":"https://github.com/john2x","followers_url":"https://api.github.com/users/john2x/followers","following_url":"https://api.github.com/users/john2x/following{/other_user}","gists_url":"https://api.github.com/users/john2x/gists{/gist_id}","starred_url":"https://api.github.com/users/john2x/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/john2x/subscriptions","organizations_url":"https://api.github.com/users/john2x/orgs","repos_url":"https://api.github.com/users/john2x/repos","events_url":"https://api.github.com/users/john2x/events{/privacy}","received_events_url":"https://api.github.com/users/john2x/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-01-31T07:28:11Z","updated_at":"2015-02-05T14:24:51Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/rbanffy/appengine-fixture-loader/pulls/3","html_url":"https://github.com/rbanffy/appengine-fixture-loader/pull/3","diff_url":"https://github.com/rbanffy/appengine-fixture-loader/pull/3.diff","patch_url":"https://github.com/rbanffy/appengine-fixture-loader/pull/3.patch"},"body":"If ancestor keys are desired, then the whole ancestor\r\npath will need to be defined explicitly in the fixture data.\r\n\r\nCustom keys are specified by the `'__key__'` special attribute with\r\nits value being an array of kind and id pairs. The array will\r\nneed to have an even number of elements (the same specs\r\nas defined here https://cloud.google.com/appengine/docs/python/ndb/entities)\r\n\r\ne.g.\r\n\r\n```\r\n[{ ...\r\n    \"__key__\": [\"ParentKind\", \"parent_id\", \"SomeKind\", \"some_id\"]\r\n }]\r\n```\r\n\r\nP.S. \r\non line # 59 in `loader.py`, I moved the `post_processor(obj)` call to *outside* of the `for` loop (I believe this was a bug? As calling the `post_processor` in the loop would trigger it for each attribute. Let me know if that was intended instead.)\r\n\r\nEDIT: After reviewing, it seems `__key__` (instead of `_key`) would be a better attribute name?"},"comment":{"url":"https://api.github.com/repos/rbanffy/appengine-fixture-loader/issues/comments/73053560","html_url":"https://github.com/rbanffy/appengine-fixture-loader/pull/3#issuecomment-73053560","issue_url":"https://api.github.com/repos/rbanffy/appengine-fixture-loader/issues/3","id":73053560,"user":{"login":"john2x","id":332885,"avatar_url":"https://avatars.githubusercontent.com/u/332885?v=3","gravatar_id":"","url":"https://api.github.com/users/john2x","html_url":"https://github.com/john2x","followers_url":"https://api.github.com/users/john2x/followers","following_url":"https://api.github.com/users/john2x/following{/other_user}","gists_url":"https://api.github.com/users/john2x/gists{/gist_id}","starred_url":"https://api.github.com/users/john2x/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/john2x/subscriptions","organizations_url":"https://api.github.com/users/john2x/orgs","repos_url":"https://api.github.com/users/john2x/repos","events_url":"https://api.github.com/users/john2x/events{/privacy}","received_events_url":"https://api.github.com/users/john2x/received_events","type":"User","site_admin":false},"created_at":"2015-02-05T14:24:51Z","updated_at":"2015-02-05T14:24:51Z","body":"Yes, having `__key__`, `__id__` and `__parent__` would bring it closer to parity with the model constructor.\r\n\r\n> it seems there is a space for both methods.\r\n\r\nI agree. So for scenarios where a nested definition of KeyProperty references is a better fit, the `__children__some_property__` form will do. And for other scenarios where it doesn't fit (as with my use-case), specifying keys to `some_property` will also work.\r\n\r\n(Would the `__children__` form take precedence if/when both methods are used in a fixture (e.g. by mistake)?)\r\n"}}