This post originated from an RSS feed registered with Java Buzz by Marc Logemann. Original Post: the kodo refactoring desaster Feed Title: Logemann Blog Feed URL: http://www.logemann.org/blojsom/blog/default/?flavor=rss2 Feed Description: Marc's thoughts on Java and more Latest Java Buzz Posts Latest Java Buzz Posts by Marc Logemann Latest Posts From Logemann Blog

What a weekend. After upgrading the version of our product at a customer we ran into a complete desaster in the first business day. We did major package refactoring in our app and this also involved all domain classes which are persistence capable classes in JDO speak. We are using kodo's internal sequencing mechanism for primary key generation. Now after deployment, we forgot to update the kodo sequence table called "jdo_sequences". The results was that kodo created new records for each domain class in this table because the primary key of this table is the package name and the class name. Of course all package names were changed in our refactoring. So every class started with 1 again and you can imagine what the database told us quite frequently. To me its a mystery why the package names must be in there. Of course i know its the obvious way to get a unique identifier, but how many people use the same domain class names more than once? I think nobody.

Then i searched for a flag to tell kodo that it should only use the class name. But ClassDBSequenceFactory doesnt support this in kodo 3.4.0. I spotted it in 4.0 but since upgrading Kodo is harder than inventing a spaceship that works without fuel, i will have to stay at the current status quo. Of course i could derive my own Sequencing class from the one i mentioned but i have other problems at this point. So to summarize, having foo.bar.Client as identifier in a sequence table is nice as long as you dont refactor packages. When you do, i am quite sure you will forget to update that table and from then .... "good luck".