该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2008-09-17
除了多数据库的问题,还有一点,就是基于进程的时候,没有办法共享内存,这一点在做cache的尤其突出,那个local memory cache基本上没有什么用,只能共享memcached,或者就是用file做缓存(磁盘,或者是通过tmpfs把file放在内存里)
|
|
返回顶楼 | |
发表时间:2008-09-17
model对引用对象属性的加载深度缺乏控制,
要么全部加载select_related() 要么在页面呈现的时候再去执行sql(n+1) |
|
返回顶楼 | |
发表时间:2008-09-17
fengzl 写道 model对引用对象属性的加载深度缺乏控制,
要么全部加载select_related() 要么在页面呈现的时候再去执行sql(n+1) 我也正在解决这个问题中,还没有找到合适的解决办法。 由于没有时间仔细研究,不敢妄自菲言。 |
|
返回顶楼 | |
发表时间:2008-09-18
select_related(3)
|
|
返回顶楼 | |
发表时间:2008-09-18
落后了阿,
现在可以这么做了:select_related(fields),或者select_related(depth=1) 不过好像对manytomany没用 |
|
返回顶楼 | |
发表时间:2008-09-18
ls的诸位有仔细研究过 select_related吗?
django的select_related实际作用不大,因为它有个最大的限制 Note that select_related() does not follow foreign keys that have null=True. 所以在在对外键允许为null的地方它都会每个属性对象单独发起一次查询 它不像hibernate用left outer join来处理,这是最大的问题 |
|
返回顶楼 | |
发表时间:2008-09-18
jjx 写道 ls的诸位有仔细研究过 select_related吗?
django的select_related实际作用不大,因为它有个最大的限制 Note that select_related() does not follow foreign keys that have null=True. 所以在在对外键允许为null的地方它都会每个属性对象单独发起一次查询 它不像hibernate用left outer join来处理,这是最大的问题 支持的不过你要写成select_related('fieldname')这种样子 不过这种方法有些问题,关联深度只能到1,在向下关联就要单独查询了 |
|
返回顶楼 | |
发表时间:2008-09-18
谢谢提醒,试了一下,也可以在向下
使用__分隔 Menu.objects.order_by('sequence').exclude(visible=False).all().select_related('menuitem','security_key','menuitem__security_key') 像这里的menuitem__security_key 暂时未试再往下 |
|
返回顶楼 | |
发表时间:2008-09-18
再往下就不行了。至少我没办法了~
楼上的宁波工作? |
|
返回顶楼 | |
发表时间:2008-09-18
多按了一下,重复提交了
|
|
返回顶楼 | |