Re: Validation of m2m

My guess is this does not work on MySQL or SQLite, since as far as I can tell it’s the only DB that will return IDs when bulk inserting. I’d think you’d have to have some other code path to handle those DB backends. -- You received this message because you are subscribed to the Google Groups

Re: ConnectionResetError in test_closes_connection_without_content_length

The problem is the version of SQLite included in recent versions of macOS. The easiest fix we saw was installing Homebrew and then doing a `brew install sqlite`. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: Review of DEP 201 - simplified routing syntax

Huzzah! Looking forward to the new syntax landing. On Sunday, May 21, 2017 at 2:56:13 AM UTC-5, Aymeric Augustin wrote: > > Hello, > > The technical board accepted DEP 201: > https://github.com/django/deps/blob/master/accepted/0201-simplified-routing-syntax.rst > > Sjoerd has taken the lead on

Re: A New Design for the "Congratulations!" Page

On Tuesday, April 18, 2017 at 1:25:36 PM UTC-5, Tim Allen wrote: > > Thanks for the kind words. To answer your questions: > > - It is also my hope to automagically create version friendly links, so we > don't see a commit on each Django release. > This ought to be useful to sub in where

Re: Database connection retry

Thanks Aymeric! I'll give that a try next time! On Wednesday, March 8, 2017 at 3:20:31 PM UTC-6, Aymeric Augustin wrote: > > Hello, > > On 8 Mar 2017, at 21:23, Chris Foresman <fore...@gmail.com > > wrote: > > I'll chime in to say I've had a similar problem

Re: Database connection retry

I'll chime in to say I've had a similar problem related to the shell and I couldn't sort out how to address it. Our database servers will drop connections that last longer than 10 minutes. So basically can never do a task I might otherwise use the shell for that would take longer than 10

Re: can_introspect_default feature

Out of curiosity, why isn't this added as part of the column definition? Isn't it better to enforce the default at the DB layer? Or is it to account for differences across database types? (This trips me up a lot because we have a lot of different apps/processes which have to touch the database

Re: Django Channels Load Testing Results

n as well > as up. > > Andrew > > On Mon, Sep 26, 2016 at 1:30 PM, Chris Foresman <fore...@gmail.com > > wrote: > >> Why would you be running a small website in ASGI mode with a single >> worker? My suspicion is that someone using Django in ASGI mode has a >

Re: Django Channels Load Testing Results

u call a pathological case is a small website, running on > something like cheap VPS. > > > > 2016-09-26 15:59 GMT+02:00 Chris Foresman <fore...@gmail.com >: > > > Robert, > > > > Thanks! This really does clear things up. The results were a little &g

Re: Django Channels Load Testing Results

splitting traffic for just websockets if you don't > want to run redis for some reason. > > > > Robert Roskam > > On Wednesday, September 14, 2016 at 10:21:27 AM UTC-4, Chris Foresman > wrote: >> >> Yes. Honestly, just explain what these results mean in words, be

Re: Challenge teaching Django to beginners: urls.py

I'd really, really like an alternate URL resolver which does typecasting. I mean, if I'm specifying the type right there, why not expect the resolved to be the type I just specified? In 995 of URLs, you're talking about three basic types anyway: strings, integers, and (increasingly) UUIDs.

Re: Django Channels Load Testing Results

ul in describing > exactly what commands were run on each system. > > Does that help bring some context? Or would you like for me to elaborate > further on some point? > > Thanks, > Robert > > > On Monday, September 12, 2016 at 2:38:59 PM UTC-4, Chris Foresman

Re: Django Channels Load Testing Results

Is this one worker each? I also don't really understand the implication of the results. There's no context to explain the numbers nor if one result is better than another. On Sunday, September 11, 2016 at 7:46:52 AM UTC-5, Robert Roskam wrote: > > Hello All, > > The following is an initial

Re: Channels is now an official Django project!

I'm looking forward to contributing however I can to the project! Exciting news! On Friday, September 9, 2016 at 9:58:24 AM UTC-5, Andrew Godwin wrote: > > Hi everyone, > > The Technical Board approved Channels as an official Django project as per > DEP 7, and so the repositories have been

Re: Why doesn't BinaryField use BINARY type?

On Thursday, September 8, 2016 at 11:36:03 AM UTC-5, Tim Graham wrote: > > Maybe the fields from django-mysql help? > > http://django-mysql.readthedocs.io/en/latest/model_fields/resizable_text_binary_fields.html > > On Thursday, September 8, 2016 at 10:56:15 AM UTC-4, Chris Foresman

Re: Official Projects DEP

Nice work! On Thursday, July 14, 2016 at 10:36:19 PM UTC-5, Andrew Godwin wrote: > > I am happy to report that the Official Projects DEP, number 0007, was > approved by the Technical Board and is now adopted as final! > > Andrwe > On 4 Jul 2016 11:39 am, "Andrew Godwin" >

Re: thinking about the admin's scope and its description in the docs

FWIW, we used to tell clients that Django offers a basic admin interface "for free". However, we NEVER had a client that was sufficiently familiar with what a database is or how data modeling works for this to ever suffice. The first thing we always do on new project is immediately disable the

Re: Query on BooleanField with values other than True and False, bug or intentional?

> > Whatever.object.filter(is_active=Value('false')) > > > > The ORM can't predict the type of a Value call - pretty much by > definition, > > since it's a raw value passed to the database. So you might be able to > fix > > BooleanField

Re: Query on BooleanField with values other than True and False, bug or intentional?

Sorry, sbrandt noted the issue of subtle bugs, not Maxime. On Friday, January 29, 2016 at 4:37:51 PM UTC-6, Chris Foresman wrote: > > I have to agree here; it's pretty sloppy to not enforce an explicit > boolean value and can lead to subtle bugs. In addition to the one mentioned &g

Re: Query on BooleanField with values other than True and False, bug or intentional?

I have to agree here; it's pretty sloppy to not enforce an explicit boolean value and can lead to subtle bugs. In addition to the one mentioned by Maxime, consider the case of a nullable boolean field: >>> bool(None) False Maybe that field has a better converter for possible values and

Re: Replacing the contrib.sites Site model with a setting?

+1 on setting. That's what I've ended up doing on all of my projects anyhowways. On Friday, January 29, 2016 at 2:45:02 PM UTC-6, Tim Graham wrote: > > In another thread about adding a "scheme" field to the Site model [1], I > floated the idea of moving the data stored by the Site model into a

Re: Vote on Jira as bugtracker

For whatever it's worth, our company switched from Pivotal Tracker to JIRA because we added a QA team and they wanted all this flexibility in devising bug ticket "workflows." All it did from my perspective is add 47 layers of complexity on top of a massively confusing UI and insists on NOT

Re: Case-insensitive email as username

We usually just handle this with a custom serializer (or form) field that converts all input to lowercase. That way we don't have to change any lookups or anything; all emails that come in to the system are already lowercase. Of course, that doesn't preserve what users enter but IME anything

Re: makemigrations --exit; exit status feels backwards from conventions

Jon, You proposal seems like a sane and welcome change that aligns the exit status of --exit with long-standing convention. Thanks, Chris On Wednesday, October 21, 2015 at 10:20:09 AM UTC-5, Jon Dufresne wrote: > > On Tue, Oct 20, 2015 at 9:29 PM, Gavin Wahl > wrote:

Re: 1.9 release planning

For an additional non-core dev data point, I'm also +1 on Loic's 1.10, 1.11, 2.0... plan. Makes it much easier to plan and communicate framework upgrades to clients. On Tuesday, June 23, 2015 at 9:14:25 PM UTC-5, Josh Smeaton wrote: > > I was worried about 1.10 because I wrongly assumed that

Re: 1.9 release planning

I'm really curious to know if the version to follow 1.9 is planned to be 2.0 or 1.10. I feel as though 1.x releases have had a lot of major feature changes. Maybe it's time to start thinking about features in terms of major, minor, and bugfix/security patch, and start saving major features for

Re: improving debug logging in development

This is what we're using to send to loggly. I'm not honestly 100% sure it works as intended but it gets the job done. It would be great if we could conditionally log to console when running in a local dev environment. LOGGING = { 'version': 1, 'disable_existing_loggers': True,

Re: User.username max_length 254

Yeah, this is the point I was trying to make. I absolutely get your point about the impact to user, though, Josh. It just seems worth doing since this is an LTS release. On Friday, February 27, 2015 at 5:41:12 PM UTC-6, Daniel Hawkins wrote: > > I'd bet an extremely large portion of those users

Re: django admin: open popups as modals instead of windows

On Thursday, February 26, 2015 at 10:25:02 AM UTC-6, Thomas Leo wrote: > > I've opened a ticket [1] to implement the popups in the admin as modal >> instead >> of windows. I'm no UI/UX expert but modals are more or less the standard >> today, >> windows looks like a relic from the 2000s. > >

Re: User.username max_length 254

Given that 1.8 is an LTS, and increasing the default username length addresses the 80% use-case for custom user models, isn't it worth adding this change now (even if it philosophically violates the alpha/beta split)? On Wednesday, February 25, 2015 at 12:24:20 PM UTC-6, Tim Graham wrote: > >

Re: Adding context to docs

Diana, I've been working on my own first patches to Django. I'm available all day tomorrow from about 8-5:30 CST if you want any help with the basic steps. You'll basically want to fork django/django, git clone that to your local machine, and set the original repo as your upstream remote to

Re: 1.8 bug fix sprinting this weekend

Tim, Our company is having our quarterly "hack days" next Thursday and Friday. Can we sync up to work on some patches then? On Thursday, February 12, 2015 at 8:07:46 PM UTC-6, Tim Graham wrote: > > If you would like to contribute to the timely release of 1.8 and if you > have some free time

Re: Pull request builder now on Ubuntu 14.04

Tim, Why don't they build on 14.04? We regularly run Django on EC2 VMs with 14.04 as the base AMI. On Monday, January 26, 2015 at 11:33:11 AM UTC-6, Tim Graham wrote: > > The pull request builders are now running on Ubuntu 14.04. The master > still runs 12.04 and handles builds for versions

Re: cursor.callproc()

, Shai Berger wrote: > > On Tuesday 21 October 2014 18:23:44 Chris Foresman wrote: > > Is there some benefit to using `.callproc()` over this? > > > > ``` python > > query = 'CALL sp_recommendation_engine(%s, %s)' > > profile = user.get_profile()

Re: cursor.callproc()

Is there some benefit to using `.callproc()` over this? ``` python query = 'CALL sp_recommendation_engine(%s, %s)' profile = user.get_profile() cursor = connection.cursor() cursor.execute(query, [user.id, profile.id]) ``` On Monday, October 20, 2014 1:29:49 PM UTC-5, Carl Meyer

Re: Proposal: Password Validity Layer

On Tuesday, August 19, 2014 4:53:39 PM UTC-5, Chris Foresman wrote: > > On Tuesday, August 19, 2014 4:49:10 PM UTC-5, Chris Foresman wrote: > >> >> >> On Monday, August 18, 2014 12:05:55 PM UTC-5, Florian Apolloner wrote: >>> >>> Validation errors

Re: Proposal: Password Validity Layer

On Tuesday, August 19, 2014 4:49:10 PM UTC-5, Chris Foresman wrote: > > > On Monday, August 18, 2014 12:05:55 PM UTC-5, Florian Apolloner wrote: >> >> Validation errors are only caught inside form validation. Forms set the >> password usually in save, not in clean,

Re: Proposal: Password Validity Layer

On Monday, August 18, 2014 12:05:55 PM UTC-5, Florian Apolloner wrote: > > Validation errors are only caught inside form validation. Forms set the > password usually in save, not in clean, so I don't think that patch covers > it (or at least the relevant forms have to call validate_password in

Re: Requiring GitHub login for actions on Trac

+1 on GitHub OAuth. I've avoided filling or commenting on bugs because setting up Yet Another Account was enough friction that I never did it. On Thursday, August 7, 2014 2:21:06 AM UTC-5, Erik Romijn wrote: > > > Using GitHub makes sense as it's very likely a new contributor already > has a

Re: Updating the organization of the Django Project

As a non-core community member, I welcome a streamlined way for new potential coders to contribute. On Thursday, July 24, 2014 7:02:16 AM UTC-5, Russell Keith-Magee wrote: > > Hi Aymeric. > > A big +1 from me. Thanks for all your work drafting these modifications. > > Russ %-) > > On Wed, Jul

Re: Django ORM support for NoSql databases

On Tuesday, December 17, 2013 8:12:43 PM UTC-6, Russell Keith-Magee wrote: > > > My claim is that complete abstraction of the data store shouldn't be the > goal. What we should be aiming for is sufficient API compatibility to allow > for two things: > > * ModelForms wrapping a model from a