[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-838) Document where non-String FQN is unacceptable

[Elias Ross (JIRA)]

     [ 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