Re: Validation of m2m

[Chris Foresman]

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 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5896cf09-193a-4e3b-b315-d0963816099a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ConnectionResetError in test_closes_connection_without_content_length

[Chris Foresman]

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)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9752c6d9-9faf-4dcb-9359-a9ba0866062f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Review of DEP 201 - simplified routing syntax

[Chris Foresman]

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 the implementation, please get in touch if 
> you'd like to help!
>
> Thanks,
>
> -- 
> Aymeric.
>
>
>
> On 12 May 2017, at 14:19, Aymeric Augustin  > wrote:
>
> After getting approval from Tom on IRC, I updated the DEP according to my 
> email below: https://github.com/django/deps/pull/41
>
> The next steps are:
>
> - account for any remaining feedback (I feel I made only minor changes 
> compared to the last version, hopefully we can wrap this up quickly now)
> - get approval from the technical board
> - complete the implementation!
>
> -- 
> Aymeric.
>
>
>
> On 12 May 2017, at 12:32, Aymeric Augustin  > wrote:
>
> Hello,
>
> I reviewed the current version of DEP 201 
> 
>  as 
> well as related 
>  
> discussions 
> .
>  
> I took notes and wrote down arguments along the way. I'm sharing them 
> below. It may be useful to add some of these arguments to the DEP.
>
> Sjoerd, Tom, I didn't want to edit your DEP directly, but if you agree 
> with the items marked *[Update DEP]* below I can prepare a PR. I will now 
> take a look at the pull requests implementing this DEP.
>
>
> *Should it live as a third-party package first?*
>
> The original motivation for this DEP was to make Django easier to use by 
> people who aren't familiar with regexes.
>
> While regexes are a powerful tool, notably for shell scripting, I find it 
> counter-productive to make them a prerequisite for building a Django 
> website. You can build a very nice and useful website with models, forms, 
> templates, and the admin, without ever needing regexes — except, until now, 
> for the URLconf!
>
> Since we aren't going to say in the official tutorial "hey install this 
> third-party package to manage your URLs", that goal can only be met by 
> building the new system into Django.
>
> Besides, I suspect many professional Django developers copy-paste regexes 
> without a deep understanding of how they work. For example, I'd be 
> surprised if everyone knew why it's wrong to match a numerical id in a URL 
> with \d+ (answer at the bottom of this email).
>
> Not only is the new system easier for beginners, but I think it'll also be 
> adopted by experienced developers to reduce the risk of mistakes in 
> URLpatterns, which are an inevitable downside of their syntax. Django can 
> solve problems like avoiding \d+ for everyone.
>
> Anecdote: I keep making hard-to-detect errors in URL regexes. The only URL 
> regexes I wrote that can't be replicated with the new system are very 
> dubious and could easily be replaced with a more explicit `if 
> some_condition(request.path): raise Http404` in the corresponding view. I 
> will be happy to convert my projects to the new system.
>
> No progress was made in this area since 2008 because URL regexes are a 
> minor annoyance. After you write them, you never see them again. I think 
> that explains why no popular alternative emerged until now.
>
> Since there's a significant amount of prior art in other projects, a 
> strong consensus on DEP 201 being a good approach, and a fairly narrow 
> scope, it seems reasonable to design the new system directly into Django.
>
>
> *What alternatives would be possible?*
>
> I have some sympathy with the arguments for a pluggable URL resolver 
> system, similar to what I did for templates in Django 1.8. However I don't 
> see this happening any time soon because there's too little motivation to 
> justify the effort. As I explained above, developers tend to live with 
> whatever the framework provides.
>
> Of course, if someone wants to write a fully pluggable URL resolver, 
> that's great! But there's no momentum besides saying that "it should be 
> done that way". Furthermore, adding the new system shouldn't make it more 
> difficult to move to a fully pluggable system. If anything, it will clean 
> up the internals and prepare further work in the area. Some changes of this 
> kind were already committed.
>
> DEP 201 is mostly independent from the problem of allowing multiple views 
> to match the same URL  — 
> that is, to resume resolving URL patterns if a view applies some logic and 
> decides it can't handle a URL. This is perhaps the biggest complaint about 
> the current design of the URL resolver. Solutions include hacking around 
> the current design or changing it fundamentally.

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

[Chris Foresman]

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 necessary for doc links:

>>> import django
>>> doc_version = '.'.join(django.get_version().split('.')[:2])
>>> doc_version
'1.8'

 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/be9dde3e-e402-4a13-912c-0372e1906863%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[Chris Foresman]

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 related to the shell and I 
> couldn't sort out how to address it.
>
>
> In such situations, AFAIK, the following works:
>
> from django.db import connection
> connection.close()
>
> Then Django will reopen the connection for the next database query.
>
> HTH,
>
> -- 
> Aymeric.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e2cee051-7c7b-4224-99b1-908b21f968a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[Chris Foresman]

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 minutes of typing things in the shell. 
The workaround I eventually arrived at was copying all the data I pulled 
from previous runs into a doc in my text editor, and restart the shell 
every time the database connection dropped. Eventually I was able to just 
copy and paste enough stuff from that doc to get everything done in the 10 
minute limit. Is there a way (e.g. the DatabaseWrapper mentioned above) to 
get the shell to reconnect without stopping the shell and restarting from 
scratch every time?

On Tuesday, March 7, 2017 at 7:30:27 AM UTC-6, James Pic wrote:
>
> It seems like we have 2 kind of issues:
>
> - code broke runserver,
> - network broke runserver.
>
> In the first case, runserver waits for a code reload event which is 
> perfect ;)
> In the second case, runserver also waits for a code reload event, which is 
> not very intuitive after fixing a network error.
>
> So if we want to handle both case, we indeed need to detect if an error is 
> caused by code or networking, which is defined by CACHES, DATABASES and 
> CHANNEL_LAYERS.
>
> Perhaps we could add a special attribute to the exception, so 
> DatabaseWrapper.get_new_connection()'s call of:
>
> connection = Database.connect(**conn_params) 
>
> Would become something like:
>
> try:
> connection = Database.connect(**conn_params)
> except Exception as e:
> e.network_error = True
> raise
>
> Another way would be to inspect exc info or have a pre-defined list of 
> exceptions that are to be considered as network error, which involves 
> referencing to exceptions potentially defined by other packages such as 
> redis.
>
> While that may seem a lot for runserver, I've restrained myself from 
> talking about what this could look like in production so far in the 
> discussion, but I feel like even production deployment could somehow 
> benefit from this at some point, so that might be worth the effort after 
> all.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cc47bf21-9bbd-4728-9f2f-968405d128ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: can_introspect_default feature

[Chris Foresman]

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 and 
only the API server is written in Django.)


On Thursday, October 20, 2016 at 7:53:23 AM UTC-5, Tim Graham wrote:
>
> The 'default' model field option is used in Python rather than in the 
> database. SchemaEditor might set a column default to ease populating a 
> value on existing rows but that default shouldn't be left in the column's 
> definition. self.assertIsNone(field.default) means that the column 
> doesn't have a default.
>
> On Thursday, October 20, 2016 at 8:29:29 AM UTC-4, Maximiliano Robaina 
> wrote:
>>
>> Hi Tim,
>>
>> Thanks for response.
>>
>> El martes, 18 de octubre de 2016, 12:07:34 (UTC-3), Tim Graham escribió:
>>>
>>> Hi Maxi,
>>>
>>> Did you take a look at the relevant commit that introduced the flag?
>>>
>>> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc
>>>
>>
>> Yes, I was looking into this changeset, but I can't understand yet what 
>> "And that the default is no longer set in the database." means in 
>> test_add_field_default_dropped [1].
>> field.default contains the column default definition not the default 
>> value of the some table record, Is it that correct?, So, why this must be 
>> None?
>>
>>
>>
>> [1] 
>> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc#diff-888b45a0a8f38ee67e8d22403cf994dbR1371
>>
>>
>> Regards 
>>
>>
>>
>>>
>>> On Tuesday, October 18, 2016 at 9:51:46 AM UTC-4, Maximiliano Robaina 
>>> wrote:

 Hi,

 How supposed to can_introspect_default must work?

 I'm working on django firebird backend and I'm trying to figured out 
 how this feature works, but the schema tests fails. 
 This default is at database level or django level?

 If I define a field with a default value, and do a metadata 
 introspection over this field to know if default value is defined, it 
 always returns True.

 I hope be clear (sorry for my bad english)

 ---
 Maxi

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/05dd4112-84fd-4a1c-8d5c-0fbeac202649%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[Chris Foresman]

Ok, but now we're talking about something that as far as I can tell, you 
can't even do with gunicorn. I agree WebSockets is a great reason to 
consider ASGI mode, but this still feels like an apples to oranges 
comparison. Or is the goal to somehow get Daphne + Django channels to work 
as fast as gunicorn + WSGI mode? Is that a reasonable way to think of it?


On Monday, September 26, 2016 at 3:45:15 PM UTC-5, Andrew Godwin wrote:
>
> You might want to run a small site with WebSockets - there are a number of 
> reasons to use ASGI mode, and it's important we make it scale down 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 
>> specific reason to do so. Otherwise, why not run it in WSGI mode?
>>
>>
>> On Monday, September 26, 2016 at 2:25:04 PM UTC-5, ludovic coues wrote:
>>>
>>> What you 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 
>>> > surprising at first blush since I believe part of the idea behind 
>>> channels 
>>> > is to be able to serve more requests concurrently than a 
>>> single-threaded 
>>> > approach typically allows. This is why I don't think this benchmark 
>>> alone is 
>>> > very useful. We already knew it would be slower to serve requests with 
>>> a 
>>> > single worker given the overhead as you described. So what does this 
>>> > benchmark get us? Is it merely to characterize the performance 
>>> difference in 
>>> > the pathological case? I think ramping up the number of workers on a 
>>> single 
>>> > machine would be an interesting next step, no? 
>>> > 
>>> > Anyway, thanks for taking the time to do this work and help us 
>>> understand 
>>> > the results. 
>>> > 
>>> > 
>>> > 
>>> > On Sunday, September 25, 2016 at 8:23:45 PM UTC-5, Robert Roskam 
>>> wrote: 
>>> >> 
>>> >> Hey Chris, 
>>> >> 
>>> >> Sure thing! I'm going to add a little color to this; probably a 
>>> little 
>>> >> more than required. 
>>> >> 
>>> >> I have gunciorn for comparison on both graphs because channels 
>>> supports 
>>> >> HTTP requests, so we wanted to see how it would do against a serious 
>>> >> production environment option. I could have equally done uwsgi. I 
>>> chose 
>>> >> gunicorn out of convenience. It serves as a control for the redis 
>>> channels 
>>> >> setup. 
>>> >> 
>>> >> The main point of comparison is to say: yeah, Daphne has an order of 
>>> >> magnitude higher latency than gunicorn, and as a consequence, it's 
>>> >> throughput in the same period of time as gunicorn is less. This 
>>> really 
>>> >> shouldn't be surprising. Channels is processing an HTTP request, 
>>> stuffing it 
>>> >> in a redis queue, having a worker pull it out, process it, and then 
>>> send a 
>>> >> response back through the queue. This has some innate overhead in it. 
>>> >> 
>>> >> You'll note I didn't include IPC for latency comparison. It's because 
>>> it's 
>>> >> so bad that it would make the graph unreadable. You can get the sense 
>>> of 
>>> >> that when you see it's throughput. So don't use it for serious 
>>> production 
>>> >> machines. Use it for a dev environment when you don'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. Honestly, just explain what these results mean in words, 
>>> because I 
>>> >>> cannot turn these graph

Re: Django Channels Load Testing Results

[Chris Foresman]

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 specific 
reason to do so. Otherwise, why not run it in WSGI mode?


On Monday, September 26, 2016 at 2:25:04 PM UTC-5, ludovic coues wrote:
>
> What you 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 
> > surprising at first blush since I believe part of the idea behind 
> channels 
> > is to be able to serve more requests concurrently than a single-threaded 
> > approach typically allows. This is why I don't think this benchmark 
> alone is 
> > very useful. We already knew it would be slower to serve requests with a 
> > single worker given the overhead as you described. So what does this 
> > benchmark get us? Is it merely to characterize the performance 
> difference in 
> > the pathological case? I think ramping up the number of workers on a 
> single 
> > machine would be an interesting next step, no? 
> > 
> > Anyway, thanks for taking the time to do this work and help us 
> understand 
> > the results. 
> > 
> > 
> > 
> > On Sunday, September 25, 2016 at 8:23:45 PM UTC-5, Robert Roskam wrote: 
> >> 
> >> Hey Chris, 
> >> 
> >> Sure thing! I'm going to add a little color to this; probably a little 
> >> more than required. 
> >> 
> >> I have gunciorn for comparison on both graphs because channels supports 
> >> HTTP requests, so we wanted to see how it would do against a serious 
> >> production environment option. I could have equally done uwsgi. I chose 
> >> gunicorn out of convenience. It serves as a control for the redis 
> channels 
> >> setup. 
> >> 
> >> The main point of comparison is to say: yeah, Daphne has an order of 
> >> magnitude higher latency than gunicorn, and as a consequence, it's 
> >> throughput in the same period of time as gunicorn is less. This really 
> >> shouldn't be surprising. Channels is processing an HTTP request, 
> stuffing it 
> >> in a redis queue, having a worker pull it out, process it, and then 
> send a 
> >> response back through the queue. This has some innate overhead in it. 
> >> 
> >> You'll note I didn't include IPC for latency comparison. It's because 
> it's 
> >> so bad that it would make the graph unreadable. You can get the sense 
> of 
> >> that when you see it's throughput. So don't use it for serious 
> production 
> >> machines. Use it for a dev environment when you don'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. Honestly, just explain what these results mean in words, because 
> I 
> >>> cannot turn these graphs into anything meaningful on my own. 
> >>> 
> >>> 
> >>> 
> >>> On Monday, September 12, 2016 at 8:41:05 PM UTC-5, Robert Roskam 
> wrote: 
> >>>> 
> >>>> Hey Chris, 
> >>>> 
> >>>> The goal of these tests is to see how channels performs with normal 
> HTTP 
> >>>> traffic under heavy load with a control. In order to compare 
> accurately, I 
> >>>> tried to eliminate variances as much as possible. 
> >>>> 
> >>>> So yes, there was one worker for both Redis and IPC setups. I 
> provided 
> >>>> the supervisor configs, as I figured those would be helpful 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 
> wrote: 
> >>>>> 
> >>>>> 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 o

Re: Django Channels Load Testing Results

[Chris Foresman]

Robert,

Thanks! This really does clear things up. The results were a little 
surprising at first blush since I believe part of the idea behind channels 
is to be able to serve more requests concurrently than a single-threaded 
approach typically allows. This is why I don't think this benchmark alone 
is very useful. We already knew it would be slower to serve requests with a 
single worker given the overhead as you described. So what does this 
benchmark get us? Is it merely to characterize the performance difference 
in the pathological case? I think ramping up the number of workers on a 
single machine would be an interesting next step, no?

Anyway, thanks for taking the time to do this work and help us understand 
the results.



On Sunday, September 25, 2016 at 8:23:45 PM UTC-5, Robert Roskam wrote:
>
> Hey Chris,
>
> Sure thing! I'm going to add a little color to this; probably a little 
> more than required.
>
> I have gunciorn for comparison on both graphs because channels supports 
> HTTP requests, so we wanted to see how it would do against a serious 
> production environment option. I could have equally done uwsgi. I chose 
> gunicorn out of convenience. It serves as a control for the redis channels 
> setup.
>
> The main point of comparison is to say: yeah, Daphne has an order of 
> magnitude higher latency than gunicorn, and as a consequence, it's 
> throughput in the same period of time as gunicorn is less. This really 
> shouldn't be surprising. Channels is processing an HTTP request, stuffing 
> it in a redis queue, having a worker pull it out, process it, and then send 
> a response back through the queue. This has some innate overhead in it. 
>
> You'll note I didn't include IPC for latency comparison. It's because it's 
> so bad that it would make the graph unreadable. You can get the sense of 
> that when you see it's throughput. So don't use it for serious production 
> machines. Use it for a dev environment when you don'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. Honestly, just explain what these results mean in words, because I 
>> cannot turn these graphs into anything meaningful on my own.
>>
>>
>>
>> On Monday, September 12, 2016 at 8:41:05 PM UTC-5, Robert Roskam wrote:
>>>
>>> Hey Chris,
>>>
>>> The goal of these tests is to see how channels performs with normal HTTP 
>>> traffic under heavy load with a control. In order to compare accurately, I 
>>> tried to eliminate variances as much as possible. 
>>>
>>> So yes, there was one worker for both Redis and IPC setups. I provided 
>>> the supervisor configs, as I figured those would be helpful 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 wrote:
>>>>
>>>> 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 report of Django Channels performance. 
>>>>> While this is being shared in other media channels at this time, I fully 
>>>>> expect to get some questions or clarifications from this group in 
>>>>> particular, and I'll be happy to add to that README anything to help 
>>>>> describe the results.
>>>>>
>>>>>
>>>>> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>>>>>
>>>>>
>>>>> Robert Roskam
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f58727ac-fc47-439b-8943-eddf4021a96f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Chris Foresman]

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 5 
years it still trips me up when I do a comparison with a number grabbed 
from a URL and, say, Object.otherobject_id.


On Thursday, September 15, 2016 at 3:52:46 AM UTC-5, Sjoerd Job Postmus 
wrote:
>
>
>
> To me, that settles it: no typecasting.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0032720b-b1a7-4050-88f3-4fef45027d46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[Chris Foresman]

Yes. Honestly, just explain what these results mean in words, because I 
cannot turn these graphs into anything meaningful on my own.



On Monday, September 12, 2016 at 8:41:05 PM UTC-5, Robert Roskam wrote:
>
> Hey Chris,
>
> The goal of these tests is to see how channels performs with normal HTTP 
> traffic under heavy load with a control. In order to compare accurately, I 
> tried to eliminate variances as much as possible. 
>
> So yes, there was one worker for both Redis and IPC setups. I provided the 
> supervisor configs, as I figured those would be helpful 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 wrote:
>>
>> 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 report of Django Channels performance. While 
>>> this is being shared in other media channels at this time, I fully expect 
>>> to get some questions or clarifications from this group in particular, and 
>>> I'll be happy to add to that README anything to help describe the results.
>>>
>>>
>>> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>>>
>>>
>>> Robert Roskam
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4c9c95f-07b0-4a8d-bb1b-468893ac9e31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels Load Testing Results

[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 report of Django Channels performance. While 
> this is being shared in other media channels at this time, I fully expect 
> to get some questions or clarifications from this group in particular, and 
> I'll be happy to add to that README anything to help describe the results.
>
>
> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>
>
> Robert Roskam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9578e218-8c95-4357-a67c-7763a3ff9b54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels is now an official Django project!

[Chris Foresman]

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 moved under the django/ project on 
> GitHub, as well as a few other things the DEP requires, and improving the 
> contribution guidelines and triaging tickets.
>
> You can read more in the announcement: 
> https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/
>
> If you have any questions about what this means, I'm happy to answer them 
> here! I'm aiming for a 1.0 release reasonably soon, after one or two minor 
> breaking changes that need to be done (there'll be deprecation warning code 
> in there so things don't mysteriously break on upgrade).
>
> Andrew
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/86c1a35f-2491-46db-bd48-023bbde47c96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't BinaryField use BINARY type?

[Chris Foresman]

That's actually pretty helpful, and sort of gets me closer the what I was 
proposing. I'm just perplexed why there's no support for the VARBINARY type 
similar to the VARCHAR used for CharField. Admittedly I've never had call 
to use this type before, but I just found it surprising that there wasn't a 
clear analog to CharField for bytestrings.


MySQL VARBINARY: 
http://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html
Postgres 
BYTEA: https://www.postgresql.org/docs/current/static/datatype-binary.html
MSSQL VARBINARY: https://msdn.microsoft.com/en-us//library/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 UTC-4, Chris Foresman wrote:
>>
>> 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 
>> MySQL documentation definitely considers LONGBLOB/BLOB analogous to TEXT. 
>> Not sure the best way to approach an improvement, though; add a 
>> BytestringField? Would this be best served as a third-party package, or 
>> should it be part of Django proper?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/81a7e504-28f8-4d12-91ae-81cbd3e207da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Official Projects DEP

[Chris Foresman]

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 revised the documentation section for clarity about external 
>> hosting, and given the lack of further discussion or dissention, I'm now 
>> taking the DEP to the technical board for a decision.
>>
>> Andrew
>>
>> On Sun, Jun 12, 2016 at 4:35 AM, Andrew Godwin > > wrote:
>>
>>>
>>> On 12 Jun 2016 2:00 a.m., "Tim Graham"  
>>> wrote:
>>>
>>> >
>>> > 1. It might be nice if projects had more than one shepherd so there's 
>>> not a single point of failure. Of course, if all members of the maintenance 
>>> team end up joining the team, then there's no issue.
>>>
>>> It depends how the role of work is split between them; I think it 
>>> depends on the project too. I'd rather not over legislate here and let us 
>>> have some leeway based on context. I agree we should aim for this if the 
>>> shepherd role is very busy for that project, but with a maintenance team we 
>>> hopefully have a ready source of knowledgeable potential new core team 
>>> members.
>>>
>>> >
>>> >
>>> > 2. Re: "The main project documentation does not have to be hosted 
>>> inside the main Django documentation, but should be under an official 
>>> Django domain if possible, and link back to with the main Django 
>>> documentation where it makes sense."
>>> >
>>> >
>>> > I'd rather not get into hosting more documentation on 
>>> djangoproject.org if possible, as there's a non-trivial maintenance 
>>> burden there. I imagine it would be easier for the project's maintenance 
>>> team to make adjustments in the readthedocs UI instead of bothering the 
>>> Django ops team in the event of any problems.
>>>
>>> This is why I said domain, not infrastructure; I'd like us to host on 
>>> RTD with a custom django project subdomain so we retain control of the URLs 
>>> in the long term but we can pay them to host and deal with it all in the 
>>> short term.
>>>
>>> >
>>> >
>>> > 3. Did you envision any involvement from the Django Fellow in these 
>>> projects? To date, I haven't really had much involvement with any of the 
>>> ancillary projects like localflavor and formtools.
>>>
>>> I didn't, mostly as I didn't want to add more responsibilities to the 
>>> existing set; do you think we should? I think asking the project to come 
>>> with a plan for that stuff is helpful, and if it would need Fellow 
>>> involvement, the proposal should include them as part of the maintenance 
>>> team maybe?
>>>
>>> Andrew
>>>
>>> >
>>> >
>>> > On Friday, June 10, 2016 at 3:01:23 AM UTC-4, Andrew Godwin wrote:
>>> >>
>>> >> Just to update on this, there was some good feedback on the draft for 
>>> writing and clarity, and it's now made it into an official draft, located 
>>> here: 
>>> https://github.com/django/deps/blob/master/draft/0007-official-projects.rst
>>> >>
>>> >> If you'd like to read through the draft and raise discussion points 
>>> or opinions on the plan, now is the time!
>>> >>
>>> >> Andrew
>>> >>
>>> >> On Wed, Jun 8, 2016 at 1:34 PM, Andrew Godwin  
>>> wrote:
>>> >>>
>>> >>> Hi everyone,
>>> >>>
>>> >>> I've started on an "official projects" process DEP as I discussed 
>>> here a while back, to formalise the process of adopting non-core packages 
>>> as repositories under the official Django organisation, with a view to 
>>> taking Channels on this route (and hopefully including the existing 
>>> localflavor under this too).
>>> >>>
>>> >>> Pull request is up here: https://github.com/django/deps/pull/23 - 
>>> comments welcome.
>>> >>>
>>> >>> Andrew
>>> >>
>>> >>
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com .
>>> > To post to this group, send email to django-d...@googlegroups.com 
>>> .
>>> > Visit this group at https://groups.google.com/group/django-developers.
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/2d85ebf4-2699-4faf-bb3a-d9c213b76fe2%40googlegroups.com
>>> .
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on 

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

[Chris Foresman]

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 admin and simply design APIs that allow our front-end teams to build 
some kind of custom dashboard/admin interface.

IME, the admin is "sufficient" for sysadmins or technically experienced 
users, but in practice those are few and far between.



On Thursday, February 11, 2016 at 12:08:08 PM UTC-6, bliy...@rentlytics.com 
wrote:
>
> While I think it's true that a process centric workflow (wizards, or hubs 
> anyone?) would be incredibly useful, that does not take away from the fact 
> that the model centric admins are also incredibly useful, and time saving.  
> It's so easy to add search, sorting, bulk actions, etc to an admin--these 
> are things I've often spent days or weeks working on in other systems.  
> With django it is often a matter of minutes to add these incredibly common 
> features.  This is probably one of my favorite things about the django 
> framework.
>
> On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney wrote:
>>
>>
>>
>> On 11/02/16 00:55, Andy Baker wrote: 
>> > I can't help but feel that the "admin is very rudimentary and hard to 
>> > customize" is perpetually overplayed by many in the community. Maybe 
>> I'm 
>> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. 
>>
>> I must admit I'm a large proponent of warning against getting caught up 
>> in "Admin as my management console". 
>>
>> As customisable as it can be, I find the problem to be it is a 
>> data-centric view of your system, closely tied to the database models. 
>>
>> IMHO a management interface for site should be a _process_ centric view, 
>> abstracting away the implementation details of tables and fields. 
>>
>> Perhaps a better way to think of it as the difference between a 
>> "management" and a "maintenance" interface. 
>>
>> True, in a lot of cases these can be the same thing, and for simpler 
>> sites Admin works "just fine".  However, I've been on too many projects 
>> that wind up spending a lot of time and effort customising Admin to do 
>> things that would have been simpler in a custom view. 
>>
>> Worse still, I've seen projects alter their schema design to accommodate 
>> Admin's limitations [like lack of nested inlines] 
>>
>> Is it possible to add other views to admin?  Sure... though it's not 
>> clear, or well documented. 
>>
>> Can documentation alone overcome this problem?  I'm not convinced it can. 
>>
>> For some years now I've been proposing an investigation into slicing 
>> Admin into two layers: a base "management interface framework" layer, 
>> and "admin" built atop this framework. 
>>
>> Then we can keep providing the Admin we all know and love, and also make 
>> it easier for people to build their own management interfaces. 
>>
>> However, I don't currently have the time [or admin familiarity] to 
>> undertake this work. 
>>
>> -- 
>> Curtis 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7fe074dc-dfbe-484c-8a2c-75f1fa098545%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Foresman]

I don't think that's the same thing. We're talking about interfacing with a 
system that has clearly delineated values.

> The boolean type can have several states: "true", "false", and a third 
> state, "unknown", which is represented by the SQL null value.[1]


While the database accepts a variety of optional string literals to insert 
true or false, none of them are truly comparable to Python's truth-y or 
false-y values. For instance, psycopg2 only uses True, False, and None to 
represent TRUE, FALSE, and NULL in the database.[2] That's why values 
passed to filter on a BooleanField are cast to bool.

While allowing some slop might be considered more "Pythonic" is some cases, 
I feel "explicit is better then implicit" in this case given that SQL 
doesn't allow boolean columns to be set in an implicit "Pythonic" 
truth-y/false-y way.


[1](http://www.postgresql.org/docs/9.1/static/datatype-boolean.html)
[2](http://initd.org/psycopg/docs/usage.html#constants-adaptation)


On Tuesday, February 2, 2016 at 4:23:37 AM UTC-6, HM wrote:
>
> I don't think enforcing it would be pythonic. 
>
> Once upon a time, Python lacked True and False, all you had were 
> truthy and falsey and maybe per-project/team constants: 
>
> http://python-history.blogspot.no/2013/11/story-of-none-true-false.html 
>
> I remember the arguments when bool() was added. Those against were 
> worried that it would send a signal that would lead to a slippery 
> slope where truthy and falsey would disappear because people would 
> insist that "it's pretty sloppy to not enforce an explicit boolean 
> value and can lead to subtle bugs". 
>
> Well.. 
>
>
> On 31 January 2016 at 10:34, Adam Johnson <djch...@gmail.com > 
> wrote: 
> > Just to play devil's advocate... you're all worrying about one simple 
> case; 
> > there are infinite variants of it with subtle bugs, for example imagine 
> the 
> > same situation 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 
> fix 
> > BooleanField for a few cases, but you can't fix them all.. 
> > 
> > 
> > 
> > On Friday, January 29, 2016 at 10:38:52 PM UTC, Chris Foresman wrote: 
> >> 
> >> 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 
> >>> by Maxime, consider the case of a nullable boolean field: 
> >>> 
> >>> >>> bool(None) 
> >>> False 
> >>> 
> >>> Maybe that field has a better converter for possible values and 
> >>> explicitly allows `None`, but I think it would be fairly trivial to 
> add a 
> >>> stricter check and pretty easy to fix code that's not backwards 
> compatible 
> >>> with find/replace. 
> >>> 
> >>> 
> >>> On Friday, January 22, 2016 at 3:18:45 PM UTC-6, Maxime Lorant wrote: 
> >>>> 
> >>>> At least, the behaviour is predictable : it uses `bool(value)`. I 
> >>>> believe it is not a bug but more a question about the input 
> definition: 
> >>>> should we allow non boolean value? I don't see any problem here 
> accepting a 
> >>>> string as a `True` value, it is the job of the user to ensure the 
> value is 
> >>>> castable to a boolean. 
> >>>> 
> >>>> The same behaviour is found on `IntegerField` for example: 
> >>>> `Model.objects.filter(pk="foo")` raises `ValueError: invalid literal 
> for 
> >>>> int() with base 10: 'foo'` which implies the ORM tried to cast 'foo' 
> as an 
> >>>> integer. 
> >>>> 
> >>>> On Friday, January 22, 2016 at 8:51:41 PM UTC+1, Kaveh wrote: 
> >>>>> 
> >>>>> Today I discovered I can use strings and numbers to query on 
> >>>>> BooleanFields. 
> >>>>> 
> >>>>> Let's say we have the following model: 
> >>>>> 
> >>>>> class Whatever(models.Model): 
> >>>>> name = models.CharField(max_length=200) 
> >>>>> is_active = models.BooleanField() 
> &g

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

[Chris Foresman]

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 
> by Maxime, consider the case of a nullable boolean field:
>
> >>> bool(None)
> False
>
> Maybe that field has a better converter for possible values and explicitly 
> allows `None`, but I think it would be fairly trivial to add a stricter 
> check and pretty easy to fix code that's not backwards compatible with 
> find/replace.
>
>
> On Friday, January 22, 2016 at 3:18:45 PM UTC-6, Maxime Lorant wrote:
>>
>> At least, the behaviour is predictable : it uses `bool(value)`. I believe 
>> it is not a bug but more a question about the input definition: should we 
>> allow non boolean value? I don't see any problem here accepting a string as 
>> a `True` value, it is the job of the user to ensure the value is castable 
>> to a boolean.
>>
>> The same behaviour is found on `IntegerField` for example: 
>> `Model.objects.filter(pk="foo")` raises `ValueError: invalid literal for 
>> int() with base 10: 'foo'` which implies the ORM tried to cast 'foo' as an 
>> integer.
>>
>> On Friday, January 22, 2016 at 8:51:41 PM UTC+1, Kaveh wrote:
>>>
>>> Today I discovered I can use strings and numbers to query on 
>>> BooleanFields.
>>>
>>> Let's say we have the following model:
>>>
>>> class Whatever(models.Model):
>>> name = models.CharField(max_length=200)
>>> is_active = models.BooleanField()
>>>
>>> The following queries return all instances which their `is_active` field 
>>> is True:
>>>
>>> Whatever.object.filter(is_active=True)
>>> Whatever.object.filter(is_active='some_random_text')
>>> Whatever.object.filter(is_active=777)
>>>
>>> and the followings return the ones which are False:
>>>
>>> Whatever.object.filter(is_active=False)
>>> Whatever.object.filter(is_active='')
>>> Whatever.object.filter(is_active=0)
>>>
>>> Is this behaviour intentional or is it a bug? Should queries on 
>>> BooleanFields accept strings and numbers?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/93361723-c7ed-466c-968b-4c1e7f6d34ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Foresman]

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 explicitly 
allows `None`, but I think it would be fairly trivial to add a stricter 
check and pretty easy to fix code that's not backwards compatible with 
find/replace.


On Friday, January 22, 2016 at 3:18:45 PM UTC-6, Maxime Lorant wrote:
>
> At least, the behaviour is predictable : it uses `bool(value)`. I believe 
> it is not a bug but more a question about the input definition: should we 
> allow non boolean value? I don't see any problem here accepting a string as 
> a `True` value, it is the job of the user to ensure the value is castable 
> to a boolean.
>
> The same behaviour is found on `IntegerField` for example: 
> `Model.objects.filter(pk="foo")` raises `ValueError: invalid literal for 
> int() with base 10: 'foo'` which implies the ORM tried to cast 'foo' as an 
> integer.
>
> On Friday, January 22, 2016 at 8:51:41 PM UTC+1, Kaveh wrote:
>>
>> Today I discovered I can use strings and numbers to query on 
>> BooleanFields.
>>
>> Let's say we have the following model:
>>
>> class Whatever(models.Model):
>> name = models.CharField(max_length=200)
>> is_active = models.BooleanField()
>>
>> The following queries return all instances which their `is_active` field 
>> is True:
>>
>> Whatever.object.filter(is_active=True)
>> Whatever.object.filter(is_active='some_random_text')
>> Whatever.object.filter(is_active=777)
>>
>> and the followings return the ones which are False:
>>
>> Whatever.object.filter(is_active=False)
>> Whatever.object.filter(is_active='')
>> Whatever.object.filter(is_active=0)
>>
>> Is this behaviour intentional or is it a bug? Should queries on 
>> BooleanFields accept strings and numbers?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1a2e5302-806b-4dfd-8f38-34c1b15c964d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Foresman]

+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 setting:
>
> I've sometimes thought that the Site model violates the principle that you 
> shouldn't put configuration in your database. I guess there's some 
> usefulness to having a ForeignKey to the site, but... would it be feasible 
> to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> Carl said:+1 to this, I've long felt that the Site model was an 
> anti-pattern. I don't know if it's worth deprecating and switching to a 
> different system, though; it'd be a relatively painful deprecation for 
> those using  it, I would guess.
>
> James said:  "In using Marten Kenbeek's URL dispatch rewrite branch, I've 
> found that using the pattern of defining some site configuration in your 
> settings is the way to go: it more easily allows you to have URL patterns 
> on multiple domain/scheme combinations. I use a dict similar to what Tim 
> has shown, and then use it to initialize my scheme/domain URL constraints 
> in my root urls.py."
>
> I'd like to get more feedback and ideas about this. Do you think we'll be 
> better off in the long run with a setting as opposed to storing the data in 
> the database? Maybe writing a new sites app that uses a setting instead of 
> trying to modify the existing models-based one would be a better plan.
>
> I think the hard problem to solve is what to do about the Redirect and 
> FlatPage models which have ForeignKey and ManyToManyField relations to the 
> Site model.
>
> Perhaps some outcome of this discussion plus considering what features of 
> related third-party tools like django-hosts [2] might be useful to 
> incorporate in Django itself would be worthy of a project like Google 
> Summer of Code.
>
> [1] 
> https://groups.google.com/d/topic/django-developers/CzxaPDe8fpI/discussion
> [2] https://github.com/jazzband/django-hosts
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ef25366e-e1b4-4f35-ad6c-c5974fd359e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Chris Foresman]

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 supporting 
markdown while using its own 
sorta-similar-but-different-enough-to-be-constantly-annoying "wiki markup", 
but it can only be supported in certain fields, only I forget which ones it 
works in and which ones it doesn't until I've carefully entered all these 
useful code snippets and links and screenshots and save the ticket and see 
it's just full of gobbledygook.

TL;DR: HATE IT

On Wednesday, January 6, 2016 at 8:34:25 AM UTC-6, Aymeric Augustin wrote:
>
> FWIW Jira seems to be an exception among bug trackers: some people really 
> love it, others really hate it. It depends on who set it up and maintained 
> it in the company where they used it.
>
> Since we don’t have a resident Jira expert, we run the risk that most of 
> the Django community will fall into the “hate it” bucket. To me this is one 
> of the riskier choices we could make.
>
> Anyway it’s unclear to me that the potential benefits of switching to any 
> bug tracker could offset the transition costs, as long as Trac is 
> serviceable.
>
> We’ll see what happens in 2020 if it doesn’t support Python 3 by then (
> http://trac.edgewall.org/ticket/10083, 
> http://trac.edgewall.org/ticket/12130).
>
> -- 
> Aymeric.
>
> On 6 janv. 2016, at 15:19, Michael Manfre  
> wrote:
>
> Agreed with the above for the same reasons.
>
> On Wed, Jan 6, 2016 at 9:17 AM, Shai Berger  > wrote:
>
>> What Marc and James said, and in particular what Daniele said : I get to 
>> use Jira on a daily basis and find it cumbersome and confusing. 
>>
>> Shai see
>>
>>
>> On 6 בינואר 2016 15:43:02 GMT+02:00, Marc Tamlyn > > wrote:
>>>
>>> Yeah, this is a non-starter for me. All bug trackers are bad, we should 
>>> stick with the bad one we are used to.
>>>
>>> Marc
>>>
>>> On 6 January 2016 at 13:26, Victor Sosa >> > wrote:
>>>
 To answer you question:
 There is a plug-in to migrate all the data to Jira and similar to 
 integrate with any it with any in you infrastructure. (I just don't know 
 it 
 all you infrastructure)


 https://confluence.atlassian.com/jira/importing-data-from-trac-238617182.html

 On Wednesday, January 6, 2016 at 9:15:41 AM UTC-4, Daniele Procida 
 wrote:
>
> On Wed, Jan 6, 2016, Victor Sosa  wrote: 
>
> >I felt like lost using trac; it is kind of messy. I just don't feel 
> >comfortable 
> >with it. 
> >I see so many open source project using Jira that is just natural. 
> Search 
> >is easy, categorize is easy, look through the all issues and task is 
> quick. 
> > 
> >I would like to propose a vote on Jira as the bugtracker for this 
> project. 
> >Just vote + or - to see how many people agree on this. 
>
> Hi Victor. It's a reasonable proposition, but it's not simply a case 
> of choosing what would be nicer: we also have to make it work in our 
> infrastructure - and that's a huge effort. 
>
> How, for example, would we migrate the many thousands of tickets from 
> Trac to JIRA? 
>
> How would JIRA be integrated into our current deployment 
> infrastructure? 
>
> By all means it's useful to get votes on something like this, even 
> before we consider those questions, because if enough people want 
> something 
> it's always possible - but be aware that simply getting lots of votes for 
> it would only ever be the first and easiest step. 
>
> Having said that: I prefer Trac to JIRA. It's simpler, and faster. 
>
> Daniele 
>
>
 -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to django-develop...@googlegroups.com .
 To post to this group, send email to django-d...@googlegroups.com 
 .
 Visit this group at https://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/3b4a63f0-e3a4-4d9b-837c-ed98d212488d%40googlegroups.com
  
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to 

Re: Case-insensitive email as username

[Chris Foresman]

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 uppercase is just a fault of using the wrong text box on iOS or 
Android.



On Tuesday, November 24, 2015 at 5:33:54 AM UTC-6, Aymeric Augustin wrote:
>
> 2015-11-23 23:52 GMT+01:00 Carl Meyer :
>
> I've implemented the CITEXT-based solution a couple times; I think for a
>> PostgreSQL-based project it's the preferable option overall.
>>
>
> Perhaps we should add native support in contrib.postgres?
>
> I'm forseeing a small difficulty in terms of API. This is a behavior I'd 
> like
> to "mix in" to some fields but I can't say if that will be easy to 
> implement.
>
> The general ideas would be:
>
> # A mixin
>
> class CITextField(TextField):
> # ...
>
> # Case-insensitive versions of some built-in Django default fields
> # (if we consider that makes sense)
>
> class CIEmailField(CITextField, EmailField):
> pass
>
> # The possibility for users to make custom fields case insensitive
>
> class CITagField(CITextField, TagField):
> pass
>
> -- 
> Aymeric.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/72d064df-7599-4111-994a-d338dc81e7a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Foresman]

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, successfully creating a migration indicates a failure. 
>
> Only if the --check flag is on. The --check flag indicates that one is 
> explicitly checking that all model changes have migrations. A non-zero 
> exist status indicates that migrations were missing. If you feel the 
> help text could be improved to communicate this, I can work towards 
> that. 
>
> > Why do you object to using a ! to communicate this? 
>
> With the --check flag or the --exit flag? 
>
> I think I covered this in the OP. But just to clarify: 
>
> My use case: 
>
> Continuous integration server check's developers' commits for 
> correctness. One aspect of correctness is that all model changes have 
> migrations. 
>
> In shell scripting and CI servers an exit status of 0 indicates 
> true/pass and an exit status of non-zero indicates false/failure. 
>
> Therefore, the command should return 0 when everything is OK and 
> correct and non-zero otherwise. Commits are correct when all model 
> changes are accounted for. 
>
> The current --exit behavior, returns non-zero when everything is 
> correct. To account for this in CI, one must negate the exit status 
> with !, this goes against conventional behavior. 
>
> Further, if something goes terribly wrong and there is an unhandled 
> exception, negating the exit status will make the CI stage appear to 
> pass. This is backwards! CI can't tell the difference between "all 
> changes accounted for" and "Python had an unhandled exception". 
>
>
> Cheers, 
> Jon 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4a641f83-2334-4f64-b9d5-438c094dbe27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Chris Foresman]

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 the entire version 
> string was ordered. SemVer (and https://www.python.org/dev/peps/pep-0386/) 
> specifically call out that each component of a version identifier MUST be 
> ordered numerically. My objections based on that incorrect assumption I 
> withdraw.
>
> I'm +1 on going to 1.10, 1.11, then to 2.0. I think it makes sense, and 
> nicely aligns with the emerging new policy. I don't think we should be held 
> to naming the version after 1.9 as 2.0, considering we're changing the 
> policy of backwards compatibility, the semantics of the version numbers, 
> and the timelines of LTS. Do it all at once, and I think that sends a much 
> stronger message.
>
> Cheers
>
> On Wednesday, 24 June 2015 02:31:11 UTC+10, Carl Meyer wrote:
>>
>> I am +1 on the 1.10 - 1.11 - 2.0 plan; I think the discrepancy between 
>> 2.x and the future version numbering scheme will in practice be _much_ 
>> more confusing (and already has been). 
>>
>> I have never found any objection to 1.10-style version numbers 
>> convincing. Dotted version numbers are clearly a representation of a 
>> tuple of integers, not an odd decimal notation, as evidenced by the fact 
>> that every commonly-used dotted version numbering scheme invests each 
>> location in the tuple with some kind of semantics. In any case, 
>> precedent for such version numbers in Django was set several years ago 
>> when we shipped 1.4.10; by now we're up to 1.4.20! (Not to mention 
>> 1.5.12 and 1.6.11). 
>>
>> FWIW, I did a GitHub code search and in the first ten pages of results I 
>> found zero uses of RemovedInDjango20Warning that weren't instances of 
>> someone committing their virtualenv (with a copy of Django) to git. So I 
>> am not concerned about changing those warnings (especially since we can 
>> provide backwards compatibility). 
>>
>> Carl 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d83ee0d0-89ba-437a-819b-6083dd7f5023%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Chris Foresman]

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 a 2.0 release that could be LTS. In the meantime, minor features could 
be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be added 
to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate upgrade 
paths, while maintaining the six-month cadence for .x releases of minor 
features.

As it is, even for short projects we end up having to stay on whatever 
version of Django we started with because the client won't pay for the work 
required to upgrade. Then each version that gets released is yet more work 
that needs done, so the estimate to update gets larger and larger every six 
months. The net effect is we get stuck on older versions unable to take 
advantage of those new features anyhowways.



On Saturday, April 4, 2015 at 7:30:59 AM UTC-5, Tim Graham wrote:
>
> Now that Django 1.8 is released, I wanted to bump this thread for 
> discussion so we can hopefully ratify this schedule or modify it based on 
> feedback. In particular, I heard a concern that a six month release 
> schedule may be too often for the community. On the other hand, I think 
> smaller releases would make incremental upgrades easier.
>
> One difficulty could be if third-party packages try to support every 
> version since the last LTS (this seemed to be common with 1.4). A 6 month 
> release schedule would mean 5 versions of Django until the next LTS, 
> instead of 3 as we had since 1.4, so more `if DJANGO_X_Y` conditionals. One 
> idea is that third-party packages could declare their own "LTS" versions 
> (if needed) and drop support for older versions more freely in future 
> development.
>
> On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote:
>>
>> With the release of 1.8 coming up, it's time to think about 1.9! I've 
>> suggested some dates below. The schedule is similar to the intervals we 
>> used for 1.8 with the final release date planned for about 6 months after 
>> 1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
>> after 1.7). Please voice any thoughts or concerns. With this schedule it 
>> seems that any GSoC work would likely be included in 2.0. If you have any 
>> big features planned, please add them here: 
>> https://code.djangoproject.com/wiki/Version1.9Roadmap
>>
>> July 20 - Alpha (feature freeze)
>> August 21 - Beta (only release blockers fixed after this)
>> September 18 - RC (string freeze for translations)
>> October 2 - Final
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9d472e86-2f2c-4e20-8c77-17b3be5e2a1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: improving debug logging in development

[Chris Foresman]

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,
'formatters': {
'simple': {
'format': '%(asctime)s %(levelname)s %(message)s',
},
'request': {
'format': '%(asctime)s %(levelname)s %(status_code)d 
%(message)s -> %(request)s',
},
'sql': {
'format': '%(asctime)s %(levelname)s duration: %(duration)d 
SQL: %(sql)s',
},
},
'handlers': {
'simple.SysLogHandler': {
'level': 'DEBUG',
'class': 'logging.handlers.SysLogHandler',
'facility': 'local5',
'formatter': 'simple',
},
'request.SysLogHandler': {
'level': 'DEBUG',
'class': 'logging.handlers.SysLogHandler',
'facility': 'local5',
'formatter': 'request',
},
'db.SysLogHandler': {
'level': 'DEBUG',
'class': 'logging.handlers.SysLogHandler',
'facility': 'local5',
'formatter': 'sql',
},
},
'loggers': {
'django.request': {
'handlers': ['request.SysLogHandler'],
'level': 'DEBUG',
'propagate': True,
},
'django.db.backends': {
'handlers': ['db.SysLogHandler'],
'level': 'DEBUG',
'propagate': True,
},
'django.db.backends.schema': {
'handlers': ['simple.SysLogHandler'],
'level': 'DEBUG',
'propagate': False,
},
'loggly_logs': {
'handlers': ['simple.SysLogHandler'],
'propagate': True,
'format': 'django: %(message)s',
'level': 'DEBUG',
},
},
}


On Monday, March 23, 2015 at 12:48:26 PM UTC-5, Tim Graham wrote:
>
> The alternative to a new setting would be to revert the "merging" behavior 
> of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING entirely. This 
> original design was proposed by Claude in 
> https://code.djangoproject.com/ticket/18993#comment:7, but now we realize 
> disable_existing_loggers=True doesn't work as expected in that proposal. 
> I also find that writing a nice configuration that uses 
> disable_existing_loggers=False and that merges nicely with Django's 
> defaults to be difficult (for example, in trying to output all log entries 
> to the console, some as simple as the config below [1] won't work because 
> Django's DEFAULT_LOGGING has handlers for 'django.request' and 
> 'django.security' which don't propagate their entries (I couldn't tell the 
> reason for this from 
> https://github.com/django/django/commit/f0f327bbfe1caae6d11fbe20a3b5b96eed1704cf#diff-246800ac266982b8ad12f505352a662eR63
> )
>
> I would like to ask if anyone who is using settings.LOGGING could share 
> their config so we can get a sense of different use cases?
>
> [1] An attempt to write a LOGGING config that outputs all entires to 
> stdout, but doesn't entirely work as stated above.
>
> LOGGING = {
> 'version': 1,
> 'handlers': {
> 'console': {
> 'level': 'DEBUG',
> 'class': 'logging.StreamHandler',
> },  
> },
> # A catch-all root logger.
> 'root': {
> 'handlers': ['console'],
> 'level': 'DEBUG',
> },
> }
>
> On Monday, March 23, 2015 at 12:31:06 PM UTC-4, Carl Meyer wrote:
>>
>> On 03/22/2015 08:23 PM, Carl Meyer wrote: 
>> > The first, more complex and more important question is: how do we fix 
>> > Django's logging config process to be less broken, so that the best 
>> > advice for getting it to do what you what isn't "disable Django's 
>> > interference entirely and do it yourself."? I don't have a 
>> > fully-packaged solution ready to propose here; someone will need to dig 
>> > into it. Probably the biggest sticking point to get around will be 
>> > backwards compatibility. 
>> > 
>> > I'm pretty sure that a good solution will include an optional way to 
>> > prevent Django from ever installing its default logging config in the 
>> > first place, since it seems there's no way to tell logging to "clear 
>> out 
>> > everything and start fresh" once some configuration has been set. 
>> > 
>> > And I think it will also mean that we stop ever recommending the use of 
>> > "disable_existing_loggers" (and probably even include a callout in our 
>> > docs warning users against it). It seems that 
>> "disable_existing_loggers" 
>> > is a bad feature with surprising behavior, and our current docs were 
>> > written based on a misunderstanding of what it does. 
>>
>> After giving this a bit more thought, I think at least the first step of 
>> a better solution may not be too hard, and could be integrated 
>> immediately along with the doc changes. 

Re: User.username max_length 254

[Chris Foresman]

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 don't absolutely have to 
>> have an increased username field. They've gone this long without it.
>>
> They (we) have gone this long, not because we didn't need it, but because 
> we didn't think of it in the very beginning, and after that it was too 
> late.  The portion of users this would affect is exactly the same as the 
> set that is affected by the change in max_length on the User.email field, 
> which is already part of 1.8.  Given that fact, I don't see this as a very 
> big violation of the alpha/beta testing process.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/70bd9900-793f-4bf4-be73-7febaf9842b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chris Foresman]

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.
>
>
> If it ain't broke don't fix it. The django admin is awesome, the reason it 
> hasn't changed much is because it doesn't need to. Google.com's home page 
> still more or less looks the same as it did in 2000.  
>


The admin isn't "broke" in that is still does what it was designed to do in 
2005 or whatever. I don't believe that fact supports your assertion that it 
doesn't need changed, and even most of the Django maintainers agree the 
existing UI isn't "awesome." Functional, to a specific end, yes, but not 
"awesome." Nearly everyone I know that uses Django agrees that the admin 
interface could use improvement.

We simply stopped including the admin in every project we build—and I mean 
deleting every admin.py and taking admin out of urls.py—because it 
invariably causes more problems than it solves. If we have to do anything 
database-related, we either do it directly or use the Django shell. If 
clients want any kind of "admin"-like dashboard or whatever, we build it 
from scratch. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/23deeacb-b344-4c32-a1d3-7ed2a4964ef2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Chris Foresman]

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:
>
> Well, this change wouldn't have been made after alpha (feature-freeze) 
> either. As there haven't been any outright rejections of the idea, I think 
> the next step is for someone to write a patch and carefully consider and 
> document and backwards compatibility concerns.
>
> On Wednesday, February 25, 2015 at 11:19:46 AM UTC-5, Daniel Hawkins wrote:
>>
>> Beta 1 marks the end of any changes that aren't considered release 
>>> blocking bugs. A bug is a "Release blocker" if it's a regression from a 
>>> previous version of Django or if it's an important bug in a new feature.
>>
>>
>> ... so I guess the ship has sailed on this idea?  :(
>>
>> On Wednesday, February 11, 2015 at 3:27:35 AM UTC-5, Daniel Hawkins wrote:
>>>
>>> Yes please!  Since contrib.auth.models.User.email is an EmailField, 
>>> that change will require everyone to run a migration, right?  Then we might 
>>> as well change the character limit on the username field at the same 
>>> time, no?  And any other defaults that might be less-than-reasonable?
>>>
>>> I was going to update the longerusername package by adding a Django 1.7 
>>> migration, but it seems I can't alter fields on the User model from 
>>> within another app's migrations in Django 1.7.  This was possible with 
>>> South, but it appears to be impossible with Django migrations (except 
>>> perhaps with raw SQL, which seems like a bad idea).  So now I *have to* 
>>> create a custom user model just so I can migrate to Django 1.7 (which I 
>>> *have 
>>> to* do in order to continue getting security releases after 1.8 is 
>>> released).
>>>
>>> According to the docs, setting a custom user model after you've already 
>>> run initial migrations is not supported (
>>> https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#substituting-a-custom-user-model).
>>>  
>>>  So, for anyone without a custom user model, who is already running on 
>>> Django 1.7 in production, who would like to have usernames longer than 30 
>>> characters, there is no way to make that happen.
>>>
>>>
>>> On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:

 Hi All,

 I was reminded by:
 Allow shadowing of abstract fields 
 https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
 and https://code.djangoproject.com/ticket/24288 (Custom User Models 
 for small tweaks).

 Could we reopen https://code.djangoproject.com/ticket/20846 
 
  
 and increase User.username max_length to 254?

 Personally, that's the only thing I've ever needed to change about my 
 User class. I just need it long enough to hold email addresses. I've seen 
 many other people wanting the same thing.

 In 1.8 we migrated the length of EmailField from 75 to 254, so it 
 should be almost™ as easy to change the username field.

 If needed, we could keep the 30-character limit on UserCreationForm and 
 UserChangeForm for backwards compatibility. The limit in the database is 
 the real killer :) Though, consistency is also nice.

 Thanks,
 Collin



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a9542359-cc2d-43cb-922f-1addb78216f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding context to docs

[Chris Foresman]

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 started. 
Then you can make a branch, make your changes, then open a pull request 
from your branch to upstream/master.

Some of the nice people in #djnago-devs on freenode have been helping me 
along the way; I'll be there tomorrow, too.

Good luck!

On Thursday, February 19, 2015 at 7:04:24 PM UTC-6, Curtis Maloney wrote:
>
> On 20 February 2015 at 11:49, Diana Probst  > wrote:
>
>> Never done either of those things, and I'm completely not set up to do 
>> them.  I will if creating this subject has made me the owner of it, but 
>> it's a lot more work for me than it would be for someone else.  I'd start 
>> with the Writing your First Django Patch part of the tutorial, yes?
>>
>>
> Please don't feel pressured to write a patch to get this fixed.  If you 
> don't feel up to it, or don't have the time, I'm happy to do it - albeit at 
> my own pace.
>
> I prefer to suggest people submit PRs simply to reinforce the fact that 
> anyone is welcome to contribute.
>
> I highly recommend reading the contribution guide - 
> https://docs.djangoproject.com/en/1.7/internals/contributing/
>
> If you'd like some guidance on getting set up to make PRs, come find the 
> helpful folks on IRC, in #django on the freenode network.
>
> Thanks for the explanation.  I had a form in what I was pretty sure was 
>> the wrong place, and it was working, but it rankled so hard I had to look 
>> for why.
>>
>
> That's usually a sign of good instincts :)
> If code doesn't "feel" right, it often leads to problems down the line.
>
> --
> Curtis
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9550fbe8-e999-4a8e-8b96-e8a27556c8fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8 bug fix sprinting this weekend

[Chris Foresman]

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 over the next couple days, please consider working on 
> something from this list (whether it is writing a patch, reviewing an 
> existing patch, or triaging an issue):
>
>
> https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=~1.8-beta=assigned=new=~1.8=assigned=new=id=summary=status=owner=type=component=changetime=1=changetime
>
> These are my top priorities until the beta release (scheduled for Monday), 
> but if you have other small bug fixes, they will also happily be considered.
>
> I will be available in #django-dev most of tomorrow (~12:00 UTC - 0:00 
> UTC) and on Saturday (~12:00 UTC - 19:00 UTC) if you need guidance (and 
> there are many other helpful people around in case I am not). I invite 
> other members of the team to participate and post their availability to 
> cover other timezones.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f62888f-bf18-4c0c-adf1-bf78370f4212%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pull request builder now on Ubuntu 14.04

[Chris Foresman]

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 older than 1.8 as those 
> builds don't pass on 14.04. Also I've reserved three of the slaves for the 
> pull request builder -- this should hopefully cut down on the dreaded "git 
> checkout  where hash was not the commit" errors.
>
> A reminder that the documentation for the CI cluster is on the wiki:
> https://code.djangoproject.com/wiki/Jenkins
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a6b1fe84-b6cf-48e2-ae70-569c47efd489%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: cursor.callproc()

[Chris Foresman]

Good points. I went looking for `callproc()` documentation and couldn't 
find anything useful, which if I understand correctly is part of the reason 
this thread started. So +1 on documenting it!

The most complicated part of dealing with store procedures from a high 
level is getting them in the database to begin with, and updating them if 
they need to change. Obviously I'm just manually entering them via the 
console, but it would be great if there was some consistent way to add them 
to the database via Migrations or something similar.


On Tuesday, October 21, 2014 4:44:25 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 = user.get_profile() 
> > cursor = connection.cursor() 
> > cursor.execute(query, [user.id, profile.id]) 
> > ``` 
> > 
> There are two benefits: 
>
> 1) Unlike Python functions, SQL stored procedures can have output 
> parameters 
> (and input/output parameters). callproc() allows you to get these (it 
> returns 
> the sequence of parameters, with outputs placed appropriately), while 
> execute() can only return the procedure's return value (I'm not quite sure 
> about procedures yielding result-sets -- callproc() will let you fetch the 
> results, I'm not sure the same holds for execute() universally). 
>
> 2) Surprisingly, stored procedure invocation syntax is not completely 
> standard; for example, on PostgreSQL, you should have 
>
> query= 'SELECT sp_recommendation_engine(%s, %s)' 
>
> HTH, 
> Shai. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4ec3adbe-e240-4a80-bd8e-1f8a8eb5d229%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: cursor.callproc()

[Chris Foresman]

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 wrote:
>
> On 10/20/2014 12:26 PM, Carl Meyer wrote: 
> > On 10/19/2014 12:54 AM, Marc Tamlyn wrote: 
> >> I guess now with migrations we have a nice way of running the SQL 
> >> against the database to create the stored procedures. 
> >> 
> >> However if we plan to make this a public API, it should be a nice one. 
> >> Something along the lines of db.procedures.proc_name(*args, **kwargs) 
> >> would be preferable I think. Obviously this requires more magic to make 
> >> it work (or explicit registration of your procedures). 
> > 
> > I know this is hypothetical, but I don't think that is a particularly 
> > nicer API, or that we should provide such syntactic sugar atop 
> > callproc(). Providing the procedure name as a string is not really a 
> > problem, and is preferable to doing `__getattr__` magic or requiring 
> > registration of procedures; the syntactic sugar just doesn't provide 
> > enough benefit to justify the magic, and all the various ways that that 
> > magic could confuse users and cause maintenance issues. 
>
> (I should clarify: I do think there are ways that we could improve on 
> the PEP 249 callproc() API if we were providing a higher-level 
> Django-specific alternative. I just don't think that moving the 
> procedure name from a string argument to a magical getattr-based Python 
> function is a good idea.) 
>
> Carl 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/602a9905-22d7-49f5-b66a-50a71ca780f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Password Validity Layer

[Chris Foresman]

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 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 clean 
>>> too)
>>>
>>
>> Is there a way to enforce that the validation calls `check_password`? 
>> Maybe create a `forms.PasswordField`? 
>>
>
>
> Or maybe the solution is to define a `check_password` function on your 
> model, and pass that in as a keyword option for the field declaration.
>
> ```python
> class RegistrationForm(forms.Form):
> password = forms.PasswordField(validator='user.MyUser.check_password')
> ...
> ```
>

Or, define the default validator for the field to be 
'settings.AUTH_USER_MODEL.validate_password()`. Then it can be overridden 
if one wants, but by default you would set it on your custom user model. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/622ba66b-252d-4ee9-b933-96c8f4212ff6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Password Validity Layer

[Chris Foresman]

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, so I don't think that patch covers 
>> it (or at least the relevant forms have to call validate_password in clean 
>> too)
>>
>
> Is there a way to enforce that the validation calls `check_password`? 
> Maybe create a `forms.PasswordField`? 
>


Or maybe the solution is to define a `check_password` function on your 
model, and pass that in as a keyword option for the field declaration.

```python
class RegistrationForm(forms.Form):
password = forms.PasswordField(validator='user.MyUser.check_password')
...
```

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/434ced60-671a-450d-8be0-3b5a32ee4c7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Password Validity Layer

[Chris Foresman]

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 clean 
> too)
>

Is there a way to enforce that the validation calls `check_password`? Maybe 
create a `forms.PasswordField`? 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89856a65-e12b-455a-b6a1-d16483465618%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring GitHub login for actions on Trac

[Chris Foresman]

+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 GitHub account (and if not, creating an account is useful for 
> much more than just Django), and many actions of contributing to Django 
> already tie closely to GitHub - even though you can still avoid it if 
> you really insist. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/85189601-fdf8-412b-8a61-d061bf4e1472%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

[Chris Foresman]

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, 2014 at 9:29 PM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Hello,
>>
>> I’ve been working on updating our organization: 
>> https://github.com/django/django/pull/2947
>>
>> This proposal attempts to address several issues with our current 
>> organization. There’s no short version and any simplistic interpretation 
>> will be wrong. Here are the main factors at play.
>>
>> 1) In theory, the core team is the group of committers, each of whom has 
>> been judged capable of making code design decisions. (Astute readers will 
>> have noticed that it isn’t true in practice.) This restrictive approach to 
>> staffing makes it hard to cover all of our HR needs. Specifically:
>> a) It creates a chasm between non-core and core contributors, 
>> which has perverse side effects and creates tons of frustration.
>> b) It drives away would-be contributors whose help wouldn’t 
>> involve committing code to the main Django repository.
>> c) Even if such contributors are found, it’s hard to convince the 
>> core team to bring them on board.
>>
>> 2) Since the BDFLs have stepped down, there’s no obvious way to 
>> counteract honest mistakes made by core developers. This is making the core 
>> team uncomfortable at times. While BDFLs hardly ever had to intervene, 
>> their mere existence played a role. We need to recreate that role in a more 
>> democratic fashion.
>>
>> 3) We’re good at burning out our most prolific contributors. Since we 
>> lack structure, it’s too easy to become responsible for everything, until 
>> you can’t handle it anymore and throw the towel. We must classify roles, 
>> write down who takes what role, fill the gaps with new volunteers, and 
>> remove pressure around stepping down.
>>
>> 4) As we have grown, having no explicit organization within the core team 
>> makes it complicated for newcomers to figure who does what and how they fit 
>> in the picture. It doesn’t erase the power structure. It merely hides it.
>>
>> My proposal builds upon years of discussions at DjangoCons. It has gone 
>> through many rounds of feedback inside the core team already. It’s an 
>> evolution, not a revolution. It takes into account the growth of the 
>> project, acknowledges and formalizes some things that we’re already doing, 
>> and introduces just enough formal organization to make everyone comfortable.
>>
>> It doesn’t encompass everything we could do to improve our organization. 
>> In particular I expect some follow up work on how we manage roles in order 
>> to avoid burnout.
>>
>> I would like to ask the core team for a formal vote on this pull request, 
>> according to our guidelines. [1] Please vote by the end of July in UTC 
>> (2014-08-01T00:00:00Z).
>>
>> Obviously, I’m voting +1.
>>
>> Thank you,
>>
>> --
>> Aymeric.
>>
>>
>> [1] 
>> https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-features/#how-we-make-decisions
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4920b823-debe-411c-8b3f-6fad13c10604%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM support for NoSql databases

[chris . foresman]

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 NoSQL data store
>  * An admin representation of a NoSQL data model.
>
> These two functions don't require complex relations. They require 
> relatively simple CRUD operations on a single object; they require an 
> implementation of filter, but not an implementation that allows joins of 
> any kind inside a filter clause. Yes, this will cut off some functionality 
> -- some custom filters, for example, won't be possible. It might be 
> necessary to remove total object counts in admin ListViews -- but then, 
> that would be a good performance boost for PostgreSQL as well. 
>
> But broadly speaking, I see no reason why it shouldn't be possible to put 
> store a data model in NoSQL, and visualise the contents of that model in 
> admin. And you should be able to throw up a Form wrapping that data model. 
>
> I see two ways to achieve this goal. The first is to put an alternate 
> backend into Django's existing ORM. This is the approach attempted by Alex 
> in his GSoC project. It's possible, and actually doesn't require that much 
> work; but there are a couple of unresolved issues, mostly around handling 
> of non-integer automatic primary keys. These are problems that we might be 
> worth addressing anyway, because UUID-based auto primary keys would be a 
> worthwhile extension to SQL data stores.
>
> The second approach is to produce a duck type compatible model API. There 
> aren't (or shouldn't be) any instance checks tied to 
> django.db.models.Model; as long as your NoSQL layer implements the same 
> API, you should be able to drop it into the admin or a ModelForm. Taking 
> this approach would have the side effect that we'd have to clean up the 
> formal definition of _meta, which in itself would be a nice goal.  Added 
> benefit -- this approach doesn't actually require any changes to core 
> itself -- the ducks can be completely external to Django. The only changes 
> to core would be whatever cleanups and documentation the project identifies.
>
> The other, unrelated problem isn't technical at all -- its that that 
> enthusiasm for this problem has pretty much dried up in the core team 
> AFAICT. I certainly don't have any call for using a NoSQL store in my life 
> at the moment. However, if a ready-to-use implementation of either of these 
> approaches were to land on our doorstep, I wouldn't resist them being added 
> to core.
>

Wouldn't an easy (i.e. straightforward) solution be to add an Django "ODM" 
that mirrors the ORM wherever it makes sense?  This sounds pretty close to 
your second solution, except choosing SQL vs NoSQL means users make a more 
explicit choice whether to use the ODM API vs the ORM API.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6f2bcf71-13bd-40cf-bee8-0f5fb264a5c7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.