Re: Database pooling vs. persistent connections

oncurrent connection is very different than a single operation. On Thursday, February 28, 2013 at 1:40 PM, Michael wrote: > On Thu, Feb 28, 2013 at 4:10 PM, Christophe Pettus <x...@thebuild.com > (mailto:x...@thebuild.com)> wrote: > > > > On Feb 28, 2013, at 11:09 AM

Re: Database pooling vs. persistent connections

Can we please change this so it defaults to off, and just document how to turn it on and in what situations you should turn it on? In my opinion this default-on feature caters to a very specific audience, and will cause a lot of unexpected behavior with other users. Here is the tl;dr of an

Re: Speeding up tests

So a few things we've done to take our test suite from 45 minutes to 12: 1. Implement global fixtures These get loaded after syncing just like initial data. Obviously this is a massive speed up as you only reload them in between transaction test cases. 2. Don't inherit from TestCase if you

Re: initial_data and post_syncdb conflicts

hould always be loaded? Then why > would the other fixtures rely on the initial_data? > > On Aug 18, 4:15 pm, David Cramer <dcra...@gmail.com> wrote: > > > > > > > > > We've been working on switching our test suite to use some new "super > > fixture

initial_data and post_syncdb conflicts

We've been working on switching our test suite to use some new "super fixtures", which are really just global, test-only initial_data style fixtures. To implement this we attach to the post_syncdb, and set a runonce-per-db flag (since it seems to be the only available signal), but we hit some

Re: required=True for BooleanFields

I'm not suggesting changing the behavior (again due to the compatibility concerns), but I completely agree with the original poster(s). Also, in my experience it's a much less common case that you're wanting an "I agree" checkbox in your form, versus a "Boolean" field which can be positive or

Re: ImportError catching in urlresolvers.py

This is currently a problem all over in the Django codebase, and I'd love to see a generic/reusable approach at solving this everywhere. On Jun 14, 1:19 pm, Michael Blume wrote: > In RegexURLPattern._get_callback, we attempt to fetch the callable named by > the URL pattern,

Re: Django Error Display Page

class EasyWin(object): def process_exception(self, request, *args, **kwargs): if not request.is_ajax(): return impot traceback return HttpResponse(traceback.format_exc()) On Jun 10, 1:11 pm, Daniel Watkins wrote: > On Thu, Jun 09, 2011 at 08:31:44PM

Re: Test optimizations (2-5x as fast)

Here's my proposal, assuming it can be done: 1. Create default database. 2. Run a test 3. If a test has fixtures, check for, and if not, copy base table to ``name_``. 4. Start transaction 5. Run Tests 6. Roll back I think that pretty much would solve all cases, and assuming you reuse tons

Re: Test optimizations (2-5x as fast)

Is there a sensible to way "copy" databases in SQL? it's pretty obvious with things like sqlite, but outside of that seems tricky. I really like that idea, and you should definitely just be able to (at the very least) run a unique hash on the required fixtures to determine if a database is

Re: Test optimizations (2-5x as fast)

correspond to a fixture or a model in the same app. -- David Cramer http://justcramer.com On Mon, May 16, 2011 at 9:09 PM, Erik Rose <e...@mozilla.com> wrote: > Woo, thanks for the constructive suggestions! > >> Also, one thing I'm quickly noticing (I'm a bit confused why

Re: Test optimizations (2-5x as fast)

, you're still reliant that nothing was created with signals that uses constraints. For us this is very common, and I can't imagine we're an edge case there On May 13, 9:42 pm, David Cramer <dcra...@gmail.com> wrote: > You sir, are my personal hero for the day :) > > We had also been lo

Re: Test optimizations (2-5x as fast)

Also, one thing I'm quickly noticing (I'm a bit confused why its setup_class and not setUpClass as well), but this wont work with postgres without changing the DELETE code to work like the test runner's TRUNCATE foo, bar; (due to foreign key constraints). On May 13, 9:42 pm, David Cramer <d

Re: Test optimizations (2-5x as fast)

You sir, are my personal hero for the day :) We had also been looking at how we could speed up the fixture loading (we were almost ready to go so far as to make one giant fixture that just loaded at the start of the test runner). This is awesome progress On May 13, 4:57 pm, Erik Rose

Re: get_or_create can still cause IntegrityError

Would it help (in PG-world) at least if the selects where in savepoints as well? On May 7, 10:09 am, David Cramer <dcra...@gmail.com> wrote: > We hit this same issue in Postgres (it's definitely not MySQL > specific). I'm unsure of the solution or precise conditions we're > hitti

Re: get_or_create can still cause IntegrityError

We hit this same issue in Postgres (it's definitely not MySQL specific). I'm unsure of the solution or precise conditions we're hitting it in, but I think by default we use READ COMMITTED. On May 7, 3:28 am, Tomasz Zielinski wrote: > I think that get_or_create

django.conf.settings.get()

Ticket speaks for itself: http://code.djangoproject.com/ticket/10098 My vote is to reopen it, as this is very common, easy to implement, and very unlikely that it would ever need deprecated. -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: Expensive queryset cloning

In our profiling we've also noticed the cloning to be one of the slowest parts of the app (that and instantiation of model objects). We haven't yet, but had been planning on exploring a way to mutate the existing class in most circumstances, but haven't dug into it too much yet. On Mar 14, 11:16 

Re: Default project layout / directory structure

Check out django-startproject from lincolnloop.com https://github.com/lincolnloop/django-startproject Kill off all the server configs (though some of it might be cool, like Fabric integration), and I think it'd make for a pretty good base to work from if this were to go into core. On Mar 13,

Re: Backwards Incompatible API Changes

I have no idea how I've done this, twice. On Feb 10, 2:16 pm, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Thu, Feb 10, 2011 at 5:14 PM, David Cramer <dcra...@gmail.com> wrote: > > We're going to be deploying a backwards incompatible change to all > > "since&

Backwards Incompatible API Changes

We're going to be deploying a backwards incompatible change to all "since" values in the API. Any endpoint which accepts this parameter to use as a form of range pagination will now include the value sent, as well as values before or after it (depending on the order). For example, in the original

Disqus API 3.0

We have been working on a new version of the API these past couple of months, and we're nearing a public release. I wanted to take this opportunity to see if any of the heavy API users (specific needs, etc) would like to chime in with what they want to see, and possible give our docs/api testing

Re: Changing settings per test

I was going to propose the same thing Santiago. Signals seem like the ideal candidate to solve that problem. -- David Cramer http://www.davidcramer.net On Fri, Nov 5, 2010 at 4:57 AM, Santiago Perez <san...@santip.com.ar> wrote: >>  * Settings that are internally cached. For examp

Re: Changing settings per test

ms(): if v is NotDefined: delattr(settings, k) else: setattr(settings, k, v) return _with_settings return wrapped -- David Cramer http://www.davidcramer.net On Thu, Nov 4, 2010 at 2:26 PM, Alex Gaynor

Changing settings per test

A common behavior I seem to have is the need to tweak the settings object for certain test cases. The other case is that in many cases we were (are?) relying on settings being configured a certain way for the Django tests to even work. I brought this up in #django-dev a while back, but wanted to

Re: Could not import man.credit.views, python 2.6.5. "No module named dl" error

It's an import issue with your app unrelated to django core. Someone here will eventually tell you to direct that to django-users, so you might as well hop over there now. On Jul 12, 4:31 pm, pacman wrote: > Hi, > > I've upgraded our python from 2.4 to 2.6.5.  When

Re: Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)

Realizing my original statement I was regarding this thread, in this thread, it's obvious that this has gone completely off track. I might have to take back everything I thought about this being useful. If you want to address a SPECIFIC concern, it makes sense to do that under its own topic.

Re: High Level Discussion about the Future of Django

I just want to throw my 2 cents into the ring here. I'm not against a fork, but at the same time I want to see the Django mainline progress. However, let me tell you my story, and how I've seen the Django development process over the years. I started with Django 4 years ago. It was cool, shiny,

Re: Front-End Developer - Contract/Telecommute | 40-50/hour

On Apr 7, 4:47 pm, OSS wrote: > Front-End Developer - Contract/Telecommute | 40-50/hour > > My client is a B2B media company and they are looking to hire a Front- > End Web Developer for a few upcoming projects, ranging from an online > publication development

Re: proposal: ask a queryset to not raise exceptions

I definitely would like to see this handled in Django, but not in the way mentioned. I personally think there does not need to be an option for what it raises. I think of this in the situations where find methods return either a -1, or an Exception, based on which method you call. Now I can't

Re: examples directory

It's already been done orokusaki. The examples were (humbly) horrible as well. No template usage, just generic HttpResponse. That's basic Python, and docs > examples (in code). On Feb 15, 11:52 pm, orokusaki wrote: > -1 I think examples, broken or working, are very

Re: QuerySet.exists() - Possible bug?

MySQL, in this situation, would have to actually select a row to return a result, so it's slower. If it was just select 1 as a from table where indexed_value = N, it doesn't even hit the tables, just the indexes. It's definitely not more efficient, and probably just an oversight somewhere. On

Re: What The Enterprise wants from Django

The first three have been huges ones with us. We're just now running into the settings issue, but would love to see what people can come up with for solutions (we dont have a good one). Glad to see multi db is finally shipping, and excited to see what can be done for startup procs. On Jan 19,

Re: Model validation incompatibility with existing Django idioms

For us we definitely use this behavior, and I'm guessing this is about to bite us in the ass. I would think a simple fix would be to have a commit=False, and validate=True keyword arg. By default, validate is NoInput, but if commit is False it defaults to False. Wouldn't that be a simple enough

Re: Session/cookie based messages (#4604)

I'm with Luke on this for the exact reasons he describes. Sent from my iPhone On Dec 5, 2009, at 7:24 PM, Russell Keith-Magee wrote: > On Sun, Dec 6, 2009 at 10:28 AM, Luke Plant > wrote: >> On Sunday 06 December 2009 00:56:56 Russell Keith-Magee

Re: Session/cookie based messages (#4604)

I agree, this is 30 minutes of work to change the usage in Django, and it should be done with the inclusion of the messages patch. David Cramer On Fri, Oct 16, 2009 at 1:08 PM, Tobias McNulty <tob...@caktusgroup.com>wrote: > > On Fri, Oct 16, 2009 at 5:10 AM, Luke Pl

Re: Session/cookie based messages (#4604)

. David Cramer On Tue, Oct 13, 2009 at 2:53 AM, Hanne Moa <hanne@gmail.com> wrote: > > On Tue, Oct 13, 2009 at 09:27, Russell Keith-Magee > <freakboy3...@gmail.com> wrote: > > I'm just > > noting that adding Django support for Python logging

Re: Session/cookie based messages (#4604)

user. It's no quicker doing it internally than it is using itertools.groupby or regroup in a template. ---- David Cramer On Mon, Oct 12, 2009 at 1:32 PM, Tobias McNulty <tob...@caktusgroup.com>wrote: > > On Mon, Oct 12, 2009 at 2:02 PM, David Cramer <dcra...@gmail.com> wrote:

Re: Session/cookie based messages (#4604)

o optimize it than regroup. However, with doing this it'd be very important that it doesn't clear the messages unless you're pulling it out. django-notices handles this by popping out elements in the iter (I believe), so that if you don't pop the message out, it's still present. ---- David Cramer O

Re: Session/cookie based messages (#4604)

definitely be a factor in the decision. Sent from my iPhone On Oct 12, 2009, at 9:39 AM, Tobias McNulty <tob...@caktusgroup.com> wrote: > > On Mon, Oct 12, 2009 at 10:21 AM, David Cramer <dcra...@gmail.com> > wrote: >> I also don't think this problem is being addressed her

Re: Session/cookie based messages (#4604)

I also don't think this problem is being addressed here. Yes you could pass messages to the context, but you would lose the ability to retrieve those variably. I believe storing it in the existing session is the best appoach for django's builtin support. Sent from my iPhone On Oct 10, 2009, at

Re: Session/cookie based messages (#4604)

The proposal per your email is more or less how django-notices works. Sent from my iPhone On Oct 10, 2009, at 12:53 PM, Tobias McNulty wrote: > > On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty > wrote: >> Things that still need to be

Re: Let's Talk About ``to_field``

I believe someone had linked a ticket before, but I was unable to find one, so I went ahead and submitted it here: http://code.djangoproject.com/ticket/11938 David Cramer On Wed, Sep 23, 2009 at 6:41 PM, David Cramer <dcra...@gmail.com> wrote: > As usual, my apologies for lackin

Re: Let's Talk About ``to_field``

t work as advertised, and it is advertised. You would have to talk to the author of newforms-admin, which I believe was Brian Rosner. There is some special code for handling to_field lookups in the admin. [1] http://www.pastethat.com/LUYWh David Cramer On Wed, Sep 23, 2009 at 6:27 PM,

Re: Session/cookie based messages (#4604)

I'm a bit late in here, and it seems we reinvented a wheel as well (even tho we did this about a year ago), but recently just OS'd our simply notices system [1]. I'm also +1 for including something like this in trunk rather than using the current user messages. I had a brief look at django_notify

Let's Talk About ``to_field``

I haven't brought this up for quite a while, but ``to_field`` still does not function properly (at least as of 1.1, I haven't noticed any changes addressing it though). The issue is that anywhere you do a GET lookup, it doesn't process the to_field properly:: # TODO: waiting on to_field

Re: 1.2 Proposal: django debug toolbar in contrib

Oh, and thats most likely my branch you're referring to Martin. I implemented a lot of the panels, and went so far as adding crazy monkey patching in some of them to catch some information I wanted. http://github.com/dcramer/django-debug-toolbar/tree/master On Aug 11, 11:38 am, Martin Maney

Re: 1.2 Proposal: django debug toolbar in contrib

I think it's mostly only my fork (and it's forks) that vary much from trunk. I never got around to changing the framework to come in line with the master branch I think because it didn't support everything that was needed. Not sure if it does now however. On Aug 12, 4:00 pm, Rob Hudson

Re: Why does get_profile exist?

I was never a fan of the profile model as it stands. It's not very practical in every situation I've ever been in. Being that 1.0 was supposed to be backwards compatible, and this is a public API I think it needs to stay. I'd love to see a way to swap out the User model in the future though,

Re: django.contrib.sitemaps Additions and Tweaks

Actually before I get a "wtf" response, I should note that the two generators do not quite match. One is rendering a template, the other is simply yielding XML. The latter approach is what I prefer, but I was rushing to finish the index generator :) On Jan 14, 11:49 am, David Cr

[Proposal] django.contrib.sitemaps Additions and Tweaks

While the Sitemaps framework in Django is fairly complete, there's a few things it's lacking, namely the ability to specify attributes for a Sitemap index file. We ended up rewriting our sitemaps, but I wanted to throw our code up here for an example of what we came up. Keep in mind that we are

Re: autodiscover for contrib.sitemaps

It would be kind of neat to have some generic autodiscover functionality for this kind of stuff. Not only could you reuse it in things like sitemaps, templatetags, and admin, but it could be used by other developers for plugable systems of their own. On Dec 19, 4:01 am, andybak

Re: Exception emails in django.core.handlers.base

We simply send them to localhost. Learned the lesson long ago to not spam a normal email account with it :) On Dec 16, 4:15 pm, "Jeremy Dunck" wrote: > On Tue, Dec 16, 2008 at 3:44 PM, Jacob Kaplan-Moss > > > > wrote: > > > On Tue, Dec 16, 2008 at

Re: Custom Fields API Cleanup

Could we just use a lazy proxy for the value value? When it's executed, it could then just call the get_value_from_db method (or whatever). On Tue, Dec 16, 2008 at 12:37 PM, Marty Alchin wrote: > > On Tue, Dec 16, 2008 at 1:03 PM, Jacob Kaplan-Moss >

Re: Custom Fields API Cleanup

I should also note, that these changes, could possibly be carried over into Model Field's. As IIRC they were suffering from some of the same problems. On Tue, Dec 16, 2008 at 12:03 PM, Jacob Kaplan-Moss < jacob.kaplanm...@gmail.com> wrote: > > On Tue, Dec 16, 2008 at 9:06 AM, David

Custom Fields API Cleanup

Recently we've been doing a lot of work with custom fields, and have had a few inconveniences come up. Some minor, some not so much. I'd like to propose a few changes to the API to make it easier to write custom fields, especially those which use custom data structures. The first of which, is

Re: Additional Fields in Core

eaning should be > dealt with. (And I think if they subclass TextField they are reasonably easy > to do without too much backend awareness.) > > My $0.02, > Mike > > On Mon, Dec 15, 2008 at 5:07 PM, David Cramer <dcra...@gmail.com> wrote: > > > I'd like to propose the

Additional Fields in Core

I'd like to propose the addition of some useful (and common) fields in the django core. Things like a JSONFied, YAMLField, HTMLField?, UUIDField, etc. A lot of these seem like common things people use, and while many examples are out there, it'd be nice to simply include these in core so there's

Re: How do you handle cascading deletes in your production apps?

To be perfectly honest, I'm +1 on a solution. I didn't realize this was happening either. Time to monkey-patch QuerySet's delete() method :) (I'm also a bit curious as to how its handling cascades in MySQL when it's not looping through each object) On Dec 10, 12:43 pm, "Karen Tracey" <[EMAIL

Re: Caching over 1MB

Oh no, now I'm going to get more emails saying the code needs updated :) There is a concept in the orm cache that splits it though, so you can probably use that idea. On Dec 7, 10:04 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On Sun, Dec 7, 2008 at 8:55 AM, Calvin Spealman <[EMAIL

Re: BitmaskField

new choices should be added to the end.  Another option > is to store the choices in something like the django_content_type field and > verify on syncdb (or some other place, not sure where it would go) that any > old field types were not assigned to a new mask. > > Craig > >

Re: SessionWizard

on the data stored each time, but not really sure. On Dec 4, 5:23 am, "Hanne Moa" <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 03:34, David Cramer <[EMAIL PROTECTED]> wrote: > > When the done() method is called, the session is also cleared unless > >

Re: BitmaskField

Awesome to see some people working on this. I had tried pre-queryset refactor and It was just not doable witht he fields API. Can't wait to see the final result of this :) I'm also agreeing with the API of field = BitMaskField(choices=LIST) On Dec 6, 10:37 am, Carl Meyer <[EMAIL PROTECTED]>

Re: SessionWizard

, 7:50 pm, David Cramer <[EMAIL PROTECTED]> wrote: > So I needed the ability to specify initial data for a wizard, and I > also liked the idea of storing it in the session (vs the POST). I was > pointed to the SessionWizard patch, and I believe this was a 1.1 > possibility as well

SessionWizard

So I needed the ability to specify initial data for a wizard, and I also liked the idea of storing it in the session (vs the POST). I was pointed to the SessionWizard patch, and I believe this was a 1.1 possibility as well, so I figured I'd bring up the numerous issues. First and foremost, the

Re: Make django debug page simple when develop ajax page(with firebug)

I'll agree 100% that a request.is_ajax() hook to output some simplified data would be awesome. On Dec 2, 10:42 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Perhaps a better solution would be to vary based on request.is_ajax(). > > Alex > > On Dec 2, 11:37 pm, kernel1983 <[EMAIL

Re: Proposal: deprecate and remove django.utils.simplejson

I have nothing against removing it from the built-in libs, but as long as we look for the system's libraries first what's the big downside to keeping it? On Dec 1, 5:02 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Mon, Dec 1, 2008 at 4:21 PM, James Bennett <[EMAIL PROTECTED]> wrote:

Re: Dropping Python 2.3 compatibility for Django 1.1

+1 Update your damn distros. Generators are important :) On Nov 26, 10:33 am, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote: > On Wed, Nov 26, 2008 at 7:23 AM, varikin <[EMAIL PROTECTED]> wrote: > > On Nov 25, 7:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > > wrote: > >> However, even saying

Re: defer().

ot;Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Sat, Nov 22, 2008 at 3:50 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > Ok with all of that being said. I've checked the ticket (once again), > > and there doesn't seem to be any API proposed for fields as inc

Re: defer().

Ok with all of that being said. I've checked the ticket (once again), and there doesn't seem to be any API proposed for fields as include- only. Is there another ticket other than #5420? On Nov 21, 7:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, 2008-11-21 at 12:53 -08

Re: defer().

[EMAIL PROTECTED]> wrote: > > > On Fri, Nov 21, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > > I won't use defer, and I won't recommend people use it. I think it's > > > not good practice. It's like using .select_related() implicitly. You > &

defer().

To avoid messing with the 1.1 Roadmap anymore. What happened with defer (). I know personally myself, and several others who expressed opinions, wanted more than just an exclude option, but an include-only option. Is this part of the "Exclude fields in a SELECT (QuerySet.defer())" or is this

Re: Proposal: Composite Foreign Keys

ows, since that seems to use the primary key. So I clear() >> and re-add instead of delete()-ing, since that doesn't use the primary >> key. Fragile, but it beats doing the puppy-eyes to the DBA. >> > > > > > -- David Cramer Director of Technology iBegin http://www

Re: Post about django optimizations

It would be a lot more useful if you put details in to it. Right now this post looks like spam on the developers group. I'm curious as to your issues with the Paginator class. Works great for me (barring some additional context vars). On Nov 17, 11:43 pm, Dipankar Sarkar <[EMAIL PROTECTED]>

Re: Django documentation index redesigned

My only opinion, is beyond the tutorial, people would much rather search then dig for the link :) On Nov 18, 10:54 am, "Clint Ecker" <[EMAIL PROTECTED]> wrote: > Aw, I had actually started to like/get used to the old-new way ;) > > > > On Tue, Nov 18, 2008 at 1:44 AM, Adrian Holovaty <[EMAIL

Re: Improving Errors from manage.py

Ahh. I suppose that makes sense. Is there any reason it doesn't show them by default? On Nov 17, 3:45 pm, "Alex Koshelev" <[EMAIL PROTECTED]> wrote: > Try to use `--traceback` switch that prints exception's traceback > > On Tue, Nov 18, 2008 at 00:41, David Cramer

Improving Errors from manage.py

I've been trying to dump some data to fixtures for the last couple days, and I've ran into various problems each time. It's been quite difficult each time to determine the problems, as there's no useful tracebacks on the error messages: [EMAIL PROTECTED]:~/Development/iplatform] ./manage.py

Re: Multi-Threaded Dev Server

I think I may have to actually agree that multi-threading is somewhat needed, since it does limit these kind of features from working. I, however, would deem it less a priority than most thing. If you can write a patch for it (or if one exists, I didn't look) though, I don't see any reason to not

Re: Proposal: Composite Foreign Keys

accidently committed. The list_select_related changes I proposed. There is also an issue with URL resolving in the admin (its a 1.1 proposal) so it's using a , vs a / for the delimiter, but it's a simply setting change. On Nov 16, 5:50 pm, David Cramer <[EMAIL PROTECTED]> wrote: > http://g

Re: Proposal: Composite Foreign Keys

lease keep in mind that the feature list we're drafting > right now isn't set it stone. Anything that gets finished between now > and the feature freeze date for 1.1 (2/15/09) is a candidate for > inclusion. We develop these feature lists to help people figure out > what to work on; nobod

Re: Django 1.1, app() and ticket #3591

I personally was a 0 on this one. Let me explain why. I want Django to be a strong platform for developers, like myself, who really want the opportunity to have power in the framework, as well as features. As of lately I have been using Rails for a project, and to be quite honest, the maturity

Branches on Github

Not the *best* place to post this, but it does relate to Django dev. Is it possible, and if so how, could one branch the Django trunk, and throw it on Github? >From what I've read I could then do some kind of "svn up" to merge in latest changes easily from trunk, and also work on my branch

Re: Proposal: Composite Foreign Keys

wrote: > On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote: > > I was thinking beyond just handling Foreign Keys actually when I wrote > > this up. It would allow for a more generic version of a generic > > foreign key. > > Generic relations are quite different to foreig

Re: Feature reviews for 1.1

I volunteer for #17! And I have working code for a pretty simplistic message handler which is session vs database based (which is one of the proposals, sort of). So I guess if that's whats wanted, I can mold it to fit what has been discussed. On Nov 13, 5:03 pm, "Jacob Kaplan-Moss" <[EMAIL

Re: Proposal: Composite Foreign Keys

is all thats stopping me from completing the composite PKs patch. On Nov 13, 7:19 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2008-11-13 at 10:53 -0800, David Cramer wrote: > > Here's my proposal for the composite keys (which act much like generic > > ke

Proposal: Composite Foreign Keys

Here's my proposal for the composite keys (which act much like generic keys except more useful): class MyModel2: pass class MyModel3: pk_part1 = models.AutoField() pk_part2 = models.ForeignKey(MyModel2) name = models.TextField() class MyModel: pk_part1 =

Re: Proposal: Ordering in the admin and via the model API

Ya this is much more needed for me on ForeignKey's, but that's like adding magical models (which I like!). You'd have to add left order, and right order fields, on the model referenced in the ForeignKey, to have an OrderedForeignKey field. This, without migrations, would not be fun with DB

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

y all go together insofar as returning you to *exactly* the   > view you were last using.  If you're going to preserve it at all,   > might as well do it right and preserve it as pristinely as possible. > > On Nov 11, 2008, at 5:34 PM, David Cramer wrote: > > > > >

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

ask for something to be added to the admin that would print   > out a URL that you could give to another user to get the filtering you   > were just using.  Which sounds handy, but is a separate ticket from   > what we're discussing here. > > On Nov 11, 2008, at 4:47 PM, David Cramer wrote:

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

URL.  Naturally if   > you do it this way, you'd also want to have a visible "clear filters"   > link so that there's some way to reset that state, I didn't check the   > patch to see if this was already included. > > On Nov 11, 2008, at 4:35 PM, David Cramer wrote: >

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

Before this gets accepted, I'd like to throw in the proposal of storing this in the session vs a huge URL. That and a hash seem to be the common approach to storing search paths. On Nov 11, 7:19 am, Jonas Pfeil <[EMAIL PROTECTED]> wrote: > Currently if you search in the admin, use some kind of

Re: select_related optimization and enhancement for the django.contrib.admin

an be a boolean, or a list. This, in my eyes, is fully backwards compatible, as its only an addition to the public API, and a bug fix. On Tue, Nov 11, 2008 at 3:17 AM, Malcolm Tredinnick < [EMAIL PROTECTED]> wrote: > > > On Mon, 2008-11-10 at 17:13 -0800, David Cramer wrote: >

Re: Denormalisation Magic, Round Two

I'm not sure on AggreateField either. What if you just do like ("Photo", "user__exact=self.user") or something. Currently there's no rerepsentation for "self" in Django QuerySet's, so this is a hard thing to call. Also, we need a way to support callables. e.g.

order_by_fields for django.contrib.admin

One of the last of my feature-needs (for optimization reasons) is the ability to specify what fields can, or can't be ordered in the admin apps. I'd like to propose something along the lines of: order_by_fields = ('field', 'field', 'field') This would allow you to only order by fields

select_related optimization and enhancement for the django.contrib.admin

While I've been working on composite primary keys, I also made a few tweaks to the admin app. Most of these are related to the primary key support, but one is an optimization. I would post this as a patch, or a ticket, but I want to open this up for discussion, and my django repo is so far from

Re: Cache and GET parameters

I really like the idea of the explicit GET params passed.So I'm +1 especially on solution #3. I actually had never realized it wasn't caching pages with GET params, luckily though, any pages where I use this decorator don't fluctuate like that :) On Nov 1, 7:51 pm, "Jeremy Dunck" <[EMAIL

Re: Composite Primary Keys

oposals earlier along on this thread, but > obviously nothing solid. Did anything ever come from DjangoCon on this > topic? What issues still need to be addressed in this design? > > On Thu, Oct 30, 2008 at 13:46, David Cramer <[EMAIL PROTECTED]> wrote: > >> It allows you to us

Re: Composite Primary Keys

ese models which really -do not- need them, makes me a bit ill. > > I would be more than willing to help test your implementation if there > is anything usable yet. This is one of the pieces that's getting me > all twitchy waiting for it. > > > -- David Cramer Dir

Re: Alternate ForeignKey based on choices

What you're wanting is a GenericForeignKey. Check out the django.contrib.contenttypes documentation. On Oct 26, 9:48 am, "Calvin Spealman" <[EMAIL PROTECTED]> wrote: > You could also have a common parent class for Robot and User, and use that > as your foreign key type. Which type is referenced

Re: Proposal: AnonymousUser that you can set specific permissions for

ssions set to it. On Oct 25, 10:46 am, "Dj Gilcrease" <[EMAIL PROTECTED]> wrote: > On Sat, Oct 25, 2008 at 2:59 AM, David Cramer <[EMAIL PROTECTED]> wrote: > > > I think being able to specify permissions for the AnonymousUser is > > useful, but

  1   2   3   >