Use linkage objects for relationships

[ctolsen]

Updating relationships now uses linkage objects, as the latest JSON API requires and as discussed in #404.

I ended up with a bit of yak shaving along the way, and updated the input for the tests in test_jsonapi.py as well. I don't think I broke anything else.

Regarding test_updating.TestAssociationProxy.test_extra_info, I'm not entirely sure what this is supposed to do. Shouldn't intermediate data basically be handled as being its own resource? I can't find any mention of intermediate data in the spec, unless I missed something, which is entirely possible.

In addition, I ended up having to eliminate the dictionary passing that was done and pass a list instead. I couldn't figure out what the dictionary was supposed to do and it created some trouble. If they are meant to update the related objects somehow, can't that be done by instead filling a list and manipulating the objects directly?

Anyway, that was a good start. Happy to take a look at some of the other m2m/association proxy stuff, but I need to know what actually needs doing first 😄

[jfinkels]

The dictionary thing was a work-in-progress solution to setting extra information on an association table. I hadn't quite gotten to implementing that part yet.

I wanted to support the behavior in test_extra_info because I think it is currently implemented in some form in Flask-Restless, and I want to maintain as much behavior as possible. See, for example, https://github.com/jfinkels/flask-restless/blob/master/tests/test_views.py#L581

[jfinkels]

As for more association proxy issues, check out, for example, test_fetching.py, which has a failing test in the TestAssociationProxy class, because I wasn't sure exactly how to define the model. Other modules like test_updating.py have similar issues.

[ctolsen]

Regarding extra info: I understand if it's legacy, but does this mean you would show the association object flatly in the related object? For instance, say you have a user, an author, and an association object where the user can follow the author. As best I can tell, you'd show it like this:

// truncated user object
'linkage': [{
  'type': 'author'
  // local attribute
  'name': 'Ernest Hemingway'
  // on the proxy
  'user_follows': 'true'
}

Is this the case? If it is, then there are a few problems – how an object looks would depend on its context, and it would open up for potentially conflicting attribute names.

You could, perhaps, remove this from Flask-Restless entirely, and handle it with hybrid properties in SQLAlchemy, leaving it up to implementation. It would not break compatibility on the API level at least. Just a suggestion – I feel like handling this increases complexity in a way that shouldn't be necessary. I'd rather handle those things on the user object in this case anyway.

[jfinkels]

A linkage object and a resource object are different, so a resource has one representation and a linkage object another. This was a clarification made to me in json-api/json-api#508 (comment). My thought was that when a response would include a linkage object (which, for a many-to-many relationship, represents a row in the association table), it would have an element representing the extra information corresponding to that row in the association table. Also, there's a fair bit of code of this sort of complexity anyway, since we need to do a lot of introspection to figure out columns, relations, etc. programmatically, so I'm not necessarily turned off by that.

[jfinkels]

I can fix that later though. I have squashed and pulled in your changes at 25020f9. Thanks.