[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-838) Document where non-String FQN is unacceptable
[ http://jira.jboss.com/jira/browse/JBCACHE-838?page=all ]
Elias Ross updated JBCACHE-838:
-------------------------------
JBoss Forum Reference:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983888
Description:
Clearly, Region names are supposed to be described using String-only FQNs. This is because
Regions are configured using String names in their configuration.
Also, the file and JDBC based persistence system do not handle non-String FQNs.
But here are several use cases for using non-String FQN.
For example, at my past company, we stored mobile handset data by country code and phone
numbers as numbers. Things like integers and enumerated types are obviously more
lightweight than string objects as keys. Personally, I think that being able to use
appropriate types in the FQN is worthwhile efficiency and is more consistent with the Java
philosophy of type safety.
In any case, it would be nice to have an audit of areas that:
0. Do support non-String FQN by design.
1. Do not support non-String FQN, but possibly could (create new issues for these?).
2. Cannot support non-String FQN, and are not documented.
was:
Clearly, Region names are supposed to be described using String-only FQNs. This is because
Regions are configured using String names in their configuration.
Also, the file and JDBC based persistence system do not handle non-String FQNs.
But here are several use cases for using non-String FQN.
For example, at my past company, we stored mobile handset data by country code and phone
numbers as numbers. Things like integers and enumerated types are obviously more
lightweight than string objects as keys. Personally, I think that being able to use
appropriate types in the FQN is worthwhile efficiency and is more consistent with the Java
philosophy of type safety.
In any case, it would be nice to have an audit of areas that:
0. Do support non-String FQN by design.
1. Do not support non-String FQN, but possibly could (create new issues for these?).
2. Cannot support non-String FQN, and are not documented.
Document where non-String FQN is unacceptable
---------------------------------------------
Key: JBCACHE-838
URL: http://jira.jboss.com/jira/browse/JBCACHE-838
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Reporter: Elias Ross
Assigned To: Manik Surtani
Clearly, Region names are supposed to be described using String-only FQNs. This is
because Regions are configured using String names in their configuration.
Also, the file and JDBC based persistence system do not handle non-String FQNs.
But here are several use cases for using non-String FQN.
For example, at my past company, we stored mobile handset data by country code and phone
numbers as numbers. Things like integers and enumerated types are obviously more
lightweight than string objects as keys. Personally, I think that being able to use
appropriate types in the FQN is worthwhile efficiency and is more consistent with the Java
philosophy of type safety.
In any case, it would be nice to have an audit of areas that:
0. Do support non-String FQN by design.
1. Do not support non-String FQN, but possibly could (create new issues for these?).
2. Cannot support non-String FQN, and are not documented.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira