Comments on: Source Controlhttps://jonathanlewis.wordpress.com/2013/03/01/source-control/
Just another Oracle weblogTue, 03 Mar 2015 01:11:37 +0000hourly1http://wordpress.com/By: Jonathan Lewishttps://jonathanlewis.wordpress.com/2013/03/01/source-control/#comment-55096
Mon, 29 Apr 2013 13:57:45 +0000http://jonathanlewis.wordpress.com/?p=10691#comment-55096I’ve been a bit slow with the follow-up – I don’t know where the time went, but I seem to have had very little spare time lately for anything but the occasional drive-by blog post, or OTN comment – but James Murtagh, has picked the two winners and they are: joaquingonzalez and John Brady.

I’ve emailed them privately with details on how to collect their prizes.

]]>By: Jonathan Lewishttps://jonathanlewis.wordpress.com/2013/03/01/source-control/#comment-54015
Fri, 08 Mar 2013 15:52:26 +0000http://jonathanlewis.wordpress.com/?p=10691#comment-54015I’ve just updated the posting – redgate have launched ahead of schedule. When was the last time you saw that happen ?!

Some new links in the posting for information, links and a web demo with Q&A.

]]>By: John Bradyhttps://jonathanlewis.wordpress.com/2013/03/01/source-control/#comment-54014
Fri, 08 Mar 2013 15:40:21 +0000http://jonathanlewis.wordpress.com/?p=10691#comment-54014Problems with database changes? Where to start? Databases must change in place using incremental changes (metamorphosis), whereas normal application software source code can just change and be compiled into a new, next version (evolution). You cannot lose the data within a production database when deploying a new version of the application software. I’ve blogged about this problem some time ago, and how it is a different kind of challenge to normal software source code versioning. Problems I’ve encountered?

* Basic ability to produce upgrade SQL scripts containing the DDL to change the database structure. Having a uniform structure to these makes maintenance and debugging so much easier. Allowing any SQL by someone writing it themselves can make it difficult to work out precisely what kind of change is being done and why.

* Sequencing of changes – which change should happen before another. You cannot index a table until it has been created. Similar issues over moving data between tables – you must make sure it is added to the new table before deleting or dropping the old table.

* Atomic scripts – change scripts should do one and one thing only. The number of times I have had a change script do 10 or 20 different things and fail at step 13 for some reason or other. As DDL essentially auto-commits you cannot just rerun the script, because all of the first 12 steps will fail now for some reason. Or worse, do the same thing again such as inserting data into a reference table.

* Another way around this is to write all database change scripts so that they detect whether each step has already been performed and skip that step if it has been run on this database. Another way of avoiding the rerun issue. This is termed “idempotent” I believe.

* Not recording within the target database when each upgrade script was run so there is no audit trail. Knowing when each change to the database structure took place would be good. Equally, recording information about the type of change performed is useful – did it create a new table, modify an existing column, create a new index, update data in a table, insert data, delete data?

* Inability to prove that creating a database directly at the final, current version results in the same structure as creating the database at an earlier version and then applying all upgrade scripts to it. Some kind of database structure comparison tool would be good. Not only to prove that the database structure is the same whichever route of upgrade scripts you take to get there, but also to show what is different between the two databases to help you identify the issue.

* Lack of error checking or trapping with database change scripts. A blind assumption that each coded change to the database must work and that there will never be anything that could cause it to go wrong when run on a real, production database. Or the other extreme of trapping and capturing errors but then just saying “something went wrong” without providing any more details.

* No pre-requisite checks being done by the upgrade script itself, that would otherwise avoid upgrade failures when it tries to make its changes to the database. With pre-upgrade checks not only are problems flagged earlier, but no database changes have been done by the upgrade script yet, so it can definitely be run again safely after the reported problems are addressed. See earlier point on being able to re-run large, complex upgrade scripts.

I could go on, but I’ll stop there. I hope that is enough for you.

John

]]>By: joaquingonzalezhttps://jonathanlewis.wordpress.com/2013/03/01/source-control/#comment-53935
Tue, 05 Mar 2013 07:23:54 +0000http://jonathanlewis.wordpress.com/?p=10691#comment-53935It would be very useful to have a tool specific to Oracle DB to do source control. Currently we are using audit create package, audit create procedure, etc. That way we store the different changes to source in dba_audit_trail. But it’s very painful to compare changes with previous version and it’s impossible to have branches.
]]>By: Rajhttps://jonathanlewis.wordpress.com/2013/03/01/source-control/#comment-53929
Mon, 04 Mar 2013 23:16:01 +0000http://jonathanlewis.wordpress.com/?p=10691#comment-53929We are SaaS company for financial transactions for small business, due to the SLAs with multiple clients, we maintain multiple copies of database procedure codebase in different set of schemas, we are having great deal of pain in understanding what version procedure/function/package….is in for particular customer environment, we use perforce for application code, and based bunch of tables and script names, we are able to do decent job in finding which object in what version and how to get a customer from version x to version y, and if a customer is in version d, what code that can be in common to version f, so that if version f ..i can go on and on…but we need a better source control for database objects, that is easy to adopt and have little to no overhead on database development group and be able to see delta between many different objects.

If the RedGate product can answer standard version related questions and generate reports per customer environment that would be of great help.

Thank you.

]]>By: johnhttps://jonathanlewis.wordpress.com/2013/03/01/source-control/#comment-53907
Mon, 04 Mar 2013 04:39:32 +0000http://jonathanlewis.wordpress.com/?p=10691#comment-53907I don’t really need the software but if you could ask them to stop tracking me with cookies everywhere I go I would appreciate it.
]]>By: Amit Vermahttps://jonathanlewis.wordpress.com/2013/03/01/source-control/#comment-53882
Sat, 02 Mar 2013 15:59:57 +0000http://jonathanlewis.wordpress.com/?p=10691#comment-53882In production, maximum time we don’t do complete package installation which means it only part of the object change however if you use older version of SVN then complete code need to deploy which makes things mad because the thing you dont want are going in.

Second story is very difficult in one package having multiple branch then it was advisible to create separate projects but for developers its double work.