Relationship not included in payload on PUT

[kurko]

Problem

Relationships are not being included in payloads when the request is an update (PUT). If the request is a creation (POST), the relationship hash is included normally.

Expected behavior: relationships should be included on both POST and PUT.

Example

Given a Post resource that has a Category (dynamic public var category: Category?).

spine.registerResource(Post.resourceType) { Post() }
spine.registerResource(Category.resourceType) { Category() }

var category = Category()
category.id   = "some-uuid"
category.name = "Swift"

var post = Post()
post.id     = "uuid-id"
post.title   = "title"
post.body  = "body"
post.category = category

spine.save(post)

In the case above, a PUT operation takes place because id was set. data.relationships is NOT included in the call.

If we remove post.id = "uuid-id", then a POST operation will take place and with that, data.relationships is included in the payload.

---

I could very well tackle this issue but I have 5 PRs opened right now and I'd need to know if you'd accept this before starting, specially given the Swift 2 effort.

[wvteijlingen]

Because Spine doesn't support client side ids, SaveOperation simply looks at the id field to check whether it should be a POST or PUT.

The reason that relationships are not included on PUT requests is because we can't be sure whether a relationship has been fetched from the server in the first place. If you fetch a resource without relationship data, change an attribute and then save it including the empty relationship data, the relationships would be overwritten with empty data (and thus lost).

I don't think we can easily work around this, unless we add dirty checking or do a lot of bookkeeping on which attributes were fetched. If you have a different solution for this project, I'm happy to integrate it. However, if it's a big change it might be better to hold off on this until we converted to Swift 2.0.

[kurko]

Ok. I added category_id to my data.attributes to get it done (I own the server, so...). Not good but it'll work for now. As for client side ids, I agree, it's doing PUTs and I have to do some work on the server.

[wvteijlingen]

I'm closing this issue in favour of the Client side ids issue: #37. When client side ids are implemented, this should be resolved as well.