소유 한 관계 및 부모/자녀 관계의 문제

Question

3 개의 엔티티 사용자, 회사 및 다음과 같은 선언이있는 주소가 있습니다.

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class User implements Serializable {
  @PrimaryKey
  @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
  private Key key;

  @Persistent(mappedBy="creator")
  @Order(extensions = @Extension(vendorName="datanucleus", key="list-ordering", value="title asc"))
  private Collection<Company> companies;

  @Persistent
  private Address address;
  . . . 
}

public class Company implements Serializable {
  @PrimaryKey
  @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
  private Key key;

  @Persistent
  @Extension(vendorName="datanucleus", key="gae.parent-pk", value="true")
  private Key creatorKey;

  @Persistent
  private User creator;

  @Persistent
  private Address address;
  . . .
}

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Address implements Serializable{
  @PrimaryKey
  @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
  private Key key;
  . . .
}

사용자를 창출 한 후 주소 및 기타 정보를 설정 한 후 사용자가 소유 한 두 회사를 지속시킵니다.

company.setCreatorKey(currentUser.getKey());
pm.makePersistent(company);

문제는 내가 회사를 검색 할 때 발생하고 그 대상에서 제작자를 언급합니다. 분명히 JDO는 두 회사의 주소가 회사와 달리 사용자에게 속하며 다음 오류가 기록된다고 생각합니다.

address is mapped as a 1 to 1 relationship but there is more than one enity of kind Address that is a child of User(email@email.com) 

사용자의 열쇠는입니다

User(email@email.com)

회사의 열쇠는입니다

User(email@email.com)\Company(1) 

그리고 두 주소의 열쇠는입니다

User(email@email.com)\Company(1)\Address(1) 
User(email@email.com)\Company(1)\Address(2)

저는 계층 적 데이터베이스에 익숙하지 않으므로 두 주소가 왜 사용자와 회사의 자녀의 자손 대신 사용자의 자녀로 지속/해석되는지 궁금했습니다. 이와 같은 상황에 대한 올바른 계층은 무엇입니까? 감사.

Answer 1

어떤 버전의 App Engine SDK를 사용하고 있습니까? 월요일에 그들은 JDO 문제에 대한 많은 수정 사항을 포함하는 새로운 것을 발표했습니다. (릴리즈 노트) 4 ~ 5 개의 수정 사항은 객체 간의 관계와 관련이 있으므로이 문제가 해결되거나 새로운 방식으로 깨 졌을 가능성이 있습니다. :) Otoh, 귀하의 문제는이 공개와 관련이있을 수 있습니다. 티켓.

저는 계층 적 데이터베이스에 익숙하지 않으므로 두 주소가 왜 사용자와 회사의 자녀의 자손 대신 사용자의 자녀로 지속/해석되는지 궁금했습니다.

당신이보고있는 주요 계층 구조는 엔티티 그룹을 기반으로합니다. DataStore가 우려하는 한, 회사는 사용자와 다른 엔티티 그룹에 회사를 가질 수 있으므로 다음과 같은 주요 구조를 초래할 수 있습니다.

User(email@email.com)
Company(1)\Address(1) 
Company(1)\Address(2)

Datastore는 반드시 1 ~ 하나의 매핑 또는 1 ~ 많은 매핑에 대해 반드시 알 필요는 없습니다. 그것은 당신이 좋아하는 다른 엔티티의 키를 참조 할 수 있습니다. 그러나 JDO 계층은 모든 엔티티를 소유의 관계에 자동으로 배치하여 아마도 거래가 변경되는 방식으로 변경이 발생할 수 있습니다.

모든 말을하면서, 당신의 구조는 나에게 괜찮아 보입니다. JDO 계층이 회사의 직접적인 자녀를 찾는 것이 아니라 친절한 주소 인 엔티티 그룹 자손을 확인하는 것처럼 보입니다.