Loosen Table Restrictions
Opened this issue · 1 comments
Is this a NEW feature request or an UPDATE feature request?
[UPDATE]
Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
Currently there is a pretty rigid structure for how the homepage table is rendered. There is a max of 7 or 8 columns, which may be rearranged, but they are not dynamic automatically. For example, if I query for verbatimDate
, decimalLongitude
and habitat
only, the table still defaults to the standard 6 default headers (even though the information will be empty for those).
Maybe I can just use a regex for advanced select queries: /(?:SELECT )([A-Za-z-_*]+(?:, ?\w+)*)/i
Additionally, id
is still enforced in queries. So the above query would ACTUALLY be querying 4 columns since the id
gets injected in. This was originally intended to prevent operations which require the id from being done without the id present. I think this should be reworked so that these operations are simply disabled without the id, rather than forcibly altering the query from the user to include it.
Additional context
This would involve two major features:
- automatic column configuration
- removing the enforcement of id, and adding in many checks to disable functionalities when id is missing where necessary
Implementing the first is more of a QOL update, since the user would have less configuration to worry about when narrowing queries. Implementing the latter has more functional benefits, removing the id injection would open up the select query options in the homepage, such as distinct actually working and a less restrictive overall table usage.
This should be handled in the mikro branch