I'm curious to find out how people manage their packages in their applications.
For example, in our development instance, an application developer may want a change to a stored procedure. However, changing the stored procedure will break the existing Java code until the DAO layer is updated to accommodate for the changes.
My typical practice has been to put the new procedure implementation into a "DEV" package. The developer can then change his reference to this package, do his testing and then when we're ready, we can replace the procedure in the "production" package, delete it from DEV and the developer changes his reference back to the production package.
However, I'm finding it doesn't work as swimmingly as I'd like. First, if there's a bunch of Java code which depends on the DEV package, then I'm in the same situation as if were editing the production package directly - if I break the package, I'll break a bunch of code.
Second, people get busy and we don't get around to moving the package into production as soon we should. Then we have two versions of the stored procedure floating around and it gets difficult to remember what has been moved into production and what hasn't.
The goal is to keep the developers working. Yes, it's a development server, but we don't want to be breaking code unexpectedly.
Can anyone suggest methodologies that have worked for them to address this issue?
If each developer has their own schema in the database and there are public synonyms for all objects in the shared schema and all the Java code uses non-qualified object names, then a local copy of the package in a particular developer's schema will have precedence over the shared version. So developer A can take the current version of the package, install it in his or her local schema, make whatever changes are desired to the package, and make whatever Java changes are necessary all within their own development environment (I'm assuming that developers have their own local app server). When both sets of changes are sufficiently stable that they can be checked in to the shared development environment, both the PL/SQL package and the Java changes can be built out to the shared development environment (the shared development app server and the real schema in the development database). The developer can then drop their local copy of the package.
That approach works reasonably well so long as the developers are checking the PL/SQL out of source control to start their changes rather than assuming that whatever local copy they have in their schema is current-- if developers keep old, local versions of code around in their local schema, they may end up with difficult to debug issues where their PL/SQL and Java versions are out of sync. You can resolve that problem by automating processes that, for example, drop packages from developer schemas if they haven't been modified in a reasonable period of time and if those packages aren't checked out by the developer in source control or by building scripts that let a developer automate the refresh of their schema as part of the build process.
The Java/DAO layer should only be affected if the procedure specification changes (ie number, name etc of parameters). Mitigation strategies for this are
Add new parameters with DEFAULT values for parameters so that they don't need to be passed.
Don't change the order of parameters if they cat called positionally [eg pkg.proc_a (1,2,3)], or rename them if called by name [eg pkg.proc_b (p_1 => 1, p_2 => 2)]
Use packages for procedures and functions so you can overload them
create or replace pkg is
proc (p1 in varchar2);
proc (p1 in varchar2, p2 in number);
end;
With overloading you can have multiple procedures with the same name in a package just with different numbers and/or datatypes of the parameters
11gR2 has introduced Editioning to solve this problem. It allows multiple versions of packages and the application code choose which 'edition' (version) of the code it wants to see - the default 'base' edition or a development version.
However I suspect upgrading the database version isn't a practical solution.
Related
I have an understanding that it might be the DBA's job to push the changes, much like a refresh, but without the DML (Data Manipulation).
Any comments/suggestions will be great!
There is no simple answer for this, but essentially the task of deploying code is similar for any computer language, with the main differences for the database component being
We can't drop and rebuild tables because we need to keep their contents.
Our code compiles in the database, so there are no binaries to deploy.
The first rule for PL/SQL development is that you should always, always work from source-controlled files, for example the code for mypackage would be in a source file named mypackage.pck (or whatever file extension works best with your chosen IDE, as long as it's not .sql). Don't edit database source code directly except for trivial testing when you don't care about keeping the changes.
Some sites only ever do incremental deployments, while others use a full teardown and rebuild from a release branch for major releases, which takes a bit more thought but is ultimately cleaner. Then deployment consists of running the scripts, recompiling the schema and perhaps running some tests and checks to ensure it has worked. You'll need a branching strategy, perhaps some kind of 'run everything in this folder' script, and ideally some tools such as Team City or Jenkins to automate as much as possible, though I don't think there is as much out there ready-made for PL/SQL as there is for more mainstream languages such as Java.
The deployment process is usually performed by an application support team as it does not require any DBA privileges unless you are creating schemas or roles etc, although some sites may organise support roles differently.
Yes. Partially it will involve DBA. But, as the developer, you probably need to provide the entire DDL script by exporting (probably in a file) to the DBA to deploy.
Check 'Importing and exporting SQL scripts' part of this link for exporting db scripts: https://docs.oracle.com/cd/B25329_01/doc/appdev.102/b25309/sql_rep.htm#BABBHEHA
I mistakenly deleted an ODI package from my project which is very large in size. Is there a way to recreate the same package if I have a previously exported scenario for the same project?
Unfortunately there isn't any way to directly generate a deleted package from a scenario which you can see as a compiled version of the package.
Here are a couple of things to check to see if you can retrieve some information :
When promoting from one environment to another, it's recommended to export the base object along with the scenario. That way you keep track of what was the code behind that scenario (black box). Bonus points if it's all versioned in a version control system (VCS).
Starting with ODI 12.2.1, VCS can be directly integrated within ODI to version your code and create release archives. If that's the case you can restore a deleted object
Before 12.2.1 it was possible to use the internal versioning system of ODI that would store the objects in the Master Repository. You can restore it from the top menu.
If nothing of that is setup, you can still open the scenario export in any file editor and manually go through it to retrieve the logic. It's just an XML files that describes the different steps of your package. That would help you to rebuild it manually.
If you end up doing that last bullet point, now is probably a good time to improve your existing procedures and setup one of the three backup/versioning solutions mentioned above so it doesn't happen in the future.
I have a Visual Studio 2010 database project and I'd like to do a partial deployment, i.e. of specified objects. Is this possible? The only options I can see are to either do a full deployment or stop after generating the script.
For example, I'm changing many tables and stored procs but not everything is 100% finished and I'd like to push out a specific stored procedure to my test database, including its permissions, etc.
I read a little bit about SQL Server Data Tools, which apparently supports this, but I'm not clear on whether I'd have to migrate my database project to use that instead (would also need the ok from team lead), or if it's simply a plugin that would allow extra functionality.
Check out Schema Comparisons. They allow you to select the objects you want to deploy. They are available without SQL Server Data Tools.
A "partial deployment" is actually a little dangerous. Consider that you will have just built your database project, your entire database project, complete with the table changes, and it has built with no errors or warnings (right?). Now you want to deploy just your stored procedure, into a database that does not have the table changes.
Your stored procedure got no errors or warnings in the context of all the changes. Are you sure it will get no errors or warnings without those changes?
You should consider a source control solution to this problem. Save a copy of your stored procedure, revert to a version of the code that matches the database you'll be deploying to, then make your stored procedure changes to that. When you deploy, you will be checking to see if the stored procedure makes sense in the context of the database you'll be deploying into.
I need somehow compare local version of pl sql package with the one that is stored in database. Are there any "easy" way to do it?
Currently I download package from database, save it in some file and perform diff using some diff tool. That is a bit cumbersome, so I would like to have such feature in ide (pl sql developer is preferable).
Typically developers use versioning software to check differences, maintain version history, and help coordinate team development of code. PL/SQL code should be no different. There's many ways to handle code releases, the following is just what I've seen done, not necessarily the "best" way.
In the Oracle environments I've seen, CVS or SVN is used. Most approaches involve checking out latest code from repository, editing (tagging/branching), and checking in. When code is tested (development instance) and release is ready, the DBAs either grab the release scripts from repository and apply, or one individual is tasked with handing over the correct release scripts to DBAs (more common from my experience). Note that the database here is typically a user acceptance instance that mirrors the production instance. If app testing passes, the code is promoted to production.
If you want to sync directly between the database and your IDE, the one option I've seen is Toad Team Coding. Toad is not free, and this option will require additional objects installed on the database (metadata/tracking tables, etc). A good overview is found here, and good setup article is found here.
Team coding is very cool, but I would only install on a development environment. How you promote the code from there through your system is up to you.
It's fairly easy to automate the procedure you described with a sqlplus command file. Select from all_source, spool it to a file. Invoke the diff command as "host diff ..." or "!diff ..." within the command file. The -b and -B options to diff will ignore whitespace and blank lines respectively.
I'm working in a multi-developer environment in Oracle with a large package. We have a DEV => TST => PRD promotion pattern. Currently, all package edits are made directly in TOAD and then compiled into the DEV package.
We run into two problems:
Concurrent changes need to be promoted on different schedules. For instance, developer A makes a change that needs to be promoted tomorrow while developer B is concurrently working on a change that won't be promoted for another two weeks. When it comes promotion time, we find ourselves manually commenting out stuff that isn't being promoted yet and then uncommenting it afterwards...yuck!!!
If two developers are making changes at the same exact time and one of them compiles, it wipes out the other developer's changes. There isn't a nice merge; instead the latest compile wins.
What strategies would you recommend to get around this? We are using TFS for our source-control but haven't yet utilized this with our Oracle packages.
P.S. I've seen this posting, but it doesn't fully answer my question.
The key is to adopt a practice of only deploying code from the source control system. I'm not familiar with TSF, but it must implement the concepts of branches, tags, etc. The question of what to deploy then falls out of the build and release tagging in the source control system.
Additional tips (for Oracle):
it works best if you split the package spec and body into different files that use a consistent file pattern for each (e.g. ".pks" for package spec, and ".pkb" for package body). If you use an automated build process that can process file patterns then you can build all of the specs and then the bodies. This also minimizes object invalidations if you are only deploying a package body.
put the time in to configure an automated build process that is driven from a release or build state of your source control system. If you have even a moderate number of db code objects it will pay to be able to build the code into a reference system and compare it to your qa or production system.
See my answer about Tools to work with stored procedures in Oracle, in a team (which I have just retagged).
Bottom line : don't modify procedures directly with TOAD. Store the source as files, that you will store in source control, modify then execute.
Plus, I would highly recommend that each developer works on its own copy of the database (use Oracle Express, which is free). You can do that if you store all the scripts to create the database in source control. More insight can be found here.
To avoid 2 developers working on the same package at the same time:
1) Use your version control system as the source of the package code. To work on a package, the developer must first check out the package from version control; nobody else can check the package out until this developer checks it back in.
2) Don't work directly on the package code in Toad or any other IDE. You have no clue whether the code you are working on there is correct or has been modified by one or more other developers. Work on the code in the script you have checked out from version control, and run that into the database to compile the package. My preference is to use a nice text editor (TextPad) and SQL Plus, but you can do this in Toad too.
3) When you have finished, check the script back into version control. Do not copy and paste code out of the database into your script (see point 2 again).
The downside (if it is one) of this controlled approach is that only one developer at a time can work on a package. This shouldn't be a major problem as long as:
You keep packages down to a reasonable size (in terms of WHAT they do, not how many lines of code or number of procedures in them). Don't have one big package that holds all the code.
Developers are encouraged to check out code only when ready to work on it, and to check it back in as soon as they have finished making and testing their changes.
We use Oracle Developer Tools for Visual Studio.NET...plugs right into TFS
we do it with a Dev database for every stream, and labels for the different streams.
Our Oracle licensing gives us unlimited dev/test instances, but we are an ISV, you may have a different licensing option
You can use the Oracle developer tools for VS or you can use sql developer. SQL developer integrates with Subversion and CVS and you can download it for free. See here: http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html
We use Toad for Oracle with the TFS MSSCCI provider against TFS 2008. We use a Custom Tool that pulls database checkins from source control and packages them for release.
To my knowledge Oracle Developer Tools for Visual Studio.Net doesn't have any real source control integration with TFS or otherwise.
You might consider Toad Extensions for Visual Studio though it's not cheap, maybe $4k I think.
Another option is the Oracle Change Management Pack but believe it requires the Enterprise edition of Oracle which is much more pricey.
You may be interested in Gitora www.gitora.com. It helps managing Oracle database objects with Git.
This article about collaborative development with the Oracle database can also be helpful: http://blog.gitora.com/plsql-how-to-develop-two-features-simultaneously-but-deploy-only-one/
Full disclosure: I am the developer and author of the article.