On Sat, Jul 24, 2010 at 4:07 PM, Carl Meyer <carl.j.me...@gmail.com> wrote:
> It's not obvious to me why .extra or .raw are the appropriate analogy > here, instead of the rest of the ORM API, which does attempt to > present the same semantics regardless of backend. > The issue is about values passed, not about semantics. I admit, it wasn't a great analogy to begin with, but it does hold for other aspects of the ORM as well (e.g., you wouldn't want values that you set to 0 converted to None on model.save()). The argument that "you know what cache backend your project uses" does > not apply to the significant ecosystem of caching-related reusable > Django code: johnny-cache, cache-machine, cachebot, and more. > True, hence the proposed big note in the docs stating that the value 0 should be used with care. If such reusable code needs to cache things forever, which sounds perfectly reasonable to me, I'd still rather not co-opt "0" to mean "forever" in all cases. Each backend that supports caching with no timeout could easily offer a class attribute, such as "TIMEOUT_FOREVER", that indicated how to set the timeout in these cases. > Last week I uploaded a patch to #6447 that maintains cross-backend > parity of allowed cache keys (without any performance hit on > memcached) by making sure the other backends will reject the same keys > memcached will reject. You approved this approach on IRC, Jacob, so > given the discrepancy I'm just curious whether it is in fact a design > goal to have semantic parity between the backends shipped with Django. > Rejecting a particular subset of cache keys is also not the greatest analogy to co-opting configuration values. :-) Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
