Good day everyone,
I'm wondering if any of you faced an issue with external views (from other databases) that happen to be rather instable and flacky, meaning they gain or lose columns throughout the day.
We try to implement Flyway in our software and in theory everything is straight forward - except for the interaction with the external views.
In this particular case we have a view A on our side which join a few other views from our end but also an external view, let's call it view B.
I'm not sure how to structure the migrations or if we should migrate them at all in Flyway. Since the external views change over time, a versioned approach is impossible because the first version of view A depends on the first version of view B which doesn't exist anymore.
This brings us to repeatables. The main concern I have with those is the amount of views we managed and the dependencies we need to tackle. Dependencies mean we need to have an order which, as far as I understood, is only guaranteed through letter-sorting. E.g. I need to manually number the names of the view-files. The next issue is that there needs to be a way recreate all dependent views should the origin view change. Again: I didn't see a way how Flyway handles this. To be honest, I think the second problem can be solved with some placeholders but for the first issue I'm kind of stuck.
What are your recommendations at this point? I'm thinking it could make most sense to not manage the views in Flyway and manage them in the code directly.
A bit information about the system and environment.
* Database: Snowflake (it's a datawarehouse)
* Codebase: Python
* SQL driver: SQLAlchemy
I hope this post meets your criteria and my question understandable. Please let me know should you need more information.
Good day everyone,
I'm wondering if any of you faced an issue with external views (from other databases) that happen to be rather instable and flacky, meaning they gain or lose columns throughout the day.
We try to implement Flyway in our software and in theory everything is straight forward - except for the interaction with the external views.
In this particular case we have a view A on our side which join a few other views from our end but also an external view, let's call it view B.
I'm not sure how to structure the migrations or if we should migrate them at all in Flyway. Since the external views change over time, a versioned approach is impossible because the first version of view A depends on the first version of view B which doesn't exist anymore.
This brings us to repeatables. The main concern I have with those is the amount of views we managed and the dependencies we need to tackle. Dependencies mean we need to have an order which, as far as I understood, is only guaranteed through letter-sorting. E.g. I need to manually number the names of the view-files. The next issue is that there needs to be a way recreate all dependent views should the origin view change. Again: I didn't see a way how Flyway handles this. To be honest, I think the second problem can be solved with some placeholders but for the first issue I'm kind of stuck.
What are your recommendations at this point? I'm thinking it could make most sense to not manage the views in Flyway and manage them in the code directly.
A bit information about the system and environment.
* Database: Snowflake (it's a datawarehouse)
* Codebase: Python
* SQL driver: SQLAlchemy
I hope this post meets your criteria and my question understandable. Please let me know should you need more information.