Re: porting of an application
Nader wrote: > But how about the content of my database? I > have used 'sqlite3' as a database engine. > Could somebody tell me how I can do this? If you're using sqlite3, wouldn't it simply be a matter of copying your .db file to the new location? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Looking for good forum software for integration with Django project ...
On Aug 9, 11:16 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote: > there's counterpoint, but I don't think its ready yet. > > http://code.google.com/p/counterpoint > > On 8/9/07, ZebZiggle <[EMAIL PROTECTED]> wrote: There's also the Sphene board/wiki/community stuff: http://sct.sphene.net/wiki/show/Start/ The author, Herbert Poul, is very open to suggestions for improvement. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unexplainable syntax error
Errors like that usually indicate errors further up in your code. if
you have pasted line 10 properly, you're just missing a closing
parenthesis.
On Jul 7, 2:43 pm, Leaf <[EMAIL PROTECTED]> wrote:
> After resolving the URLConf problem, I wrote some views without
> templates to make sure that I had the syntax right. When I tried to
> visit localhost:8000/styles/css/classic-b-and-w/ again, I recieved the
> error "SyntaxError at /styles/css/classic-b-and-w/ - invalid syntax
> (views.py, line 12)". The lines in question are (from the
> aforementioned views.py):
>
> (12) def test_page(request, stylename):
> (13)ow_my_style = get_object_or_404(Style, Slug=stylename)
> (14)return render_to_response('templates/testpage.html', {title:
> ow_my_style.Style_Name, slug: ow_my_style.Slug,
> author:ow_my_style.Author})
>
> I don't see why Python has a problem with it, because it passed a
> nearly identical line (line 8):
>
> (8) def css_generate(request, stylename):
> (9)you_cant_handle_my_style = get_object_or_404(Style,
> Slug=stylename)
> (10)return render_to_response('templates/genstyle.css', {style:
> you_cant_handle_my_style}
>
> This one has me really confused. Does anyone know what could have
> happened here?
>
> Regards,
> Leaf
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Nested edit_inline?
Hi all, Is there a way to have nested inline editing? For example, I have a Poll model which can have multiple Questions - which, of course, can have multiple Answers. I tried adding edit_inline=models.TABULAR to both the Question and Answer models, but of course, it didn't work. I can edit a question and see all of the answers inline, and I can edit a poll and see all of the questions inline. But what I want is to edit a poll and see all its questions, each with its associated answers. Is this possible? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: mod_python without httpd.conf?
On Friday 18 May 2007 14:06:48 [EMAIL PROTECTED] wrote: > I've tried googling for this for days without success. I'm looking for > a way to deploy a django app on a mod_python enabled server to which I > do not have httpd.conf access. This is entirely possible. Take whatever you were going to put in a directive in httpd.conf, and put it in a .htaccess file in your Django project's root without the enclosing . For example, this is (almost) what I have in a .htaccess file on a working development server I use: PythonPath "['/home/[your_home]'] + sys.path" SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonDebug On If you want to have Apache handle any subdirectories, just put "SetHandler None" into a .htaccess file in that directory. This replaces, for example, SetHandler None in the httpd.conf file. Keep in mind that all of these directives affect all subdirectories. > Also. Rightly or wrongly, I am also trying to achieve this with the > app and django files parallel to, not in, public_html. This approach works only if Apache can read the .htaccess files. This probably means that it has to be under whatever Apache believes to be its public_html directory, and since you don't have access to the httpd.conf file you have no say in the matter, unfortunately. Dan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: mod_python without httpd.conf?
On Friday 18 May 2007 21:32:33 Graham Dumpleton wrote: > This will all only work if the web site administrator has also set: > > AllowOverride FileInfo > > for the directory containing the .htaccess file you want to add the > the SetHandler directive to. Yes, that's true. Sorry, forgot to add that bit of info. Same for AuthConfig if you want to restrict access to sensitive projects in your .htaccess file. Dan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Apache configuration
On Monday 21 May 2007 14:27:02 dystopia wrote: > I'm worried that I haven't set this up properly, because in effect the > application (which is for test purposes) should really run off the > main domain rather than requiring to be accessed through a folder. Alternatively, you could set up a temporary subdomain for the project. Many hosts allow a certain number of these domains for an account. This would allow you to use the subdomain's root instead of a folder, avoiding the need to change everything when you deploy any of these projects. Dan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Is it essential to run setup.py?
On Wednesday 23 May 2007 01:07:13 Thomas Ashelford wrote: > Is there any kind soul who could explain what I can do to install 0.96 > without root access? If you're using Apache, you can include the path to Django in your .htaccess file. For example, I have a directory "software" which lives alongside "public_html" (aliased to "www") in my account's home directory. In there I've svn co'd the latest Django. You could actually have as many Django versions in there as you want. In the .htaccess file for a particular project, include the path to the Django you want to use for that project: PythonPath "['/home/[your_home]/software/django', '/home/[your_home]/www'] + sys.path Remember that the paths have to point to the directory in which each Python module lives. So inside the "django" directory there is another "django" directory which is the actual module that gets imported. Dan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Very large scale sites in Django
Hi all, I'm about to start a Django project that will be replacing an existing high-profile Drupal site. The existing site has extremely high traffic - approximately 1,440,000 page views per hour, or 400 per second. This is only possible with the help of Akami. Without Akami the site would melt. Is there anything I need to be aware of with regard to Django and high availability? I saw this: http://www.davidcramer.net/other/43/rapid-development-serving-50-pageshour.html but our traffic is triple that. I did glean a lot of good information from the site, however. I know that if we throw enough hardware at the system it will be able to handle the volume, but we don't have the budget for the hardware necessary in this case. Does anyone have any experience with a site of this magnitude? The 400 pages per second is a constant rate, not peak. The launch date is in September, so we have a limited time to design the models, port over the data (from Drupal's fractured database structure), and recreate this site from scratch. Thanks! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Very large scale sites in Django
On Thursday 31 May 2007 09:03:32 Christian Markwart Hoeppner wrote: > AFAIK, the bottleneck tends to be the database, so a cache solution like > memcached should make the deal. Think of a 256Mb cache for 10 seconds > maybe. Yes, the database is generally the main bottleneck these days. memcached is definitely on my radar. > Of course, the hardware should be able at least to serve that amount of > static pages, and maybe you should think about running the database on > another box, and link them with a proper lan. Currently we have three web server machines behind a load balancer, all of which talk to one MySQL database on another machine. We also have a separate machine for the copious media involved. Of course, the load is mitigated by the (expensive!) Akami off-site caching. > Though I have not ever experienced such a traffic, so this is pure > theory. Thanks for the response! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Very large scale sites in Django
On Thursday 31 May 2007 10:31:24 John M wrote: > I would love to know your site. Well, I'll reveal that when the site launches, but suffice to say it's for a very popular network TV show. We did the current site and are now redesigning and rearchitecting the entire thing for the next season. Don't worry though, I'll almost certainly have many questions during the course of its development. We already successfully launched a Django-powered site for another TV show, but the traffic isn't in the same league. Does anyone have hints regarding migrating a Drupal site to Django? I would appreciate any pointers people might have. Sounds like this might end up being the highest-traffic Django site there is! :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Very large scale sites in Django
On Thursday 31 May 2007 11:26:37 Nic James Ferrier wrote: > Daniel Ellison <[EMAIL PROTECTED]> writes: > > Sounds like this might end up being the highest-traffic Django site there > > is! :) > > Errr... I might be in competition with you there. > > /8-> Fine. Sounds like this might end up being the second highest-traffic Django site there is! :) What site do you run that gets > 400 hits per second, sustained? You could definitely provide some sage advice! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Very large scale sites in Django
On Thursday 31 May 2007 11:44:51 Tim Chase wrote: > It would also be helpful to know things about the usage > patterns--particularly the read-to-write ratio and > currency-demands. > > If most of your hits are reads, and stale data is okay (only > updated every N minutes), then you're a top candidate for several > of the caching solutions supported by Django. Or even front-end > caches that prevent Django from even seeing the request. Fortunately most of the hits are reads and they don't need to return up-to-the-second data. Minutes, maybe. So it sounds like door number one will do for us. Currently we use Akami caching for the Drupal version of the site, but it's a very expensive way to go. I'll investigate caching solutions supported by Django. A quick glance at the memcached site says that it's used on LiveJournal, which gets over 20,000,000 page requests per day. Excellent. Not quite at our traffic level, but not too shabby. :) Thanks, Tim. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Very large scale sites in Django
On Saturday 02 June 2007 10:02:08 Simon Willison wrote: > Memcached is pretty much the industry standard now for caching on high > traffic sites, at least those that use the LAMP stack. Flickr and > Wikipedia both use it, but the highest traffic install at the moment > is probably Facebook who are running 200+ memcache servers each with > 16GB of RAM. > > http://thread.gmane.org/gmane.comp.web.cache.memcached/3212 That's really good to know. Thanks, Simon. > If your site is almost all reads memcache should work like a dream. > Django's caching framework (which can use memcache on the backend) > should cover you nicely. Excellent. It looks quite straightforward to integrate memcached into a Django project (http://www.djangoproject.com/documentation/cache/#memcached). I now have a better idea of how to spec out this site. > If you haven't read it already, I'd strongly suggest getting a copy of > Cal Henderson's book "Building Scalable Websites", which covers a ton > of lessons he learnt scaling Flickr. Best book on the subject I've > seen. I haven't read it yet, but I most definitely will! It seems this won't be the last large-scale Django site we do - especially if I get all of this sorted out and the current project is a success. :) The client would dearly love to break its dependence on Akami caching, and it now looks like we may be able to do so. Thanks everyone for your help in this. Dan --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Very large scale sites in Django
On Sunday 03 June 2007 08:22:10 Tim Chase wrote: > Just as a side note, I believe Akami does geographic cache > controlling in addition to simply caching out of a central > location (as do several other big names in the caching business). > This means that users in, say, China, hit the cache controlling > machines in China, rather than your central servers in, say, > Atlanta. If all your users are fairly geographically > centralized, this may not introduce noticeable problems. The users of this site will be almost exclusively in the U.S. The site is for one of those high-profile American talk shows that wouldn't really appeal to those outside the States and perhaps Canada. > However, if your user-base is spread across the globe, a > centralized solution out of a single data-center may introduce > latency problems for more distant users. Some companies > (salesforce.com, for example) have several data-centers, > geographically dispersed so that customers end up hitting the > closest one. Perhaps Akami has reports that can be generated > from their usage to provide management with the data needed to > decide whether users are clustered near your data-center (such as > on the same continent), or if they're all around the world. I'm assuming that the very large sites using memcached are themselves geographically dispersed. LiveJournal, FaceBook, Wikipedia - I'm wondering if they have their own data centres. It's still worth getting stats from Akami if I can, however. It could give me a good idea as to where to host the site if I know where the biggest concentration of "viewers" is. Thanks again, Tim --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
