Should Fqns only contain String elements?

[manik]

Quick poll - from JBoss Cache 2.x onwards, should Fqns only be allowed to contain String elements? For a number of Cache Loaders, we mandate that only Strings are allowed in Fqns, the question is should this be mandated anyway?

How would this affect peoples' use cases?

[belaban]

+1

[brian.stansberry]

This would significantly affect the JBC/Hibernate integration, since Hibernate uses the primary key of an entity in its Fqn for the entity cache and a serialized form of a query as part of the Fqn in the query cache.

[manik]

Yes, in it's current form this does become problematic, but can't string representations of the PK be used for the entity cache, and again something similar for the query cache?

[brian.stansberry]

Only if an algorithm could be developed that could convert the PK/query to a String such that

if (pk1.equals(pk2)
assertTrue(pkToString(pk1).equals(pkToString(pk2)));
else
assertFalse(pkToString(pk1).equals(pkToString(pk2)));

always passes.

Or we come up with some thinking-out-of-the-box solution. :)

[brian.stansberry]

Hey, JBoss Cache community -- please don't interpret my above posts as settling this issue! Please provide your input to Manik's original question; it's very much wanted!

[genman]

Non-String in FQN reasons:

1. I work with a lot of numbers and ranges. Converting from numeric to string and back again is inefficient and annoying.
2. Strings are bulky objects compared to Integer, especially in huge numbers.
3. Most CacheLoaders could support them. Admittedly this would require some work or restrictions.

For example, in the FileCacheLoader, you could simply use a PropertyEditor to convert the object to text and use this as the directory name. Store the PE used in the data file. Then, use a PropertyManager to convert the directory name back to an Object.

For BDB, convert the FQN to a byte array using serialization.

4. I would be nice to use package-private objects in FQN that would be invisible to the user to restrict data access. This is better than crafting strings that look like __HIDDEN_DATA_DO_NOT_TOUCH_PLEASE__ .

Allowing null in FQN does suck and there are probably some bugs in JBC handling them. That's a different thread perhaps.

[genman]

Also: For PojoCache, the collections wrappers currently use numbers for array indicies and hash codes. These numbers are part of the FQN, and have to be converted to Strings.

I really would like at least String and Integer/Long to work with Fqn. I don't really see too much value for floating points in Fqn. Enum would be nice as well.

[manakhan]

int / long / string would support all our foreseeable needs, mostly for convenience again on the first two ... primarily we use strings and use jbosscache as a standalone with our own socket server in front of it, so string only would be OK too

[aditsu]

I'm not sure if this is still relevant now, but here's my opinion anyway:
I generally agree with genman; at the very least, I think the cache should accept String and Integer elements.
Ideally, it should also support Long, Double, Date and enums.