0

In the context of a REST API, I've been using DBIx::Class to create related rows, i.e.

POST /artist
{ "name":"Bob Marley", "cds":[{"title":"Exodus"}] }

That ultimately calls $artist->new($data)->insert() which creates an Artist AND creates the related row(s) in the CD table. It then send back the resulting object to the user (via DBIC::ResultClass::HashRefInflator), including the created primary keys and default values. The problem arises when the user makes changes to those objects and send them back to the API again:

POST /artist/7
{ "name":"Robert Nesta Marley", "artistid":"7", 
  "cds":[{"title":"Exodus", "cdid":"1", "artistid":"7", "year":"1977"}] }

Now what? From what I can see from testing, DBIC::Row::update doesn't deal with changes in related rows, so in this case the name change would work, but the update to the CD's year would not. DBIC::ResultSet::update_or_create just calls DBIC::Row::update. So I went searching for some alternatives, and they do seem to exist, i.e. DBIC::ResultSet::RecursiveUpdate, but it hasn't been updated in 4 years, and references to it seem to suggest it should/would be folded into DBIC. Did that happen?

Am I missing something easier?

Obviously, I can handle this particular situation, but I have many APIs to write and it would be easier to handle it generically for all of them. I'm certainly tempted to use RecursiveUpdate, but wary due to its apparent abandonment.

Ryley
  • 21,046
  • 2
  • 67
  • 81
  • of course you can do all kind off things with your api, it's yours. But please reconsider what you said in your first line REST-api. Yes, one can POST to /artists including the (entire) list of cds. More commonly, create CD's, hold their ID's; create the Artist and post the ID's from the CD's to /artists/{artist_id}/cds. Basically: each thing it's own URI,created by a separate POST actions. Editing, do a PUT on the existing resource, not a POST with multiple resources mixed. We tried 'PATCH', but that is a different story. – vanHoesel Jan 25 '18 at 03:08

1 Answers1

1

Ribasushi promised to core the RecursiveUpdate feature if someone steps up and migrates its test suite to the DBIC schema and comes up with a sane API because he didn't like how RU handles this currently. Catalyst::Controller::DBIC::API is using RU under the hood as well as HTML::Formhandler::Model::DBIC both here in production since years without any issues.

So currently RecursiveUpdate is the way to go.

Alexander Hartmaier
  • 2,178
  • 12
  • 21