On Wed, Dec 7, 2011 at 6:08 PM, Steve Ebersole <st...@hibernate.org> wrote:
> But in either case we have a
> violation of the immutability.
One of the use cases way back when I tried using Natural Keys was for
accessing user accounts indexed by phone number. So 90% of our data
access pattern was just mapping a phone number to a primary key,
loading that entity, and the rest of the data would be cached...
Phone numbers are interesting as they are considered immutable, but in
the U.S. we infrequently have area code splits. There's also (fairly
rare) cases where people update their phone number, say, if they move
cities. Or, a phone number may be dropped and then later reused by an
entirely different user. Maybe the user can expect some disruption in
service but the expectation is service is available minutes after
porting is done.
There's also many issues dealing with various identities such as
device ID or subscriber IDs. For example MIN versus MSISDN versus MDN.
In all cases for a carrier we would store one of these values and then
build an index with the others. The index is basically a table as
such:
class NumberMapping {
@Id
long id;
String number;
int type; // usually an enum
Subscriber sub;
}
So you would select data using two columns "String, int" (not one). It
would be nice to have NaturalKey be composite, if possible...Maybe
declared as above? Or it might make sense to simply do like you do for
composite @Id.
@NaturalId
class PhoneNumber {
@Column
String number;
@Column
int type;
}
@Immutable
class NumberMapping {
@Id
long id;
@NaturalId
PhoneNumber number;
@ManyToOne
Subscriber sub;
}
The above is sort of venturing off-topic but maybe compound keys need
to be discussed as well.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
