[
https://issues.apache.org/jira/browse/JUDDI-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688057#action_12688057
]
Jeff Faath commented on JUDDI-170:
----------------------------------
All user supplied keys in save operations are case-folded now. This may be
good enough. The only other thing to do would be to make sure any key passed
on any operation is case-folded.
> Handle case sensitivity with keys
> ---------------------------------
>
> Key: JUDDI-170
> URL: https://issues.apache.org/jira/browse/JUDDI-170
> Project: jUDDI
> Issue Type: Task
> Affects Versions: 3.0
> Reporter: Jeff Faath
> Assignee: Jeff Faath
> Priority: Minor
> Fix For: 3.0
>
>
> In UDDI v3, the user supplies entity keys that become the primary key for the
> entity. The problem is, databases handle case sensitivity with queries. The
> code currently handles key comparisons with case insensitivity in mind,
> however, the "find" operation of the JPA EntityManager may react differently
> depending on the DB. In this case, if the user supplies a key that isn't the
> exact case of the entity they meant to work with, it will be treated as a new
> entity. Other unexpected behavior may occur as well.
> There are two ways to make this work for both case insensitive and case
> sensitive databases.
> 1) automatically convert all user-supplied keys to one case and store it that
> way (advantages: easy; disadvantages: doesn't preserve user case, for ex, if
> they want to use CamelCase for Ids)
> 2) No longer use the "find" operation and instead replace it with a case
> insensitive query (advantages: preserves user case; disadvantages: "find" is
> used quite a bit to test for existence, a SELECT query will need to be
> created for every entity that find was used)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
