Re: More efficient negative lookups

On Oct 27, 2010, at 5:55 PM, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: >> I'm inclined to say we do the former -- restore the "ne" lookup type >> -- because it's a quick fix, and ask somebody to write up a patch for >> the latter. Does anybody have strong

Re: More efficient negative lookups

On Oct 27, 5:55 pm, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: > > I'm inclined to say we do the former -- restore the "ne" lookup type > > -- because it's a quick fix, and ask somebody to write up a patch for > > the latter. Does anybody have strong opin

Re: MySQL index hints

On Jul 4, 2010, at 1:10 AM, Simon Litchfield wrote: > For those of us using MySQL, having large tables, whilst also wanting > queryset goodness -- > http://code.djangoproject.com/ticket/11003 > > It goes a little something like this -- > Model.objects.filter(field=value).with_hints('my_index') >

Re: Process discussion: reboot

On Apr 19, 2010, at 5:16 PM, Mike wrote: > For the project of such exposure as Django the number of _active_ core > members that actually do work on trunk and are participating in the > decision making process is extremely small. Quick and dirty statistic > on > trunk commits shows that more than

Re: Opinions sought on m2m signal ordering

On Mar 27, 2010, at 1:08 PM, Russell Keith-Magee wrote: > Option 3: We modify the existing signals so we have a pre-post pair > for every signal. This maintains the analog with pre/post save, and > gives the most control. For example, on Alex Gaynor has suggested to > me that some people might wa

Re: Logging instead of connection.queries

On Aug 3, 2009, at 6:53 PM, Malcolm Tredinnick wrote: > > On Mon, 2009-08-03 at 15:48 +0400, Ivan Sagalaev wrote: >> Hello! >> >> A couple of days ago a sudden thought has struck me while thinking on >> the matter of logging in Python libraries. I consider a good practice >> for a library to log

Re: Should TransactionTestCase flush db in teardown rather than setup?

On Apr 15, 2009, at 2:28 PM, Sean Legassick wrote: > It strikes me that TransactionTestCase should be flushing the database > in the teardown stage of the test case rather than the setup. My > thinking is that when using a mixture of TestCase and > TransactionTestCase (where the latter is only u

Re: Reverse mappings raising exceptions

On Apr 13, 2009, at 5:55 AM, Shai Berger wrote: > I think a stronger case can be made: The reverse OneToOne relation > just should > not throw DoesNotExist, always returning None when there is no > matching > object. This is a realization of the idea that "OneToOne" relations > are > reall

Re: select_related to work with backward relationships?

On Mar 23, 2009, at 8:08 PM, Malcolm Tredinnick wrote: > It is documented in that respect. In a couple of different Trac > tickets > (since there are multiple issues: select related for reverse one-to- > one, > which only isn't in 1.1-beta because I ran out of time to fix the > patch, > and

Re: Small URLconf suggestion

"Those are most *NOT* definitely the same". Typos too early in the morning, sorry about that. On Feb 22, 2009, at 8:29 AM, George Vilches wrote: > > > On Feb 22, 2009, at 7:44 AM, rihad wrote: >> I was just special-casing the backslash, which is special anyway,

Re: Small URLconf suggestion

On Feb 22, 2009, at 7:44 AM, rihad wrote: > I was just special-casing the backslash, which is special anyway, > otherwise APPEND_SLASH wouldn't exist. > Moreover, hello and hello/ (and hello/) _are_ the same URL to > Django, otherwise it wouldn't redirect to the url with the slash > appended.

Re: BitmaskField

Unfortunately, Malcolm has shot this down in the past as something that would be included in Django: http://groups.google.com/group/django-developers/browse_thread/thread/4cc529b95c9efe20/439e90ed09cbcf2e Theoretically, you can do this with a Q object, although I have not tried since Django

Re: Proposal: Make filters in admin persistent (#6903)

se before > that. So it'd need to handle clearing it at the right time as well. > > On Nov 11, 3:51 pm, George Vilches <[EMAIL PROTECTED]> wrote: >> Don't sessions already have standard expirations in them? Besides >> that, this is the admin, it's not a

Re: Proposal: Make filters in admin persistent (#6903)

n > idea, as you increase the size of the session significantly, and then > have to worry about expiring those or clearing them somehow. The > session just keeps it for that users session, vs whoever else happens > to visit that url (say I pass it off to a coworker). > > On Nov

Re: Proposal: Make filters in admin persistent (#6903)

I definitely second this. The extra bonus to storing it in the session is that you can maintain your search state on multiple admin pages/models independently without overflowing the URL. Naturally if you do it this way, you'd also want to have a visible "clear filters" link so that ther

Re: Ticket #7591: Authenticate By Email Support

On Jul 2, 2008, at 1:24 PM, Paul Kenjora wrote: > I understand the resistance but you've got demand, you've got a > willing developer, and you've got a clean fix that significantly > improves the adaptability of the framework. What better reason > would you need? Someone who has a proven

Re: MySQL exact/iexact lookups change

On Jun 30, 2008, at 1:27 PM, Collin Grady wrote: > > George Vilches said the following: >> As of http://code.djangoproject.com/changeset/7798 in the MySQL >> DatabaseWrapper.operations, Malcolm has changed the "__exact" filter >> to use '= BINARY' t

MySQL exact/iexact lookups change

As of http://code.djangoproject.com/changeset/7798 in the MySQL DatabaseWrapper.operations, Malcolm has changed the "__exact" filter to use '= BINARY' to force case-sensitive comparisons, which is appropriate. I therefore propose that operations."__iexact" should be changed from 'LIKE %s'

Re: Nullable foreignkeys do not let me retrieve records where the foreignkey is null

You'll be happy to know that there's a ticket in the system that already resolves this problem: http://code.djangoproject.com/ticket/ 7512 . It will properly LEFT JOIN whenever ordering occurs on null=True relationships on any of the major field types. gav On Jun 23, 2008, at 10:00 AM, Mik

Re: RFC: Django 1.0 roadmap and timeline

Just one fix to this list: On Jun 11, 2008, at 10:03 PM, Jacob Kaplan-Moss wrote: > 8. Many-to-many intermediates (#6905). > Shouldn't that be #6095? http://code.djangoproject.com/ticket/6095 George --~--~-~--~~~---~--~~ You received this message because you a

Re: OneToOne model field bug?

On Jun 11, 2008, at 7:06 AM, patS wrote: > {{ m.z.pool }} prints: something in z > > but if i put {{ m.z.pool }} after {{ m.y.pool }} it will print > something in y not something in z This appears just like a problem that was solved in SVN trunk a couple weeks ago with improper caching on One

Re: Django releases

On Jun 9, 2008, at 9:16 PM, Karen Tracey wrote: > I'd trade your controversial part for an alternative: merge mewforms- > admin back to trunk now. It's been as 'usable' as old admin for > months. Sure, it's got a couple of dozen 'blocking' bugs in the > tracker but none of them are all th

Re: Django releases

On Jun 8, 2008, at 4:27 AM, Wim Feijen wrote: > Fortunately, the trunk is stable (thank you!). I think what people are missing most here is that this statement is moderately inaccurate. Since QSRF, there have been a significant number of data-fetching related tickets that are relatively ea

Re: Magic ORM save()

On May 30, 2008, at 7:29 PM, Jeremy Dunck wrote: > > On Fri, May 30, 2008 at 5:16 PM, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: >> >> Let's discuss the ORM save() method. In my opinion, unless I grossly >> misunderstand what's going on it seems the save method is very >> magical. >> >> Firs

Re: Rethinking silent failures in templates

On May 14, 2008, at 12:29 PM, J. Cliff Dyer wrote: > > On Wed, 2008-05-14 at 19:00 +0400, Ivan Sagalaev wrote: >> Simon Willison wrote: >>> {{ article.something.title }} - outputs text if article is there, >>> fails silently otherwise >>> >>> Which leaves us in a tricky situation. A global setti

Re: Rethinking silent failures in templates

On May 14, 2008, at 9:58 AM, Simon Willison wrote: > Silent errors are bad. If we were to remove them, how much of a > negative impact would it have on the existing user base? I suspect that a lot of people actually rely on this behavior, and it would be devastating to them. What I've persona

Re: Model Inheritance in qsrf and User?

On May 1, 2008, at 11:49 AM, [EMAIL PROTECTED] wrote: > >> Now that QSRF has landed, this type of thinking leads me to: who's >> working on 121-rewrite? > > I'm fairly certain that in refactoring QuerySet, OneToOneField has > been fixed. It's the base mechanism that allows multi-table > subclas

Re: meta attribute for default select_related?

On Apr 30, 2008, at 2:33 PM, Ken Arnold wrote: > > What would you all think about a Meta attribute for models for > select_related, analogous to ordering? i.e., default to selecting > these related fields for any query on this model. > > For example, I have a model roughly like: > > class Contri

Re: Model Inheritance in qsrf and User?

On Apr 25, 2008, at 3:40 PM, Marty Alchin wrote: > *snip* > class AuthorProfile(models.Model): >user = models.OneToOneField(User) >pen_name = models.CharField(max_length=255) Now that QSRF has landed, this type of thinking leads me to: who's working on 121-rewrite? And more important

Re: Feature Request: "Abstract Model"

On Feb 4, 2008, at 7:50 AM, Brian Harring wrote: > > This is a dirty hack mind you, but a rather effective one- I > personally use it for when I need to create common structures w/in > tables and need to able to change the structure definitions in a > single spot. If you did the following- > > de

Re: preventing syncdb from loading initial_data

On Jan 29, 2008, at 10:51 PM, Russell Keith-Magee wrote: > > On Jan 30, 2008 8:17 AM, Joseph Kocherhans <[EMAIL PROTECTED]> > wrote: >> >> I ran into a situation today where for every future site I set up, >> I'll want to load an initial_data fixture, but for some existing >> sites >> that I

Re: Django 1.0 features -- the definitive list

Etienne Robillard wrote: > > > On Nov 30, 2007 2:27 AM, Max Battcher <[EMAIL PROTECTED] > > wrote: > > > On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED] > > wrote: > > move 0.96 to 1.0 status. This might sound somewhat artificial

Bitwise operations in QuerySets?

What I want to do: Assume I have an integer column in a table that contains a value that I want perform a bit operation on. I would like to able to make a QuerySet that generates a query similar to this: "SELECT * FROM table WHERE column & 4;". (example is MySQL-friendly). I've looked around

Missing imports in sessions?

All, Just throwing this out there because I think it breaks everyone currently using sessions against trunk. Already filed a ticket (and patch) for it: http://code.djangoproject.com/ticket/5598 . Short of it, there's a couple imports that look like they're missing from django/contrib/session

Re: Following OneToOne Relationships

[EMAIL PROTECTED] wrote: > I have searched through the dev list and couldn't find anything > relating to the specific thing I am trying to do. I also am aware that > both QuerySet and OneToOne fields are in some sort of flux right now. > > QuerySet is being completely refactored, and I will of co

Re: Creating and using a project-specific database backend?

George Vilches wrote: > Russell Keith-Magee wrote: >> On 8/30/07, George Vilches <[EMAIL PROTECTED]> wrote: >>> Folks, >>> >>> Now that the database backend refactoring has landed, and DB >>> functionality is really easy to extend, how does

Re: Creating and using a project-specific database backend?

Russell Keith-Magee wrote: > On 8/30/07, George Vilches <[EMAIL PROTECTED]> wrote: >> Folks, >> >> Now that the database backend refactoring has landed, and DB >> functionality is really easy to extend, how does everyone feel about the >> possibility

Creating and using a project-specific database backend?

Folks, Now that the database backend refactoring has landed, and DB functionality is really easy to extend, how does everyone feel about the possibility of allowing people to specify their own database backends within their projects (i.e., without modifying the Django source tree in any way?)

Re: Django 500 error debugging causes QuerySets to evaluate

Jeremy Dunck wrote: > On 8/28/07, George Vilches <[EMAIL PROTECTED]> wrote: > ... >> Something seems very wrong about this situation, that debugging could >> cause another query to execute (especially an unintended query), but I >> don't know what the correct w

Django 500 error debugging causes QuerySets to evaluate

Quick summary: If Django errors during a QuerySet evaluation with DEBUG=True, the built-in 500 handler in views/debug.py causes the last QuerySet (one filter shorter than the final version) to be executed, as in the SQL statement hits the database. This is very bad if there was only a single

Re: Run script from management.py

Casey T. Deccio wrote: > I would find it extremely useful to pass a script argument to the > 'manage.py shell' command, so I could run arbitrary scripts using the > models library defined in project/app. I can't currently see a way to > do this except using input redirection: > > python manage.p

Re: Django unit tests for pre/post_save, pre/post_delete signals

Russell Keith-Magee wrote: > On 8/21/07, George Vilches <[EMAIL PROTECTED]> wrote: >> All, >> >> I've looked everywhere in the Django unit tests and can't find anywhere >> that's testing these four signals: > ... >> Thoughts? > > On

Django unit tests for pre/post_save, pre/post_delete signals

All, I've looked everywhere in the Django unit tests and can't find anywhere that's testing these four signals: pre_save post_save pre_delete post_delete I found the dispatcher tests, which cover all the generic bits, but nothing specifically for these model signals. On the assumption that I

Re: Adding hooks to methods that generate SQL in django/core/management.py

Russell Keith-Magee wrote: > On 8/13/07, George Vilches <[EMAIL PROTECTED]> wrote: >> Russell Keith-Magee wrote: >>> The configuration option will need to be a little more generic - i.e., >>> putting the entire backend into a record mode - not just a single >

Re: Taming management.py, the 1730-line behemoth

> I'd like to suggest a (somewhat controversial) extension: > > Let any (installed) app provide its own manage.py actions in a similar > way -- something like:: > > schema_evolution/ > management/ > __init__.py > commands/ > __init__.py >

Re: Changing the options in manage.py, adding more signals

Marty Alchin wrote: > Okay, I'll post one last time on this subject, then leave you guys to > do what you're supposed to be doing. I'm only posting here in case who > heard me ranting find it interesting. I did manage to come up with a > solution like I mentioned, and I'll be posting it soon. It'd

Re: Changing the options in manage.py, adding more signals

Marty Alchin wrote: > This sounds like a far more complicated example than I had considered > when I was doing my work with dynamic models[1], but I did have > success getting syncdb to install dynamic models, provided a few > things are in order. I probably didn't document them well enough on > t

Re: Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

George Vilches wrote: > Russell Keith-Magee wrote: >> On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: >>> 1) Add a signal to every option? >> If we were going to go down this path, this would be the preferred >> option. However, I'm not sure I&#

Re: Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

Russell Keith-Magee wrote: > On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: >> 1) Add a signal to every option? > > If we were going to go down this path, this would be the preferred > option. However, I'm not sure I'm convinced of the need. Which >

Re: Adding hooks to methods that generate SQL in django/core/management.py

Russell Keith-Magee wrote: > On 8/12/07, George Vilches <[EMAIL PROTECTED]> wrote: >> How about the patch below? When you create the cursor, if you want >> access to "don't run this SQL, just have playback available", just use >> connection.cursor(playba

Re: Does SELECT 1 FROM... Work on SQL Server and Oracle?

Simon Greenhill wrote: > Hi all, > > I'm trying to work out if Ticket #5030 is good to go or not. > Basically, when save() is called on a model, django does a SELECT > COUNT(*)... query to check that the primary key is good. > > However, SELECT 1... is apparently quite a bit faster in many > cir

Changing the options in manage.py, adding more signals (was Re: Adding hooks to methods that generate SQL in django/core/management.py)

perfectly legitimate one. :) Russell Keith-Magee wrote: > On 8/9/07, George Vilches <[EMAIL PROTECTED]> wrote: >> So, my proposal is this: generate hooks for users. For each of the >> get_custom_sql/get_create_sql/etc., add a small portion that checks the >> installed apps fo

Re: Adding hooks to methods that generate SQL in django/core/management.py

Russell Keith-Magee wrote: > I would suggest approaching this problem at lower than that - > installing a filter at the level of the database cursor that diverts > queries away from the actual database, and into a store. That way, if > you run the code 'Author.objects.all()' , the backend will ge

Re: Maybe we need more triagers? Or something else?

[EMAIL PROTECTED] wrote: > Another thing to possibly consider is putting out some general > guidelines about the thought process the developers go through to > evaluate the tickets with design decisions needed. In other words, > how do the developers make the decision to include/exclude something

Adding hooks to methods that generate SQL in django/core/management.py

I find that on a few occasions, I've needed to generate extra SQL for both creation and deletion tasks when I'm executing "manage.py syncdb" (or sql, or reset, sqlclear, etc., pretty much all of the SQL generation commands). Currently, if you use only use syncdb for everything, you can do thi