"jason.greene(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote : Twist
on this I just remembered. With entity caching, user types can be part of the FQN as
well. Primary key of the entity is the last element of the FQN. A user type in an FQN is
of course generally possible; entity caching is just a particular example where I've
had to handle it with region-based marshalling. (The region portion of the FQN is only
strings).
|
| IMO we should start requiring that FQNs are only composed of serializable types that
are on the cache classpath. POJO Cache does a very similar thing to entity caching, and it
should also be changed not to do this. We should instead compute a value based off of the
hash code. In my case, which should be possible with an entity cache, I can actually allow
collisions, by simply using the key object as an attribute (key) on the node, instead of
the last element of an fqn. The value of the key would point to an internal fqn,
containing the data of the object. Alternatively, a sub fqn structure could be created
using a unique value. In this alternative case, you would have to iterate all children,
performing a comparison.
|
| -Jason
|
|
+100. Hugely limiting in the way we have to support custom objects in Fqns right now. I
understand why people don't want just Strings as Fqn elements, but we should restrict
this to Strings + boxed primitives or something like that.
Again, though, not something we can do now (2.1.0). Perhaps 3.0.0?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116529#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...