On Thursday, January 5, 2017 at 11:14:08 PM UTC+1, Josh Smeaton wrote:
>
> > I am -0 to -1 for the debugger -- I've seen to many sites out there
> running with DEBUG=True, enabling RCE ootb seems to be pretty horrible.
>
> But it's so incredibly useful. And we already show the django debug page
> I am -0 to -1 for the debugger -- I've seen to many sites out there
running with DEBUG=True, enabling RCE ootb seems to be pretty horrible.
But it's so incredibly useful. And we already show the django debug page
for errors with DEBUG=True that exposes enough secrets to allow a
sufficient att
I’m -0 on the change. I could move to +0 if I understood why the use
case described here requires watching additional files.
A different use case we've run into is non-python configuration files.
Our settings.py reads a few variables off a toml file and it would be
nice if we could configure r
On Thu, Jan 5, 2017 at 8:06 AM Florian Apolloner
wrote:
>
>
> On Thursday, January 5, 2017 at 1:38:44 PM UTC+1, Sam Willis wrote:
>
> Could one options be to replace the current devserver with the one from
> Werkzeug? It already uses watchdog (similar to watchman) for monitoring
> file system eve
On Thursday, January 5, 2017 at 1:38:44 PM UTC+1, Sam Willis wrote:
>
> Could one options be to replace the current devserver with the one from
> Werkzeug? It already uses watchdog (similar to watchman) for monitoring
> file system events and is well maintained. With Django now allowing
> depe
Could one options be to replace the current devserver with the one from
Werkzeug? It already uses watchdog (similar to watchman) for monitoring
file system events and is well maintained. With Django now allowing
dependancies, this seems like something that doesn't necessarily need to be
develop
On 4 Jan 2017, at 23:31, Bobby Mozumder wrote:
> I guess I could just use Watchman to restart the Django development server as
> needed?
If you find a way to tell watchman to run `django-admin runserver --noreload`
and restart it whenever a file in the current directory changes, that should d
No, there's a cached template
loader:
https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.loaders.cached.Loader
On Wednesday, January 4, 2017 at 7:00:31 PM UTC-5, Bobby Mozumder wrote:
>
>
> On Jan 4, 2017, at 5:40 PM, Adam Johnson >
> wrote:
>
> How do people serve develop
> On Jan 4, 2017, at 5:40 PM, Adam Johnson wrote:
>
> How do people serve development Javascript & CSS files? These days
> Javascript & CSS involves a large build process. Are we forced to manually
> restart the development server every time Javascript changes?
>
> Django just serves them f
>
> How do people serve development Javascript & CSS files? These days
> Javascript & CSS involves a large build process. Are we forced to manually
> restart the development server every time Javascript changes?
Django just serves them from the filesystem, and doesn't cache them itself.
You rel
> On Jan 4, 2017, at 4:47 PM, Aymeric Augustin
> wrote:
>
> Hello Bobby,
>
>> On 4 Jan 2017, at 22:25, Bobby Mozumder wrote:
>>
>> It’s actually called once on app startup during DB connection via a Signal.
>
> Unless I missed something, since the development server creates a new
> connect
Hello Bobby,
> On 4 Jan 2017, at 22:25, Bobby Mozumder wrote:
>
> It’s actually called once on app startup during DB connection via a Signal.
Unless I missed something, since the development server creates a new
connection to the database for each request — Python’s threaded socket server
cre
That’ll make development server access times really slow. There’s a pretty
long Makefile also that builds Javascript. We really shouldn’t have to rebuild
Javascript on every page view, especially since I call interactive API requests
with these views.
-bobby
> On Jan 4, 2017, at 4:18 PM, Ada
It’s actually called once on app startup during DB connection via a Signal.
Here is my app.py:
from django.apps import AppConfig
from .signals import *
from django.utils import autoreload
class FashionAppConfig(AppConfig):
name = 'fashion'
verbose_name = "Fashion"
And here is my signals
For that use case I'd suggest just re-executing prepare_db_queries on every
page view when DEBUG=True. This is similar to how Django's template loaders
work without the cached loader wrapping them.
On 4 January 2017 at 21:12, Bobby Mozumder wrote:
> OK here is some example code snippet where I l
When is prepare_db_queries() called? During a request/response cycle? I
doesn't look like any caching is happening so I still doesn't see why the
server needs to restart to pickup changes to the SQL files.
On Wednesday, January 4, 2017 at 4:12:27 PM UTC-5, Bobby Mozumder wrote:
>
> OK here is so
OK here is some example code snippet where I load prepared SQL statements:
class FastDetailView(DetailView,FastView):
c = connection.cursor()
SQL_VIEW_DIRS = {
'fashion': (
'include/sql/materializedviews/headlines',
'include/sql/materializedviews/latestCo
Could you give us a code snippet (sample view, perhaps) demonstrating how
this caching happens?
On Wednesday, January 4, 2017 at 3:57:31 PM UTC-5, Bobby Mozumder wrote:
>
> Hi,
>
> Right now, Django only tracks Python module files for autoreload during
> development. As a project starts to incl
Hi,
Right now, Django only tracks Python module files for autoreload during
development. As a project starts to include more custom include files, such as
Javascript, SQL, Makefiles, etc.., the autoreload function doesn't apply to
these.
For my use case, I have custom view functions that call
19 matches
Mail list logo
