Reputation: 14361
Are there any issues with using a byte[] as a primary key in a JPA Entity?
I want to use a UUID as my primary key, but stored as a string I feel it will be too large.
I was thinking of doing something like this to store the ID as a byte[] and set it as my Entity's ID:
public static byte[] byteArray(UUID uuid) {
long lsb = uuid.getLeastSignificantBits();
long msb = uuid.getMostSignificantBits();
ByteArrayOutputStream bos = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(bos);
try {
dos.writeLong(lsb);
dos.writeLong(msb);
dos.flush();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
byte[] data = bos.toByteArray();
// System.out.println("Byte Array Length "+data.length);
return data;
}
Will I have any trouble putting indexes on this in the DB? I am using both Postgres and HSQL. I am using Hibernate as my JPA provider.
Upvotes: 2
Views: 4431
Reputation: 3300
I'll concur with an earlier respondent that storing the keys as bytes will make the very difficult to query by hand when doing problem diagnosis. Using a char(x) or varchar(x) field will not consume significantly more space and will be much easier for support staff to read.
Upvotes: 1
Reputation: 18337
Bear in mind that users using an SQL client will have trouble querying for byte[] ids. That's why db ids are typically numbers; it's much easier to hand-write queries.
Upvotes: 1
Reputation: 181270
I don't think there are going to be issues with this other than a little bit of performance penalty for having a Primary Key larger than a usual 4 bytes (int) one.
Why do you need a UUID as your primary key? Why can't you just use a surrogated integer key with a autoincrement?
Upvotes: 1