You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I love Postico's subquery popups for foreign keys in content views, but it would be FANTASTIC if it could go one step further and allow aliasing of how that column is presented in column view; eg, if, as is common, the key is on an integer or uuid, to let you alias that column's presentation as a different column from the referenced table (italicized or somehow otherwise graphically adjusted to reflect that it's not the true value of the column).
Obviously this is non-trivial since you're effectively doing a join for every content view but would be a huge readability & entry time-saver, especially for heavily-normalized schema.
While you can achieve similar results by setting up views in the DB itself, there are many advantages to not creating permanent schema in the DB purely for presentation/utility reasons, and then having to limit or otherwise scope access for what's a convenience for one user.
Even better would be if this was configurable by way of a bi-directional data handler function, to allow other aliasing/presentation step transformations. Extensibility could then allow other things like, for instance, configuring a column that stores image urls to actually show the image :)
The text was updated successfully, but these errors were encountered:
I love Postico's subquery popups for foreign keys in content views, but it would be FANTASTIC if it could go one step further and allow aliasing of how that column is presented in column view; eg, if, as is common, the key is on an integer or uuid, to let you alias that column's presentation as a different column from the referenced table (italicized or somehow otherwise graphically adjusted to reflect that it's not the true value of the column).
Obviously this is non-trivial since you're effectively doing a join for every content view but would be a huge readability & entry time-saver, especially for heavily-normalized schema.
While you can achieve similar results by setting up views in the DB itself, there are many advantages to not creating permanent schema in the DB purely for presentation/utility reasons, and then having to limit or otherwise scope access for what's a convenience for one user.
Even better would be if this was configurable by way of a bi-directional data handler function, to allow other aliasing/presentation step transformations. Extensibility could then allow other things like, for instance, configuring a column that stores image urls to actually show the image :)
The text was updated successfully, but these errors were encountered: