Re: Using the Django development server for local subdomain development
It's actually quite easy to test a subdomain setup with the run server and any
web server like Apache or nginx.
I'm commonly using nginx to do this, plus a few entries in my /etc/hosts file:
127.0.0.1 some.domain.localhost
127.0.0.1 other.domain.localhost
And the nginx configuration works like this:
upstream runserver {
server 127.0.0.1:8000;
}
server {
listen 80;
server_name some.domain.localhost
other.domain.localhost;
access_log /usr/local/var/log/nginx/domain.access.log main;
error_log /usr/local/var/log/nginx/domain.error.log;
root/Users/you/Site/domain;
proxy_set_header Host$host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
location / {
try_files $uri @django;
}
location @django {
proxy_pass $scheme://runserver;
}
}
That's it.
Cheers, Fabian
On 27.01.2013, at 02:27, Russell Keith-Magee wrote:
>
> The best approach I've found is to use xip.io. xip.io is a service that is
> actually provided by the 37 Signals guys, but it works for any web project
> (not just Rails). I'll honour a good idea wherever it comes from.
>
> It's a DNS server with unusual behaviour: If you prepend an IP address to the
> start of .xip.io, it will return that IP address as the resolved IP for the
> domain.
>
> So - if you set your server running on 127.0.0.1:8000, but point your browser
> at http://127.0.0.1.xip.io:8000, it will resolve to 127.0.0.1.
>
> Then, you can use your subdomain; bob.127.0.0.1.xip.io:8000 will resolve to
> your development server, but with a request header that tells you the
> subdomain.
>
> I've found it very useful for testing subdomains.
>
> Yours,
> Russ Magee %-)
>
> On Sun, Jan 27, 2013 at 7:47 AM, Brian Dant wrote:
> I'm trying to create a development environment that supports testing my
> subdomain configuration. I'll be using the django-subdomains package, which
> relies on the sites framework. To make a local environment that supports
> this while using the Django built-in webserver, do I need to set up local
> DNS? Most of the solutions I see rely on Apache, and refer to the /etc/hosts
> file. I've tried to use that, but nothing happens when I hit the name I
> think should map to 127.0.0.1:8000.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
How does the {% trans %} tag choose translations?
Hey everyone, got a little problem with the trans tag: In one of my apps, I've got a translation marker in a template saying "All dates", which is translated in the apps PO file for German (de) to "Alle Termine". But on the frontend I see "Alle Daten", which comes from the German translation file of django.contrib.admin. (I've rebuilt my translation files and recompiled them just to be perfectly sure that "Alle Daten" is not in there) Is there any way to define which translation catalog (domain?) the trans tag uses first? If not, why does it prefer Django admin's translations over my own in the templates of my application? Thanks for any help! Fabian -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How does the {% trans %} tag choose translations?
Thanks Bruno, that was helpful. 2011/6/22 bruno desthuilliers : > Not a direct answer, but this might help you understanding what's > going on: > > https://docs.djangoproject.com/en/1.3/topics/i18n/deployment/#how-django-discovers-translations > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Slow query. Any way to speed things up?
Hello everyone,
maybe someone can help me to speed up a quite slow query:
I've got two models (only the important stuff outlined here): Events and
EventDates
class Event(models.Model):
> status = models.SmallIntegerField(verbose_name=_(u"status"),
> choices=STATUS_CHOICES, default=STATUS_ONLINE, db_index=True)
>
> online = EventOnlineManager()
>
class EventDate(models.Model):
> event = models.ForeignKey(Event)
>
> date = models.DateField(verbose_name=_(u"start date"), db_index=True)
>
Events have an EventOnlineManager with a "to_expire" method which should
select all Events with status=online and EventDates associated which date <
today.
class EventOnlineManager(models.Manager):
>
> def get_query_set(self):
> return (super(EventOnlineManager, self).get_query_set()
> .filter(status=Event.STATUS_ONLINE))
>
> @property
> def to_expire(self):
> today = datetime.date.today()
> return (self.annotate(eventdate_max=models.Max('eventdate__date'))
> .filter(eventdate_max__lt=today))
>
Now this query takes about 15 seconds to run on a database with about 5,000
Events and 50,000 EventDates.
I'm running Django 1.3 (trunk) and PostgreSQL 9.0 on a relatively recent
quadcore machine.
Is there any way to do a more efficient query?
Thanks in advance!
Regards, Fabian
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Slow query. Any way to speed things up?
Hello Javier,
thanks for your answer!
The reason for one Event having multiple EventDates is simple: an event like
a theatre can have multiple shows/screenings.
Is there a way to add an index on event+date other than unique-together? (
http://docs.djangoproject.com/en/dev/ref/models/options/#unique-together)
I cannot use unique-together because that is not the case. EventDates have
more than just those two fields (see the full model below) and one event can
possibly have multiple shows each day.
class EventDate(models.Model):
> event = models.ForeignKey(Event)
>
> date = models.DateField(verbose_name=_(u"start date"), db_index=True)
> enddate = models.DateField(verbose_name=_(u"end date"),
>blank=True, null=True)
> start = models.TimeField(verbose_name=_(u"start time"),
> blank=True, null=True)
> end = models.TimeField(verbose_name=_(u"end time"),
>blank=True, null=True)
>
> class Meta:
> verbose_name = _(u"event date")
> verbose_name_plural = _(u"event dates")
> ordering = ('event', 'date')
>
Regards, Fabian
2011/3/28 Javier Guerra Giraldez
> On Mon, Mar 28, 2011 at 7:52 AM, Fabian Büchler
> wrote:
> >
> > Events have an EventOnlineManager with a "to_expire" method which should
> select all Events with status=online and EventDates associated which date <
> today.
> >
> >> class EventOnlineManager(models.Manager):
> >>
> >> def get_query_set(self):
> >> return (super(EventOnlineManager, self).get_query_set()
> >> .filter(status=Event.STATUS_ONLINE))
> >>
> >> @property
> >> def to_expire(self):
> >> today = datetime.date.today()
> >> return
> (self.annotate(eventdate_max=models.Max('eventdate__date'))
> >> .filter(eventdate_max__lt=today))
>
>
>
> I guess you have reasons to allow several EventDates per Event (if
> not, they should be a single table). my first attempt would be to
> add an (event, date) index to EventDate. can you add an
> ordering=('event','date') ?
>
> --
> Javier
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Slow query. Any way to speed things up?
"events_event"."subtitle_de", > "events_event"."description_de", > "events_event"."title_en", > "events_event"."subtitle_en", > "events_event"."description_en", > "events_event"."image_id", > "events_event"."location_id", > "events_event"."room_id", > "events_event"."contact_display", > "events_event"."price_from", > "events_event"."price_to", > "events_event"."vienna_card", > "events_event"."use_address", > "events_event"."use_tel_1", > "events_event"."use_tel_2", > "events_event"."use_tel_3", > "events_event"."use_email", > "events_event"."use_web", > "events_event"."alt_contact", > "events_event"."alt_contact_use", > "events_event"."alt_tel_1", > "events_event"."alt_tel_1_comment_de", > "events_event"."alt_tel_1_comment_en", > "events_event"."alt_tel_1_use", > "events_event"."alt_tel_2", > "events_event"."alt_tel_2_comment_de", > "events_event"."alt_tel_2_comment_en", > "events_event"."alt_tel_2_use", > "events_event"."alt_tel_3", > "events_event"."alt_tel_3_comment_de", > "events_event"."alt_tel_3_comment_en", > "events_event"."alt_tel_3_use", > "events_event"."alt_email_1", > "events_event"."alt_email_1_use", > "events_event"."alt_email_2", > "events_event"."alt_email_2_use", > "events_event"."alt_email_3", > "events_event"."alt_email_3_use", > "events_event"."alt_url_1", > "events_event"."alt_url_1_use", > "events_event"."alt_url_2", > "events_event"."alt_url_2_use", > "events_event"."alt_url_3", > "events_event"."alt_url_3_use", > "events_event"."ranking", > "events_event"."toptip", > "events_event"."daily_top", > "events_event"."term", > "events_event"."legacy_id", > "events_event"."id", duplicate fields > starting here > "events_event"."uid", > "events_event"."slug_de", > "events_event"."slug_en", > "events_event"."created_by_id", > "events_event"."created_on", > "events_event"."modified_by_id", > "events_event"."modified_on", > "events_event"."status", > "events_event"."online_from", > "events_event"."title_de", > "events_event"."subtitle_de", > "events_event"."description_de", > "events_event"."title_en", > "events_event"."subtitle_en", > "events_event"."description_en", > "events_event"."image_id", > "events_event"."location_id", > "events_event"."room_id", > "events_event"."contact_display", > "events_event"."price_from", > "events_event"."price_to", > "events_event"."vienna_card", > "events_event"."use_address", > "events_event"."use_tel_1", > "events_event"."use_tel_2", > "events_event"."use_tel_3", > "events_event"."use_email", > "events_event"
Re: Slow query. Any way to speed things up?
I've analyzed the query using pgAdmin and it seems the most time is being
spent with a the GroupAggregate.
This is because of so many columns being listed in the GROUP BY clause.
Creating two-column indexes over event_id and date or some other
combinations I've tried did not gain any perforamance.
Thus I've tried to get rid of some by just selecting some columns via
"only(...)". Strangely this does not have any effect on the GROUP BY clause.
On the other hand, if I use "values(...)" the GROUP BY clause shrinks to
only the named columns (but still being listed twice each).
>>> str(Event.objects.values('id','title_de','status')
... .filter(status=Event.STATUS_ONLINE)
>
... .annotate(eventdate_max=models.Max('eventdate__date'))
>
... .filter(eventdate_max__lt=today).query)
>
>
'SELECT "events_event"."id", "events_event"."title_de",
> "events_event"."status", MAX("events_eventdate"."date") AS "eventdate_max"
> FROM "events_event" LEFT OUTER JOIN "events_eventdate" ON
> ("events_event"."id" = "events_eventdate"."event_id") WHERE
> ("events_event"."status" = 2 ) GROUP BY "events_event"."id",
> "events_event"."title_de", "events_event"."status", "events_event"."id",
> "events_event"."title_de", "events_event"."status" HAVING
> MAX("events_eventdate"."date") < 2011-03-29 ORDER BY
> "events_event"."title_de" ASC, "events_event"."status" ASC'
>
This query runs in a few milliseconds. I guess I'll just go with this for
now since I don't know any other method...
The QuerySet.only() method not limiting the GROUP BY clause to the named
columns seems like a "bug" (or inefficiency) in the ORM to me. Is that valid
at any rate?
Regards,
Fabian
2011/3/29 bruno desthuilliers
> On 29 mar, 12:26, Fabian Büchler wrote:
>
> (snip part about the generated query)
>
> > As Javier suggested, an index on the "events_eventdate" over table over
> > "event_id" and "date" could help, but I don't know how to create one
> using
> > Django's model techniques
>
> This is something you can do directly at the database level - and you
> can add custom SQL statements to be run at syncdb time if necessary:
>
>
> http://docs.djangoproject.com/en/dev/howto/initial-data/#providing-initial-sql-data
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Slow query. Any way to speed things up?
Hello Matthias, 2011/3/29 Matthias Kestenholz > On Tue, Mar 29, 2011 at 2:27 PM, Fabian Büchler > wrote: > > I've analyzed the query using pgAdmin and it seems the most time is being > > spent with a the GroupAggregate. > > This is because of so many columns being listed in the GROUP BY clause. > > Creating two-column indexes over event_id and date or some other > > combinations I've tried did not gain any perforamance. > > > > Thus I've tried to get rid of some by just selecting some columns via > > "only(...)". Strangely this does not have any effect on the GROUP BY > clause. > > > > only() does not affect the generated query in any way -- it would be a > bug if it did. > only() does affect the selected columns, but of course that can never affect the rows that will be selected. > > On the other hand, if I use "values(...)" the GROUP BY clause shrinks to > > only the named columns (but still being listed twice each). > > > > There's already a ticket for the duplicated GROUP BY columns in the > Django ticket tracker: > > http://code.djangoproject.com/ticket/15709 > Thanks for this insight. The bug is already fixed but not yet checked in. Good to know. > > The QuerySet.only() method not limiting the GROUP BY clause to the named > > columns seems like a "bug" (or inefficiency) in the ORM to me. Is that > valid > > at any rate? > > > > Not sure about that. I'd say it isn't a bug because this could > potentially cause different results depending on the table and table > content. > Interesting thought. I guess that might be true, although I'm not quite enough SQL-sawy to be able to evaluate if that is correct. In my case the massive GROUP BY clause caused a pretty severe impact on query speed. But by now I've fixed the problem by just using the QuerySet.values() method instead of .only(). That works just fine and fast. > Matthias > Regards, Fabian > -- > Django CMS building toolkit: > http://www.feinheit.ch/labs/feincms-django-cms/ > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
