Google App Engine: stocker des relations sans nombre de plusieurs à

Question

J'ai deux objets un utilisateur et un rôle que je rends persistant en utilisant JDO et googles app moteur. Les deux types de données sont liés les uns aux autres en tant que relation plusieurs à plusieurs. J'ai essayé de modéliser autant que dans le gae-tutorial décrit comme des ensembles contenant la clé de l'objet correspondant. Au moment où je crée mes objets, ces clés sont nulles. Donc, afin d'obtenir des clés générées, je rends ces objets persistants. Après cela, j'ajoute les clés de référence à ces objets. Cependant, ces clés ne sont pas stockées à la fin.

En plus de la définition des touches, je manipule également d'autres attributs (après makePersistent). Ces modifications sont répercutées plus tard dans le magasin de données. Cependant, tous les changements de clés que je fais après makePersistent, ne le font pas au datastore. Si je mets ces clés avant makePersistent, elles sont stockées comme elles le devraient. Cependant, ce n'est pas une solution, car au moins un objet doit logiquement recevoir la réfrence de clé après qu'il a été rendu persistant. Ci-dessous un exemple de code, pour expliquer le problème.

Quelle est la bonne pratique pour stocker ces clés?

Persistable Rôle classe

public class Role { 

    @PrimaryKey 
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) 
    private Key Role_id; 

    @Persistent 
    private Set<Key> Users = new HashSet<Key>(); 
... 
} 

Persistable classe User

public class User { 

    @PrimaryKey 
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) 
    private Key User_id; 

    @Persistent 
    private String EMail = null; 

    @Persistent 
    private Set<Key> Roles = new HashSet<Key>(); 
    ... 
} 

code extrait qui crée 1 Rôle et 1 utilisateur et tente de définir la clé des références des deux côtés. Ils changs clés ne finissent pas dans le magasin de données. Cependant, la modification de l'adresse e-mail est écrite dans le magasin de données. ...

PersistenceManager pm = PMF.get().getPersistenceManager(); 
    Role GlobalAdmin = new Role(); 
    User Daniel = new User(); 

    try { 
     pm.makePersistent(GlobalAdmin); 
     pm.makePersistent(Daniel); 
    } catch (Exception e){ 
     System.out.println("Storing failed: " + e.getMessage()); 
    } 

    GlobalAdmin.addUser(Daniel.getUser_id()); 
    Daniel.addRole(GlobalAdmin.getRole_id()); 
    Daniel.setEMail("a@b.com"); 

    pm.close(); 
... 

Answer 1

J'ai trouvé une solution à mon problème. Quand je veux écrire ces clés, je dois détacher ces objets et les rendre persistants plus tard. Je ne comprends pas non plus pourquoi je dois le faire ni s'il y aurait quelque chose de plus élégant. Cependant, il preuves au travail.

Alors d'abord de toutes ces classes doivent être detechable:

@PersistenceCapable(detachable = "true") 
    public class User { 
    ... 

Après avoir fait les objets Persistant, je les détacher, mes clés et mis reatch ces objets au magasin ...

... 
    pm.makePersistent(GlobalAdmin); 
    pm.makePersistent(Daniel); 

    pm.detachCopy(GlobalAdmin); 
    pm.detachCopy(Daniel); 

    GlobalAdmin.addUser(Daniel.getUser_id()); 
    Daniel.addRole(GlobalAdmin.getRole_id()); 

    pm.makePersistent(GlobalAdmin); 
    pm.makePersistent(Daniel); 
    ... 

Answer 2

Je pense que vous devriez lire la documentation de datanucleus. Cela vous expliquera la solution que vous avez actuellement.

http://www.datanucleus.org/products/accessplatform_1_1/jdo/attach_detach.html

JDO fournit une interface pour la persistance des objets. JDO 1.0 ne fournit pas un moyen de prendre un objet qui était juste persisté et juste de travailler dessus et mettre à jour l'objet persistant plus tard. L'utilisateur a pour copier manuellement les champs et les copier ultérieurement sur l'objet persistant . JDO 2.0 introduit une nouvelle façon de traiter cette situation, en détachant un objet du graphique de persistance, permettant de le traiter dans l'application utilisateur . Il peut ensuite être attaché au graphique de persistance plus tard.