)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":13055,"name":"Alexander Makarov","email":"ajiekcahdp.makapob@gmail.com","username":"amakarov"},"change_message_id":"2a8a4b13218b420d744cd1385db0a330e00d7d4d","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Ioram Schechtman Sette \u003ciss@cin.ufpe.br\u003e"},{"line_number":5,"context_line":"CommitDate: 2015-07-02 16:21:04 +0100"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"API spec for managing Attribute hierarchies in the Policy database"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"It allows administrators to add, modify, read and delete attribute hierarchies."},{"line_number":10,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9a1a9d01_34b06043","line":7,"updated":"2015-09-25 16:08:45.000000000","message":"line is too long","commit_id":"7e1a203d88ee5652a72d437bb21214015244f807"},{"author":{"_account_id":13055,"name":"Alexander Makarov","email":"ajiekcahdp.makapob@gmail.com","username":"amakarov"},"change_message_id":"2a8a4b13218b420d744cd1385db0a330e00d7d4d","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"API spec for managing Attribute hierarchies in the Policy database"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"It allows administrators to add, modify, read and delete attribute hierarchies."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Change-Id: I3d8f176134231bb9d0b013cbbf20bfaf92bd51a8"},{"line_number":12,"context_line":"Co-Authored-By: David Chadwick \u003cd.w.chadwick@kent.ac.uk\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9a1a9d01_d487a45f","line":9,"updated":"2015-09-25 16:08:45.000000000","message":"Same here","commit_id":"7e1a203d88ee5652a72d437bb21214015244f807"}],"specs/backlog/identity-api-v3-os-attribute-hierarchy.rst":[{"author":{"_account_id":13055,"name":"Alexander Makarov","email":"ajiekcahdp.makapob@gmail.com","username":"amakarov"},"change_message_id":"6b817e1215cb20bda073c7be56e9aee83b8ffb8e","unresolved":false,"context_lines":[{"line_number":63,"context_line":"            \"self\": \"http://identity:5000/v3/attributes/--attribute-id--\""},{"line_number":64,"context_line":"        }"},{"line_number":65,"context_line":"    }"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"List attribute hierarchies"},{"line_number":69,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_024a0926","line":66,"updated":"2015-05-22 16:54:42.000000000","message":"Adjacency list is not the best choice to store hierarchies - it is best used for nets. You will need to resolve circular dependencies and use recursions to work with such structure. While the structure is relatively compact I\u0027d recommend using directory-like structure here, as in https://review.openstack.org/#/c/173424/","commit_id":"8060407b988604ac380b2f492deba299637eac4c"},{"author":{"_account_id":6534,"name":"David Chadwick","email":"d.w.chadwick@truetrust.co.uk","username":"d-w-chadwick"},"change_message_id":"b9e2929c12c225f8dcf7a5329aabaae8995b01e6","unresolved":false,"context_lines":[{"line_number":63,"context_line":"            \"self\": \"http://identity:5000/v3/attributes/--attribute-id--\""},{"line_number":64,"context_line":"        }"},{"line_number":65,"context_line":"    }"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"List attribute hierarchies"},{"line_number":69,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_974f5233","line":66,"in_reply_to":"7a016987_024a0926","updated":"2015-05-22 22:43:38.000000000","message":"1. we dont *need* to resolve circular dependencies as the policy store is simply a store: what you put in you get back. Its the PDP that needs to make sure it is OK. However it would be *advantageous* to do this to help stop the administrator from screwing up by creating a duff policy. (But again this could be a GUI task or a function of the POST command ie. reject the input of a hierarchy that contains a circular dependency).\n\n2. We dont need to use recursions because we dont do anything with the hierarchies. They are simply stored here and shipped out to the cloud systems. We dont support modification of them.\n\n3. The only bit of code that we will write that will parse the hierarchy is in the policy mapping code that converts the DNF into an Openstack policy and will expand the hierarchies (until OpenStack supports them). This code will need to trap any circular dependencies and then raise an exception if one occurs. Even if the policy is supposed to not contain screwed up hierarchies, the mapping code will still need to check this when expanding it. So putting code in the database is a duplication of code that will need to be in the mapping code regardless of whether the database stores circular hierarchies or not.\n\nSo I am not convinced that complicating the storage system provides any benefit","commit_id":"8060407b988604ac380b2f492deba299637eac4c"},{"author":{"_account_id":2218,"name":"Adam Young","email":"adam@younglogic.com","username":"ayoung"},"change_message_id":"27eb8930a52671a89c4f112b1b1c6da39937942a","unresolved":false,"context_lines":[{"line_number":63,"context_line":"            \"self\": \"http://identity:5000/v3/attributes/--attribute-id--\""},{"line_number":64,"context_line":"        }"},{"line_number":65,"context_line":"    }"},{"line_number":66,"context_line":""},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"List attribute hierarchies"},{"line_number":69,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_b1ef5786","line":66,"in_reply_to":"7a016987_974f5233","updated":"2015-05-28 21:28:58.000000000","message":"I think the format is OK, but the naming here is very strange and hard to understand. sup_value and sub_value look too similiar to quickly parse.  parent/child would be better, but why not just make them key value pairs, with the parent the key and the list of children the values like this:\n     \"attribute\": \"loa\",\n        \"hierarchy\": { \"value1\" : [\"value2\".\"value3\"],\n                       \"value3\": {\"value4\", \"value5\"]}\nas that is both clearer and more concise.\n\nIf we wanted to keep going, we could continue the key value pair pattern on down the hierarchy and define the whole thing in one pass:  values with no children could be empyt lists:\n\n{ \"value1\" : {\"value2\":[], \"value3\": {\"value4\":[],  \"value5\":[]}","commit_id":"8060407b988604ac380b2f492deba299637eac4c"}]}