Dmitri Pal wrote:
Rob Crittenden wrote:
Adam Young wrote:
On 10/22/2010 04:08 PM, Rob Crittenden wrote:
Adam Young wrote:
I did a quick spike into what it would take to implement my idea
and got
this far (done in internal.py)


class bulk(Command):

takes_args = (
List('methods?',
doc=_('Nested Methods to execute'),
),
)

has_output = output.standard_entry
def execute(self, *args, **options):
results=dict();
for arg in args:
for method in arg:
results[method]=unicode("OK")

return dict(result=results, value=unicode("Something"))

api.register(bulk)




And tested it using:


[ayo...@ipa ~]$ curl -H "Content-Type:application/json" -H
"Accept:applicaton/json" -H "Accept-Language:en" --negotiate -u :
--cacert /etc/ipa/ca.crt -d
'{"method":"bulk","params":[[],{"methods":"1,2" }],"id":6}' -X POST
http://localhost:8888/ipa/json
{
"error": null,
"id": 6,
"result": {
"result": {
"1": "OK",
"2": "OK"
},
"summary": null,
"value": "Something"
}
}


I don't think the List type is going to work for this. We need, I
think,
a Dict type here, in order to support the full JSON Parsing, we might
need a true array type as well. Or, we could make separate methods for
JSON and XML and make a type for each of those. Any thoughts?


You can define your own output format, look in ipalib/Output.py. In
this case I think a list of a dict of results is probably the right
thing.

Yeah, problem is input format, not output. Output I know we can do based
on how we did the json_metadata, although based on your comment, it
looks like we can do it in a more standard manner.

Ah, ok. I think something like:

MULTICALL: list of CALL

CALL: dict(METHODNAME, ARGS, OPTIONS)

METHODNAME: string

ARGS: list

OPTIONS: dict

ex:

[
    {'method': 'user_show',
     'args': ['admin'],
     'options': {'all': True, 'raw': True}
    },
    {'method': 'user_show',
     'args': ['kfrog'],
     'options': {'all': True, 'raw': True}
    },
]

IIRC this is pretty similar to what you first proposed.

rob

There should be some metadata about what to do if some call fails.
Like fail the whole thing and stop or continue for the rest.
So there should be a dictionary of the multicall properties.

We have decided to soldier on in case of failure. We'll add additional logic to handle this in the future. It can take the form of additional keys in the request which won't affect backwards compatibility.

This will have the effect of keeping bulk processing very tight.

rob







So we have a list of results whose position maps to each method call.
In each position we store the name of the method call (just for
clarify) and the results of that call.

It might look like this to show two separate users:

[{'method': 'user_show', result={'result': {'dn':
u'uid=admin,cn=users,cn=accounts,dc=greyoak,dc=com', 'memberof_group':
(u'admins',), 'uid': (u'admin',), 'loginshell': (u'/bin/bash',),
'homedirectory': (u'/home/admin',), 'sn': (u'Administrator',),
'memberof_rolegroup': (u'replicaadmin',), 'memberof_taskgroup':
(u'managereplica', u'deletereplica')}, 'value': u'admin', 'summary':
None}},
{'method': 'user_show', result={'result': {'dn':
u'uid=kfrog,cn=users,cn=accounts,dc=greyoak,dc=com', 'memberof_group':
(u'ipausers',), 'uid': (u'kfrog',), 'loginshell': (u'/bin/bash',),
'homedirectory': (u'/home/kfrog',), 'givenname': (u'Kermit',), 'sn':
(u'Frog',)}, 'value': u'kfrog', 'summary': None}}]

You could probably even throw in *args and **options too.

This way when you pull result[0]['result'] you have what user_show
would have returned for user_show admin.

rob


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to