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