Re: skipping elidable migrations

nction that uses > cursor.execute(). And if a project develops problems with past migrations, > it's always possible to (carefully) edit them to include such conditions. > > On Fri, 9 Nov 2018 at 16:11, Dan Watson > > wrote: > >> Hi All, >> >> I was wondering i

skipping elidable migrations

Hi All, I was wondering if anyone had any thoughts on an option to the "migrate" command (--skip-elidable?) that would skip running elidable migrations. The use case here is that data migrations that build up over time may act on certain assumptions (existing tables/data) that may not be true

Re: about ticket 28588- has_perm hide non-existent permissions

Seems like maybe it would be more helpful if has_perm logged a note about the permission not existing (probably only in debug), rather than just returning False. In fact, I'd argue it should still return True -- if the permission did exist, the superuser would have it. And there's a

Re: Suggested documentation: PG server-side cursors used in .iterator() only work inside a transaction

Declaring a cursor WITH HOLD means it can be used outside transactions, but it seems like the server-side cursors are already set up WITH HOLD when autocommit is on: https://github.com/django/django/blob/master/django/db/backends/postgresql/base.py#L212 So I'm guessing maybe you've disabled

Re: Using AbstractBaseUser without django.contrib.auth

On Thursday, April 2, 2015 at 10:38:48 AM UTC-4, Marc Tamlyn wrote: > > Apologies, I was confusing abstract base user and abstract user there. > Seems your proposal should work. Have you opened a ticket? > I have: https://code.djangoproject.com/ticket/24564

Re: Using AbstractBaseUser without django.contrib.auth

On Thursday, April 2, 2015 at 2:27:51 AM UTC-4, Marc Tamlyn wrote: > > Moving them into another module won't make much difference as their > definition requires Permission and Group and therefore they'd still need to > import Permission and Group. We'd need an "AbstractAbstractBaseUser" which >

Re: Using AbstractBaseUser without django.contrib.auth

> I'm using my own permissions system, but implementing everything PermissionsMixin does (without subclassing it) so the admin still works. > -- > Curtis > > On 2 April 2015 at 13:47, Dan Watson <dcwa...@gmail.com > > wrote: > >> While trying out Django 1.8 wit

Using AbstractBaseUser without django.contrib.auth

While trying out Django 1.8 with one of my sites that uses a custom User model (and doesn't have django.contrib.auth in INSTALLED_APPS), I noticed a few unexpected deprecation warnings: /Users/dcwatson/Documents/Environments/reader/lib/python3.4/site-packages/django/contrib/auth/models.py:41:

Re: Proposal: unique by default on SlugFields

On Wednesday, June 27, 2012 7:15:03 AM UTC-4, Meshy wrote: > > Perhaps it's just me, but I've very rarely wanted a SlugField that wasn't > unique. Would this not be a sensible default? I realise that a lot of apps > will rely upon this default, but objectively speaking would this not be >

Re: revisiting #7726

On Saturday, July 30, 2011 8:59:48 PM UTC-4, Russell Keith-Magee wrote: > > On Fri, Jul 29, 2011 at 11:07 PM, Dan Watson <dcwa...@gmail.com> wrote: > > We were recently bitten by a backwards-incompatible change that seemed to > > creep in between 1.2.4 and 1.2.5. D

revisiting #7726

We were recently bitten by a backwards-incompatible change that seemed to creep in between 1.2.4 and 1.2.5. DecimalFields that define max_digits == decimal_places used to be valid until #7726 [1]. When trying to upgrade to 1.2.5, several models failed validation. Changing them such that

Re: combining querysets with isnull

On Thursday, October 14, 2010 7:03:35 PM UTC-4, Johannes Dollinger wrote: > > > Am 14.10.2010 um 23:07 schrieb Dan Watson: > > > There seems to be some inconsistent behavior when combining querysets > > that use isnull on a ForeignKey. I'm not sure how to explain it well

Re: #14733: A vote in favor of no validation of .raw() queries

On Wednesday, March 9, 2011 4:15:43 PM UTC-5, Xof wrote: > > Hi, > > I'd like to offer a vote in favor of accepting the original patch to > #14733, which removes the validation of the query done in a .raw() operation > on a QuerySet. > > The current situation is that Django requires that any

Re: Re-open #7231: New "join" parameter for the "extra" QuerySet method

On Tuesday, March 8, 2011 6:16:26 PM UTC-5, Russell Keith-Magee wrote: > > On Wed, Mar 9, 2011 at 7:09 AM, Jacob Kaplan-Moss > wrote: > > On Tue, Mar 8, 2011 at 9:35 PM, bendavis78 wrote: > >> I'd like to start a discussion on this since russelm closed

combining querysets with isnull

There seems to be some inconsistent behavior when combining querysets that use isnull on a ForeignKey. I'm not sure how to explain it well in plain english, so here's a boiled-down example: # Models class Item (models.Model): title = models.CharField( max_length=100 ) class PropertyValue

Re: Adding signing (and signed cookies) to Django core

On Sep 24, 3:46 pm, Simon Willison wrote: > > 1) request.unsign_cookie('foo') -- This breaks the parallelism with > > existing cookies.  Sometimes we'll be doing request.COOKIES['foo'] and > > sometimes we'll be doing request.unsign_cookie('foo'). > > If we were going

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

On Mar 15, 4:40 pm, Jacob Kaplan-Moss wrote: > We take a slightly more reasonable approach to backwards compatibly as > detailed > athttp://docs.djangoproject.com/en/dev/misc/api-stability/#what-stable- > Read that carefully: nothing there prevents us from adding

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

On Mar 15, 1:12 pm, "Gary Wilson Jr." wrote: > What do you think? Wouldn't this be a backwards-incompatible change at this point? It would clash with any model fields named "update". Dan --~--~-~--~~~---~--~~ You received this message

Re: uploaded file permissions

On Aug 14, 5:29 pm, Dan Watson <[EMAIL PROTECTED]> wrote: > As mentioned a few times in #2070, uploaded files large enough to be > streamed to a temporary file get created with a mode of 0600, as per > python's tempfile.mkstemp. This causes two problems: > > 1. Files

database schema support

I know this has been touched on a couple times, but I have an itch for database schema support I'd like to scratch. The relevant ticket it #6148 [1]. I was thinking the Options class would grow a db_schema field, which would default to settings.DEFAULT_DATABASE_SCHEMA. Then everywhere that

Re: Subversion Access

Questions like this should be directed to the django-users mailing list. That said, this is probably caused by your proxy server not understanding how to handle subversion's requests. See http://subversion.tigris.org/faq.html#proxy or search the mailing lists - this has come up before. On May

Re: QuerySet.exists()

On Oct 17, 6:47 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > You want to read this thread (first result when searching the group > archive for "queryset exists"): > > http://groups.google.com/group/django-developers/browse_frm/thread/54... I mentioned that thread at the bottom of my post,

QuerySet.exists()

I was wondering what people thought of adding a .exists() method to querysets that would take another QuerySet, and add a "WHERE EXISTS (SELECT ...)" to the original query. It would require that the passed- in QuerySet be joinable with the original QuerySet via a ForeignKey relationship. Take the

Re: proposal: update QuerySet.get() to return a default if object does not exist?

Just to ping this again (since I think it's super-convenient and don't want it to get lost), I've created ticket 5741 with a patch and doc changes. The patch would look the same for the queryset-refactor branch as it stands now, too. http://code.djangoproject.com/ticket/5741 Dan On Aug 23,

Re: None != Null?

Just thought I'd mention one other point to consider: at least in postgresql, there is a configuration option to transform "= NULL" to "IS NULL" on the fly. [1] So if you're using "= NULL" (which is an error in virtually all cases) you may get different results on different databases anyway.

Re: Google Sitemaps

[EMAIL PROTECTED] wrote: > I've installed it and it's very nice. I've moved "sitemap" to contrib - > is it ok? :) because there is one minor problem is with sitemap.xml - > it try to load it from: > > Django tried loading these templates, in this order: > Using

Re: Google Sitemaps

Jacob Kaplan-Moss wrote: > On Aug 30, 2006, at 11:51 AM, Dan Watson wrote: > > Just wanted to draw some attention to > > http://code.djangoproject.com/ticket/2628 - it's a contrib app I've > > written to automatically generate sitemap.xml files for Google. I've > >

Google Sitemaps

Just wanted to draw some attention to http://code.djangoproject.com/ticket/2628 - it's a contrib app I've written to automatically generate sitemap.xml files for Google. I've also written about it here: http://theidioteque.net/blog/2006/08/29/google-sitemaps/ Not sure if people will use it, but

Re: Validation Aware Models and django.forms on steroids

> I'm afraid that I find the idea in Brantley Harris's proposal of > raising a Form as an exception as a form of flow control really > counter-intuitive. Apologies and it's just my opinion of course, but it > has a sort of "too clever" feel to me. Also, exceptions are very > expensive, and I

Re: [Fw]The Python Web Framework

> In my experience such simple behavior is rarely needed. When you > actually need a pool it means that your app become pretty large so it > requires not only static pool but also other settings like minimum spare > connections, maximum spare connections, keep-alive timeouts etc... So > this

Re: Multi-db branch feedback/questions

Another use case to mull around: I'm currently using django for basically everything *but* it's ORM, in large part due to not supporting multiple databases. We have one software package with many nearly-identical databases (for different customers). The models would be the same, but I'd want to

Re: Moving auth and core models to contrib -- and dependencies

I'm definitely +1 on splitting out the core and auth models/tables. If installing them is just as simple as running init and installing the admin app is now, what's the big deal? For those who want it, it's no harder, and you'd be able to install the admin without even realizing you're installing