问题
Is there any way to create a primary key that is only unique inside one specific kind (assuming I am asking the right question here! - apologies if not) I notice there is an "IdentityType.APPLICATION" option but "Application" seems to be the "smallest" available option!!
I have the following:
@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class AuditTrail
{
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long ID;
@Persistent
private Date createDate;
@Persistent
private Long AdminID;
public AuditTrail()
{
this.createDate = new Date();
}
public AuditTrail(Long AdminID)
{
this();
this.setAdminID(AdminID);
}
}
But when I create a new entry, the ID is unique across all the items in my application, so that a Contact, an Admin, an Appointment, a Service etc are all separate "tables" (or kinds?) so its OK that the are all unique against each other, but the Audit Trail, could just have its own counting space, so that it doesn't interfere with the count of my "actual data"
Am I asking this in the right way, I have really tried to figure out this Entity/Kind/Property/Key thing, but I'm not sure I am fully understanding how it all actually works under the hood!
回答1:
AppEngine is designed for high scalability and the lack of unique identifiers per Kind is one of the consequences. People often ask about similar related capability but it just is not efficient to provide. The Datastore is a NoSQL design built on BigTable which is described as a huge key-value store. It can retrieve the value for a key rapidly but considering that your many records are not necessarily on the same server it too much overhead to maintain an accurate count of a set of them (the Kind).
If you try to add the functionality robustly in your own code, you cannot avoid time consuming operations. Therefore your code will cause a high workload and delay or "latency" as some like to call it. Probably the AppEngine developers saw the same problems and opted for speed rather than developer friendliness.
There is nothing stopping you from maintaining your own counts in your application code, and even saving them in the Datastore. In some cases it is worth the delay. Always bear Brewer's CAP theorem (explanation) in mind.
来源:https://stackoverflow.com/questions/21437075/idgeneratorstrategy-unique-for-each-kind