Re: Model.objects.raw() (#11863)
On Tue, Sep 29, 2009 at 4:30 AM, Russell Keith-Magee wrote: ... > This trick is exactly what Django does internally when it constructs > object instances. However, in the Django internals, it is a completely > automated process - Django issues the query and parses the results, so > there's no risk of getting the column order wrong. Code here; note the treatment of .defer'd querysets in a branch that uses **dict as well. http://code.djangoproject.com/browser/django/trunk/django/db/models/query.py#L950 --~--~-~--~~~---~--~~ 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: contrib.admindocs need some love.
I have an icky patch for this. On Oct 5, 2009, at 2:07 PM, Peter Baumgartner wrote: > > On Thu, Aug 27, 2009 at 2:03 PM, Justin Lilly > wrote: >> Hey guys. >> >> I started writing some docs for another developer today and hit a >> few >> issues with admindocs that I plan on sprinting on for DjangoCon. I'm >> hoping anyone else with complaints / ideas will voice up, though my >> main >> impetus for the post is to announce that I'm going to do it so I >> can't back out. ;) >> >> Things I plan to address: >> >> 1. No tests. >> 2. No docs. >> 3. You can't seem to cross-link to views without the link being >> app.package.func . I'd like to see it at least configurable. >> 4. ManyToManyFields don't show up. >> >> There's not a ton there, but worth sprinting on, imo. Any other >> ideas or >> changes you'd like to see in admindocs that I might be able to work >> on? >> Shout them out. >> > > It may be out of your scope, but admindocs flat-out breaks with GIS > fields. http://code.djangoproject.com/ticket/7977 > > -- Pete > > > --~--~-~--~~~---~--~~ 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: contrib.admindocs need some love.
On Mon, Oct 5, 2009 at 2:18 PM, Jeremy Dunck wrote: > I have an icky patch for this. To be clearer, this is a general problem with admindocs-- it has a mapping, DATA_TYPE_MAPPING, and assumes any model field's .get_internal_type() will be in that dictionary. I can think of a couple ways to address this: 1) Have each app which ships custom fields check to see if INSTALLED_APPS includes admindocs, and if so, update DATA_TYPE_MAPPING. 2) Have admindocs check for a new API, Field.get_readable_data_type(), falling back to DATA_TYPE_MAPPING, and finally to the result of .get_internal_type(). The attached patch does the first approach for GIS (applied against django trunk 11125). I think the second approach is better, but doesn't fix your problem immediately. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- gis-admindocs.diff Description: Binary data
Re: Proposal for 1.2: Dumber email validation
Ned, You really ought to show us all how to use that time machine. :) On Oct 10, 2009, at 8:49 AM, Ned Batchelder wrote: > > +1 > > http://nedbatchelder.com/blog/200908/humane_email_validation.html > > I was going to kibbitz on the fix (removing a single * would have > sufficed), and realized we were once again in the quagmire of email > regex validation. > > --Ned. > > James Bennett wrote: >> In light of yesterday's security issue, I'd like to propose that we >> significantly dumb down the regex Django uses to validate email >> addresses. >> >> Currently, the regex we use covers many common cases, but comes >> nowhere near covering the entire spectrum of addresses allowed by the >> RFC; several tickets are open regarding this. Trying to cover more of >> the RFC is possible, although supporting all valid email addresses is >> not (various regexes claim to do this, but full coverage is >> impossible >> -- the RFC is flexible enough WRT things like nested comments that >> I'm >> fairly certain no single regex can handle them all), and -- as we've >> seen -- attempts to cover a broader chunk of the RFC can introduce >> issues with performance. >> >> So what I'd like to propose is that EmailField essentially check that >> the value contains an '@', and a '.' somewhere after it. This will >> cover most addresses that are likely to be in actual use, and various >> confirmation processes can be used to rule out any invalid addresses >> which happen to slip through that. Meanwhile, people who want to >> support comments inside a bang path or other such exotic beasts can >> simply write their own regex for it and tell a form to use that >> instead. >> >> >> >> >> > > > --~--~-~--~~~---~--~~ 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: Best place for code that processes stuff from settings.py once (for logging implementation)
On Oct 12, 2009, at 11:04 AM, Simon Willison wrote: > > On Oct 12, 9:03 am, Benjamin Slavin wrote: >> That means: I'm strongly in favor of any hook to allow code to be run >> before the Django environment is setup, and I'm not tied to any >> particular path of solving the problem. > > a very useful step one would be to go > through and document exactly how Django initialises itself at the > moment - what loads in what order, when are settings evaluated, what > bits of Django actually look at INSTALLED_APPS etc. It's a bit dated now, but this might be a useful place to start. http://code.djangoproject.com/wiki/DevModelCreation > Also, I bet Marty knows this area well from his book 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are threading.local objects evil? (was Re: shortcut proposal)
On Fri, Oct 16, 2009 at 3:01 PM, Michael P. Jung wrote: > mp> I've found it to be way more practical to just store the request object > mp> inside a threading.local object and let my functions access it directly. > mp> (...) > > Alex> Quite simply, no. Storing anything in a threadlocal instead of > Alex> passing it around is indicative of bad coding practice, and poor > Alex> architecture. > > Stating that the use of threading.local objects is "indicative of bad > coding practice, and poor architecture" is plainly wrong. > > I say: It depends. Alex just spent a bunch of time adding multi-db support; part of the effort involved in that work was removing the request=thread=connection assumption that tied django to a single DB. So he's got a very specific viewpoint. I've previously advocated for something I'd call a blackboard-- a globally reachable place where middleware could scribble information, possibly useful to something else somewhere downstream in the system. This information would be safe to ignore if you weren't interested in this information. I think of it as a sort of persistent, opt-in signal. He reacted badly to that one, too. :-) But I'll side with Alex and say that a thread-local request is a bad idea. In fact, people do use Django in async systems: Old but useful here: http://code.google.com/p/django-on-twisted/ --~--~-~--~~~---~--~~ 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: Help me write tests for my patch on template rendering
On Wed, Oct 21, 2009 at 9:29 AM, Peter Bengtsson wrote: ... > Can someone guide me through the jungle of Django tests to run and > write a test for this? > I figure the place to add test is: > trunk/tests/regressiontests/templates/tests.py > > But how do I run these? It takes many many seconds to run the whole > suite. Assuming you've already got a test project set up and DJANGO_SETTINGS_MODULE is set: python /path/to/django/tests/runtests.py templates --~--~-~--~~~---~--~~ 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: The this-needs-to-be-in-django angst
On Oct 21, 2009, at 7:48 PM, James Bennett wrote: > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." Very fitting. --~--~-~--~~~---~--~~ 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: The this-needs-to-be-in-django angst
On Wed, Oct 21, 2009 at 2:22 PM, mrts wrote: ... > Django Bug Days > --- > > At regular intervals, say twice a month on Saturdays, > set aside 2-3 hours for IRC-based bug hunting sprints. If we do this, I think the time slot should rotate to allow different timezones to participate; +6 hours each occurrence? > Devs list tickets that they want people to work on and > people are free to suggest their own. Work is done over > longer periods, but the bug days provide an occasion to > get feedback from the devs. I think, really, any ticket without "has patch" or with "patch needs improvement" is that list. Asking the core devs to pick bugs to focus on is sort of defeating the purpose; we're trying to grease the wheels, not give core more to do. > The patches will perhaps not be integrated into SVN but to a > branch on a DVCS (see the next suggestion). git clone http://github.com/django/django/ git checkout -b bughunt- master #patch, w/ docs and tests #update code.djangoproject for ticket#, pointing to repo's commit? Core, is this really an improvement over patches attached to tickets? > Added benefit: if nobody shows up, they have no right to > grumble on the mailing list :). ...Until someone feels frustrated that *this* isn't incorporated fast enough. :-/ --~--~-~--~~~---~--~~ 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 1.2 feature voting
On Tue, Oct 13, 2009 at 8:38 AM, Jacob Kaplan-Moss wrote: ... > A +1 from a non-committer is an offer to personally work on the feature, > or to help the person working on it by reviewing the patch, testing, etc. Holy smokes, there are gonna be some busy people. :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Regularly-scheduled Django sprints, first December 11 - 13
Djangonauts, To help speed along development on Django, I'd like us to start holding regularly-scheduled sprints. I've previously contacted core committers to see who would be willing to supply the commit bits for the sprint workflow. I'm now looking for members of the dev list to help organize locally. If you would be willing to help organize your local Django developers, the DSF can pay for lunches or similar costs. It doesn't take much effort-- you just need a place to work that offers a good network connection and a little coordination to get people together. If you're an experienced contributor, great, but there will be people on #django-dev and #django-sprint to help out, too. We can certainly get a committer available online. In some cases, we can get a committer on-site to help things along as well. To start, let's try running a sprint once every two months. I don't think the specific days matter too much, but for a start, let's say the second Friday through Sunday of every second month, starting in December. That would make the first scheduled sprint December 11 - 13. Since we have developers world-wide, I think it would make sense to have the sprint roll across the time zones, starting at Fri 11 Dec at 18:00 UTC [1] and running continuously until Mon 14 Dec at 00:00 UTC [2]. Within that range of time, local groups can gather with some assurance that a committer will be available at least virtually. It'd be lovely to get more than one location per sprint, and I'd like to ensure that people all over at least have a reasonable chance to attend a gathering. The exact days and start times will be up to local organizers-- I'm just trying to make some conventions so we don't have to fiddle with configuration so much. If you're willing to organize a sprint gathering during this time span, please let me know and I'll help to ensure committers are available and to promote the sprint gathering. (There's actually pretty good guidance on the Sprints wiki page [3].) Even if you can't host on those dates, but would like to host in the future, please let me know so I can have a list of candidates to work from in the future. [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=11&hour=18&min=0&sec=0&p1=64&p2=37&p3=196 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=14&hour=0&min=0&sec=0&p1=64&p2=37&p3=196 [3] http://code.djangoproject.com/wiki/Sprints --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
On Tue, Nov 10, 2009 at 10:04 AM, Alex Gaynor wrote: ... > From December 19th through January 24th I will be willing to do > anything necessary to organize a sprint in Chicago, hopefully it won't > be too hard to drag our local core devs there :). Let me know what > the sprint date would be over that time period and I can start working > things out. Ah, winter break. :-) 2nd weekend is Jan 8-10, so let's say that? --~--~-~--~~~---~--~~ 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: Regularly-scheduled Django sprints, first December 11 - 13
On Wed, Nov 11, 2009 at 5:57 AM, Russell Keith-Magee wrote: > > On Wed, Nov 11, 2009 at 1:06 AM, mrts wrote: >> >> Great news! Have you discussed the workflow yet? >> I.e. will a DVCS be involved, and if yes, will there be >> a central repo for coordinating the effort? >> >> A special repo on Github would otherwise be perfect, >> but as mentioned before, we have a problem with re-forking: >> http://support.github.com/discussions/feature-requests/560-two-forks-of-a-single-repo Even presuming you want to use git for collaboration in this way, I fail to see why you need to have two repos both called django, or similar. Github seems to encourage you to fork through them because that helps them manage fork queues, but unless I'm missing something, it's perfectly OK to make a repo called django-sprint-dallas-200912 and push up the regular django repo there, then use that as your merge point. (I sometimes worry that sites like github and bitbucket gloss over the fundamentals and make you think that they offer some core feature -- they are nice, but DVCS works without some magick site service in the middle. Github is git-daemon + social networking + some handy utilities.) Bringing stuff back into the main django repo doesn't have to be done through github's fork queue-- it's really not too hard to see what is unmerged once you've fetched in a remote: git clone git://github.com/django/django.git django-sprint (make a shared sprint repo on github, perhaps django-sprint-location-date, e.g. django-sprint-dallas-200912) git remote add merge-point g...@github.com:jdunck/django-sprint-dallas-200912.git git checkout -b upstream-master origin/master #just for easy reference git push merge-point upstream-master:master #so everyone starts at the same place git checkout -b jdunck-feature-A upstream-master (do some local work, merging with sprint collaborators, but keeping a separate branch per ticket or feature) Want to see what other have done? Add their repos as remotes, and fetch them: git remote add mrts-sprint g...@github.com:mrts/django-sprint.git git fetch mrts-sprint Want to see what mrts has done that I haven't merged yet? git log mrts-sprint/pet-feature --not sprint-work OK, if that looks good, I can pull it into the blessed sprint repo: git branch mrts-pet-feature mrts-sprint/peg-feature git push merge-point mrts-pet-feature:done-mrts-pet-feature - At the end of the day, though, you're still going to make trac patches (unless a core is willing to accept patches from django-sprint*/done-* repo branches). -- 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: Regularly-scheduled Django sprints, first December 11 - 13
On Wed, Nov 11, 2009 at 3:57 PM, mrts wrote: ... >> As I have said to you in the past - if you want to make your >> contribution to Django to be a DVCS repository that acts as a staging >> area for trunk-ready patches, that would be a very helpful >> contribution. This is doubly true during a sprint - sprints generate a >> lot of activity, so having good lieutenants to triage contributions is >> extremely useful. > > Done, http://github.com/django-mq/django-mq . > > I'm willing to regularly review pull requests and add > collaborators who are willing to do the same. Have you received any pull requests on this? If not, why do you think this is? If so, how has the integration work gone? > Few or no people will use the repo > unless there's a general consensus that it's a good thing. > That consensus can only come from clear understanding of > it's purpose and workflow (the "essays") -- only then can > people start contributing. Otherwise they will feel that > it's a waste of their time on an obscure fringe thing. I can see that a sprint repo could be useful for sharing work between multiple people working on the same feature. If etherpad supported editing trees, less so. But at the end of the day, core gets a patch to test and apply; how does a DVCS repo make this better? Perhaps it would make it easier to keep patches fresh if there's a long period where the patch is "done" but not committed. Maybe you could do this as a value-add to gain karma: look for useful but old patches in trac; pull those bitrotten patches into your tree, and update them. Provide a link to the updated tip in those trac tickets. -- 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.
Django sprint in Dallas - Dec 12 & 13
Hi All, There will be a local Django Development sprint in Uptown Dallas next weekend (Dec 12 and 13). A development sprint is an excuse to get together, write some code, and have a good time doing it. The purpose of this sprint will be to help finish features and push out bug fixes in preparation for the Django 1.2 release[0], which feature freezes January 26. If you're interested in coming to work on other open source Django-based projects, that's welcome too. (There will also be a concurrent sprint in the Triangle, NC area.) We'll be meeting at CoHabitat (2517 Thomas Avenue, Dallas, TX 75201 [1]) and I'll be there to open the doors at 9am both days. For more information, please check out the corresponding wiki page[2] and RSVP via Eventbrite[3] if you're interested: We're looking for sponsors (lunch, coffee, beer, firewood, etc.), so out the sponsors section of the wiki and add yourself (or your company) if you'd like to bring something. Hope to see you there! [0] http://code.djangoproject.com/wiki/Version1.2Features [1] http://bit.ly/cohab-gmaps [2] http://code.djangoproject.com/wiki/Sprint200912Dallas http://code.djangoproject.com/wiki/Sprints [3] http://django-sprint-dallas-200912.eventbrite.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.
Sprint issue tracking / triaging
Hey all, I was wondering if I could do anything to streamline applying sprint-created patches. Obviously, I can do triaging and provide feedback on patches. Can I be blessed to say "Ready for checkin"? What else can I do? I think getting patches which are actually ready to be committed quickly will help sprinters be motivated and want to participate in future sprints. -- 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: Django 1.2 progress assessment
On Mon, Dec 7, 2009 at 4:03 PM, Alex Gaynor wrote: > I'm very confident that multi-db will be ready for merge by then, > Justin and I (ok mostly Justin) have been working on the GIS stuff, > which is the last blocker. Perhaps I missed the gripping conclusion, but wasn't there some outstanding work to be done on multi-db's interaction with admin? -- 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: Sprint issue tracking / triaging
On Dec 7, 2009, at 5:02 PM, Russell Keith-Magee wrote: > Looking at new ideas to try - if someone trusted at the sprint (such > as yourself) were to take the role of developing a merge-ready git > branch, we (the committers) could use that branch to feed into trunk. > This hasn't been done in the past, but if you want to try an > experiment, it would be interesting to see if we can make it work. I assume one branch per feature/ticket, plus maybe a meta branch for integration test? I'd imagined people would still like one (or more) commit per feature. -- 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: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 11:27 AM, mrts wrote: ... > I have thought about the process a bit and even wrote some > helper code. > > Unfortunately I fell ill and haven't fully recovered (and am > therefore horribly off-schedule with my work), so I haven't > had the chance to continue with the effort. > *Notoriously* bad timing, considering we had a similar > discussion before and that the sprint is coming up soon. Sorry to hear that. The document you linked is a start, but I'm a bit concerned by this goal: "to keep the main integration branch as stable as the official trunk so that it can be used in actual deployments" My concern here would be that people become dependent on your selections for prod, and some of these changes never get merged to mainline, so that there's functionally a fork in terms of support and community. I guess people will vote with their feet if your queue is really better. If I do run sprint repos, my specific purpose will be to provide patchsets for easy integration, but no expectation of people using those branches for deployment. :-/ -- 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: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 11:40 AM, Alex Gaynor wrote: ... > Personally I think merge queues ignore where the real work is. > Applying a patch (as a diff, or pulling from another repo myself) is a > trivial amount of work, and the number of times I have had actual > conflicts between 2 patches that were going to be applied is tiny, and > where there was a conflict it usually indicated something more > fundamental was wrong with the patch. I agree, though I think this depends on the depth of the unapplied queue. > Because of this work to review tickets, provide feedback, and get them > into an RFC state is far more important IMO. Agreed. -- 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: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 12:56 PM, Alex Gaynor wrote: > This line of reasoning makes 0 sense IMO. Your argument is people > provide sub-par patches because they think trunk moves too quickly, > and a committer will need to rewrite it anyways. OK, I declare bikeshed. I'll run the experiment as Russ suggested, and we'll see if it does any good. :-) -- 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 __contains__
On Tue, Dec 8, 2009 at 7:22 PM, Luke Plant wrote: ... > However, it could be slightly more efficient in some cases, because > the entire QuerySet._result_cache does not necessarily need to be > filled - we can stop if we find a match, saving us the work of > building Model objects that might not be needed. You could also inspect the item to see if it's an instance of the .model; if not, fast path False. Which leads to a question of edge-case semantics -- "1 in qs" checking for primary key value. Good or bad? -- 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 __contains__
On Tue, Dec 8, 2009 at 8:38 PM, Luke Plant wrote: > On Wednesday 09 December 2009 01:52:48 Jeremy Dunck wrote: ... >> You could also inspect the item to see if it's an instance of the >> .model; if not, fast path False. >> >> Which leads to a question of edge-case semantics -- "1 in qs" >> checking for primary key value. Good or bad? > > I think it's much better to leave __contains__ just doing an '==' > check, rather than anything clever which could surprise people. (If > the developer is doing a test which is always going to return False, > it's a mistake, not an optimization opportunity). I see what you're saying. I got there starting from the thought that __contains__ should perform a PK query if iteration hasn't started, rather than filling the results cache. __nonzero__ is O(1), where "in" would be O(N). -- 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: Django sprint in Dallas - Dec 12 & 13
Hello all, Just a friendly reminder about the sprints this Saturday and Sunday in Dallas, TX and Triangle, NC. We'll also be on #django-sprint on freenode from about 9AM UTC-6. More details here: http://code.djangoproject.com/wiki/Sprints On Fri, Dec 4, 2009 at 12:06 PM, Jeremy Dunck wrote: > Hi All, > > There will be a local Django Development sprint in Uptown Dallas next > weekend (Dec 12 and 13). A development sprint is an excuse to get > together, write some code, and have a good time doing it. The purpose > of this sprint will be to help finish features and push out bug fixes > in preparation for the Django 1.2 release[0], which feature freezes > January 26. If you're interested in coming to work on other open > source Django-based projects, that's welcome too. (There will also be > a concurrent sprint in the Triangle, NC area.) > > We'll be meeting at CoHabitat (2517 Thomas Avenue, Dallas, TX 75201 > [1]) and I'll be there to open the doors at 9am both days. > > For more information, please check out the corresponding wiki page[2] > and RSVP via Eventbrite[3] if you're interested: > > We're looking for sponsors (lunch, coffee, beer, firewood, etc.), so > out the sponsors section of the wiki and add yourself (or your > company) if you'd like to bring something. > > Hope to see you there! > > [0] > http://code.djangoproject.com/wiki/Version1.2Features > > [1] > http://bit.ly/cohab-gmaps > > [2] > http://code.djangoproject.com/wiki/Sprint200912Dallas > http://code.djangoproject.com/wiki/Sprints > > [3] > http://django-sprint-dallas-200912.eventbrite.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: Session/cookie based messages (#4604)
Hijacking thread a bit; I found a bug in messages under python 2.4. Basically, in 2.4, hmac.new expects digestmod to be an object with a callable .new(). In 2.5, it expects just a callable. hashcompat supplied a callable (only) in both cases. I added *_hmac to hashcompat to make hmac.new work in both cases. Patch attached; it's tiny. Want a ticket anyway? -- 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. messages-hmac-py2.4.diff Description: Binary data
Re: Session/cookie based messages (#4604)
On Fri, Dec 11, 2009 at 11:03 PM, Jeremy Dunck wrote: .. > > Patch attached; it's tiny. Want a ticket anyway? Added as ticket #12362 -- 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: Ticket #3349 patch review
On Sat, Dec 12, 2009 at 4:18 PM, ab wrote:
> I'd like some opinions on the existing patch for
> http://code.djangoproject.com/ticket/3349.
> This ticket ("If an ImportError occurs within some loaders a rather
> confusing exception is raised") seeks to address the difficulty of
> debugging ImportErrors raised in template tag library.
...
> 3. Design -- Seeing the ImportError's traceback is indeed helpful in
> identifying the source of the problem. But, it's also kind of weird to
> have the traceback of an ImportError (ending with the line "import
> notthere" or whatever) associated with a different exception.
This may be helpful?
http://blog.ianbicking.org/2007/09/12/re-raising-exceptions/
--
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: Last call: #11863 (Model.objects.raw)
On Tue, Dec 15, 2009 at 4:15 PM, Jacob Kaplan-Moss wrote: > Hey folks -- > > Forgot to mention it during the sprint this weekend, but I've pushed a > RC patch to #11863, Model.objects.raw(). If anyone's got any feedback, > let it fly. Otherwise, I'll be checking this in in a couple-three days > or so. == InsuficientFields -> InsufficientFields == This bit doesn't seem to be true; It seems that missing fields will raise InsuficientFields instead. Am I reading it wrong? " The ``Person`` objects returned by this query will have their ``first_name`` attributes set correctly, but *will not have any other model fields set*. This means that accessing ``last_name`` or ``birth_date`` will result in an ``AttributeError``. " == RawQuery.__len__ calls _populate_cache twice. I see the comment about SQLite, but if that was intended, why not just use len(self._cache) to start with, since _populate_cache does .fetchall()? == RawQuery._populate_cache does fetchall(). This is sort of surprising, since normal QuerySets go out of their way to avoid fetchall. RawQuerySets are not as lazy as normal querysets in that normal querysets do fetchmany. If this was intended, it might be worth pointing out. In fact, I think RawQuerySet.iterator won't do what people expect. == On "admonition:: Model table names" - Person._meta.db_table would have the value, and it might be better to be more explicit about it. But it's an "_" API, so maybe we don't want to make it clearer after all. ;-) == "You'll use ``%s``" Is that back-end independent? It looks like it gets evaluated by whatever backend you're using, and so would depend on DB-API paramstyle. == Typo here: "It's tempting to write the above query as:: " >>> query = 'SELECT * FROM myapp_person WHERE last_name = %s', % lname) -> >>> query = 'SELECT * FROM myapp_person WHERE last_name = %s' % lname Or did you make it bad syntax on purpose? == RawQuery.validate_sql excludes anything but selects, but Oracle uses comments to do query hinting. Can an Oracle person confirm that those hints can't start the query SQL? (Not worth holding up landing, of course.) == -- 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: Last call: #11863 (Model.objects.raw)
On Dec 15, 2009, at 11:16 PM, "Sean O'Connor" wrote: > In regard to the deferred fields option, I'll let Jacob speak for > his view but I've approached such functionality as "nice to have" > for the patch since its not critical to the patch being useful. > Personally I haven't had the time to figure it out and implement it > so my original patch didn't include it. I like the idea of the deferred fields, but if we don't implement it now, people may come to rely on the AttributeError so that we can't add deferred later. Perhaps a note in the docs stating our intent to add deferreds would suffice? -- 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: Last call: #11863 (Model.objects.raw)
On Wed, Dec 16, 2009 at 8:19 AM, Anssi Kaariainen wrote: ... > A nice way to test which fields the model > were populated and marking the non-populated fields as deferred would > be optimal in my opinion. One use case where you don't necessary know > which fields are populated and which ones aren't is when you have > multiple raw() queries defined populating different fields of the > model. I was with you until the end here, where I'm not sure I follow. Describe the API you're wishing for? -- 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: Last call: #11863 (Model.objects.raw)
On Wed, Dec 16, 2009 at 10:02 AM, Anssi Kaariainen wrote: ... > I am not suggesting this. What I would like to have is something like > foo.field.is_deferred(). I don't think there is any easy way to test > this currently. This could come handy in a template for example. You > could use the same template for objects fetched with different raw > queries, and skip deferred fields when showing data about the object. This won't work, because deferred fields are descriptors, and accessing foo.field would run the query. Something you could do is foo.deferred_fields.field_name -> Boolean, but that seems pretty clunky to me. -- 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: preventing brute forcing passwords
On Thu, Dec 17, 2009 at 6:47 PM, Luke Plant wrote: ... > The problem with signals is that they don't return values, and so the > mechanism can't interact with the actual login process. It can only > notice that something is going on and try to stop it by some external > mechanism. Actually, they do return values -- an iterable of (receiver, response) pairs. Otherwise, I agree with most of your sentiment. But -- I would like to see some form of rate limiting built in; Django tries to do the right thing wrt. security, and brute force is a common form of attach. -- 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: Loading Backends
On Mon, Dec 21, 2009 at 8:22 AM, Marty Alchin wrote: ... > django.contrib.auth.load_backend() > django.core.files.storage.get_storage_class() > django.template.loader.find_template_loader() > django.db.load_backend() Also, django.core.cache.get_cache -- 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: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 1:05 PM, Jeremy Dunck wrote: > On Tue, Dec 8, 2009 at 12:56 PM, Alex Gaynor wrote: > >> This line of reasoning makes 0 sense IMO. Your argument is people >> provide sub-par patches because they think trunk moves too quickly, >> and a committer will need to rewrite it anyways. > > OK, I declare bikeshed. > > I'll run the experiment as Russ suggested, and we'll see if it does > any good. :-) Here's my report-- The Dallas sprint had 10 people participating for various amounts of time. About half were comfortable enough with git to participate in the queue. I think we closed got about 8 patches ready; 5 went into my queue. After I reviewed them, I marked them ready-for-checkin in trac, attaching the relevant diffs. I'd intended to publish my merge queue at the end of the sprint, but I had reservations about one ticket -- 11753. By the time Jacob and I had gone back and forth cleaning that up, a couple of the other tickets in my queue had been checked in and closed. At this point, I don't think it's worth having the queue merged as a special dance, since there's only a couple small diffs outstanding and they are also in trac. Though the queue wasn't used for merging into SVN, it was still useful to me in the sprint coordination role. It served as a list of patches ready for my review and facilitated iteration on the patches with sprinters. It also served, just now, as a handy checklist to see that people's work got committed and that I did an OK job of marking things ready. I think this kind of positive feedback is good for sprinter morale. If anyone has specific questions on the process or utility, let me know. -- 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: cached template loader is new in trunk/1.2, docs does not mention that
On Wed, Jan 6, 2010 at 10:24 AM, Amit Upadhyay wrote: > http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types, I > looked and could not find "cached.py" > in Django-1.1.1/django/template/loaders. There is a section for "django.template.loaders.cached.Loader". Isn't that what you mean? -- 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: Model validation incompatibility with existing Django idioms
On Wed, Jan 6, 2010 at 3:56 PM, Joseph Kocherhans wrote:
...
>>> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison
>>> wrote:
...
form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
if form.is_valid():
p = form.save(commit=False)
p.user = request.user
p.primary_contact = somecontact
p.save()
...
> I had another idea that I think might work out. What if
> ModelForm.validate() only validated fields on the form, like it worked
> before the merge, and ModelForm.save() would automatically validate
> the excluded fields, raising ValidationError if there was a problem?
> Validation for each field would only happen once, it would accommodate
> the commit=False idiom, and it would still ensure that the model
> itself is validated in common usage.
Note that p in the example above is the unsaved model instance, not
the ModelForm. So to fix the idiom, the excluded field validation
would need to be done on Model.save, not ModelForm.save, right?
--
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.
Message level API awkwardness
I realize I'm very late giving feedback on the API, sorry and feel free to ignore if I'm too late. That said, from the docs, the API to set the effective messaging level is awkward: == # Change the messages level to ensure the debug message is added. messages.get_messages(request).level = messages.DEBUG == To *set* the messaging level, I call .get_messages? I think I understand the reason this was done-- get_messages is backend- and request-specific, but it is definitely surprising. Perhaps something like this would do better? messages.effective_level(request) => messages.INFO messages.set_effective_level(request, messages.DEBUG) ? Behind the scenes, it could be almost the same implementation. -- 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: Django docs aren't aware custom model save methods need the "using" keyward arg.
On Thu, Jan 7, 2010 at 5:17 PM, j...@jeffcroft.com wrote: ... > I would suggest the docs ought to instruct users to use a signature > like: > > def save(self, *args, **kwargs): Sounds reasonable to me. > I will now duck and cover, as I tend to get destroyed anytime i say > anything at all in this group. Are you sending from other email addresses? I only see a few occurrences of j...@jeffcroft.com on django-dev, and I haven't seen you get destroyed. :-/ Sucks that you feel that way. -- 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: Django Design Czar
On Sat, Feb 6, 2010 at 7:09 PM, j...@jeffcroft.com wrote: > It's really hard to reconcile the open source mentality with the fact > that design-by-commitee never works well. I'm not sure how to go about > it, really. The "design czar" idea isn't perfect, but at least it's > attempt to find a way to achieve both open source community and good > design work -- and to date, it's worked fairly well for Django. I feel the same tension. You can't write unit tests for design, and the idea of having designers each working on different pieces of code until they earn the crown will probably just lead to differing opinions and an incoherent result. Survivor: Design? Nah, everybody ends up pissed at each other for voting off their friend, and nobody wins the $1M. Swords at dawn, then. ;-) More seriously, +1 for design progress, but I have no idea how to get there from here. :-/ -- 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: Django Design Czar
On Mon, Feb 8, 2010 at 3:42 PM, j...@jeffcroft.com wrote: ... > One way I think design proposals/tickets need to be treated > differently than other stuff is that there shouldn't be this, "sure, > great idea, go build it and get back to us" attitude involved. I agree with your general point, which I interpret to mean: ideas are useful, even without code, and designers specialize, often to the exclusion of coding.Unfortunately, unless the person filing the request/ticket makes it clear that their request isn't something they can personally fulfill, it's hard to tell the difference between a person being lazy (i.e. wishing for a pony) and a person asking for assistance (i.e. a designer asking for a smart if tag). It's an important distinction. At the same time, it is also important to recognize the difference between being ignored and being in a long, difficult to prioritize, line. ... > I think the Django community needs to better respect the fact that > just because someone can't SOLVE a problem themselves doesn't mean > they're not able to IDENTIFY one. I think "patches welcome" does presuppose that anyone with the proper time and attention could fill their own needs, and that's generally been a correct assumption. Open source is built on sharing code, and sometimes it's hard to judge whether an idea is good or not without seeing an implementation. I guess I'd just ask that when you feel coders are being unfair just call it when you see it. Start with the assumption that we mean well and maybe don't see where you're coming from, like Russ with the contest idea. :-) All that said, developers everywhere have some amount of not-invented-here syndrome, and they have ideas, too. Often, they'll work on their ideas rather than look for someone else's. Since we're all volunteer, it's not appropriate to tell people what they should or shouldn't work on. So I think designers proposing ideas (but not providing code) are inherently at a disadvantage. I imagine that there's enough overlap between designers who can code a bit and developers who can design a bit to get together and make progress. We just have to try it and see how it goes. -- 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: Django Design Czar
On Mon, Feb 8, 2010 at 4:00 PM, Wilson wrote: > I've started a stub of a wiki page that anyone who's interested can > start to share and collect ideas that require design work or input. > > http://code.djangoproject.com/wiki/DjangoDesign > > As the input outgrows the wiki page, or as individual proposals become > actionable, we'll adapt from there. There were a bunch of partially-done items in the admin-ui branch: http://code.djangoproject.com/wiki/soc2009-admin-ui http://groups.google.com/group/django-developers/browse_thread/thread/1edf77c9c8b1101d/4ecda5e4c982c7e1?pli=1 I don't have time to garden that into the wiki page, but perhaps someone else would like 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-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?
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: [RFC] Fixing middleware/view decorator handling of content iterators
On Mon, Feb 15, 2010 at 3:16 PM, Forest Bond wrote: ... > * Forbid premature draining of the content iterator via response.content by > only > evaluating the content iterator if accessed via iter(response) and raising an > exception if it is accessed via response.content. ... > * Is this type of change too invasive for 1.2? I assume you mean 1.3, since 1.2 is in feature freeze. Anyway, the response.content attribute is documented and client code may depend on it, making this a backwards-compatibility issue. http://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpResponse.content For GZip support of iterators and similar large in-flight values, I think spooling to memory and disk, like file upload does, might be a reasonable solution, but still, .content is just a string, so it'll be difficult to keep compatibility. Just my opinion. I hope a committer overrules me. ;-) -- 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: Potential bug in select_related() as of Beta
We'll need your model definitions in order to help much. On Wed, Feb 17, 2010 at 2:54 PM, Steve wrote: > Hello all, > > I believe select_related is creating some extraneous joins in situations > where one is joining child models from a base model (model inheritance). > > Take the following SQL generated (dpaste here, probably more readable > http://dpaste.com/160677/) > > > > SELECT (fields) FROM `base_contact` > > > LEFT OUTER JOIN `consumer_consumer` ON (`base_contact`.`consumer_id` = > `consumer_consumer`.`id`) # ok > > > INNER JOIN `agency_program` ON (`base_contact`.`program_id` = > `agency_program`.`id`) # ok > > > LEFT OUTER JOIN `consumer_contact` ON (`base_contact`.`id` = > `consumer_contact`.`base_id`) # ok > > > INNER JOIN `base_contact` T5 ON (`consumer_contact`.`base_id` = T5.`id`) # > ?!? > > > # These next two are questionable, since they are joined on a LEFT OUTER (so > they may potentially not be there) > > > INNER JOIN `consumer_service` ON (`consumer_contact`.`service_id` = > `consumer_service`.`id`) > > > INNER JOIN `consumer_servicetype` ON (`consumer_service`.`type_id` = > `consumer_servicetype`.`id`) > > > LEFT OUTER JOIN `IR_contact` ON (`base_contact`.`id` = > `IR_contact`.`base_id`) # ok > > > INNER JOIN `base_contact` T9 ON (`IR_contact`.`base_id` = T9.`id`) # ?!? > > > WHERE `consumer_consumer`.`file` = 06-1757 ORDER BY `base_contact`.`date` > DESC > > > > > There are two joins I simply can't explain (marked "?!?"). Removing them > gives me my expected results. select_related in on case seems to correctly > create a LEFT OUTER, but then follows up by creating an unwanted INNER. > > Keep in mind I made a note about the 'questionable' join above, but even > removing that entirely creates the same problem. > > I'll be glad to file a ticket, if the issue is something other than my > ignorance. > > -Steve > > -- > 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: Potential bug in select_related() as of Beta
Erm, and the queryset creation.
Also, people are en route to PyCon, so responses may be a bit slow.
On Wed, Feb 17, 2010 at 3:30 PM, subs...@gmail.com wrote:
> http://dpaste.com/160722/
>
> class Contact(models.Model):
> program = models.ForeignKey('agency.Program')
> consumer =
> models.ForeignKey('consumer.Consumer',null=True,blank=True)
> date = models.DateField('Contact Date')
> notes = models.TextField()
> date_added = models.DateTimeField(editable=False)
> method =
> models.CharField(max_length=10,choices=choices.CONTACT_METHOD,\
> null=True,blank=True)
>
> # consumer_contact
> class Contact(basemodels.Contact):
> base = models.OneToOneField(basemodels.Contact,
> parent_link=True,related_name="consumer_contact")
> service = models.ForeignKey(Service)
> confidential = models.BooleanField(default=False,help_text='These
> notes will not be visible to general staff')
> group = models.ForeignKey(Group,null=True,blank=True)
> group_contact =
> models.ForeignKey('consumer.GroupContact',blank=True,null=True)
>
> def save(self, *args, **kwargs):
> super(Contact, self).save(*args,**kwargs)
>
> class Meta:
> permissions = (
> ("allow_confidential", "Can make contacts confidential"),
> )
>
> #ir_contact
> class Contact(basemodels.Contact):
>
> base=models.OneToOneField(BaseContact,parent_link=True,related_name='IR_contact')
> IR=models.ForeignKey(IR,blank=True,null=True)
>
> referred_from=models.ForeignKey(ReferralSource,related_name='IR_referred_from')
>
> referred_to=models.ManyToManyField(ReferralSource,related_name='IR_referred_to')
>
> information=models.ManyToManyField(Information,verbose_name='Information
> Requested')
>
>
> On Feb 17, 4:15 pm, Jeremy Dunck wrote:
>> We'll need your model definitions in order to help much.
>>
>> On Wed, Feb 17, 2010 at 2:54 PM, Steve wrote:
>> > Hello all,
>>
>> > I believe select_related is creating some extraneous joins in situations
>> > where one is joining child models from a base model (model inheritance).
>>
>> > Take the following SQL generated (dpaste here, probably more readable
>> >http://dpaste.com/160677/)
>>
>> >
>>
>> > SELECT (fields) FROM `base_contact`
>>
>> > LEFT OUTER JOIN `consumer_consumer` ON (`base_contact`.`consumer_id` =
>> > `consumer_consumer`.`id`) # ok
>>
>> > INNER JOIN `agency_program` ON (`base_contact`.`program_id` =
>> > `agency_program`.`id`) # ok
>>
>> > LEFT OUTER JOIN `consumer_contact` ON (`base_contact`.`id` =
>> > `consumer_contact`.`base_id`) # ok
>>
>> > INNER JOIN `base_contact` T5 ON (`consumer_contact`.`base_id` = T5.`id`) #
>> > ?!?
>>
>> > # These next two are questionable, since they are joined on a LEFT OUTER
>> > (so
>> > they may potentially not be there)
>>
>> > INNER JOIN `consumer_service` ON (`consumer_contact`.`service_id` =
>> > `consumer_service`.`id`)
>>
>> > INNER JOIN `consumer_servicetype` ON (`consumer_service`.`type_id` =
>> > `consumer_servicetype`.`id`)
>>
>> > LEFT OUTER JOIN `IR_contact` ON (`base_contact`.`id` =
>> > `IR_contact`.`base_id`) # ok
>>
>> > INNER JOIN `base_contact` T9 ON (`IR_contact`.`base_id` = T9.`id`) # ?!?
>>
>> > WHERE `consumer_consumer`.`file` = 06-1757 ORDER BY `base_contact`.`date`
>> > DESC
>>
>> >
>>
>> > There are two joins I simply can't explain (marked "?!?"). Removing them
>> > gives me my expected results. select_related in on case seems to correctly
>> > create a LEFT OUTER, but then follows up by creating an unwanted INNER.
>>
>> > Keep in mind I made a note about the 'questionable' join above, but even
>> > removing that entirely creates the same problem.
>>
>> > I'll be glad to file a ticket, if the issue is something other than my
>> > ignorance.
>>
>> > -Steve
>>
>> > --
>> > 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.
>
>
--
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: django + memcached: problem with limit of 1 mb
On Thu, Feb 18, 2010 at 1:34 PM, ramu...@gmail.com wrote: > Does anyone know why django can't keep a data bigger, than 1 mb in > memcached ? > > This is no big deal to cut big data to 1mb pieces before setting and > merge this pieces after getting from memcached. And this algorithm can > work transparently for users. I think Ramusus is asking for the low-level caching framework to split serialized data into 1MB chunks before storing in a bunch of keys if the data is larger than 1MB. He's not asking why there's a limit, he's asking for Django to work around the limit. I think the general reasoning for a 1MB limit is that it places bounds on access/storage times for a given key, and avoids an antipattern of storing really large objects in cache. I've wished for special-case side-stepping of the 1MB limit before myself, but I'd hate for it to be the default. -- 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: django + memcached: problem with limit of 1 mb
On Thu, Feb 18, 2010 at 2:21 PM, Forest Bond wrote: > Hi, > > On Thu, Feb 18, 2010 at 03:17:32PM -0500, Alex Gaynor wrote: >> On Thu, Feb 18, 2010 at 3:12 PM, Jeremy Dunck wrote: >> > On Thu, Feb 18, 2010 at 1:34 PM, ramu...@gmail.com >> > wrote: >> >> Does anyone know why django can't keep a data bigger, than 1 mb in >> >> memcached ? >> >> >> >> This is no big deal to cut big data to 1mb pieces before setting and >> >> merge this pieces after getting from memcached. And this algorithm can >> >> work transparently for users. >> > >> > I think Ramusus is asking for the low-level caching framework to split >> > serialized data into 1MB chunks before storing in a bunch of keys if >> > the data is larger than 1MB. >> > >> > He's not asking why there's a limit, he's asking for Django to work >> > around the limit. >> > >> > I think the general reasoning for a 1MB limit is that it places bounds >> > on access/storage times for a given key, and avoids an antipattern of >> > storing really large objects in cache. I've wished for special-case >> > side-stepping of the 1MB limit before myself, but I'd hate for it to >> > be the default. >> >> I don't see how that would be possible, sure storing it would be easy, >> but how do you retrieve it? Either you have to always try the >> "part-2" key (unreasonable overhead fro 99% of the use cases) or you >> have to store a tuple of (blocks, data) in the first slot, that's not >> a huge runtime overhead, but it feels like a large code-complexity >> overhead for a very rare usecase (I had no idea memcached even had >> these limits, and I use it pretty extensively). Attempting to store >1MB fails silently, so you may have hit this but never noticed. Having a hot >1MB miss kind of sucks. :-) > Such operations would also not be atomic. Concurrent attempts to update cache > would be problematic. > To be clear, I'm not arguing that this should be included in Django, especially by default. I can roll my own when needed -- that's sort of the point of the low-level API. But atomic semantics can be achieved with prefixing: http://www.aminus.org/blogs/index.php/2007/12/30/memcached_set_invalidation?blog=2 -- 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: 404 debug pages should show the name of the tried urlpattern - #9310
On Wed, Feb 24, 2010 at 11:14 AM, Tobias McNulty wrote: ... > I'm hoping this will spark a discussion about how we can work more > efficiently and put donated time to better use. I may be a bit biased, > because this is coming on the tail end of spending 2+ person hours trying to > reproduce a ticket in the PyCon sprint that, I later found out, two others > had done the same thing with a day earlier, but neither had indicated as > much in the ticket. The basic problem, as ever, is managing volunteer time. In this case, it looks like a failure of triage. A committer often looks for ready-for-checkin, and this ticket, despite having a patch, never got marked ready-for-checkin. Prompted by your question, I see that there are over 700 tickets in this status -- I'd say a ticket should fairly quickly clear this stage -- either be marked ready or marked patch-needs-improvement. But of course the triagers themselves are volunteers, doing relatively unglamorous work when they can. (And thank you to all triagers for their work!) http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&needs_better_patch=%211&has_patch=1&order=priority&stage=%21Ready+for+checkin There are over 200 bugs marked 1.2 -- even after features got booted to 1.3 (including yours), with the release date coming soon. I'm sure more will have to be pushed. James got to be the bad guy booting tickets for features late for 1.2-- some apparently due to workflow failure. But he's just following the workflow, too. > A couple ideas to get us started: > > 1) Reemphasize via documentation and/or training (and/or by reading this > message) the proper work flow for tickets (e.g., accept it when you start > working on it, post a comment when you're done, etc.): > > http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets I don't think documenting it more is the solution -- if people aren't clear on the process as documented, I certainly haven't heard that confusion. I think the issue is that documenting and doing are two different things. For example, I know that I should only have tickets assigned to me if I'm actively working them, but that hasn't stopped me from forgetfully breaking that rule pretty often. > 2) For each release, assign several people (I'd be happy to take a turn) the > task of searching through all outstanding tickets in the milestone in > question a couple weeks before the feature freeze and assigning > "committable" ones to specific committers. Maybe this ticket is an outlier, > but I expect there are others out there that are also getting missed. I'm > not sure if this means that the current way ticket triage is outlined to > work is just not happening, or if there are changes we need to make so that > it works more effectively: > > http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage This gets at the problem more directly -- we used to have a feature/bug classification, but it was abused -- lots of people marked things as bugs simply because they felt they were necessary, and hence not "features". Everything is miscellaneous, but if there is no consistent distinction between bug and feature, there's no point in having the field. I don't think we need a workflow that assigns committables to specific committers-- they're working and doing what they can, we already have a ready-for-commit sign, and (I presume) the issue isn't that they aren't committing as quickly as possible -- the # of ready-for-commit tickets has hovered between 15 and 100 for a year, and sits at 50 now. Tickets are being resolved quite a bit, so the inflow is roughly matching the outflow. What you're asking for, I think, is some sensitivity to the scope of a change vs. how long it's been pending. This is a pretty hard problem to address -- if it falls to triagers, you're back where we started of triaging not being able to keep up with the queue. It'd be nice if Trac stored time-stamped state transitions to reveal this sort of thing. That said, I wasn't aware that the # of untriaged tickets was that high-- if I had known, maybe I would have spent more time triaging. So I'm asking myself: where in the process are there places that workflow breaks down, and how can we make those places more visible? I'm presuming that if it were more visible, it would be better addressed -- but it may simply be the case that we need more volunteers to step into the break -- to stop filing their feature patches, and to start clearing the triage queue. http://docs.djangoproject.com/en/dev/internals/contributing/#triage-by-the-general-community -- 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-develop
Security concern: information leakage (even under SSL)
There's a new-ish security paper detailing how information can be gleaned by observing the sizes of secure responses. Summary here, which links to the original paper: http://www.freedom-to-tinker.com/blog/felten/side-channel-leaks-web-applications One possible mitigation is to add cover traffic in the form of padding so that the information is obscured. To that end, I hacked out a middleware. I'd like to get some feedback (testing, suggestions for improvement, etc) from the list. http://www.djangosnippets.org/snippets/1970/ Once it isn't broken in obvious ways, maybe we can have a security expert get further feedback and add to core? -- 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: Low-Hanging Fruit
On Mon, Apr 19, 2010 at 7:52 PM, Russell Keith-Magee wrote: > On Tue, Apr 20, 2010 at 5:20 AM, Don Guernsey wrote: >> How do I sign up to help? Is there an overall schematic for how django >> works? > > There's no official signup process; just dig in and get your hands > dirty. General guidance on how to get started can be found here [1]. For what it's worth, the homepage of Trac includes a "Getting Involved" section: http://code.djangoproject.com/#Gettinginvolved This includes a link to a wiki page with low-hanging fruit: http://code.djangoproject.com/wiki/LittleEasyImprovements It looks like that list isn't too actively maintained, but it might be useful. -- 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: Process discussion: reboot
On Mon, Apr 19, 2010 at 9:19 AM, Jacob Kaplan-Moss wrote: ... > So: here's your chance. You have suggestions about Django's > development process? Make them. I'm listening. I have a perception that there are some phases of the ticket lifecycle where things get stuck -- I think that if you look at this diagram: http://docs.djangoproject.com/en/dev/_images/djangotickets.png there is a pretty clear flow, and people are encouraged to pitch in where ever they feel it might help. But in practice, it seems that some of the edges become queues, and some tickets sit in that queue for a long time -- either because the next step for that ticket isn't obvious, or because there's a shortage of triage attention on that particular ticket. Earlier in the other thread, someone claimed there were hundreds of patches ready (but ignored), while the response was "no, those tickets aren't actually ready" -- the issue was a recognition of procedure, in that case. Even so, the perception of ignored tickets is part of the problem-- whether tickets are actually ignored or not, the perception still would discourage contribution. I'd like to highlight tickets that have sat in each queue for a period of time -- a summary of min, max, mean time in queue (over time), and a detail view to sort tickets by age in queue, etc. I know this isn't well-supported by Trac, but Joseph pointed me at the XML RPC API--- the pieces are there. I never worked on it; generally, I felt that the triagers are doing what they can and if anything, my time would be better spent fixing bugs or triaging. But this debate has been at least partially about responsiveness and the perception of inclusion. Triagers, commiters, off-put contributors, do you think this sort of view would help the workflow and understanding of the ticket status? -- 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: Cujo .... an experimental branch of django.
Tom, it may be inconvenient at this point, but please consider forking the github django repo so that upstream pulls can be handled more easily. On Wed, Apr 21, 2010 at 11:46 AM, Kevin Howerton wrote: ... > I think Cujo (the name at least) has been abandoned and I have joined my > efforts with some other developers also interested in contributing to an > experimental branch. > > http://github.com/tomxtobin/django-experimental > http://groups.google.com/group/django-experimental?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: managing javascript and css resources
On Wed, Apr 21, 2010 at 11:40 AM, Owen Nelson wrote: > Jacob Kaplan-Moss wrote: >> If you'd like to look into it, a good place to start would be by >> looking at the existing static asset management tools in the ecosystem... >> > I most certainly would like to. I'll prepare a "report" with my findings. I'm an enthusiast on this topic -- if you haven't yet, have a look at YSlow and Souder's two books: http://www.stevesouders.com/hpws/ http://www.stevesouders.com/efws/ FWIW, I think GWT took an early lead with image bundling (automated creation of sprites). Lots of frameworks have caught up to that, but they may have improved their lead since I last looked. More recently, Cappuccino added some great support for bundling-- in particular, I was interested in their cross-browser approach for inlining content. http://cappuccino.org/discuss/2009/11/11/just-one-file-with-cappuccino-0-8/ These aren't something we could easily incorporate. Just automating JS and CSS bundling and compression would be a big help. This is a good place to start on that: http://stackoverflow.com/questions/28932/best-javascript-compressor I've played off and on with making great asset handling for Django. We had something to do automated spriting at Pegasus, but I don't have that code any more (their IP). For example, avatars for the X most frequent commenter's avatars: http://media.pegasusnews.com/pegasus/bundles/img/8a339a7ffaf8e89432732f3d7c67ede6.jpg In general, I found it difficult to provide great support without some heavy JS, and picking a JS framework would make it difficult to include in core. Also, we used a media server 404 handler for thumbnailing, which is outside the range of Django; maybe Sorl has a better answer here. This presentation has some nice ideas, too: http://assets.en.oreilly.com/1/event/29/The%20Secret%20Weapons%20of%20the%20AOL%20Optimization%20Team%20Presentation.pdf (SONAR, particularly-- nothing is faster than skipping load of something that isn't actually needed.) One more idea that I haven't seen anyone doing yet is to inline content that would miss the browser cache, and background load any assets likely to be needed later. Roughly speaking, there would be a cookie whose value is a bloom filter of which assets have been downloaded to local cache. On a request, the server would inline all assets needed for the page, and set up background loading of any high-priority assets, updating the cookie as loads occurred. Total transfer would be higher (due to overlap between inlined and backgrounded loads), but perceived response time should be hugely improved. Thanks for your interest in this topic! -- 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: Cujo .... an experimental branch of django.
On Wed, Apr 21, 2010 at 1:14 PM, Tom X. Tobin wrote: ... > There are no formal plans (on experimental's side) to merge anything > from experimental to trunk. Anyone is welcome to package up code from > experimental and champion a change for inclusion in Django proper, but > it won't be me; I'm done working with patch files and Trac tickets. > :-) This will be pretty difficult to pull off unless there are feature branches in -experimental. Will you recommend that, at least? -- 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: Cujo .... an experimental branch of django.
On Wed, Apr 21, 2010 at 1:47 PM, Kevin Howerton wrote: > From the github: > > "* Commits should be atomic: they should each encompass a single logical >change that works on its own. You can use "git rebase --interactive" to >collapse multiple commits into a single commit before pushing your code >up for contribution." > > I think the idea is to basically have feature branches that are pushed back > into Tom's repo as atomic commits... That Should make things relatively easy > to deal with right? > Assuming nobody ever pushes a bug as a public branch commit -- 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: Process discussion: reboot
On Thu, Apr 22, 2010 at 3:26 PM, Gabriel Hurley wrote: > On Apr 22, 1:21 pm, Adam Nelson wrote: > >> 2. Assign all of these tickets to 1.3 and nothing else: >> >> http://code.djangoproject.com/query?status=new&status=assigned&status... > > A, only 900 tickets to work through for 1.3? Don't go too easy on > the core team! ;-) To be clear, this is why the triage process exists. We need more people to look at tickets, review them for the standards that Django has set (good code, test coverage, documentation for any new features) and mark them "ready for checkin". The subset of tickets that achieve "ready for checkin" then take a commiter's time for final review and merge. -- 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: Process discussion: reboot
On Thu, Apr 22, 2010 at 4:36 PM, Adam Nelson wrote: > I guess I'll jump in and start triaging. What about a ticket like > this: > > http://code.djangoproject.com/ticket/2284 > > Super-ambiguous. There are dozens of tickets like this that are > frozen in time with no way for anybody to know what's going on. Maybe > there just needs to be a better way to handle this type of ticket? > First, thanks for taking the time to look with triaging in mind. There may be dozens of tickets like this, but that's a small portion of 900. :-) In any case, yes, very old tickets may be inadvertently fixed or left open, or they may still be accurate, but have bad patches on them. In this specific case, I think the current status is captured in comments 11 through 14 -- that the logic for executing initial SQL breaks in cases where extended SQL syntax (such as pgsql's DECLARE) includes quoted text, etc. You can see the Malcolm objected to the latest patch in 11, and ScottAnderson objected to it in 13. Certainly, the patch needs improvement because it doesn't include any test cases. Possibly, the patch as-is isn't good for the reasons Malcolm listed, but it's hard for me to tell without doing my own testing. I'd mark patch-needs-improvement. If you're feeling more ambitious, I'd suggest coming up with a set of initial SQL files that exercise the assumptions of the loading code. If it's helpful, I like this summary of unit testing points: http://media.pragprog.com/titles/utj/StandaloneSummary.pdf -- 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.
Trac workflow assistance (commiter feedback needed)
Commiters and triagers, I've gone through the contributing doc and tried to identify places that tickets might get stuck (or other places that automation might smooth the process). If you could take a few minutes to give feedback on the list, hopefully prioritizing in your named column with +/- 0/1, it'd help me focus effort. http://spreadsheets.google.com/ccc?key=0ApFMbbFef2aVdE1TZThZY01ValRKUUVOT1oxck1VaWc&hl=en I added people from the commiter page; we still don't have triagers named publicly, I think, and so didn't hazard an incomplete list of triagers. Please just add yourself if you're a triager and would like to vote. Also, I'm planning on building the tool using the XMLRPC trac plugin (I'm assuming the live app can't easily have access to the DB, or that the RPC API's abstractions are useful at the app level). Correct me if I'm wrong. In any case, I'd like to have a local copy of the trac DB so that I can be abusive to the RPC API while testing/building, work offline, etc. Can a DB dump be shared? -- 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: Trac workflow assistance (commiter feedback needed)
On Fri, Apr 23, 2010 at 11:32 AM, Russell Keith-Magee
wrote:
...
> 2: Would be useful as a work list for people looking for. It would
> also be useful if tickets could be auto-disowned; i.e., if there's no
> activity from the owner after a month, post a comment asking for a
> status update; if no activity after another month, remove the
> ownership. This might get annoying for long-lived tickets with an
> owner that has a vested interest, though.
(I put numbers in the 1st column in case people decide to sort later.)
Thanks for the detailed feedback. I was mostly brainstorming based
off the doc. If you have other suggestions, they're welcome. I'm
happy to exclude things that aren't useful -- less work to be done.
But on the objection of people that won't follow the process -- to
some extent, all of the failings I'm hoping to make more visible here
are failures to follow the process. As one example, if a ticket with
a patch sits unreviewed for weeks, that's a failure. Keep in mind I'm
not blaming anyone for this problem -- I just think there's not enough
visibility when these failures occur. Similarly, if a person is
willingly ignoring the process and has a history of it, that's a basis
of reputation -- one that's recognizable, not just in the
triager/commiter's head, but by anyone looking at the history.
Frequent contributors are not the only audience for this tool -- I'm
trying to help answer the question -- where is help most needed right
now?
With that perspective, does your feedback change?
In any case, I plan to do whatever people agree is most useful first.
> 5-10: The most useful of the lot for me personally. An automated
> process that applies patches and runs tests would be nice; if it can
> autocheck the appropriate flags ("patch needs improvement", "needs
> tests" etc) that would be even better.
I recognize running tests w/ regressions pass would be useful, but
it's getting into CI-land -- once we have some CI infrastructure in
place, I'd be happy to use that.
I think automatically moving patches that don't apply cleanly to
patch_needs_improvement automatically would be a useful first step.
> There are edge cases that will make this difficult; e.g., patches that
> span multiple diffs, or tickets where the submitter provides multiple
> alternative patches.
Yeah, hmm. I'll have to think about this. Multiple partial patches
is a bug, IMHO, but alternative patches is probably good practice.
> I'm also not sure if a direct email or adding a comment to the ticket
> in trac would be the best approach. I suspect a comment would be
> better, since it provides a public record of the automated reporting
> activity.
Sure, probably I was premature to say what to do when X goes wrong. :-)
> 12-14: Nifty stats, but I'm not sure they would help much
I'm basically hoping to give guidance on whether we're bailing water
fast enough. Again, probably not a core committer issue, but perhaps
will persuade people to work an existing ticket rather than adding a
new one, or to organize a sprint, etc.
> 15-17 would be useful if we wanted to audit the work of volunteers,
> but that's not really something we do. I keep a rough eye on every
> ticket change as they come in; if something looks way off, I'll jump
> on it, but otherwise I just live and let live and let the crowd sort
> it out.
Do you feel it's a burden to keep that eye on it? Do you think stuff
slips through? I mostly agree with you -- don't look a gift horse in
the mouth, etc.
> 18: I'd be interested to see what this produces. My gut tells me that
> tags aren't used often enough (or consistently enough) for this to
> provide any real patterns. However I might be wrong. If it works, it
> might be a handy way to work out common themes that need a broader
> approach.
Yep, I had the same thought, probably would only work well if there
was some guidance on the existing vocabulary.
> If you're looking to implement this as a standalone thing, it probably
> *could* access the Trac DB directly, but in the interests of
> everyone's sanity (including Trac's) it's probably best to keep to
> public interfaces like XMLRPC.
>
> However, it's also possible that some of these features would best be
> implemented as a Trac plugin.
I'm not sure the RPC interface has all the pieces needed, but I'd
prefer to get as far as I can with it.
What version of trac are we on? I'll look to see what
incompatibilities there are between 0.x and 0.y once I know that to
try and decide between the options.
> I'd also suggest that before you embark on a big Trac-specific
> tool-building exercise that we investigate what we could gain by
> moving to another bug tracking tool.
Ah, yes, I was afraid this would come up. :-)
This quickly veers into the DVCS debate, python-vs-*, etc. If there
are trackers that are substantially better, I'm interested in hearing
about them, but I imagine it'll be more heat than light to try to find
something that solves our ailmen
Re: Django unit test coverage
There's an open ticket on it, though no progress recently. http://code.djangoproject.com/ticket/4501 http://groups.google.com/group/django-developers/browse_thread/thread/7e4dae3534c8a8c3/5d49f4d17cb1bed0 George Song's project: http://opensource.55minutes.com/trac On Wed, Apr 28, 2010 at 10:36 AM, Vinay Sajip wrote: > Can someone please point me to any information about stats on coverage > of Django's own code by its unit tests? I searched for "Django test > coverage" and "test coverage site:djangoproject.com" but I'm getting > pages about testing code which uses Django using Django's test > infrastructure, and I couldn't spot anything which refers to coverage > of Django's own code. If I've missed something blindingly obvious, > sorry for the bother, but a pointer would be appreciated! > > Regards, > > Vinay Sajip > > -- > 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: Trac workflow assistance (commiter feedback needed)
On Sun, Apr 25, 2010 at 1:27 AM, Stephen Wolff wrote: >> I recognize running tests w/ regressions pass would be useful, but >> it's getting into CI-land -- once we have some CI infrastructure in >> place, I'd be happy to use that. >> >> > > In case you missed it, there already is some CI infrastructure a bunch > of servers made available to django for testing via Hudson: > > http://hudson.djangoproject.com/ > I knew Eric was noodling on it, but didn't know it was up. Eric, two questions: 1) is there (or could there easily be) a way to run the suite against uncommitted patches (or a mirror repo with branch-per-patch attempt)? 2) in general, what happens if a malicious patch is run? I'm not looking for total sandbox here -- but at least the understanding that putting a machine into the test system means taking the risk that the machine gets rm -rf'd or similar. (Does anyone know of a general container for testing untrusted patches safely?) -- 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: Trac workflow assistance (commiter feedback needed)
On Sun, Apr 25, 2010 at 5:37 PM, yml wrote: ... > While spending some more time looking at launchpad.net I stumbled upon > another very neat feature you can also sort the bug by heat [1]. Thanks for this -- I'll be reading it shortly. -- 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: Trac workflow assistance (commiter feedback needed)
On Fri, Apr 23, 2010 at 10:26 PM, Russell Keith-Magee wrote: ... >>> I'm not a huge fan of Trac - it's >>> got lots of quirks and bugs that annoy the bejezus out of me, >> ... >> Perhaps upgrading would get us some distance? > > Possibly. Was that you volunteering to become our Trac jockey? :-) > I've read the TracHacks wiki, it doesn't seem too bad. ;-) I've just set up trac locally for testing (0.10.5, hoping that's accurate), auth/xmlrpc working, hooray. To be clear, I'm not against switching to a better ticket tracker, but I haven't heard one proposed. I'll take a look at RedMine and/or steal ideas from launchpad -- but writing a new tracker isn't the problem I'm trying to solve. If people want to propose other trackers they've been happy with, please do. It would save me a lot of time if there was something that already addresses my concerns. But meantime, I'm doing work against trac, since it seems the shortest path to solving the problem I'm seeing. -- 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.
Upgrading Trac
Does anyone have crib notes on what upgrading from (presumed) 0.10.4 to 0.11.7 would buy us? If not, I can go read changelogs. Separate from that, I'd like to open discussion on what it would take to do the upgrade. Who has access to the server? What do I need to do to convince to let me upgrade? This is purely exploratory-- I imagine the workflow stuff I'm trying to do doesn't really need the upgrade, but Russ complained a bit about nits, so I thought I'd at least see what's what. -- 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: Upgrading Trac
As long as I'm here, how much interest is there in review board? http://code.google.com/p/reviewboard/ On Fri, Apr 30, 2010 at 10:06 AM, Jeremy Dunck wrote: > Does anyone have crib notes on what upgrading from (presumed) 0.10.4 > to 0.11.7 would buy us? If not, I can go read changelogs. > > Separate from that, I'd like to open discussion on what it would take > to do the upgrade. > > Who has access to the server? What do I need to do to convince to let > me upgrade? > > This is purely exploratory-- I imagine the workflow stuff I'm trying > to do doesn't really need the upgrade, but Russ complained a bit about > nits, so I thought I'd at least see what's what. > -- 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: Upgrading Trac
On Apr 30, 2010, at 10:56 AM, Russell Keith-Magee > wrote: On Fri, Apr 30, 2010 at 11:11 PM, Jeremy Dunck wrote: As long as I'm here, how much interest is there in review board? http://code.google.com/p/reviewboard/ ... 5) The patch is missing some critical component like tests or docs ... Cases 5 is annoying, particularly if it looks like the patch would be in case 1 or 2 if only the contributor had written a test case. This is a major time sink, but a code review tool isn't needed here - the 'needs tests' flag is all that is required. I guess I didn't realize that commiters were writing tests and docs for otherwise good patches. I assumed those just immediately got a needs_* flag and sat until an interested party finished it. Ideas how we can fix this? -- 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: Silently replaced session_key
On Wed, May 5, 2010 at 2:45 PM, George Sakkis wrote: ... > I'm repeating myself here but if the intention is to really disallow > user-provided ids. it can be done more clearly: raise an exception if > the key does not exist and make the session_key property read-only. > Now it seems like a bug that you can sort of work around by setting > the key just before saving. Allowing an attacker to predictably raise exceptions might be bad. > By the way, this does not apply to all backends; file SessionStore for > example uses passed ids as is. Whatever the desired behavior is, it > should apply to all backends, so the relevant logic should move to > SessionBase. I filed a ticket for this: http://code.djangoproject.com/ticket/13478 -- 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.
NB: New leader in group posting
After years of Malcolm's legend response rate leading the chart, I'm pleased to point out that there's a new name in all-time most-posted to django-developers: http://groups.google.com/group/django-developers/about (It is my hope that this sly ploy brings Malcolm back to activity.) -- 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: djangocon.eu sprints (was Re: Class based generic views in 1.3?)
On Fri, May 14, 2010 at 9:12 AM, Reinout van Rees wrote: ... > I'm used to Plone sprints and there's usually some "make sure you have svn > access to x and y" stuff best handled *before* the sprint, that's why I'm > asking :-) This might help: http://code.djangoproject.com/wiki/Sprints If you have questions after that, let me know -- I'd be happy to improve that page. -- 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: djangocon.eu sprints (was Re: Class based generic views in 1.3?)
On May 14, 2010, at 4:02 PM, Reinout van Rees wrote: That page is fine. The page linked from there that tells you how to set up an svn trunk django got me frowning a bit: "symlink django trunk into your system python". Ehm, I'd rather isolate it with virtualenv or buildout to keep trunk's stuff out of the rest of my django projects. So: is that just a missing piece of documentation? Or is the virtualenv kind of isolation rarely done when developing on trunk? I'm pretty sure it's just that it was written before virtualenv was made. I should be updated. I use ve on dj dev often. -- 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: Default ordering on User model
On Fri, May 21, 2010 at 7:38 AM, tiemonster wrote: > Is there a reason that the default ordering on the User model is by > pk? Would it be a reasonable request to ask that the default ordering > for this model be username? I have several models that have a m2m to > the User model, and it's very hard to find someone to add using the > admin when the users are in pk order. I wanted to test the waters > before opening a ticket. Actually, the user model's default ordering used to be by username-- but in large deployments, this needlessly caused significant overhead when using the User model. Presuming you have many users, your admins will likely still use the search field to find the user they need. Even so, you could create a custom ModelAdmin for User, specifying the ordering option: http://docs.djangoproject.com/en/1.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.ordering -- 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.
Request: 1.3 proposals include "Proposal" in subject
Would help keeping track of proposals. :-) -- 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: Admin sloooow with postgresql and a 160k record table
Found via google site:... http://code.djangoproject.com/ticket/8408 On Thu, May 27, 2010 at 4:58 PM, Alex Gaynor wrote: > On Thu, May 27, 2010 at 11:54 PM, Marcob wrote: >> On May 27, 11:13 pm, Jacob Kaplan-Moss wrote: >> >>> I thought there was already a ticket open for this, but I can't seem >>> to find one. Can you open a ticket so that we don't forget? >> >> To posterity: http://code.djangoproject.com/ticket/13643 >> >> :-) >> >> Ciao. >> Marco. >> >> -- >> 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. >> >> > > FWIW Jacob was wrong, there is another tiket, but I can't find out now > (yay trac search ;)), so don't be offended if I close your ticket. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me > > -- > 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: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]
On Wed, Jun 2, 2010 at 11:20 AM, Rob Hudson wrote: > Also, at the time, many of the jQuery autocomplete widgets were in a > state of flux or had some warts. Our (Jannis and my) idea at the time > was to write our own from scratch, custom and optimized for Django. > That looks to be about a year ago so the state of things is probably > much different today. (Or not?) jQuery UI 1.8 newly ships with an autocomplete widget: http://jqueryui.com/demos/autocomplete/ -- 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: Beating on an old issue; counter intuitive cascade deletes on foreign keys
On Tue, Jun 8, 2010 at 7:30 AM, Peter Bengtsson wrote: > I've now had to learn this the hard way by having real live data > deleted from my database on two production projects and it pisses me > off big time every time. > > I can accept that NOT nullable foreign relations cascade the delete > but not if they have null=True on them. Example: Actually, this looks to be fixed in 1.2. What version are you running? Closed ticket (with test cases) here: http://code.djangoproject.com/ticket/9308 -- 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: Admin patches
On Wed, Jun 9, 2010 at 3:52 PM, Simon Meers wrote: ... > Did you also know you can run any desired subset of tests? E.g.: > ./runtests.py --settings=test_sqlite admin_inlines admin_views > -- > Ran 145 tests in 29.500s Thanks for pointing this out, Simon. I thin it could be clearer in the contributing/testing docs. Running a subset while working up a patch can help speed things along quite a bit, but do take care to run the whole suite before pushing the patch -- the committer will have to do this anyway, and a failure missed this way will just delay inclusion. -- 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: Project-wide cache prefix (low-level API)
On Sun, Jun 13, 2010 at 7:18 AM, lenz wrote: > Could you share your code with us? > Thanks you! This might help: http://gist.github.com/425403 -- 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: Session overload
On Fri, Jun 11, 2010 at 1:43 PM, Jan Murre wrote: > On Fri, Jun 11, 2010 at 3:13 PM, Tom Evans wrote: >> On Fri, Jun 11, 2010 at 11:41 AM, jjmurre wrote: >>> Hi, >>> >>> I am using long living session in the database backend. Because of >>> Robots I am getting a huge amount of sessions. I googled if there is >>> some kind of Session middleware that does user-agent blacklisting and >>> does not create new sessions in the database for Robots accessing the >>> site. I did not find anything. Would this be possible at all? FWIW, sessions should only be written to the DB if they are modified, and you can avoid that by checking User.is_authenticated first. -- 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: 'exists' parameter for pre_save signal
On Tue, Jun 15, 2010 at 10:46 AM, George Sakkis wrote: > ...In the current save_base() > implementation, pre_save is sent before the instance's existence is > determined, so I'm not sure if postponing it would break existing > code. If there is no backwards compatibility issue, I can open a > ticket and send a patch for it. Well, a significant difference is that pre_save right now can cancel a save before a query to determine existence is needed (0 vs 1 or 2 queries). I'm not sure how many people really use pre_save's cancellation feature, but I think we'd need some confidence that moving wouldn't cause a problem for people counting on the 0-query cancellation that's available right now. -- 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: 1.3: Start deprecating mod_python?
On Tue, Jun 22, 2010 at 6:48 PM, Alex Gaynor wrote: ... > http://code.djangoproject.com/browser/django/trunk/django/core/handlers/profiler-hotshot.py > > (Honestly does anyone use this?) I think I did a few times in the dark days before debug-toolbar, etc. -- 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: contrib.admin:list_editable - ForeignKey Performance is O(m*n)?
On Wed, Jun 30, 2010 at 2:04 AM, chadc wrote: ... > 3. Overriding the ForeignKey widget with a custom CachedSelect widget. > ... > > PS: For the sake of posterity, I have included the code for my > CachedSelect widget. Yes, I am aware that using regular expressions to > parse the key is a nasty hack. If you have any better ideas, please > let me know! For clarity of what's going on here, would you mind posting an example model? -- 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: contrib.admin:list_editable - ForeignKey Performance is O(m*n)?
On Thu, Jul 1, 2010 at 12:40 AM, chadc wrote: ... > The jist of what I am wondering is if the changelist is going to allow > editable ForeignKeys, should it be caching the choices rather than > hitting the database every time? Yep, your models and explanation are clear. I'm not sure that CachedSelect is a good solution; it seems like there's a general problem with repeated queries within ModelFormSet, not just admin-- it's just cropping up here. I'll try to look at it by tomorrow. File a ticket and let me know the number? -- 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: django changes some chracters in on my website
Django loves all characters equally, including umlauts. I suspect you're seeing the effects of auto-escaping: http://docs.djangoproject.com/en/1.2/topics/templates/#id2 You've mailed the django-developers list which is for development *of Django itself*. The proper mailing list about *using* Django is django-users. Please send this message to django-users unless you're proposing a change to Django. http://groups.google.com/group/django-users -- 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: Cleanup Signal
Note that the project is no longer active here; see this repo: http://github.com/django-extensions/django-extensions/ On Fri, Jul 2, 2010 at 2:44 PM, hcarvalhoalves wrote: > I guess you'll like the jobs abstraction from django-command- > extensions [1] > > Besides that, I don't see the need for anything to integrate inside a > single "clean" command. It's not like the management commands provided > by Django are hooks, you can and should be making yours for each > specific need. Just register new management commands, and if you are > bothered of having many commands to run with different names, you can > run all together with one job and setup crontab just once. Having a > defined set of "management signals" that works for everybody is IMHO > impossible. > > [1] http://code.google.com/p/django-command-extensions/ > > On 1 jul, 06:36, Gregor Müllegger wrote: >> Hi, >> >> its very convenient for most projects to have cleanup-tasks that run >> out of a request-response cycle. The best example is in django core. >> The `cleanup` management command deletes expired session instances. >> But in most cases there are more tasks like this: deleting expired >> registrations/email verification codes, removing expired codes for >> captchas, removing thumbnails of images that don't longer exists etc. >> >> The list is endless. Until yet most applications provide >> their own management command for this (cleanup_thumbnail, >> cleanup_registrations...) - IMO there should be a better way to only >> need one cronjob that can do all the work. >> >> My suggestion is to add a cleanup signal that is called in django's >> cleanup management command. This would make custom cleanup code easier >> to use. >> >> What are your opinions about a cleanup signal? >> >> Maybe it would even make sense to have a more generic signal that fires >> when a management command is called and one when the command finishes. >> This would make sense e.g. for `validate` management command to have >> custom validation logic etc. >> >> (Sorry if the mailing-list is the wrong list to propose this feature >> request, is it better to open a ticket first?) >> >> -- >> Servus, >> Gregor Müllegger > > -- > 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: Suggestion: Better handling of HTML entities by slugify()
On Wed, Jul 7, 2010 at 8:27 AM, Russell Keith-Magee wrote: > On Wed, Jul 7, 2010 at 4:00 AM, C. Alan Zoppa wrote: >> I occasionally enter special characters as HTML entities (e.g. “, >> ®, etc.) in an object's title. I feel that slugify() would be more >> useful if these were removed entirely from the returned slug. For example: >> At the moment, a title of “Object Title ” returns the slug >> "ldquoobject-titlerdquo." It is my opinion that "object-title" would be more >> useful in this situation. > > I can't think of any way that ldquo et al could be considered helpful > in a slug, so yes -- this sounds like a bug to me. Storing HTML (or other markup) in strings is meaningful, but I don't see how slugify can generally correct for format-to-slug. If you want no-HTML slugs, how about: === from django.template.defaultfilters import slugify from django.utils.html import strip_entities slug = slugify(strip_entities(your_html)) === ? -- 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.
djangoproject.com hiccup: community section configured wrong
Did someone fiddle with the server recently? Scott Turnbull join pointed out a problem on http://www.djangoproject.com/community/ -- some links point to example.com. I looked just now, and it looks like the importer ran incorrectly for one run -- from "My thoughts on DjangoCon Berlin 2010" to "First Post" on the run at July 9, 2010 at 4:04 PM. Any ideas? -- 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: djangoproject.com hiccup: community section configured wrong
On Fri, Jul 16, 2010 at 4:29 PM, Alex Gaynor wrote: ... > Are we sure it wasn't a problem with whoevers blog that is? D'oh. You're right, I thought since it affected multiple entries, it must be multiple sites, all those entries are from the same site. -- 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.
Fwd: djangoproject.com hiccup: community section configured wrong
-- Forwarded message -- From: Jeremy Dunck Date: Fri, Jul 16, 2010 at 4:33 PM Subject: Re: djangoproject.com hiccup: community section configured wrong To: django-developers@googlegroups.com On Fri, Jul 16, 2010 at 4:29 PM, Alex Gaynor wrote: ... > Are we sure it wasn't a problem with whoevers blog that is? D'oh. You're right, I thought since it affected multiple entries, it must be multiple sites, all those entries are from the same site. His site is fixed now. -- 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: Documenting new features: built-in obsolescence of the "versionadded" tag.
On Fri, Jul 23, 2010 at 11:18 AM, Tobias McNulty wrote: > I agree. It's a little odd seeings things flagged "New" that have been > around since 1.0. I also like your proposal of removing the notes for > unsupported versions. > Tobias I think maybe the rendering can just be altered to ignore tags with the old values? -- 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: Can a core developer or ticket triager please look at #6932
On Sun, Jul 25, 2010 at 1:13 PM, faldridge wrote: > I have an open ticket that adds a get_flatpages template tag to the > flatpages contrib app to retrieve and iterate over all the installed > flatpages for a given site. > > The ticket is #6932; it is in the 'accepted' triage stage with a patch > that applies cleanly to trunk (r13446), including documentation that > builds successfully. > There's a bit of muddy water since DrMeers attached a new patch, but Justin Lilly signed off on the prior patch. I haven't had time to check DrMeers changes. :-/ -- 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: Allowing models to influence QuerySet.update
On Wed, Jul 28, 2010 at 12:02 PM, Jacob Kaplan-Moss wrote: > Hi Dennis -- > > I'm not totally thrilled with this proposal, though perhaps there's > some points I just don't get. As it is, though, I'm -0 on the idea. > update() is supposed to be an optimization that's "close to the metal" > of the database; adding potentially-hidden slow code to the mix rubs > me the wrong way. > > In general, signals are a very dangerous thing: they make side-effects > non-obvious, and make it hard to discover what's going to be called > when. They also add a not-insignificant overhead. I'm of the opinion > that they should be avoided except where critically important, and I > don't see this to be one of those cases. > > On Wed, Jun 16, 2010 at 7:38 AM, Dennis Kaarsemaker > wrote: >> However, I'd like to have a bit more control over what update() does, >> e.g. for auditing purposes. I know that I can simply write a few lines >> of code near every update() call to do what I want, but that violates >> DRY. > > I think you may have missed a few possibilities in your search for a > DRY solution to the problem. If I was trying to add some audibility > around QuerySet.update() I would: > > 1. Define a QuerySet subclass that extended update() to provide > whatever hooks I needed (this could be a signal, perhaps, or just the > code). > > 2. Make a Manager subclass that returned by QuerySet object from > get_query_set(). > > 3. Use said Manager (or a subclass) on each model that I want the behavior on. > > This gives me control over *where* my added behavior happens, and it's > completely clear to anyone reading the code that I've got a custom > Manager; they can follow the trail to the update behavior. A bit of a seque, but I think this is a useful way to DRY this common need: http://djangosnippets.org/snippets/2117/ -- 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: Allowing models to influence QuerySet.update
On Wed, Jul 28, 2010 at 2:46 PM, Jeremy Dunck wrote: ... > A bit of a seque, but I think this is a useful way to DRY this common need: > http://djangosnippets.org/snippets/2117/ segue, but non sequitur is what I meant in any case. :-) -- 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: Querysets with "only()" and "defer()" slower than without?
On Thu, Aug 5, 2010 at 4:32 PM, OverKrik wrote: > I am performing every test 10 times, excluding one fastest and one > slowest result, restarting db every time and performing 10 000 request > to warm db before measuring execution time. > Just in case, I've tried running tests in only-full-only-full and > defer-full-defer-full patters and got same results. This sounds like a pretty good test. Can you attach the code? I'm sure it's not pretty, but I've been meaning to work on benchmarks for a long time and it'd be a shame to not reuse your effort. -- 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: Trac issues review
On Sun, Aug 15, 2010 at 2:03 AM, burc...@gmail.com wrote: > Hi Russell, > > On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee > wrote: >> On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com wrote: >>> I had few useful thoughts about changing the way Django development >>> contributions gets accepted and committed -- but all I get from this >>> mailing list that all attempts to improve any process is just a waste >>> of time. >> >> That's not entirely fair. ... Sorry, I've missed some context here -- can someone point me to the beginning of this thread? -- 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: Trac issues review
On Sun, Aug 15, 2010 at 11:33 AM, burc...@gmail.com wrote: > Hi Jeremy, > ... >> >> Sorry, I've missed some context here -- can someone point me to the >> beginning of this thread? > > Thread "#11834: colorized debug page. Assigned to buriy" ( > http://groups.google.com/group/django-developers/browse_thread/thread/bd43e2e040a17784 > ) is the beginning. > Thanks, got 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-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.
Buglet in tutorial 2
At: http://www.djangoproject.com/documentation/tutorial2/ This: "By default, Django displays the repr() of each object." It actually uses str() now, right? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Solving the POST-data-lost-after-redirect problem
On 6/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > * THROW ERROR ON POST: The CommonMiddleware, when adding a slash and > redirecting, can check for POST data. If it finds any, it somehow logs > the error or otherwise alerts the developer. Maybe if DEBUG=True it > can actually display an error, with a custom-built message saying "You > need to change so-and-so form action to so-and-so URL"? I can't think > of any case in which a POST to a page that needs to be redirected > would be intentional, and if we only do it for DEBUG=True I think this > may be acceptable. Similar to this, but: Django can already send emails on 404. Why not add a similar thing to RedirectFallbackMiddleware so that if adding a slash and action = POST, send email complaining? Between DEBUG=True and the fallback error email, I think it'd be pretty quickly caught. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Solving the POST-data-lost-after-redirect problem
On 6/7/06, Luke Plant <[EMAIL PROTECTED]> wrote: > I already wrote a validator app that checks > outgoing HTML for validity, using a middleware to intercept the > response. It also stores all details of failed pages so you can go > back to them, which would be overkill in this case. Hmm, this sort of thing suggests that "email when bad stuff happens" would be a nice general feature. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Middleware fiddling
Is there a reason _request_middleware's are called in the BaseHandler, while _response_middleware's are called in the subclass (i.e. ModPythonHandler)? Also, in BaseHandler.load_middleware, I noticed that an exception loading any middleware will leave the middlewares not None, but also not valid since remaining middleware's will not be loaded. Is this a philosophical choice (i.e. you don't want to load later middleware's as they may depend on earlier ones or, maybe, you don't want to repeatedly try loading a broken middleware stack) or an accident of implementation? If philosophical, I think leaving the middleware stack totally unloaded is safer than leaving it partially loaded after failure of some component. Finally, if I understand the code correctly, it'd be useful to document that middleware can cause the response's iterator to be evaluated before it's actually ready to be rendered. Which is to say, if the iterator is intended to manage resource usage to stream large or long responses to the client, that intent may be foiled by using middleware like gzip. I know these are pretty fine points. I'm just getting more familiar with django's internals and making notes as I go. Cheers, Jeremy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Solving the POST-data-lost-after-redirect problem
On 6/7/06, Steven Armstrong <[EMAIL PROTECTED]> wrote: ... > GET /some/url/?cm_data_id=78fsd8fasdf7ad8asaf7889sdf > > - load POST/GET data from /tmp/78fsd8fasdf7ad8asaf7889sdf, populate > POST/GET dicts with it > - remove cm_data_id from GET variables > - delete /tmp/78fsd8fasdf7ad8asaf7889sdf > - log message that data has been picked up django.core.handlers.FileSystemHandler ;-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
