I'm new to Mezzanine, trying to publish my first site using it 
(http://batistapeniel.org/).

I came here from a similar issue, when I realized that there are so many 
queries to 'django_site'. 

Since my site only have 1 domain and based on how current_site_id() works, I 
disabled all lookups by placing a simple middleware before all others that 
uses default settings.SITE_ID:


   1. from django.conf import settings
   2.  
   3. class FixedSiteID(object):
   4.     def process_request(self, request):
   5.         request.site_id = settings.SITE_ID
   

Best regards,

Em quinta-feira, 21 de março de 2013 23h57min53s UTC-3, Stephen McDonald 
escreveu:
>
> Well it would certainly break the case of people using multiple domains 
> against a single site record, so yeah I think this is some of the pain I 
> was thinking there might be.
>
> I guess all we can do is if a site can't be matched by domain, fall back 
> to the first site, or specifically the site defined by the SITE_ID setting, 
> which actually already happens here:
>
>
> https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/utils/sites.py#L54-L55
>
> The thing with that though is that it doesn't attach the site ID to the 
> request, so each site lookup continues to query the database. I guess we 
> could have the fallback to SITE_ID also attach the site ID to the request 
> so that there's still only a single DB query as is the case with a valid 
> domain.
>
> Can anyone think of any pitfalls this might trigger? I can't.
>
> On Fri, Mar 22, 2013 at 7:48 AM, Josh Cartmell 
> <[email protected]<javascript:>
> > wrote:
>
>> Do you think that would be redundant with the new ALLOWED_HOSTS Django 
>> setting?  Your whole site will already not work if a domain isn't found in 
>> ALLOWED_HOSTS.  There also might be use cases where you have two domains 
>> pointing at a site but don't want them to have separate site records.  For 
>> example a lot of times I'll initially have a dev domain pointed at a site 
>> so that I can show the client progress on a site, while in reality the 
>> Django site record already contains their live domain.
>>
>>
>> On Thu, Mar 21, 2013 at 12:39 PM, Stephen McDonald 
>> <[email protected]<javascript:>
>> > wrote:
>>
>>> That makes sense. You need to have a valid site record set up.
>>>
>>> I'm not sure if it would cause more pain than correctness, but it might 
>>> be worthwhile if we raise an exception if a valid domain isn't matched.
>>>
>>>
>>> On Fri, Mar 22, 2013 at 4:20 AM, irrelevance 
>>> <[email protected]<javascript:>
>>> > wrote:
>>>
>>>> I end up changing django_site table from this:
>>>>
>>>> id   domain                   name
>>>> 1    productionsite.com   SiteName
>>>>
>>>> to this:
>>>>
>>>> id   domain                name
>>>> 1     1 <http://productionsite.com/>27.0.0.1:8000    SiteName
>>>>
>>>> And after that repeating query disappeared.
>>>>
>>>> On Saturday, March 2, 2013 5:37:37 PM UTC+4, irrelevance wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> Im notices that one of my ORM queries produces queries like:
>>>>>
>>>>> SELECT `django_site`.`id`, `django_site`.`domain`, 
>>>>> `django_site`.`name` 
>>>>> FROM `django_site` WHERE `django_site`.`domain` LIKE '127.0.0.1:8000'
>>>>>
>>>>>
>>>>> Im figured it from django_debug_toolbar logs, and MySQL query logs, 
>>>>> using IDE debugger for executing suspicious query.
>>>>> Im running site from production server that I set up on Django 
>>>>> dev-server.
>>>>> Contents of 'django_site' table:
>>>>>
>>>>> id   domain                        name
>>>>> 1    productionsite.com    SiteNameAlias
>>>>>
>>>>> My m2m call is like item.categories.all(). And Im sure that problem 
>>>>> is just in that call code, because it cause spam queries in any 
>>>>> place, wherever it being called.
>>>>>
>>>>> Actual code that produce query is get_query_set() method of 
>>>>> CurrentSiteManager 
>>>>> class in mezanine.core.managers module:
>>>>>
>>>>> def get_query_set(self):
>>>>>         if not self.__is_validated:
>>>>>             self._validate_field_name()
>>>>>         lookup = {self.__field_name + "__id__exact": current_site_id()}
>>>>>         return super(DjangoCSM, self).get_query_set().filter(**lookup)
>>>>>
>>>>>
>>>>> on 'lookup ='  code exectuion goes in mezzanine.utils.sites module in 
>>>>> current_site_id() function:
>>>>>
>>>>> from mezzanine.utils.cache import cache_installed, cache_get, cache_set
>>>>>     request = current_request()
>>>>>     site_id = getattr(request, "site_id", None)
>>>>>     if request and not site_id:
>>>>>         site_id = request.session.get("site_id", None)
>>>>>         if not site_id:
>>>>>             domain = request.get_host().lower()
>>>>>             if cache_installed():
>>>>>                 # Don't use Mezzanine's cache_key_prefix here, since it
>>>>>                 # uses this very function we're in right now to create 
>>>>> a
>>>>>                 # per-site cache key.
>>>>>                 cache_key = settings.CACHE_MIDDLEWARE_KEY_PREFIX + 
>>>>> ".site_id"
>>>>>                 site_id = cache_get(cache_key)
>>>>>             if not site_id:
>>>>>                 try:
>>>>>                     site = Site.objects.get(domain__iexact=domain)
>>>>>                 except Site.DoesNotExist:
>>>>>                     pass
>>>>>                 else:
>>>>>                     site_id = site.id
>>>>>                     if cache_installed():
>>>>>                         cache_set(cache_key, site_id)
>>>>>         if request and site_id:
>>>>>             request.site_id = site_id
>>>>>     if not site_id:
>>>>>         site_id = os.environ.get("MEZZANINE_SITE_ID", 
>>>>> settings.SITE_ID)
>>>>>     return site_id
>>>>>
>>>>>
>>>>> And that call - 'site = Site.objects.get(domain__iexact=domain)' 
>>>>> produces spam query.
>>>>>
>>>>> Im sure that Im missed somewhat setting in Mezzanine or Django, and 
>>>>> that cause that Mezz everytime tries quering DB to get 'site_id'. 
>>>>> Im using Mezzanine 1.2.3
>>>>> Im new to Mezzanine and code I dealing with is legacy. 
>>>>> Also I can provide any additional information about setup and 
>>>>> execution if needed.
>>>>>
>>>>> Kindly help :)
>>>>>
>>>>  -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Mezzanine Users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected] <javascript:>.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>  
>>>>  
>>>>
>>>
>>>
>>>
>>> -- 
>>> Stephen McDonald
>>> http://jupo.org 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Mezzanine Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected] <javascript:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mezzanine Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> Stephen McDonald
> http://jupo.org 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to