tag:blogger.com,1999:blog-10846234.post114244734428505086..comments2023-06-22T09:51:55.639+01:00Comments on BOBABLOG: Agile software development and Salesforce: UK-OUG and runningRob Bailliehttp://www.blogger.com/profile/06513796097645814224noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-10846234.post-1144160051378754522006-04-04T15:14:00.000+01:002006-04-04T15:14:00.000+01:00Cheers for the feedback!Cheers for the feedback!Rob Bailliehttps://www.blogger.com/profile/06513796097645814224noreply@blogger.comtag:blogger.com,1999:blog-10846234.post-1144158234748329632006-04-04T14:43:00.000+01:002006-04-04T14:43:00.000+01:00This is a very very good article, must read for al...This is a very very good article, must read for all DBA'sAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-10846234.post-1144158103925832932006-04-04T14:41:00.000+01:002006-04-04T14:41:00.000+01:00This is a very very good article, must read for al...This is a very very good article, must read for all the Database Developers, DBA's...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10846234.post-1142947069182347362006-03-21T13:17:00.000+00:002006-03-21T13:17:00.000+00:00Damn it!Don't you just hate it when people spot yo...Damn it!<BR/><BR/>Don't you just hate it when people spot your flaws ;-)<BR/><BR/>The simplest solution (in terms of process anyway) is to say that your patch scripts can't rely on views.<BR/>By virtue of the design stated, you simply can't rely on the state of a given view. You may even drop the views that do exist at the start of the upgrade to make sure that this assumption is never ignored.<BR/><BR/>But I'm guessing that's not the answer you're looking for...<BR/><BR/>Alternatively, you could create the views that you need as part of the patch itself. That view would be the version of the view at the time of the patch creation, and so would be accurate for that patch.<BR/><BR/>There is problem though, in that you now limit the position in your build at which that patch can run... this might have implications when you're moving between branch versions, or suchlike.<BR/><BR/>Finally, you could state that because of the situation you state, you cannot regard a view as being a non-transitory object. That is, views must be installed in patches, not at the end of the build.<BR/><BR/>The major problem I see with this is that this simply opens the doors to packages / procedures and suchlike. Basically, if you rely on a view in a patch, why would you not rely on a procedure? If you rely on a procedure then how do you make sure it's the right version...<BR/><BR/><BR/>So, our angle is that we don't ever access views in our patches. Our patches can only rely on the state of the tables due to the fact that only tables are ever upgraded during the patch runs. We've found that it doesn't really cause us any problems (in fact it's caused us absolutely non that I know of).<BR/><BR/>However, the problem may need to be addressed in line of one of the other above suggestions if your system uses triggers...<BR/><BR/>Ours, thankfully, does not.Rob Bailliehttps://www.blogger.com/profile/06513796097645814224noreply@blogger.comtag:blogger.com,1999:blog-10846234.post-1142930254815382332006-03-21T08:37:00.000+00:002006-03-21T08:37:00.000+00:00I've always loved your articles about your develop...I've always loved your articles about your development process and it has been one of the examples which I'm using in setting up our own development process.<BR/><BR/>We have 25 developers and quite a complex database (4 application schemas, 540 tables and some 3500 PL/SQL objects). I'm struggling to get the patch runner in working order.<BR/><BR/>You say you have two phases:<BR/>1) Run all patches that should run once and only once<BR/>2) Re-install all PL/SQL, views and other stuff you can safely recreate<BR/><BR/>And you say you can checkout any version from version control and install it on a system.<BR/><BR/>But how do you handle the following scenario:<BR/>- your system is at revision 100<BR/>- at revision 120 a view definition changed<BR/>- at revision 140 a patch script was created that relies on the view from rev. 120<BR/>- when you checkout revision 130 first and install it on the system it upgrades the view. If you then checkout revision 150 it will run thee patchscript from 140 ok.<BR/>- But what if you have a system running at rev. 100 and checkout rev. 150 and try to install. The patchscripts will run first but it relies on the view being present in the database.<BR/><BR/>How do you handle this?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10846234.post-1142801849382878542006-03-19T20:57:00.000+00:002006-03-19T20:57:00.000+00:00RobI definitely plan a longer response on my blog,...Rob<BR/><BR/>I definitely plan a longer response on my blog, but I think this is just a fantastic article. <BR/><BR/>true story word verification starts rtfm...Niallhttps://www.blogger.com/profile/07109750882834293686noreply@blogger.com