Feat query support in list attributes & list indexes endpoint - #5885

Why do we disallow select queries?

Select queries are not supported due to the limitation of no "key" in the metadata table, which is being used to validate select queries. Also, @TorstenDittmann said most of the keys are not optional so it's not worth it.
https://github.com/utopia-php/database/blob/a9f706034a12c7c87e6fd38eca69587fd3def0e0/src/Database/Database.php#L4509

What's the error if they're enabled? I think the key attribute should be there since it's in the collections config here:

Select queries might not particularly useful for these resources but I would suggest we allow them if easy enough, so we can remove this code and keep the controller complexity to a minimum

Okay, we cannot really use that because validate selections uses the property on line 245 above you have shared.
In this case, we need a property 'key' just like '$id'.
There's a property 'key' in the metadata table for all collections and databases but not for the ones that are created when a project is created.

Also, one more suggestion, for validating select queries, why don't we use $id instead of 'key' because seems to be they are similar? Then we can support select queries

I think if we use $id instead of $key in validating select queries then we can maybe use that because $id exists in all rows of metadata attributes and indexes

We can try get the key and fallback to $id if it's not found, we're doing this a few other places I think

Made the changes. But sadly list attributes endpoint will have to be much more complex for adding select queries support, we need to have type attribute for validating the response model for Attributes list.

If select query does not include type support, we will have to add type in select query and then remove type property from output.

discussed two options with @christyjacob4, either we use validator to not support select queries or we support select queries but we add type in select query when it doesn't include it.

We decided to keep endpont consistent with select queries, we need to add type in select queries.

Do we need the type for the response models or just to check if it's a relationship here?

This logic adds relationship attributes to each attribute object as the options key gets filtered out from Attribute Relationship Type as defined in the model.
I have moved this logic in the filter function of the Relationship Model so we can avoid this from controller logic.

If we left it in the controller, would we be able to remove the type attribute after fetching from the database but before we call $response->dynamic? It would be much cleaner that way as opposed to calling $response->output then $response->static after filtering

This section of the code is distinct from the $type attribute. Its purpose is to transition from the options key, which contains relationship data, to the appropriate keys that the models necessitate.

In terms of output and static, it is not feasible to eliminate the type attribute before the output method executes. As much as I dislike doing it, we must include the type property in the select query because the output method demands it.