Stalled tickets

Hi, I am playing around at the DjangoCon US 2019 Sprints and while trying to do my share one thing stands out in the open tickets is: Some are very old and others have not been touched in a while. I did a simple analysis of accepted and open tickets based on last modified time (kind of a live

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

special function import. For bulk_disassociate() the analogous API would be: M1.m2_set.remove_pairs(*[(m1, m2), ...]) # --- OR --- M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...]) - David On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote: > > Given the following e

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Trac ticket created: https://code.djangoproject.com/ticket/30828 On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote: > > Hey David, > I like this idea, while I don’t think the use case is common there have > been a few times where I’ve needed this and got around it by

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

s/#patch-review-checklist> and either mark the ticket as "Ready for checkin" if everything looks good, or leave comments for improvement and mark the ticket as "Patch needs improvement". Thanks for any help. - David On Tuesday, October 1, 2019 at 11:06:15 PM UTC-7, Davi

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Here's the link to the PR for review: https://github.com/django/django/pull/11899 (Apologies for the double-post) - David On Sunday, October 13, 2019 at 3:37:07 PM UTC-7, David Foster wrote: > > I've created a PR which is waiting for review, if someone has time. > > Accor

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

Put them on the umbrella Trac ticket: https://code.djangoproject.com/ticket/30828 Cheers, David Foster | Seattle, WA, USA On Sunday, October 13, 2019 at 3:39:12 PM UTC-7, David Foster wrote: > > Here's the link to the PR for review: > https://github.com/django/django/pull/11899

Re: delegating our static file serving

wsgi.py! This approach will be marginally less efficient than handling things at the WSGI layer, but the integration is much cleaner. On Tuesday, 29 December 2015 17:31:02 UTC, David Evans wrote: > > I'd be very happy to help with this. Two things to mention: > > 1. When I first w

Re: Feedback on Django Channels

On the static files question, I'm about to release v3 of WhiteNoise (http://whitenoise.evans.io/en/latest/changelog.html) which provides the option to integrate via Django middlware, rather than wsgi middleware. (It uses the FileResponse class, which didn't exist when I first wrote WhiteNoise.)

Revisiting lazy middleware initialization

Hi all, Currently, middleware is initialized lazily on serving the first request, rather than on application start. There may well have been good reasons for this historically, but I don't think they apply any longer. Lazy initialization is unhelpful if a middleware class throws an error (e.g t

Re: Revisiting lazy middleware initialization

16 10:08 a.m., "Florian Apolloner" wrote: > +1 -- Patches welcome :D > > On Friday, March 25, 2016 at 11:02:26 AM UTC+1, Aymeric Augustin wrote: >> >> On 24 Mar 2016, at 17:39, David Evans wrote: >> >> >> Currently, middleware is initialized

Help Text Per Model Field Choice

class ChoiceTuple nicely minimizes the amount of changes needed to plumb the change all the way from the model field to the widget. I'm not married to the approach, I'm just looking for a clean way to allow help texts per choice. Proof of concept patch (based on current master): http:

Admin Themes in 1.10

hts? I'd like to restore this ability to easily provide different options to these admin jQuery plugins before 1.10 is finalized as it will be harder to put the cat back in the bag if it ships without the ability. - David [1] https://github.com/django/django/pull/5567 [2] http://pastebin.com/wcCk8T

need not_equal and not_in query lookup types for a natural use case that can't easily be implemented with existing queries

Hi folks, Django is missing a not_equal lookup type for database queries. I know this has been requested before and that the usual response is to use exclude or ~Q. While that works for a lot of use cases, I have a natural use case that I haven't seen discussed and that seems to escape easy i

Re: Unicode normalization for username field

> > - I'm afraid this change may result in boilerplate as most custom user > models will revert to Django's historical (and in my opinion sensible) > username validation rules. > That's a tough question to estimate. This might be true for most English monolingual web sites, but not necessaril

Minor concerns about auth.models.User default settings

In 1.10 auth.models.User.username changed from max_length 30 to 150 and defaults to UnicodeValidator. 1. max_length=150 pushes the username string from 1-byte overhead to 4-bytes overhead in Postgres. 2. (Opinionated) AS

Re: delegating our static file serving

I've been intending to work on this for a while (as the original author of WhiteNoise it would make the most sense for me to do the integration work) but as ever the problem has been finding the time. I've been hoping to make some progress on this over the Christmas period, but we'll see what ha

Feature idea: forms signals

Or, worse, monkey patching the form class. A much nicer way to do this would be to add a few well chosen signals to forms. Potential ones could be: - post_init - post_clean - post_save (for ModelForms) I'd be happy to do a pull request for this, but just wondered what people think. Davi

Re: Feature idea: forms signals

d of hook would make it a lot easier for Django developers to architect their projects as small, pluggable apps - something that is pretty difficult to make work with forms. David On Monday, 6 March 2017 21:43:47 UTC, contact wrote: > > Hi ! > I'd prefer to that a standardized way

Re: Feature idea: forms signals

I've created a ticket for this here: https://code.djangoproject.com/ticket/27923#ticket What are the next steps? Shall I create a pull request, or does this need more consensus first? David On Wednesday, 8 March 2017 17:46:12 UTC, Melvyn Sopacua wrote: > > On Wednesday 08 March 20

Re: Feature idea: forms signals

lude them for completeness. Would value any comments! On Monday, 6 March 2017 19:08:29 UTC, David Seddon wrote: > > Hi all, > > One thing I've always found challenging with Django is to adjust the > functionality of forms from other apps. An example might be to add an &g

Re: Opportunity to contribute in Django

Hi Jainesh, Have a look at this page which should give you an idea about where to start: https://docs.djangoproject.com/en/1.10/intro/contributing/#finding-your-first-real-ticket On Monday, 13 March 2017 13:52:34 UTC, Jainesh Patel wrote: > > Hello, > > I am a final year CSE student from PICT,

Re: SQLAlchemy integration - More details

On Monday, March 13, 2017 at 3:26:48 AM UTC+3, stamati...@gmail.com wrote: > > Hello. > > I would like to request a bit more information about the SQLAlchemy > integration project listed on the GSoC ideas: > https://code.djangoproject.com/wiki/SummerOfCode2017#SQLAlchemyNoSQLintegration > > Eve

Re: delegating our static file serving

Hi Aleksej, Thanks for your work on this, and sorry I haven't replied sooner -- just been busy with lots of other things ;) My plan for integrating WhiteNoise was actually to merge it in as part of contrib.staticfiles and basically stop development on it as an independent project. When I first

Re: Feature idea: forms signals

nterested to hear if anyone thinks it's worth me making a pull request for this. David On Sunday, 16 April 2017 23:59:31 UTC+1, jp...@yourlabs.org wrote: > > Hello David, > > Is it possible to try to use it as part of the Django fork you mention, > instead of the app ? > > I

Re: #26369: default formfield callback override

n the forms signals feature thread? David On Sunday, 16 April 2017 23:18:13 UTC+1, Jamesie Pic wrote: > > Ooops yes this is correct, it doesn't work in the advised file, apps.py > > Thank you so much for your feedback, I need to ditch this patch just > find a way to make Django

archive_year generic view and object_list order

lt? I think the Meta one is better... David --~--~-~--~~~---~--~~ 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

Re: newforms issues

half-cleaned data out of cleaned_data will get easier). And of course clean_FIELD() is not documented so far, which was the reason for changing its name to do_clean_FIELD() in some commit lately. So I don't see any reason why not to do this again to get things straight. Greetings, David Danier

Re: Ticket #3297 and File uploads

orm(new_data) But I think copy() already allocates memory, so the performance difference might be small. Greetings, David Danier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: Ticket #3297 and File uploads

rue, so the var did not include any special chars' else: print 'most likely with foreign languages' If you change the encoding of the request this might be fine, but the items in the dict returned by copy() should (/MUST?) look the same as the items in the original. Or am I

Re: Ping: Extend "for" tag to allow unpacking of lists

er for a decision. > I'm not a core dev but as a daily user, this patch is really interesting/pythonic so I'm definitely +1. David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers&qu

Re: signals

eful too when you need to send mass mail at each modification of an object. David --~--~-~--~~~---~--~~ 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

'retrieve': the missing permission?

e' to the auth.management._get_all_permissions function, but I don't want to hack my django code so I wonder why this choice had been done? (I suspect the admin goal which is driven by the User.is_staff field but auth can be used elsewhere). David --~--~-~--~~~---

Re: 'retrieve': the missing permission?

2007/6/18, David Larlet <[EMAIL PROTECTED]>: > Hi, > > I've just tried to use the permission_required decorator for my views > and I realise that there is a missing 'retrieve' permission. It's a > bit odd because others ones follow the CRUD permissions.

Re: 'retrieve': the missing permission?

2007/6/20, Gábor Farkas <[EMAIL PROTECTED]>: > > David Larlet wrote: > > 2007/6/18, David Larlet <[EMAIL PROTECTED]>: > >> Hi, > >> > >> I've just tried to use the permission_required decorator for my views > >> and I realise t

Re: contrib.thumbnails approval?

folder if the file does not exists any more. Perhaps this can even be done in some post_delete-signal-handler (iterate over all fields, find image-fields, delete thumbnail-folders). Greetings, David Danier --~--~-~--~~~---~--~~ You received this message becaus

Re: 'retrieve': the missing permission?

2007/6/20, David Larlet <[EMAIL PROTECTED]>: > 2007/6/20, Gábor Farkas <[EMAIL PROTECTED]>: > > > > David Larlet wrote: > > > 2007/6/18, David Larlet <[EMAIL PROTECTED]>: > > >> Hi, > > >> > > >> I've just tried to

Status of contrib.comments rewrite?

of this update? Did someone is already on this? David --~--~-~--~~~---~--~~ 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 uns

Re: Shared memory across processes

he settings-module should do the rest... Sorry if this is stupid and I miss some bigger picture here. ;-) Greetings, David Danier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. T

Re: Status of contrib.comments rewrite?

2007/6/26, Jacob Kaplan-Moss <[EMAIL PROTECTED]>: > > On 6/26/07, David Larlet <[EMAIL PROTECTED]> wrote: > > I'm just curious, I've read somewhere (maybe here) that the > > contrib.comments package need to be rewritten in order to allow more > >

Re: Unicode branch - last call for comments(?)

ngs in my code and works really smooth after using __unicode__. ;-) Greetings, David Danier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email t

Re: Unicode branch - last call for comments(?)

> Well if I have understood what you say, it is exactly what is > explained here <http://code.djangoproject.com/wiki/ > UnicodeBranch#PortingApplicationsTheQuickChecklist>.. Right, now I feel dump. ;-) I even read the docs some time ago.... Greeting

CacheManager

So I had a cool little idea -- to build a CacheManager, which let our team collaborate with caching controls and not duplicating data in the cache. So, here's a rough draft that i hammered out in 15 minutes. http://www.davidcramer.net/code/50/django-cachemanager.html Criticism welcomed! --~--

Re: CacheManager

clean but it's the only other way I can think of. On Jul 4, 11:25 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote: > > >http://www.davidcramer.net/code/50/django-cachemanager.html > > > Criticism

Re: CacheManager

Sorry, new link: http://dpaste.com/hold/13668/ On Jul 5, 11:41 am, "Honza Král" <[EMAIL PROTECTED]> wrote: > On 7/5/07, David Cramer <[EMAIL PROTECTED]> wrote: > > > > > Ya cache invalidation is something you'll always have a problem with. > &

Re: CacheManager

Here's about as final as we're going to get it for now: http://dpaste.com/hold/13884/ On Jul 5, 4:07 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On 7/5/07, Honza Král <[EMAIL PROTECTED]> wrote: > > > We haven't tested it for performance (we are building a high-volume > > site) yet and we sti

New Python ORM

Not sure if you guys have seen this, but maybe Django can take a bit from what it does well. https://storm.canonical.com/Tutorial --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post t

Re: Problem in current svn TRUNK

e.djangoproject.com/wiki/UnicodeBranch#PortingApplicationsTheQuickChecklist Greetings, David Danier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to dja

Re: CacheManager

That's an interesting solution. My main reason for not doing that is because I've been told the dispatcher sucks (it's slow) and we're going for speed. I don't see the reasoning for adding QUERY_ to the cache_key. By default the cache_key is your db_table. So if your model is myapp.HelloWorld it

Re: New Python ORM

; It just seems that Django's ORM is already syntactically nicer and, other > than inheritance, Storm doesn't seem to have any really compelling feature. > > On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > On Jul 10, 4:43 pm, David C

Unicode Keys

Is there any reason why its storing the keys in QueryDict (possibly others) as unicode? This seems like a bug, possibly overlooked, but having unicode keys prevents certain functionality like **request.GET in a method call. --~--~-~--~~~---~--~~ You received this

Re: Unicode Keys

Ya it's probably not a great practice. I argued about these should be str's for an hour yesterday and I was convinced to drop it :) Gábor Farkas wrote: > David Cramer wrote: > > Is there any reason why its storing the keys in QueryDict (possibly > > others) as unicode?

Re: GSoC 2007 Status Update IV: Django REST interface

an interesting example for a real django case. Best regards, David [1] http://django-crudapi.googlecode.com/svn/trunk/views.py [2] http://djangocollection.googlecode.com/svn/trunk/djcollection/views.py [3] http://www.crummy.com/writing/RESTful-Web-Services/ [

Re: Proposal: QuerySet.exists() method

.exists() > I agree too, if documentation is a problem it can be resolved with a simple example. So I'm +1 for __nonzero__ and -1 for .exists() David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Dj

None != Null?

Is there a specific reason that myfield=None doesn't translate to myfield__isnull=True in the database backend? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send

Re: None != Null?

It's not so much related to ManyToMany. But None is Python's equiv to SQL's NULL. I'd very much like to see it evaluate to such, and I agree, isnull=True should be deprecated. On Jul 16, 9:46 am, "Benjamin Slavin" <[EMAIL PROTECTED]> wrote: > On 7/16/07,

Re: None != Null?

I forsee a patch incoming.. as soon as we make our crazy Django branch fit w/ trunk :) Didn't know about __ne before today. A lot easier than throwing on excludes :) On Jul 16, 2:19 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On 7/16/07, David Cramer <[EMAIL

Re: None != Null?

I'm still not quite sure what the point of having None not mean NULL is. '' is not None, False is not None. If this is what it's currently doing then the ORM handles it incorrectly. Yes, it may be a backwards incompatible change, but who relies on None? I've yet to see myfield=None pull any result

Re: None != Null?

I feel that returning an empty queryset where value=None is just laziness. Yes, maybe it will break things, but maybe those things are meant to be broken. You could just as easily say myfield__exact which would work as it would before, and leave the default to isnull for None. This is similar to h

Re: #4001 - newforms commit=false and m2m data loss

t called by it. Greetings, David Danier --~--~-~--~~~---~--~~ 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 t

Re: schema evolution

environment without having to fear that they screw the whole thing up easily. In a professional environment this might help having a nice way to deprecate things. Greetings, David Danier --~--~-~--~~~---~--~~ You received this message because you are subscribed

group_by() support

I committed a quick patch earlier to trunk that adds group_by() support. I can't run the tests on trunk, as we're not quite up that far, but it should be working. http://code.djangoproject.com/ticket/4997#comment:1 I plan to add having=[] support to extra as well this weekend. --~--~-

Re: group_by() support

#x27;choices': 'my_column'} On Jul 27, 7:49 pm, David Cramer <[EMAIL PROTECTED]> wrote: > I committed a quick patch earlier to trunk that adds group_by() > support. > > I can't run the tests on trunk, as we're not quite up that far, but it > should be

Re: group_by() support

n to not put in working fixes right now. On Jul 27, 8:06 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 7/28/07, David Cramer <[EMAIL PROTECTED]> wrote: > > > > > I committed a quick patch earlier to trunk that adds group_by() > > support. &

Re: group_by() support

It's not abusive, and we use Django daily. I looked at the QuerySet recactoring and I honestly don't like the aggregate() stuff. We are real people, and developers also :) On Jul 27, 8:59 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > On 7/27/07, David Cra

select_related additions

I have taken a bit of time to rewrite part of the QuerySet code (including select_related). Please, no lectures about a QuerySet refactoring. The changes force .filter() to take advantage of select_related. Before: .filter(mykey__name='Hello') would give you results, but if you didn't do .select

BlobField before .97

In my opinion BlobField's need some kind of support inside of Django before the coming of 0.97 release. They have never been officially supported, but they were at least usable (as say a TextField) before Unicode. Now they're unusable as you run into encoding/decoding issues. --~--~-~--

Re: select_related additions

I've submitted a ticket and attached part of the patch (the fields selection on select_related): http://code.djangoproject.com/ticket/5020 On Jul 30, 12:39 pm, David Cramer <[EMAIL PROTECTED]> wrote: > I have taken a bit of time to rewrite part of the QuerySet code > (includi

Re: select_related additions

Seems I slipped in the diff. I have to actually apply the patch to at least 2 different versions of Django with our current setup, can get tedious :P *args should be *fields :) On Aug 1, 9:26 am, Michael Radziej <[EMAIL PROTECTED]> wrote: > On Wed, Aug 01, David Cramer wrote: &

Re: How submit a patch with files not in subversion?

actical.com/ Greetings, David Danier --~--~-~--~~~---~--~~ 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,

Re: select_related additions

t; On Thu, Aug 02, David Cramer wrote: > > > Seems I slipped in the diff. I have to actually apply the patch to at > > least 2 different versions of Django with our current setup, can get > > tedious :P > > > *args should be *fields :) > > ;-) > > Well, for t

CachedForeignKey

This is round #8 for ideas on how to improve caching mechanisms :) The way the code works is that it caches all requests to this ForeignKey in a single dictionary. It then does a lookup on the primary key (doesn't support multiple pks) and returns it. This works great when you would need to join

Re: usability issues

So this definitely needs to be put into your own middleware or view (which does the redirect). Greetings, David Danier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this

Re: GSoC 2007 Status Update IV: Django REST interface

2007/8/3, Andreas Stuhlmüller <[EMAIL PROTECTED]>: > > On 7/13/07, David Larlet <[EMAIL PROTECTED]> wrote: > > * About users, how can I handle django users' permissions? John > > Sutherland had already done some work on django-crudapi [1] and it > >

Re: GSoC 2007 Status Update VI: Django REST interface

code once this project is merged to the trunk. Regards, David --~--~-~--~~~---~--~~ 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.c

About Changeset [5819]

/models/fields/__init__.py?rev=5819#L785). Why is this done? If I read the code right self.upload_to gets stripped later in FileField.get_filename() and is added in File.get_directory_name(), again. Greetings, David Danier --~--~-~--~~~---~--~~ You received this

Re: ModelChoiceField's clean() uses default manager instead of query set

ople may guess valid IDs that they should not use (for example if you use user_profile.some_relation as the queryset). Perhaps it could be changed to only allow choices in the queryset, but an option is added to ModelChoiceField to use the default manager? Greetings

Re: GSoC 2007 Status Update VI: Django REST interface

2007/8/10, Andreas Stuhlmüller <[EMAIL PROTECTED]>: > > On 8/6/07, David Larlet <[EMAIL PROTECTED]> wrote: > > * What about additional pages like: create form, update form, delete > > confirmation and so on? I've just noticed the get_create_form at the > >

Re: manage.py idea?

> Would following that with a syncdb then restore the content types for > the installed apps? I'll have to test that later. Even if it did the id's might have changed and any generic relations be broken. Greetings, David Danier --~--~-~--~~~

Re: GSoC 2007 Status Update VI: Django REST interface

2007/8/12, Andreas Stuhlmüller <[EMAIL PROTECTED]>: > > On 8/11/07, David Larlet <[EMAIL PROTECTED]> wrote: > > Here is my suggestion: the current forms from model or instance are > > great but you often need a custom form, what about an extra-argument > >

Re: GSoC 2007 Status Update VII: Django REST interface

or want to contribute bugfixes and other > enhancements, please go ahead. > Just one (latest?) thought, it's a bit hard to debug because 400 errors are not really verbose, is it possible to find a way to make debug easier? For the moment, I have: if settings.DEBUG: print i.er

Re: GSoC 2007 Status Update VII: Django REST interface

2007/8/19, Andreas Stuhlmüller <[EMAIL PROTECTED]>: > > On 8/17/07, David Larlet <[EMAIL PROTECTED]> wrote: > > Just one (latest?) thought, it's a bit hard to debug because > > 400 errors are not really verbose, is it possible to find a > > way to make

Re: Time for a new release?

to do so. Let's try to add html doc with the djangoproject's css and maybe more users will use local docs. A lot of people don't even know the rst2html command... About the release question, before voting can we have an estimation of how far the newforms-admin branch i

Re: Time for a new release?

2007/8/26, Simon Greenhill <[EMAIL PROTECTED]>: > > On Aug 26, 9:56 pm, "David Larlet" <[EMAIL PROTECTED]> wrote: > > I agree that users do not try to read the local docs for the moment, > > but maybe it's because the ReST style discourage them to

Re: Time for a new release?

2007/8/26, James Bennett <[EMAIL PROTECTED]>: > > On 8/26/07, David Larlet <[EMAIL PROTECTED]> wrote: > > I agree that users do not try to read the local docs for the moment, > > but maybe it's because the ReST style discourage them to do so. Let's > >

Multiple PKs and "is_stored"

So we all know Django doesn't support multiple pks, big problem, yes. While looking into a temporary solution to fix some issues I have with these, I cam across another issue. Django's check for "is this row in the database", is simply checking if it has a primary key attribute set. If it does, i

Re: Multiple PKs and "is_stored"

applicable, but that goes into the queryset refactoring. On Aug 30, 5:13 pm, Collin Grady <[EMAIL PROTECTED]> wrote: > Russell Keith-Magee said the following: > > > On 8/31/07, David Cramer <[EMAIL PROTECTED]> wrote: > >> Not only would this fix my multiple pk issue

Re: Multiple PKs and "is_stored"

Here's the patch: http://code.djangoproject.com/ticket/5309 On Aug 30, 5:39 pm, David Cramer <[EMAIL PROTECTED]> wrote: > We were talking it over in IRC, and here's a pretty good solution: > > Intially is_stored is set to None. When you do a .get or .create it > wou

Re: Multiple PKs and "is_stored"

If there are any, then I would expect it'd handle them just as it does without the flag. The problem is (at least in my eyes) that Django should not be guessing, and especially should not be doing an extra query, when you are explicitly saing update or create on an object. On Aug 31, 2:24 am, "Vs

Re: Let's schedule a Django sprint

You promise we have refactoring done by the 14th? ;) I can see if anyone at the office is interested in participating. On Sep 5, 1:32 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > It's about time we scheduled an official Django sprint. We've got a > bunch of features that are almost done bu

Re: Let's schedule a Django sprint

If they can host it at the HQ in Mountain View even better, count me in either way. On Sep 5, 2:39 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On 9/5/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > It's about time we scheduled an official Django sprint. > > I've contacted Brian Fitzpa

Re: Let's schedule a Django sprint

On 5 Sep 2007, at 9:32 pm, Adrian Holovaty wrote: > I propose Friday, September 14. Some reasoning: I'm not wholly familiar with how sprints work, but if there's a need for testers, I can be around a bit on Friday and at the weekend. Thanks, David -- David Reynolds [EM

GenericForeignKey and GenericRelation, possible bug?

;, "object_id") self.content_type_field_name = kwargs.pop("content_type_field", "content_type") Any thought before I hack my django in order to find a patch? Regards, David --~--~-~--~~~---~--~~ You received this message because you are subs

Re: GenericForeignKey and GenericRelation, possible bug?

2007/9/6, David Larlet <[EMAIL PROTECTED]>: > Hi all, > > Before submitting a bug I'd like to be sure that it hadn't been done > intentionally, here is the issue: > > I had a model with two GenericForeignKeys which where defined like that: >

Re: How to deal with backend-specific parameter types? [Was: django on jython (new version)?]

On Sep 6, 8:06 pm, "Leo Soto M." <[EMAIL PROTECTED]> wrote: > Am I on the right track? Do you people have other ideas? > Some backends provide some type_cast functions that you can attach to some data types, on a quick search for zxJDBC I found in the home page "Datatype mapping callbacks through

Re: Let's schedule a Django sprint

Only 3 of us from SF? Come on now! It's for sure that it'll be good at Google's campus? On Sep 7, 9:20 am, Fernando Gutierrez <[EMAIL PROTECTED]> wrote: > On Wed, 2007-09-05 at 15:32 -0500, Adrian Holovaty wrote: > > It's about time we scheduled an official Django sprint. We've got a > > bunch o

wikimarkup and django-sphinx releases

I've taken the time to upload both our SphinxSearch layer, and our MediaWiki markup util to Google code today. For more info see my blog post: http://www.davidcramer.net/code/54/mediawiki-markup-and-sphinxsearch-for-django.html I haven't used Google code before, so if theres any problems just le

Re: wikimarkup and django-sphinx releases

Thinking about this more, it made more sense in django-users, sorry :) On Sep 7, 3:30 pm, David Cramer <[EMAIL PROTECTED]> wrote: > I've taken the time to upload both our SphinxSearch layer, and our > MediaWiki markup util to Google code today. For more info see my

Re: mod_python documentation issues

in what's there. Thanks, David Graham Dumpleton wrote: > On Aug 30, 9:34 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: >> On 8/29/07, GrahamDumpleton<[EMAIL PROTECTED]> wrote: >> >> >> >>> Seems I can no longer add to Django tickets

Call to Arms -- Caching Mechanisms

So in the past months, we've tried several different methods of handling caching over at Curse. Curse.com for the unfamiliar, we're a very high traffic dynamic content driven website. - Caching frequently used querysets with cache.get()/set() - Caching entire views - Caching middleware Now we've

Re: Call to Arms -- Caching Mechanisms

cy information is created and when the cache > gets invalidated, it is taken into account. > > We are still in early stages with this, but the foundation seems > solid. We still have a fine-grained control over what gets cached and > what not (caching the entire page simply isn

<    1   2   3   4   5   6   7   8   9   >