Skip to content

Entries from June 2010.

SQL Error: 17006, SQLState: null Invalid column name in Hibernate

Recently I've got the following error during SQL named query execution:

SQL Error: 17006, SQLState: null Invalid column name

In order to track the problem down I enabled SQL logging and collected SQL query issued, then run it under SQL monitor and ... it was working without error! I was surprised.

In order to debug what's going on I enabled detailed logging in Hibernate. What was happened then?

[INFO] could not read column value from result set: entityKey215_0_; Invalid column name

This message showed me that the problem was not related to generated SQL query but to column names expected by Hibernate. Generated recordset didn't has entityKey215_0_ column. I added:

entityKey AS {list.entityKey}

to named SQL query and error dissapeared.

This error is not-very-obvious kind of error because Oracle hides column / table names in error messages returned. Why? I don't get this cryptic error messages idea. In order to track an error under Oracle I had to enable verbose logging (error message standalone din't give anything useful). Much simpler database MySQL has better error reporting than "fat" Oracle.

ConfigurationException: XML-22101: (Fatal Error) DOMSource node as this type not supported

When you setup your project with commons-configuration library plugged in sometimes you can get very misleading error:

ConfigurationException: XML-22101: (Fatal Error) DOMSource node as this type not supported

This error may be caused by missing XML library bindings. In order to fix that error you have to configure properly some service providers (point JVM to correct XML parsing/transformation implementations).

How to do that? You have to create the following directory structure somewhere under classpath:

  • META-INF
  • META-INF/services
  • META-INF/services/interface_name_files

Then inside "services" directory place filenames named after interfaces and filled with full class name of an implementation, for example (Xerces + Xalan plugged in):

  • src/META-INF/services/javax.xml.parsers.DocumentBuilderFactory
    • org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
  • src/META-INF/services/javax.xml.parsers.SAXParserFactory
    • org.apache.xerces.jaxp.SAXParserFactoryImpl
  • src/META-INF/services/javax.xml.transform.TransformerFactory
    • org.apache.xalan.processor.TransformerFactoryImpl

After this change proper XML implementation should be used (if the jar is present on classpatch of course).

Coloured GIT output

Coloured git output on console is a very helpful feature. It was enabled by default on git interface cogito. I liked it, but had to switch to raw git few years ago (cogito is deprecated now).

Fortunately current version of GIT supports that nice feature. It can be enabled with few settings in ~/.gitconfig file:

[diff]
color = true

[pager]
color = true

[status]
color = true

Additionally pager used (less in my case) should support ANSI colors (~/.bash_profile):

export LESS="-R"

And now diffs are rendered using colors that improve readability (anyone who doesn't review changesets before commit? ;-) ). Now diffs look much better on a X terminal:

Subversion: How To Revert Single Commit

Let's say you tracked someone broke HEAD of trunk and you want to reverse that single commit from main branch. Subversion makes very handy syntax for reverse merges:

svn merge -c -19203 https://REPO_URL

In example above you do reverse merge of 19203 revision (note "-" sign before revision number). After that merge:

  • Inspect if workspace compiles without errors
  • If it's OK: commit local changeset
  • Notify 19203 committer about the change

In order to fix broken commit original author should do the opposite:

svn merge -c 19203 https://REPO_URL

(note there's no "-" before revision number). Then:

  • Correct changeset and test if workspace is not broken
  • If it's OK: commit local changeset (it will be nice to show original revision number in a comment)

flaker.pl nie działa / 504 Gateway Time-out

Flaker to polski serwis mikroblogowy wzorowany na Twitterze. Od kilku dni obserwuję okresową (kilka godzin) niedostępność serwisu. Pojawia się komunikat:

504 Gateway Time-out nginx/0.7.64

Oto wynik monitora realizowanego przez site-uptime.net:

Jak widać serwis boryka się z problemem wydajności podobnie jak kilka miesięcy temu Twitter. Czyżby znowu "popularność zaskoczyła drogowców" ;-) ?

Aktualizacja (2010-06-13). Sytuacja nie wygląda najlepiej. Od tygodnia ciągłe pady i uptime 82%: