Accessing FileUpload[] items by index

[AlMighty-Ymir]

Hello @ignatz ,

A penny for your thoughts:

When defining a column as an array of files like:

images TEXT CHECK(jsonschema('std.FileUploads', images)) NOT NULL

The API returns an array of FileUpload[] objects. Accessing them works through:

• For single file:

`${recordApiBasePath}/${apiName}/${recordId}/file/${columnName}`

• For multiple files:

`${recordApiBasePath}/${apiName}/${recordId}/files/${columnName}/${index}`

Here the index comes from the file’s position in the array.

The problem I ran into: if I update the files array locally before persisting back to the record, the original indexes may shift, so the “correct” index for each file can get lost. That means I either need to reconstruct the array carefully, or find another way to consistently map file → URL.

Would it make sense for the API response to:

• Include the index field alongside each FileUpload, or
• Provide a way to access file URLs directly by id instead of relying on position?

Curious what you think is the cleanest approach here.

Thank you.

[ignatz]

A penny for your thoughts:

And some :) 🙏

Would it make sense for the API response to:

• Include the index field alongside each FileUpload, or
• Provide a way to access file URLs directly by id instead of relying on position?

I see your point. The first one may still have the same issue (e.g. some concurrent update), if I understand correctly. The latte seems the most robust. WDYT?

[AlMighty-Ymir]

I see your point. The first one may still have the same issue (e.g. some concurrent update), if I understand correctly. The latte seems the most robust. WDYT?

You’re absolutely correct, relying on the index will always run into issues. The id-based approach is definitely the most reliable, since it’s a unique UUID, and we could even use a safe base64 version of it for the URL. Though, I’m not sure how well this would apply when using S3 or other object stores ?

[ignatz]

I just pushed a change 3964993 that allows retrieving file contents by UUID as well.
I made it so that the same API endpoint accepts both, thinking that we might want to fade index-based access in the future (though that would be a breaking change).

The id-based approach is definitely the most reliable, since it’s a unique UUID, and we could even use a safe base64 version of it for the URL.

The UUIDs are (at least currently) text-encoded, i.e. they should be url safe (only alphanumeric + '-').

Happy to change the API. WDYT? 🙏

[ignatz]

We're having a somewhat related discussion on image file uploads on #156...

As an early heads-up, I'm wondering if it would make sense to do something more akin to PocketBase, i.e. access by a manged filename, e.g. "orig_filename_920983204.png":

• We wouldn't leak the UUID (don't think it's a problem per se).
• We'd preserve the extension, which may be valuable for some client use-cases
• having a unique filename, rather than just the original filename, would address many issues with cache invalidation for free, e.g. when using a CDN. (That's already the case with the UUIDs.)

[ignatz]

Ok, just pushed an update that removes UUID access again (sorry for the churn) in favor of unique filenames as described above: 85363c9. Hope this makes sense and works for you too.