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
This is more of a question to explore than an actual issue.
Working with the framework on a project, the ids which are integers at the source, were appended a prefix which transformed them to varchars. The only "issue" is when you're debugging and want to get to the source's id, it's quicker to copy the whole value instead of removing the prefix. Also, I think it might be better practice to stick to the source's natural field type instead of forcing it to varchars.
This is more of a question to explore than an actual issue.
Working with the framework on a project, the ids which are integers at the source, were appended a prefix which transformed them to varchars. The only "issue" is when you're debugging and want to get to the source's id, it's quicker to copy the whole value instead of removing the prefix. Also, I think it might be better practice to stick to the source's natural field type instead of forcing it to varchars.
My preference for this project has been
source_table_natural_key
Example:
┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: