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
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)"
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 t
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 necessa
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 >
> wrote:
>
> I'll chime in to say I've had a similar problem related to the
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 minute
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 a
scale down as well
> as up.
>
> Andrew
>
> On Mon, Sep 26, 2016 at 1:30 PM, Chris Foresman > 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
>> s
call a pathological case is a small website, running on
> something like cheap VPS.
>
>
>
> 2016-09-26 15:59 GMT+02:00 Chris Foresman >:
>
> > Robert,
> >
> > Thanks! This really does clear things up. The results were a little
> > surprising at
#x27;t want a complex setup,
> or use it with nginx 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.
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. After
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
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 repor
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 move
ary/ms188362.aspx
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
I had a need to store an encrypted bytestring, and CharField doesn't work.
But BinaryField uses LONGBLOB by default (at least on MySQL). Doesn't it
make more sense to have a BinaryField equivalent of CharField, and use
LONGBLOB for something analogous to TextField? As far as I can tell, the
MyS
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" >
> wrote:
>
>> I've revi
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
tion but with Value:
> >
> > 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
> fi
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 mentione
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 explicit
+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
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 suppo
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 up
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:
> > In your case, succ
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 t
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
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,
'form
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
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.
>
>
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:
>
>
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 get
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 o
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 o
5 PM UTC-5, 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
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 wr
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
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,
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
+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 Gi
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 23,
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 NoS
42 matches
Mail list logo