pradeep
pradeep

Reputation: 155

Using Source Code Control in Oracle SQL Developer

I am new to Oracle , so i want to do Source Code Control in Oracle, so there is a option supply in Oracle SQL Developer

1.Is this Better solution to do Version Controlling to Oracle

2.Can i use PL/SQL

Upvotes: 1

Views: 4089

Answers (1)

Prahalad Deshpande
Prahalad Deshpande

Reputation: 4767

Firstly, your question talks about two un-related concepts - using source control in SQL Developer and the other about PL/SQL. Hence here is a response that will hopefully disambiguate everything for you:

  • Oracle SQL Developer does provide a way to integrate with source control. Refer this link for instructions. It talks about Subversion, howver the same must be applicable to any other source control repository like Perforce or Clearcase.
  • Whether this is a better solution to doing version control to Oracle - there is no definitive Yes/No for this; however the approach is definitely recommended (why else would they provide it in the first place? :) ). Keeping your code editor integrated with version control will save the pain associated with manually checking out every file that you are editing. More importantly, it helps when you move/rename files or add new files. You definitely do not want to write an awesome package and then figure out that the build fails simply because you forgot to add dependent files/ delete some obsolete files from the version control manually. Hence this is the preferred way to go - however the choice rests with you.
  • Can you use PL/SQL - frankly there is no relation whatsoever between PL/SQL and source control - PL/SQL is simply a programming language for the Oracle database platform (just like you could use Java/C++/Python to do the same task with the correct bindings and drivers). I guess, the confusion would be more about - PL/SQL procedures and functions reside within the database as DB objects, so how can source control them?. Well, in this case the answer is :
    • Develop your PL/SQL source code procedures in separate files and keep them stored on the disk with your source code tree.
    • Invoke these files from a command line utility such as SQL*Plus or a custom installation program to have the stored procedures and
      functions created within the database.

The approach has the advantage that you can develop and test your scripts independent of the database instance - you can clone the existing production database into a test database, create the original stored procs and database objects and then verify any changes or defect fixes to these objects without impacting production. Also, since you are checking in these files using source control you also have access to the revision history to observe how the scripts changed over time.

I hope this long answer gives you an insight on how to achieve your objective.

Upvotes: 6

Related Questions