feat: Non-atomic bulk operation support

[egeersoz]

Code of Conduct

• I agree to follow this project's Code of Conduct

AI Policy

• I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

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

JSON:API spec allows both atomic and non-atomic bulk actions. This library seems to prefer atomic operations, but support for non-atomic operations seems lacking.

Use case: we're selecting students on a table and assigning them homework. There are various scenarios where this assignment may fail for each student. In those scenarios, we don't want to fail and roll back the entire operation because it would be really bad UX.

Describe the solution you'd like

In scenarios where bulk operation success is partial, we instead want to return a 207 Multi-Status response. Based on the spec, this would look something like this:

HTTP/1.1 207 Multi-Status
Content-Type: application/vnd.api+json

{
  "data": [
    {
      "type": "student-assignments",
      "id": "1",
      "attributes": { "assigned_at": "2023-10-15T10:30:00Z" }
    },
    {
      "type": "student-assignments", 
      "id": "2",
      "attributes": { "assigned_at": "2023-10-15T10:30:00Z" }
    },
    {
      "type": "student-assignments",
      "id": "3", 
      "attributes": { "assigned_at": "2023-10-15T10:30:00Z" }
    }
  ],
  "errors": [
    {
      "status": "422",
      "title": "Already Assigned",
      "detail": "Student with ID '4' is already assigned that homework",
      "source": { "pointer": "/data/3" },
      "meta": { "student_id": "4" }
    },
    {
      "status": "404",
      "title": "Student Not Found", 
      "detail": "Student with ID '5' does not exist",
      "source": { "pointer": "/data/4" },
      "meta": { "student_id": "5" }
    }
  ],
  "meta": {
    "total_requested": 5,
    "successful": 3,
    "failed": 2
  }
}

I know about the transaction? false option but that doesn't quite get us all the way where we need to be. We also need the framework to compile the non-atomic results and send them to the client in the 207 format in the spec.

Describe alternatives you've considered

We considered sending individual requests for each operation (not ideal, there can be hundreds) and also writing our custom logic (which defeats the purpose of using this library).

Additional context

No response

[zachdaniel]

This is a great thing to add, but is not something I personally could do any time soon. It requires improvements to Ash core in addition to AshJsonApi.

To support it, we would need:

1. a new route type, like bulk_update, which supports options like multi_inputs?: true, atomic?: false, transaction: :per_record to say that it should opt out of doing atomic/transactional work, and accept multiple inputs as opposed to updating all that match.
2. Ash core does not currently support "record-by-record" updating. We'd need to implement Ash.update_all(changesets) or some other formulation of bulk updates.
3. Then we can leverage that for the bulk_update route type.
4. Bulk actions/bulk results currently support partial successes, and either currently have the input index set on them or could easily be updated to do so, so we can gather up the errors and create the response shown in the original report.

[zachdaniel]

If we add update_all logic to the data layer, then the bulk create action can be copied almost line-for-line to support Ash.update_all FWIW, since they are almost entirely the same thing.