The following are the guidelines everyone should use to contribute to utPLSQL.
Changes are welcome from all members of the Community.
- Create a GitHub Account.
- Fork the utPLSQL Repository and setup your local Repository. See how to Fork article
- Each of the steps below are detailed in Get started with development section.
- Clone your Fork to your local machine.
- Configure "upstream" remote to the utPLSQL repository.
- For each change you want to make:
- Make sure your forked repository is up to date with upstream before you start coding. See syncing your local repository with upstream utPLSQL repository.
- Create a new branch for your change. We use
feature/feature_nameorbugfix/fixed_issue_nameto identify branch types. - Make your change in your new branch.
- Make sure your change is covered with unit tests.
- Verify code compiles and all existing and new unit tests pass.
- The quickest way to have a Pull Request not approved, is to submit code that does not compile or pass tests.
- Commit change to your local repository.
- Push change to your remote repository.
- Submit a Pull Request into develop branch.
- Note: local and remote branches can be deleted after pull request has been merged.
- We use snake case for all identifiers in PLSQL code. This separates keywords in names with underscores.
execute_test - All code is lower case.
- Prefixes:
- Arguments to procedures and functions will start with
a_, an Example would be procedureis_valid(a_owner_name varchar2) - Object types and packages will start with
ut_ - Local variables
l_ - Global variables
g_ - Global Constants start with
gc_ - Types in packages, objects start with
t_ - Nested Tables start with
tt_
- Arguments to procedures and functions will start with
- varchar2 lengths are set in characters not bytes
Your local environment can be of any flavor (Unix/Linux/Windows/Mac). At minimum, you need to have Oracle database 19c accessible for the project and SYS account access to install and develop utPLSQL.
We use four different database accounts (users) for development process.
ut3- holds latest released version of utPLSQL. This schema holds the testing framework used for self-testing of utPLSQL development.ut3_develop- holds the version of utPLSQL of your current branch. This is the schema you will be working on.ut3_tester- holds unit test packages for development of utPLSQL.ut3_user- used for testing accessibility to schema names with special characters.ut3_tester_helper- elevated privileges user, used for creating and dropping objects in other schemas during test run.
To get started with development, follow the below steps.
If you're using Windows, run the shell scripts using GIT bash - Windows-based bash command line.
Caution: If you are using jetBrains DataGrip, don't use the integrated console to run the shell scripts (not even with GIT bash configured). It might disconnect from oracle randomly during script-run.
# clone your fork of utPLSQL
git clone https://github.com/your account/utPLSQL.git utPLSQL
cd utPLSQL
# add main project repo as upstream
git remote add upstream https://github.com/utPLSQL/utPLSQL.git
# fetch all remote repositories
git fetch --allCopy the environment variables template development/template.env.sh to development/env.sh
cp development/template.env.sh development/env.sh
chmod u+w development/env.shYou might have to adjust the following lines in development/env.sh:
export SQLCLI=sql # For sqlcl client
#export SQLCLI=sqlplus # For sqlplus client
export CONNECTION_STR=127.0.0.1:1521/xe # Adjust the connect string
export ORACLE_PWD=oracle # Adjust your local SYS passwordThe below script is fetching latest release version from utPLSQL repository. Latest release version is used for self-testing.
./development/refresh_sources.sh./development/install.shYou now have the following:
- sources from
developbranch of your fork of utPLSQL repository inutPLSQL/ut3_latest_releasedirectory - sources from
mainbranch of utPLSQL/utPLSQL repository inutPLSQL/ut3_latest_releasedirectory - binaries of
utplsql-cliinutPLSQL/utPLSQL-clidirectory - database users created
- your current branch of utPLSQL deployed into
ut3schema - utPLSQL released version deployed to
ut3_latest_release
At any time, if you need to refresh your database, the below scripts might be helpful.
development/cleanup.shdevelopment/refresh_ut3.shWhenever a new version of utPLSQL or a new version of utPLSQL-cli is available, use development/refresh_sources.sh to refresh files in your local project folders.
utPLSQL v3 unit tests are located in the test directory
Before you push any changes and create a pull request to the utPLSQL project repository, make sure that all the tests are executing successfully in your local environment.
Every new functionality needs to be documented by unit tests that cover happy-path scenarios as well as edge-cases and exception paths.
Important notice: We do our best to keep utPLSQL covered with unit tests. Lack of sufficient unit testing is a perfect reason for PR to be rejected.
To run a full suite of unit tests execute:
. ./development/env.sh
./test/install_and_run_tests.shYou can review the results of tests as well as see information about code coverage in ./coverage.html file.
Below diagram gives a high-level overview of utPLSQL v3 modules and their dependencies.
Dependencies to ut_util are not shown as most of modules are depending on it.
We are using a combination of private and publicly available docker images to test utPLSQL. The following versions of Oracle Database are used for testing:
- 19c-Standard Edition (private image)
- 21-free
- 23-free
The Free varsions are publicly available and you can set up your local development environment to use one of from here
These [private image]((https://github.com/utPLSQL/docker-scripts) is a slimmed version of the official Oracle database dockerfiles . Due to licensing restrictions, the image cannot be public.
You can build your own and use it locally, or push to a private docker repository. The build steps are simple if you already have some experience using Docker. You can find detailed information about how to build your own image with a running database in: example of creating an image with pre-built DB
If you are new to Docker, you can start by reading the Getting Started With Docker docs.
If you are new to GIT here are some links to help you with understanding how it works.
