Re: 1.2 Proposal: django debug toolbar in contrib
I think it's mostly only my fork (and it's forks) that vary much from trunk. I never got around to changing the framework to come in line with the master branch I think because it didn't support everything that was needed. Not sure if it does now however. On Aug 12, 4:00 pm, Rob Hudson wrote: > I'm not sure if this is the place but here are some other issues or > questions I have if this were to happen... > > * The jQuery question is a big one. I've taken strides to make the > debug toolbar interoperate with other popular JS frameworks (mootools > and prototype, namely). But if jQuery were decided against, would it > make sense to re-use some of the Javascript libraries that Django has > developed for its admin? Would it use the same admin media handler > trick? > > * Which set of plugins are included, and of those that have settings, > what are their defaults. Some defaults currently optimize to general > case and provide more debugging information, but on larger sites > performance may suffer severely. It may make sense to take a > philosophy of best default performance with opt-in added debugging. > > * Should there be a place for plugins (panels) that don't make the > cut? Panels consist of some Python and some HTML, so it's not a > single file. They *could* be changed to work similar to form.widgets > with a render method and HTML backed in... but I'm not a huge fan of > that. But it would make it a bit easier for posting on a site like > Django Snippets. > > * Should the UI match that of the Django admin (overall theme, colors, > etc)? > > * If the debug toolbar is incorporated, should we consider different > integration options? e.g. Currently the debug toolbar injects URLs > into the project in a rather ugly way -- could this be done better if > it were part of Django? > > Thanks, > Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~--~~~~--~~--~--~---
Re: 1.2 Proposal: django debug toolbar in contrib
Oh, and thats most likely my branch you're referring to Martin. I implemented a lot of the panels, and went so far as adding crazy monkey patching in some of them to catch some information I wanted. http://github.com/dcramer/django-debug-toolbar/tree/master On Aug 11, 11:38 am, Martin Maney wrote: > On Tue, Aug 11, 2009 at 09:50:35AM -0500, Alex Gaynor wrote: > > Right now django-debug-toolbar has a pretty stable panel interface and > > I actually can't recall it changing since release. A possibly more > > interesting issue is that some of the debug information it get's is > > somewhat of a hack, that is template data is gotten from monkey > > patching Template.render, the SQL data is also a monkeypatch. > > Caching stats were another area where monkeypatching seemed to be the > only alternative to an altered usage in one's source code. Back when I > spent some time using and extending parts of ddt the situation was as > described here: > > http://wiki.github.com/mmaney/django-debug-toolbar/cache-panel-workar... > > That predates the discussion I had with Rob Hudson about another fellow's > branch (can't recall whose offhand) which used a monkeypatch to add the > necessary intercept to the cache object. At one point I had hoped to > bend Jacob's ear at PyCon about this, but I got to be too busy with > other work and, in fact, never had time to drop in. Plus I had read > about how everyone was focusing on getting 1.1 out Real Soon Now and > figured it wasn't the best time for it. Months passed... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~--~~~~--~~--~--~---
Let's Talk About ``to_field``
I haven't brought this up for quite a while, but ``to_field`` still does not function properly (at least as of 1.1, I haven't noticed any changes addressing it though). The issue is that anywhere you do a GET lookup, it doesn't process the to_field properly:: # TODO: waiting on to_field fix try: opt = cls.objects.get(business=business.business_id, key=key) except cls.DoesNotExist: opt = cls.objects.create(business=business, key=key, value=value) This seems to have been solved in the admin branch when newforms-admin landed, but seems mostly ignored in the core field's. This issue has also existed as far as I can remember, which is quite some time :) So, what do we need to get the ball rolling on this. I don't have much time myself to commit, but if it's minor things such as writing some tests that easily reproduce all errors we've found. We'll glady commit those. Other than though my day is just filled, but I'd love to see this get fixed. It's something that's advertised as a core feature, has been for 3+years, and simply doesn't work. On a side note, something that I also believe is a bug, is that ManyToManyRel.get_related_field() returns the primary key field no matter what. I'm not sure if thats the intended functionality of that or not, but to me it sounds like this should refer to the field in the through model (even if that model is virtual) that it's pointing to. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
I'm a bit late in here, and it seems we reinvented a wheel as well (even tho we did this about a year ago), but recently just OS'd our simply notices system [1]. I'm also +1 for including something like this in trunk rather than using the current user messages. I had a brief look at django_notify and its a similar approach, but it seems much more configurable than what we wrote. [1] http://github.com/dcramer/django-notices On Sep 22, 9:49 pm, Tobias McNulty wrote: > On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee > > wrote: > > In reality, I get a ping time closer to 300 ms. And that's to a > > high-end data center under ideal conditions - it can be much larger if > > I'm dealing with low end providers. > > What?? 200 ms is the average quoted by Mr. Sproutcore himself! > > No, in all seriousness, my apologies for making such a broad generalization > about packet latency. I could/should have said 500 ms or even a second; the > argument and corresponding solution, if needed, remain the same. > > Anyways..we digress. I am marking this a non-issue in my own head - please > pipe up if there's a case to be made. > > Tobias --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~--~~~~--~~--~--~---
Re: Let's Talk About ``to_field``
As usual, my apologies for lacking context :) The problem happens when you try to query with a model containing a foreign key that references a to_field. It fails to pass the proper attribute. # Exampe 1, a simple get lookup class ExampleBrokenModel(models.Model): user = models.ForeignKey(User, to_field="username") user = User.objects.get(username="a_username") # The following will fail due to the fact it's going to try to do user_id= user.pk, rather # than user_id=user.username ExampleBrokenModel.objects.get(user=user) I will attach additional tests to a ticket, see also [1] I'm not aware of this ever working properly, but I'm not going to dig up tickets. You can take my word for it as we've been dealing with it at this project for a year, and had been working with Django almost 2 years before that. Either way, it's not a big deal, the fact is it doesn't work as advertised, and it is advertised. You would have to talk to the author of newforms-admin, which I believe was Brian Rosner. There is some special code for handling to_field lookups in the admin. [1] http://www.pastethat.com/LUYWh David Cramer On Wed, Sep 23, 2009 at 6:27 PM, Karen Tracey wrote: > On Wed, Sep 23, 2009 at 4:59 PM, David Cramer wrote: > >> >> I haven't brought this up for quite a while, but ``to_field`` still >> does not function properly (at least as of 1.1, I haven't noticed any >> changes addressing it though). The issue is that anywhere you do a GET >> lookup, it doesn't process the to_field properly:: >> >># TODO: waiting on to_field fix >>try: >>opt = cls.objects.get(business=business.business_id, >> key=key) >>except cls.DoesNotExist: >>opt = cls.objects.create(business=business, key=key, >> value=value) >> >> > That's supposed to illustrate the problem with to_field? It's a snippet of > code lacking any context with a cryptic TODO comment. What is the model > definition here (which would at least give a clue where to_field applies)? > How would this code be different if this "to_field fix" were applied? > > This query: > > > http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority<http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=%7Eto_field&order=priority> > > shows 4 open tickets with the "to_field" in their summary. Is the problem > you are referring to one of these? > > >> This seems to have been solved in the admin branch when newforms-admin >> landed, but seems mostly ignored in the core field's. This issue has >> also existed as far as I can remember, which is quite some time :) >> >> > I've not been around as long as you so without reference to a ticket or > something unfortunately I have no idea what problem you are talking about. > I also don't know what you mean by it being fixed in admin but not in "core > fields". Admin doesn't define fields, so huh? I can't really parse what > you are trying to say here. > > > >> So, what do we need to get the ball rolling on this. I don't have much >> time myself to commit, but if it's minor things such as writing some >> tests that easily reproduce all errors we've found. We'll glady commit >> those. Other than though my day is just filled, but I'd love to see >> this get fixed. It's something that's advertised as a core feature, >> has been for 3+years, and simply doesn't work. >> >> > The tests you mention filed in a ticket, or attached to one of those > tickets from above if indeed one of those is reporting the problem you are > talking about, would be helpful. If none of those tickets reflect the > problem you are talking about, then a complete description of the problem > would be helpful; as it is I have no idea what problem you are referring > to. > > >> > > On a side note, something that I also believe is a bug, is that >> ManyToManyRel.get_related_field() returns the primary key field no >> matter what. I'm not sure if thats the intended functionality of that >> or not, but to me it sounds like this should refer to the field in the >> through model (even if that model is virtual) that it's pointing to. >> > > A filed ticket describing the problem and how to recreate it would have a > better chance of getting remembered and fixed than a side note in an email. > > Karen > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~--~~~~--~~--~--~---
Re: Let's Talk About ``to_field``
I believe someone had linked a ticket before, but I was unable to find one, so I went ahead and submitted it here: http://code.djangoproject.com/ticket/11938 David Cramer On Wed, Sep 23, 2009 at 6:41 PM, David Cramer wrote: > As usual, my apologies for lacking context :) > > The problem happens when you try to query with a model containing a foreign > key that references a to_field. It fails to pass the proper attribute. > > # Exampe 1, a simple get lookup > class ExampleBrokenModel(models.Model): > user = models.ForeignKey(User, to_field="username") > > user = User.objects.get(username="a_username") > > # The following will fail due to the fact it's going to try to do user_id= > user.pk, rather > # than user_id=user.username > ExampleBrokenModel.objects.get(user=user) > > I will attach additional tests to a ticket, see also [1] > > I'm not aware of this ever working properly, but I'm not going to dig up > tickets. You can take my word for it as we've been dealing with it at this > project for a year, and had been working with Django almost 2 years before > that. Either way, it's not a big deal, the fact is it doesn't work as > advertised, and it is advertised. > > You would have to talk to the author of newforms-admin, which I believe was > Brian Rosner. There is some special code for handling to_field lookups in > the admin. > > [1] http://www.pastethat.com/LUYWh > > > David Cramer > > > > > On Wed, Sep 23, 2009 at 6:27 PM, Karen Tracey wrote: > >> On Wed, Sep 23, 2009 at 4:59 PM, David Cramer wrote: >> >>> >>> I haven't brought this up for quite a while, but ``to_field`` still >>> does not function properly (at least as of 1.1, I haven't noticed any >>> changes addressing it though). The issue is that anywhere you do a GET >>> lookup, it doesn't process the to_field properly:: >>> >>># TODO: waiting on to_field fix >>>try: >>>opt = cls.objects.get(business=business.business_id, >>> key=key) >>>except cls.DoesNotExist: >>>opt = cls.objects.create(business=business, key=key, >>> value=value) >>> >>> >> That's supposed to illustrate the problem with to_field? It's a snippet >> of code lacking any context with a cryptic TODO comment. What is the model >> definition here (which would at least give a clue where to_field applies)? >> How would this code be different if this "to_field fix" were applied? >> >> This query: >> >> >> http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=~to_field&order=priority<http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&summary=%7Eto_field&order=priority> >> >> shows 4 open tickets with the "to_field" in their summary. Is the problem >> you are referring to one of these? >> >> >>> This seems to have been solved in the admin branch when newforms-admin >>> landed, but seems mostly ignored in the core field's. This issue has >>> also existed as far as I can remember, which is quite some time :) >>> >>> >> I've not been around as long as you so without reference to a ticket or >> something unfortunately I have no idea what problem you are talking about. >> I also don't know what you mean by it being fixed in admin but not in "core >> fields". Admin doesn't define fields, so huh? I can't really parse what >> you are trying to say here. >> >> >> >>> So, what do we need to get the ball rolling on this. I don't have much >>> time myself to commit, but if it's minor things such as writing some >>> tests that easily reproduce all errors we've found. We'll glady commit >>> those. Other than though my day is just filled, but I'd love to see >>> this get fixed. It's something that's advertised as a core feature, >>> has been for 3+years, and simply doesn't work. >>> >>> >> The tests you mention filed in a ticket, or attached to one of those >> tickets from above if indeed one of those is reporting the problem you are >> talking about, would be helpful. If none of those tickets reflect the >> problem you are talking about, then a complete description of the problem >> would be helpful; as it is I have no idea what problem you are referring >> to. >> >> >>> >> >> On a side note, so
Re: Session/cookie based messages (#4604)
The proposal per your email is more or less how django-notices works.
Sent from my iPhone
On Oct 10, 2009, at 12:53 PM, Tobias McNulty
wrote:
>
> On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty > wrote:
>> Things that still need to be discussed/done:
>>
>> * Coming to consensus on what 3rd party app we actually choose to
>> extend/modify to fit into Django
>>
>> * What to do with the existing user message API (see
>> http://code.djangoproject.com/wiki/SessionMessages#IntegratingwiththeExistingAPI
>> )
>>
>> * Review/add to the TODO list on the wiki
>> (http://code.djangoproject.com/wiki/SessionMessages#TODOOnceaSolutionisChosen
>> )
>
> I should have also added:
>
> * Coming to consensus on a de facto standard API suitable for
> inclusion in Django
>
> I originally put it on the TODO list, but in retrospect the discussion
> needn't wait till we pick a solution.
>
> As a practical starting point, I copied the API for django-notify to
> the wiki page. I like the general form of that API, but I'd be
> slightly more happy with something like:
>
> from django.contrib import messages
>
> request.messages.add('message', messages.INFO)
> # or
> request.messages.add('message', classes=(messages.WARNING,))
> # or
> request.messages.error('message')
>
> A la python logging, I think endorsing a specific set of message
> classes or tags (but still allowing them to be extended) is A Good
> Thing because it helps reusable apps provide more customized feedback
> in a standard way.
>
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (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-developers@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
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
I also don't think this problem is being addressed here. Yes you could pass messages to the context, but you would lose the ability to retrieve those variably. I believe storing it in the existing session is the best appoach for django's builtin support. Sent from my iPhone On Oct 10, 2009, at 8:00 PM, Tobias McNulty wrote: > > On Sat, Oct 10, 2009 at 7:03 PM, veena wrote: >> Today I was on very bad wifi connection. Constantly dropped. 20 >> seconds to load a page. >> I save in admin in two tabs and got a notice in one tab from the >> other >> tab. >> >> But I agree, I defer this "bug" for the first release od django >> messaging. I think django isn't now in right mood to add there some >> functionality like adding of query parameters to response object by >> some application. Maybe in future. > > AFAIK this will become a non-issue with the advent of HTML5, as each > window/tab will have its own session. > > Tobias > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > (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-developers@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 -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
I would definitely say it needs to be configurable then at the least. As using cookies to send messges is fine if you guarantee the entity is removed onthe next hit. Otherwise it becomes a performance issue storing them for longer periods of time. While I don't think that is common it should definitely be a factor in the decision. Sent from my iPhone On Oct 12, 2009, at 9:39 AM, Tobias McNulty wrote: > > On Mon, Oct 12, 2009 at 10:21 AM, David Cramer > wrote: >> I also don't think this problem is being addressed here. Yes you >> could >> pass messages to the context, but you would lose the ability to >> retrieve those variably. I believe storing it in the existing session >> is the best appoach for django's builtin support. > > I'm not exactly sure what problem you see as not being addressed, and > I don't think you were arguing against this, but it has been noted > elsewhere that it's more desirable to store the messages directly in a > cookie, if possible, to avoid the extra database or cache hit. > > It seems well worth it to me and there are solutions out there that > try to store the messages in a cookie and then fall back to the > session for longer (>4kb) messages. > > Tobias > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > (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-developers@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 -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
I'm -1 on adding .errors or whatever. The main reasoning being that "levels"
are simply numeric values (even though django-notices does provide default
labels for its built-ins). Regroup is very easy and I don't think this is
something that needs built-in, as there's no better way to optimize it than
regroup. However, with doing this it'd be very important that it doesn't
clear the messages unless you're pulling it out. django-notices handles this
by popping out elements in the iter (I believe), so that if you don't pop
the message out, it's still present.
David Cramer
On Mon, Oct 12, 2009 at 11:19 AM, Paul McLanahan wrote:
>
> On Mon, Oct 12, 2009 at 12:11 PM, Tobias McNulty
> wrote:
> > I have no particular issue with allowing messages to be iterated in
> > full and/or by type. We could also just sort the messages and let you
> > use {% regroup messages by tag %}, but I suppose you want the ability
> > to pull out a particular type of error and that could get tedious with
> > {% regroup %}.
>
> I think regroup would be fine. My thought was that with iteration by
> type you'd be able to easily highlight just one type if you so choose,
> and even have any of the types displayed in a completely different
> area of the markup if you needed. Having both abilities would be the
> best-of-all-possible-worlds in my opinion, but this is starting to
> smell like scope-creep. I'll just say that the backends and API are
> the most important things, and having individually iterable lists is
> just a "nice to have." I'd definitely be happy to help with the
> implementation though if the group thinks it a worthy feature.
>
> Paul
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
Sorry for the misunderstanding, I was talking specifically on retrieval of
messages. I definitely see no reason not to keep it in line with the logging
module in terms of errors/warnings/info messages. However, using things to
"retrieve all error messages" should be left up to the user. It's no quicker
doing it internally than it is using itertools.groupby or regroup in a
template.
----
David Cramer
On Mon, Oct 12, 2009 at 1:32 PM, Tobias McNulty wrote:
>
> On Mon, Oct 12, 2009 at 2:02 PM, David Cramer wrote:
> > I'm -1 on adding .errors or whatever. The main reasoning being that
> "levels"
> > are simply numeric values (even though django-notices does provide
> default
> > labels for its built-ins). Regroup is very easy and I don't think this is
> > something that needs built-in, as there's no better way to optimize it
> than
> > regroup. However, with doing this it'd be very important that it doesn't
> > clear the messages unless you're pulling it out. django-notices handles
> this
> > by popping out elements in the iter (I believe), so that if you don't pop
> > the message out, it's still present.
>
> In Python logging the levels are integers, but you still get
> convenience methods like logger.error('msg'), etc.
>
> I don't see why a similar method to filter the messages by type would
> be a bad thing.
>
> For the record I have no personal need for this feature (and hence
> strong feelings about it), but nor do I see why adding it would be a
> bad thing IF the need is actually there. Right now it sounds like
> regroup will work fine for its original proponent, so, in the interest
> of keeping things simple, let's assume it will not be included unless
> someone brings up a compelling case.
>
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (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-developers@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
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
I don't agree with one calling doing logging and notices. There's really no reason to mix in logging with the notices framework as they serve completely different purposes. I believe Russel is just suggesting the APIs match so that there is no additional learning curve, which makes complete sense. ---- David Cramer On Tue, Oct 13, 2009 at 2:53 AM, Hanne Moa wrote: > > On Tue, Oct 13, 2009 at 09:27, Russell Keith-Magee > wrote: > > I'm just > > noting that adding Django support for Python logging is also on the > > cards for v1.2, and it seems weird that we would introduce two APIs > > with similar external APIs, but not try to maintain parity. > > In fact, it would be very useful to both log and add a message at the > same time, iff there is an error. So that shouldn't deliberately be > made hard to do but maybe suitable for a lazy man's shortcut: one call > that does both. > > > HM > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
I agree, this is 30 minutes of work to change the usage in Django, and it should be done with the inclusion of the messages patch. David Cramer On Fri, Oct 16, 2009 at 1:08 PM, Tobias McNulty wrote: > > On Fri, Oct 16, 2009 at 5:10 AM, Luke Plant wrote: > > I think this means that either the deprecation cycle would have to > > pushed back one (i.e. pending deprecation warning in 1.3, deprecation > > in 1.4, removed in 1.5), or core/contrib should be fixed by 1.2. I > > would strongly prefer the latter, and this would affect my vote: I > > don't want two messaging systems in Django, and if user messages are > > not deprecated, then we do have two systems. > > I agree that using deprecated code in the core is setting a bad > example. A quick review of the code shows 8 calls to > message_set.create: 3 in auth, 2 in admin, and 3 in the > create/update/delete family of generic views. This definitely sounds > to me like a manageable update for 1.2. > > Per feedback from Jacob, Chris, and Luke, I updated the notes on the > existing API, the transition plan, and the potential API on the wiki: > > http://code.djangoproject.com/wiki/SessionMessages > > Cheers, > Tobias > > > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > (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-developers@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 -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
I'm with Luke on this for the exact reasons he describes. Sent from my iPhone On Dec 5, 2009, at 7:24 PM, Russell Keith-Magee wrote: > On Sun, Dec 6, 2009 at 10:28 AM, Luke Plant > wrote: >> On Sunday 06 December 2009 00:56:56 Russell Keith-Magee wrote: >> Really? Files definitely seem to be more on the "storage" side of things: http://code.djangoproject.com/browser/django/trunk/django/core/fi les/storage.py >>> >>> The problem we have here is that we have all sorts of >>> inconsistencies introduced by history. Yes, files and templates >>> use function/class level specifiers, but db, session, cache, and >>> email all use module level specifiers. Module level specifiers >>> have the majority at this point, and personally, I prefer the >>> module approach - it shortens the user configuration strings, and >>> it enforces good usage of modules. >> >> I would have to question "enforcing good usage of modules"! It >> enforces a *single* way of using modules, that is, one class per >> module. > > The fact that it is one class per module is, IMHO, incidental. It's > one *concept* per module - one *backend* per module that I consider to > be a design pattern worth enforcing. > >> That is not necessarily 'good', it certainly isn't Pythonic >> in my experience, and it could well be bad. As such, it would be >> opinionated in a bad way - it forces other developers to have a >> proliferation of modules which might be very inconvenient. Why not >> just leave the decision in the hands of the people who are writing >> and >> organizing the code? We are all consenting adults here. > > The only time I can see this as inconvenient is if you want to put two > backends in the same module - to which I say you should have two > modules anyway. > > A part of my like for modules is the aesthetic of the end settings: > > BACKEND = 'path.to.module.backends.cookie.CookieBackend' > > vs > > BACKEND = 'path.to.module.backends.cookie' > > I vastly prefer the latter for the duplication it avoids. > >> In addition to the arguments in my other message, you also have the >> case where some third party writes a backend, and then realises they >> need another. So, they had: >> >> acme.messages.MessageStorage >> >> and just want to add >> >> acme.messages.SuperMessageStorage >> >> Instead, they are forced to move code around so each of these can >> live >> in its own module, or else have stub modules that serve no purpose >> except to appease the Django-gods. > > Again, I call this good code modularity. It may well be that the > second module requires nothing but an import and a configuration of > the first, but I would still argue that it would be good practice to > use two modules. > >> I agree that it would be good to be consistent if possible, but I >> would also like to see the better convention used, and the e-mail >> system could just as easily be changed as the messages system at this >> point, which would swing the majority the other way (it's actually >> currently "4-all" by my count, and that doesn't include the other >> configurable callables and classes, such as TEST_RUNNER, >> CSRF_FAILURE_VIEW, context processors, middlewares and view >> functions, >> which all use full paths). And #6262 could also go the other way too. > > I'm not sure I pay the comparison with middlewares, context processors > and the like. A middleware is, by definition, just a class. Off the > top of my head, I can't think of any examples where a middleware > module is split into submodules - most apps just define a middleware > module and put all relevant middlewares in that module. Hence, there > is no namespace duplication. > > On the other hand, backends are consistently broken into submodules, > because they're a lot more complex. The backend isn't defined by a > single class - conceptually, there's can be multiple classes, support > data structures, etc. The database backends are the best demonstration > of this, but IMHO the broader concept exisis and is worth preserving > in other backends. > > However, I'm also willing to admit that personal preference is a > factor here. We may just need to push this up for a BDFL judgement. I > would certainly prefer module level definitions, but at the end of the > day, I don't think I'd lose much sleep if the decision went the other > way. > > Yours, > Russ Magee %-) > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > To post to this group, send email to django-developers@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 > . > > -- 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
Re: Model validation incompatibility with existing Django idioms
For us we definitely use this behavior, and I'm guessing this is about to bite us in the ass. I would think a simple fix would be to have a commit=False, and validate=True keyword arg. By default, validate is NoInput, but if commit is False it defaults to False. Wouldn't that be a simple enough backwards compatible workaround? On Jan 7, 10:40 am, Honza Král wrote: > Hi everybody, sorry for the late reply, was busy. > > Just to add few points that lead us to do it this way: > > ModelForm has a save() method that saves the model. It is reasonable > to assume that if the form is valid, the save() method call should > succeed, that's why the entire model is validated. > > We could create a PartialModelForm, that would have save() method only > when editing (and not adding) models and have other method (or > enforced commit=False) for retrieval of the partial model. This form > would only call validation on the modelfields that are part of the > form (not being excluded). This is the behavior I understand everybody > expects from ModelForm, so, for backwards compatibility, we could call > it just ModelForm. > > Also please mind that it could prove difficult to do half the > validation in one place and other fields elsewhere without a form. > Models, as opposed to forms, don't have a state in sense of > validated/raw and they don't track changes to their fields' data. > That's why validation is run every time and the results are not cached > on the instance. > > Few quick questions to get some ideas: > > 1) If editing a model (passed an instance parameter to __init__), even > with a partial form, do you expect model.full_validate being called? > > 2) Are you OK with ripping save(commit=False) functionality to some > other method? (current functionality can stay with a deprecation > warning for example) > > 3) Would you want errors raised in model validation after it being > created by a form (commit=False) to appear on the form? > > on subject of inlines: > 1) Is it acceptable to create a model and not it's inlines in the > admin if the modelform validates but the inlines don't? > > 2) How can we limit people's validation code to avoid validating FKs > in inlines since users can (and should) create their own validation > logic on Models? Especially when we try and treat admin as "just a > cool app" and not something people should really design for. > > 3) How would you feel on creating an option to enable behavior (1) ) > and document that models with side effects in their save and delete > should really go for that? > > 4) Making 3) the default and enable switching it off if people want > their admin page to save atomically. > > Please let me know what you think > > Thanks! > > Honza Král > E-Mail: honza.k...@gmail.com > Phone: +420 606 678585 -- 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.
Re: What The Enterprise wants from Django
The first three have been huges ones with us. We're just now running into the settings issue, but would love to see what people can come up with for solutions (we dont have a good one). Glad to see multi db is finally shipping, and excited to see what can be done for startup procs. On Jan 19, 3:26 pm, Jacob Kaplan-Moss wrote: > Hi folks -- > > I had a conversation this morning with one of my clients. In the > interests of being a good corporate citizen I'll refrain from > mentioning who other than (a) they're big (Fortune 1000), (b) you've > heard of them, and (c) they're using Django. > > Before our chat, they'd invited any engineers internally to bitch > about Django, and they shared some of the pain points they'd come > across. I took some notes; the really good news is that it's a short > list, and we already know about most of it. > > Before I share the list, I should mention that I'm not arguing we have > to immediately devote resources to these problems, nor even that we > have to solve them. I'm sharing this just as food for thought, and as > a perspective from a class of developers who mostly don't participate > in our process at all. > > So: > > The main issue they have is multiple database support. Music to my > ears (and especially Alex's :) since it looks like 1.2 will solve most > (all?) of their issues. My main takeaway from this point was that the > best way to please companies like this one will be to ship 1.2 on > time. Which will happen. So we rock. > > The next big one was the "startup signal" issue -- they've got lots of > code that needs to run at startup time, and there's no great mechanism > to do that currently. The core devs have talked about this one a *lot* > over the years, and it's obviously a hard one -- for one, there's no > clear definition of what "startup" means -- but a common theme seems > to be that bigger, more complex applications need some way to cleanly > run one-time, expensive startup tasks. > > Next, we discussed the difficulty of maintaining large installations > with multiple sites, a plethora of apps, and unspeakable possible > combinations thereof. Django's settings mechanism is simple and easy > to use, but once you have hundreds of sites it starts getting really > tricky to keep things in sync across hundreds of settings files. We > talked at some length about different possibilities for dynamic > settings infrastructure; this would especially come in handy for folks > wanting to build application servers/services like App Engine or the > nascent Toppcloud. > > If you've not yet checked out Toppcloud, do so now. I'll > wait. > > Finally, we ruminated over the difficulties in building rich internet > applications. Sure, writing HTML/CSS/JS/Python/SQL by hand works fine, > but we doesn't really have a good answer for the people who want > something IDE or GUI-ish. Meanwhile, Adobe and Microsoft are putting > all sorts of marketing dollars into Flex/Silverlight, and although > HTML5 can do some amazing things, the lack of tooling is a big danger. > (I've written at more length about this in the > past:http://jacobian.org/writing/snakes-on-the-web/#s-rich-web-applications). > > Of course, there may not be much us backend folks can do about this > problem -- I'm certainly not enough of a GUI application guy to be > able to even start to think about this problem -- but the lack of an > end-to-end solution will nonetheless put some off from writing web > applications with open source tools. > > So there we are. This is very much a brain dump, and I don't really > expect any concrete action to result from it. However, I found some > really interesting stuff there, and I thought I'd share. > > Jacob -- 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.
Re: QuerySet.exists() - Possible bug?
MySQL, in this situation, would have to actually select a row to
return a result, so it's slower. If it was just select 1 as a from
table where indexed_value = N, it doesn't even hit the tables, just
the indexes.
It's definitely not more efficient, and probably just an oversight
somewhere.
On Feb 10, 7:35 am, Jeremy Dunck wrote:
> On Wed, Feb 10, 2010 at 2:05 AM, Karen Tracey wrote:
>
> ...
>
> >> * What version of Django (including SVN revision, if appropriate) are
> >> you using?
>
> > I tried current trunk and backed off to the changeset where the function was
> > added -- query was the same. Looking at the idiom it replaced, the extra
> > select of the constant 1 value as 'a' was followed by a values('a') that
> > turned the result into a ValuesQuerySet. I don't see where this is being
> > done with the exists() implementation. As a result it seems to be a regular
> > QuerySet with a query with default_cols=True, resulting in all the default
> > columns getting pulled into the query.
>
> It seems odd to me that adding columns to the result of a returned row
> would be significantly slower than the PK. It also seems to me that
> using the default ordering might be unnecessary overhead, too.
>
> But I wonder if different DBs return different things based on the
> columns in the select clause? Perhaps Malcolm had a reason for making
> the change. :-/
--
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.
Re: examples directory
It's already been done orokusaki. The examples were (humbly) horrible as well. No template usage, just generic HttpResponse. That's basic Python, and docs > examples (in code). On Feb 15, 11:52 pm, orokusaki wrote: > -1 I think examples, broken or working, are very helpful for absolute > beginners. Maybe there should be strict warnings about the quality of > the code (in a similar fashion to the ones that warn you when you view > old docs). -- 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.
Re: proposal: ask a queryset to not raise exceptions
I definitely would like to see this handled in Django, but not in the
way mentioned. I personally think there does not need to be an option
for what it raises. I think of this in the situations where find
methods return either a -1, or an Exception, based on which method you
call.
Now I can't come up w/ any reasonable alternatives, and a param
to .get() is bad simply due to the fact that i'd reserve a column
name, but something like
Model.objects.get() -- raises DoesNotExist
Model.objects.get_when() -- returns None
On Mar 7, 4:14 pm, Vitaliy Kulchevych wrote:
> http://code.djangoproject.com/ticket/5741
>
>
>
>
>
> On Sun, Mar 7, 2010 at 11:48 PM, Chris wrote:
> > In my projects, I use this pattern a lot:
>
> > try:
> > obj = SomeModel.objects.filter(**crazy_filters_here).latest()
> > except SomeModel.DoesNotExist:
> > obj = None
>
> > Basically, I throw a filter at a queryset and if some value comes out,
> > I use it, If the filter happens to filter out all rows, I want the
> > queryset to return None. The way it works now is kind of tedious. I
> > can understand in some instances a DoesNotExist exception is whats
> > best, but other times, it would be best to just return None.
>
> > This I think would be better:
>
> > obj =
> > SomeModel.objects.filter(**crazy_filters_here).empty(raise=None).latest()
>
> > if you want the old behavior:
>
> > obj =
> > SomeModel.objects.filter(**crazy_filters_here).empty(raise="DoesNotExist").
> > latest()
>
> > Also, instead of:
>
> > from django.shortcuts import get_object_or_404
> > obj = get_object_or_404(SomeModel, **crazy_filters_here).latest()
>
> > you could do:
>
> > obj =
> > SomeModel.objects.filter(**crazy_filters_here).empty(raise="404").latest()
>
> > Another pattern that appears in my code is this:
>
> > try:
> > val =
> > SomeModel.objects.filter(**crazy_filters_here).values_list('val',
> > flat=True)[0]
> > except IndexError:
> > val = None
>
> > It should also allow this to work without raising an IndexError:
>
> > val =
> > SomeModel.objects.filter(**crazy_filters_here).empty(raise=None).values_lis
> > t('val',
> > flat=True)[0]
>
> > because empty() should return a NoneQuerySet or FourOhFourQuerySet or
> > something like that, which allows values() and slicing, but are
> > ignored.
>
> > I don't know, this is just an idea I had, what do you all think?
>
> > --
> > 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
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> live free or die;
--
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.
Re: Front-End Developer - Contract/Telecommute | 40-50/hour
On Apr 7, 4:47 pm, OSS wrote: > Front-End Developer - Contract/Telecommute | 40-50/hour > > My client is a B2B media company and they are looking to hire a Front- > End Web Developer for a few upcoming projects, ranging from an online > publication development project to social media applications. This is > contract work for now, but it might have the potential to turn into a > permanent position for the right person. > > Here's a quick run down of the important stuff they are looking for, > ideally: > > * Solid JavaScript development experience. JQuery is a huge plus. > * Solid PHP experience. WordPress plug-in development would be great. > * Python experience would be a huge plus. Django experience an even > bigger plus. > * Solid HTML/CSS. This almost goes without saying. > * Experience working with templating languages would be great. > * Strong visual design skills. You should be able to craft amazing- > looking, functional user-interfaces even if you're not working off an > explicit mockup a designer has given you. > * The ability to learn and adapt quickly to new languages, APIs, > development requirements, etc. > > Above all else, what they require is a strong commitment to > productivity. They are not hiring somebody because their team lacks > the skill sets mentioned above; they are hiring somebody because they > have a lot of projects on their plate and they need to increase their > output. They are only interested in working with people who are > passionate about helping them increase the quality and quantity of > development work they do. > > Although my client has an office in NYC, your geographic U.S. location > is not important, since the development team is scattered around the > country. Wherever you live, you'll have to be comfortable working > with others remotely. You must be able to contribute as little as 20 > or as many as 40+ hours per week. > > To be considered, please submit your RESUME and HOURLY requirements to > beau[AT]open-source-staffing.com > > Thank you, > Beau J. Gould > -- > Open Source > Staffinghttp://www.open-source-staffing.comhttp://www.facebook.com/beau.gould > beau[AT]open-source-staffing.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.
Re: High Level Discussion about the Future of Django
I just want to throw my 2 cents into the ring here. I'm not against a fork, but at the same time I want to see the Django mainline progress. However, let me tell you my story, and how I've seen the Django development process over the years. I started with Django 4 years ago. It was cool, shiny, and let us get up and running. At the time, were were one of the largest Django installations. We had needs, and some of those needs were met. However, many were not. We were the only ones furiously trying to get the core team to accept our patches, ideas, etc.. Now while I'm not going to say every idea we had was right for Django, there were in fact many that were great, and eventually have made it into trunk. There are also still many (lets take the classic #17 here), that still haven't made it into trunk, even though people have been even more aggressively pushing them lately. I honestly can only remember a single patch that I've committed that has ever been fully integrated into trunk (select_related refactor). Now, the development process has changed with Django over the years, but I will sadly say that I feel it's been for the worst. I've completely given up on trac, submitting patches, or even participating. Now while some may not like my aggressive tacts (e.g. James) that doesn't mean what I've brought to the table hasn't been needed. For the last year or two all I've seen on the trac whenever I took up the time to write a patch, or even submit a ticket, was a closure of "wontfix" for some, honestly, stupid reason. It just isnt worth my time to submit the same ticket 3 times just so its "correct", or it fits everyones needs. Tickets are not patches, and they shouldn't be treated like "if this one isnt accepted, create a new one". I think there's a split within the Django core team right now and I strongly believe that unless you can tirelessly convince a core developer (no matter how large the following), a feature is not going to make it into mainline. This to me is a serious issue when you're talking about an open source, community contributed project. Sure, the core team does a large amount of the work, but not without help from the community. I'll take this back to my old analogy, not everyone is building a blog, and if they are, they can go use WordPress. Many, many things have gone ignored for far too long. I love Malcom's ORM refactor, but that was at a standstill for I don't know how long, and that entire time any patch which was related to improvements to the ORM was ignored simply stating "we're working on a refactor of the ORM". This philosophy seems to continue still today. Just recently there was a post about "High Level Talk About Django" (or whatever it was called). Now while the thread didn't make a whole lot of sense in general, it was just an attempt to gather some ideas, and brainstorm. Immediately it was shut down by the core developers. What frustrates me even more is all of this pony talk. If there's one thing I dislike it's Django's philosophy that "if it can be done 3rd party, do it", yet even the simplest things, like the template engine, have better 3rd party implementations (Jinja2). Django still doesn't have migrations. It still doesn't have dependancies. It's seriously lacking in many areas which other (albeit lesser) alternatives such as Rails have made available for far too long. Now while there's great 3rd party apps for things like this (South), and there's a few mediocre sites to find pieces of code (Django Snippets), this doesn't solve the problem which is really going on in Django: The community cant contribute beyond what the core team deems necessary. For me, I've entirely given up on trying to give back to Django. I've written enormous amounts of questionable code simply so I didn't have to patch Django, or even bother dealing w/ the process of Django's development. Monkey patching, ugly metaclass hacks, you name it. Anything that's made it easier to avoid this "process", has made it easier for us to develop. I continue to build these "ponies", but that doesn't make them any easier to integrate in Django. All in all, I think some things have been ignored for far too long. Simple things, again, like migrations, JSON and RESTful utilities, and even the tools to make development easier (the debug toolbar hasn't been around that long). Yet so much time is spent on things like refactoring the admin (while it's useful, in the big picture, its not flexible, and never can be), the template system, and many other things which have been done and done again by other people. Again, this is just my opinion, and I do know that many share it. This has been one of the largest outcries of people I've seen in a while. I honestly can't see that I see a fork succeeding, but I would definitely like to see what can happen to make the "process" friendlier to people like myself and some of the others who have posted here. Really, for me, I just don't (nor do I want to) have the time to
Re: Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)
Realizing my original statement I was regarding this thread, in this thread, it's obvious that this has gone completely off track. I might have to take back everything I thought about this being useful. If you want to address a SPECIFIC concern, it makes sense to do that under its own topic. Think of this mailing list like a forum, as, after all, many of us browse it just like one. When a "thread" happens to have 12 different topics it loses its value fast. On Apr 19, 3:44 pm, Richard Laager wrote: > In the end, *my* requirement is that I have *some place* to put > validation code that 1) can see the whole model instance, 2) will be run > from the admin interface, and 3) will return nice validation failures to > the user (not throw exceptions that will give the user a 500 error and > send me an email). > > A) Is this an unreasonable pony? If so, why? > B) If not, how can I implement this such that it will get accepted? > > I'd like to have it in for 1.2 if possible, as the model validation > interfaces are new. Once released, there will be more > backwards-compatibility guarantees to maintain. > > > > > > On Mon, 2010-04-19 at 10:53 -0500, James Bennett wrote: > > On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote: > > > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > > >> With all respect, you still haven't addressed my main concern: You > > >> told me that it was because of backward compatibility that this simple > > >> change couldn't be put in the trunk. It is backward compatible. If I'm > > >> wrong, it would suffice to have a simple explanation of what it > > >> breaks. > > > > I'd like to second this question. orokusaki suggested a couple of things > > > in ticket #13100, but I'm seconding specifically this comment: > > >http://code.djangoproject.com/ticket/13100#comment:8 > > > The difference between how ModelForm works and how Model works is > > that, if you're overriding clean() on a ModelForm subclass, you don't > > automatically get uniqueness validation -- you have to call up to the > > parent clean(), or manually apply the uniqueness validation in your > > own clean(). > > Thank you for this explanation. > > orokusaki noted in ticket #13100: > "The only difference between its implementation and > ModelForm?._post_clean() is the internal check it makes before running > validate_unique()." > > So is the actual issue here that naively calling Model.full_clean() will > always run Model.validate_unique(), when the existing > ModelForm._post_clean() code only calls Model.validate_unique() when > self._validate_unique? > > If so, Model.full_clean() is new in 1.2. So, could we just add a kwarg > like this (or similar)? > def full_clean(self, exclude=None, validate_unique=True) > > Then, it would be modified to only call Model.validate_unique if the > validate_unique argument was True. > > Then, you could call Model.full_clean() from ModelForm._post_clean(), > passing self._validate_unique and preserve the same behavior. > > Alternatively, could we add another function to Model that allows for > whole-model validation but does not call Model.validate_unique() and > then call that from ModelForm._post_clean() instead of calling > Model.full_clean()? Of course, Model.full_clean() would have to call > this new validation function as well. > > Richard > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Could not import man.credit.views, python 2.6.5. "No module named dl" error
It's an import issue with your app unrelated to django core. Someone here will eventually tell you to direct that to django-users, so you might as well hop over there now. On Jul 12, 4:31 pm, pacman wrote: > Hi, > > I've upgraded our python from 2.4 to 2.6.5. When connecting to django > server (1.2.1), it shows the following error: > > I assume it's still searching for deprecated dlmodule.so (py 2.4) or > dl.so (py 2.6). We didn't compile that module in py 2.6.5. Anyone has > seen this error and knows fix on the django side? Thanks! > > TemplateSyntaxError at / > Caught ViewDoesNotExist while rendering: Could not import > man.credit.views. Error was: No module named dlRequest Method: GET > Request URL:http://devpmmtg1:9060/ > Django Version: 1.2.1 > Exception Type: TemplateSyntaxError > Exception Value: Caught ViewDoesNotExist while rendering: Could not > import man.credit.views. Error was: No module named dl > Exception Location: /usr/local/python-2.6.5/lib/python2.6/site- > packages/django/core/urlresolvers.py in _get_callback, line 132 > Python Executable: /appl/pm/vendor/python/lx-x86/python-2.6.5/bin/ > python > Python Version: 2.6.5 -- 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.
Re: select_related() changes
http://dpaste.com/hold/4541/ :) On Jan 10, 8:39 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Updated paste:http://dpaste.com/hold/4539/ > > Should be no problems now :) > > On Jan 10, 8:22 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > Code Source:http://dpaste.com/hold/4538/ > > > This replaces django/db/query.py and adds two arguments for > > select_related(): > > > depth=N, the recursion depth, by default, infinite, follows any key > > where blank isn't True > > fields=[], a list of fields, right now only supports fields from the > > base table. I'd like to extend this to be able to do > > relatedfield__fieldname, as well. if fields is not empty it will change > > depth to 1 > > > I think i've worked out all the kinks and if a few of you could give it > > a workout it'd be great. I'd like this to become core functionality as > > I feel its needed. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
What's the svn command for generating the diff? On Jan 10, 11:07 am, Michael Radziej <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] schrieb: > > > Updated paste:http://dpaste.com/hold/4539/Thanks for your code, and I would > > have good use for some > improvements on select_related. But it's hard for me to see what > changed in the paste. > > The common way to suggest or discuss changes on this list is to > open a ticket with an attached diff and then start a discussion > refering to the ticket number. It's much easier to deal with > this, and the contributions don't get lost. Emails come and go, > tickets stay ;-) > > If you have problems creating a diff or so, let us know and > someone will surely assist. > > Cheers, > > Michael > > -- > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > http://www.noris.de- The IT-Outsourcing Company --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
Any links to an example ticket so I can keep a normal format for what im going to post? :) On Jan 10, 11:40 am, "Honza Král" <[EMAIL PROTECTED]> wrote: > On 1/10/07, David Cramer <[EMAIL PROTECTED]> wrote: > > > > > What's the svn command for generating the diff?svn diff > > you go into the top-level directory of your checked-out django, do svn > diff and capture the output > > > > > > > On Jan 10, 11:07 am, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] schrieb: > > > > > Updated paste:http://dpaste.com/hold/4539/Thanksfor your code, and I > > > > would have good use for some > > > improvements on select_related. But it's hard for me to see what > > > changed in the paste. > > > > The common way to suggest or discuss changes on this list is to > > > open a ticket with an attached diff and then start a discussion > > > refering to the ticket number. It's much easier to deal with > > > this, and the contributions don't get lost. Emails come and go, > > > tickets stay ;-) > > > > If you have problems creating a diff or so, let us know and > > > someone will surely assist. > > > > Cheers, > > > > Michael > > > > -- > > > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > > > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > > >http://www.noris.de-The IT-Outsourcing Company-- > Honza Král > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
http://code.djangoproject.com/ticket/3275 Thanks :) On Jan 10, 2:50 pm, Nikolaus Schlemm <[EMAIL PROTECTED]> wrote: > > Any links to an example ticket so I can keep a normal format for what > > im going to post? :)take a look at the tickets with patches: > >http://code.djangoproject.com/report/12 > -- > cheers, > > Nikl --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
Not quite sure what to write in terms of the documentation :) On Jan 10, 4:07 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote: > On 1/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > I'd like this to become core functionality as I feel its needed.For that > > to happen, you will likely need to do everything listed here > [1]. That includes writing some unit tests for the new functionality > and documentation explaining how to use it. In both cases they should > be submitted as diffs, just like the code. You can attach each as a > different file, or include everything all in one diff file. > > [1]:http://www.djangoproject.com/documentation/contributing/#patch-style > > -- > > Waylan Limberg > [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
I can do the docs, but it'd be a great time saver if you could do the tests. I'm up to my elbows in work at the moment so :) On Jan 10, 4:37 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > Hi David, > > if you want me to write the docs or the tests, let me know. I > could deliver within a day or two. > > Michael > > -- > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > http://www.noris.de- The IT-Outsourcing Company --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
It seems there are some issues with the code. Although I'm not sure why it's happening, this was causing servers to get extremely loaded, and the SQL queries werent executing properly. I had no issues when running it on runserver before we pushed it onto a live environment though. Going to look into it some more tomorrow, if anyone has any ideas let me know. On Jan 10, 5:45 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > David Cramer schrieb: > > > I can do the docs, but it'd be a great time saver if you could do the > > tests. I'm up to my elbows in work at the moment so :)Fine for me, then I > > take the tests. > > Michael > > -- > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > http://www.noris.de- The IT-Outsourcing Company --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
I retract my statement, we had some other random server configuration error that just happened to appear at the same time as us putting this live :) On Jan 10, 8:34 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > It seems there are some issues with the code. Although I'm not sure why > it's happening, this was causing servers to get extremely loaded, and > the SQL queries werent executing properly. I had no issues when running > it on runserver before we pushed it onto a live environment though. > > Going to look into it some more tomorrow, if anyone has any ideas let > me know. > > On Jan 10, 5:45 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > David Cramer schrieb: > > > > I can do the docs, but it'd be a great time saver if you could do the > > > tests. I'm up to my elbows in work at the moment so :)Fine for me, then I > > > take the tests. > > > Michael > > > -- > > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > >http://www.noris.de-The IT-Outsourcing Company --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: select_related() changes
It still seems to have a bug when just doing .select_related(depth=1), sometimes its filling the field w/ the wrong data, looking into it. On Jan 11, 11:31 am, "David Cramer" <[EMAIL PROTECTED]> wrote: > I retract my statement, we had some other random server configuration > error that just happened to appear at the same time as us putting this > live :) > > On Jan 10, 8:34 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > > > It seems there are some issues with the code. Although I'm not sure why > > it's happening, this was causing servers to get extremely loaded, and > > the SQL queries werent executing properly. I had no issues when running > > it on runserver before we pushed it onto a live environment though. > > > Going to look into it some more tomorrow, if anyone has any ideas let > > me know. > > > On Jan 10, 5:45 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > > David Cramer schrieb: > > > > > I can do the docs, but it'd be a great time saver if you could do the > > > > tests. I'm up to my elbows in work at the moment so :)Fine for me, then > > > > I take the tests. > > > > Michael > > > > -- > > > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - > > > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > > >http://www.noris.de-TheIT-Outsourcing Company --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Speeding up tests
So a few things we've done to take our test suite from 45 minutes to 12: 1. Implement global fixtures These get loaded after syncing just like initial data. Obviously this is a massive speed up as you only reload them in between transaction test cases. 2. Don't inherit from TestCase if you aren't using the db Around 10% of our tests now inherit from unit test instead. This let's us only bootstrap the db if it's required as well as skip any db flushing on those tests. 3. Speedup fixture loading More or less what is proposed by the original poster 4. Stop writing integration tests Biggest win :) learn to use mock On Jan 19, 12:47 pm, Adrian Holovaty wrote: > On Mon, Jan 16, 2012 at 10:46 AM, Anssi Kääriäinen > > wrote: > > I have been investigating what takes time in Django's test runner and > > if there is anything to do about it. The short answer is: yes, there > > is a lot of room for improvement. I managed to reduce the running > > speed of the test suite (on sqlite3) from 1700 seconds to around 500 > > seconds. On postgresql I reduced the run time from 5000 to 2500 > > seconds. > > Wow! Just wanted to say thanks for doing all of this work and making > these optimizations. I'm going to take a look at #16759, along with > your Git branch. > > Adrian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Database pooling vs. persistent connections
Can we please change this so it defaults to off, and just document how to turn it on and in what situations you should turn it on? In my opinion this default-on feature caters to a very specific audience, and will cause a lot of unexpected behavior with other users. Here is the tl;dr of an argument for turning it on: Connections are expensive, we should persist them. Here is the tl;dr for turning it off: Connections are expensive, so we dont have a lot of them. Immediately for anyone who has configured more workers than they have Postgres connections (which I can only imagine is common among people who havent setup infrastructure like pgbouncer) things will start blowing up. Why should this be the default behavior? Unlike MySQL, which already has cheap connections and doesn't suffer this problem, connections in Postgres add quite a large cost, both on creation, on allowing them. **Everyone** who cares about their performance on Postgres should already be using pgbouncer (or some alternative) to offset **both** of these, not just a single problem which is what Django is addressing here. I will happily defend my opinion in person at PyCon in two weeks if it still remains a default, and anyone is willing to listen, and if you reach out to the other large (and I dont mean scale) Django users I imagine you will find a lot of mixed feelings about this default. On Sunday, February 17, 2013 3:24:52 AM UTC-8, Aymeric Augustin wrote: > > **tl;dr** I believe that persistent database connections are a good idea. > Please prove me wrong :) > > > > Since I didn't know why the idea of adding a connection pooler to Django > was > rejected, I did some research before replying to the cx_Oracle > SessionPooling > thread. > > The best explanation I've found is from Russell: > > > To clarify -- we've historically been opposed to adding connection > > pooling to Django is for the same reason that we don't include a web > > server in Django -- the capability already exists in third party > > tools, and they're in a position to do a much better job at it than us > > because it's their sole focus. Django doesn't have to be the whole > > stack. > > All the discussions boil down to this argument, and the only ticket on the > topic is short on details: https://code.djangoproject.com/ticket/11798 > > > > The connection pools for Django I've looked at replace "open a connection" > by > "take a connection from the pool" and "close a connection" by "return the > connection to the pool". This isn't "real" connection pooling: each worker > holds a connection for the entire duration of each request, regardless of > whether it has an open transaction or not. > > This requires as many connection as workers, and thus is essentially > equivalent to persistent database connections, except connections can be > rotated among workers. > > Persistent connections would eliminate the overhead of creating a > connection > (IIRC ~50ms/req), which is the most annoying symptom, without incurring > the > complexity of a "real" pooler. > > They would be a win for small and medium websites that don't manage their > database transactions manually and where the complexity of maintaining an > external connection pooler isn't justified. > > Besides, when Django's transaction middelware is enabled, each request is > wrapped in a single transaction, which reserves a connection. In this > case, a > connection pooler won't perform better than persistent connections. > > Obviously, large websites should use an external pooler to multiplex their > hundreds of connections from workers into tens of connections to their > database and manage their transactions manually. I don't believe > persistent > connections to the pooler would hurt in this scenario, but if it does, it > could be optional. > > > > AFAICT there are three things to take care of before reusing a connection: > > 1) restore a pristine transaction state: transaction.rollback() should do; > > 2) reset all connection settings: the foundation was laid in #19274; > > 3) check if the connection is still alive, and re-open it otherwise: > - for psycopg2: "SELECT 1"; > - for MySQL and Oracle: connection.ping(). > > Some have argued that persistent connections tie the lifetime of databases > connections to the lifetime of workers, but it's easy to store the > creation > timestamp and re-open the connection if it exceeds a given max-age. > > So -- did I miss something? > > -- > Aymeric. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=
Re: Database pooling vs. persistent connections
It is most definitely not an "error" to have less connections available than workers, considering workers may serve different types of requests, and will now persist the database connection even after that request has finished. It may not be "the most correct", but a concurrent connection is very different than a single operation. On Thursday, February 28, 2013 at 1:40 PM, Michael wrote: > On Thu, Feb 28, 2013 at 4:10 PM, Christophe Pettus (mailto:x...@thebuild.com)> wrote: > > > > On Feb 28, 2013, at 11:09 AM, David Cramer wrote: > > > > > Immediately for anyone who has configured more workers than they have > > > Postgres connections (which I can only imagine is common among people who > > > havent setup infrastructure like pgbouncer) things will start blowing up. > > > > If they have this configuration, it's an error. The fact that the error is > > now surfacing doesn't make it a correct configuration. > > Why is this an error? It sounds more like a barrier to entry to me. Most > sites won't ever hit the maximum number of database connections, but they > over provision in their app (or they add more apps to the database as they > see their database load isn't so high). Seems to me if we enable this by > default, we are requiring a certain set of hardware that is way more > demanding than the actual use case for the app, just for a small speed > increase. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/NwY9CHM4xpU/unsubscribe?hl=en. > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > To post to this group, send email to django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Changing settings per test
A common behavior I seem to have is the need to tweak the settings object for certain test cases. The other case is that in many cases we were (are?) relying on settings being configured a certain way for the Django tests to even work. I brought this up in #django-dev a while back, but wanted to open it up to further discussion. Let me start with an example test: def test_with_awesome_setting(self): _orig = getattr(settings, 'AWESOME', None) settings.AWESOME = True # do my test ... settings.AWESOME = _orig So the obvious problem for me here is that I'm repeating this same code flow in a lot of situations. Ignoring the fact that it's ugly, it's just not fun mangling with settings like this (at least, not fun having to reset the values). My proposal is to include some kind of utility within the test suite which would make this easier. There's a couple ways I could see this working: 1. The settings object could be copied and reset on each case. 2. The settings object could be replaced with a Proxy which stores a copy of any value changed since reset, and returns that value if present. It could then simply just be reset (clear the proxy's dict) on each setUp. Anyways, I'd love to hear how others have dealt with this and any other possible solutions. -- 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.
Re: Changing settings per test
With a decorator approach here's what I whipped up:
(This is dry code)
def with_settings(**overrides):
"""Allows you to define settings that are required for this
function to work"""
NotDefined = object()
def wrapped(func):
@wraps(func)
def _with_settings(*args, **kwargs):
_orig = {}
for k, v in overrides.iteritems():
_orig[k] = getattr(settings, k, NotDefined)
try:
func(*args, **kwargs)
finally:
for k, v in _orig.iteritems():
if v is NotDefined:
delattr(settings, k)
else:
setattr(settings, k, v)
return _with_settings
return wrapped
I'm not familiar with the context managers, but I imagine those would
solve things like adjusting CONTEXT_PROCESSORS.
On Thu, Nov 4, 2010 at 1:06 PM, Dan Fairs wrote:
>
>> Let me start with an example test:
>>
>> def test_with_awesome_setting(self):
>> _orig = getattr(settings, 'AWESOME', None)
>> settings.AWESOME = True
>>
>> # do my test
>> ...
>>
>> settings.AWESOME = _orig
>>
>
> Pedant: there's a small bug above which has bitten me before doing a similar
> thing - settings.AWESOME ends up set to None after the test has run if it
> didn't exist before.
>
>> Anyways, I'd love to hear how others have dealt with this and any
>> other possible solutions.
>
> I've used Michael Foord's Mock library to patch a setting for the duration of
> a test case. Chris Withers' testfixtures library also has some sugar to
> provide a context manager approach, though I haven't used that in a little
> while.
>
> Cheers,
> Dan
>
> --
> Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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.
>
>
--
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.
Re: Changing settings per test
Agree with Alex. We're considering moving more towards decorating
views rather than class attributes. I'm not sure of the performance
implications of many classes vs decorating functions on a large class
instead, but it just seems to make more sense in some cases.
Here's a working (we're now using it) version of the previous decorator:
def with_settings(**overrides):
"""Allows you to define settings that are required for this
function to work"""
NotDefined = object()
def wrapped(func):
@wraps(func)
def _with_settings(*args, **kwargs):
_orig = {}
for k, v in overrides.iteritems():
_orig[k] = getattr(settings, k, NotDefined)
setattr(settings, k, v)
try:
func(*args, **kwargs)
finally:
for k, v in _orig.iteritems():
if v is NotDefined:
delattr(settings, k)
else:
setattr(settings, k, v)
return _with_settings
return wrapped
--
David Cramer
http://www.davidcramer.net
On Thu, Nov 4, 2010 at 2:26 PM, Alex Gaynor wrote:
> 2010/11/4 Łukasz Rekucki :
>> Funny, I had exactly the same problem today at work while refactoring
>> my application's tests suite :).
>>
>> Currently, I'm using a pair of save/restore functions: save() monkey
>> patches the settings module and returns a dictionary of old values,
>> restore() puts back the old values based on the dictionary. I usually
>> put this in setUp/tearDown so I don't have to repeat in every test. I
>> was about to propose that
>> Django's TestCase should do something similar by default.
>>
>> Both the decorator and context processor are very useful, but having
>> something to set values for the whole test case instead of a single
>> test or a block of code would be great too. I was thinking about
>> something in line of:
>>
>> class EmailTestCase(TestCase):
>> settings = dict(DEFAULT_FROM_EMAIL="webmas...@example.com")
>>
>> On 4 November 2010 21:11, David Cramer wrote:
>>> With a decorator approach here's what I whipped up:
>>>
>>> (This is dry code)
>>>
>>> def with_settings(**overrides):
>>> """Allows you to define settings that are required for this
>>> function to work"""
>>> NotDefined = object()
>>> def wrapped(func):
>>> �...@wraps(func)
>>> def _with_settings(*args, **kwargs):
>>> _orig = {}
>>> for k, v in overrides.iteritems():
>>> _orig[k] = getattr(settings, k, NotDefined)
>>>
>>> try:
>>> func(*args, **kwargs)
>>> finally:
>>> for k, v in _orig.iteritems():
>>> if v is NotDefined:
>>> delattr(settings, k)
>>> else:
>>> setattr(settings, k, v)
>>> return _with_settings
>>> return wrapped
>>>
>>> I'm not familiar with the context managers, but I imagine those would
>>> solve things like adjusting CONTEXT_PROCESSORS.
>>>
>>> On Thu, Nov 4, 2010 at 1:06 PM, Dan Fairs wrote:
>>>>
>>>>> Let me start with an example test:
>>>>>
>>>>> def test_with_awesome_setting(self):
>>>>> _orig = getattr(settings, 'AWESOME', None)
>>>>> settings.AWESOME = True
>>>>>
>>>>> # do my test
>>>>> ...
>>>>>
>>>>> settings.AWESOME = _orig
>>>>>
>>>>
>>>> Pedant: there's a small bug above which has bitten me before doing a
>>>> similar thing - settings.AWESOME ends up set to None after the test has
>>>> run if it didn't exist before.
>>>>
>>>>> Anyways, I'd love to hear how others have dealt with this and any
>>>>> other possible solutions.
>>>>
>>>> I've used Michael Foord's Mock library to patch a setting for the duration
>>>> of a test case. Chris Withers' testfixtures library also has some sugar to
>>>> provide a context manager approach, though I haven't used that in a little
>>>> while.
>>>>
>>>> Cheers,
>>>> Dan
>>>>
>>>> --
>>>> Dan Fairs | dan.fa...@gmail.com | www.fezc
Re: Changing settings per test
I was going to propose the same thing Santiago. Signals seem like the ideal candidate to solve that problem. -- David Cramer http://www.davidcramer.net On Fri, Nov 5, 2010 at 4:57 AM, Santiago Perez wrote: >> * Settings that are internally cached. For example, anything that >> modifies INSTALLED_APPS. >> >> * Settings that need to make call to reset state affected by loading >> new new group of settings. For example, if you change TZ, you need to >> call "time.tzset()" on teardown to reset the timezone. Similarly for >> deactivating translations if you change USE_I18N. >> >> * Settings that need to be removed, rather that set to None. Again, >> TZ is an example here -- there is a difference between "TZ exists and >> is None" and "TZ doesn't exist". > > Isn't it be possible to change the setattr of settings so that when ever a > setting is changed, a signal is activated and those who cache or need to > trigger actions such as time.tzset() can hook to those signals to perform > those actions? If every setting is ready to be updated then a simple > decorator should be much simpler. These hooks could even allow the owner of > a setting to raise an exception when a setting is modified if it is truly > impossible to change it at run-time. > > -- > 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. > -- 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.
Disqus API 3.0
We have been working on a new version of the API these past couple of months, and we're nearing a public release. I wanted to take this opportunity to see if any of the heavy API users (specific needs, etc) would like to chime in with what they want to see, and possible give our docs/api testing tools a whirl. Just throw your feedback here, and if you're interested in testing out the new API before it goes public, toss me an email (da...@disqus) with what your current application use and we'll go from there. Thanks! -- 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.
Backwards Incompatible API Changes
We're going to be deploying a backwards incompatible change to all "since" values in the API. Any endpoint which accepts this parameter to use as a form of range pagination will now include the value sent, as well as values before or after it (depending on the order). For example, in the original implementation, since=1, would return results of 2, 3, 4, etc. In the new implementation, since=1, would return results of 1, 2, 3, 4, etc. We will also very shortly be implementing proper pagination using cursors to avoid certain race conditions when attempting to paginate. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Backwards Incompatible API Changes
I have no idea how I've done this, twice. On Feb 10, 2:16 pm, Alex Gaynor wrote: > On Thu, Feb 10, 2011 at 5:14 PM, David Cramer wrote: > > We're going to be deploying a backwards incompatible change to all > > "since" values in the API. Any endpoint which accepts this parameter > > to use as a form of range pagination will now include the value sent, > > as well as values before or after it (depending on the order). > > > For example, in the original implementation, since=1, would return > > results of 2, 3, 4, etc. > > > In the new implementation, since=1, would return results of 1, 2, 3, > > 4, etc. > > > We will also very shortly be implementing proper pagination using > > cursors to avoid certain race conditions when attempting to paginate. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-developers@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. > > Did this go out to the wrong mailing list? > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Default project layout / directory structure
Check out django-startproject from lincolnloop.com https://github.com/lincolnloop/django-startproject Kill off all the server configs (though some of it might be cool, like Fabric integration), and I think it'd make for a pretty good base to work from if this were to go into core. On Mar 13, 9:17 pm, John Debs wrote: > I like the idea too, since I've run into a lot of situations where > some more convention here would make a decision much easier to make. > However, it isn't clear what exactly should be better defined and I > think the first step to a serious proposal would be to figure that > out. > > The only example that comes to mind is Pinax's apps/ directory for a > project's internal apps – it's a good convention that many people > already follow. My other gripe has already been taken care of, with > the integration of django-staticfiles. > > What other things did you have in mind? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Expensive queryset cloning
In our profiling we've also noticed the cloning to be one of the slowest parts of the app (that and instantiation of model objects). We haven't yet, but had been planning on exploring a way to mutate the existing class in most circumstances, but haven't dug into it too much yet. On Mar 14, 11:16 pm, Alexander Schepanovski wrote: > > I'd be surprised if the cloning of querysets is actually a > > significant bottleneck relative to the database query itself > > I was too. > Query via ORM is 2-4 times slower for me than just database query + > network roundtrip. It is not only due queryset cloning, but cloning > takes 0.5-1 of that 2-4 times. > Also, I cache db queries issued via ORM, so for cache hit I need to > construct queryset but don't need to execute query. > > > unless you're doing loops with hundreds or thousands of clones, in which > > case > > it can almost certainly be optimized via Q objects. > > not loops but many ifs. I already use dicts and Q objects (when need > complex conditions) but I still have no less than 3 (filter + order_by > + slice) clones for each query. Here we see an interesting thing - > cloning querysets made me write less beautiful code. > > > If you really think it will make a significant difference for your app, > > you can probably achieve this for yourself by using your own subclass of > > QuerySet and overriding the _clone method. > > Already do this, but it does not cover User model and such. I probably > go with some monkey patch for now. > > > This is not an option. It will break quite a lot of existing code, and > > often in highly confusing ways. > > Not so much code. In most cases cloning is not needed. But it will be > confusing breakage, I agree. On other hand for an unbiased person > cloning can be confusing too. I wonder how many people were surprised > why > qs.filter(...) > does not filter qs. > > Ok, if not by default, still we can provide some .mutating() method > or .cloning(bool) method which switches queryset into/off mutating > mode. Then we can use it in some django code such as Manager.get to > avoid useless cloning. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
django.conf.settings.get()
Ticket speaks for itself: http://code.djangoproject.com/ticket/10098 My vote is to reopen it, as this is very common, easy to implement, and very unlikely that it would ever need deprecated. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: get_or_create can still cause IntegrityError
We hit this same issue in Postgres (it's definitely not MySQL specific). I'm unsure of the solution or precise conditions we're hitting it in, but I think by default we use READ COMMITTED. On May 7, 3:28 am, Tomasz Zielinski wrote: > I think that get_or_create is still broken, despite this > fix:http://code.djangoproject.com/ticket/6641 > > The details, along with a working solution, are in my answer > here:http://stackoverflow.com/questions/2235318/how-do-i-deal-with-this-ra... > I'm not sure if the solution is optimal, trying to INSERT first might be > overally more expensive, but I think that something should be done with > get_or_create. > > Best, > > Tomasz -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: get_or_create can still cause IntegrityError
Would it help (in PG-world) at least if the selects where in savepoints as well? On May 7, 10:09 am, David Cramer wrote: > We hit this same issue in Postgres (it's definitely not MySQL > specific). I'm unsure of the solution or precise conditions we're > hitting it in, but I think by default we use READ COMMITTED. > > On May 7, 3:28 am, Tomasz Zielinski > wrote: > > > > > > > > > I think that get_or_create is still broken, despite this > > fix:http://code.djangoproject.com/ticket/6641 > > > The details, along with a working solution, are in my answer > > here:http://stackoverflow.com/questions/2235318/how-do-i-deal-with-this-ra... > > I'm not sure if the solution is optimal, trying to INSERT first might be > > overally more expensive, but I think that something should be done with > > get_or_create. > > > Best, > > > Tomasz -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Test optimizations (2-5x as fast)
You sir, are my personal hero for the day :) We had also been looking at how we could speed up the fixture loading (we were almost ready to go so far as to make one giant fixture that just loaded at the start of the test runner). This is awesome progress On May 13, 4:57 pm, Erik Rose wrote: > tl;dr: I've written an alternative TestCase base class which makes > fixture-using tests much more I/O efficient on transactional DBs, and I'd > like to upstream it. > > Greetings, all! This is my first django-dev post, so please be gentle. :-) I > hack on support.mozilla.com, a fairly large Django site with about 1000 > tests. Those tests make heavy use of fixtures and, as a result, used to take > over 5 minutes to run. So, I spent a few days seeing if I could cut the > amount of DB I/O needed. Ultimately, I got the run down to just over 1 > minute, and almost all of those gains are translatable to any Django site > running against a transactional DB. No changes to the apps themselves are > needed. I'd love to push some of this work upstream, if there's interest (or > even lack of opposition ;-)). > > The speedups came from 3 main optimizations: > > 1. Class-level fixture setup > > Given a transaction DB, there's no reason to reload fixtures via dozens of > SQL statements before every test. I made use of setup_class() and > teardown_class() (yay, unittest2!) to change the flow for TestCase-using > tests to this: > a. Load the fixtures at the top of the class, and commit. > b. Run a test. > c. Roll back, returning to pristine fixtures. Go back to step b. > d. At class teardown, figure out which tables the fixtures loaded into, > and expressly clear out what was added. > > Before this optimization: 302s to run the suite > After: 97s. > > Before: 37,583 queries > After: 4,116 > > On top of that, an additional 4s was saved by reusing a single connection > rather than opening and closing them all the time, bringing the final number > down to 93s. (We can get away with this because we're committing any > on-cursor-initialization setup, whereas the old TestCase rolled it back.) > > Here's the > code:https://github.com/erikrose/test-utils/blob/master/test_utils/__init_ > I'd love to generalize it a bit (to fall back to the old behavior with > non-transactional backends, for example) and offer it as a patch to Django > proper, replacing TestCase. Thoughts? > > (If you notice that copy-and-paste of loaddata sitting off to the side in > another module, don't fret; in the patch, that would turn into a refactoring > of loaddata to make the computation of the fixture-referenced tables > separately reusable.) > > 2. Fixture grouping > > I next observed that many test classes reused the same sets of fixtures, > often via subclassing. After the previous optimization, our tests still > loaded fixtures 114 times, even though there were only 11 distinct sets of > them. So, I thought: why not write a custom testrunner that buckets the > classes by fixture set and advises the classes that, unless they're the first > or last in a bucket, they shouldn't bother tearing down or setting up the > fixtures, respectively? This took the form of a custom nose plugin (we use > nose for all our Django stuff), and it took another quarter off the test run: > > Before: 97s > After: 74s > > Of course, test independence is still preserved. We're just factoring out > pointlessly repeated setup. > > I don't really have plans to upstream this unless someone calls for it, but > I'll be making it available soon, likely as part of django-nose. > > 3. Startup optimizations > > At this point, it was bothering me that, just to run a single test, I had to > wait through 15s of DB initialization (mostly auth_permissions and > django_content_type population)—stuff which was already perfectly valid from > the previous test run. So, building on some work we had already done in this > direction, I decided to skip the teardown of the test DB and, symmetrically, > the setup on future runs. If you make schema changes, just set an env var, > and it wipes and remakes the DB like usual. I could see pushing this into > django-nose as well, but it's got the hackiest implementation and can > potentially confuse users. I mention it for completeness. > > Before: startup time 15s > After: 3s (There's quite a wide variance due to I/O caching luck.) > > Code:https://github.com/erikrose/test-utils/commit/b95a1b7 > > If you read this far, you get a cookie! I welcome your feedback on merging > optimization #1 into core, as well as any accusations of insanity re: #2 and > #3. FWIW, everything works great without touching any of the tests on 3 of > our Django sites, totaling over 2000 tests. > > Best regards and wishes for a happy weekend, > Erik Rose > support.mozilla.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-d
Re: Test optimizations (2-5x as fast)
Also, one thing I'm quickly noticing (I'm a bit confused why its setup_class and not setUpClass as well), but this wont work with postgres without changing the DELETE code to work like the test runner's TRUNCATE foo, bar; (due to foreign key constraints). On May 13, 9:42 pm, David Cramer wrote: > You sir, are my personal hero for the day :) > > We had also been looking at how we could speed up the fixture loading > (we were almost ready to go so far as to make one giant fixture that > just loaded at the start of the test runner). This is awesome progress > > On May 13, 4:57 pm, Erik Rose wrote: > > > > > > > > > tl;dr: I've written an alternative TestCase base class which makes > > fixture-using tests much more I/O efficient on transactional DBs, and I'd > > like to upstream it. > > > Greetings, all! This is my first django-dev post, so please be gentle. :-) > > I hack on support.mozilla.com, a fairly large Django site with about 1000 > > tests. Those tests make heavy use of fixtures and, as a result, used to > > take over 5 minutes to run. So, I spent a few days seeing if I could cut > > the amount of DB I/O needed. Ultimately, I got the run down to just over 1 > > minute, and almost all of those gains are translatable to any Django site > > running against a transactional DB. No changes to the apps themselves are > > needed. I'd love to push some of this work upstream, if there's interest > > (or even lack of opposition ;-)). > > > The speedups came from 3 main optimizations: > > > 1. Class-level fixture setup > > > Given a transaction DB, there's no reason to reload fixtures via dozens of > > SQL statements before every test. I made use of setup_class() and > > teardown_class() (yay, unittest2!) to change the flow for TestCase-using > > tests to this: > > a. Load the fixtures at the top of the class, and commit. > > b. Run a test. > > c. Roll back, returning to pristine fixtures. Go back to step b. > > d. At class teardown, figure out which tables the fixtures loaded into, > > and expressly clear out what was added. > > > Before this optimization: 302s to run the suite > > After: 97s. > > > Before: 37,583 queries > > After: 4,116 > > > On top of that, an additional 4s was saved by reusing a single connection > > rather than opening and closing them all the time, bringing the final > > number down to 93s. (We can get away with this because we're committing any > > on-cursor-initialization setup, whereas the old TestCase rolled it back.) > > > Here's the > > code:https://github.com/erikrose/test-utils/blob/master/test_utils/__init_ > > I'd love to generalize it a bit (to fall back to the old behavior with > > non-transactional backends, for example) and offer it as a patch to Django > > proper, replacing TestCase. Thoughts? > > > (If you notice that copy-and-paste of loaddata sitting off to the side in > > another module, don't fret; in the patch, that would turn into a > > refactoring of loaddata to make the computation of the fixture-referenced > > tables separately reusable.) > > > 2. Fixture grouping > > > I next observed that many test classes reused the same sets of fixtures, > > often via subclassing. After the previous optimization, our tests still > > loaded fixtures 114 times, even though there were only 11 distinct sets of > > them. So, I thought: why not write a custom testrunner that buckets the > > classes by fixture set and advises the classes that, unless they're the > > first or last in a bucket, they shouldn't bother tearing down or setting up > > the fixtures, respectively? This took the form of a custom nose plugin (we > > use nose for all our Django stuff), and it took another quarter off the > > test run: > > > Before: 97s > > After: 74s > > > Of course, test independence is still preserved. We're just factoring out > > pointlessly repeated setup. > > > I don't really have plans to upstream this unless someone calls for it, but > > I'll be making it available soon, likely as part of django-nose. > > > 3. Startup optimizations > > > At this point, it was bothering me that, just to run a single test, I had > > to wait through 15s of DB initialization (mostly auth_permissions and > > django_content_type population)—stuff which was already perfectly valid > > from the previous test run. So, building on some work we had already done > > in this direction, I decided to skip the teardown of t
Re: Test optimizations (2-5x as fast)
More quick notes. You can do something like this to handle the flushing: sql_list = connection.ops.sql_flush(no_style(), tables, connection.introspection.sequence_list()) for sql in sql_list: cursor.execute(sql) Unfortunately, you're still reliant that nothing was created with signals that uses constraints. For us this is very common, and I can't imagine we're an edge case there On May 13, 9:42 pm, David Cramer wrote: > You sir, are my personal hero for the day :) > > We had also been looking at how we could speed up the fixture loading > (we were almost ready to go so far as to make one giant fixture that > just loaded at the start of the test runner). This is awesome progress > > On May 13, 4:57 pm, Erik Rose wrote: > > > > > > > > > tl;dr: I've written an alternative TestCase base class which makes > > fixture-using tests much more I/O efficient on transactional DBs, and I'd > > like to upstream it. > > > Greetings, all! This is my first django-dev post, so please be gentle. :-) > > I hack on support.mozilla.com, a fairly large Django site with about 1000 > > tests. Those tests make heavy use of fixtures and, as a result, used to > > take over 5 minutes to run. So, I spent a few days seeing if I could cut > > the amount of DB I/O needed. Ultimately, I got the run down to just over 1 > > minute, and almost all of those gains are translatable to any Django site > > running against a transactional DB. No changes to the apps themselves are > > needed. I'd love to push some of this work upstream, if there's interest > > (or even lack of opposition ;-)). > > > The speedups came from 3 main optimizations: > > > 1. Class-level fixture setup > > > Given a transaction DB, there's no reason to reload fixtures via dozens of > > SQL statements before every test. I made use of setup_class() and > > teardown_class() (yay, unittest2!) to change the flow for TestCase-using > > tests to this: > > a. Load the fixtures at the top of the class, and commit. > > b. Run a test. > > c. Roll back, returning to pristine fixtures. Go back to step b. > > d. At class teardown, figure out which tables the fixtures loaded into, > > and expressly clear out what was added. > > > Before this optimization: 302s to run the suite > > After: 97s. > > > Before: 37,583 queries > > After: 4,116 > > > On top of that, an additional 4s was saved by reusing a single connection > > rather than opening and closing them all the time, bringing the final > > number down to 93s. (We can get away with this because we're committing any > > on-cursor-initialization setup, whereas the old TestCase rolled it back.) > > > Here's the > > code:https://github.com/erikrose/test-utils/blob/master/test_utils/__init_ > > I'd love to generalize it a bit (to fall back to the old behavior with > > non-transactional backends, for example) and offer it as a patch to Django > > proper, replacing TestCase. Thoughts? > > > (If you notice that copy-and-paste of loaddata sitting off to the side in > > another module, don't fret; in the patch, that would turn into a > > refactoring of loaddata to make the computation of the fixture-referenced > > tables separately reusable.) > > > 2. Fixture grouping > > > I next observed that many test classes reused the same sets of fixtures, > > often via subclassing. After the previous optimization, our tests still > > loaded fixtures 114 times, even though there were only 11 distinct sets of > > them. So, I thought: why not write a custom testrunner that buckets the > > classes by fixture set and advises the classes that, unless they're the > > first or last in a bucket, they shouldn't bother tearing down or setting up > > the fixtures, respectively? This took the form of a custom nose plugin (we > > use nose for all our Django stuff), and it took another quarter off the > > test run: > > > Before: 97s > > After: 74s > > > Of course, test independence is still preserved. We're just factoring out > > pointlessly repeated setup. > > > I don't really have plans to upstream this unless someone calls for it, but > > I'll be making it available soon, likely as part of django-nose. > > > 3. Startup optimizations > > > At this point, it was bothering me that, just to run a single test, I had > > to wait through 15s of DB initialization (mostly auth_permissions and > > django_content_type populatio
Re: Test optimizations (2-5x as fast)
Postgres requires resetting the sequences I believe. I just assume Oracle/MSSQL are probably similar. Regarding the signals, basically we have a bunch of post_save type things, which tend to store aggregate data for certain conditions. These get populated (in some cases) in our tests, but don't correspond to a fixture or a model in the same app. -- David Cramer http://justcramer.com On Mon, May 16, 2011 at 9:09 PM, Erik Rose wrote: > Woo, thanks for the constructive suggestions! > >> Also, one thing I'm quickly noticing (I'm a bit confused why its >> setup_class and not setUpClass as well), > > I was writing to nose's hooks; didn't realize Django used unittest2 now! > >> but this wont work with >> postgres without changing the DELETE code to work like the test >> runner's TRUNCATE foo, bar; (due to foreign key constraints). > > Absolutely. I assume this is what you fix below > >> You can do something like this to handle the >> flushing: >> >> sql_list = connection.ops.sql_flush(no_style(), >> tables, connection.introspection.sequence_list()) >> for sql in sql_list: >> cursor.execute(sql) > > Brilliant! Thanks! Say, can you think of any backends in which you actually > have to reset the sequences after truncating? That seems like an interesting > decoupling to me. MySQL, anyway, does the reset implicitly; perhaps we can > optimize its sql_flush routine. > >> Unfortunately, you're still reliant that nothing was created with >> signals that uses constraints. For us this is very common, and I can't >> imagine we're an edge case there > > Can you tell me of these signals? Which ones? I don't think we use them, but > I don't want to overlook them. > > Erik -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Test optimizations (2-5x as fast)
Is there a sensible to way "copy" databases in SQL? it's pretty obvious with things like sqlite, but outside of that seems tricky. I really like that idea, and you should definitely just be able to (at the very least) run a unique hash on the required fixtures to determine if a database is available for this or not. On May 17, 11:28 am, Erik Rose wrote: > > I would be very happy to test this against Oracle database to see is how > > much patch improves speed since previously running tests against Oracle > > has been a real pain specially all db recreate stuff took a long long > > time. > > Great! I'll post again to this thread when the patch is ready. Or, if you'd > like to try it now, you can downloadhttps://github.com/jbalogh/test-utilsand > make your test classes subclass FastFixtureTestCase rather than TestCase. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Test optimizations (2-5x as fast)
Here's my proposal, assuming it can be done: 1. Create default database. 2. Run a test 3. If a test has fixtures, check for, and if not, copy base table to ``name_``. 4. Start transaction 5. Run Tests 6. Roll back I think that pretty much would solve all cases, and assuming you reuse tons of fixtures it should be a huge benefit. Also if the begin/rollback aren't good enough, and we can already "copy" a database, then we could just continually copy databases each time (assuming its fast). On May 19, 6:12 am, Hanne Moa wrote: > On 18 May 2011 01:46, Erik Rose wrote: > > >> Is there a sensible to way "copy" databases in SQL? > > > SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a > > table. It's supported in MySQL at least. You could then do a bunch of > > INSERT INTO ... SELECTs if you deferred foreign key checks first. > > Sometimes, in order to rescue data from an overfull table (because the > cleanup-job had died and a DELETE would take too long) I've done the > following: > > - start transcation > - rename bad table > - receate the table (CREATE TABLE x LIKE would work) > - INSERT INTO ... SELECT good data into the recreated table from the > renamed table > - drop renamed table > - end transaction > > This works even when the system is up and running, on production servers. > > HM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Django Error Display Page
class EasyWin(object):
def process_exception(self, request, *args, **kwargs):
if not request.is_ajax(): return
impot traceback
return HttpResponse(traceback.format_exc())
On Jun 10, 1:11 pm, Daniel Watkins
wrote:
> On Thu, Jun 09, 2011 at 08:31:44PM -0700, Valentin Golev wrote:
> > What I'd really like is a stacktrace in a plain text in the html
> > commentary ("") on the very top of the page.
>
> I've openedhttps://code.djangoproject.com/ticket/16227with patch
> attached.
>
> Regards,
>
> Dan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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.
Re: ImportError catching in urlresolvers.py
This is currently a problem all over in the Django codebase, and I'd
love to see a generic/reusable approach at solving this everywhere.
On Jun 14, 1:19 pm, Michael Blume wrote:
> In RegexURLPattern._get_callback, we attempt to fetch the callable named by
> the URL pattern, and catch a possible ImportError if this fails. If so, we
> raise ViewDoesNotExist.
>
> try:
> self._callback = get_callable(self._callback_str)
> except ImportError, e:
> mod_name, _ = get_mod_func(self._callback_str)
> raise ViewDoesNotExist("Could not import %s. Error was: %s" %
> (mod_name, str(e)))
>
> The trouble is that the view we're importing may indeed exist, and may
> *itself* make a failed import (say of a model, or some library function), in
> which case ViewDoesNotExist becomes a badly misleading exception name, and
> the resulting traceback is cut unhelpfully short. I've noodled a bit trying
> to come up with a patch, but been stymied by the lack of information bubbled
> up by python's ImportError extension (at least in 2.6).
>
> Personally, I don't think catching ImportError/raising ViewDoesNotExist adds
> much value (we do catch it once in contrib/admindocs/views), so unless we
> can come up with a way to ensure that it only triggers when the top-level
> import fails, I'd recommend eliminating it.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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.
Re: required=True for BooleanFields
I'm not suggesting changing the behavior (again due to the compatibility concerns), but I completely agree with the original poster(s). Also, in my experience it's a much less common case that you're wanting an "I agree" checkbox in your form, versus a "Boolean" field which can be positive or negative. On Jun 16, 9:34 pm, Tai Lee wrote: > This has been discussed many times in the past. For better or worse, > we're stuck with the current behaviour for backwards compatibility. > > I personally think it's better this way. Without this behaviour, it > would be a PITA to implement forms that have a "required" boolean > field (must be ticked) without repeating yourself constantly by > writing custom validation for those fields. Most forms I work with > have a "Yes, I have agreed to the terms and conditions" or "Yes, I > want to receive emails from XYZ" type fields. > > If your boolean fields are not "required" (as per the definition in > Django forms, "must be ticked"), why can't you just put > `required=False` in your form? > > I'd try to avoid patching your local Django with a change like this > unless absolutely necessary so that you can cleanly upgrade and don't > end up writing code that does the opposite of what everyone else > expects. > > Cheers. > Tai. > > On Jun 17, 5:14 am, Michael Blume wrote: > > > > > > > > > In Django BooleanFields, the required flag is used to mean that the field > > must be checked for the form to validate. Required is True by default for > > all Fields, so this is the default behavior. > > > I strongly suspect that this violates principle of least surprise for most > > people including Boolean Fields in forms. It did for me. > > > I've patched it in my local Django checkout. I realize this is a > > backwards-incompatible change, so it might not be eligible for trunk any > > time soon, but FWIW, here's the patch: > > > --- i/django/forms/fields.py > > +++ w/django/forms/fields.py > > @@ -606,6 +606,11 @@ class URLField(CharField): > > class BooleanField(Field): > > widget = CheckboxInput > > > + def __init__(self, *args, **kwargs): > > + if not args and 'required' not in kwargs: > > + kwargs['required'] = False > > + return super(BooleanField, self).__init__(*args, **kwargs) > > + > > def to_python(self, value): > > """Returns a Python boolean object.""" > > # Explicitly check for the string 'False', which is what a hidden > > field -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
initial_data and post_syncdb conflicts
We've been working on switching our test suite to use some new "super
fixtures", which are really just global, test-only initial_data style
fixtures. To implement this we attach to the post_syncdb, and set a
runonce-per-db flag (since it seems to be the only available signal),
but we hit some issues with the way the process flow works for flush/
syncdb.
Basically, all the code goes:
{flush,syncdb} => {db actions} => emit post_syncdb => load
initial_data
In order for our hooks to work, we had to reorder load initial_data so
that it happened before the syncdb signal was sent out. The reason
being is that some of our fixture data relied on foreignkeys which
were present in initial_data.
My question is, would it be reasonable to change this upstream (both
in syncdb and flush), or would it be better to possibly add some
additional signals?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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.
Re: initial_data and post_syncdb conflicts
initial_data gets populated whenever you migrate your database (e.g.
syncdb, reset, etc). These, at least in my opinion, can be see as
default database fixtures that you should be allowed to have an
expectation of their existence. Gven that, we have *test only*
fixtures (not initial_data) that get loaded that reference (with
foreign keys) rows that are created in the initial_data load.
On Aug 19, 1:12 am, Stephen Burrows
wrote:
> Perhaps I'm missing something... initial_data is "test-only", right?
> As opposed to other fixtures which should always be loaded? Then why
> would the other fixtures rely on the initial_data?
>
> On Aug 18, 4:15 pm, David Cramer wrote:
>
>
>
>
>
>
>
> > We've been working on switching our test suite to use some new "super
> > fixtures", which are really just global, test-only initial_data style
> > fixtures. To implement this we attach to the post_syncdb, and set a
> > runonce-per-db flag (since it seems to be the only available signal),
> > but we hit some issues with the way the process flow works for flush/
> > syncdb.
>
> > Basically, all the code goes:
>
> > {flush,syncdb} => {db actions} => emit post_syncdb => load
> > initial_data
>
> > In order for our hooks to work, we had to reorder load initial_data so
> > that it happened before the syncdb signal was sent out. The reason
> > being is that some of our fixture data relied on foreignkeys which
> > were present in initial_data.
>
> > My question is, would it be reasonable to change this upstream (both
> > in syncdb and flush), or would it be better to possibly add some
> > additional signals?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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.
Dynamic Fields in Models
I came across the need today to modify PhoneNumberField to allow for International phone numbers. Doing so, it occurred to me, it'd be very useful just to be able to swap out my phone number field with the localized version based on whatever country was selected. Has any thought/real-use happened in regards to doing something along these lines? I could see many use-cases where this could happen, but a lot of it in relation to internalization. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: intcomma and locale
I received a nice lecture when I asked "why doesn't Jinja (a template engine I use as an alternative to Django) include an intcomma filter, its very useful" on the fact that intcomma is a [insert a bunch of negative remarks here] name for the filter, and it's an internationalization concept, not a standard. I still agree, it's extremely useful, but I believe it could be renamed, and (if it doesnt) default to the current locale's correct separator. On Jun 3, 8:11 am, Flavio Curella <[EMAIL PROTECTED]> wrote: > Hi, > > Do you think intcomma should use localized separator? If so, would > still be 'intcomma' a correct name (after all, it wouldn't use commas > in, for example, Italian)? > > I already wrote a patch which gives intcomma an optional argument. But > I don't know if I should submit a ticket about intcomma or about a new > filter in humanize. > > Thanks, > Flavio Curella. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
I suppose I'll chime in here since we actually wrote master/slave replication code on Curse. Our approach: - read_cursor and write_cursor exist. write_cursor is what cursor would point ot. - get queries all use the read cursor - saves all use the write cursor - we had a list of database connections, which stored the same settings, just in a tuple format - reading I believe used something like itertools.cycle but I can't honestly say without looking at the code Beyond this, the database itself should handle writing the objects to the slaves. Django shouldn't even bother. In regards to multiple databases in general. it is my feeling that even if it is not good practice, Django _NEEDS_ to support a model being attached to a database other than the default. So if you have mydjango_blogs, and mydjango_forums databases, my Forum model always goes to the write db when it queries, and same for blogs. I myself like a Meta solution to this as it makes sense. In MySQL as well, you can optimize things, so that if they use the same connection, you can just query on that database. It's select X from mydatabase.mytable. I'm not sure if something similar exists in other database engines. On Jun 16, 9:05 pm, mengel <[EMAIL PROTECTED]> wrote: > On May 22, 9:59 am, Simon Willison <[EMAIL PROTECTED]> wrote: > > > 1. Replication - being able to send all of my writes to one master > > machine but spread all of my reads over several slave machines. > > 2. Sharding - being able to put User entries 1-1000 on DB1, whereas > > User entries 1001-2000 live on DB2 and so on. > > It seems to me this isn't beyond doing in the current setup; but I'm > not sure I understand > the underlying mechanism well enough. For case 1, you need an object > class that > creates two (or more) (apparently identical) Models.model classes, one > attached to each database, based on the field types declared as class > variables: > * on searches, it picks one of the model classes to search > * on saves, saves the same data to each object class in turn > > For case 2, it's very similar, except you need to run the query on all > sides (unless > you can tell it should only go to one) building a chained query-set > union type to hold > the result, and for saves pick the right model to save to based on > the condition. > > In each case, the underlying models have to be tied to the right > databases, but this can > be done using the mechanism in the proposal so far.. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Community representation, or, #django user "Magus-" needs to go far away
I'll agree Magus is harsh, but he's also helpful, and this isn't the place to discuss this :) On Jul 1, 11:40 am, "Rajeev J Sebastian" <[EMAIL PROTECTED]> wrote: > +1 to Tom, though magus > > On Tue, Jul 1, 2008 at 7:34 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves > > <[EMAIL PROTECTED]> wrote: > > >> why should he be more polite? He follows the policy of 'teaching to > >> fish' rather than spoonfeeding. I have several times got flamed by > >> him for getting impatient and giving the answer. I would say that he > >> is the single most important person in the channel. He has even taken > >> the trouble of writing a script whereby he can generate almost > >> instantaneous references to the *relevant* docs. It is easy to give > >> direct answers - difficult, irritating and time consuming to 'teach > >> to fish'. Let him be as rude as he wants, as long as he is there. > > > Stepping back for a moment from the way I approached this issue — > > which I readily admit was the wrong way to do it, and which I > > apologize to the community for — and the parties in question, I'm > > concerned with the general sentiment expressed in this thread. It is > > quite understandable to be grateful to someone for performing a > > difficult task; it's another thing to allow that gratitude to mute > > necessary criticism. I think there's room in our community for both > > charity *and* civility; if we can improve, we *should* improve. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms rendering and MVC pattern
I personally like the rendering methods being attached to the form, as they don't make sense as a universal template filter/tag. I do however, use a filter as "as_p" doesn't do much :) On Jun 28, 8:33 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2008-06-28 at 06:12 -0700, ionut wrote: > > I do'nt consider to be a MVC good pattern rendering form html inside > > newforms class. > > A form class is purely presentational, so there's no "MVC" (or whatever > you might want to call it -- you can't do MVC on the web, after all) > violation going on in that respect. > > > I think a better proach while rendering html forms is to use a > > template file > > [...] > > So do that. There's nothing stopping you from implementing whatever > method you like on forms. I've done similar things for some of my forms, > reading the presentation layout from a template for rendering. It's not > necessarily a universal solution, since it requires quite a lot of logic > in the template to handle all cases and can consequently get very messy, > so sometimes the trade-off of placing HTML in the Python code leads to > something that's easier to manage. Sometimes, though, your approach is > easiest (it does keep the HTML and the Python separate, for example). > > Remember, a form is just a class on which you call methods in your > template. So implement the presentation method you call however you > like. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Call for testing: streaming uploads (#2070)
I haven't read this over in too much detail yet (I just auto ignore the 10k trac emails about it :P) but a few concerns: - Is there a setting (e.g. settings.py) to restrict the maximum file size in an upload? - For test suites couldn't you while (xrange(n)) pass /dev/random or whatever to make a larger file upload simulation? On Jul 1, 3:56 pm, Jonathan Hseu <[EMAIL PROTECTED]> wrote: > I mentioned some issues to Michael Axiak a while back, and he said > he'd get to them but that I should post them on the 2070 ticket. I > forgot to post them, so he might've missed it before it was committed > to SVN. I made a new ticket for them: > > http://code.djangoproject.com/ticket/7593 > > A quick overview of the issues: > 1. The temporary file is not deleted in many cases. This is a problem > when handling large uploads. The fix is to use tempfile.TemporaryFile > instead of uploadhandler.py's TemporaryFile (why does it even > exist?). tempfile.TemporaryFile unlinks the file immediately after > creation. uploadhandler.py's TemporaryFile also does not act > completely like a file object, which would be fixed by moving to > tempfile.TemporaryFile. > 2. An extremely common use-case requires direct access to the file > object. Both upload handlers (memory & temporary file) have file > objects that UploadedFile can return, so why not put it in the API? > > Thanks, > Jonathan Hseu > > On Jun 26, 2:14 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> > wrote: > > > Hi folks -- > > > As far as I'm concerned, #2070, adding large streaming uploads, is > > done. I'd like to get some public kicking-of-the-tires before I push > > the change to trunk (which won't happen before Tuesday: I'm taking a > > long weekend off). > > > You can get the code either from my git repository > > (git://djangoproject.com/django; branch "2070-streaming-uploads") or > > as a patch against [7728] > > fromhttp://code.djangoproject.com/attachment/ticket/2070/2070-r7728.patch. > > There's also a > > gitweb:http://code.djangoproject.com/git/?p=django;a=shortlog;h=refs/heads/2 > > > Documentation of the new features is can be found in > > ``docs/upload_handling.txt`` > > orhttp://code.djangoproject.com/git/?p=django;a=blob_plain;f=docs/uploa > > > I need a hand on the following things: > > > * Running the test suite -- coverage is quite good now, but I've only > > been able to test on a limited set of OSes/DBs. Looks elsewhere just > > in case, very good. > > > * Real-world tests -- try uploading huge files. I can't really > > simulate enormous files in the test suite, so someone willing to > > upload a bunch of porn^H^H^H^H video would help. > > > * Custom upload handlers: write some, and let me know how it goes. > > > Also, anyone with better git-fu than me might want to try merging this > > into the newforms-admin branch to see if anything crazy blows up; I > > don't have any idea how this'll affect that (though I hope it won't). > > > Please report any problems back here; the ticket is nearly impossible > > to follow now. > > > Thanks! > > > Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MySQL BINARY WHERE Clauses
I don't want to seem harsh Karen, but I understand the differences in the user lists. This is not an issue with how I'm using Django, it's an issue with what Django's doing. This may be better suited as a ticket, but I'd rather not end up with another trac ticket that emails me daily because it turns into a discussion on how it should work. In summary, this is, in fact, a problem in the Django codebase, and need's addressed, as it's causing issues for myself, and probably a number of other people, even if they haven't realized it yet. On Tue, Jul 22, 2008 at 1:25 AM, Karen Tracey <[EMAIL PROTECTED]> wrote: > On Tue, Jul 22, 2008 at 2:13 AM, David Cramer <[EMAIL PROTECTED]> wrote: > >> >> I was using utf8_general. I'm swapping to utf8_bin to attempt to fix >> it, but binary encodings cause problems as well with unique indexes or >> something similar (can't remember what my test case was from Curse). >> >> On Jul 22, 12:59 am, David Cramer <[EMAIL PROTECTED]> wrote: >> > SELECT * FROM `spider_discoveredlink` WHERE >> > `spider_discoveredlink`.`url` = BINARY 'http://www.starcraft.org/maps/ >> > scums/multiplayerums/multiplayerrpg/Shinhwa+2008'; >> > >> > is NOT the same as >> > >> > SELECT * FROM `spider_discoveredlink` WHERE >> > `spider_discoveredlink`.`url` = 'http://www.starcraft.org/maps/scums/ >> > multiplayerums/multiplayerrpg/Shinhwa+2008'; >> > >> > Just FYI, you are breaking all of my queries :) >> > > This topic would seem better suited to django-users, since you are not > discussing developing django, but using it. You are also not really > providing enough information to help you. I do not know which of those > queries you actually want, what Django lookup methods you have tried to > achieve the results you are looking for, etc. If you follow up on > django-users with specifics of what Django code you are running, what > results you were hoping for and what you are seeing instead, someone might > be able to suggest something. > > Karen > > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MySQL BINARY WHERE Clauses
Sorry, to be more clear, that is an *exact* match on what is in the database, but using the BINARY form does not return the result. On Tue, Jul 22, 2008 at 1:45 AM, Malcolm Tredinnick < [EMAIL PROTECTED]> wrote: > > > On Tue, 2008-07-22 at 01:29 -0500, David Cramer wrote: > [...] > > In summary, this is, in fact, a problem in the Django codebase, and > > need's addressed, as it's causing issues for myself, and probably a > > number of other people, even if they haven't realized it yet. > > So let's start off by assuming that we understand the two are different. > If they were the same, it wouldn't have been necessary to make any > changes. Let's also assume you've read > > http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#ExactComparisonsRespectCaseInMySQLwhich > is the relevant change. > > Now, given the purpose of that change, what is the problem you perceive > here and why isn't it fixed by moving to an iexact query if you want the > non-binary form of matching? > > You haven't actually reported a problem yet. You've noted that two > non-identical queries behave differently. That's usually the case with > two different queries. > > Regards, > Malcolm > > > > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
MySQL and Autocommit
Recently I noticed a bunch of queries I was executing by hand (one's which the ORM didn't support) were not being committed. I dug into the docs, and it clearly states that the default transaction mode is autocommit, and mysql's default transaction mode is autocommit. So, my question is, what's going on? I ended up doing set autocommit=1 at the beginning of the queries, but this is a pretty big gotcha. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
Really I'm stuck at an architectural point. I have database validation and synchronization done, and the admin is working. What is left is more or less handling relatedfield lookups. The issue is, that field's are designed to reference more than one field, so it's a tough design deicision to make on how that should be approached. On Wed, Aug 27, 2008 at 5:23 PM, Rock <[EMAIL PROTECTED]> wrote: > > Any progress on this patch David? I would be happy to take a look at > whatever you have and perhaps help out with completing the patch. > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
What I had briefly discussed with malcom was using ordered tuples but
switching up the defaults to use actualy field lookups.
MyModel.objects.get(pk=(1, 2)) or MyModel.objects.get(foo=1, bar=2)
If we could come up with some design for multi-column fields I'm wiling to
put in the work.
On Wed, Aug 27, 2008 at 6:15 PM, Alberto García Hierro <[EMAIL PROTECTED]>wrote:
>
>
> El 28/08/2008, a las 0:27, David Cramer escribió:
>
> > Really I'm stuck at an architectural point.
> >
> > I have database validation and synchronization done, and the admin
> > is working.
> >
> > What is left is more or less handling relatedfield lookups. The
> > issue is, that field's are designed to reference more than one
> > field, so it's a tough design deicision to make on how that should
> > be approached.
>
> I think the best (and the only one right) solution involves adding
> multicolumn fields to Django and doing lookups with some syntax like
> Model.objects.get(pk=('foo', 1)). There are other hackish approaches,
> like using hash(tuple(pk[0], pk[1], ..., pk[n])) as foreign key, that
> could work. However, I won't rely on them, since I'm not sure if
> hash() implementation is guaranteed to be kept as is.
>
> On other related point, what's the status of multicolumn fields?
>
> Regards,
> Alberto
>
> >
>
--
David Cramer
Director of Technology
iBegin
http://www.ibegin.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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Composite Primary Keys
I'm not quite sure how that relates to Composite Primary Keys? A ForeignKey would point to multiple internal fields, but it should look like it's a single field. At the same time, this would open up the possibility for Composite Foreign Keys, which would mean it could point to multiple public fields. On Thu, Aug 28, 2008 at 5:36 PM, Rock <[EMAIL PROTECTED]> wrote: > > To be clear, the syntax is: > > myfkey = models.ForeignKey(SomeClass,to_field="id") > > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: primary_key for ImageField does not work any more
This sounds like a bug. I would submit a ticket for it.
On Sep 1, 6:42 am, Jochen Voss <[EMAIL PROTECTED]> wrote:
> Hello,
>
> with Django 0.96 I used a model which contained the following field:
>
> class ImageFile(models.Model):
> [...]
> fname = models.ImageField(upload_to="images", primary_key=True,
> width_field="width", height_field="height")
> [...]
>
> When trying to convert this to the current version of Django, I got the
> following error message for this line:
>
> [...]
> File "/home/voss/s2/s2/images/models.py", line 96, in
> class ImageFile(models.Model):
> File "/home/voss/s2/s2/images/models.py", line 107, in ImageFile
> width_field="width", height_field="height")
> File
> "/var/lib/python-support/python2.5/django/db/models/fields/files.py", line
> 240, in __init__
> FileField.__init__(self, verbose_name, name, **kwargs)
> File
> "/var/lib/python-support/python2.5/django/db/models/fields/files.py", line
> 129, in __init__
> raise TypeError("'%s' is not a valid argument for %s." % (arg,
> self.__class__))
> TypeError: 'primary_key' is not a valid argument for 'django.db.models.fields.files.ImageField'>.
>
> It seems that primary_key=True is no longer allowed for ImageField
> fields. I looked
> athttp://code.djangoproject.com/wiki/BackwardsIncompatibleChanges
> but did not find any information about this.
>
> I am not sure whether this change is intended or a bug, but I think it
> should either be mentioned in the list of backward incompatible
> changes or should be allowed again.
>
> I hope this helps,
> Jochen
> --http://seehuhn.de/
>
> signature.asc
> < 1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Composite Primary Keys
For anyone who's interested, it'd be great to meetup at DjangoCon to go over a good design approach to composite fields. On Sep 2, 2:44 pm, Rock <[EMAIL PROTECTED]> wrote: > One use case for Composite Primary Keys is for setting up database > partitions. In my case I am using Range-Hash partitions with the range > determined by an IntegerField called "ISOweek" and the hash working > off of the "id" field supplied by Django. To allow this partitioning > to work, the primary key must be a composite primary key incorporating > the "ISOweek" and the "id" fields. My versions of the sqlreset and > reset management functions do this while also ensuring that "id" is > marked as unique even though it is not the primary key. This allows a > ForeignKey pointed at my partitioned model to work correctly by > setting "id" as the to_field. (If "id" is not set as unique, Django > and/or the database will fail in its' attempt to set up the full > foreign key relationship.) > > The initial version of Composite Primary Keys should not preclude this > scenario, however full support for setting up and managing partitioned > models need not be included at this time. (I plan to help add that > later.) The interesting point is that support for related fields for > the Composite Primary Key is not required in order to support this > particular use case. > > Rock > > On Aug 28, 8:05 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > > > I'm not quite sure how that relates to Composite Primary Keys? > > > A ForeignKey would point to multiple internal fields, but it should look > > like it's a single field. At the same time, this would open up the > > possibility for Composite Foreign Keys, which would mean it could point to > > multiple public fields. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
This is one of those things that I really need to get hammered out (for our platform). I'm willing to do all the work, but I need a design around it to where the patch won't get rejected :) On Sep 3, 11:08 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Tue, 2008-09-02 at 22:02 -0700, David Cramer wrote: > > For anyone who's interested, it'd be great to meetup at DjangoCon to > > go over a good design approach to composite fields. > > Take notes. There's going to be a lot going on at DjangoCon (including > celebrating), so there will be a group who are putting off thinking > about this until quieten down who'll likely be busy throughout the > weekend. In a few weeks we can start looking at this more concretely on > the list and working out how it might fit into the whole. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Templates extending themselves cause infinite recursion
Does the error message pretty easily let you figure out what's wrong?
On Aug 31, 1:38 pm, Martin Ostrovsky <[EMAIL PROTECTED]>
wrote:
> Now I'm not sure if this is a bug worth squashing or more a case of if
> you're dumb, you deserve what you get but ... I erroneously extended a
> template with itself (it was a typo, that's how I stumbled upon it).
> So say you have a template called home.html and had the following in
> it:
>
> {% extends 'home.html' %}
>
> This causes infinite recursion as
> django.template.loader_tag.ExtendsNode.get_parent is repeatedly called
> until Python says that's enough, and crashes. This also happens if
> template A extends template B and template B extends template A.
>
> Again, these two scenarios make no sense at all and don't represent
> logical use cases. I'm just wondering if it's something we want to
> address?
>
> - Martin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: multi-column field support (#5929)
Ya, depending on how support is planned I may be able to remove some of the composite pk hacks. FYI the last patch I threw up didn't work in all areas, but I do have it running on our staging environment now without issues (so far). The code is only very slightly changed though. On Sep 9, 8:10 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote: > On Tue, Sep 9, 2008 at 4:08 PM, Malcolm Tredinnick > > <[EMAIL PROTECTED]> wrote: > > I've got most of it done locally, but I need to port it forwards to > > match recent changes on trunk > ... > > if you haven't seen anything in a week, ping me again. > > Thanks, that's great to hear. > > -Justin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Fields
I think that will work Malcom. One thing we'll need to deal with, is .name, .attname, etc on these. It should act the same way on the pk as it does on the multi-column field (because after all, this will be just a wrapper). Right now .pks is just an alias for .pk.as_tuple or something. I had it throwing errors if you tried accessing .pk.name if there were multiple fields in it, as name is the field name, and the field name becomes multiple. I will post up what I have done later tonight. On Sep 16, 9:36 am, Rock <[EMAIL PROTECTED]> wrote: > Malcolm, > > I strongly concur with the proposed API. It looks like it can be used > to implement future RangeHash partitioning support. Consider: > > I have a model to be partitioned that has an IntegerField that will > become the range partitioning value: > > week = models.IntegerField() # 1 to 53 depending on the week of > creation > > The hash partitioning value is a field that works precisely like "id": > > hash_id = models.IntegerField( auto_everything=True ) # (I made > "auto_everything" up as I am not sure precisely what parameters I need > to set in order to make this happen.) > > Now I can create my RangeHash partitioning primary key with a > compositeField: > > range_hash = models.CompositeField( hash_id, week, primary_key=True ) > > What I am doing today for my partitioned models is to use the > automatically generated "id" field, but that looks dicey with the > CompositeField since you can't do this: > > range_hash = models.CompositeField( id, week, primaryKey=True ) > > since "id" doesn't exist yet and, by designating this CompositeField > as the primary key, id won't be generated. Rather than try to special > case this situation, ensuring that I can create a field that works > precisely like "id" by hand and then using that seems to be the way to > go. > > Rock --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Denormalisation, magic, and is it really that useful?
If you're not doing denormalization in your database, most likely
you're doing something wrong. I really like the approach that is
offered here.
For me, personally, it would be great if this could accept callables
as well. So you could store the username, like so, or you could store
a choices field like:
field = models.IntegerField(choices=CHOICES)
denorm = models.DenormField('self', 'get_field_display') # which
would rock if it was .field.display ;)
You could also make it somehow accept querysets or something similar
for things like count(). I see a lot of possibilities and am a bit
disappointed I didn't come up with something this easy for my use-
cases.
+1 from me!
On Sep 22, 7:00 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 23, 12:21 am, "Justin Fagnani" <[EMAIL PROTECTED]>
> wrote:
>
> > In my experience at least, denormalization occurs
> > a lot and leaves a lot of room for mistakes, so it's something a
> > framework should handle if possible.
>
> Just so it's on the record, I'd like any denormalisation tools in
> Django to include a mechanism for re-syncronizing them should
> something go awry (like direct updates being applied to the database
> without keeping the denormalised fields in sync). This mechanism could
> then be exposed as a ./manage.py command which could be called
> periodically to verify and fix any incorrect data.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Inner imports in core code
I was digging through some code today, and I noticed imports are
happening within a lot of functions. It was my knowledge that it works
like so:
import in a function is the same as ruby's load or php's include --
its executed everytime the function is
import in a module outside a function is like ruby's require or php's
require_once -- its loaded and cached in memory
If this is the case, then this seems like an unneeded performance hits
in many situations.
An example off hand, is the get_hexdigest() function of the auth
module:
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/models.py
It waits to import the hashing methods, which if you're in a pooled
environment, it could save a lot by onlying importing it once,
correct?
Here's my benchmark script:
import timeit
def without_import():
pass
def with_import():
import random
def main():
print "Without an inner import:",
print timeit.Timer("module_loading.without_import()", "import
module_loading, random").timeit()
print "With an inner import:",
print timeit.Timer("module_loading.with_import()", "import
module_loading").timeit()
if __name__ == '__main__':
main()
And the result:
Without an inner import: 1.28283500671
With an inner import: 5.402146101
If everyone's in agreement, I'd like to approach correcting this in
Django
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Denormalisation, magic, and is it really that useful?
I just wanted to touch on this point:
models.IntegerField(default=0) does not translate to INT(11) default
0; in SQL :)
Django doesn't nescesarily try to interact with the database properly
when it should, because it requires too much thinking (and more code
that hasn't been written).
I would say ignore triggers on the DB level, until they've been
written in the framework.
On Sep 23, 7:44 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> This appears to be a proposal to re-implement triggers inside Django.
>
> I can see there are benefits if the underlying DB platform won't support
> triggers, but wouldn't triggers be the preferred solution when they're
> available? That way there is no chance that changes can be made outside
> the scope of the denormalization, and hence no need to recompute the
> denormalized values.
>
> regards
> Steve
>
> Andrew Godwin wrote:
> > David Cramer wrote:
>
> >> If you're not doing denormalization in your database, most likely
> >> you're doing something wrong. I really like the approach that is
> >> offered here.
>
> >> For me, personally, it would be great if this could accept callables
> >> as well. So you could store the username, like so, or you could store
> >> a choices field like:
>
> >> field = models.IntegerField(choices=CHOICES)
> >> denorm = models.DenormField('self', 'get_field_display') # which
> >> would rock if it was .field.display ;)
>
> >> You could also make it somehow accept querysets or something similar
> >> for things like count(). I see a lot of possibilities and am a bit
> >> disappointed I didn't come up with something this easy for my use-
> >> cases.
>
> > The key is making sure you can listen for changes on whatever's at the
> > other end of your denormalisation. With my current snippet, it listens
> > for a save on the model the foreignkey points to, then checks for the
> > right ID; if we start accepting random querysets, then there has to be a
> > way to resolve that back to conditions the signal listener can understand.
>
> > Still, with an
> > AggregateField(Sandwiches.filter(filling="cheese").count()) it's still
> > possible to work out that you want to listen on the Sandwiches model,
> > and you could then fall back to re-running the count on every Sandwich
> > save, even if it ends up not having a cheese filling.
>
> > So, I think the best approach would be one to replicate fields (like my
> > current DenormField; perhaps call it CopyField or something) and one to
> > cache aggregates (an AggregateField, like above).
>
> > Simon Willison wrote:
>
> >> Just so it's on the record, I'd like any denormalisation tools in
> >> Django to include a mechanism for re-syncronizing them should
> >> something go awry (like direct updates being applied to the database
> >> without keeping the denormalised fields in sync). This mechanism could
> >> then be exposed as a ./manage.py command which could be called
> >> periodically to verify and fix any incorrect data.
>
> > Yes, this I very much agree with. The reason you always layer this stuff
> > on top of a pre-normalised database is because you can then rebuild the
> > data after playing with it externally.
>
> > Doing so shouldn't be too much of a problem; have a management command
> > that loads the models, and then just executes the update method on each
> > of the denormalisationalish fields.
>
> > Justin's idea of lazy updating is interesting, and probably quite doable
> > (as well as what most people will want by default on aggregate queries).
>
> > I'm also hoping any kind of aggregate denormalisation will work with any
> > future extended aggregate support, but if the field just takes a normal
> > QuerySet, that might Just Work™.
>
> > Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Denormalisation, magic, and is it really that useful?
Denormalized for me personally happens a LOT when it's not just a
simple foreign key. Maybe I want to store a many to many field as
name,name,name in a column (tags). We're already inside of Django so
it should already be available (it's not going to be much slower than
it is executing the subquery in sql to get the denormalized output).
On Sep 23, 4:19 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 23, 2008 at 12:52 AM, David Cramer <[EMAIL PROTECTED]> wrote:>
> > For me, personally, it would be great if this could accept callables
> > as well. So you could store the username, like so, or you could store
> > a choices field like:
>
> > field = models.IntegerField(choices=CHOICES)
> > denorm = models.DenormField('self', 'get_field_display') # which
> > would rock if it was .field.display ;)
>
> I think denormalizing with callables is a very different thing than
> denormalizing with expressions that can be evaluated by the database.
> Not that they both aren't worth supporting, but db-level expressions
> are going to be far easier and more efficient to validate and update
> in bulk - no looping in Python, just executing SQL. In this case, I
> think your example would be better suited as an FK, for denorm
> purposes.
>
> Callables would be useful for something more complicated like
> abstracting auto_now to not be limited to dates, that is allowing a
> field value to be set by a callable on save, not just create, for any
> field type.
>
> On Tue, Sep 23, 2008 at 2:42 AM, Andrew Godwin <[EMAIL PROTECTED]> wrote:
> > Still, with an
> > AggregateField(Sandwiches.filter(filling="cheese").count()) it's still
> > possible to work out that you want to listen on the Sandwiches model,
> > and you could then fall back to re-running the count on every Sandwich
> > save, even if it ends up not having a cheese filling.
>
> I'm not sure I like the idea of accepting arbitrary QuerySets. It
> could just be my point-of-view, but I see automatic denormalization
> and aggregation as intimately tied, where a denormalized field is just
> a declarative aggregate expression that's optionally cached in a
> column. I think this makes it easy to understand and document, since
> aggregation queries and calculation fields would support the same
> features, and it also allows the implementation to share a lot with
> aggregates. It's also better in terms of storing and updating a
> calculation: you can calculate on reads or writes for N objects in one
> query without N subqueries, though it may involve a lot of joins.
>
> > So, I think the best approach would be one to replicate fields (like my
> > current DenormField; perhaps call it CopyField or something) and one to
> > cache aggregates (an AggregateField, like above).
>
> I'd also be hesitant to have two separate fields for these cases,
> since copying a related field value is just a simple SQL expression. I
> think the same calculation field could be used for both, by assuming a
> string is a field name:
>
> name = CalculationField('user.name')
>
> or by using F expressions:
>
> name = CalculationField(F('user.name'))
>
> Another approach to calculations, that doesn't necessarily involve
> denormalization, would be to use views. Russell talked to me a bit
> about this at djangocon, and I think the idea was that if you solve
> basing models on views (Isn't it actually possible now? Maybe we need
> read-only fields), and then have view creation support in the ORM,
> then calculation fields can be implemented with views. I see that
> un-stored calculations are re-implementing views, but I don't know
> enough about views to know whether they have some performance
> advantages over embedding the calculation in a query.
>
> -Justin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Optimizations on templates
Just use Jinja if you want faster template rendering ;)
In all seriousness though, this sounds like an awesome optimization
which I think should be fair game for 1.1.
On Sep 24, 6:28 pm, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> Am 25.09.2008 um 00:39 schrieb Manuel Saelices:
>
>
>
> > It's a different aproach. I consider my cache attempt a optimization
> > like URL dispatcher cache, without considering django cache system,
> > like url resolvers cache, _join_cache in orm or other many cases.
> > Also, I'm not sure that #6262 consider the inheritance problem (look
> > at copy.deepcopy(self.get_parent()) line in my patch).
>
> Your approach requires django.template.loader to be reloaded whenever
> a template changes, which probably means a server restart.
> This is different from other module level caches in django because
> those are only invalidated if other python modules are modified
> (urls.py or models.py).
>
> I'm not familiar with either patch and I not shure I understand the
> problem you tried to fix with that deepcopy().
> Anyway, from a quick look: you damaged {% extends var_name %}, and
> this new `dirs` argument to `get_template()` should be part of the
> cache key, and what does `from_child` do?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Denormalisation, magic, and is it really that useful?
CopiedField sounds a bit off, but otherwise I like the proposed additions.
On Thu, Sep 25, 2008 at 8:08 AM, Andrew Godwin <[EMAIL PROTECTED]>wrote:
>
> David Cramer wrote:
> > I would say ignore triggers on the DB level, until they've been
> > written in the framework.
> >
>
> Yes, this was essentially my point earlier; triggers would be nice to
> have from a consistency point of view, but it will be easier and quicker
> to reimplement them in Python, not least because it allows more complex
> functionality to be put straight in if we want it in the future. Then,
> we can always extend it so that some types of fields are implemented
> directly as triggers if you want once the API is settled.
>
> With all this in mind, my API proposal would be something like this:
>
> A CopiedField, called like so: user_username =
> models.CopiedField("user", "username") [here, "user" is the name of
> the ForeignKey to link through]
>
> An AggregateField: post_count =
> models.AggregateField(Post.objects.filter(visible=True), "count")
>
> The CopiedField essentially works how my current DenormField does, but
> using a foreignkey to avoid you having to specify both it _and_ the
> model if you have more than one to the same model (a reasonable amount
> of the DenormField code is just for finding which foreignkey to link
> through, anyway)
>
> The AggregateField takes a simple queryset (from which it can extract
> the model to hook a signal onto), and whenever something in the queryset
> is saved (so, either an extra select on each save to see what items are
> in the queryset, or just updating the aggregate every time - possibly
> with either selectable, since the cost might be higher on either), and
> it also takes the function to run on the set - either a builtin name
> like "count" here, or an actual function which takes a queryset and
> returns a result (in this situation the type of the underlying column
> will also have to be specified).
>
> This should probably cover most cases, and has the advantage of people
> being able to specify their own in-python aggregate functions (such as
> working out the standard deviation of the users' ages) if they tell us
> what kind of field to sling the result in.
>
> I'm happy to change the field names, too, CopiedField especially is a
> little clunky.
>
> Andrew
>
> >
>
--
David Cramer
Director of Technology
iBegin
http://www.ibegin.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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Sitemaps Memory Usage
We launched the new iBegin.com yesterday, and congrats to Django we've pushed over 600 req/s on a server shared with several other websites and daemons (including sphinx and memcached). BUT I noticed a huge issue right after launch with memory usage. It was randomly spiking (and staying) high. The problem was not only an issue of me not using select_related (although both would create equally deathly problems), but that there's no kind of generator expression usage in outputting the sitemap.xml. So, Yahoo, and Google, both hit our new sitemaps, which consist of 12 million entries (paged automatically, yay Django), and began eating up 5%-10% memory per sitemap. Now what do we do to solve this? I would think that it could be approached by somehow creating a file like object which could yield the urls (and then passing that to HttpResponse), but I'm not very familiar with how generators and file objects work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Sitemaps Memory Usage
Also in regards to this, using a template is overkill in my opinion. Especially if it's going to cause extra headaches. I'll try out your recommendation for now, thanks Malcolm. On Sep 28, 11:40 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2008-09-28 at 21:21 -0700, David Cramer wrote: > > [...] > > > So, Yahoo, and Google, both hit our new sitemaps, which consist of 12 > > million entries (paged automatically, yay Django), and began eating up > > 5%-10% memory per sitemap. > > > Now what do we do to solve this? > > > I would think that it could be approached by somehow creating a file > > like object which could yield the urls (and then passing that to > > HttpResponse), but I'm not very familiar with how generators and file > > objects work. > > Using generators for template output went very badly the last time we > tried it. There were all sorts of unexpected side-effects because > template rendering involves database accesses a lot of the time (due to > lazy evaluation of querysets). > > This type of memory usage hit for querysets that are only going to be > used exactly once is something I've been thinking about a bit over the > past few months. There's a case for some kind of "don't cache in memory" > attribute on querysets so that __iter__ won't populate the internal > cache. It's usually going to be far more dangerous than useful, but in > some situations it will be promising. When we branch off from 1.0.x and > trunk can take features again, I'll probably add something along those > lines. > > More specifically for your case, though, in a way that won't require > changing anything in core (and it on becomes a django-users type of > problem): try subclassing the GenericSitemap class and replace the > items() method to return a subclass of QuerySet with an overridden > __iter__ that doesn't cache the results in memory. So, you're going to > write something like this: > > SkinnyQueryset(QuerySet): > def __iter__(self): > # <-- your stuff here > > LessGenericSitemap(GenericSitemap): > def items(): > # <-- return QuerySet subclass here. > > I've left the details up to you, since it's just a matter of looking at > the existing code. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ManyToManyField with raw_id_admin
After miserably failing at making it possible to use a field with 10k choices, I've decided to take a new approach in the admin. Right now I'm writing up a widget which would take the m2m field (for raw_admin_fields) and output it just as it would a foreign key, except one input per line. This sounds like something that could be very useful in trunk, and I was curious as to the stance on this, or if it's somehow already done? :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ManyToManyField with raw_id_admin
It seems I was unbelievably blind and not seeing the spyglass icon on M2M fields. Please ignore me :) On Sep 29, 5:48 pm, David Cramer <[EMAIL PROTECTED]> wrote: > After miserably failing at making it possible to use a field > with 10k choices, I've decided to take a new approach in the admin. > > Right now I'm writing up a widget which would take the m2m field (for > raw_admin_fields) and output it just as it would a foreign key, except > one input per line. This sounds like something that could be very > useful in trunk, and I was curious as to the stance on this, or if > it's somehow already done? :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Query Cleanup in Admin History Log
It seems theres some issues, and this may go outside of the scope of
the admin history log (I didn't dig into the code).
1) It looks like it could use a .select_related('content_type') as
it's doing a query for every content type, repeatedly even.
2) It's adding an ORDER BY on the .get()-like queries which it is
doing. I'm concerned that this is a bug deeper inside the codebase
than just the history log.
http://www.pastethat.com/1AJeU
django-debug-toolbar informed me of this, talk about usefulness ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Query Cleanup in Admin History Log
Oh, and it's also selecting the user in that history log query and not
using it.. at least from the looks of it.
On Sep 30, 5:23 am, David Cramer <[EMAIL PROTECTED]> wrote:
> It seems theres some issues, and this may go outside of the scope of
> the admin history log (I didn't dig into the code).
>
> 1) It looks like it could use a .select_related('content_type') as
> it's doing a query for every content type, repeatedly even.
>
> 2) It's adding an ORDER BY on the .get()-like queries which it is
> doing. I'm concerned that this is a bug deeper inside the codebase
> than just the history log.
>
> http://www.pastethat.com/1AJeU
>
> django-debug-toolbar informed me of this, talk about usefulness ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Query Cleanup in Admin History Log
At least part of it seems to be fixed here:
http://code.djangoproject.com/attachment/ticket/9083/getAdminLogRelated.patch
On Sep 30, 5:24 am, David Cramer <[EMAIL PROTECTED]> wrote:
> Oh, and it's also selecting the user in that history log query and not
> using it.. at least from the looks of it.
>
> On Sep 30, 5:23 am, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > It seems theres some issues, and this may go outside of the scope of
> > the admin history log (I didn't dig into the code).
>
> > 1) It looks like it could use a .select_related('content_type') as
> > it's doing a query for every content type, repeatedly even.
>
> > 2) It's adding an ORDER BY on the .get()-like queries which it is
> > doing. I'm concerned that this is a bug deeper inside the codebase
> > than just the history log.
>
> >http://www.pastethat.com/1AJeU
>
> > django-debug-toolbar informed me of this, talk about usefulness ;)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
HttpResponse and file-like objects
I'm running into an issue when trying to pass a file-like object to
HttpResponse and telling it to label it as "application/xml"
def sitemap(request, sitemaps, section):
page = request.GET.get('p', 1)
fpath = os.path.join(settings.BASE_PATH + '/', 'cache/sitemap-%s-
%s.xml' % (section, page))
if not os.path.exists(fpath):
raise Http404
return HttpResponse(open(fpath, 'r'), mimetype='application/xml')
When added the mimetype, nothing gets sent to the browser. Removing it
solves the issue, but then it has an invalid content type.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: HttpResponse and file-like objects
Thanks Graham, I'll check that out.
I was going to file a ticket for this, but it seems streaming isn't
really "supported" anyways, so I had to change the approach.
On Sep 30, 8:19 pm, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> On Oct 1, 11:06 am, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > I'm running into an issue when trying to pass a file-like object to
> > HttpResponse and telling it to label it as "application/xml"
>
> > def sitemap(request, sitemaps, section):
> > page = request.GET.get('p', 1)
> > fpath = os.path.join(settings.BASE_PATH + '/', 'cache/sitemap-%s-
> > %s.xml' % (section, page))
> > if not os.path.exists(fpath):
> > raise Http404
>
> > return HttpResponse(open(fpath, 'r'), mimetype='application/xml')
>
> > When added the mimetype, nothing gets sent to the browser. Removing it
> > solves the issue, but then it has an invalid content type.
>
> Nothing to do with your specific problem, but knowing how you always
> want things to run as well as possible and how big your sitemap file
> apparently is, may interest you to look at wsgi.file_wrapper
> references in:
>
> http://code.djangoproject.com/wiki/Version1.1Features
>
> One of the tickets (7894) has patch to allow static files to be
> returned using more optimal means provided by mod_wsgi/mod_python,
> ie., using sendfile() or other memory mapping techniques.
>
> Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Composite Primary Keys
What we hope to achieve here is full support within the Django core, as opposed to specifying some kind of model. The only thing I have left to do is implement composite fields, but there's still no API for it. On Sat, Oct 4, 2008 at 12:03 PM, Eric <[EMAIL PROTECTED]> wrote: > > Hi, > i just discover this thread, I am working on this problem; you may > take a look at > http://kenai.com/projects/django-trac/pages/LegacyModule > > legacy is a module in my "django hacks trac" (or djac) project; it > aims to deal with > tables with no primary key or with composite pk. It provides 2 > methods: > > - use of oid field (works on sqlite, oracle, postgres <= 8) > - composite pk (for mysql that provides no oid field) > > cheers, > Eric > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Improvements for django.forms
Some of these changes I think are very valuable, especially CSS
classes. The formfield_kwargs I don't think is the right approach, but
possibly a method which could be called, as a lot of times I'm
overriding __init__ and it's quite messy, just to change the queryset
for a form.
I would personally like to see every form row that's output using the
default methods be wrapped in a container, and have classnames for:
- Errors
- If Required
- Widget Type (including parent type, excluding "Field")
And, as_p should be as_div or some block element that can contain all
of this IMO also :)
On Oct 16, 10:09 pm, pm13 <[EMAIL PROTECTED]> wrote:
> I would like to propose five quite isolated improvements for
> django.forms. But I think it is better to write about them in one
> email - otherwise there would not be complete answers for the
> problems. (More specifically, proposal 5 is very useful for proposals
> 1 and 2. And proposals 3 a 4 are very useful for proposal 5). And the
> improvements have common motive - it should be very easy to write very
> powerful and very flexible forms.
>
> I want only write about syntax. I have working patches for them but I
> don't say they are perfect or ready (for example only the first of
> them has tests).
>
> 1. Ordering and filtering of fields, fieldsets
>
> There would be three meta attributes for Form - fieldsets, fields and
> exclude. These attributes would be set with inner meta class:
>
> class FormX(FirstForm, SecondForm):
> class Meta:
> fields = 'first_A', 'first_B', 'second_A'
>
> class FormY(FirstForm, SecondForm):
> class Meta:
> exclude = 'first_C',
>
> class FormZ(FirstForm, SecondForm):
> class Meta:
> fieldsets = (
> {'fields': ('first_A', 'second_A')},
> {'legend': 'More information', 'fields': (''first_B',
> 'first_C')},
> )
>
> Attribute "fieldsets" would be a list of dictionaries. Each dictionary
> could have item fields, legend and attrs.
>
> Atribute "fields" would be a list of field names. It would be quite
> similar as in the current model forms - but the attribute would also
> specified ordering.
>
> Attribute "exclude" would be a list of field names. It would have the
> same semantics as in the current model forms.
>
> There would be no change in Form._html_output. But there would be two
> new methods in Form for templates - has_fieldsets and fieldsets. The
> second method would be a iterator of dictionaries with items attrs,
> legend and fields. Item fields would be a list of bound fields
> specified by fieldsets meta attributes, other items would be relevant
> meta attributes.
>
> Patch:http://code.djangoproject.com/attachment/ticket/6630/00-fieldsets.diff
>
> 2. Inlines
>
> There would be a new meta attribute for Form - inlines. And it would
> be possible to use inline in meta attribute fieldsets:
>
> class FormX(FirstForm, SecondForm):
> class Meta:
> fields = 'first_A', 'first_B', 'second_A'
> inlines = InlineA, InlineB
>
> class FormZ(FirstForm, SecondForm):
> class Meta:
> fieldsets = (
> {'fields': ('first_A', 'first_B', 'second_A')},
> InlineA,
> InlineB,
> )
>
> (These examples are equivalent.)
>
> Attribute "inlines" would be a list of formset classes. And these
> classes could be a part of "fieldsets" attribute.
>
> Form would not be able to construct inline formset instances.
> ModelForm would construct inline formset instances through one to many
> model fields.
>
> Methods Form.full_clean, Form.media, Form.is_multipart, ModelForm.save
> and FormSet.full_clean would be changed to support forms with inline
> formsets.
>
> There would be no change in Form._html_output. But method
> Form.fieldsets would be changed to iterate two kinds of dictionaries -
> the first variant (for fieldsets) would have items order (order of the
> fieldset between fieldsets), attrs, legend and fields. The second
> variant (for formsets) would have items order (order of the formset
> between formsets) and formset (an inline formset instance).
>
> Patch:http://code.djangoproject.com/attachment/ticket/6632/01-inlines.diff
>
> 3. Meta attribute formfield_kwargs for model forms
>
> There would be a new meta attribute for ModelForm - formfield_kwargs.
> It is a generalization of the "widgets proposal":
>
> class CommentForm(forms.ModelForm):
> class Meta:
> model = Comment
> fields = 'user', 'user_name', 'submit_date', 'comment',
> formfield_kwargs = {
> 'user': {'queryset':
> User.objects.exclude(is_superuser=True), 'attrs': {'class':
> 'important'}},
> 'user_name': {'help_text': 'for anonymous users'},
> 'submit_date': {'widget': SpecialDateWidget},
> }
>
> This meta attribute would be used as kwargs for
> django.db.models.Form.formfield.
>
> Patch:http://code.djangoproject.com/attachment/ticket/9385/02-formfield-kwa...
>
> 4. Attributes "attrs", "templ
Re: Proposal: AnonymousUser that you can set specific permissions for
I think being able to specify permissions for the AnonymousUser is useful, but hacking this in as a row in the database for User is not the right approach. I'm +1 for the ability to give permissions to anonymous users. On Oct 24, 9:59 pm, "Dj Gilcrease" <[EMAIL PROTECTED]> wrote: > On Fri, Oct 24, 2008 at 8:49 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > Seeing as you can already create a special user object in your own app > > and treat it as "the" "anonymous" user, I don't see any benefit from > > this, as I told you when you mentioned this in the #django-dev > > channel. Plus, it's unlikely that everyone who wants a "real" > > anonymous user will have exactly the same needs you do, which makes > > this even more a candidate for being your own code in your own app, > > rather than everyone's code in everyone's copy of Django (this is a > > huge bikeshed argument waiting to happen, in other words). > > I understand that and it is likely what I will end up doing, but I > figured I would throw my proposal and patch up here for people to > debate so I could see what other potential use cases might not be met > by this so that I can try and make my AnonUser model work for as many > people as possible. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: AnonymousUser that you can set specific permissions for
You are creating a model yourself though. You're just saying "don't use htis model, as it was created automagickally". You can have an AnonymousUser model (class?) which already exists. You could then edit it via however you want it to edited (the db is whats important) and have permissions set to it. On Oct 25, 10:46 am, "Dj Gilcrease" <[EMAIL PROTECTED]> wrote: > On Sat, Oct 25, 2008 at 2:59 AM, David Cramer <[EMAIL PROTECTED]> wrote: > > > I think being able to specify permissions for the AnonymousUser is > > useful, but hacking this in as a row in the database for User is not > > the right approach. > > > I'm +1 for the ability to give permissions to anonymous users. > > How would you suggest doing it then? Since creating a model that will > only ever hold one item seems kind of odd to me and in order to > specify permissions there needs to be some model to to assign the > permissions to. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Alternate ForeignKey based on choices
What you're wanting is a GenericForeignKey. Check out the
django.contrib.contenttypes documentation.
On Oct 26, 9:48 am, "Calvin Spealman" <[EMAIL PROTECTED]> wrote:
> You could also have a common parent class for Robot and User, and use that
> as your foreign key type. Which type is referenced would be your
> determination of user type.
>
>
>
> On Sun, Oct 26, 2008 at 6:19 AM, CooLMaN <[EMAIL PROTECTED]> wrote:
>
> > Hello,
>
> > I have an application with a model similar to the following:
> > class Relations(models.Model):
> > user1 = models.ForeignKey(User, related_name='relations_user1_set',
> > editable=False)
> > user2 = models.ForeignKey(User, related_name='relations_user2_set',
> > editable=False)
> > userType = models.PositiveSmallIntegerField(max_length=1,
> > editable=False, choices=( ('0', 'user'), ('0', robot) ))
>
> > Ok, so basically what I need this to do is that in case that the
> > userType is 1-robot it'll be a ForeignKey to Robot and not to User.
>
> > I'm assuming this is not possible with the current ORM implementation,
> > but I would be glad to hear I'm wrong.
>
> > Any suggestions? (this table serves the same purpose, and I'll most
> > likely always grab both robots and users so having another table for
> > each type is redundant and will be a problem if I append any more
> > choices in the future).
>
> > Thank you!
> > Gil
>
> --
> Read my blog! I depend on your acceptance of my opinion! I am
> interesting!http://techblog.ironfroggy.com/
> Follow me if you're into that sort of thing:http://www.twitter.com/ironfroggy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Composite Primary Keys
It allows you to use them, automatically creates them, and has some of the admin handling done. However, there's still no API design around multi-column fields (no one seems to want to talk about it) so I'm pretty much stopped working on it. e.g. You can't say field1 = this, field2 = that, and then say compositekey = field1,field2 you instead are forced to do key1=blah, key2=blah in all your lookups, and no easy foreignkey properties. I'm running this on production environments, so it works fine, but I can up SVN and fix any conflicts and post a patch again. On Thu, Oct 30, 2008 at 3:40 PM, Joey Wilhelm <[EMAIL PROTECTED]> wrote: > > David, > > What is the current status of this patch? I'm starting up a new > project which pretty much desperately needs this support as well. I > could work around it, but the thought of adding AutoFields to all of > these models which really -do not- need them, makes me a bit ill. > > I would be more than willing to help test your implementation if there > is anything usable yet. This is one of the pieces that's getting me > all twitchy waiting for it. > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Composite Primary Keys
Well GenericRelation's or whatever are an attempt to provide some composite space, but we need an expandable space, not something tied to content type's. We need to say mykey = CompositeField(field, field, field) or something. No one wanted to discuss it at DjangoCon, so no. On Thu, Oct 30, 2008 at 3:57 PM, Joey Wilhelm <[EMAIL PROTECTED]> wrote: > That would be great. The project I am working on now won't be doing > anything too terribly complex just yet; I mainly need the admin support to > make my life a little easier. > > As to the API, I saw several proposals earlier along on this thread, but > obviously nothing solid. Did anything ever come from DjangoCon on this > topic? What issues still need to be addressed in this design? > > On Thu, Oct 30, 2008 at 13:46, David Cramer <[EMAIL PROTECTED]> wrote: > >> It allows you to use them, automatically creates them, and has some of the >> admin handling done. However, there's still no API design around >> multi-column fields (no one seems to want to talk about it) so I'm pretty >> much stopped working on it. >> >> e.g. You can't say field1 = this, field2 = that, and then say compositekey >> = field1,field2 you instead are forced to do key1=blah, key2=blah in all >> your lookups, and no easy foreignkey properties. >> >> I'm running this on production environments, so it works fine, but I can >> up SVN and fix any conflicts and post a patch again. >> >> -- >> David Cramer >> Director of Technology >> iBegin >> http://www.ibegin.com/ >> >> >> > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Cache and GET parameters
I really like the idea of the explicit GET params passed.So I'm +1 especially on solution #3. I actually had never realized it wasn't caching pages with GET params, luckily though, any pages where I use this decorator don't fluctuate like that :) On Nov 1, 7:51 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On Sat, Nov 1, 2008 at 8:32 PM, SmileyChris <[EMAIL PROTECTED]> wrote: > > > On Nov 2, 2:52 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > >> Assuming vary_on_get() with no parameters means no variance (other > >> than the HTTP Vary headers), then [...] > > > That seems confusing - the decorator name seems to imply that it would > > vary on any get attribute (even though this is the default) - at least > > that's how I'd look at it if I didn't know otherwise. > > @vary_on_get(None) ? :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
select_related optimization and enhancement for the django.contrib.admin
While I've been working on composite primary keys, I also made a few tweaks to the admin app. Most of these are related to the primary key support, but one is an optimization. I would post this as a patch, or a ticket, but I want to open this up for discussion, and my django repo is so far from trunk it's a PITA at the moment to create the patch. Anyways, what it does: * list_select_related can be a boolean, or a list. If it's a list it says "select_related on these fields" * select_related is smart by default, no more implicit select all If someone wants to create a patch, you'll be able to get to it a lot faster than I will. Otherwise I'll eventually throw one up on trac for each change. line 198ish of django.contrib.admin.views.main if isinstance(self.list_select_related, (tuple, list)): qs = qs.select_related(*self.list_select_related) elif self.list_select_related: qs = qs.select_related() else: fields = [] for field_name in self.list_display: try: f = self.lookup_opts.get_field(field_name) except models.FieldDoesNotExist: pass else: if isinstance(f.rel, models.ManyToOneRel): fields.append(name) if fields: qs = qs.select_related(*fields) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
