On Mon, 2014-01-13 at 10:05 -0500, Doug Hellmann wrote: > > > > > On Sun, Jan 12, 2014 at 6:33 PM, Jamie Lennox <[email protected]> > wrote: > On Fri, 2014-01-10 at 10:23 -0500, Doug Hellmann wrote: > > > > > > > > > > On Thu, Jan 9, 2014 at 12:02 AM, Jamie Lennox > <[email protected]> > > wrote: > > Is there any way to have WSME pass through arbitrary > > attributes to the created object? There is nothing > that i can > > see in the documentation or code that would seem to > support > > this. > > > > In keystone we have the situation where arbitrary > data was > > able to be attached to our resources. For example > there are a > > certain number of predefined attributes for a user > including > > name, email but if you want to include an address > you just add > > an 'address': 'value' to the resource creation and > it will be > > saved and returned to you when you request the > resource. > > > > Ignoring whether this is a good idea or not (it's > done), is > > the option there that i missed - or is there any > plans/way to > > support something like this? > > > > > > There's a change in WSME trunk (I don't think we've released > it yet) > > that allows the schema for a type to be changed after the > class is > > defined. There isn't any facility for allowing the caller to > pass > > arbitrary data, though. Part of the point of WSME is to > define the > > inputs and outputs of the API for validation. > > > > > > How are the arbitrary values being stored in keystone? What > sorts of > > things can be done with them? Can an API caller query them, > for > > example? > > > > > > Doug > > > So you can't query based on these arbitrary values but they > are there as > part of the resource. We have generic middleware that > interprets the > incoming json or xml to python dictionaries. Then we extract > the > queryable information for storing into database cells. In the > case of > User these are: id, name, password, enabled, domain_id, > default_project_id. Everything else in the dictionary is > stored in an > 'extra' column in the database as a JSON dictionary. When we > reconstruct > the User object we recreate the extra dictionary and update it > with the > known attributes. > > So there is no restriction on types or depth of objects, and > whilst you > can't query from those attributes they will always be present > if you get > or list the user. > > Note that User is probably a bad example in this because of > LDAP and > other backends but the idea is the same for all keystone > resources. > > > So I don't think that changing the WSME type after definition > is useful > in this case. Is it the sort of thing that would be possible > or accepted > to add to WSME? > > From the little bit of looking i've done it appears that WSME > loops over > the defined attributes of the class and extracts those from > the message > rather than looping over keys in the message which makes this > more > difficult. Can WSME be made to decode all values in a purely > python > primative way (eg don't decode dates, objects etc, just give > python > dictionaries like from a json.loads)? > > > WSME asserts that APIs should be well and clearly defined, so that > callers of the API can understand what they are supposed to (or > required to) pass in, and what they will receive as a response. > Accepting arbitrary data goes somewhat against this design goal. > > > I would prefer not to have keystone using yet another > framework from the > rest of openstack, but should i just be looking to use > jsonschema or > something instead? > > > What requirement(s) led to keystone supporting this feature?
I completely agree with you/WSME that this is a bad situation. I've got no idea where the requirement came from however it is something that is supported now and so not something we can back out of. I don't think WSME should advocate the situation, though it will already ignore additional attributes i'm wondering what would be involved with just collecting and stashing those additional attributes? > Doug > > > > > Jamie > > > > > > > > > Thanks, > > > > Jamie > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
