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