RE: Whats with the IJournal methods?
Jake Ginnivan
Sent from my Windows Phone
From: Žymantas Večorskis
Sent: 29/09/2015 5:37 PM
To: DbUp Discuss
Subject: Whats with the IJournal methods?
You received this message because you are subscribed to the Google Groups "DbUp Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dbup-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Darrell Tunnell
Hi there!
"how do you make comparison of physical file scripts and records in journal table by date, user?"
DbUp only cares about figuring out scripts that have been executed so it doesn't execute them again, so to date, there has been no need for those comparisons.
"How do you run scripts only those who changed?"
Short answer is you don't.. imagine a create table script is run. Then someone amends it. If DbUp ran that script again because it changed obviously the second time the create script will fail because you cant create a table twice in a db. The correct procedure as far as dbup goes is to add a new script containing your changes - a 'change script' if you will.
It's possible we may have to revisit this interface in the future for example to deal with a proposed new feature around script hash checking.. but thats not really set in stone at this point.
Perhaps you can elaborate on what you are trying to achieve with DbUp and where the IJournal is letting you down?
Jake Ginnivan
Sent from my Windows Phone
From: Žymantas Večorskis
Sent: 29/09/2015 6:46 PM
To: DbUp Discuss
Subject: Re: Whats with the IJournal methods?
Jake Ginnivan
The way I do development in DbUp is that I drop and rebuild my database whenever I need to make changes. After you deploy to a test environment or something which you do not rebuild constantly you lock that script then create a new script which you can modify over say the course of a sprint or week or whatever works in with how your team develops.
The idea is that your database migrations would have been run hundreds of times during development then in different test environments so when you go to production you have minimised risk.
I am not quite understanding the IJournal generic approach you are asking about.
There are other tools which look at the last version of the database, then the current and they will generate change scripts and such for you. DbUp is a very simple tool which simply runs scripts which have not been run before.
Does that help?
From: dbup-d...@googlegroups.com [mailto:dbup-d...@googlegroups.com]
On Behalf Of Žymantas Vecorskis
Sent: Tuesday, 29 September 2015 9:03 PM
To: DbUp Discuss <dbup-d...@googlegroups.com>
Subject: Re: Whats with the IJournal methods?
I am still exploring this nice tool, which i find very useful in couple reasons.
OK i got it. I was looking from several developer and system under development perspective , not only form one time task.
For create table example a script should handle that, you can check if object does exist in DB and then simply by doping it or altering.
During development scripts might (and they will) change, like views queries change, logic of procedures,columns being added to table etc.... And for that it would be nice to see if a particular change in db is up to date(simple comparison of file name and date executed would be enough), as for right now you can know if script was executed. And i believe that Journal was introduced here for that reason for tracking scripts.
With IJournal generic aproach would be better...
Or i am not seeing here something.