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
When migrating, CODE_ONLY artifacts are ignored because there is no DB asset to manage.
However, the whole point is to allow developers to build arbitrary complex artifacts that Tilda cannot do, eg, complex CTE/Union based views and so on. This happens rarely, and by design, we want to keep Tilda simple (The T in Tilda means Transparent, so we need that simplicity).
But Tilda could still help with validation during migration, i.e., check that the Tilda definition DOES match the underlying custom-coded DB artifact (table or view).
We propose to add a feature to implement that validation so that the Tilda definition of the Object or View matches at least a subset of the columns (with types and other details) present in the database.
The text was updated successfully, but these errors were encountered:
When migrating, CODE_ONLY artifacts are ignored because there is no DB asset to manage.
However, the whole point is to allow developers to build arbitrary complex artifacts that Tilda cannot do, eg, complex CTE/Union based views and so on. This happens rarely, and by design, we want to keep Tilda simple (The T in Tilda means Transparent, so we need that simplicity).
But Tilda could still help with validation during migration, i.e., check that the Tilda definition DOES match the underlying custom-coded DB artifact (table or view).
We propose to add a feature to implement that validation so that the Tilda definition of the Object or View matches at least a subset of the columns (with types and other details) present in the database.
The text was updated successfully, but these errors were encountered: