Support for generating changelogs

[sunsear]

Hi Datical / Nathan,

We are looking at this plugin in order to use for automating our Teradata Database creation. The plugin doesn't include this according to earlier issues I found about an error Database 'information_schema' does not exist.

I see you are working on making this plugin work again with Liquibase 4.0. That leads me to believe it is at least a current plugin. Are there plans to include this changelog creation for Teradata? It seems like a sizeable job if I look at the code in the snapshots package. We are looking at this in order to use Liquibase. I would be able to contribute a few days of development time, but probably not more than that. Can we make something work in that amount of time, or is adding a new database a monster project?

Look forward to hearing from you,

Martin

┆Issue is synchronized with this Jira Bug by Unito

[r2-lf]

Hi, Martin!

I don't think it's a huge challenge. We certainly have examples of generateChangeLog in other extensions. Maybe that would be helpful. @nvoxland is going to look for his favorite and get that to you.

Another thing that might be helpful is the automated Travis builds on PR's: https://travis-ci.com/github/liquibase/liquibase-teradata. Can you access that?

Thanks!

Robert

[nvoxland]

Yes, the snapshot work can be a sizable effort. But, it depends on the database a bit too. The main liquibase code tries to be as cross-database as possible, but the metadata queries tend to be some of the least standarized things databases do.

We're working on an improved, standard integration test system that makes it easier to automatically find where the standard code doesn't work for your particular database, but in the mean time it's basically creating creating objects in your database and then calling "liquibase snapshot" or "liquibase generateChangeLog" to see what gets picked up correctly and what does not.

For examples, you can see the Vertica extension (https://github.com/liquibase/liquibase-vertica/tree/master/src/main/java/liquibase/ext/vertica/snapshot) and Hana extensions (https://github.com/liquibase/liquibase-hana/tree/master/src/main/java/liquibase/ext/hana/snapshot) for what they've been doing.

The final thing to remember with snapshots/metadata is that it is usually easy to hit the main things people want, but then there is really no end to how deep the path goes down. Making sure you can snapshot simple tables, columns, indexes, etc. on your database is usually pretty straightforward and covers most of what people want. But, then you have things like primary keys that are backed by specific indexes, or inherited tables, or whatever that your datatabase can support but isn't in the snapshot support yet.

[sunsear]

Hi Nathan, Datical, Have been working on a really simple version of this functionality that does not involve Liquibase, but writes out scripts in a sql version. I then put the scripts in the proper order (so sorted based on dependencies) In a changelog so they can be applied to the database through Liquibase. Making the scripts database independent is of course the way of Liquibase, but will involve a lot of trickery as you mentioned. Would it be valuable to have a version of the plugin that creates changelogs with sql scripts? Would that fit in the model even? The reason I ask is that teradata is really good about keeping the sql scripts around, you can simply type the show XYZ statement and you get a sql script that is the original script that was used to create the object. It even includes the original formatting and comments. I realize this method might not fit Liquibase very well, but it is the simplest way to do this. Look forward to hearing from you, Martin Op do 21 mei 2020 om 20:36 schreef Nathan Voxland <notifications@github.com>

Yes, the snapshot work can be a sizable effort. But, it depends on the database a bit too. The main liquibase code tries to be as cross-database as possible, but the metadata queries tend to be some of the least standarized things databases do. We're working on an improved, standard integration test system that makes it easier to automatically find where the standard code doesn't work for your particular database, but in the mean time it's basically creating creating objects in your database and then calling "liquibase snapshot" or "liquibase generateChangeLog" to see what gets picked up correctly and what does not. For examples, you can see the Vertica extension ( https://github.com/liquibase/liquibase-vertica/tree/master/src/main/java/liquibase/ext/vertica/snapshot) and Hana extensions ( https://github.com/liquibase/liquibase-hana/tree/master/src/main/java/liquibase/ext/hana/snapshot) for what they've been doing. The final thing to remember with snapshots/metadata is that it is usually easy to hit the main things people want, but then there is really no end to how deep the path goes down. Making sure you can snapshot simple tables, columns, indexes, etc. on your database is usually pretty straightforward and covers most of what people want. But, then you have things like primary keys that are backed by specific indexes, or inherited tables, or whatever that your datatabase can support but isn't in the snapshot support yet. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVMNMVOBGU47XIAIC4BZWDRSVYCZANCNFSM4MYYPEZQ> .

-- Martin van Dijken M +31 (0)6 26 144 223 E martin@van-dijken.eu http://www.linkedin.com/in/sunsear

[r2-lf]

Martin, the sql and sqlFile attributes should work for you. That's absolutely OK to include sql that is specific to your database platform. Does that work for you?

[sunsear]

Hey Robert, Thanks for reply! Yeah, I am using Liquibase to apply the sql files now. I was inquiring whether it would be valuable to the Liquibase project if the teradata plugin starts outputting that type of file on a generateChangelog. I can adapt the code I have now to a Liquibase structure probably. Martin Op vr 29 mei 2020 om 15:24 schreef Robert Reeves <notifications@github.com>

Martin, the sql and sqlFile attributes should work for you. That's absolutely OK to include sql that is specific to your database platform. Does that work for you? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVMNMVXZZELKJDE5ECRBQLRT6ZR3ANCNFSM4MYYPEZQ> .

-- Martin van Dijken M +31 (0)6 26 144 223 E martin@van-dijken.eu http://www.linkedin.com/in/sunsear