[ANNOUNCE] Django 1.11 alpha 1 released

[Tim Graham]

We've made the first release on the way to Django's next major release, 
Django 1.11! With two and a half months until the scheduled final release, 
we'll need timely testing from the community to ensure an on-time and 
stable release. Check out the blog post:

https://www.djangoproject.com/weblog/2017/jan/17/django-111-alpha-1/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ec78273c-eeb7-44d9-bd54-4efa0c71b971%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django search

[Branko Zivanovic]

Yes that is true, and I have succeeded in making select menu and checkbox 
by using Django's forms and their widgets.

Thanks anyway!

уторак, 17. јануар 2017. 21.04.51 UTC+1, Fred Stluka је написао/ла:
>
> Branko,
>
> You may need to explain a little more.
>
> It sounds like you have search working when you type the search 
> string into a HTML text box.  True?
>
> What do you want to do with the menu and checkbox?  Are you 
> trying to arrange for the text of the menu label and the text of the
> checkbox label to be combined somehow to form the search 
> string?
>
> --Fred 
> --
> Fred Stluka -- mailt...@bristle.com  -- 
> http://bristle.com/~fred/ 
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! 
> Open Source: Without walls and fences, we need no Windows or Gates. 
> --
>
> On 1/17/17 9:32 AM, Branko Zivanovic wrote:
>
> Thank you for reply! 
>
> I'm fine with text input but I also want select menu and checkbox. I want 
> to use it to somehow filter my search. 
> I'm not sure how it fits anyway in bigger picture. How do people make 
> search with select menu and checkbox?
>
> Best,
> Branko
>
> понедељак, 16. јануар 2017. 07.13.44 UTC+1, Constantine Covtushenko је 
> написао/ла: 
>>
>> Hi Branco, 
>>
>> Sorry, but can you be more specific?
>> If you've got the result what is your concern?
>> Do you only need to switch into forms?
>>
>> Regards,
>> Constantine C.
>>
>> On Sun, Jan 15, 2017 at 2:41 PM, Branko Zivanovic > > wrote:
>>
>>> How do i implement search on django website with select menu and 
>>> checkbox? I've succeeded in adding basic text input and it works but I 
>>> didn't use django forms. How do I add this type of search?
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/078841f1-a976-4c22-bb2f-ff5069bdce1d%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 users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users...@googlegroups.com .
> To post to this group, send email to django...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/9fc70bbe-487d-4c4b-8f9a-77ad79281193%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/642c076f-aafd-46b1-b63c-0a8d174e8595%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the fate of closed database connections?

[Fred Stluka]

  
  
Mike,

Good info.  Yeah, keep experimenting and report what you find 
here.  Hopefully someone will jump in with a definitive answer 
for you.

--Fred
  
  
  Fred Stluka -- mailto:f...@bristle.com --
  http://bristle.com/~fred/
  
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service!
  
  Open Source: Without walls and fences, we need no Windows or
  Gates.
  
  

On 1/17/17 4:52 PM, Michael Grundler
  wrote:


  CONN_MAX_AGE = 1 behaves similarly to 2 and None. I
will try and do some testing with additional spatialite DB
drivers. Perhaps its worth noting that I have not seen any of
these problems when using postgresql as the DB backend.


Many thanks,
Mike
  
  On Tuesday, January 17, 2017 at 4:18:01 PM UTC-5, Fred Stluka
  wrote:
  
 Mike,
  
  I agree.  It seems that 0 and 2 should have similar
  effects in your 
  case.  Have you tried 1?
  
  So, 2 behaves like None, eh?  Perhaps that's because they
  are both
  allowing connections to be reused.  0 explicitly prevents
  connection
  pooling, so that each request opens/uses/closes its own
  connection.
  Maybe there's a bug related to closing connections as you
  originally
  suggested?
  
  Have you tried a different driver for the spatialite DB? 
  Also, can you
  experiment with a different DB to shed some light in the
  problem?
  Personally, I've found it VERY easy to flip between MySQL
  and SQLite.
  On my project, we use MySQL in PROD, but we run all of our
  
  regression tests against SQLite.  To make this happen, all
  I had to 
  do was add this to our settings file:
  
  RUNNING_UNIT_TESTS = 'test' in sys.argv
  if RUNNING_UNIT_TESTS:
      DATABASES['default'] = {
      'ENGINE': 'django.db.backends.sqlite3',
      }
  
  Any other ideas, anyone?
  
  --Fred 
  
 Fred Stluka -- mailt...@bristle.com
-- http://bristle.com/~fred/ 
Bristle Software, Inc -- http://bristle.com -- Glad to be of
service! 
Open Source: Without walls and fences, we need no
Windows or Gates.
 
  
  On 1/17/17 3:59 PM, Michael Grundler wrote:
  
  

  Fred,
  
  
  I observe this behavior using uwsgi + nginx. Per your
  suggesting I tried a CONN_MAX_AGE = 2, which seems to
  have the same qualitative behavior as CONN_MAX_AGE =
  None (i.e. the error message does not appear in the
  log after repeatedly refreshing the browser on the
  admin page). 
  
  
  I don't understand why a CONN_MAX_AGE = 0 would
yield qualitatively different behavior than
CONN_MAX_AGE = 2.


Many thanks,
Mike



  
  On Tuesday, January 17, 2017 at 2:59:21 PM UTC-5,
  Fred Stluka wrote:
  
 Mike,
  
  As of version 1.6, Django supports persistent
  DB connections
  (connection pooling).  CONN_MAX_AGE specifies
  the number of
  seconds that a connection will remain open and
  be reused.
  You can set it to 0 to cause each DB
  interaction to open, use,
  and close its own connection.  You can set it
  to None to allow
  an unlimited number of connections.  See:
  - https://docs.djangoproject.com/en/dev/ref/databases/
  
  However, the behavior you're seeing doesn't
  seem to match this 
  documented behavior.  I'd have expected
  CONN_MAX_AGE = 0
  to prevent connections from being reused, so
  they should be 
 

Re: Am I stupid or is there an essential error in Django 1.10 Docs?

[Vijay Khemlani]

The only "custom include" in Django is for loading other url files

The rest of the imports are typical Python module / packages

On 1/17/17, 'Peter Müller' via Django users
 wrote:
> Ah I now see the problem. However I tried to remove the entry in the
> __init__.py file
> Python is then unable to find *any *module in that directory. Don't ask me
> why that is.
>
> Also I noticed that django has its completely own import ecosystem.
> So I used django.conf.urls.include to include a new urls file in that sub
> directory.
> And suddenly everything works fine.
>
> Thanks everyone
>
> Am Dienstag, 17. Januar 2017 08:01:41 UTC+1 schrieb Michal Petrucha:
>>
>> On Mon, Jan 16, 2017 at 12:23:09PM -0800, 'Peter Müller' via Django users
>>
>> wrote:
>> > Am Montag, 16. Januar 2017 21:20:53 UTC+1 schrieb Daniel Roseman:
>> > > The traceback shows that you are importing your views module in the
>> > > __init__.py of your app. Don't do that.
>> >
>> > Well else python doesn't find the view.py file?
>>
>> Python will be able to import db_testing.views just fine even if you
>> don't import viewsi from . in db_testing/__init__.py. All Python cares
>> about is that there is a correct Python file in the correct location.
>>
>> If you're interested in more details about what's going wrong here,
>> there's an explanation here:
>>
>> https://docs.djangoproject.com/en/1.10/ref/applications/#how-applications-are-loaded
>>
>>
>> In particular, the following paragraphs:
>>
>> > At this stage, your code shouldn’t import any models!
>> >
>> > In other words, your applications’ root packages and the modules
>> > that define your application configuration classes shouldn’t import
>> > any models, even indirectly.
>>
>> What's happening here is that the root of your “db_testing” package
>> (i.e. db_testing/__init__.py) indirectly imports models, because it
>> imports the views module, which in turn imports models.
>>
>> Just removing the “from . import views” line should let you move
>> forward – unless you also have other imports in the __init__.py file,
>> in which case you can most likely just remove them, too. In general,
>> in an average Django package, there's little reason to import stuff in
>> its root package.
>>
>> Good luck,
>>
>> Michal
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/b1760656-c6a0-40c5-a002-19958e5706ef%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALn3ei3UOv%2BeiT6eRbZqSnmaNadbc-Smwfc%2BCK0%3DMuxC2opTCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the fate of closed database connections?

[Michael Grundler]

CONN_MAX_AGE = 1 behaves similarly to 2 and None. I will try and do some 
testing with additional spatialite DB drivers. Perhaps its worth noting 
that I have not seen any of these problems when using postgresql as the DB 
backend.

Many thanks,
Mike

On Tuesday, January 17, 2017 at 4:18:01 PM UTC-5, Fred Stluka wrote:
>
> Mike,
>
> I agree.  It seems that 0 and 2 should have similar effects in your 
> case.  Have you tried 1?
>
> So, 2 behaves like None, eh?  Perhaps that's because they are both
> allowing connections to be reused.  0 explicitly prevents connection
> pooling, so that each request opens/uses/closes its own connection.
> Maybe there's a bug related to closing connections as you originally
> suggested?
>
> Have you tried a different driver for the spatialite DB?  Also, can you
> experiment with a different DB to shed some light in the problem?
> Personally, I've found it VERY easy to flip between MySQL and SQLite.
> On my project, we use MySQL in PROD, but we run all of our 
> regression tests against SQLite.  To make this happen, all I had to 
> do was add this to our settings file:
>
> RUNNING_UNIT_TESTS = 'test' in sys.argv
> if RUNNING_UNIT_TESTS:
> DATABASES['default'] = {
> 'ENGINE': 'django.db.backends.sqlite3',
> }
>
> Any other ideas, anyone?
>
> --Fred 
> --
> Fred Stluka -- mailt...@bristle.com  -- 
> http://bristle.com/~fred/ 
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! 
> Open Source: Without walls and fences, we need no Windows or Gates. 
> --
>
> On 1/17/17 3:59 PM, Michael Grundler wrote:
>
> Fred,
>
> I observe this behavior using uwsgi + nginx. Per your suggesting I tried a 
> CONN_MAX_AGE = 2, which seems to have the same qualitative behavior as 
> CONN_MAX_AGE = None (i.e. the error message does not appear in the log 
> after repeatedly refreshing the browser on the admin page).  
>
> I don't understand why a CONN_MAX_AGE = 0 would yield qualitatively 
> different behavior than CONN_MAX_AGE = 2. 
>
> Many thanks,
> Mike
>
>
>
> On Tuesday, January 17, 2017 at 2:59:21 PM UTC-5, Fred Stluka wrote: 
>>
>> Mike,
>>
>> As of version 1.6, Django supports persistent DB connections
>> (connection pooling).  CONN_MAX_AGE specifies the number of
>> seconds that a connection will remain open and be reused.
>> You can set it to 0 to cause each DB interaction to open, use,
>> and close its own connection.  You can set it to None to allow
>> an unlimited number of connections.  See:
>> - https://docs.djangoproject.com/en/dev/ref/databases/
>>
>> However, the behavior you're seeing doesn't seem to match this 
>> documented behavior.  I'd have expected CONN_MAX_AGE = 0
>> to prevent connections from being reused, so they should be 
>> closed at the end of the request that used them.  So, unless you
>> have 65 or more concurrent requests, you should not be hitting
>> your limit.  
>>
>> I'm not surprised that CONN_MAX_AGE = None has an effect, but 
>> I wouldn't have been able to predict whether it makes things 
>> better or worse.  It allows Django to reuse connections so fewer
>> of them should be created, but it also allows Django to pool them 
>> for as long as it likes, so a large number of them may accumulate.
>>
>> Have you tried any other values for CONN_MAX_AGE, like 1 or 2?
>>
>> Also, are you using the Django development server?  The docs
>> linked above say:
>> "The development server creates a new thread for each request 
>>  it handles, negating the effect of persistent connections. 
>>  Don’t enable them during development."
>>
>> --Fred 
>> --
>> Fred Stluka -- mailt...@bristle.com -- http://bristle.com/~fred/ 
>> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! 
>> Open Source: Without walls and fences, we need no Windows or Gates. 
>> --
>>
>> On 1/17/17 2:25 PM, Michael Grundler wrote:
>>
>> When Django closes a database connection at the end of a request/response 
>> cycle does that connection still maintain its hold on the database?
>>
>>
>> I ask because I am running an app on a spatialite (v4.3.0a) database, 
>> which, due to a limitation in the GEOS library (v3.6.1-CAPI-1.10.1 r0), can 
>> only accept a maximum of 64 connections. When I configure Django so that 
>> CONN_MAX_AGE = 0, the server log will eventually begin filling up with 
>> messages that read "ERROR: Too many connections: max 64". If I enable 
>> persistent connections by setting CONN_MAX_AGE = None, these messages 
>> disappear. To me this suggests that when Django closes a connection at the 
>> end of a request/response cycle that connection persists from spatialite's 
>> perspective.
>>
>>
>> Is this expected behavior?
>>
>>
>> The error message is easily reproduced by starting a project configured 
>> to use spatialite, logging into the admin page, and then refreshing your 
>> browser repeatedly until 64 

Re: Am I stupid or is there an essential error in Django 1.10 Docs?

['Peter Müller' via Django users]

Ah I now see the problem. However I tried to remove the entry in the 
__init__.py file
Python is then unable to find *any *module in that directory. Don't ask me 
why that is.

Also I noticed that django has its completely own import ecosystem.
So I used django.conf.urls.include to include a new urls file in that sub 
directory.
And suddenly everything works fine.

Thanks everyone 

Am Dienstag, 17. Januar 2017 08:01:41 UTC+1 schrieb Michal Petrucha:
>
> On Mon, Jan 16, 2017 at 12:23:09PM -0800, 'Peter Müller' via Django users 
> wrote: 
> > Am Montag, 16. Januar 2017 21:20:53 UTC+1 schrieb Daniel Roseman: 
> > > The traceback shows that you are importing your views module in the 
> > > __init__.py of your app. Don't do that. 
> > 
> > Well else python doesn't find the view.py file? 
>
> Python will be able to import db_testing.views just fine even if you 
> don't import viewsi from . in db_testing/__init__.py. All Python cares 
> about is that there is a correct Python file in the correct location. 
>
> If you're interested in more details about what's going wrong here, 
> there's an explanation here: 
>
> https://docs.djangoproject.com/en/1.10/ref/applications/#how-applications-are-loaded
>  
>
> In particular, the following paragraphs: 
>
> > At this stage, your code shouldn’t import any models! 
> > 
> > In other words, your applications’ root packages and the modules 
> > that define your application configuration classes shouldn’t import 
> > any models, even indirectly. 
>
> What's happening here is that the root of your “db_testing” package 
> (i.e. db_testing/__init__.py) indirectly imports models, because it 
> imports the views module, which in turn imports models. 
>
> Just removing the “from . import views” line should let you move 
> forward – unless you also have other imports in the __init__.py file, 
> in which case you can most likely just remove them, too. In general, 
> in an average Django package, there's little reason to import stuff in 
> its root package. 
>
> Good luck, 
>
> Michal 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b1760656-c6a0-40c5-a002-19958e5706ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the fate of closed database connections?

[Fred Stluka]

  
  
Mike,

I agree.  It seems that 0 and 2 should have similar effects in your

case.  Have you tried 1?

So, 2 behaves like None, eh?  Perhaps that's because they are both
allowing connections to be reused.  0 explicitly prevents connection
pooling, so that each request opens/uses/closes its own connection.
Maybe there's a bug related to closing connections as you originally
suggested?

Have you tried a different driver for the spatialite DB?  Also, can
you
experiment with a different DB to shed some light in the problem?
Personally, I've found it VERY easy to flip between MySQL and
SQLite.
On my project, we use MySQL in PROD, but we run all of our 
regression tests against SQLite.  To make this happen, all I had to

do was add this to our settings file:

RUNNING_UNIT_TESTS = 'test' in sys.argv
if RUNNING_UNIT_TESTS:
    DATABASES['default'] = {
    'ENGINE': 'django.db.backends.sqlite3',
    }

Any other ideas, anyone?

--Fred


  
  Fred Stluka -- mailto:f...@bristle.com --
  http://bristle.com/~fred/
  
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service!
  
  Open Source: Without walls and fences, we need no Windows or
  Gates.
  
  

On 1/17/17 3:59 PM, Michael Grundler
  wrote:


  
Fred,


I observe this behavior using uwsgi + nginx. Per your suggesting
I tried a CONN_MAX_AGE = 2, which seems to have the same
qualitative behavior as CONN_MAX_AGE = None (i.e. the error
message does not appear in the log after repeatedly refreshing
the browser on the admin page). 


I don't understand why a CONN_MAX_AGE = 0 would yield
  qualitatively different behavior than CONN_MAX_AGE = 2.
  
  
  Many thanks,
  Mike
  
  
  

On Tuesday, January 17, 2017 at 2:59:21 PM UTC-5, Fred
Stluka wrote:

   Mike,

As of version 1.6, Django supports persistent DB
connections
(connection pooling).  CONN_MAX_AGE specifies the number
of
seconds that a connection will remain open and be
reused.
You can set it to 0 to cause each DB interaction to
open, use,
and close its own connection.  You can set it to None to
allow
an unlimited number of connections.  See:
- https://docs.djangoproject.com/en/dev/ref/databases/

However, the behavior you're seeing doesn't seem to
match this 
documented behavior.  I'd have expected CONN_MAX_AGE = 0
to prevent connections from being reused, so they should
be 
closed at the end of the request that used them.  So,
unless you
have 65 or more concurrent requests, you should not be
hitting
your limit.  

I'm not surprised that CONN_MAX_AGE = None has an
effect, but 
I wouldn't have been able to predict whether it makes
things 
better or worse.  It allows Django to reuse connections
so fewer
of them should be created, but it also allows Django to
pool them 
for as long as it likes, so a large number of them may
accumulate.

Have you tried any other values for CONN_MAX_AGE, like 1
or 2?

Also, are you using the Django development server?  The
docs
linked above say:
    "The development server creates a new thread for
each request 
 it handles, negating the effect of persistent
connections. 
 Don’t enable them during development."

--Fred 
   Fred Stluka -- mailt...@bristle.com
  -- http://bristle.com/~fred/ 
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service! 
  Open Source: Without walls and fences, we need no
  Windows or Gates.
   

On 1/17/17 2:25 PM, Michael Grundler wrote:


  
When
  Django closes a database connection at the end of
  a request/response cycle does that connection
  still maintain 

Re: What is the fate of closed database connections?

[Michael Grundler]

Fred,

I observe this behavior using uwsgi + nginx. Per your suggesting I tried a 
CONN_MAX_AGE = 2, which seems to have the same qualitative behavior as 
CONN_MAX_AGE = None (i.e. the error message does not appear in the log 
after repeatedly refreshing the browser on the admin page). 

I don't understand why a CONN_MAX_AGE = 0 would yield qualitatively 
different behavior than CONN_MAX_AGE = 2.

Many thanks,
Mike



On Tuesday, January 17, 2017 at 2:59:21 PM UTC-5, Fred Stluka wrote:
>
> Mike,
>
> As of version 1.6, Django supports persistent DB connections
> (connection pooling).  CONN_MAX_AGE specifies the number of
> seconds that a connection will remain open and be reused.
> You can set it to 0 to cause each DB interaction to open, use,
> and close its own connection.  You can set it to None to allow
> an unlimited number of connections.  See:
> - https://docs.djangoproject.com/en/dev/ref/databases/
>
> However, the behavior you're seeing doesn't seem to match this 
> documented behavior.  I'd have expected CONN_MAX_AGE = 0
> to prevent connections from being reused, so they should be 
> closed at the end of the request that used them.  So, unless you
> have 65 or more concurrent requests, you should not be hitting
> your limit.  
>
> I'm not surprised that CONN_MAX_AGE = None has an effect, but 
> I wouldn't have been able to predict whether it makes things 
> better or worse.  It allows Django to reuse connections so fewer
> of them should be created, but it also allows Django to pool them 
> for as long as it likes, so a large number of them may accumulate.
>
> Have you tried any other values for CONN_MAX_AGE, like 1 or 2?
>
> Also, are you using the Django development server?  The docs
> linked above say:
> "The development server creates a new thread for each request 
>  it handles, negating the effect of persistent connections. 
>  Don’t enable them during development."
>
> --Fred 
> --
> Fred Stluka -- mailt...@bristle.com  -- 
> http://bristle.com/~fred/ 
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! 
> Open Source: Without walls and fences, we need no Windows or Gates. 
> --
>
> On 1/17/17 2:25 PM, Michael Grundler wrote:
>
> When Django closes a database connection at the end of a request/response 
> cycle does that connection still maintain its hold on the database?
>
>
> I ask because I am running an app on a spatialite (v4.3.0a) database, 
> which, due to a limitation in the GEOS library (v3.6.1-CAPI-1.10.1 r0), can 
> only accept a maximum of 64 connections. When I configure Django so that 
> CONN_MAX_AGE = 0, the server log will eventually begin filling up with 
> messages that read "ERROR: Too many connections: max 64". If I enable 
> persistent connections by setting CONN_MAX_AGE = None, these messages 
> disappear. To me this suggests that when Django closes a connection at the 
> end of a request/response cycle that connection persists from spatialite's 
> perspective.
>
>
> Is this expected behavior?
>
>
> The error message is easily reproduced by starting a project configured to 
> use spatialite, logging into the admin page, and then refreshing your 
> browser repeatedly until 64 requests have been made.
>
>
> Thanks for any insights,
>
> Mike
>
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users...@googlegroups.com .
> To post to this group, send email to django...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/8b2d88c4-056c-4eeb-9dc9-7295f7ff0961%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5e49730b-8e58-4d26-aedc-0228717eefa6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to do ces monitoring on django application

[Fred Stluka]

  
  
Anjali,

What do you mean by "ces monitoring"?  I've never heard of it.
When I searched:
- http://google.com/search?q=ces+monitoring
I found some references to IBM products.

--Fred
  
  
  Fred Stluka -- mailto:f...@bristle.com --
  http://bristle.com/~fred/
  
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service!
  
  Open Source: Without walls and fences, we need no Windows or
  Gates.
  
  

On 1/17/17 6:06 AM,
  anjalim...@gmail.com wrote:


  
I want to do ces monitoring for my application. I got one
  module as statsd but that wasn't helpful.
Can anyone provide me suggestions how I can do that.


Thanks in advance,
Anjali
  
  -- 
  You received this message because you are subscribed to the Google
  Groups "Django users" group.
  To unsubscribe from this group and stop receiving emails from it,
  send an email to django-users+unsubscr...@googlegroups.com.
  To post to this group, send email to django-users@googlegroups.com.
  Visit this group at https://groups.google.com/group/django-users.
  To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7f89f222-be77-4410-8e0d-856ae4a0c02d%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3a3a4648-b7cb-9300-b4a3-a517e98d90eb%40bristle.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django search

[Fred Stluka]

  
  
Branko,

You may need to explain a little more.

It sounds like you have search working when you type the search 
string into a HTML text box.  True?

What do you want to do with the menu and checkbox?  Are you 
trying to arrange for the text of the menu label and the text of the
checkbox label to be combined somehow to form the search 
string?

--Fred
  
  
  Fred Stluka -- mailto:f...@bristle.com --
  http://bristle.com/~fred/
  
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service!
  
  Open Source: Without walls and fences, we need no Windows or
  Gates.
  
  

On 1/17/17 9:32 AM, Branko Zivanovic
  wrote:


  Thank you for reply!


I'm fine with text input but I also want select menu and
  checkbox. I want to use it to somehow filter my search. 
I'm not sure how it fits anyway in bigger picture. How do
  people make search with select menu and checkbox?


Best,
Branko
  
  понедељак, 16. јануар 2017. 07.13.44 UTC+1, Constantine
  Covtushenko је написао/ла:
  
Hi Branco,
  
  
  Sorry, but can you be more specific?
  If you've got the result what is your concern?
  Do you only need to switch into forms?
  
  
  Regards,
  Constantine C.


  On Sun, Jan 15, 2017 at 2:41 PM,
Branko Zivanovic 
wrote:

  How
  do i implement search on django website with
  select menu and checkbox? I've succeeded in adding
  basic text input and it works but I didn't use
  django forms. How do I add this type of search?
  
  
  -- 
  You received this message because you are
  subscribed to the Google Groups "Django users"
  group.
  To unsubscribe from this group and stop receiving
  emails from it, send an email to django-users...@googlegroups.com.
  To post to this group, send email to django...@googlegroups.com.
  Visit this group at https://groups.google.com/group/django-users.
  To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/078841f1-a976-4c22-bb2f-ff5069bdce1d%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 users" group.
  To unsubscribe from this group and stop receiving emails from it,
  send an email to django-users+unsubscr...@googlegroups.com.
  To post to this group, send email to django-users@googlegroups.com.
  Visit this group at https://groups.google.com/group/django-users.
  To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9fc70bbe-487d-4c4b-8f9a-77ad79281193%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a899b1c5-a9ad-015f-e451-20363de1b8c1%40bristle.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the fate of closed database connections?

[Fred Stluka]

  
  
Mike,

As of version 1.6, Django supports persistent DB connections
(connection pooling).  CONN_MAX_AGE specifies the number of
seconds that a connection will remain open and be reused.
You can set it to 0 to cause each DB interaction to open, use,
and close its own connection.  You can set it to None to allow
an unlimited number of connections.  See:
- https://docs.djangoproject.com/en/dev/ref/databases/

However, the behavior you're seeing doesn't seem to match this 
documented behavior.  I'd have expected CONN_MAX_AGE = 0
to prevent connections from being reused, so they should be 
closed at the end of the request that used them.  So, unless you
have 65 or more concurrent requests, you should not be hitting
your limit.  

I'm not surprised that CONN_MAX_AGE = None has an effect, but 
I wouldn't have been able to predict whether it makes things 
better or worse.  It allows Django to reuse connections so fewer
of them should be created, but it also allows Django to pool them 
for as long as it likes, so a large number of them may accumulate.

Have you tried any other values for CONN_MAX_AGE, like 1 or 2?

Also, are you using the Django development server?  The docs
linked above say:
    "The development server creates a new thread for each request 
 it handles, negating the effect of persistent connections. 
 Don’t enable them during development."

--Fred
  
  
  Fred Stluka -- mailto:f...@bristle.com --
  http://bristle.com/~fred/
  
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service!
  
  Open Source: Without walls and fences, we need no Windows or
  Gates.
  
  

On 1/17/17 2:25 PM, Michael Grundler
  wrote:


  

When Django
  closes a database
  connection at the end of a request/response cycle does that
  connection still maintain its hold on the database?


I ask because I
  am
  running an app on a spatialite (v4.3.0a) database, which, due
  to a
  limitation in the GEOS library (v3.6.1-CAPI-1.10.1 r0), can
  only accept a maximum of 64
  connections. When I configure Django so that CONN_MAX_AGE = 0,
  the
  server log will eventually begin filling up with messages that
  read
  "ERROR: Too many connections: max 64". If I enable
  persistent connections by setting CONN_MAX_AGE = None, these
  messages
  disappear. To me this suggests that when Django closes a
  connection
  at the end of a request/response cycle that connection
  persists
  from spatialite's perspective.


Is this
  expected behavior?


The error
  message is easily
  reproduced by starting a project configured to use spatialite,
  logging into the admin page, and then refreshing your browser
  repeatedly until 64 requests have been made.


Thanks for any
  insights,
Mike




  
  -- 
  You received this message because you are subscribed to the Google
  Groups "Django users" group.
  To unsubscribe from this group and stop receiving emails from it,
  send an email to django-users+unsubscr...@googlegroups.com.
  To post to this group, send email to django-users@googlegroups.com.
  Visit this group at https://groups.google.com/group/django-users.
  To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8b2d88c4-056c-4eeb-9dc9-7295f7ff0961%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6d7eefba-47ac-5a7c-a6b2-1bc38091f7e2%40bristle.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to make a queryset into a database, starting from a template html

[Fred Stluka]

  
  
Carlobo,

If you want the nation field to be given a value as soon as a 
a dialing prefix is entered, without posting the page to the web 
server and retrieving a new page, you're going to have to use 
_javascript_ and the perhaps the technique called Ajax.

Django and its Python code run only on the server, not in the 
browser.  So, it cannot fill in one field based on another, except
by posting the partially completed form to the server and having
it sent back with the one additional field filled in.  The 
disadvantages of this approach include:
- Slower than the approaches described below
- Harder to preserve the user's context in the Web page (which
   field had the keyboard focus, how far down the page was 
   scrolled, etc.)
- May place a heavier load on the server

If you want to use _javascript_, you can include the _javascript_ code
in an HTML 

What is the fate of closed database connections?

[Michael Grundler]

 

When Django closes a database connection at the end of a request/response 
cycle does that connection still maintain its hold on the database?


I ask because I am running an app on a spatialite (v4.3.0a) database, 
which, due to a limitation in the GEOS library (v3.6.1-CAPI-1.10.1 r0), can 
only accept a maximum of 64 connections. When I configure Django so that 
CONN_MAX_AGE = 0, the server log will eventually begin filling up with 
messages that read "ERROR: Too many connections: max 64". If I enable 
persistent connections by setting CONN_MAX_AGE = None, these messages 
disappear. To me this suggests that when Django closes a connection at the 
end of a request/response cycle that connection persists from spatialite's 
perspective.


Is this expected behavior?


The error message is easily reproduced by starting a project configured to 
use spatialite, logging into the admin page, and then refreshing your 
browser repeatedly until 64 requests have been made.


Thanks for any insights,

Mike



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8b2d88c4-056c-4eeb-9dc9-7295f7ff0961%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to make a queryset into a database, starting from a template html

[carlobo]

in a html template I receive some input to create a new record in a database
. One of these inputs is the international dialing prefix (such as +39 for 
Italy). In another field of the same template there is another input to 
enter the country. To facilitate the user would like, after entering the 
code, he appears already precompiled nation field with the result of the 
query to the table Nations where Nazioni.prefisso = area code entered in 
the field.
What procedure should I follow? is there any example?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9354d04d-7802-48a8-a9f5-4e1d28bd509a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Creating a sample poll app 2

[jorrit787]

Because you need to import the Question model from the models.py file 
before you can register it in the admin. "from .models import X" means 
"import X from the file models which is in the same directory as the 
current file".


On Tuesday, January 17, 2017 at 3:18:47 PM UTC+1, Rachit Tibrewal wrote:
>
> Why is '.models' in the documentation? 
> ##polls/admin.py 
> from django.contrib import admin 
>
> from .models import Question 
>
> admin.site.register(Question)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/dc818be1-8a20-46f5-9661-0cfb2585a763%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django admin raises CSRF verification failed when changing from DEBUG True - > False

[Juan Pedro Lipari]

I have the same problem

El miércoles, 20 de julio de 2016, 9:14:17 (UTC-3), Muhammed Riyas escribió:
>
> Hi All,
>
> I am having a difficulty with my Django site. In which I was running 
> smoothly in dubug mode(DEBUG = True). While changing it to DEBUG = False 
> (Also set ALLOWED_HOSTS = ['*']) , it raises error when logging in to admin 
> "
> Forbidden (403)
>
> CSRF verification failed. Request aborted.
> More information is available with DEBUG=True."
>
> I haven't set any value in CSRF_COOKIE_DOMAIN and CSRF_COOKIE_SECURE. 
>
> I couldn't find any information on log. What is the reason behind this.?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a1174e05-02e1-4605-b86c-f11035e3d73e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django search

[Branko Zivanovic]

Thank you for reply!

I'm fine with text input but I also want select menu and checkbox. I want 
to use it to somehow filter my search. 
I'm not sure how it fits anyway in bigger picture. How do people make 
search with select menu and checkbox?

Best,
Branko

понедељак, 16. јануар 2017. 07.13.44 UTC+1, Constantine Covtushenko је 
написао/ла:
>
> Hi Branco,
>
> Sorry, but can you be more specific?
> If you've got the result what is your concern?
> Do you only need to switch into forms?
>
> Regards,
> Constantine C.
>
> On Sun, Jan 15, 2017 at 2:41 PM, Branko Zivanovic  > wrote:
>
>> How do i implement search on django website with select menu and 
>> checkbox? I've succeeded in adding basic text input and it works but I 
>> didn't use django forms. How do I add this type of search?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/078841f1-a976-4c22-bb2f-ff5069bdce1d%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9fc70bbe-487d-4c4b-8f9a-77ad79281193%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Creating a sample poll app 2

[Rachit Tibrewal]

Why is '.models' in the documentation?
##polls/admin.py
from django.contrib import admin

from .models import Question

admin.site.register(Question)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/16c75d33-b488-44cf-9a68-1525534cd0f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

how to do ces monitoring on django application

[anjalimk68]

I want to do ces monitoring for my application. I got one module as statsd 
but that wasn't helpful.
Can anyone provide me suggestions how I can do that.

Thanks in advance,
Anjali

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7f89f222-be77-4410-8e0d-856ae4a0c02d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Projects vs. apps

[Antonis Christofides]

django.contrib.admin is an example of an app. You can use it in multiple
projects by specifying it in INSTALLED_APPS. apps that can be used in multiple
projects are typically pip-installable.

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com


On 01/17/2017 12:44 AM, Thufir Hawat wrote:
> Not sure that I follow:
>
> What’s the difference between a project and an app? An app is a Web
> application that does something – e.g., a Weblog system, a database of public
> records or a simple poll app. A project is a collection of configuration and
> apps for a particular website. A project can contain multiple apps. An app can
> be in multiple projects.
>
>
> How can an app be in multiple projects?  If someone would make that sentence
> more concrete that would be appreciated.
>
>
> thanks,
>
> Thufir
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1f4d9b14-7f57-4b4f-2ba6-1774aa5e1522%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.