On Mon, Jan 13, 2014 at 9:36 PM, Jamie Lennox <[email protected]>wrote:
> 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. > Why not? Isn't this a backwards incompatible API change already? :-) 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? > If it's truly a requirement, we can look into how to make that work. The data is obviously present in the request, so we would just need to preserve it. Doug > > > > 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 >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
