Just improving the python script which I had been using for few years for backing up Picasa albums would not be an option, because this new tool would need a UI. The user needs first to have an overview over the albums and the disk space they consume, and then decide which one to archive.

So I decided to make a tool which would help me with it. On Saturday evening I started to code and have fun with the good old Swing, and finished it late on Sunday. And then the tool helped me to remove tens of thousands of non-starred photos which I didn’t want to have on my laptop (after backing them up) and free precious gigabytes just in few minutes.

Here it is: Picback. If you are an extensive Picasa user and photographer, I hope it can be useful for you too.

But there are few problems which I experienced:

1. The most frustrating is in fact described in the Hibernate docs. An object returned by session.load() isn’t necessarily an object of the expected class:

   Cat cat = (Cat) session.load(Cat.class, id);  // instantiate a proxy (does not hit the db)
   if (cat.isDomesticCat()) {                  // hit the db to initialize the proxy
       DomesticCat dc = (DomesticCat) cat;       // Error!
       ....
   }

2. No inheritance mapping for value objects: here is the JIRA issue that never gets fixed, and a workaround.
3. The strong suggestion in the Hibernate documentation to use a join table for every unidirectional one-to-many association (in the section 2.2.5.3.2.2. “Unidirectional”). Another suggestion is discussed here.
4. 2nd level caching should be used with caution: after deleting an object the stale version can still stay in cache which can lead to an ObjectNotFoundException. I found no other solution except disabling the 2nd level cache for the class.

${node.title}
<div class="children">
<c:forEach var="node" items="${node.children}">
	<c:set var="node" value="${node}" scope="request"/>
	<jsp:include page="node.jsp"/>
</c:forEach>
</div>

The tricky thing is that when you use jsp:include (and for recursion you have to use the dynamic inclusion), normally, you loose all the variables defined in the parent JSP. But if you redefine the variables you need in the “request” scope, then they will be visible in the included JSP too. I assumed that this very JSP is named “node.jsp” and omitted the declarations. Surprisingly, I found neither this nor any other solution on the Web, so I had to invent one.

import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
import java.util.List;
import java.util.Locale;
 
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
import org.springframework.web.servlet.LocaleResolver;
 
/**
 * A wrapper for LocaleResolver. Allows to set only one of the predefined set of locales.
 *
 * @author Ilya Boyandin
 */
public class RestrictiveLocaleResolver implements LocaleResolver {
 
	private final LocaleResolver localeResolver;
	private final Locale defaultLocale;
	private final List<Locale> supportedLocales;
 
	private RestrictiveLocaleResolver(
			LocaleResolver localeResolver, Locale defaultLocale,
			Collection<String> supportedLocales) {
 
		this.localeResolver = localeResolver;
		this.defaultLocale = defaultLocale;
 
		final List<Locale> locales = new ArrayList<Locale>();
		for (String loc : supportedLocales) {
			locales.add(new Locale(loc));
		}
		this.supportedLocales = locales;
	}
 
	public LocaleResolver getLocaleResolver() {
		return localeResolver;
	}
 
	public Locale getDefaultLocale() {
		return defaultLocale;
	}
 
	public Collection<Locale> getSupportedLocales() {
		return Collections.unmodifiableCollection(supportedLocales);
	}
 
	@Override
	public Locale resolveLocale(HttpServletRequest request) {
		final Locale resolved = localeResolver.resolveLocale(request);
		final Locale supported = findSupportedLocale(resolved);	 // this ensures that a locale with one
																 // of the predefined names will be used
		if (supported != null) {
			return supported;
		} else {
			return defaultLocale;
		}
	}
 
	@Override
	public void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale) {
		final Locale supported = findSupportedLocale(locale);	// this ensures that a locale with one
																// of the predefined names will be used
		if (supported != null) {
			localeResolver.setLocale(request, response, supported);
		} else {
			localeResolver.setLocale(request, response, defaultLocale);
		}
	}
 
	private Locale findSupportedLocale(Locale locale) {
		for (int i = 0, len = supportedLocales.size(); i < len; i++) {
			final Locale loc = supportedLocales.get(i);
			if (loc.equals(locale)) return loc;
		}
		return null;
	}
 
}

And then you must have something like this in your config file (of course, you can use any other locale resolver instead of SessionLocaleResolver here):

<bean id="localeResolver" class="org.fhj.joanna.web.utils.RestrictiveLocaleResolver">
	<constructor-arg><bean class="org.springframework.web.servlet.i18n.SessionLocaleResolver"/></constructor-arg>
	<constructor-arg value="de"/>
	<constructor-arg><set><value>de</value><value>en</value></set></constructor-arg>
</bean>

The funny thing is that when we tried to run the very same query in Microsoft Query Analyzer it worked without an error. Then I wrote a short test that queried the database directly using PreparedStatement without Spring and iBatis to localize the problem and found out that when I passed parameters to it the error came, when I put the parameter values into the query itself it didn’t. So it seems that passing the parameters affected the order in which the conditions in the WHERE clause were evaluated: without the parameters another condition was evaluated first so that the errorneous date entry was filtered out before coming to the condition which used DATEADD.