Home/ Questions/Q 7979629
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T09:49:30+00:00

I’m using Java and JPA for ORM. Initially I was defining entity keys like

  • 0

I’m using Java and JPA for ORM.

Initially I was defining entity keys like this:

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Key key;

but that resulted in ids that were growing pretty fast and in unpredictable ways (…19,20,22,1003…1007,1014,1015,2004…)

which seems to contradict docs which state that “The simplest key field is a long integer value that is automatically populated by JPA with a value unique across all other instances of the class when the object is saved to the datastore for the first time. Long integer keys use a @Id annotation, and a @GeneratedValue(strategy = GenerationType.IDENTITY) annotation”

So I found this unit test and I switched to the way it was done there:

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
private Long id;

which migrated fine after updating some GQL statements, but I’m still seeing keys increasing by 1000 every time.

Should I be using GenerationType.TABLE? Or should I have been using IDENTITY on a Long rather than a Key field?

I’m hoping to get some definitive answers before I keep changing this in my live (beta) app. Unfortunately all schemes I’ve used so far in the dev env result in contiguous keys so really no way to test out new approaches except by deploying.

Thanks in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It’s really hard to do contiguous keys on App Engine. The docs never stated that the auto-generated keys are contiguous – only that they will be unique.

    The simplest solution on app engine is to design your keys so that you don’t need them to be contiguous. Given the way BigTable is designed, if you did have contiguously incrementing keys, you’d likely have some perf bottlenecks whenever a tablet needs to be split under the hood.

    • 0