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.py:
from django.dispatch import receiver
from django.db.backends.signals import connection_created
from .page import factory as pageFactory
from .api import APIFactory
@receiver(connection_created, dispatch_uid="dbConnectionInitiated")
def prepareSQL(sender, **kwargs):
pageFactory.prepare_db_queries()
APIFactory.prepare_db_queries()
pass
My FastDetailView class is a subclass of factory , and this is where
prepare_db_queries happens.
I also have separate code that loads in Javascript into this FastDetailView
class.
Basically I don’t read html from the template at all during the
Request/Response cycle. I instead pre-load all my DB Queries and Javascript.
(This whole process helps speed up the view response generation times. I can
generate a full page in about 4ms, and that includes GZip.)
-bobby
> On Jan 4, 2017, at 4:17 PM, Tim Graham <[email protected]> wrote:
>
> 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 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/latestCollections',
> 'include/sql/materializedviews/allSeasons',
> 'include/sql/materializedviews/fullSeason',
> 'include/sql/materializedviews/gallery',
> 'include/sql/materializedviews/indexView',
> 'include/sql/materializedviews/cover',
> 'include/sql/materializedviews/latestSeasonView',
> 'include/sql/materializedviews/seasonView',
> 'include/sql/materializedviews/collectionView',
> 'include/sql/materializedviews/latestCollectionsJSON',
> 'include/sql/materializedviews/collectionCardJSON',
> 'include/sql/materializedviews/indexJSON',
> 'include/sql/materializedviews/categoryJSON',
> 'include/sql/materializedviews/articleJSON',
> 'include/sql/triggers/globals',
> 'include/sql/triggers/brand',
> 'include/sql/triggers/collection',
> 'include/sql/triggers/collectionlookassignment',
> 'include/sql/triggers/cover',
> 'include/sql/triggers/look',
> 'include/sql/triggers/photo',
> 'include/sql/triggers/season',
> 'include/sql/triggers/fashion_headlinesviewmat',
> 'include/sql/triggers/fashion_latestcollectionsviewmat',
> 'include/sql/triggers/fashion_allseasonsviewmat',
> 'include/sql/triggers/fashion_fullseasonviewmat',
> 'include/sql/triggers/fashion_galleryviewmat',
> 'include/sql/triggers/fashion_coverviewmat',
> 'include/sql/triggers/fashion_indexviewmat',
> 'include/sql/triggers/fashion_latestseasonviewmat',
> 'include/sql/triggers/fashion_seasonviewmat',
> 'include/sql/triggers/fashion_collectionviewmat',
> 'include/sql/triggers/fashion_collectioncardjsonviewmat',
> ),
> 'analytics': (
> 'include/sql/analytics',
> ),
> }
>
> MATERIALIZED_VIEWS = True
>
> @classmethod
> def prepare_db_queries(self):
> logger.info <http://logger.info/>('Reading fashion prepared SQL
> statements')
> cursor = connection.cursor()
> for sql_view_dir in SQL_VIEW_DIRS['fashion']:
> file_name = sql_view_dir + '/prepare.sql'
> try:
> with open(file_name, 'r') as file:
> sql_prepare=file.read().strip()
> if sql_prepare:
> cursor.execute(sql_prepare)
> except (OSError, IOError) as e:
> pass
> except e:
> logger.info <http://logger.info/>('Error reading SQL file:
> %s' % file_name)
> raise e
> if MATERIALIZED_VIEWS:
> file_name = sql_view_dir + '/prepare_materialized.sql'
> try:
> with open(file_name, 'r') as file:
> sql_prepare=file.read().strip()
> if sql_prepare:
> cursor.execute(sql_prepare)
> except (OSError, IOError) as e:
> pass
> except e:
> logger.info <http://logger.info/>('Error reading SQL
> file: %s' % file_name)
> raise e
>
>
> It’s a custom view class that basically reads SQL from a separate list of
> files on initialization, and executes those SQL files.
>
> If I edit these SQL files, it won't restart the development server.
>
> -bobby
>
>> On Jan 4, 2017, at 4:03 PM, Tim Graham <timog...@ <>gmail.com
>> <http://gmail.com/>> wrote:
>>
>> 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 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 in separate SQL &
>> Javascript files. (I don’t use the template system.)
>>
>> If I edit these Javascript & SQL files, the Django server doesn’t
>> autoreload.
>>
>> So, I made a pull-request where we can add a manual list of files to track
>> for autoreload: https://github.com/django/django/pull/7791
>> <https://github.com/django/django/pull/7791>
>>
>> In your project's settings.py file, assign a variable TRACK_FILES containing
>> a list of full file paths to track. This will track files to autoreload the
>> development run server as these files are updated.
>>
>> Is this OK? This pull request is a basic option and I’m sure it can get
>> more complicated than that (directory tracking, Makefiles, Javscript builds,
>> etc..)
>>
>> -bobby
>>
>> --
>> 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 <http://googlegroups.com/>.
>> To post to this group, send email to django-d...@ <>googlegroups.com
>> <http://googlegroups.com/>.
>> Visit this group at https://groups.google.com/group/django-developers
>> <https://groups.google.com/group/django-developers>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/c857c334-6388-4e10-8367-ffbee08acc10%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-developers/c857c334-6388-4e10-8367-ffbee08acc10%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> For more options, visit https://groups.google.com/d/optout
>> <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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/django-developers
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ceaf7dcc-7cf1-42e1-be76-a528d394da63%40googlegroups.com
>
> <https://groups.google.com/d/msgid/django-developers/ceaf7dcc-7cf1-42e1-be76-a528d394da63%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <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 [email protected].
To post to this group, send email to [email protected].
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/4A776CD1-68D8-4DEB-8BFF-BBEB4AE9F329%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
