Non-indexed foreign keys

Let me start my first accepting a misconception which I had till very recently. I sort of always assumed that foreign keys are always indexed. A little more digging revealed that Oracle, DB2 and even SQL server does not create an index for a foreign key automatically. So it has to be explicitly done.
We all know indexes has cost associated to it. Apart from using the storage space, it has to be maintained by the database on inserts and updates but still it is very good idea to create an index for a foreign key and especially when

• We have a use case where deletion of the parent row cascades into deletion on the child table. Otherwise it will lead to a full table scan of the child table for each parent row deletion.

• We frequently join parent and child tables. Otherwise it will have a performance impact.

So basically a little bit of a trade off as what we really want to do but in general it is always a good idea to have an index on a foreign key.

But does all this have any impact on how we do our Hibernate mappings, yes for sure. So for example if we decide to not index a foreign key, then

• Be careful while using : on-delete=”cascade” even though the database has a support for it

• Always specify lazy=”true” to prevent a join and eager fetch of the child rows.

Now what is this Git?

It is an open source version control system. So why do we care? We already have subversion. Here are few points which might get you interested.

It is a distributed version control system – which means every user has a complete copy of the whole repository locally on his/her box, I mean everything with complete history and thus the ability to track the revisions without going to a central server. It brings in the advantage of looking at a file history offline and in no time. It also brings in a side effect of having the repository backup at so many places.

Branching and merging comes in naturally – Since every check out in a way, is a sort of branching by itself, the whole process of branching and merging for Git can be compared to checkout and commit for may be subversion.

Offline and Extremely fast – Remember there is no network latency as everything happens locally, as the local copy on a box is a full-fledged repository. So no matter what we are doing, committing the changes, looking at a previous version of a file, looking at the history, performing a diff or anything else we do not need a network connection to the central server and it is damn fast.

Does need a small space – If every user has a complete repository on his/her local box, so obviously there is a concern for the size of it. Fortunately the way it is packed it is much smaller in size then may be subversion.

Not yet good support for IDEs – Not yet quite there to support most of the features from IDEs like eclipse or may be a windows explorer extension which we have for subversion. Although it does provide command line tools and graphical interfaces like git-gui

Tracking binary files – Git considers each merge of a binary file as a new file and thus do not support tracking and history for such files.

If these are not enough to arouse the interest, may be looking the projects which uses Git for their source code management might as well.

http://git.or.cz/gitwiki/GitProjects

DBUnit – Need for creating tables

While doing unit testing for my DAO’s with DBunit, I never really realized that I have to explicitly create tables in the in-memory database and having an XML for the test data or even a DTD to validate it is not enough. That was till I planned to use JDBC and not hibernate to implement the DAO’s.
While woking with Hibernate it was always so easy to just turn on the hibernate.hbm2ddl.auto to update as part of hibernate properties and that is it, hibernate takes care of creating the schema from the hbm files or the respective annotations. But with JDBC, we have to explicitly create the tables in the in-memory database otherwise executing the test case will throw NoSuchTableException.
The easiest way to do it, is to execute the following.

SimpleJdbcTestUtils.executeSqlScript(new SimpleJdbcTemplate(getDataSource()),
new ClassPathResource("CreateTables.sql"), true);

Obviously we can use the above if we are using spring framework.

Eclipse Tip : Static import help

While working with easy mock, till now I have to explicitly go and copy paste all the static imports from an earlier test case into the new one as there is no way (at least that is what I thought till now) to make eclipse help me assist with content completion without it.

Even worse is for every new method which I want to use on easy mock; I have to explicitly add a static import myself and then use it or for that matter may be first use it and then add the import.

This was till I found a feature in eclipse where I can specify my favorites for static imports.

Is there ever a valid scenario to check in commented code?

Unsure about the changes : From my experiences whenever I comment the code it is because I am not sure about my changes for the time being and I want to test them first may be with some of the already existing pieces commented out. This is just to make sure I do not have to write the same stuff back if my changes do not work.

That is Ok to do as long as we realize that commenting out code is very temporary thing and should never cross the boundary of our workspace. If it does and it goes in the version control, then in a way we are doing what version control does for us (by letting us retrieve the older versions of the code).

Two or more scenarios out of which only one is applicable at a time: Make it configurable to pick one scenario at the run time rather then commenting out the valid scenario and uncommenting the invalid ones before each run. It might sound funny as to why people would want to do it this way but believe me I have seen such occurrences and to quote the most frequent is logging.

I will just leave it there commented out till my code is reviewed: Again just make sure it is not breaking the build and check it in. For the worst scenario, version control has the old version which we can always pickup anytime so why keep the dead code around.

I just read about it in an interesting post on code deletion. The Joy of Deletion

Agile Programming Essentials

Follow YAGNI : It is very tempting to write more code then we really need. Since we are already on it lets build the whole damn thing as we are going to need it anyway and then we soon realize oh it is not just the code but it has to be a properly tested code, well designed, easily maintainable and also might change with the change in future feature requirements. With this we end up comprising the quality of the feature which we were building in the very first place. Why code when you ain’t gonna need it for the task at hand?

Let it DRY : Use and reuse code as much as possible which might be either our own code or available frameworks, tools, libraries. There are different ways of putting it avoid code duplication, DRY (do not repeat yourself). The key to enable laziness is abstraction – being modular, loose coupling, DI, separation of concerns (aspects). Reuse becomes harder with the increase in the size of the component we want to reuse so keep it short.