feat: return object id on object operations

[supermar1010]

What kind of change does this PR introduce?

feature

What is the current behavior?

currently is not possible to create relationships from the client side to an object because the id is never returned

What is the new behavior?

object id is returned on the following operations:

• createObject
• copyObject
• updateObject

Additional context

Reimplemented this PR. #197

One remark, when testing this locally I had problems with RLS. I couldn't insert anything because it always failed with a RLS new row violates row-level security policy for table "objects".

What a problem is, is the RLS. Because by removing the returning: 'minimal'. You need the select permission to insert a file right now.

I don't know if that's a problem?

[supermar1010]

And I can't get the test database to start. So no updated unit tests so far :/

[GaryAustin1]

What is the intent with storing the object id versus just path in your associated tables? It is true you also have to save bucket name if the bucket is not fixed for your structure and save a bit of database space. But the cost is you have to read the storage table directly to do any followup storage-api call.

The object id has no operation it can be used for directly. My fear in dealing with user issues, is that if this is implemented, it further gives users the impression they can just delete the storage.objects row and the associated s3 file data is deleted also. Which is not the case.

[supermar1010]

I definitely see your point, that might be an issue.

For me the reason why I want it is, easily ensure that the image referenced really exists and that it is uploaded by the user trying to create the current row.

So users cannot use other peoples images and also not use non existent ones. This is easier when having the id available and a fk, but could be solved just by using the name as well. So I guess your worries are bigger than the advantages this provides :)

[fenos]

This is now being implemented