Update won't work with formula/lookup fields in the table

[dmerand]

Hi,

I was having a ton of problems getting an existing record to update, and then I found this line in lib/airtable/records.rb:

# Airtable will complain if we pass an 'id' as part of the request body.
def fields_for_update; fields.except(:id); end

It turns out that Airtable will complain if you've got any calculated fields in the table, and it won't update :/

What I've done to fix this in my code is a monkeypatch like this:

module Airtable
  class Record
    def fields_for_update
      fields.except(:id, :FormulaField, :LookupField)
    end
  end
end

... but I wonder if there's a more elegant way to do this?

The most elegant way to fix it would be if Airtable didn't FAIL when you try to update a calculated field (or the ID), but merely sent along some kind of warning. I'll send this idea along to them as well.

Thanks! -Donald

[dmerand]

Another note that I forgot to add: the Airtable API allows for PATCH in addition to PUT:

To update some (but not all) fields of a [whatever] record, issue a PATCH request to the record endpoint. Any fields that are not included will not be updated.

However this gem appears to be converting all updates to PUT requests that post all of the fields. Perhaps on update it would be better to check whether all fields are being updated, or just a subset, and then issue the according PATCH/PUT. This would likely solve the problem of not being able to update formula/calc fields.

Hope that helps. Thanks again!

[syrnick]

Thanks Donald!

That makes sense. There are two conflicting objectives that we'd need to resolve:

First is that the API should accept back any value that it returned. You should be able to read a record, update it and save it back.

Second objective is to protect API users from unexpected data loss and silently swallowed errors. I.e. If you unintentionally update a computed field in the client and then try to save it back, it should error out.

The solution is probably to ignore computed fields submitted to the API for now. Perhaps we could return a warning in the response if that happens.

Eventually we might provide the list of the computed fields to the client. The client could then cleanly protect against developer errors. That would complicate the interaction quite a bit.

Alex

On Saturday, May 7, 2016, Donald Merand notifications@github.com wrote:

Hi,

I was having a ton of problems getting an existing record to update, and then I found this line in lib/airtable/records.rb:

Airtable will complain if we pass an 'id' as part of the request body.

def fields_for_update; fields.except(:id); end

It turns out that Airtable will complain if you've got any calculated fields in the table, and it won't update :/

What I've done to fix this in my code is a monkeypatch like this:

module Airtable class Record def fields_for_update fields.except(:id, :FormulaField, :LookupField) end endend

... but I wonder if there's a more elegant way to do this?

The most elegant way to fix it would be if Airtable didn't FAIL when you try to update a calculated field (or the ID), but merely sent along some kind of warning. I'll send this idea along to them as well.

Thanks! -Donald

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Airtable/airtable-ruby/issues/8

Sent from Gmail Mobile on my iPhone

[syrnick]

yeah, the record could keep track of changed fields and then the update method on table could PATCH only changed fields.

[syrnick]

This is not a complete solution to computed fields, but I added update_record_fields method to table (on master)

[dmerand]

While a "complete" solution would be aesthetically pure, I can say that my needs are met perfectly by the update_record_fields method that you added. Thanks so much! I knocked out about 10 lines of very ugly code thanks to that method. 👍

[sirupsen]

I am not a big fan of having two paths into updating fields. Why not always use update_record_fields, instead of putting the decision of PATCH vs PUT on the user?

I just ran into this issue an hour ago, and didn't realize this method existed for example :)

[dsomel21]

I know this is 3 years old, but does this Gem support filterByFormular like Python's does?

It's kimpossible to update a record in my scenario, because there's absolutely no chance that I will ever have the ID of the record I am trying to update.