On Jul 5, 9:51 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Solution #1
> ===
> SITE_PREFIX="/site_prefix/"
>
> urlpatterns = patterns('',
> ('^%s/foo/...' % SITE_PREFIX, ),
> ...
> )
> Solution #2
> ===
> urlpatterns
rn (see my post
http://lethain.com/entry/2008/jun/22/json-object-oriented-views-and-starting-a-real-app/),
so I figured out a way to work around that problem: the
instance_decorator descriptor that I pasted at the top of that patch.
-Ken
On Jun 25, 9:41 am, "Gary Wilson Jr." <[EMAIL PROT
newforms-admin has a special-cased URL dispatcher in site.py. (see
#6470)
Various REST-ish frameworks have a '.*' url mapping and a similar
hacky dispatcher.
Django has a nice URL dispatcher in core/urlresolvers.py, which could
drop in and replace those ad-hoc dispatchers. Only it takes the name
True. But surprisingly enough, the `create` method is a QuerySet
instance method. And it doesn't use any of the filtering, so
Article.objects.filter(category=cat).create(title=title,
content=content)
doesn't do what you'd expect. (Though `cat.article_set.create` should
work.) Has that actual
So then what is the difference between a Manager and a QuerySet?
Nearly everything would work identically if Manager were simply:
class Manager(QuerySet):
pass
(except actually keeping the magic that connects it to the model
class.)
It would be exactly identical, except that:
* the assign
On Jun 14, 7:22 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> My comment was a generalization. A good number of patches that are 5
> months old won't apply cleanly to trunk, so they are effectively
> abandoned. Of course, there will always be exceptions - but this is
> the sort of thing t
On May 23, 2:29 pm, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote:
> However, one of the benefits of values() returning a dict is that you
> avoid the more expensive model instance creation when you don't need it.
I wouldn't be so quick to assume that creating model instances (or
ducks that look li
I made some comments on bug #5140 a while back, before I realized that
bug reports weren't a great place to discuss important things. That
bug bit me quite enough back in the early days of my project.
I'd definitely want to know if any url templatetag failed. And
probably any variable lookup also
What would you all think about a Meta attribute for models for
select_related, analogous to ordering? i.e., default to selecting
these related fields for any query on this model.
For example, I have a model roughly like:
class Contribution(models.Model):
# content...
creator = models.For
On Apr 27, 8:58 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-04-27 at 17:52 -0700, [EMAIL PROTECTED] wrote:
> > I'd like to point out that in #2705, the patch creators have put the
> > API on the side of the get(), as for_update(), so that the decision
> > about whether the sav
+1 also, but I'll suggest keeping the ability to get aggregate
statistics, e.g.,
django.db.connection.total_queries
django.db.connection.total_query_time
(and maybe the whole queries list should be renamed as
django.db.connection.recent_queries, so as not to suggest that it's
actually all of them
My previous email was pretty bad. I actually had two different things
to bring up, but I had conflated them into one thing that was poorly
thought out and difficult to understand. Here's one of those issues,
with a little more clear thought this time.
Problem: Debug pages sometimes load very slow
I just hacked together http://www.djangosnippets.org/snippets/631/
which includes the technical_500 error view page with the admin error
email. I did this after seeing a Django site have lots of small errors
that were difficult to track down because the traceback didn't have
enough information. An
13 matches
Mail list logo
