Would there ever be a case where we would have to limit the allowed db types of a mathesar type on the client? #935
-
The column endpoint currently returns a property However on the frontend, we do not allow the user to directly choose the database type. Instead, we display mathesar types and identify the database type based on the configurations entered by the user. Would there be a case where the specified configuration might lead to the selection of a database type which is not an allowed target? For eg., On the frontend however, based on our UX, we display a configuration pane: The user is free to choose whatever configuration here, leading to the selected db type being ' Is this scenario possible? Additional questions:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
If something isn't listed by A scenario that could theoretically happen would be where only some subset of the Mathesar type is available as a target for a given type. I can't see any that makes logical sense with our current types, but it's feasible. For a contrived example, suppose have both emails and URLs under some "address" type in the future, and I'm coming from a URI. I can't cast any valid URI to an email, but I can cast some valid URIs to URLs. As for sending the I'm not fiercely opposed to changing this behavior, however, it's a mild preference. |
Beta Was this translation helpful? Give feedback.
If something isn't listed by
valid_target_types
, and the front end is funneling users into casting to that type, that's a bug. We cannot cast a column to any DB type not listed invalid_target_types
, as this lists every target type for which a casting function is implemented. Thus, the scenario should not be possible, and if it occurs, we should submit a bug and fix it.A scenario that could theoretically happen would be where only some subset of the Mathesar type is available as a target for a given type. I can't see any that makes logical sense with our current types, but it's feasible. For a contrived example, suppose have both emails and URLs under some "address" type in the future, a…