I’ve been using a query which utilizes both DBA_FREE_SPACE and DBA_DATA_FILES system views, but it often tends to be slow. Recently I’d come across another system view which is lightning fast – DBA_TABLESPACE_USAGE_METRICS. Continue reading →
There are many different Git workflows and it is very likely that the one you are using relies heavily on Git’s outstanding branch management.
If you have many branches, some of which may be release branches, you surely don’t want anyone to merge a feature branch branched off of develop into it (which already probably is dozens of commits ahead).
This is extremely important in teams formed by many developers – if one of them makes the mistake, and the others start branching off of the release branch, all of them will have the “corrupted” version of the branch, and then it takes a lot of effort to undo all of the damage.
Git doesn’t provide a way to deal with this problem out of the box – a pre hook is required, or some third-party software.
If you are using GitBlit, however, writing a pre hook which guards a branch from being flooded with commits from a branch which should never be merged into it, is quite easy.
I’ve been recently writing a pre hook for Git to check if any of the committed files violate any policies. I’m using GitBlit and it’s using JGit (an implementation of Git written in Java). You can’t use normal Git pre hooks with GitBlit, but you can write them in Groovy.
GitBlit’s author created an API to ease the use of JGit in pre hooks. I needed to detect if a file was renamed, and have access to its old path, as well as the new one.
Unfortunately, the documentation of PathChangeModel (which corresponds to a file in a commit) doesn’t state how to obtain the old path – the renamed file object’s path property contains the new path.
Luckily, it’s open source! I’ve had a look into the source code of the mentioned class and it turned out that, in case of a rename, the old path is stored in the name property. Take a look at the following example. Continue reading →
Git is an extremely powerful Distributed Version Control System. And by saying that, I’m getting straight to business.
The “Distributed” part means that there is no central repository on which all developers are working. On the contrary – every developer has a clone of some publicly available (whether on the internet, or at work) repository. The “central” becomes just a place to share your work and pull others’ changes.
This is one of the features that make working with Git very handy. It is also one that people often don’t realize. Continue reading →
Back in the days, when I was just beginning working as an Oracle developer, I used to view Oracle Database Server as such a great piece of software to the extent where I wouldn’t even consider that a problem which I’ve just encountered wasn’t my fault, but Oracle’s bug!
Why am I bringing this up, you might ask? Well, a few weeks ago I’ve stumbled upon a weird bug in Oracle. I was using Oracle 184.108.40.206.0. Take a look at the below example: Continue reading →
Getting Referential Constraints using DBMS_METADATA
The GET_DDL function of the DBMS_METADATA package, supplied by Oracle, is a nice tool to extract the DDLs of database objects. This quick guide will show you how to deal with the problem of exporting referential constraints – what problem, I hear you saying? Continue reading →