如何保存mongodb中的一对多关系
有以下2个实体
@Document
public class ProductInfo {
@Id
private ObjectId id ;
private String productName;
@DBRef
private List<ReleaseInfo> releaseinfo ;
}
@Document
public class ReleaseInfo{
@Id
private ObjectId id ;
private String rname;
}
逻辑为先 生成projectId 再生成Release
以下是我的实现代码
@RequestMapping(value = "/add")
public @ResponseBody Result add(ReleaseInfo release,HttpServletRequest req) {
String productId =req.getParameter("productId");
save(release);
List<ReleaseInfo> rlst ;
Query query =new Query(Criteria.where("id").is(productId));
ProductInfo product =mongoTemplate.findOne(query,ProductInfo.class);
if(product.getReleaseinfo()==null){
rlst=new ArrayList<ReleaseInfo>();
}else{
rlst=product.getReleaseinfo();
}
rlst.add(release);
Update update =new Update();
//DBRef dbref =new DBRef();
update.set("releaseinfo", rlst);
//query.
mongoTemplate.findAndModify(query, update, ProductInfo.class);
return Result.ok();
}
但是奇怪的是 进入MongoDB中的时候,他的展示形式是
release:[{ObjectId:....},{bjectId:....}]
但是我想要的结果应该是
DBRef{
“releaseInfo”,ObjectId:{....}
}
求大神解答
相关推荐
demo-onetomany-nosql:与OneToMany关系中的MongoDB的Spring Data演示项目
一对多Nosql演示 与OneToMany关系中的MongoDB的Spring Data演示项目 该项目是我发表的文章的来源。 请以下文章的链接:
MongoDB数据库设计.pptx
MongoDB数据库设计 MongoDB数据库设计全文共21页,当前为第1页。 MongoDB数据库 MongoDB is a general purpose, document-based, distributed database built for modern application developers and for the cloud era. No database is more productive to use. MongoDB is a document database, which means it stores data in JSON-like documents. We believe this is the most natural way to think about data, and is much more expressive and powerful than the traditional row/column model. MongoDB数据库设计全文共21页,当前为第2页。 Rich JSON Documents MongoDB数据库设计全文共21页,当前为第3页。 Powerful query language MongoDB数据库设计全文共21页,当前为第4页。 All the power of a relational database, and more... Full ACID transactions. 原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。一个支持事务(Transaction)的数据库,必须要具有这四种特性,否则在事务过程(Transaction processing)当中无法保证数据的正确性,交易过程极可能达不到交易方的要求。 Support for joins in queries. Two types of relationships instead of one: reference and embedded. MongoDB数据库设计全文共21页,当前为第5页。 一对多关系建模的三种基础方案 当你设计一个MongoDB数据库结构,你需要先问自己一个在使用关系型数据库时不会考虑的问题:这个关系中集合的大小是什么样的规模?你需要意识到一对很少,一对许多,一对非常多,这些细微的区别。不同的情况下你的建模也将不同。 Modeling One-to-Few One-to-Many One-to-Squillions MongoDB数据库设计全文共21页,当前为第6页。 Modeling One-to-Few 针对个人需要保存多个地址进行建模的场景下使用内嵌文档是很合适,可以在person文档中嵌入addresses数组文档 MongoDB数据库设计全文共21页,当前为第7页。 One-to-Many 以产品零件订货系统为例。每个商品有数百个可替换的零件,但是不会超过数千个。这个用例很适合使用间接引用---将零件的objectid作为数组存放在商品文档中(在这个例子中的ObjectID我使用更加易读的2字节,正常是由12个字节组成的)。 MongoDB数据库设计全文共21页,当前为第8页。 One-to-Squillions 我们用一个收集各种机器日志的例子来讨论一对非常多的问题。由于每个mongodb的文档有16M的大小限制,所以即使你是存储ObjectID也是不够的。我们可以使用很经典的处理方法"父级引用"---用一个文档存储主机,在每个日志文档中保存这个主机的ObjectID。 MongoDB数据库设计全文共21页,当前为第9页。 内嵌,子引用,父引用 三种基本的设计方案:内嵌,子引用,父引用 在选择方案时需要考虑的两个关键因素:1)一对多中的多是否需要一个单独的实体;2)这个关系中集合的规模是一对很少,很多,还是非常多。 一对很少且不需要单独访问内嵌内容的情况下可以使用内嵌多的一方。 一对很多且很多的一端内容因为各种理由需要单独存在的情况下可以通过数组的方式引用多的一方的。 一对非常多的情况下,请将一的那端引用嵌入进多的一端对象中。 MongoDB数据库设计全文共21页,当前为第10页。 双向关联Two-Way Referencing 以任务跟踪系统为例。有person和task两个集合,one-to-n的关系是从person端到task端。在需要获取person所有的task这个场景下需要在person这个对象中保存有task的id数组 在某些场景中这个应用需要显示任务的列表(例如显示一个多人协作项目中所有的任务),为了能够快速的获取某个用户负责的项目可以在task
sane-examples-one-to-many:在健全的堆栈应用程序中围绕一对多关系进行 CRUD 操作的简单示例
理智的示例应用程序 突出一对多 CRUD 功能 在健全的堆栈应用程序中围绕一对多关系进行 CRUD 操作的简单示例
python爬虫数据保存到mongoDB的实例方法
在本篇文章里小编给大家整理的是一篇关于python爬虫数据保存到mongoDB的实例方法,有需要的朋友们可以参考下。
MongoDB数据库设计法则
“我有丰富的sql使用经验,但是我是个MongoDB的初学者。我应该如何在MongoDB中针对一对多关系进行建模?”这是我被问及最多的问题之一。我没法简单的给出答案,因为这有很多方案去实现。接下来我会教导你如何针对一对多进行建模。这个话题有很多内容需要讨论,我会用三个部分进行说明。在第一部分,我会讨论针对一对多关系建模的三种基础方案。在第二部分我将会覆盖更多高级内容,包括反范式化和双向引用。在最后一部分,我将会回顾各种选择,并给出做决定时需要考虑的因素。很多初学者认为在MongoDB中针对一对多建模唯一的方案就是在父文档中内嵌一个数组子文档,但是这是不准确的。因为你可以在MongoDB内嵌一个


