Frühling Mongo DB @DBREF

Question

Das ist mein MongoDB Struktur,

db.user.find(); 

Benutzer:

{ 
"name" : "KSK", 
"claim" : [objectId("52ffc4a5d85242602e000000"),objectId("52ffc4a5d85242602e000001")] 
} 

Anspruch:

[ 
    { 
    "_id" : "52ffc4a5d85242602e000001", 
    "claimName" :"XXXX" 
    }, 
    { 
    "_id" : "52ffc4a5d85242602e000000", 
    "claimName" :"YYY" 
    } 
] 

Meine Entity-Klasse:

@Document(collection="user") 
public class User{ 
    @Id  
    private String id; 
    private String name; 
    @DBRef 
private List<Claim> claim; 
// setter and getter 

} 

Anspruch Klasse:

@Document(collection="Claim") 
public class Claim{ 
    @Id 
    private String id; 
    private String claimName; 
} 

ich eine Methode, die Benutzer mit Namen wie unten zu bekommen,

public User findByName(String name); 

Wenn ich versuche, diese Methode zu treffen eine Störung erhält, dass

Nein Konverter, der vom Typ org.bson.types.ObjectId in den Typ java.lang.String konvertiert werden konnte

Also änderte ich meine User-Entity-Klasse wie unten,

Statt private List<Claim> claim;

Geändert als Private List<ObjectId> claim;

Nun, wenn ich eine Methode (findByName) ausführen, bekomme ich ein Benutzerobjekt, das beide Anspruch Objekt-IDs („52ffc4a5d85242602e000001“, „52ffc4a5d85242602e000000“) hat dann den Anspruch Liste iterieren und die Ansprüche Details entsprechend den Anspruch Objekt Id erhalten .

Anstatt dies zu tun, wenn ich findByName Methode ausführen möchte ich einen Benutzer und Anspruch Details erhalten. Wie kann ich diese Funktionalität erreichen?

Answer 1

Wenn Sie Ihr Claim s in der User Klasse mit @DBRef verweisen, Ihre JSON sollte nicht nur die ID aber den Verweis auf die Sammlung enthalten, in denen auch die ID zu finden, wie folgt aus:

{ 
    "name" : "KSK", 
    "claim" : [ 
    { "$ref":"claim", // the target collection 
     "$id : "ObjectId("52ffc4a5d85242602e000000") 
    } 
    ] 
} 

das heißt, wie Spring-Datenkarten Ihr Java zu MongoDB-Objekte. Wenn Sie mit einer leeren Datenbank starten und lassen den Frühling schaffen und die Beziehungen sparen, sollten Sie keine Probleme haben

mit

@DBRef List<Claim> claims; 

Answer 2

Mein Vorschlag besteht nicht darin, diese Anspruchsklasse in ein separates @Document zu setzen oder einfach zu relationalen Datenbanken zurückzukehren, da es sich nicht um einen Mongo-Ansatz handelt. Auch, wenn Sie auf aktuelle Architektur bestehen können Sie versuchen, über dieser Liste in User.class in smth wie dies mit @DBRef:

public class ParentModel { 

    @Id 
    private String id; 

    private String name; 

    private ParentType parentType; 

    private SubType subType; 

    @DBRef 
    private List<Model> models; 

.... 
}