table.apply() fails in some cases

[ljpearlman]

When table.apply() is called on a view that has a foreign key, it will attempt to create the existing foreign key. This will fail (because the fkey exists). It also seems to retry forever (this might be because ermrest returns 500 for those calls).

To recreate:

1. Create a view
2. Add a foreign key to the view
3. Do something like this:

table = model.table(schema_name, table_name)
column = table.column_definitions(column_name)
column.acls["select"] = ["*"]
table.apply()

and then look at the server error logs. I'm guessing this will also fail for any changes to a table, but I haven't tried anything other than changing a column acl.

[karlcz]

This sounds really weird as model.apply() should only be trying to update comment, annotation, acl, and acl_binding sub-resources. It should NEVER be trying to create model elements like fkeys. As I recall, the deriva-py apply() method maps to the per model node alter() methods for the whole model tree. This then maps to the ermrest alter method that was added more recently than other parts of the web api: catalog.put( '/schema/S/table/T/column/C', json={ "acls": ..., "acl_bindings": ..., "annotations": ..., "comment": ..., } ) where deriva-py sends a sparse map of the sub-resource to modify. I think this is unlikely to be a deriva-py bug at all, but something going wrong in the ermrest service with respect to the pseudo foreign key feature. It might even just be the model introspection failing on the subsequent request after the pseudo fkey change to the model. Can you try swapping in different operations in step (3) of your test sequence and see if they all cause errors? Try more basic catalog operations like: - catalog.get('/schema') - catalog.get('/schema/S/table/T/column/C/acl/select') - catalog.get('/schema/S/table/T/column/C') - catalog.put('/schema/S/table/T/column/C/comment', data="new comment") - catalog.put('/schema/S/table/T/column/C', json={"comment": "new comment"}) Karl