fabioberger/airtable-go

Golang client library for the Airtable API

airtable-go's Issues

Record values in multi-page List Request are overwritten

If you are experiencing issues where records have some fields with incorrect values it likely because of a bug in ListRecords when process requests with multiple pages. Basically the tmpRecords list is not fully cleared when making multiple requests.

There are several fixes. You can simply use this forked branch if you are looking for something quick:

https://github.com/makeitraina/airtable-go

Update Required for API Key Validation to Accommodate New Airtable API Key Formats

Hello,

I'm reaching out to address a compatibility issue with the airtable-go library in relation to the latest changes in Airtable's API key format. Airtable has updated their API keys to a new format, which includes a longer length and the use of additional characters such as "." (dot). This change impacts the airtable-go library's ability to validate API keys using the current implementation found in client.go.

Issue Description:
The library currently validates API keys with a fixed length of 17 characters and expects them to start with a specific prefix ("key"). This validation is performed by the IsValidAPIKey function in the utils package. However, with Airtable's recent update to their API key format, this validation logic no longer accommodates the new key specifications, potentially leading to valid API keys being incorrectly flagged as invalid.

func isValidAirtableID(id, expectedPrefix string) bool {
    regex := regexp.MustCompile("[a-zA-Z0-9]{17}")
    return len(id) == 17 && strings.HasPrefix(id, expectedPrefix) && regex.Match([]byte(id))
}

Suggested Actions:

1. Update Validation Logic: Revise the isValidAirtableID function (and by extension, IsValidAPIKey and IsValidBaseID) to support the new API key format. This may involve adjusting the length check and expanding the character set to include "." (dot) among other characters now allowed in Airtable API keys.
2. Flexible Length Check: Given that API key formats can change, consider making the length check more flexible or removing it altogether, focusing instead on the presence of a valid prefix and ensuring the key consists only of allowed characters.
3. Enhance Documentation: Update the library's documentation to reflect these changes and provide guidance on the new API key format expectations for users of the airtable-go library.

Impact of Issue:
Without these adjustments, users of the airtable-go library who had to migrate to or are using the new Airtable API keys may encounter errors or be unable to use the library to interact with Airtable, hindering the library's applicability and usefulness.

We greatly appreciate the work you've put into developing and maintaining the airtable-go library. Addressing this issue will not only enhance its functionality but also ensure its compatibility with Airtable's evolving platform.

Thank you for considering this request. I'm looking forward to your thoughts on this matter and am happy to contribute to testing or further discussions if helpful.

Best regards
Pascal Rossi

Seeing re-use of elements for ListRecords

If I pass a []Row, where Row is:

type Row struct {
	AirtableID string `json:"id,omitempty"`
	Fields     map[string]interface{} `json:"fields"`
}

I end up having data cross the row boundary. If I switch it to an []interface{} or remove the optimization of it only creating tempRecordsHolder once, I get the correct behavior.

I've read the json.Unmarshal doc and agree it sounds like it shouldn't be re-using any values, but it looks like it is.

Proposal: allow HTTP transport (roundtripper) to be parameterized

First off, thanks for writing this API and open-sourcing it.

I was wondering if it makes sense to allow the transport of the HTTP client used by theimplementation to be parameterized.

This allows for:

• automatic rate limiting by client. The RoundTripper implementation could automatically delay requests if more than 'm' concurrent requests are happening in the last 'n' seconds.
• removal of API methods that exist only to allow the client to be stubbed. A custom RoundTripper can do whatever the heck it wants under the covers as long as it implements RoundTrip() correctly. IMO, this covers the testing use-case in a more idiomatic way than having to expose custom methods in the public interface used only for testing.

Let me know if this makes sense and I'll be happy to send a PR.