Earlier this year

• Feb 28, 2009

  issue 10 (Italian locale) Status changed by leidel   -   Thanks!

  Status: Fixed

  Thanks!

  Status: Fixed
• Feb 28, 2009

  issue 11 ("Templates" doesn't show up in admin when egg is zipped) Status changed by leidel   -   Changed setup.py to use setuptools because it has a with zip_safe attribute which prevents creating zipped installations.

  Status: Fixed

  Changed setup.py to use setuptools because it has a with zip_safe attribute which prevents creating zipped installations.

  Status: Fixed
• Feb 04, 2009

  issue 11 ("Templates" doesn't show up in admin when egg is zipped) commented on by ryates100   -   This is a Django core bug with admin.autodiscover() http://code.djangoproject.com/ticket/9427

  This is a Django core bug with admin.autodiscover() http://code.djangoproject.com/ticket/9427
• Feb 04, 2009

  issue 11 ("Templates" doesn't show up in admin when egg is zipped) commented on by corpuanalytics   -   This is a core Django bug with admin.autodiscover(): http://code.djangoproject.com/ticket/9427

  This is a core Django bug with admin.autodiscover(): http://code.djangoproject.com/ticket/9427
• Jan 23, 2009

  issue 11 ("Templates" doesn't show up in admin when egg is zipped) commented on by d...@brondsema.net   -   The admin section where administrators can add/edit the templates. I think the admin autodiscovery didn't find dbtemplates' admin.py file since it was zipped up and not actually in the filesyste

  The admin section where administrators can add/edit the templates. I think the admin autodiscovery didn't find dbtemplates' admin.py file since it was zipped up and not actually in the filesyste
• Jan 23, 2009

  issue 11 ("Templates" doesn't show up in admin when egg is zipped) commented on by brondsem   -   The admin section where administrators can add/edit the templates. I think the admin autodiscovery didn't find dbtemplates' admin.py file since it was zipped up and not actually in the filesystem.

  The admin section where administrators can add/edit the templates. I think the admin autodiscovery didn't find dbtemplates' admin.py file since it was zipped up and not actually in the filesystem.
• Jan 23, 2009

  issue 11 ("Templates" doesn't show up in admin when egg is zipped) Status changed by leidel   -   Interesting, do you mean the admin section of the Template model or the the created templates could not be loaded?

  Status: Accepted

  Interesting, do you mean the admin section of the Template model or the the created templates could not be loaded?

  Status: Accepted
• Jan 23, 2009

  issue 11 ("Templates" doesn't show up in admin when egg is zipped) reported by d...@brondsema.net   -   What steps will reproduce the problem? 1. easy_install -z django-dbtemplates 2. regular setup 3. go to /admin What is the expected output? What do you see instead? Templates don't show up. I understand this is probably more a django issue than a dbtemplates issue, but you can easily work around the problem by running "easy_install -Z django-dbtemplates" I'd recommend changing the dbtemplates docs to have the -Z flag easy_install is mentioned. Thanks!

  What steps will reproduce the problem? 1. easy_install -z django-dbtemplates 2. regular setup 3. go to /admin What is the expected output? What do you see instead? Templates don't show up. I understand this is probably more a django issue than a dbtemplates issue, but you can easily work around the problem by running "easy_install -Z django-dbtemplates" I'd recommend changing the dbtemplates docs to have the -Z flag easy_install is mentioned. Thanks!
• Jan 21, 2009

  issue 10 (Italian locale) reported by marcoberi   -   Bravo!!! Great tool! :-)

  Bravo!!! Great tool! :-)
• Jan 21, 2009

  r93 (Removed superfluous imports) committed by leidel   -   Removed superfluous imports

  Removed superfluous imports
• Jan 21, 2009

  r92 (Fix typo) committed by leidel   -   Fix typo

  Fix typo
• Jan 21, 2009

  r91 (Look in INSTALLED_APPS to find out if django-reversion is in...) committed by leidel   -   Look in INSTALLED_APPS to find out if django-reversion is installed

  Look in INSTALLED_APPS to find out if django-reversion is installed
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by n.leush   -   Thank you. It would be easer to make changes on my side.

  Thank you. It would be easer to make changes on my side.
• Jan 03, 2009

  issue 9 (Save and remove signals doesn't take to account template sit...) commented on by n.leush   -   I see... But in this case altering settings is not a bug reason. I clearly can see add_template_to_cache and remove_cached_template works incorrect when saving template for some another "Site" which differs from current. Let's see an example - I have one db for two same sites which are different django instances. Is this normal? I can save template for "another" site while working with current. And I'll get cached template from another site for current site. If this is not a normal situation (when to sites are in one db) - then why to store "sites" field in db-template? This is just a bug after bug (http://code.google.com/p/django-dbtemplates/issues/detail?id=6). My solution of issue 6 was very easy but not correct generally considering model's signals cache access. Sorry for this miss take, I just wanted to correct it...

  I see... But in this case altering settings is not a bug reason. I clearly can see add_template_to_cache and remove_cached_template works incorrect when saving template for some another "Site" which differs from current. Let's see an example - I have one db for two same sites which are different django instances. Is this normal? I can save template for "another" site while working with current. And I'll get cached template from another site for current site. If this is not a normal situation (when to sites are in one db) - then why to store "sites" field in db-template? This is just a bug after bug (http://code.google.com/p/django-dbtemplates/issues/detail?id=6). My solution of issue 6 was very easy but not correct generally considering model's signals cache access. Sorry for this miss take, I just wanted to correct it...
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by leidel   -   Well, you can write your own backend, just subclass dbtemplates.cache.BaseCacheBackend and provide the required methods. You can then set the DBTEMPLATES_CACHE_BACKEND setting to the dotted path of your cache backend, e.g. myproject.cache.SmartSiteAwareBackend. The question is if there is something on my side that'd help you to do that.

  Well, you can write your own backend, just subclass dbtemplates.cache.BaseCacheBackend and provide the required methods. You can then set the DBTEMPLATES_CACHE_BACKEND setting to the dotted path of your cache backend, e.g. myproject.cache.SmartSiteAwareBackend. The question is if there is something on my side that'd help you to do that.
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by n.leush   -   Actually i don't know how to make it easier... Maybe more smart cache backend with option whether to save or not unexisting templates. So backend decides to save it or not. It would be more correct and flexible as for me. But it's up to you to decide if such feature reasonable to implement.

  Actually i don't know how to make it easier... Maybe more smart cache backend with option whether to save or not unexisting templates. So backend decides to save it or not. It would be more correct and flexible as for me. But it's up to you to decide if such feature reasonable to implement.
• Jan 03, 2009

  issue 9 (Save and remove signals doesn't take to account template sit...) Status changed by leidel   -   Of course nobody forbids you to change the Site dynamically but it's clearly not recommended: http://docs.djangoproject.com/en/dev/topics/settings/#altering-settings-at-runtime Even though there is another nice approach which hopefully will land in Django (http://code.djangoproject.com/ticket/4438) dbtemplates won't support unofficial features because that's not what people expect if they follow the documentation and official operation of Django. You basically redefined what a "Site" is to support hierarchical virtual hosts. That's way out of scope of this app.

  Status: WontFix

  Of course nobody forbids you to change the Site dynamically but it's clearly not recommended: http://docs.djangoproject.com/en/dev/topics/settings/#altering-settings-at-runtime Even though there is another nice approach which hopefully will land in Django (http://code.djangoproject.com/ticket/4438) dbtemplates won't support unofficial features because that's not what people expect if they follow the documentation and official operation of Django. You basically redefined what a "Site" is to support hierarchical virtual hosts. That's way out of scope of this app.

  Status: WontFix
• Jan 03, 2009

  Source (Use the source, Luke.) Wiki page added by leidel
• Jan 03, 2009

  issue 9 (Save and remove signals doesn't take to account template sit...) commented on by n.leush   -   My application switches between "Site"s dynamically in special middleware. Nothing forbids me to do this. And i have main site and subsites. Admin app works in main site. So when i save template for subsite - cache writes this template for main site. Considering I use templates with same names for main and subsites - i have bug, because main site loads cached template created for subsite.

  My application switches between "Site"s dynamically in special middleware. Nothing forbids me to do this. And i have main site and subsites. Admin app works in main site. So when i save template for subsite - cache writes this template for main site. Considering I use templates with same names for main and subsites - i have bug, because main site loads cached template created for subsite.
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by leidel   -   I wonder if there could be a way to provide a hook to make it easier for you. Do you have a suggestion?

  I wonder if there could be a way to provide a hook to make it easier for you. Do you have a suggestion?
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by n.leush   -   You are right. I use it as primary loader. Maybe this feature should be optional... for such cases. Nevertheless if nobody else asks for it - it will be my personal customization.

  You are right. I use it as primary loader. Maybe this feature should be optional... for such cases. Nevertheless if nobody else asks for it - it will be my personal customization.
• Jan 03, 2009

  issue 9 (Save and remove signals doesn't take to account template sit...) commented on by leidel   -   The SITE_ID settings defines which "Site" a Django process serves. Hence it's perfectly fine to let every Django instance create or remove the cache of a template itself. Passing the template object to the backend could solve that problem, yes. But you want to have as much separation between the different Django instances as possible, e.g. no interference between the cache operation of example.com and example.org.

  The SITE_ID settings defines which "Site" a Django process serves. Hence it's perfectly fine to let every Django instance create or remove the cache of a template itself. Passing the template object to the backend could solve that problem, yes. But you want to have as much separation between the different Django instances as possible, e.g. no interference between the cache operation of example.com and example.org.
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) Status changed by leidel   -   I see. Now that I know what you are actually trying to do, I'm convinced to not support it. It's just an edge case that nobody will use except you and confuse a lot of people who don't understand it. For example the file system cache backend will create a lot of files containing "False". That's not useful. Also, if I understand correctly, you use the "dbtemplates.loader.load_template_source" at the top of your TEMPLATE_LOADERS settings which tells Django to use dbtemplates first, even before the regular template loaders. That's not recommended. dbtemplates is not a replacement for the other template loaders but a supplement.

  Status: WontFix

  I see. Now that I know what you are actually trying to do, I'm convinced to not support it. It's just an edge case that nobody will use except you and confuse a lot of people who don't understand it. For example the file system cache backend will create a lot of files containing "False". That's not useful. Also, if I understand correctly, you use the "dbtemplates.loader.load_template_source" at the top of your TEMPLATE_LOADERS settings which tells Django to use dbtemplates first, even before the regular template loaders. That's not recommended. dbtemplates is not a replacement for the other template loaders but a supplement.

  Status: WontFix
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by n.leush   -   > Besides I'm not convinced of the effectiveness of that measure. How many templates do you use per request? In my case I have near 60 templates in page. All tamplates are in files, but in case of personal user site customization - it can be stored in database. So db-templates application tries to load all templates each request, when I need actually to customize 2-3 of them.

  > Besides I'm not convinced of the effectiveness of that measure. How many templates do you use per request? In my case I have near 60 templates in page. All tamplates are in files, but in case of personal user site customization - it can be stored in database. So db-templates application tries to load all templates each request, when I need actually to customize 2-3 of them.
• Jan 03, 2009

  issue 9 (Save and remove signals doesn't take to account template sit...) reported by n.leush   -   When signal works - template is cached to current site, not for sites of template. Here is how i solved this. It's ugly... but works. I think maybe cache backend should accept whole template object to do this work incapsulated. def add_template_to_cache(instance, **kwargs): """ Called via Django's signals to cache the templates, if the template in the database was added or changed. """ SITE_ID = settings.SITE_ID for site in instance.sites.all(): settings.SITE_ID = site.pk backend.save(instance.name, instance.content) settings.SITE_ID = SITE_ID def remove_cached_template(instance, **kwargs): """ Called via Django's signals to remove cached templates, if the template in the database was changed or deleted. """ SITE_ID = settings.SITE_ID for site in instance.sites.all(): settings.SITE_ID = site.pk backend.remove(instance.name) settings.SITE_ID = SITE_ID

  When signal works - template is cached to current site, not for sites of template. Here is how i solved this. It's ugly... but works. I think maybe cache backend should accept whole template object to do this work incapsulated. def add_template_to_cache(instance, **kwargs): """ Called via Django's signals to cache the templates, if the template in the database was added or changed. """ SITE_ID = settings.SITE_ID for site in instance.sites.all(): settings.SITE_ID = site.pk backend.save(instance.name, instance.content) settings.SITE_ID = SITE_ID def remove_cached_template(instance, **kwargs): """ Called via Django's signals to remove cached templates, if the template in the database was changed or deleted. """ SITE_ID = settings.SITE_ID for site in instance.sites.all(): settings.SITE_ID = site.pk backend.remove(instance.name) settings.SITE_ID = SITE_ID
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by n.leush   -   Here is a diff patch.

  Here is a diff patch.
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by leidel   -   Please post a diff of your changes so I see what changed and can apply cleanly. Although I understand what you want to achieve I don't think the cache should carry information if a template is available in the database or not. Depending on the used backend it could fail for various reasons that would make looking for the cause of a TemplateDoesNotExist error very frustrating. Besides I'm not convinced of the effectiveness of that measure. How many templates do you use per request?

  Please post a diff of your changes so I see what changed and can apply cleanly. Although I understand what you want to achieve I don't think the cache should carry information if a template is available in the database or not. Depending on the used backend it could fail for various reasons that would make looking for the cause of a TemplateDoesNotExist error very frustrating. Besides I'm not convinced of the effectiveness of that measure. How many templates do you use per request?
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) commented on by n.leush   -   I've already posted my solution in http://code.google.com/p/django-dbtemplates/issues/detail?id=5&can=1#c2. Wnen template doesn't exists "False" is cached. So next time while reading template from cache we can get "None" (which means template should be read and cached) or "False" (wich means no template was found in db previously). When user will create template in admin - post_save signal will override cache record. As for me its suitable. Is it bad solution?

  I've already posted my solution in http://code.google.com/p/django-dbtemplates/issues/detail?id=5&can=1#c2. Wnen template doesn't exists "False" is cached. So next time while reading template from cache we can get "None" (which means template should be read and cached) or "False" (wich means no template was found in db previously). When user will create template in admin - post_save signal will override cache record. As for me its suitable. Is it bad solution?
• Jan 03, 2009

  issue 7 (Cache unexisting db teampltes entries) changed by leidel   -   I'm not really sure how that could work without overengineering it. I'm open for suggestions though.

  Owner: leidel

  Labels: Type-Enhancement −Type-Defect

  I'm not really sure how that could work without overengineering it. I'm open for suggestions though.

  Owner: leidel

  Labels: Type-Enhancement −Type-Defect
• Jan 03, 2009

  issue 8 (Add "sites" column in admin list display.) Status changed by leidel   -   Fixed in r89.

  Status: Fixed

  Fixed in r89.

  Status: Fixed
• Jan 03, 2009

  r89 (Added a list to the admin list view that contains all site n...) committed by leidel   -   Added a list to the admin list view that contains all site names that the template is used on.

  Added a list to the admin list view that contains all site names that the template is used on.
• Jan 02, 2009

  issue 8 (Add "sites" column in admin list display.) reported by n.leush   -   When same templates are used in different sites - its impossible to understand to which site belongs template in admin's list view.

  When same templates are used in different sites - its impossible to understand to which site belongs template in admin's list view.
• Jan 02, 2009

  issue 7 (Cache unexisting db teampltes entries) reported by n.leush   -   It would be nice optimization to cache whether template exists in database.

  It would be nice optimization to cache whether template exists in database.

Older

• Dec 28, 2008

  issue 5 (Dynamically save the templates to cache) commented on by n.leush   -   Why saving bad state isn't good idea? If new template will be created it will rewrite existing cache entry. So it's not a problem. Without this option I have hundred failed queries per request (many templates used). Or maybe new issue required in this case?

  Why saving bad state isn't good idea? If new template will be created it will rewrite existing cache entry. So it's not a problem. Without this option I have hundred failed queries per request (many templates used). Or maybe new issue required in this case?
• Dec 26, 2008

  issue 5 (Dynamically save the templates to cache) Status changed by leidel   -   I fixed the original issue in r88. I don't think saving the bad state of a template to the cache is a good idea. So the issue of n.leush won't be fixed in the future, too.

  Status: Fixed

  I fixed the original issue in r88. I don't think saving the bad state of a template to the cache is a good idea. So the issue of n.leush won't be fixed in the future, too.

  Status: Fixed
• Dec 26, 2008

  issue 6 (Cache backend doesn't save SITE_ID) Status changed by leidel   -  

  Status: Fixed

  Status: Fixed
• Dec 26, 2008

  issue 6 (Cache backend doesn't save SITE_ID) commented on by leidel   -   Fixed in r88. Thanks!

  Fixed in r88. Thanks!
• Dec 26, 2008

  r88 (Made loader and cache backends site-aware. The filesystem ca...) committed by leidel   -   Made loader and cache backends site-aware. The filesystem cache backend now saves the files under <dir>/<site_domain>/<file_name>. The Django cache backend the Site id in the cache key. Template is now saved explicitly to backend if not existent in cache (e.g. if deleted manually or invalidated). Bumped version to 0.5.4.

  Made loader and cache backends site-aware. The filesystem cache backend now saves the files under <dir>/<site_domain>/<file_name>. The Django cache backend the Site id in the cache key. Template is now saved explicitly to backend if not existent in cache (e.g. if deleted manually or invalidated). Bumped version to 0.5.4.
• Dec 26, 2008

  issue 6 (Cache backend doesn't save SITE_ID) Status changed by leidel   -  

  Status: Accepted

  Status: Accepted
• Dec 21, 2008

  issue 5 (Dynamically save the templates to cache) commented on by n.leush   -   Besides I propose to save to cache absent templates. So if loader try to load template wich doesn't exists in database it should write to cache this information to prevent further same useless operations. My tested solution in attachment.

  Besides I propose to save to cache absent templates. So if loader try to load template wich doesn't exists in database it should write to cache this information to prevent further same useless operations. My tested solution in attachment.
• Dec 21, 2008

  issue 6 (Cache backend doesn't save SITE_ID) reported by n.leush   -   What steps will reproduce the problem? 1. Create templates for different Sites. 2. Write middleware wich dynamically swithces SITE_ID. 3. Wrong templates loading for current Site from cache. Example working solution: class DjangoCacheBackend(BaseCacheBackend): """ A cache backend that uses Django's cache mechanism. """ def _cache_key(self, name): return 'dbtemplates::%s::%s' % (name, settings.SITE_ID)

  What steps will reproduce the problem? 1. Create templates for different Sites. 2. Write middleware wich dynamically swithces SITE_ID. 3. Wrong templates loading for current Site from cache. Example working solution: class DjangoCacheBackend(BaseCacheBackend): """ A cache backend that uses Django's cache mechanism. """ def _cache_key(self, name): return 'dbtemplates::%s::%s' % (name, settings.SITE_ID)
• Dec 21, 2008

  issue 5 (Dynamically save the templates to cache) commented on by n.leush   -   Same solution helps for me.

  Same solution helps for me.
• Dec 16, 2008

  issue 5 (Dynamically save the templates to cache) reported by m.rem...@webmasters.de   -   What steps will reproduce the problem? 1. Activate template caching (no matter which one) 2. Edit a template and save it 3. Manually delete the cached item, or wait for garbage collection when using django cache 4. Load a page, that uses this template What is the expected output? What do you see instead? I would expect, that the template is loaded once from db and then put into the cache again. Instead it is loaded on every request again, as the cache is filled only when the template is saved again. Please provide any additional information below. A small change to loader.py could solve the problem: try: template = Template.objects.get(name__exact=template_name, sites__pk=settings.SITE_ID) backend.save(template_name, template.content) <--- NEW return (template.content, display_name) except: pass raise TemplateDoesNotExist, template_name

  What steps will reproduce the problem? 1. Activate template caching (no matter which one) 2. Edit a template and save it 3. Manually delete the cached item, or wait for garbage collection when using django cache 4. Load a page, that uses this template What is the expected output? What do you see instead? I would expect, that the template is loaded once from db and then put into the cache again. Instead it is loaded on every request again, as the cache is filled only when the template is saved again. Please provide any additional information below. A small change to loader.py could solve the problem: try: template = Template.objects.get(name__exact=template_name, sites__pk=settings.SITE_ID) backend.save(template_name, template.content) <--- NEW return (template.content, display_name) except: pass raise TemplateDoesNotExist, template_name
• Nov 29, 2008

  r87 (Small change to fix download from Github.) committed by leidel   -   Small change to fix download from Github.

  Small change to fix download from Github.
• Nov 28, 2008

  r86 (Removed hg cruft) committed by leidel   -   Removed hg cruft

  Removed hg cruft
• Nov 28, 2008

  r85 (Changed wrong link in docs) committed by leidel   -   Changed wrong link in docs

  Changed wrong link in docs
• Nov 28, 2008

  r84 (Removed automatic creation of 404.html and 500.html template...) committed by leidel   -   Removed automatic creation of 404.html and 500.html templates and added a new management command for those cases called "create_error_templates". Also made reverted move to Bitbucket.

  Removed automatic creation of 404.html and 500.html templates and added a new management command for those cases called "create_error_templates". Also made reverted move to Bitbucket.
• Nov 21, 2008

  r83 (Added hooks for __version__) committed by leidel   -   Added hooks for __version__

  Added hooks for __version__
• Nov 21, 2008

  r82 (Small change in the description) committed by leidel   -   Small change in the description

  Small change in the description
• Nov 21, 2008

  r81 (Added tag v0.5.2 for changeset c2ddc104f0da) committed by leidel   -   Added tag v0.5.2 for changeset c2ddc104f0da

  Added tag v0.5.2 for changeset c2ddc104f0da