Re: Caching back-refernces on one-to-one fields

On Wed, Jan 18, 2012 at 11:07 AM, Shai Berger wrote: > Do you see a reason why I should not post a ticket? +1 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

First-run experience w/ psycopg2 and django 1.3.x

There's a known problem w/ latest pg (2.4.2) and we decided not to backport the fix to 1.3.x because there's a workaround. https://code.djangoproject.com/ticket/16250 All well and good, but someone coming to Django w/ postgres will have a bad first-run experience because the docs don't mention

Re: Caching back-refernces on one-to-one fields

On Thu, Jan 19, 2012 at 5:14 PM, Adrian Holovaty wrote: > On Wed, Jan 18, 2012 at 1:07 PM, Shai Berger wrote: >> I have a small improvement to suggest for one-to-one fields: Make them cache >> back-references on related objects. That is, assume > > Yes!

Testing multidb without inconsistency

I have a master and a replica. In test, the TEST_MIRROR on the replica points to master. I make writes to master, then read from replica, then assert some numbers. def test_stuff(self): Foo.objects.using('master').create() number_received = do_expensive_computations() # Down in some

Re: Testing multidb without inconsistency

On Sat, Feb 25, 2012 at 2:13 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On Feb 25, 9:24 am, Jeremy Dunck <jdu...@gmail.com> wrote: >> I have a master and a replica.  In test, the TEST_MIRROR on the >> replica points to master.  I make writes to master

Re: Mobile Login????

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 On Mon, Feb 27,

Re: Pretty Django model instaces updating

On Thu, Mar 1, 2012 at 9:28 PM, Carl Meyer wrote: > The "only_fields" kwarg suggestion comes from ticket 4102, and it is > primarily intended as a performance optimization for large models by > only sending the values of certain fields to the database at all, > something

Re: Looking for some insight into a tiny piece of the django codebase

On Mon, Mar 19, 2012 at 11:17 PM, Tim Diggins wrote: > Hi - > > I'm wondering what the lines at the end of django/db/models/ > deletion.py do: > >        for model, instances in self.data.iteritems(): >            for instance in instances: >                

Re: #18094: signals, model inheritance, and proxy models

On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer wrote: > Hi all, > > There's a discussion ongoing on ticket #18094 > (https://code.djangoproject.com/ticket/18094) that has enough potential > back-compat implications that it seems worth getting feedback here. Small note, I'll try to

Re: django db library doesn't handle quoted table/field names

On Thu, Apr 12, 2012 at 3:06 PM, Craig Lucas wrote: > i have developed a database for a client that uses camel casing in the > database. we are now trying to get a models.py file to mimic the > database structure and i have run into a few bugs with regards to > using quoted

Re: Application init inconsistent

On Tue, May 8, 2012 at 9:33 AM, Alex Ogier wrote: > My guess is that Django is doing some normalization on the name you are > importing. It does this to prevent double imports, for example importing > 'projectname.appname' and 'appname' which would otherwise be considered >

Announcement: twice-monthly Django sprints in San Francisco

My company, Votizen, now has an office in San Francisco, just a block from the 4th St Caltrain station. We have room to host sprints - easily 25 people, though we can grow if there is demand. We have a professional kitchen, great coffee gear, and maybe a kegerator soon. There are many great

Non-default managers in related field lookups

It feels to me that each place that ._default_manager is mentioned here is a misfeature: https://github.com/django/django/blob/2cd516002d43cdc09741618f0a0db047ee6d78fd/django/db/models/fields/related.py As an example, we (Votizen) currently have some default managers which show subsets of all

Re: Non-default managers in related field lookups

On Fri, Jun 1, 2012 at 2:26 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Fri, Jun 1, 2012 at 8:53 AM, Jeremy Dunck <jdu...@gmail.com> wrote: ... >> Candidate.context('site') would return a manager depending on the >> requested context. >> (o

Re: #18094: signals, model inheritance, and proxy models

On Fri, Apr 20, 2012 at 9:01 AM, Anssi Kääriäinen wrote: > On Apr 12, 10:27 pm, Anssi Kääriäinen wrote: >> > So perhaps we do need the signal inheritance behavior to be opt-in when >> > connecting the signal handler. I think I'd like to see a

San Francisco sprint info

We (Votizen) hosted a 1-day sprint yesterday from 10a to 6p. I had capped attendance at 30 just for logistical reasons - there's room for more but I wanted to gauge interest. 24 people signed up, and I'd guess that about 20 people total were there for at least part of the day. I think we peaked

Re: Announcement: twice-monthly Django sprints in San Francisco

I've just opened signup for our 2nd sprint - Saturday, June 16th, from 10a to 6p: http://sfdjangosprint2.eventbrite.com/ Please sign up if you plan to attend -- it's free of course. On Tue, May 22, 2012 at 2:30 PM, Jeremy Dunck <jdu...@gmail.com> wrote: > My company, Votizen, now has

Re: XSS and string interpolation

On Jun 28, 2012, at 6:57 AM, Luke Plant wrote: > Hi all, > > 2) Any better name than 'html_fragment'? > I like the general approach, but I miss the security-minded namse of "escape" and "mark safe". Maybe "safe_html_fragment" or "make_safe_html_fragment"? Getting

pre_init/post_init vs. performance

I was poking around in our (Votizen's) use of signals and thinking about making some tooling so that signal usage was a bit more transparent. In doing so, I noticed that GenericForeignKey hooks the model pre_init signal. It does that because GFK needs a chance to munge kwargs from the GFK field

Re: pre_init/post_init vs. performance

On Sun, Jul 15, 2012 at 9:51 AM, Andy McCurdy wrote: > > On Jul 14, 2012, at 6:37 PM, Russell Keith-Magee wrote: > >> >> My only concern is: >> >>> We could store which fields have these hooks upon ModelBase.__new__ >>> construction and so skip most fields and overhead in

Upcoming sprint to update Django's tutorial

On August 4, PyLadies SF will collaborate with Django sprinters in San Francisco to improve the Django tutorial. I expect around 30 people will attend, including Alex Gaynor and Karen Rustad ( http://pyvideo.org/video/713/improving-documentation-with-beginners-mind-o ). We'll run a prep session

Re: Upcoming sprint to update Django's tutorial

. I could go either way - my preferred approach isn't right in all cases, and it might seem a distraction to the absolute beginner or a person who has their own opinions. On Mon, Jul 16, 2012 at 11:15 PM, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: > 2012/7/16 Jeremy D

Re: Django git guidelines

I noticed this hasn't made it to master yet. Could it? I'm running sprints and there's a bit of confusion on how to contribute to git. Cheers, Jeremy On Thu, Jun 7, 2012 at 9:53 AM, Aymeric Augustin wrote: > On 6 juin 2012, at 21:09, Anssi Kääriäinen

Re: Git questions

On Fri, Jun 8, 2012 at 7:57 AM, Anssi Kääriäinen wrote: > On 8 kesä, 17:28, Luke Plant wrote: >> First, thanks so much to Aymeric and Anssi and others for the >> contribution guidelines, they're very helpful. >> >> I've got some questions that are

Re: pre_init/post_init vs. performance

On Sun, Jul 15, 2012 at 11:07 AM, Jeremy Dunck <jdu...@gmail.com> wrote: > > That is indeed what I meant, but I think Anssi's probably right that > this belongs in contribute_to_class instead of a new adhoc thing in > ModelBase.__new__. > > I'll take a swing at making

More efficient m2m assignment SQL

I have 2 models: class District(Model): pass class Voter(Model): districts = ManyToManyField(District) Sometimes I want to reset the m2m list: voter.districts = other_districts I noticed that this uses ManyRelatedManager._clear_items, which, among other things, boils down to:

Re: More efficient m2m assignment SQL

On Thu, Jul 26, 2012 at 11:26 PM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On 27 heinä, 08:15, Jeremy Dunck <jdu...@gmail.com> wrote: ... >> I would have expected something along the lines of : >> >> DELETE FROM `api_voter_districts` WHERE `voter_id` = 1

Re: pre_init/post_init vs. performance

Can I get a review of the branch? 25% performance improvement of Model.__init__ in stock django seems worth landing. :) On Wed, Jul 18, 2012 at 3:48 AM, Jeremy Dunck <jdu...@gmail.com> wrote: > On Sun, Jul 15, 2012 at 11:07 AM, Jeremy Dunck <jdu...@gmail.com> wrote: >> >

Re: Upcoming sprint to update Django's tutorial

cially on Windows its not that uncommon to entirely neglect >> pip/virtualenv. >> >> On Jul 17, 2012 8:31 PM, "Alex Ogier" <alex.og...@gmail.com> wrote: >>> >>> On Tue, Jul 17, 2012 at 3:07 PM, Jeremy Dunck <jdu...@gmail.com> wrote: >>>> >

Re: #16455 PostGIS 2.0 support

I'm fairly familiar with the django gis code, but I haven't been following postgis 2.0. Could you point me towards some discussion of the index changes from 1.5 to 2.0? On the face of it, I'm doubtful that they've removed a useful form of indexing with no replacement/alternative. It's hard for

Testing multidb with TEST_MIRROR

I have been working on a master/slave router library [1] and have run into some trouble testing a client application of it. The issue is that TestCase (as designed) holds test db writes in a transaction, but the read slave connection (which is to the same DB under TEST_MIRROR) does not have

Re: Testing multidb with TEST_MIRROR

On Thu, Sep 6, 2012 at 12:16 PM, Anssi Kääriäinen wrote: > On 3 syys, 07:40, Anssi Kääriäinen wrote: >> I would like to make the TransactionTestCase faster. Currently when >> running Django's test suite, for every test ran you will truncate >>

Results of testing votizen's py2.6/7 codebase against django master (319e1355190)

In response to the call to test py2.x on django's current master, I ran the test suite for Votizen. Our codebase is currently running with django 1.4.x. Our codebase is ~100kloc, ~32kloc of which is tests. We use abstract model inheritance a good bit, but no concrete inheritance. No i18n or

Re: Results of testing votizen's py2.6/7 codebase against django master (319e1355190)

On Tue, Sep 18, 2012 at 11:23 AM, Jeremy Dunck <jdu...@gmail.com> wrote: ... > And the last one, I hesitate to raise because it's likely to be > specific to my machine, but... our (django-nose-based) test runner > hangs after completing the suite but before tearing down. Using >

A bit of Django history

I was searching around for a different old blog post and found this one: http://jacobian.org/writing/why-django/ It made me smile - we've come a ways since then. :) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

Would it be reasonable to have a backend-specific hook to determine a fingerprint, where that could be mtime or md5 or whathaveyou as long as equality (or maybe ordering) works? On Oct 8, 2012, at 10:23 AM, Alex Ogier wrote: > On Mon, Oct 8, 2012 at 1:06 PM, ptone

Call for use cases of metrics in django core

If you use/monitor/graph metrics (the idea, not Coda's library, but that would be good, too), I'd like to hear from you. What sort of metrics, under what implementation, would be useful to you operationally? -- You received this message because you are subscribed to the Google Groups "Django

Re: Django Admin Revamp - Any updates?

For the record: It's bad timing for Idan. He lives in Tel Aviv which is currently receiving intermittent rocket attacks. He may be a bit slow to respond. ;) Let's wish him and his family safety and the luxury of worrying about django's admin in good time. On Thu, Nov 15, 2012 at 7:23 AM,

Re: Full time job opportunity in SF Bay Area - Python/Django developer

Please do not send recruitment emails to this mailing list. This is your one warning. Repeating will result in you being banned from the list. On Fri, Jan 25, 2013 at 12:47 PM, wrote: > We are looking for a Full stack engineer with strong python and django > development

Re: Switch to database-level autocommit

On Mon, Mar 4, 2013 at 1:34 AM, Aymeric Augustin wrote: > On 4 mars 2013, at 01:07, Shai Berger wrote: ... >> The use of savepoints in Django apps so far has been very little, as far as >> I know. One point >> I'm unsure of is the

Re: Switch to database-level autocommit

I'm not sure what you're referring to here - integrity, uniqueness, and locking are handled at the individual query level - transactions just cause locks to be held (if needed) until commit or rollback. Can you give a concrete example of an exception being raised at commit time? On Tue, Mar 5,

Re: Switch to database-level autocommit

I, for one, would prefer that we not recommend TransactionMiddleware so highly. Now that I'm doing active development with Rails, it's quite clear to me that a major difference in the ORM layers are which DB they grew up with -- the django orm is tuned best to postgres, while working passably on

Re: Persistent connections, take 2

It sounds like we need a way to tell the worker that we are done sending requests to it so that the worker can do cleanup (of which db conn close is one task). This mirrors the previous request_finished "coupling" to requests_finished. (OS?) Signal? Sentinel queue/socket/named pipe +

Re: why does django.db.signals map to django.core.signals

I'm not sure what you mean by "maps to". The basic signal framework is in django.dispatcher. If you're implementing https://code.djangoproject.com/ticket/11398 then you probably want to import: from django.dispatcher import Signal. django.db imports django.core.signals because it is a *consumer*

Django Core mentorship list

Hey all, I've just created django-core-mentorship[1] with founding members including Carl Meyer, Jacob Kaplan-Moss, Simon Charette, and Russell Keith-Magee. Modeled after pythonmentors.com, the intention is to help more people make the leap from using django to contributing to it. It is a

Re: Django Core mentorship list

Ahem: [1] https://groups.google.com/forum/?fromgroups#!forum/django-core-mentorship :) On Wed, Apr 3, 2013 at 11:44 AM, Jeremy Dunck <jdu...@gmail.com> wrote: > Hey all, > I've just created django-core-mentorship[1] with founding members > including Carl Meyer, Jacob Kap

Re: "Design Decision Needed" is gone. Good riddance.

"easy" is for people new to contributing django or to open source in general. Your view of "easy" may be different than our intended meaning. :) On Mon, Apr 8, 2013 at 2:58 PM, Lennart Regebro wrote: > On Mon, Apr 8, 2013 at 4:57 PM, Jacob Kaplan-Moss

django.utils.simplejson + stdlib json

I've just seen a documented example of this breaking things in the wild. https://github.com/simplejson/simplejson/issues/37 I think we broke backwards-compat here - django 1.5.1. plus sentry 5.4.5 dies because django's own DjangoJSONEncoder depends on stdlib json, but sentry (and lots of things)

Re: django.utils.simplejson + stdlib json

fests, other than trying to use something from the > standard library with simplejson, which is obviously wrong. > > Alex > > > On Thu, Apr 11, 2013 at 5:51 PM, Jeremy Dunck <jdu...@gmail.com> wrote: >> I've just seen a documented example of this breaking things in the

Re: django.utils.simplejson + stdlib json

ONEncoder) which, despite django.utils.simplejson only > being in a pending deprecation state, is broken. > > On Thu, Apr 11, 2013 at 9:22 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >> When doing what? What do I need to do to trigger this? >> >> Alex >> >

Re: django.utils.simplejson + stdlib json

After reading that ticket, I'm not sure what Alex and I are disagreeing on. I was suggesting using django.utils.simplejson internally until it's removed, so that at least people could be consistent with django itself. That way, DjangoJSONEncoder would be a simplejson.JSONEncoder (if simplejson

Re: Not calling things twice in templates

I've had this issue and have used {% with %} or moved the my.bonnet() call into the view/context.I agree, not ideal, but I was never moved to make it better in general. If you're suggesting a general caching layer in the template such that a given expression is only called once in the course

Re: Benchmarking 1.5 vs 1.6

It may be useful to place a comment where @wraps was removed, lest some later do-gooder "fix" it. On Sep 17, 2013, at 12:06 AM, Marc Tamlyn wrote: > Can't say I'm hugely worried about perfect tracebacks and introspection with > internal kind of functions here if it

Re: Encodings outside of utf-8

On Wed, Jun 17, 2009 at 3:50 PM, ccahoon wrote: ... > > Does anyone have a use-case they could share with me? > I hear Malcolm's hovercraft is full of eels. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the

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

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 >>

Re: contrib.admindocs need some love.

On Mon, Oct 5, 2009 at 2:18 PM, Jeremy Dunck <jdu...@gmail.com> 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

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

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

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

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

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

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

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. :)

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

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

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

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

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

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

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.

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

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

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.

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

Re: QuerySet __contains__

On Tue, Dec 8, 2009 at 8:38 PM, Luke Plant <l.plant...@cantab.net> 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

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 <

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

Re: Session/cookie based messages (#4604)

On Fri, Dec 11, 2009 at 11:03 PM, Jeremy Dunck <jdu...@gmail.com> 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

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

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

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. >

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

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 >

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 >

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

Re: Sprint issue tracking / triaging

On Tue, Dec 8, 2009 at 1:05 PM, Jeremy Dunck <jdu...@gmail.com> wrote: > On Tue, Dec 8, 2009 at 12:56 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > >> This line of reasoning makes 0 sense IMO.  Your argument is people >> provide sub-par patches because they

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".

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 =

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 =

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 >

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 >

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

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,

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

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

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

Re: Potential bug in select_related() as of Beta

): > > 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,relate

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

Re: django + memcached: problem with limit of 1 mb

On Thu, Feb 18, 2010 at 2:21 PM, Forest Bond <for...@alittletooquiet.net> 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 <jdu...@gmail.com> wrote: >> > On Thu, Feb 18, 2010

  1   2   3   4   5   6   >