A new topic, 'June 25, 2009 Meetup Followup/Transcript', has been made on a
board you are watching.
You can see it at
http://liquibase.org/forum/index.php?topic=63.new#new
The text of the topic is shown below:
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 <stop> 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
Unsubscribe to new topics from this board by clicking here:
http://liquibase.org/forum/index.php?action=notifyboard;board=1.0
Regards,
The LiquiBase Community Forum Team.
------------------------------------------------------------------------------
_______________________________________________
Liquibase-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/liquibase-user
