Bela Ban wrote:
Okay. We can actually say that FQNs can only have strings as
components,
which is a requirement for some cache loaders anyway (JDBC for instance)
The JDBM cache loader I worked on allowed for FQNs composed of any
object, including "null" of course. I believe a unit test checked if
null was supported.
I'm not sure allowing for any object is a useful feature for most or any
customer, but it's the least astonishing for the user. I recall a forum
thread that had one customer wondering why their data wasn't coming back
because FQN components were converted to strings upon store.
And then there's the question of how to appropriately store and restore
null strings. I also wonder about FQNs with "/" or null characters in
them, in a file system context they need to be escaped.
When working with a text column, it might make sense to convert
non-strings to a Java serialized, Base-64 string. Or, if the DB
supports it, simply store FQNs serialized in a short byte array or blob.
At the very least, throwing out an exception for non-strings during
store makes a lot of sense.