Thanks to everyone who made it to the meetup today. I think it went well and hopefully it was useful to you.
What feedback do you have on how it went? Chat app work well for you? Discussion flow good or bad? Other thoughts? I’m thinking that the chat app had too much of a delay typing and sending and we should switch to a real IRC server, or something else next time. It worked well if it wasn’t for the typing delay.
Is there any additional comments on topics discussed?
The transcript is too large for the 20k character limit, so I will post the first half here, and the second half in a follow-up post.
(11:56:49) Nathan_Voxland: Hello everyone (11:57:02) sduncan: hello (11:57:04) tvial: Hi! (11:57:07) kkrikor: Hello (11:57:13) upul: Hi (11:57:21) taranenko: morning (11:57:39) Nathan_Voxland: Good to see you, It will be interesting to see how well this works :) (11:57:44) otatop: testing 1.. 2... 3... (11:58:23) Nathan_Voxland: We'll wait a couple mintutes to really get started (11:58:51) Nathan_Voxland: A couple things to think about: afterwords I would like some feedback on what went well, what didn't with this so we can improve them in the future (11:59:11) Nathan_Voxland: Related to chat technology, discussion management, etc. (11:59:27) tvial: Will there be a transcript of the conversation ? (I won't attend the whole thing :() (11:59:56) Nathan_Voxland: I am hoping to get a trascript. It may just be copy/paste, but I thinki ti will work (12:00:18) tvial: great! (12:00:37) Nathan_Voxland: How many of you have actually look at/worked with the liquibase code before, vs. simply using it? (12:00:46) Nathan_Voxland: (as a guide for talking) (12:01:18) kkrikor: Looked at the code very briefly (12:01:36) tvial: only used it so far, and not in a real project yet (12:02:02) otatop: We are going to be using liquibase in my current project but haven't done much with it yet. (12:02:24) taranenko: I just spending 7-8 full days to working with codebase. Basically to make JUnit tests working and some new feature implementing (12:02:39) kkrikor: We do use it in our project, including maven and spring integrations (12:03:09) upul: I am a user (12:03:50) taranenko: additionally i'm actively using liquibase in 4 different projects (12:04:09) Nathan_Voxland: Great, thanks for letting me know. Lets start it off with an open question of "is there anything in particular you would like to cover?" (12:04:53) tvial: here's a hard one ;) I've heard that Visual Studio's DB designer and Rail's db:migrate tool can compare pretty much with LiquiBase wrt DB refactoring, and are more mature. I don't know those tools; what is your opinion on them? (12:05:28) kkrikor: rolling back changeSets using their ids (12:06:07) taranenko: i'm strongly need to sync table's data (12:06:07) otatop: I'm really interested in what's the current priorities, any really big tips, and finally I'm still really hoping for some enhancments for hibernate integration (there's a feature request out there for it) (12:06:25) kkrikor: that would specifically be useful when the changeSet is breaking something (12:06:45) Nathan_Voxland: I'll keep queuing up questions, so even if we are on something else, keep asking (12:07:09) Nathan_Voxland: I'll start with the first one... (12:07:50) samawon: is it possible to generate full database scripts without connecting to the database? thinking of using it inside the build system (12:08:14) Nathan_Voxland: tvial: A hard one, but luckly I'm very opinionated on the subject :) I haven't used visual studio's db designer to really know what it does, but from what I understand it is a diff based system. (12:08:49) Nathan_Voxland: It compares your local database with the "standard" database to figure out what changes need to be made. (12:08:54) kkrikor: Define strategies on how to write changeSets for multiple dbs (12:09:32) Nathan_Voxland: I think in general doing a database diff is not a safe way to track chages. See http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html. (12:10:12) tvial: I agree with that. Also, merging two SQL scripts by hand is not a trivial task (12:10:18) Nathan_Voxland: The trouble comes down to just because you can compare two points in time, you loose important information if you don't understand what happened in between. (12:11:50) tvial: well you've got commit comments from source control, but they can be very coarse or simply missing (12:11:55) Nathan_Voxland: rail's db:migrate I also think is inherently broken (12:11:55) otatop: Agreed. My dream would would be liquibase comparing the current liquibase xml with the hibernate annotations and appending to the liquibase xml what additional changes are necessary. That would rid us of needing a real db to gen the liquibase file. (12:13:01) Nathan_Voxland: My rails blog post: http://blog.liquibase.org/2007/06/the-problem-with-rails-active-migrations.html (12:13:31) Nathan_Voxland: The trouble with the hibernate diff is that you still can get wrong changeSets. (12:14:20) Nathan_Voxland: With databases, it is just as important HOW you get from one state to the next compared to THAT you get to the final state. (12:15:09) Nathan_Voxland: The example I use is renaming a column from "firstname" to "first_name", a diff program would see "there is no longer a firstname column and we are missing the 'first_name' column. drop firstname, add first_name' (12:15:27) Nathan_Voxland: it gets you to where you need to be, but you loose your valuable data in the process (12:15:54) tvial: that's a very good example & argument (12:16:11) Nathan_Voxland: That is the main reason why hbm2ddl with hibernate isn't safe to use directly either. It is going to do the diff and you could loose data. (12:16:43) Nathan_Voxland: The goal of the diff support we have is to help out creating changesets, but should not replace them. (12:17:51) Nathan_Voxland: comparing the hibernate mapping with your database and appending to the changelog is a good example, because 90% of the time it is right and so easy to do, but you need to actually read what is being added and change it as nessisary before applying it. (12:18:29) otatop: As long as the tool can figure out the final state from the liquibase file I think it'd be good to have a generate from hibernate that compared the xml and the hibernate annotations. If the tool generates a drop "first_name" and then an add "firstname" I'm ok with that, as long as I can modify it afterwords and on subsequent runs it can figure out that I've already handled the rename to "firstname" myself. (12:18:41) taranenko: another technical question: is there a plans to change building from ant to maven? (12:18:48) Nathan_Voxland: Comparing hibernate.xml to liquibase.xml is non-trivial when you allow SQL and end-user extensions, however, so I doubt we will ever get to that point, unfortuantely otatop (12:18:52) markfarnsworth: can liqua base produce a sql script in the target dialect from a change set? (this would be helpful to hand off to a DBA for formal review) (12:19:07) tvial: I have to go now, thanks a lot for your time and your answers. I'll be looking forward to the transcript :) (12:19:12) otatop: You can't 100% rely on it without reviewing, but it can save a significant amount of leg work to gen then review, vs. just doing it all on your own. I definately understand that it's quite the challange though. (12:19:46) tvial: just another question if time permits -- a list of best practices: when to start from a fresh changelog, how to tie it with the releases of your application, ... (12:20:35) Nathan_Voxland: Ok tvial, thanks for coming. A bit more on the rails question: They use a more simple version number to control ordering and what is to be applied and that breaks down quickly with muiltiple devs and branches. That is why we have the separate id/author/filename tracking and why we apply changesets by changelog order, not id order. (12:21:51) Nathan_Voxland: Next question: kkrikor: rolling back changeSets using their ids (12:22:21) Nathan_Voxland: You are asking for the ability to be able to pass in the id/author of a changeset to roll just it back? (12:22:39) Nathan_Voxland: My concern with that is that what happened after that changeset can make rolling back an earlier one impossible. (12:23:15) Nathan_Voxland: for example, changelog1 adds table "person", changelog2 renames "person"->"users", you now cannot rollback "person" by dropping the table because it no longer exists as "person". (12:23:53) Nathan_Voxland: There is a rollbackCount command that lets you undo the last N changes to help troubleshoot why things are breaking. (12:24:37) kkrikor: ok (12:24:45) markfarnsworth: I assum LQB tracks everything in tracking tables but does it also inspect the state of the schema? (12:24:46) Nathan_Voxland: I think there is an updateCount command as well to let you step through changesets. I suually use those during development to watch what is going on. (12:25:11) markfarnsworth: i.e. does LQB assume that others are not changing the schema? (12:25:41) markfarnsworth: i had been thinking of walking the schema and calculate an MD5 to be sure that no others had mondified the schema (12:25:47) Nathan_Voxland: In a large existing changeset that is failing on a far past changeset, I will usually add the tag temporarily to get it to a particular point and step through it then, or add precondtions to handle new, unexpected cases. (12:25:48) markfarnsworth: but hard to do that in DB neutral way (12:26:12) kkrikor: We run into this issue because we primarily deploy on postgres and then every now and then deploy on oracle (12:26:43) kkrikor: i think it is our approach that is the wrong one (12:26:55) Nathan_Voxland: markfarnsorth: yes, we don't track the state of the schema, just the applied changes. If something is done to the database outside of liquibase, we would not know it at all. (12:27:19) Nathan_Voxland: kkrinkor: I have ran into the same problem with supporting multiple database (12:27:37) Nathan_Voxland: multi-database support is built in for that reason, however. (12:28:14) Nathan_Voxland: I think the trick is to have all your supported database updated by liquibase on your build server. That way you will catch any non-compliant changes right away. (12:29:09) markfarnsworth: so basically make sure the user assigned to LQB is the only user with DDL priv (12:29:15) kkrikor: yes that is they way to go (12:29:29) Nathan_Voxland: yes, that is best. Not always possible, but best :) (12:30:06) Nathan_Voxland: You may be able to do with with using the the generateChangeLog command to make a dump of the schema and doing an md5sum on it. (12:30:27) Nathan_Voxland: WOuld make a good addition to the liquibase extension portal :) (12:31:07) kkrikor: thanks (12:31:14) kkrikor: for the response (12:31:28) Nathan_Voxland: Question: taranenko: i'm strongly need to sync table's data: Unfortunately I think it is a difficult problem to solve in general, so nothing we hve plans to implement in the near future. (12:31:58) taranenko: sad (12:32:15) kkrikor: Another question let's say you have your liquibase scripts creating postgres and oracle schemas and then you get a requirement that you need to support mysql what is the strategy to get that done ? (12:33:15) Nathan_Voxland: you could probably get something going with the data export capabilities, but it will not be overly robust. I would guess that any data sync support that performs well and is powerful enough is probably going to have to be heavily database dependent. (12:34:16) Nathan_Voxland: I recently had a case where we added MSSQL support to a product that had previouly just been mysql. What we ended up dong was using generateChangeLog on our fully-updated mysql database and restarted our changelog from there. (12:35:19) Nathan_Voxland: 1/2 hour in. I do plan to post the transcript to the user forum, and we can continue any threads even after time is up.
CONTINUED ON NEXT MESSAGE