Re: Password validation in Django revisited

On 09/07/2015 06:31 PM, Tim Graham wrote: > The extra complexity of varying validation logic based on DEBUG doesn't > seem quite right to me, but I guess I won't oppose it if that's the > consensus. I'm strongly -1 on anything that automatically turns off password validation everywhere based on DE

Re: Feature proposal: Target API version

Hi Patryk, On 11/12/2015 05:48 AM, Patryk Zawadzki wrote: > I have spent quite a while thinking about this and am still not sure > what the best approach would be or even if there are enough benefits > to justify the change. I think the idea is interesting (and I know it's been at least briefly d

Re: Odd behavior change in 1.8 with {% if %}, RelatedObjectDoesNotExist, and TEMPLATE_STRING_IF_INVALID

On 11/12/2015 09:22 AM, Tim Graham wrote: > The expected behavior of the {% if %} tag isn't clear to me. How do you > propose to solve the "bug"? As I noted in the ticket: > > We end up checking {% if %} which passes for a > non-empty string_if_invalid. I'm not sure we should add special handling

Re: Case-insensitive email as username

Hi Aymeric, On 11/22/2015 11:56 AM, Aymeric Augustin wrote: > I spent a good part of today implementing what must be the most common > scenario for custom user models: case-insensitive email as username. > (Yes. This horse has been beaten to death. Multiple times.) > > Since it was the first time

Re: Case-insensitive email as username

On 11/23/2015 03:52 PM, Carl Meyer wrote: ... > I suppose the best we could do to ease this would be to add a > CreateExtension migration operation in contrib.postgres that, if lacking > super-user permissions, simply errors out and tells you what SQL you > need to run manually as

Re: Case-insensitive email as username

On 11/24/2015 04:33 AM, Aymeric Augustin wrote: > 2015-11-23 23:52 GMT+01:00 Carl Meyer <mailto:c...@oddbird.net>>: > > I've implemented the CITEXT-based solution a couple times; I think for a > PostgreSQL-based project it's the preferable option over

Re: Possible bug transaction rollback or SQLite backend

Hi Jonas, On 12/03/2015 07:02 AM, Jonas H wrote: > Hi there, > > there seems to be something wrong with either the SQLite backend, the > SQLite library itself or Django's transaction handling. Whenever I try > to run the test suite of a specific project of mine > (https://github.com/jonashaag/fah

Re: Channels integration plan, first draft

Hi Andrew, On 12/17/2015 04:34 AM, Andrew Godwin wrote: > Hi everyone, > > One of the first steps I want to get done for Channels is get a rough > plan in place for how things are going to work in terms of where code > goes, supported versions, etc. I've written up my thoughts on this into > a fi

Re: Channels integration plan, first draft

On 12/17/2015 11:50 AM, Andrew Godwin wrote: > - I thought SCRIPT_NAME was basically unused by anyone these days, but > hey, happy to be proved wrong. Do we have any usage numbers on it to > know if we'd need it for a new standalone server to implement? It's > really not hard to add it into the req

Re: structural & functional review of django documentation

Hi Doug, On 12/18/2015 04:35 PM, Doug Epling wrote: > I filed bug report > > #25952 > > but apparently it was in the wrong place. In case it wasn't clear, it wasn't in the wrong place because it was documentation-related, it was in the wrong pla

Re: A community Poll

Hi Curtis, On 12/21/2015 06:52 AM, Curtis wrote: > Whilst I'm awake... a pull request I made to a 3rd party project > included replacing explicit model imports for relation fields with lazy > binding -- ForeignKey('contenttypes.ContentType') in this case. > > The author pointed out this didn't pl

Re: Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

Hi Tim, On 12/21/2015 08:09 AM, Tim Graham wrote: > I'd like to ask for opinions about whether or not deprecations are more > useful than making small backwards incompatible changes when they move > Django in a direction toward unhiding probable developer error. > > An example from a past release

Re: Django 1.2.3 released

On Sep 11, 2:25 pm, Dana Spiegel wrote: > When will the releases be available as tags in subversion? > Specifically, both 1.2.2 and 1.2.3 have not been tagged in > thehttp://code.djangoproject.com/svn/django/tags/releases/SVN directory. I believe this has now been corrected. Carl -- You recei

Re: Proposal: Add signals test_setup and test_teardown to Django test suite runner

Hi Jim, On Sep 19, 1:19 am, "Jim D." wrote: > I found some time this evening to work this out, and have included a > revised patch for this proposal at the end of this message. Thanks for your work on this! The usual Django workflow doesn't include patches to the mailing list: rather you can go

proposal for lazy foreignkeys

Hi all, I've seen some level of interest in the idea of a lazy foreign key (one whose target table is determined by project configuration in some way, not hardcoded by the app/model in which it lives). The idea was most recently brought up again in Eric Florenzano's keynote at DjangoCon. I have so

Re: proposal for lazy foreignkeys

On Sep 25, 1:50 pm, Alex Gaynor wrote: > ISTM this would solve the "auth.User" issue, but doesn't help reusable > apps at large: one can trivially imagine a project that wants voting > (or tagging ;), or commenting, or ...) on more than one model. Of course! This isn't a silver bullet for every s

Re: #6735 -- Class based generic views: call for comment

On Oct 1, 10:00 pm, Russell Keith-Magee wrote: > Now, I'm sure the counterargument is going to be that copy() will be > just as error prone and FAQ inducing. My argument to this is: Yes. >   * when it fails, it will fail during development, not just in production > >   * the cases where it wil

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 4:34 am, Russell Keith-Magee wrote: > I can't argue with the fact that setting variables in __init__() is a > common idiom in Python generally, and this is certainly a weakness of > copy on call that will fail in non-thread safe ways. > > My counterclaim is that the move to class-based

Re: contrib.staticfiles app concerns

Hi Waldemar, On Oct 20, 1:40 pm, Waldemar Kornewald wrote: [snip] > However, what staticfiles does has almost nothing to do with "bigger > project" asset management. Just look at the features grid on > djangopackages (disclaimer: I'm the author of django-mediagenerator > and I maintain that grid)

Re: contrib.staticfiles app concerns

Hi Waldemar, On Oct 20, 4:04 pm, Waldemar Kornewald wrote: > In what way does staticfiles make writing reusable apps easier? It > merely collects apps' "static" folders. The same thing could be > achieved by defining a simple standard: > "Put media files in the 'media' folder." > and then making

Re: contrib.staticfiles app concerns

Hi Waldemar, Thanks for putting so much thought into this issue, and outlining these options in detail. However, I am not convinced that this something Django core should be concerned with. I think we need to maintain a clearer conceptual separation between the various layers of functionality here

Re: contrib.staticfiles and runserver

On Oct 28, 9:45 pm, SmileyChris wrote: > My suggestion is that StaticFilesHandler only does its magic if > 'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that > sound acceptable? That seems like a very reasonable opt-in approach that solves the backwards-compatibility problem. +1

Re: contrib.staticfiles app concerns

Hi Waldemar, On Oct 29, 3:05 am, Waldemar Kornewald wrote: > Just to clarify: We are in fact talking about two questions here: > 1. Do we need a standard for URL handling? > > This is the most important question and my answer is "yes" (I'll > explain this in the rest of this mail). I don't think

Re: Gentle Proposal: add 'render' shortcut in 1.3

On Oct 29, 2:04 pm, Ivan Sagalaev wrote: > Aha, I see the point now. On a second thought I think we can avoid this > problem altogether by not passing actual response object into > middleware. Instead we could pass just those bits that a middleware > should care about: a template name and a contex

Re: Git-using core devs: preference for merge vs. rebase?

Hi Tom, On Nov 2, 12:58 pm, "Tom X. Tobin" wrote: > Do the Git-using core developers have a preference for merge vs. > rebase for updating an upstream-tracking branch?  I prefer to rebase > to keep the changes in question at the branch HEAD, especially if the > branch hasn't been pushed publicly

Call for review and comment: #7539 (ForeignKey on_delete)

Hi all, The patch for #7539 [1] (support for on_delete behaviors other than cascading deletes) has reached a state where I consider it a candidate for committing; I invite review and comments. The current patch is available as a github branch; the compare view [2] presents it nicely as a diff with

Re: Call for review and comment: #7539 (ForeignKey on_delete)

On Nov 5, 11:17 am, Russell Keith-Magee wrote: > Giving credit where it's due, I think Michael Glassford also deserves > a shoutout here. He was the original driving force behind this ticket, > as was actively involved during the 1.2 development cycle. Indeed! My mistake. I'd made a mental note a

Re: Call for review and comment: #7539 (ForeignKey on_delete)

On Nov 5, 6:51 pm, Gabriel Hurley wrote: > 1. Add the versionadded directive to "docs/topics/db/queries.txt", and > "docs/ref/contrib/contenttypes.txt". For reference, you can make it > very clear what was changed/added by using the following syntax (note > the *single* line break between the ve

Re: No default comment_notification_email.txt, no docs

Hi Peter, On Nov 7, 9:41 pm, Peter Herndon wrote: > I just ran into a minor issue and thought I'd bring it to light.  In adding > django.contrib.comments to a site I'm building, I found that when using > moderation and setting email_notification to True, that there is no default > template for

Re: Call for review and comment: #7539 (ForeignKey on_delete)

Last call for any concerns with the patch; planning to land it in the next 24 hours. Carl -- 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 gro

Re: Call for review and comment: #7539 (ForeignKey on_delete)

This is committed as r14507: http://code.djangoproject.com/changeset/14507 Carl -- 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 e

Re: RFC: Add a "needinfo" state to triaging

On Nov 17, 9:16 am, Tai Lee wrote: > I believe that only the reporter, owner, and CCs are notified when an > update is made, not anyone who added a comment. I am quite sure this hasn't been my experience. I often receive email notifications from Trac about changes to tickets that I have commented

Deprecating ADMIN_MEDIA_PREFIX

Hi all, The special-cased handling of contrib.admin static assets in Django core is a long-time wart. Fortunately, the new static assets standard introduced by contrib.staticfiles and the STATIC_URL and STATIC_ROOT settings finally allows us to begin a migration path to remove this wart. AdminMedi

contrib.sites and multitenancy

Hi all, I've recently been exploring simple multitenancy options in Django using contrib.sites, and have some thoughts on how core could make it easier. First, let me make a quick distinction between static and dynamic multitenancy. In the static case, you have a limited set of sites running on t

Re: Models.py not loaded at server startup ?????

Hi, On Dec 12, 4:40 pm, Pakal wrote: > Why, then, isn't it specified that all models.py files should be > loaded by each starting worker ? That would solve the whole problem > and hidden errors around startup code like signals and startup checks. This is a real issue for me as well; not necessar

Re: ForeignKey with null=True

Hi Luke, On Dec 16, 9:47 am, Luke Plant wrote: > For the latter, I think we should use instance._state.adding to reliably > detect whether a PK has been set or not. This could cause some [snip] > While I was there,  I fixed _get_next_or_previous_by_FIELD to use > self._state.adding, rather than

Re: ForeignKey with null=True

On Dec 17, 9:21 am, Carl Meyer wrote: > Instance._state.adding is new in 1.2 (in 1.2 it was instance._adding > and only ever monkeypatched onto a model instance by ModelForm; I > changed it to instance._state.adding and encapsulated it inside the > ORM just a few weeks ago in r14612

Re: contrib.sites and multitenancy

Thanks legutierr for all your work on this ticket and patch, and everyone for the comments. I just took some time to review the patch on #15089 and had a long conversation on IRC with legutierr, and here's what I'm thinking: It does appear that there is some code (CurrentSiteManager, for instance)

Re: contrib.sites and multitenancy

Hi Gabriel, On Jan 19, 5:55 pm, Gabriel Hurley wrote: > > In my mind, the introduction of a multitenancy hook (in the 1.4 > > timeframe) could then look something like this: > > Also agreed on the 1.4 timeframe. While there is a valid concern for making > sure that get_current_site() (introduced

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

This seems right to me. Does anyone with more history on BooleanField know of any reason why the "wontfix" resolution on #2855 was incorrect and the current default-to-False behavior is correct? Carl -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Question on ForeignKey (on_delete=DO_NOTHING)

On Jan 24, 3:51 am, Rahul wrote: > Can you let me know how i can specify that this test case should not > be run, when i run the inbuilt unit test-cases. Currently i just run > them like this 'python runtests.py --setting=settings' You should not avoid running test_do_nothing. It is written such

Re: One Django instance, hundreds of websites

On Jan 31, 1:49 am, Xavier Ordoquy wrote: > The thread is pretty long because there are also 2 threads in one: >  - one for simply changing the site_id per request >  - one for changing the all setting per request Exactly! For the record, as far as I'm concerned #15089 is limited in scope to the

Re: Question on ForeignKey (on_delete=DO_NOTHING)

Hi Rahul, On Feb 2, 4:03 am, Rahul wrote: > When i run the entire inbuilt test suit of django, first test case it > hits is of contenttypes app of contrib apps and first test > case(intest_lookup_cache)  works fine. But when it hits the 2nd test > case (test_shortcut_view) it first flushes out al

Re: Ticket #8809 - "Better error message when can't import url callback".

Hi Vivek, On Feb 3, 1:03 am, Vivek Narayanan wrote: > I am new to the Django community and I would like to implement a patch > for the ticket #8809 - "Better error message when can't import url > callback". Welcome, and thanks for contributing! > I was looking into the _get_callback function of

Re: r15401 and removing star imports

Only reason I didn't add it to the import is that it's not used in any of the commented sample lines. But the better solution is to import it and demonstrate using it. Done in http://code.djangoproject.com/changeset/15415 Thanks for the suggestion. Carl -- You received this message because you

Re: Question on ForeignKey (on_delete=DO_NOTHING)

On Feb 4, 3:41 am, Rahul wrote: > When i set this flag in DatabaseFeatures  then for full test suit also > both test cases of "contenttypes" app works fine. > > But i am not able to figure out why this test case was failing when we > were not sets supports_transaction flag. It may be worth invest

Re: Feature request: Abstract ManyToManyField

Hi Mike, On Feb 3, 4:36 pm, Mike Lindsey wrote: > I'm doing something with bidirectional ManyToManyFields, in a project > I'm working on, that is resulting in duplicate attempts to create the > intermediate tables.  I'm perfectly open to suggestions of "You're > doing it wrong" if they come with

Re: Pluggable encryption for django auth (design proposal)

Hi Paul, On Feb 14, 1:37 am, poswald wrote: > * Django ships with SHA2-256, SHA2-512 or PBKDF2 by default. SHA2 is > python 2.5 compatible (due to hashlib being added in python 2.5) and > PBKDF2 is short enough that it could be included into the project. > This satisfies NIST/US Gov requirements.

Re: Bound formset.empty_form after posting formset

Hi Hidde-Jan, On Feb 18, 10:20 am, Hidde-Jan Jongsma wrote: > Lately, I've been working a lot with Django's modelformsets in > combination with javascript. The BaseFormSet implements a handy method > _get_empty_form, accessible through the empty_form property. This > method checks whether formset

Missing release notes for point releases (#15330)

Hi Russell et al, I don't agree with the wontfix resolution of #15330. I think the OP there is right - we should be consistent in providing release notes for all releases, even if they would be as short as "No significant changes" (and I don't actually think that's true even for 1.2.1 or 1.2.3 --

Re: Delete cascade up for Inherited models

Hi Rahul, On Feb 21, 12:56 am, Rahul wrote: > When i ran the test cases ( "modeltests/delete/ > test_inheritance_cascade_up" ) which were doing cascade up for > inherited models, it failed for DB2 cause of the fact that DB2 doesn't > support initial deferred constraint checks like behavior, hence

Re: Problem due to contenttype cache

On Mar 4, 5:55 am, Rahul wrote: > When i ran test cases of multiple_databases model of regressiontests > then "test_generic_key_deletion" test case gave Error at the point > where it was trying to create Review object using "other" db, > but when i ran "test_generic_key_deletion" test case only

Re: type-field model inheritance

Hi Craig, On Mar 4, 1:03 am, Craig de Stigter wrote: > It looks like django_polymorphic does what I want. I'm not yet sure why it > says it takes one query per type of model in a queryset. Unless it is > talking about multi-table inheritance, in which each type would require a > different join. B

Re: type-field model inheritance

Hi Simon, On Mar 4, 3:27 am, Simon Meers wrote: > +1 for better polymorphic support in Django core; it is a very common > problem which could do with an efficient and elegant solution. > Regarding efficiency, if you can keep track of your subclasses > effectively (potentially using a registry if

Re: Expensive queryset cloning

Hi Alex, On 03/14/2011 08:49 PM, Alexander Schepanovski wrote: > Personally, I would like all querysets mutate not clone by default. > And when one need a clone just make it explicitly. This is not an option. It will break quite a lot of existing code, and often in highly confusing ways. You'll n

Re: Proposal: template-based widget rendering

Hi Bruno, On 03/14/2011 06:33 PM, Bruno Renié wrote: > Although Django 1.3 is not released yet I'd like to take advantage of > the pycon sprints to discuss a proposal for 1.4: render form widgets > using Django templates instead of python code. > > This approach is implemented in django-floppyfor

Re: QuerySet subclass based on namedtuple()

Hi Alexander, On 03/15/2011 03:30 AM, Alexander Schepanovski wrote: > It would be nice to have a QuerySet subclass based on namedtuple(). > namedtuples takes less memory than dicts (from ValuesQuerySet), much > more convenient and induce more readable code than tuples > (ValuesListQuerySet). > >

Re: Composite primary keys

On Mar 16, 11:43 am, Christophe Pettus wrote: > On Mar 16, 2011, at 2:24 AM, Johannes Dollinger wrote: > > > I would be nice if support for composite primary keys would be implemented > > as a special case of general composite fields. > > It's appealing, but the reality is that no existing back-e

Re: Django urls in JavaScript

Hi Marco, On 03/17/2011 10:44 AM, Marco Louro wrote: > I don't really know how to approach this issue the best way, so I'm > just going to be direct, I'd love to see Django provide support for > django.core.urlresolvers.reverse (at least) on the client (in > JavaScript). I think this is really in

Re: Default project layout / directory structure

On 03/17/2011 05:36 AM, Tom Evans wrote: > I strongly disagree here. Django shouldn't be doing magic with my > PYTHONPATH, if I want stuff in my PYTHONPATH, I'll darn well put it > there. Hear, hear! I'm only a weak +0 on the entire idea of documenting a "standard" project layout, as I think it'

Re: Homogenization of User and UserProfile

On 03/18/2011 08:09 AM, Alexander Schepanovski wrote: > I think using subclass of User model for your fields has the same > flexibility as separate profile model (since you can have only one). You can have multiple subclasses of the User model (not that I recommend subclassing). > contrib.auth

Re: Improving Class based views names

Hi Benny, On 03/19/2011 05:41 PM, daonb wrote: > Migration to the beta was quite smooth except for two names that broke > my code: `pk` & `get_context_data`. The first comes from `models` and > is now used instead of `object_id` in urls and views. It also broke > compatibility with django-backlink

Re: Improving Class based views names

On 03/21/2011 09:14 AM, daonb wrote: > On Mar 20, 4:49 am, Carl Meyer wrote: >> Those last five characters in "get_context_data" actually serve quite a >> useful purpose, IMO. They clarify that the return value is just the data >> that will go into building a contex

Re: secret key from file...

On 03/22/2011 07:05 PM, Ian Kelly wrote: > On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt > wrote: >> Why not just do an import for your custom settings? >> >> try: >>from site_settings import * >> except ImportError: >>pass > > No particularly compelling reason that I know of,

Re: Proposal: template-based widget rendering

Hi Bruno, On 03/23/2011 08:56 AM, Bruno Renié wrote: > I'm not sure, however, how django's backwards-compatibility applies in > this case. The widgets API has never been publicly documented but the > official documentation encourages people to look at the code and > create their own widgets based

Re: Wrong error message when user having is_staff=False tries to login to admin

On Mar 16, 12:11 am, Tai Lee wrote: > Assuming that any authenticated user might be an attacker who has > brute forced a password and presenting obscure error messages to > authenticated users is not helping anybody. I agree with this, and with the many people in this thread who have come to the

Re: Complains about FileField not deleting files in 1.3.

On 03/27/2011 06:42 AM, -RAX- wrote: > I am referring to this: > http://docs.djangoproject.com/en/dev/releases/1.3/#filefield-no-longer-deletes-files > Instead of preventing the data loss from happening a very usefull > feature has been removed. Well, it does also prevent the data loss from happe

Re: Trac components cleanup

On 03/28/2011 02:33 AM, Russell Keith-Magee wrote: > As with the other thread on Trac changes -- I agree this is worth > doing, but would like to hear some other core dev voices before making > any changes. These changes look to me like a gain in sanity on every front. +1 Carl -- You received

Re: Proposal: switch to HTML5 for bundled templates

Hi Luke, On 03/28/2011 12:38 PM, Luke Plant wrote: > Overall, I think the advantages outweigh the disadvantages, that we have > to make the move sometime, and now is about the right time, or perhaps > slightly late. 100% agreed, for all the reasons you outlined. We've been using the HTML5 doctype

Re: Complains about FileField not deleting files in 1.3.

Hi Alex, On 03/29/2011 01:36 AM, Alex Kamedov wrote: > I think, cron jobs is an overhead in many simple cases where old > behaviour was useful and more simpler. > Why you don't want include DeletingFileField[1] in django? > > [1] https://gist.github.com/889692 Because, as mentioned above, it is

Re: Proposal: switch to HTML5 for bundled templates

I think it would be helpful here to clearly distinguish three distinct varieties of "using HTML5," two of which are clear wins and one which I don't see any reason to do: 1. Switching to the HTML5 doctype in those few places where Django actually renders a full page with doctype (the admin, databr

Re: Single Table Inheritance

Hi Jordan, On 03/29/2011 11:40 AM, Jordan MacDonald wrote: > I have three models, structured like so: > > Document > -Presentation > -Spreadsheet > > Document is never instantiated on its own; a prime candidate for an > abstract base class. However, there are times where I want to list/ > search

Re: Single Table Inheritance

On 03/29/2011 12:40 PM, Jeremy Dunck wrote: > What about keeping abstract inheritance in this case, but allowing > Document.objects.* to work by returning instances of the subclasses. > Filtering, etc. would only work based on the Document base class. > > It would mean doing some unions, but would

Re: Single Table Inheritance

Hi Shawn, On 03/29/2011 01:28 PM, Shawn Milochik wrote: > Hopefully someone on the core dev team can let me know if this is > possible in Django. If so, it will solve this problem. > I am not familiar with custom metaclass stuff done within models.Model. > > 1. Create a custom metaclass as descri

Re: Single Table Inheritance

On 03/29/2011 02:46 PM, Shawn Milochik wrote: > I'm not proposing a change to Django itself or suggesting that this > should be a standard practice. I do think that this is a fairly clean > solution for an individual to use to solve this problem if they have > it. > > They can create a custom ma

Re: GSOC : Django auth

On 03/30/2011 07:43 PM, Russell Keith-Magee wrote: > ... and this is the exact model that has been proposed, and rejected > in #3011 (albeit with a more complex dance around default values). It I just re-read #3011, and it is far from clear from reading through the ticket that that approach was

Re: [GSoC] Revised form rendering

Hi Gregor, As you've probably seen in past threads, this is an area where I'm quite motivated to see some improvement. I think you've got quite a strong proposal here in general, and you've clearly done your homework, so my comments below dive directly into the details: On 04/01/2011 11:57 AM, Gr

Re: Revised form rendering

Hi Mikhail, On 04/01/2011 05:09 PM, Mikhail Korobov wrote: > Hi Carl and Gregor, > > On 2 апр, 01:17, Carl Meyer wrote: >> >>> 3. The designers I worked with are often interested on adding custom css >>> class >>>or an attribute to a form fie

Re: [GSoC] Composite fields

Hi Michal, On 04/01/2011 09:22 PM, Michal Petrucha wrote: > I propose to implement a CompositeField with the following properties: > > - will be represented as a namedtuple containing the values of the > actual fields it encapsulates > > - will support retrieval and assignment (assignment sets

Re: Filter via related_name in inherited model not working .. Bug?

Hi Alex, On 04/15/2011 07:51 AM, robim42 wrote: > --- models.py code --- snip --- > from django.db import models > > class Base(models.Model): > name = models.CharField(max_length=20) > > def __unicode__(self): > return self.name > > class Seller(Base): > childa = models.Cha

Re: Accidental logging disabling

On 04/15/2011 04:20 AM, akaariai wrote: > I have been using setup_environ in my projects, and the lazy > initialization in can cause some weird problems, for example if you do > manual timing using: > start = datetime.now() > access settings > print 'Used %s' % (datetime.now() - start) > > You mig

#14891, a.k.a. "related managers don't work how we claim they do"

Hi all, Our documentation on "automatic managers" [1] and related managers [2] is quite clear that automatically-created managers for related-objects access will be plain-vanilla Manager instances, unless you set "use_for_related_fields = True" on the custom Manager subclass that you use as a defa

Re: The model option's verbose_name_raw is not really that 'raw'

Hi Viktor, On 04/18/2011 09:14 AM, Viktor Kojouharov wrote: > I think I might have stumbled upon a small bug. According to its docs, > the 'verbose_name_raw' property is supposed to return an untranslated > version of the 'verbose_name' property. However, if LANGUAGE_CODE is > set, then 'verbose_n

Re: Accidental logging disabling

Hi Ivan, On 04/17/2011 10:38 PM, Ivan Sagalaev wrote: > On 04/15/2011 02:20 AM, akaariai wrote: >> I have been using setup_environ in my projects, and the lazy >> initialization in can cause some weird problems, for example if you do >> manual timing using: >> start = datetime.now() >> access sett

Re: Filter via related_name in inherited model not working .. Bug?

Hi Alex, On 04/18/2011 02:44 AM, robim42 wrote: > thank you for your answer. I also thought that owner_partner should > work ... but when you try you get this: Sorry, not owner__partner - since partner is only a field on Buyer, not on Base, you'd need owner__buyer__partner. In any case, I don't

Re: #14891, a.k.a. "related managers don't work how we claim they do"

Hi Ivan, On 04/18/2011 01:07 PM, Ivan Sagalaev wrote: >> even if "use_for_related_fields" is absent or explicitly set to >> False on your Manager subclass. > > … the default manager should not be used as a base class. Fixing just > this would be the best option because it retains current behavior

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 12:47 PM, Luke Plant wrote: >> So - do we (A) fix the behavior to match our documented semantics, note >> it in the release notes, and hope for the best? Or (B) bow to >> backwards-compatibility and change the documentation to match the actual >> behavior? Or (C) find some middle gr

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 04:35 PM, Ivan Sagalaev wrote: > Not exactly… I mean that when use_for_related_fields is set explicitly > Django should respect it. Right now, as I understand from your first > mail, it doesn't work as False when set to False. So I agree that this > should definitely be fixed. > > Wh

Re: #14891, a.k.a. "related managers don't work how we claim they do"

Hi Johannes, On 04/18/2011 01:45 PM, Johannes Dollinger wrote: > Deprecate `use_for_related_fields` and always use the default manager > for related managers. Then add the possibility to specify custom > mangers for individual relations: > > ForeignKey(Foo, related_manager=RSpecialManager) ManyTo

Re: Right way to do formfield-less fields?

On 04/19/2011 09:44 AM, Jonas H. wrote: > On 04/10/2011 03:14 PM, Jonas H. wrote: >> What's the preferred way to do a custom model field that has no >> corresponding formfield? Intuitively, I'd say raise a >> NotImplementedError, but that would make the whole model unusable in the >> admin even i

Re: RFC: new backports policy

On 04/19/2011 05:24 PM, Luke Plant wrote: > Another issue with regards to backporting bug fixes that Jacob didn't > mention is the fact that bug fixes often introduce subtle regressions > and backwards incompatibilities. > > Personally, I find that backporting a fix very often takes only a > minut

Re: Admin search behavior changed from 1.2.5 to 1.3

Hi Ryan, On 04/20/2011 10:42 AM, Ryan K wrote: > Today I discovered behavior similar to that originally reported in > #15819 (http://code.djangoproject.com/ticket/15819). I've updated it > with a simple way to reproduce the issue. Could anyone confirm this > behavior? It's nothing major but it doe

Re: RFC: new backports policy

On 04/20/2011 04:37 PM, Tobias McNulty wrote: > I'd be more comfortable if the policy stated that any new bugs > introduced by the last release would be backported to that release. > It's possible that "major functionality bugs in newly-introduced > features" will equate to virtually the same th

Re: Help review tickets, get a prize!

On 04/20/2011 04:27 PM, Alex Gaynor wrote: > Consider me in on the 5-1 offer. Same here. Carl -- 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: Help review tickets, get a prize!

Hi Tino, On 04/20/2011 05:14 PM, TiNo wrote: > It takes me, being a newbie at reviewing tickets, quite some more time. > Would you (or any other core dev / speed reviewer) mind sharing your > workflow? Any scripts to create environments at certain revisions or > something alike? Or to quickly run

Re: Help review tickets, get a prize!

On 04/20/2011 05:38 PM, Jacob Kaplan-Moss wrote: > * It clearly *is* a bug, and there seems to be a fair bit of > information (steps to reproduce, the traceback, etc.); these I quickly > mark "accepted", fix the metadata, and move on. So you don't necessarily reproduce it yourself before marking

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

On 04/22/2011 02:42 AM, legutierr wrote: > However, in the case of a tuple of fields that are "unique together", > the proper behavior should be that if *any* of those fields are > editable in the form, the constraint should be validated by > is_valid(). In the current implementation, *all* of t

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Florian, On 04/23/2011 08:18 AM, Florian Apolloner wrote: > Nice, something like that would be great. One of my bigger problems > regarding modelforms lately was that I wanted something like: "If you > don't fill out the user it's set to the current user", in the admin, > with as little modific

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/19/2011 04:58 AM, Johannes Dollinger wrote: >> Do you have real-world use-cases in mind that require per-relation >> manager configuration? I can't think of any uses I've run across >> that weren't workable with a single default manager used by all >> relations. > > The only time I used a c

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/19/2011 01:47 AM, Ivan Sagalaev wrote: > OK, may be not reverse OneToOne… What I mean is that although it seems > natural to treat all relations equally they are actually used for > different use cases where different defaults make sense. For example: > > - Reverse many-to-one (topic.artic

<    1   2   3   4   5   6   7   8   >