I've seen at least two cases where the current
implementation of labelprop fails for me:
- I have an "address" class for customer data. This
class does not have a key. Customers can haven an
(academic) title attribute. This is not very suitable
as labelprop :-)
- If a class has neither title nor a key nor a name,
the chosen labelprop is very likely "activity". Not
very suitable either.

The attached patch adds a new method setlabelprop to
hyperdb.py that is intended to be used similar to
setkey, it sets the property name that should be used
for labels. It sets the class attribute _labelprop.

The patch modifies the labelprop member function of
Class to return the class attribute _labelprop if set.

I have also removed three redundant copies of the
labelprop method (checked with diff!) from all three
backends (rdbms used a common labelprop implementation)
and moved the modified version of labelprop to hyperdb.

The patch is tested only with the postgres backend.

The patch fixes both usecases outlined at the top and
does not break existing code (modulo bugs I may have
introduced). The refactoring benefits the roundup codebase.

-- Ralf