각 종류에 고유 한 IdGeneratorStrategy

Question

하나의 특정 종류 안에서만 고유 한 기본 키를 만들 수있는 방법이 있습니까? (여기에 올바른 질문을하고 있다고 가정합니다 .- 사과하지 않으면 사과합니다.) "IdentityType.APPLICATION" 옵션이지만 "응용 프로그램"은 "가장 작은"사용 가능한 옵션 인 것 같습니다!

@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); 
    } 
} 

를하지만 새 항목을 만들 때 ID는 그래서 연락처,의 관리자, 약속, 서비스 등, 내 응용 프로그램의 모든 항목에서 고유 :

나는 다음이 모두 별개의 "테이블"(또는 종류?)이므로 OK는 서로 고유하지만 Audit Trail은 자체 카운팅 공간을 가질 수 있으므로 내 "실제"카운트를 방해하지 않습니다. 데이터 "

올바른 방법으로이 질문을합니다.이 Entity/Kind/Property/Key 항목을 실제로 알아 내려했지만 실제로 어떻게 모든 것을 이해했는지 확신 할 수 없습니다. ctually 후드에서 작동합니다!

Answer 1

AppEngine은 높은 확장 성을 위해 설계되었으며 종류별 고유 식별자가 부족하여 결과 중 하나입니다. 사람들은 종종 유사한 관련 역량에 대해 묻지 만 제공하는 것이 효율적이지 않습니다. Datastore는 거대한 키 - 값 저장소로 설명되는 BigTable을 기반으로하는 NoSQL 디자인입니다. 키 값을 빠르게 검색 할 수 있지만 많은 레코드가 동일한 서버에있을 필요는 없다는 것을 고려하면 일련의 레코드 (Kind)의 정확한 개수를 유지하는 데 너무 많은 오버 헤드가 있습니다.

자신의 코드에서 기능을 강력하게 추가하려고하면 시간이 많이 소요되는 작업을 피할 수 없습니다. 따라서 코드를 호출하면 워크로드와 지연 또는 대기 시간이 길어질 수 있습니다. 아마도 App Engine 개발자는 동일한 문제를 보았고 개발자의 친숙 함보다는 속도를 선택했을 것입니다.

응용 프로그램 코드에서 자신의 개수를 유지하고 데이터 저장소에 저장하는 것을 막을 수있는 방법은 없습니다. 어떤 경우에는 그럴 가치가 있습니다. Brewer의 CAP 이론 (explanation)을 항상 명심하십시오.