And now we have one more:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1027
(that exactly follows into the example below).
Which one should we keep? :(
thanks,
-marina
Marina Vatkina wrote On 08/16/06 20:02,:
> Hi Chris,
>
> Case sensitivity is not a java2db feature (or problem), it's the mapping
> processing logic in the 1st place: see e.g. Pramod's comments on issue 832.
>
> Now, I would've agreed that it's a feature beyond the spec only if, the
> spec itself won't have examples in the mixed case, e.g.
>
> In 3.6.6 SQL Queries:
> @SqlResultSetMapping(name="OrderItemResults",
> entities={
> @EntityResult(entityClass=com.acme.Order.class, fields={
> @FieldResult(name="id", column="order_id"),
> @FieldResult(name="quantity", column="order_quantity"),
> @FieldResult(name="item", column="order_item")}),
> @EntityResult(entityClass=com.acme.Item.class)
>
> In 9.1.27 MapKey Annotation:
> @Entity
> public class Employee {
> ...
> @Id Integer getEmpid() { ... }
>
> @ManyToOne
> @JoinColumn(name="dept_id")
> public Department getDepartment() { ... }
> ...
> }
>
> It might've been an oversight in the spec (most of the annotations are in the
> upper case), but all the defaults are defined as the names of an entity or a
> field or property, and it looks like upper and mixed case names should be
> actually interchangeable as the rule.
>
> It would be a feature to support case-sensitive identifiers in a case-sensitive
> way on case-sensitive databases.
>
> My $.02.
>
> thanks,
> -marina
>
>
> Christopher Delahunt wrote:
>
>>Hello Everyone,
>>
>>I was looking over issues 832 and 887 which seem to be duplicates of 600.
>>
>>832 really describes two parts: The first is java2db
>>throwing a NPE (which needs to change so NPE isn't thrown), the second is
>>the case insensitivity within essentials will cause a mapping exception
>>during deployment as well.
>>
>>I believe that changing this could be a feature, but one that will make
>>code dependent on
>>the database, and so would not be portable across different databases.
>>
>>The request/bug is that in
>>
>>@Entity
>>@IdClass(EventPK.class)
>>public class AlarmT implements java.io.Serializable {
>>
>> @Id protected String notificationId;
>>
>> @OneToOne
>> @PrimaryKeyJoinColumns({_at_PrimaryKeyJoinColumn(name="NotificationId",
>> referencedColumnName="NotificationId"),
>>
>>the attribute notificationId is being generated in the database as
>>NOTIFICATIONID, but is being set in the join column as "NotificationId".
>>They are requesting changes such that, on a case insensitive database, this
>>will just work, as the database does not care. But when the app gets
>>ported
>>to a case sensitive database the provider will either have to throw
>>exceptions or they will get runtime errors - field "NotificationId" does
>>not
>>exist etc. This implies that users will code their applications to only
>>work on specific databases without even knowing about it.
>>
>> one is with java2db throwing a NPE, the other will be that there is a
>>mapping exception if the app is deployed
>>
>>If we leave things as is, and users instead are made aware (through
>>documentation, and through the exceptions) that field names default to
>>uppercase (as spec examples show), then applications will not need to worry
>>that their field names will need to change on different databases. The
>>attribute name will need to match join columns exactly, and so apps will
>>work regardless of the database they are run on.
>>
>>This would also insure portability among providers, as I do not know how
>>the
>>other providers are handling it.
>>
>>I believe Sybase uses case sensitive names, and so testing on Oracle then
>>moving to Sybase would be an example that would cause problems to users
>>with
>>the above example, while
>>
>>@Id protected String notificationId;
>>..
>>@PrimaryKeyJoinColumns({_at_PrimaryKeyJoinColumn(name="NOTIFICATIONID",
>>
>>or
>>
>>@Id (name="NotificationId") protected String notificationId;
>>..
>>@PrimaryKeyJoinColumns({_at_PrimaryKeyJoinColumn(name="NotificationId",
>>
>>is guaranteed to work regardless of the database (albeit using different
>>columns if both exist in a Sybase table).
>>
>>
>>Best Regards,
>>Chris