Wednesday, December 16, 2009

Fedora, sqlplus: error while loading shared libraries

My sqlplus stopped working one day with the error:

sqlplus: error while loading shared libraries: cannot open shared object file: No such file or directory

this is a classic shared object where the shared object cannot be found.

I don't know how it happened, but my sqlplus install had become detached. The solution is simple as root: search for the .so file in your file system. You can do this using your expert knowledge, or find:

find /usr -name ''

Once you have this location, stick the folder which contains this library (i.e. /usr/lib/oracle/11.2/client/lib/) in a file for linker to find:


The linker is call 'ld' and on Fedora 11 uses /etc/ld... for it's configuration files. The final step is to re-configure the dynamic linker run time bindings which is done with:


Building a self contained Jar with Maven on Netbeans

Sometimes I need to build a Jar for distribution. A typically ideal type of Jar is one which can be executed from the command line:

java -jar ./myApp.jar

I have in the past used One-Jar which works nicely for this purpose, but now I'm using Maven as standard, this should be able to do this for me. And do it without IDE dependent plugins.

Today I'm going to build a jar with Eclipse. The project which I'm building is dependent on another local Maven project, and they both are dependent on locally and repository managed Jars.

Once all the dependencies are in the Maven Classpath Container, it is a matter of editing the pom.xml file which dictates the build process.

to this I added a plugin - in the section of the node:


so now, issuing (from the command line):

mvn assembly:assembly

will create a Jar for you. I got this far with the assistance of the excellent KSB's Maven Notes.

Now, in Netbeans, you can add a Custom Goal. Right click on the project you want to build, select 'Custom->Goals...' and then in the Goal field type:


OK. Now you can select this Goal (using the same mouse navigation) and it will build you a Jar. Hopefully.

Thursday, December 10, 2009

reserved words in MVC

There is no other words to express my disappointment with object relational mapping framworks than: woeful

I have played with three MVC frameworks (Catalyst/perl, rails/ruby, grails/groovy) and by one metric, Rails is pittyful. That metric is narrow but significant (in my opinion) and is described below.

The object-relational mapping frameworks in question are:


My issue is that all these frameworks have implicit 'reserved words'. These typically throw an obscure error if you use in your Models because they collide with either framework or DB reserved words.

Let me draw up a table:

# reserved words
0 + db dependent
DB reserved words are not permitted.
0 + db dependent
DB reserved words are not permitted.
7 + db dependent
based on Reserved words in Rails blog post from 2007

So, there is an important uncertainty here: DB reserved words.

Irrespective of db reserved words, the frameworks differed on DB reserved words - so your models aren't portable across DBs. Am I alone in feeling this is a real lost opportunity for relational mapping frameworks?

I have still not seen a reason why these 'reserved words' restrictions exist
All (?) decent DBs will (I think) allow you arbetary table names with by quoting db names...
From an architecture perspective, having reserved words for something which is supposed by be abstract is just perverse.

I await the end of 'reserved words'.

UPDATE: This post is poorly researched. I discovered an additional resource in a blog post by Daniel Butler. However, my experience still points to Catalyst being an good choice of MVC framework when dealing with large legacy databases.

Sunday, December 6, 2009

postgresql search_path with ruby on rails

I studied (amongh other things) electrical engineering at Univsrity. One of the lectures said that you only need one forumal to master the subject: V=IR. However, the lecture warned, you have to know that forumla inside out.

Indeed, you could argue that V=IR is a simplification of Maxwells law, so V=IR not only covers you for EE, but a large chunk of physics (astro, plasma for example) as well.

Some times, I think MVC frameworks are similar.

Anyways... .I'm finding myself using Rails today. I've used it before with some success but didn't like the way it wanted to dominate the DB. My current thinking is that this approach is alright unless you want to integrate a legacy DB.

I'm integrating a legacy DB. It's in PostgreSQL and it uses schema namespaces. Namespaces are really worth the effort. They look great if you use PgAdminIII.

I struggled for a hour or so with my namespaces and then I discovered that I could include a search_path in ./config/database.yml. Now everything is working well again.

Saturday, December 5, 2009

discovering namespaces in postgresql

I've been working on a project with a friend. We're using PostgreSQL for our db...

I thoughtfully prepared the DB locally. I then did a complete dump of it and gave it to my chum...

However, I hadn't anticipated a few things:
  1. I didn't tell my friend the username I had used when creating the database. The PostgreSQL dump had helpfully included a bunch of 'ALTER TABLE, OWNER TO' commands. If you haven't anticipated this - and the user doesn't exist - you will end up with a bunch of problems when ingesting the dump.
    Proposed solutions:

    1. Create a user with the name recorded in the dump file before ingestion
    2. when doing a pg_dump, add the --no-owner flag.

  2.  I didn't tell my friend that I have used schema in the db. Once they had got over the first problem, they were greeted with an apprently empty database! If you don't set your search_path to add the relevant schema names, \dt will tell you 'no relations found'
    Proposed solutions:

    1. Tell my friend the names of the schema that i've used - maybe even in the form of a SET search_path=newschema,"$user",public; command.
    2. Let my friend grep the dump file for 'search_path'.
    3. Let my friend figure out the relevant names of the schema by having them do a SELECT * FROM pg_namespaces;

I think I could improve on the namespace discovery query, possibably by just suggesting that my friend does a SELECT * FROM pg_tables; which seems to reveal more useful information.

UPDATE: after some more playing around, I've discovered that I'll will save myself alot of time by editing the dump file to remove all the 'alter to' commands. One it is ingested, the resulting db requires alot of effort to manipulate all the permissions.