有一个问题感觉很奇怪

[lointain]

onload里,如果并 不要 一直监听一个model列表的改变情况,
而是只需要获得一次当前状态,在clouda里面应该如何实现

比如一个购物车应用,商品列表的话sub/pub模型,是合适的,在列表更新后,每个客户端都会收到更新信息.
但订单信息就不是需要每个客户都需要监听的了,比如获得uid=1的所有order列表.
(别人的订单我根本不关心,从安全上讲,也不应该让我知道)

事实上,这个场景还不能说明我遇到的问题,我现在有一个单词库,大小约为一万条记录,导出的sql大约2m
此表是只可以查找,不需要改变的,如果这个表也sub/pub,总觉得做了很多无谓的消耗,
1.主要在监听上.
2.subscribe中的回调,中传入那个collection,在执行find之前就已经是完整的了(难道就这样就莫名奇妙的在这里生成一个一万条对象的数组吗.)
其实我只需要有where条件后的对象列表,应该如何操作呢.

clouda这样的中文框架我是自然的非常喜欢,
只是不知我要开发的这个应用是否合适使用这个框架实现

[huang-xin]

同学你好，pub/sub不是clouda的全部，只是是实现实时数据的一种方式，适合如你所说的“购物车”，“电影院选座购票”等场景。如果你的应用场景不需要实时与同步，可以选择其他方式来实现：如用external三方数据一次性抓取的方式，或者直接将你的2M数据直接存到localStorage里。

[lointain]

原来是这样,谢谢你的解答
也许clouda是一个专为获得百度抓取数据,生成轻应用的框架,并不是一个通用框架
其实在onload里面可以得到mongoClient或者mongoConn的话,就可以绑定到clouda的model中实现我的功能.
但clouda为什么不这样设计呢,是因为技术上的问题,还是市场策略的问题呢.
如果我想写一个这样的插件,我应该从哪个类入手呢.

[MarsYoung]

..去年这个时候我看的这个框架，当时就觉得 该框架只是为了把流量搞到baidu服务器，第3方的数据非常不方便。折腾了好久才能取到数据，当时文档不够完善，例子也不全，感觉不够轻便。当然技术很赞，只不过不适用所有应用。

[brandnewera]

谢谢认可。
关于流量的问题其实是误会了，这种纯数据无用户感知的流量其实是只有服务器成本没有商业收益的，实在是没必要“骗”这样的流量。
那么之所以引导大家把数据都经过百度，是因为在数据中转时涉及一些中转套件的部署，这些中转套件都还处于我们开发的早期版本，部署起来比较复杂，也有坑。为了提供一个好的开发体验，显得靠谱一些，在中转套件易部署和兼容性完善之前，就决定都引导大家使用百度已经弄好的云平台做数据中转了，仅此而已。