Home/ Questions/Q 3214670
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T15:05:17+00:00

I am trying out Google App Engine Java, however the absence of a unique

  • 0

I am trying out Google App Engine Java, however the absence of a unique constraint is making things difficult.
I have been through this post and this blog suggests a method to implement something similar. My background is in MySQL.Moving to datastore without a unique constraint makes me jittery because I never had to worry about duplicate values before and checking each value before inserting a new value still has room for error.

“No, you still cannot specify unique
during schema creation.”

— David Underhill talks about GAE and the unique constraint (post link)

What are you guys using to implement something similar to a unique or primary key?

I heard about a abstract datastore layer created using the low level api which worked like a regular RDB, which however was not free(however I do not remember the name of the software)

Schematic view of my problem

sNo = biggest serial_number in the db
sNo++
Insert new entry with sNo as serial_number value //checkpoint
User adds data pertaining to current serial_number 
Update entry with data where serial_number is sNo

However at line number 3(checkpoint), I feel two users might add the same sNo. And that is what is preventing me from working with appengine.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You can generate unique serial numbers for your products without needing to enforce unique IDs or querying the entire set of entities to find out what the largest serial number currently is. You can use transactions and a singleton entity to generate the ‘next’ serial number. Because the operation occurs inside a transaction, you can be sure that no two products will ever get the same serial number.

    This approach will, however, be a potential performance chokepoint and limit your application’s scalability. If it is the case that the creation of new serial numbers does not happen so often that you get contention, it may work for you.

    EDIT:
    To clarify, the singleton that holds the current — or next — serial number that is to be assigned is completely independent of any entities that actually have serial numbers assigned to them. They do not need to be all be a part of an entity group. You could have entities from multiple models using the same mechanism to get a new, unique serial number.

    I don’t remember Java well enough to provide sample code, and my Python example might be meaningless to you, but here’s pseudo-code to illustrate the idea:

    1. Receive request to create a new inventory item.
    2. Enter transaction.
    3. Retrieve current value of the single entity of the SerialNumber model.
    4. Increment value and write it to the database
    5. Return value as you exit transaction.

    Now, the code that does all the work of actually creating the inventory item and storing it along with its new serial number DOES NOT need to run in a transaction.

    Caveat: as I stated above, this could be a major performance bottleneck, as only one serial number can be created at any one time. However, it does provide you with the certainty that the serial number that you just generated is unique and not in-use.

    • 0