Client provided `id` handling changes

[binarypaladin]

Is your feature request related to a problem? Please describe.

Allow id field to be set outside the attributes object.

In the main API I operate, idempotence on create is handled by just setting the id of the resource. It's one of the joys of using UUIDs. Ash currently works with this:

{
  "data": {
    "attributes": {
      "id": "d67fc7b1-24d1-4c3a-9129-97ece194cbc8"
    }
  }
}

But not this:

{
  "data": {
    "id": "d67fc7b1-24d1-4c3a-9129-97ece194cbc8"
}

Describe the solution you'd like

Simply accept id as a direct child of data. (I would say if the client provided it in two spots, an error is returned rather than argue about which has precedence.)

Express the feature either with a change to resource syntax, or with a change to the resource interface

Accepting IDs shouldn't require any actual DSL unless you wanted to support returning errors on id being a direct child of data.

[binarypaladin]

I'd also like to add, there are a bunch of open issues for JSON:API. If any make sense to handle while I'm looking at my own pet peeves, lemme know. I'm going to try to work on the docs as I get through this stuff too.

[zachdaniel]

That would be fine to me. There may be some potential difficulty implementing it, as currently the error struct is the same when a value conflicts vs when a value is invalid for some other reason.

So this may involve a change to ash core, and potentially in ash_postgres to have it generate errors in a way that we can hook into. If it uses a new struct (which will have to be opt-in via configuration) then we can simply configure a status for it.

Please break the the id in data support into its own issue.

Both of these make sense to me to support, PRs welcome.

[zachdaniel]

The id one is probably pretty easy :) If we get different values for id in two places we can show an error, but if they are both present and are the same that should be fine.

[binarypaladin]

That would be fine to me. There may be some potential difficulty implementing it, as currently the error struct is the same when a value conflicts vs when a value is invalid for some other reason.

So this may involve a change to ash core, and potentially in ash_postgres to have it generate errors in a way that we can hook into. If it uses a new struct (which will have to be opt-in via configuration) then we can simply configure a status for it.

I think we can match on something other than the struct type though, right? I think first I just add the escape hatch you proposed in #277 (that would solve this) and then we consider if there really needs to be any other behavior anyway.

Please break the the id in data support into its own issue.

Any issue just keeping it here since I think #277 solves my other issue? We can refine on or after those submissions and use that to create to default behaviors so everyone doesn't have to reinvent the wheel.

[zachdaniel]

Sure, can we put the details from here on 409 errors into that other issue then?

[sprite2005]

Any updates on this? I'm using JAPX for encoding/decoding for most of my app but have to use custom encoding for create actions that provide client side generated UUIDs.

[zachdaniel]

I don't believe so, but this would likely be a pretty straightforward addition. PRs welcome! 🙇

[binarypaladin]

I’ll try to find the time to do this. When I started using Ash we planned on using JSON:API but I ended up having to conform our system with a quasi standard where I work. (Ash has made us too productive for our own good.)

I just haven’t had the time to go back and mess with the JSON:API implementation since.