supabase
Don't change ID when renaming/moving objects
Feature Request
Is your feature request related to a problem? Please describe.
I have a table with a foreign key that references the id column of the storage.objects table. But every time I rename an object (which results in a move) this link gets broken.
Describe the solution you'd like
Instead of deleting the old object in the database and inserting a new one, the existing object should be updated.
Hi @joeldomke, This is an interesting scenario, conceptually objects are immutable. This is also the case in S3. In S3 you cannot rename an object, you'll instead need to copy the object and assign a new name then delete the old one.
I'm wondering if in your case you might want to have the granular control and issue both commands on your end, so that you can update your link before the old object is deleted.
Do you think that might work for you?
The rename method does simply that in a single operation.
First of all sorry, I should have created a feature request in the supabase discussions section. That would have gotten more visibility and more opinions/insights from the community.
I think your suggestion would work if I renamed the images inside of my application. But since I'm currently working on a prototype I planned to use the storage file browser in supabase studio for now. But, whenever I rename/move something in the file browser I lose all my references.
Now that I know about the move behavior I just don't move anything, since I am working with a limited amount of files anyways.
For a more complex version with file renaming within the application, I would do the following:
- Have an image table that has a reference to
storage.objects. - Every time an object gets renamed I updated that reference in my
imagestable. - Then, every table that needs to reference an image can reference my
imagestable.
In order to update the id in my images table, I would need the ID of the object that was created during the move. It would be useful if the move method returned the ID just like the upload method does.
We have the same issue; since the storage schema does not have any metadata fields for users to use, we've ended up needing a relation table for objects just to store an object's related info.
When using rename/move, this ID is broken, and in the case of using cascading, worse, it erases the data.
The more I've used the storage, the more Im convinced the Storage API needs to retain the same object ID and not change it for move/rename operations. Even if under the hood this is using S3, the API should abstract those details from the user and give a permanent reference to the "same" file from the supabase side. If the current id comes from S3, you could keep it as well in teh table un a new field or under the current metadata object, although that as well I think is just a dump of the S3 file metadata so merging that could pollute its integrity, I would store it in a new column called "s3_key_id" or something.