In other words, this blog will be discontinued… Stay tuned on our new software development blog on techblog.41concepts.com (english) or our business startup blog on bizblog.41concepts.dk (danish).

Background
The rails framework developers, being of the opinion that complexity is best located in the code and not in the database, does not advocate using stored procedures as a abstraction layer between the database and the application. Instead dynamic sql generated from RoR code is used. For typical application databases, this approach works very well indeed.

Examples where the traditional rails way of database thinking sometimes fails short are projects involving multiple (some non-rails) applications, projects involving legacy databases, projects where the lifetime of the data will exceed the life of the application code and finally specialized projects where a non-trivial amount of handcrafted sql code is needed (typically for reporting, statistical analysis, data mining, scheduled database maintenance tasks and other sql that are not related to the O-R mapping handled by ActiveRecord).

For the latter cases, some usage of stored procedures together with the rest of the traditional database arsenal (foreign key constrains (*), Triggers, views etc) can be useful at times… all depending on the specific project needs of cause.

(*) Actually, from experience, I highly recommend always defining foreign key constrains (even in “application” databases). This is sadly NOT the current way of thinking among rails developers and consequently rails support is lacking - but that is another story.

Defining stored procedures in MySql

Since version 5 of the MySql database you can define a simple no-arg stored procedure like this:

DELIMITER $$

CREATE PROCEDURE mydb.my_stored_procedure()
BEGIN
– INSERT CODE HERE
END $$

DELIMITER ;

Notice the importance of overriding the default “;” delimiter when defining your typical stored procedure! This is different from creating stored procedure in Sql Server for instance.

Calling stored procedures from Rails:

Begin by upgradíng your standard ruby mysql driver to the native “C” driver (gem install mysql) as the standard pure-ruby mysql driver doesn’t support all the needed MySql 5 features.

From rails, our MySQL procedure can f.x. be called using execute(”CALL my_stored_procedure()“) in a migration . Unfortunately, it might not always work. If your stored procedure return multiple result sets, calling the procedure will fail unless you pass the Mysql::CLIENT_MULTI_RESULTS flag when establishing the database connection. Unfortunately, active record does not allow specifying client flags for your database connection. For workaround instructions, that involve patching the MySql Adaptor, see the wiki entry here or the outdated bug report with patch here.

Creating your stored procedures in rails migrations:

The brave adventurer may try to create a Mysql 5 stored procedures like this in a rails migration:

class CreateDatabaseObjects < ActiveRecord::Migration

def self.up
sql_directory = File.join(File.dirname(__FILE__), “sql” )

begin
f=File.open(File.join(sql_directory, “my_stored_procedure.sql”), “r”)
sql = f.readlines.join
execute(sql)
ensure
f.close unless f==nil
end
end

def self.down
execute “DROP PROCEDURE my_stored_procedure”
end

end

Unfortunately, I have found that the obvious approach above does not work with the newest stable version of ruby 1.8.6 and rails 1.2.3 on my Windows installation (meaningless error). Hacking the MySql Adaptor to include the Mysql::CLIENT_MULTI_STATEMENTS client flag does not improve the situation (which is rather strange).

However, I did succeed in creating a workaround. Not a pretty hack or a truely happy resolution but it works:

class CreateDatabaseObjects < ActiveRecord::Migration

def self.up
sql_directory = File.join(File.dirname(__FILE__), “sql” )

# Hack: Invoke database cmd tool subprocess to create our mysql stored procedure.
conf = ActiveRecord::Base.configurations[RAILS_ENV]
sql_file = File.join(sql_directory, “my_stored_procedure.sql”)
cmd_line=”mysql -h “+conf[”host”]+” -D “+conf[”database”]+ ” -u “+conf[”username”]+” -p”+conf[”password”]+” <”+sql_file
if !system(cmd_line)
raise Exception, “Error executing “+cmd_line
end

end

def self.down
execute “DROP PROCEDURE my_stored_procedure”
end

end

- The end -

Therefore, if you are a software developer here in Denmark with a strong interest in Ruby / RoR you will currently find local work possibilities lacking (*). However, I expect this situation to change in the mid/long term so developers should get prepared (e.x: start you own RoR / Ruby projects, find foreign clients or do both like me :-)).

One way that will help you get started is to join one of the new Danish RoR / Ruby user groups. The groups that I know of are:

aarhus.rb - Ruby/Rails user group situated in Århus. Meets at the start of every month at different locations hosted by members. Next meeting is 28. September 16.00-18.00, 2006 at Mjølner Informatics, Helsingforsgade 27, 8200 Århus N.. See the link for the associated google group.
Copenhagen.rb - Ruby/Rails user group for greater Copenhagen area. Meets about every 1-2 months at different locations hosted by members. Next meeting is 19. September, 17.30-?, 2006 at Kraftvaerk, Vesterbrogade 74, 4. sal, 1620 København V.. See link for details.

(* NOTE) If your (Danish) company do actually use Ruby / RoR or are interested in learning how to leverage the benefits, please let me know.

Modern Exception Handling (EH) in C++, JAVA, Ruby, Modular-3, C# and other modern programming languages is a great tool for handling errors but unfortunately it is sometimes abused by software developers that do not quite get what exceptions are really for or are just ignorant of possible implementations.

Common abuses of EH includes using exceptions as an alternative flow control mechanism (think sophisticated “goto’s” and you got the basic idea of this antipattern”)……. Don’t do that. It will only make the code harder to read. It will also make your code slower to execute since throwing exceptions are generally very expensive operations.

Another less apparent misuse of EH is usage of try-catch(-finally), or similar constructions your language may offer, inside the control flow of hotspots (such as inside time critical loops). Don’t do that, as a the try-catch-finally construction may have overhead even when you won’t expect it.

So why are throwing exceptions expensive and why may the try-catch-finally constructions (or similar) have overhead ? Well, it all depends on the language, the implementation of your VM or compiler (and sometimes on whether you use native code or not if your language allows it). Depending on your environment, just raising one exception can be from 10-100.000 times as slow as alternatively returning a simple return code from the method. And even if you don’t raise any exception, just having a try-catch-finally in your control flow can also be moderately expensive (but usually only enough to be a problem inside hotspots).

Specifically, the case of overhead of try-catch-finally constructions when no exceptions occur is difficult to get rid of by compiler & virtual-machine implementers. Few implementations on selected chip architecture got it right and have 100% overhead-free implementations but many impose a overhead just for placing try/catch/finally constructions in your control flow. Basically this is because something like a “linked list” has to be maintained internally by the compiler or VM each time the control flow enters or exits a try-catch-finally.

For much more details about various possible implementations of exception handling and the impact on performance refer to this old thesis of mine here.

In conclusion, the morale of the story is:
* Do use exception handling for error handling only (not for control flow).
* Don’t use try-catch-finally constructs inside hot-spots (i.e. loops and such) if it can be avoided. Do the try-catch at a higher level that is called less often.
* If your particular java, c++, ruby, clr … implementation of exception handling on one chip architecture yields excellent performance even when you break the above rules you are just plain lucky. Change the version, vendor or chip architecture and you luck may desert you. Therefore don’t do it

Why code generation?
I am a big believer in the DRY (Don’t Repeat Yourself) principle and believe that code generation is a great tool to help achieve it’s goal. More specifically I have found that code generation (when done right) helps me improve quality and save time & effort by reducing redundancy and drudge work (especially for statically typed languages like Java or C# that I use a lot these days when doing consulting).

Why the Jostraca code generator?
A year ago while evaluation existing code generation tools, I ended up with Jostraca, a free GPL code generation tool written by Richard Rodger.

Jostraca is a template based generator that is based on extended Java Server Pages syntax. Notably, Jostraca lets you use this syntax with multiple languages, including Java, Perl, Python, Ruby etc. The output can be of any (textual) type including new source files for the project.

The Jostraca template language is much more powerful than the language for the (in eclipse circles) well know JET generator, which I have personally found inadequate for my needs. For an example of one useful Jostraca feature, that JET does not have, check the Jostraca template extract below. It that shows how to declare a java template method called “formatThis”, that just like a macro, can be called from the normal generate method:

<%@ section declare %>
<%private void formatThis(String name) {%>
<%=name%>
<%}%>

<%@ section generate %>
<% formatThis( “foo” ); %>

For those that wonder about the implementation, the above extract gets translated to a temporary codewriter class that is executed in order to produce the actual output (similar to how JSP translates into servlets that are executed upon a http request in order to produce HTML).

Jostraca has many more advanced features. Look at the Jostraca code generator documentation for details.

What CodeGenJostraca offers for your code generation needs
CodeGenJostraca allows you to create/edit your Jostraca templates in the eclipse editor. The plugin features a fully integrated (incremental) Jostraca builder that generates output automatically when you save your template file and inserts the generated output directly into your project structure at a configurable location!

As such CodeGenJostraca allows you to use codegeneration with a seamless build process just like working with normal source files (note this is very different from most other code generators, including JET, which requires you to perform special actions or even do some programming to produce your output).

CodeGenJostraca allows you to write your templates in any language supported by Jostraca, including my favourite scripting languages Ruby and Python!

However for the current release, Java based templates have the best support regarding error handling, libraries and stability. One particular notable feature – absent for all other eclipse generator tools I have heard of - is that the Java templates can access all libraries and classes on the eclipse project path! I.e. you can have external libraries or helper classes in your project that gets called when Jostraca is generating code while eclipse builds your project (note that using this feature will make your project depend on itself for building ; a bit like self hosting compilers).

My business case or why I am releasing this project (for free)?
I work as a freelance software architect/developer and also do some development on the side. I use code generation but it is not my current focus business wise. Therefore, I am releasing this project as free GPL code… So, if other developers can use this project that is fine. If some of you can come up with improvements even better

A word about the implementation and CodeGenClipse
My ultimate aim is to offer support for multiple code generators as need arises, with Jostraca being the initial focus. I have therefore released the project as two plugins:
• CodeGenClipse : A generic Eclipse plugin that provides a basic foundation for integrating code generators in Eclipse. End users do not use this plugin in itself, but other plugins depends on it. This plugin is bundled with the plugin below.
• CodegenJostraca : An Eclipse plugin that offers integration of the Jostraca code generator into the Eclipse IDE. This plugin is targeted towards end users and the principal subject of this posting.

Notes & disclaimers
Note that this is a beta release that has been tested under Eclipse 3.1.2 and Eclipse 3.2RC5 running JDK1.5_06 under Windows XP. It requires JDK1.5! It has NOT been tested on Unix/Linux/Mac so far. It runs stable on the few PC’s I use but that is all I can assure you of right now. Note also that of the many scripting languages supported by Jostraca, only Java, Ruby and Python has been tested so far.
In addition plugin developers interested in supporting other code generators should be aware that the CodeGenClipse plugin is a bit rough right now and the API is not stable yet.

More information
See the project homepage http://codegenclipse.sourceforge.net/ or the sourceforge project site. Alternatively contact me directly (see my homepage for details).

I personally have quite some experience with ‘traditional’ web development using ASP.NET and J2EE. Having experimented with RoR myself and gone through additional training, I can now say for sure that RoR is definitely easier and more productive than these (and at the same time making it easy to get great quality and maintainability). RoR also compares very favourably against PHP according to the many PHP developers I meet during the course.

According to the guys behind the Rails Studio training course for Ruby On Rails: “Nothing says ‘I’m ready to write killer Rails apps’ better than a Rails Studio alumni button”. So here is the button I got:

In a consulting job I recently ran into an interesting case involving a webservice with several different service methods f1, f2, fn (sample names, not actual names) all taking the same string argument and all returning a string. The user would select an operation name after which my code had to call the named operation on a web service using a standard parameter. Trivial really, if one would do accept bad code like this below, but I don’t:

String operationName = …
String arg = …
Webserviceproxy webserviceproxy = …
// Warning: Badly coupled code begins here (need to update each time we add/rename/delete operations).
switch (operationName) {
case “f1″: return webserviceproxy.f1(arg); break;
case “f2″: return webserviceproxy.f2(arg); break;
}

What is really needed is a method to invoke a webservice method by name, while still using the generated .NET proxy to do the hard soap/http stuff (no time to reinvent a better wheel here).

Let’s look at an extract of the generated proxy:

(more…)