In December Meghan and I visited my sister and her husband (Katie and Patrick Portner). Patrick has a friend that owns a Ferrari 360 Modena that he was lucky enough to borrow for the weekend. Patrick and I drove it on a nearby expressway. My limit was around 130 mph. The car was amazing though, it was hugging the road and zipping nicely no matter what speed I was going. 
Currently tables created in MySQL default to MyISam. This is unacceptable for us at Openmrs. You can set a property in your my.cnf file called “default-storage-engine”, but I needed a solution that didn’t involve implementers having to modify their system config files.
I changed the jdbc connection url string to set a session property that sets InnoDB as the default engine:
jdbc:mysql://localhost:3306/databasename?autoReconnect=true&sessionVariables=storage_engine=InnoDB
NOTE! Requires mysql jdbc connecter version 3.1.18 or greater. See http://dev.mysql.com/doc/refman/5.0/en/connector-j.html for documentation and then http://dev.mysql.com/downloads/connector/j/ to download.
The error message I was getting before upgrading the mysql jdbc connector was:
java.sql.SQLException: Server connection failure during transaction. Due to underlying exception: ‘java.sql.SQLException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1′.
** BEGIN NESTED EXCEPTION **
java.sql.SQLException
MESSAGE: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1STACKTRACE:
java.sql.SQLException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2921)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1570)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2972)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2902)
at com.mysql.jdbc.Statement.executeUpdate(Statement.java:929)
at com.mysql.jdbc.Connection.setSessionVariables(Connection.java:5077)
at com.mysql.jdbc.Connection.initializePropsFromServer(Connection.java:3680)
at com.mysql.jdbc.Connection.createNewIO(Connection.java:2684)
at com.mysql.jdbc.Connection.<init>(Connection.java:1474)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:264)
at com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:135)
at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:182)
at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:171)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137)
at com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014)
at com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32)
at com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810)
at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
For some reason Java doesn’t like to obey http forwards if the protocol is changing. It has been this way for a while: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4620571. So when I was trying to load https://modules.openmrs.org that had an apache redirectMatch to http://modules.openmrs.org, I would get the html for the 301 redirect instead of the source of http://modules.openmrs.org.
I was lucky that I have control over the server and could change the http/https to a simply proxy instead of redirecting. If I didn’t, I would have had to catch the protocol change and refetch the new url.
It took me a while to find an answer for this because these keywords didn’t give many results on google: URLConnection HttpURLConnection openConnection() connect() getInputStream() Apache redirectMatch 301 302.
For some reason Ubuntu regressed a bit in the multiple monitor department between Hardy and Intrepid. Before upgrading I was able to dock my Thinkpad and easily switch screens using fn-f7 to switch resolutions just like in the Windows World. After upgrading function f7 usually didn’t work so I had to start just shutting down the computer (or at least control-alt-backspacing to restart x) if I switched between external monitor and the laptop monitor.
I recently discovered “grandr” and its capabilities. It worked more often than Ubuntu’s Screen Resolution program…but I had to use my mouse and see the screen to do so. This meant that I had to the lcd before I did a stand by or took the laptop off the dock.
I then discovered the command line “xrandr” program. It let me set up some scripts to switch the screen resolution.
lcd.sh:
/usr/bin/xrandr –screen LVDS –auto
vga.sh:
/usr/bin/xrandr –screen “VGA-0″ –auto
/bin/sleep 4
/usr/bin/xrandr –screen LVDS –output LVDS –off
Jaunty is supposed to have improved monitor support, so I’m looking forward to its release.
When trying to merge from our trunk to a branch I was getting these errors:
svn: File ‘/tmp/svnkitmerge42139.tmp/.diff.192.tmp’ has inconsistent newlines
svn: File ‘/tmp/svnkitmerge42139.tmp/.diff.192.tmp’ has inconsistent newlines
and
svn: File ‘/tmp/tmp’ has inconsistent newlines svn: Inconsistent line ending style
svn: Error reading spooled REPORT request responsesvn: Generic IO error
svn: Generic IO error
Here are the steps I did to get around this and still merge from trunk to the branch:
Note: If you have changes on another checked out copy, an “svn update” won’t work on that one. You will have to apply a patch of the changes to the freshly checked out/merged copy.