Lookups that span relationships

[rob]

Hi there,

I'm having trouble with the documentation at
http://www.djangoproject.com/documentation/db_api/#lookups-that-span-relationships

It says that I can follow a 'reverse' relationship by using the
lowercase name of the model, but when I try with the model below, I get
an error. What am I doing wrong?
Many thanks in advance for your time and assistance.

class Person(models.Model):
surname = models.CharField(maxlength=32)
given_names = models.CharField(maxlength=32)

class Registration(models.Model):
person = models.ForeignKey(Person, edit_inline=models.TABULAR)
reg_year = models.IntegerField(core=True)

Person.objects.filter(registration__reg_year__exact=2006)
 ==> TypeError: Cannot resolve keyword 'registration' into field


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DateField and DateTimefield do not really validate

[Rudolph]

Hi,

Ok: http://code.djangoproject.com/ticket/2103

Cheers, Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Site testing How-To

[Brett Parker]

On Tue, Jun 06, 2006 at 10:33:42PM -0600, Joseph Kocherhans wrote:
> 
> On 6/6/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > Does anyone know of a way to get all attributes of a module into
> > another module while overriding just a few?
> 
> I think you want tocreate something like testsettings.py, and in that
> file do something like:
> 
> from myproject.settings import *
> 
> then override the specific settings you want. It won't work with
> manage.py, but your tests should be able to just set the
> DJANGO_SETTINGS_MODULE env variable to use the myproject.testsettings
> module.

I'd do it the other way round, leave the settings module to be the main
settings, then do something like:

try:
from myproject.localsettings import 
except:


Then just create a localsettings.db on the live and dev instances that
have the right settings in. I'm currently using this style setup for a
project, seems to work quite well, even using sqlite3 on the dev server
and postgres on the live server.

Cheers,
-- 
Brett Parker

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Site testing How-To

[Simon Willison]

On 7 Jun 2006, at 02:42, Todd O'Bryan wrote:

> Does anybody have a best practice (or not-too-annoying practice) for
> testing?
>
> I think I'll use Selenium to test my site, but how should I change to
> a test database, populate the test database, etc.?

This is an area where Django can learn a huge amount from Ruby on  
Rails - they've solved a whole lot of the pain points with regards to  
testing against a database driven app. The two features that would be  
most relevant here are fixtures and a testing environment.

Rails lets you configure a separate database for testing (in fact you  
can have one for development, one for testing and one for deployment)  
- unit tests automatically run against the test DB.

Fixtures are YAML files containing default data which is loaded in to  
your test DB at the start of every test and reset afterwards. I'm not  
overjoyed with YAML for this (it's a little verbose) but it does the  
job and is very friendly to human editing, which is exactly why they  
picked it.

A neat trick for Django would be a command line tool that can dump an  
existing database in to fixture format - YAML or JSON or even  
serialized Python objects. This could serve a dual purpose - at the  
moment migrating Django application data from, for example, postgres  
to mysql requires custom hacking (even though django.db lets you  
interchange databases themselves with ease). Having a database- 
neutral backup/dump format would provide a tool for doing exactly that.

For the moment Django's model tests demonstrate a reasonably way of  
doing this stuff, but they aren't first class citizens of the Django  
environment - you have to do a bit of leg work to get that kind of  
thing set up for your own project. Fixing this would be another  
feather in Django's cap.

Cheers,

Simon

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Site testing How-To

[Simon Willison]

On 7 Jun 2006, at 05:33, Joseph Kocherhans wrote:

> I think you want tocreate something like testsettings.py, and in that
> file do something like:
>
> from myproject.settings import *
>
> then override the specific settings you want. It won't work with
> manage.py, but your tests should be able to just set the
> DJANGO_SETTINGS_MODULE env variable to use the myproject.testsettings
> module.

You can also use the ./manage.py --settings=myproject.testsettings  
command-line flag if you don't want to mess around with your  
environment variables.

Cheers,

Simon

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Please help with project setup

[Kristoffer]

Thanks, everyone, I have almost gotten things to work now!

One thing I can't quite figure out, though, is the following:

Say that I have Category defined as in
http://code.djangoproject.com/wiki/CookBookCategoryDataModel
(I use Django 0.91), with the exception that these lines

def get_separator(self):
return ' :: '

are changed to

def get_separator(self):
return '/'


In addition to the Category class I also have a Document definition in
my model:

class Document(meta.Model):
title = meta.CharField('title', maxlength=200)
cat = meta.ForeignKey(Category, blank=True, null=True)

status = meta.CharField(maxlength=10, choices=STATUS_CHOICES)
body = meta.TextField('Entry body', help_text='Use Restructured text
syntax.')

def __repr__(self):
return self.title

class META:
admin = meta.Admin(
fields = (
(None, {'fields': ('title', 'status', 'cat', 
'body')}),
)
)


Now, my question is: how should I write my urls.py and views.py files
so that I can display the correct document given an url that looks like
this: /myappname/cat1/cat2/cat3/article-title

This is what I have now:
def detail(request, doc_id):
docs = documents.get_list()
output = ', '.join([d.title for d in docs])
return HttpResponse("Hello, all available docs are: %s %s" % (doc_id,
output))

from django.conf.urls.defaults import *

urlpatterns = patterns('doccenter.articles.views',
(r'^$', 'index'),
(r'^(?P.+)/$', 'detail'),
)

Thanks,
Kristoffer


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Subclassing in Trunk

[David Reynolds]

Hi,

I seem to remember reading either on the mailing list or IRC channel  
that sub-classing doesn't work at the moment, is that correct? It  
seems to work to some extent but I can't recreate the behaviour that  
replaces_model='modelname' used to do. Is this going to be readded,  
or a better way of doing it added and what sort of timescales are on  
this?

Cheers,

David
-- 
David Reynolds
[EMAIL PROTECTED]




--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Internalization: Two DB tables for one Model?

[Archatas]

For better understanding of the second and the third ways of creating
multilingual models I mentioned, you can read the sub-article
"Database" in the "Internationalization Primer" at
http://digital-web.com/articles/internationalization_primer/

In my opinion, internalization is very important feature of websites.
Therefore, it has to be fully  supported in any web CMS or development
framework.

Aidas

Aidas Bendoraitis wrote:
> Hello Django Professionals!
>
> I am making a Django-based website that has to be multilingual.
> Everything is clear about making the admin section and the templates
> translatable. The problem is multilingual objects.
>
> I could think of several approaches to implement internationalization
> for Django objects:
>
> 1. Use special tagging inside the translatable fields, i.e.
> <%en%>Title<%/en%><%de%>Titel<%/de%><%lt%>Pavadinimas<%/lt%>
> (this is not usable for common people, administrating the site and
> tricky for implementing searches and other functionalities)
>
> 2. Create class attributes for every single translatable field, i.e.
> title_en = models.TextField(verbose_name=_("English Title"));
> title_de = models.TextField(verbose_name=_("German Title"));
> title_lt = models.TextField(verbose_name=_("Lithuanian Title"));
> (it's not flexible, because you can't add languages dynamically)
>
> 3. Create a separate DB table for every model that has translatable fields
> The table would contain
> - model_id
> - translatable fields (title, description)
> - language_id (or code)
> (I find this way the most proper for implementing multilingual
> objects, but.. (read further))
>
> One way to have a separate table for a model is to have a separate
> model for translatable fields and One to Many relationship between the
> models.
> i.e.
> class ItemLng(models.Model):
> product = models.ForeignKey(Item);
> language = models.CharField(maxlength=5, choices=LANGUAGES,
> verbose_name=_("language"))
> title = models.CharField(maxlength=200, core=True, 
> verbose_name=_("title"))
> description = models.TextField(verbose_name=_("description"))
> Then you can use tabular views in the administration to edit those
> translatable fields. (is it possible to restrict administrator from
> inserting two different versions of translations for the same
> language?)
>
> This may be OK until you start using tabular views for the primary
> objects. Let's take the example with Polls. Poll has children PollLng
> and Option, whereas Option has children OptionLng. As it is impossible
> to use two levels of tabular views, either Poll has to be edited
> separately from its Options, or Options has to be edited separately
> from their translated fields. And that makes no sense.
>
> So, I think, there should be a way to bound two database tables for
> one model. If you have an example or suggestions how to do that, or
> you have some suggestions how to implement translatable objects in
> another way, please respond to this email.
> 
> Mr. Aidas Bendoraitis


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django on Intel mac?

[Corey Oordt]

I have  MacBook, and although it was a challenge to get everything up  
and running, I ended up using darwinports to install apache 2, mysql  
5 and python 2.4.

Everything is working really well now

Corey Oordt

On Jun 6, 2006, at 9:36 PM, Greg Harman wrote:

>
>
> Oliver Kiessler wrote:
>
>> ---
>>
>> I also tried MysqlDB which compiles fine but throws a runtime error:
>>
>> macbookpro:~/mysite oliver$ python manage.py runserverValidating  
>> models...
>> Unhandled exception in thread started by > 0x77b930>
>> Traceback (most recent call last):
>>   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
>> python2.4/site-packages/Django-0.91-py2.4.egg/django/core/ 
>> management.py",
>> line 757, in inner_run
>> validate()
>>   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
>> python2.4/site-packages/Django-0.91-py2.4.egg/django/core/ 
>> management.py",
>> line 741, in validate
>> num_errors = get_validation_errors(outfile)
>>   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
>> python2.4/site-packages/Django-0.91-py2.4.egg/django/core/ 
>> management.py",
>> line 634, in get_validation_errors
>> import django.models
>>   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
>> python2.4/site-packages/Django-0.91-py2.4.egg/django/models/ 
>> __init__.py",
>> line 1, in ?
>> from django.core import meta
>>   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
>> python2.4/site-packages/Django-0.91-py2.4.egg/django/core/meta/ 
>> __init__.py",
>> line 3, in ?
>> from django.core import db
>>   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
>> python2.4/site-packages/Django-0.91-py2.4.egg/django/core/db/ 
>> __init__.py",
>> line 23, in ?
>> raise ImproperlyConfigured, "Could not load database backend: %s.
>> Is your DATABASE_ENGINE setting (currently, %r) spelled correctly?
>> Available options are: %s" % \
>> django.core.exceptions.ImproperlyConfigured: Could not load database
>> backend: Failure linking new module:
>> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
>> site-packages/_mysql.so:
>> Symbol not found: _uncompress
>>   Referenced from:
>> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
>> site-packages/_mysql.so
>>   Expected in: dynamic lookup
>> . Is your DATABASE_ENGINE setting (currently, 'mysql') spelled
>> correctly? Available options are: 'ado_mssql', 'mysql', 'postgresql',
>> 'sqlite3'
>
> I'm fighting the same problem now trying to use MySQL with my Intel
> Mac.  This particular error is because
> /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
> site-packages/_mysql.so
> was compiled for the PPC chipset.
>
> I've tried compiling from source for the i386 architecture, but am
> having no luck. :-(
>
>
> >


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

MyFormWrapper.myfield works in {{}} but not {%%} ?

[mazurin]

Hi all,

  I have a short question, it's probably a stupid one but I can't quite
figure out why Django behaves this way.

  I am using limoudou's 'expr' tag, btw.

  In a template html file, why can I do this (very simplified example):

  {{ form.somefield }}  

  but not this:

{% expr form.somefield as var %}
  {{ var }}  

  The 2nd example causes Django to raise an AttributeError, saying
"FormWrapper instance has no attribute 'somefield'."

  Why can I call the somefield method from within variable expansion
{{}} but not inside a custom tag? The reason I want to do this is I
want to use the same template for listing some object properties as for
displaying input fields to modify them.

  Thanks in advance,

mikah

--


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Site testing How-To

[Jeroen Ruigrok van der Werven]

On 6/7/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> I think I'll use Selenium to test my site, but how should I change to
> a test database, populate the test database, etc.?

You might like twill as well: http://twill.idyll.org/

http://agiletesting.blogspot.com/2005/09/web-app-testing-with-python-part-3.html

-- 
Jeroen Ruigrok van der Werven

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Site testing How-To

[Todd O'Bryan]

On Jun 7, 2006, at 3:54 AM, Simon Willison wrote:

>
>
> On 7 Jun 2006, at 05:33, Joseph Kocherhans wrote:
>
>> I think you want tocreate something like testsettings.py, and in that
>> file do something like:
>>
>> from myproject.settings import *
>>
>> then override the specific settings you want. It won't work with
>> manage.py, but your tests should be able to just set the
>> DJANGO_SETTINGS_MODULE env variable to use the myproject.testsettings
>> module.
>
> You can also use the ./manage.py --settings=myproject.testsettings
> command-line flag if you don't want to mess around with your
> environment variables.

That did exactly what I was looking for. Now I just have to figure  
out the most efficient way to pre-populate everything. I'm thinking  
I'll have a 'test' app that has hooks for sticking in data that I can  
call before I run tests.

Thanks everybody!
Todd

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Site testing How-To

[Matthew Flanagan]

On 6/7/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
>
> On Jun 7, 2006, at 3:54 AM, Simon Willison wrote:
>
> >
> >
> > On 7 Jun 2006, at 05:33, Joseph Kocherhans wrote:
> >
> >> I think you want tocreate something like testsettings.py, and in that
> >> file do something like:
> >>
> >> from myproject.settings import *
> >>
> >> then override the specific settings you want. It won't work with
> >> manage.py, but your tests should be able to just set the
> >> DJANGO_SETTINGS_MODULE env variable to use the myproject.testsettings
> >> module.
> >
> > You can also use the ./manage.py --settings=myproject.testsettings
> > command-line flag if you don't want to mess around with your
> > environment variables.
>
> That did exactly what I was looking for. Now I just have to figure
> out the most efficient way to pre-populate everything. I'm thinking
> I'll have a 'test' app that has hooks for sticking in data that I can
> call before I run tests.
>
> Thanks everybody!
> Todd
>

You should check out
https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/wiki/DjangoTesting
for django fixtures and unittest framework. The patch in
https://simon.bofh.ms/cgi-bin/trac-django-projects.cgi/ticket/226
updates it for the latest django trunk. The ony thing that isn't
updated for MR is django-test.py, which in my project i've replaced
with a simpler script, a fragment of which is below:

import os
import sys
import unittest

def runtests(applications):
from django.conf import settings
from stuff.testing import gather_testcases

for app_label in applications:
path = None
mod = None
mod = __import__(app_label, {}, {}, [app_label])
if app_label in settings.INSTALLED_APPS:
path = os.path.dirname(mod.__file__)
if path is None:
print "Error: did you add the application to your INSTALLED_APPS?"
sys.exit(8)
testsuite = gather_testcases(os.path.join(path, 'test', 'unittests'))
runner = unittest.TextTestRunner()
runner.run(testsuite)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Site testing How-To

[Michael Radziej]

Hi,

Just a little teaser:

I've found a nice approach to test your views. The problem is, the http 
response is hard to test, since you have to either scrape the interesting 
content from it, or use regexps. Both is not really nice.

My approach does not check the actual http response, but the context that the 
view passes to the template. This means:

- changes in the template don't affect your tests
- changes in the tests are much easier to handle than with screen scraping
- test cases are easy to read, since you see all the data passed in and out


During a test run:

- you need to insert a special template tag ("ContextKeeper") into your base 
site template (see below)
- a HttpRequest gets created and run through Django via 
BaseHandler.get_response()
- the ContextKeeper fetches the view context and saves it into thread storage
- this is then used to compare the context to the expected context.
- In the context, objects are replaced by their __repr__(), but lists, 
dictionaries, sets, tuples stay as they are
- You can ignore context entries that you're not interested in, like all the 
"LANGUAGE_*" entries

In code, it looks like this:

def test_portal_initial():
# test case for GET /mailadmin/portal/
response, context = runner.get_response('/mailadmin/portal/', 'GET', {}, {})
assert runner.check_context(response, context, {'domain_title': None,
'domains': [],
'get_new_mailbox_url': 'create-mailbox/',
'kunden': [''],
'mailbox_count': 0L,
'mailboxes': [],
'mailrule_count': 1L,
'messages': [],
'person': '',
'rules': [' mx.x.de>'],
'single_kunde': True,
'too_many_domains': False,
'too_many_mailboxes': False,
'too_many_rules': False,
'user': ''})
assert runner.check_response(response, {'status_code': 200, 'cookies': 
SimpleCookie('')})

This can the be used with py.test. 

Then, there's a special middleware that writes the test cases for you while you 
use the browser. For each http transaction, it creates a test case. Cut and 
paste, a little bit tailoring and organizing, you're done.

I've also solved the problems of initializing the test database from a set of 
dicts, comparing dictionaries etc., and handling sessions. I'm already using it 
with great fun. It's only a little bit raw, but I plan to contribute it soon.

Then, I've found a way to combine py.test with doctests, including database 
setup. I use this to test all the functions that are not views.

Michael


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Django on Dreamhost. Getting 503 http error when I try to login to admin

[Tomas Jacobsen]

Hi. Im trying to install django on my Dreamhost domain. I have followed
the dreamhost wiki and the guide on
http://www2.jeffcroft.com/2006/may/11/django-dreamhost/  about 4 times
now, and the last 3 times I get the same 503 error when I try to login
to admin.

Before I installed admin I get the "It worked, Congratulations on your
first Django-powered page" when I try to access my django.mydomain.com.


Then I try to install the admin and the .htaccess file. Now I get a
nice django 404 error on the django.mydomain.com. But when I try to
access django.mydomain.com/admin I get the username and password page
(without css) and I login with the superuser I created, but I only get
a regular 503 http error when I submit.

In the error log i get this error:

mod_security: Access denied with code 503. Pattern match
"(go\\.to|get\\.to|drop\\.to|hey\\.to|switch\\.to|dive\\.to|move\\.to|again\\.at)"
at HEADER. [hostname "django.mydomain.com"] [uri "/admin/"]

Can anyone check if my settings is correct?


settings.py:
===
# Django settings for myproject project.

DEBUG = True
TEMPLATE_DEBUG = DEBUG

ADMINS = (
 ('Tomas', '[EMAIL PROTECTED]'),
)

MANAGERS = ADMINS

DATABASE_ENGINE = 'mysql'   # 'postgresql', 'mysql', 'sqlite3'
or 'ado_mssql'.
DATABASE_NAME = 'django_db' # Or path to database file if
using sqlite3.
DATABASE_USER = 'tomas' # Not used with sqlite3.
DATABASE_PASSWORD = '' # Not used with sqlite3.
DATABASE_HOST = 'djangodb.mydomain.com' # Set to empty
string for localhost. Not used with sqlite3.
DATABASE_PORT = '' # Set to empty string for default. Not
used with sqlite3.

# Local time zone for this installation. All choices can be found here:
#
http://www.postgresql.org/docs/current/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE
TIME_ZONE = 'America/Chicago'

# Language code for this installation. All choices can be found here:
# http://www.w3.org/TR/REC-html40/struct/dirlang.html#langcodes
# http://blogs.law.harvard.edu/tech/stories/storyReader$15
LANGUAGE_CODE = 'en-us'

SITE_ID = 1

# Absolute path to the directory that holds media.
# Example: "/home/media/media.lawrence.com/"
MEDIA_ROOT = '/home/tomasjac/django.mydomain.com/media/'

# URL that handles the media served from MEDIA_ROOT.
# Example: "http://media.lawrence.com";
MEDIA_URL = 'http://django.mydomain.com/media'

# URL prefix for admin media -- CSS, JavaScript and images. Make sure
to use a
# trailing slash.
# Examples: "http://foo.com/media/";, "/media/".
ADMIN_MEDIA_PREFIX = '/admin_media/'

# Make this unique, and don't share it with anybody.
SECRET_KEY = '***'

# List of callables that know how to import templates from various
sources.
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.load_template_source',
'django.template.loaders.app_directories.load_template_source',
# 'django.template.loaders.eggs.load_template_source',
)

MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
)

ROOT_URLCONF = 'myproject.urls'

TEMPLATE_DIRS = (
# Put strings here, like "/home/html/django_templates".
# Always use forward slashes, even on Windows
"/home/tomasjac/django/django_templates"
)

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
)

===

django.fcgi:
===
#!/usr/bin/env python
import sys
sys.path += ['/home/tomasjac/django/django_src']
sys.path += ['/home/tomasjac/django/django_projects']
from fcgi import WSGIServer
from django.core.handlers.wsgi import WSGIHandler
import os
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
WSGIServer(WSGIHandler()).run()

===

.htaccess:
===
RewriteEngine On
RewriteBase /
RewriteRule ^(media/.*)$ - [L]
RewriteRule ^(admin_media/.*)$ - [L]
RewriteRule ^(django\.fcgi/.*)$ - [L]
RewriteRule ^(.*)$ django.fcgi/$1 [L]

===
I
Inside my django.mydomain.com I have a folder called "admin_media".

I have used the command:

ln -s $HOME/django/django_src/django/contrib/admin/media
$HOME/django.mydomain.com/admin_media

And when I look insidethe "admin_media" folder with ftp I see a another
folder called "media" with a shortcut icon on, but when I try to access
it I get a "550 media: No such file or directory". Is this normal?

I hope someone could help me. Im really stuck!


--~--~-~--~~~---~--~~
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 [EM

"Back-to-front" LDAP Authentication

[James Mulholland]

I've set up Django under Apache 2, so that users are prompted for their
LDAP username/password when they try to visit my Django site. This
authentication is the standard Apache http-auth dialog which has
nothing to do with Django itself. I also created this (below) as a way
to populate the Django user database and return a user object when the
user fetches a page from the site (this lives in
"intranet/httpauth/models.py"):

def http_login(request):
rem_user = request.META['REMOTE_USER']
domain_a_user = re.compile(r'^\w+\.\w+$')
domain_b_user = re.compile(r'^\w+$')

try:
user = User.objects.get(username__exact=rem_user)
except User.DoesNotExist:
pw = User.objects.make_random_password(length=10,
allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')
domain = ''
if domain_a_user.match(rem_user):
domain = '@firstdomain.co.uk'
elif domain_b_user.match(rem_user):
domain = '@seconddomain.co.uk'
user = User.objects.create_user(rem_user, rem_user + domain,
pw)
user.is_staff = True

request.session[SESSION_KEY] = user.id
if user.is_active:
return user
else:
return None

def account_not_found(request):
http_auth_name = request.META['REMOTE_USER']
return render_to_response('http_auth/locked.html',
{'http_auth_name': http_auth_name})

I'm not, incidentally, holding this up as exemplary code -- it's
basically a hack which solves my immediate problem of using LDAP auth
without changing anything in the Django source code (except I had to
make *one* change so it would accept usernames with dots in, and the
presence of a dot in the LDAP username indicates which email domain
this user should have -- user.name = '@domain_a.co.uk' but username =
'@domain_b.co.uk').

The immediate problems are:

1. I have to put "from intranet.httpauth.models import
account_not_found, http_login" in each views.py
2. I have to check the user with

user = http_login(request)
if not user:
return account_not_found(request)

at the start of each subroutine in views.py, and pass the user object
into the templates. I'm guessing there has to be a smarter way to do
this, and I would appreciate advice. I like that the code doesn't
interfere (much) with the "raw" Django code, but it is an egregious
offender against the DRY principle.

Please bear in mind that I'm new to Python and Django, so I confuse
easily :-} I'm also from a perl background, so if you see anything
perl-ish in there, that's why.

--
James


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django on Dreamhost. Getting 503 http error when I try to login to admin

[Michael Radziej]

Tomas Jacobsen wrote:
> In the error log i get this error:
> 
> mod_security: Access denied with code 503. Pattern match
> "(go\\.to|get\\.to|drop\\.to|hey\\.to|switch\\.to|dive\\.to|move\\.to|again\\.at)"
> at HEADER. [hostname "django.mydomain.com"] [uri "/admin/"]

How exactly did you access your web site? What URL? 

It looks as if you have triggered a precaution against using some forwardings 
services like go.to ... probably set up by Dreamhost. It doesn't look as if 
it's anything got to do with your settings.

Michael

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django on Dreamhost. Getting 503 http error when I try to login to admin

[Tomas Jacobsen]

I use: http://www.django.tomasjacobsen.com/admin/ and
http://django.tomasjacobsen.com/admin/ . The same result on both.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django on Dreamhost. Getting 503 http error when I try to login to admin

[Michael Radziej]

Tomas Jacobsen wrote:
> I use: http://www.django.tomasjacobsen.com/admin/ and
> http://django.tomasjacobsen.com/admin/ . The same result on both.

That's it. There's "go.to" in "django.tomasjacobsen".

You should complain at Dreamhost. They filter in the wrong way. For a 
work-around, change your domain to e.g.
www.tomasjacobsen.com

Good luck ;-)


Michael


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django on Dreamhost. Getting 503 http error when I try to login to admin

[Tomas Jacobsen]

Ah, good to know Im not stupid :) Will try it out with my regular
domain later. Thank you!


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

DoesNotExist at /accounts/login/

[Charles F. Munat]

New to Django but pretty impressed so far. Am having some trouble 
getting Auth to work. Have tried everything I can think of. Error 
message below. Any help appreciated.

Chas. Munat
Seattle

(Not knowing yet what is important, I included everything here. If there 
are parts of the error message I can leave out, then please let me know. 
Thanks.)


DoesNotExist at /accounts/login/
Site matching query does not exist.
Request Method: GET
Request URL:http://127.0.0.1:8000/accounts/login/
Exception Type: DoesNotExist
Exception Value:Site matching query does not exist.
Exception Location: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/db/models/query.py
 
in get, line 204
Traceback (innermost last)
Switch to copy-and-paste view

 * 
/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/core/handlers/base.py
 
in get_response
 67. # Apply view middleware
 68. for middleware_method in self._view_middleware:
 69. response = middleware_method(request, callback, 
callback_args, callback_kwargs)
 70. if response:
 71. return response
 72.
 73. try:
 74. response = callback(request, *callback_args, 
**callback_kwargs) ...
 75. except Exception, e:
 76. # If the view raised an exception, run it through exception
 77. # middleware, and if the exception middleware returns a
 78. # response, use that. Otherwise, reraise the exception.
 79. for middleware_method in self._exception_middleware:
 80. response = middleware_method(request, e)
   ▼ Local vars
   Variable Value
   callback 
   
   callback_args
   ()
   callback_kwargs  
   {}
   e
   
   exceptions   
   
   mail_admins  
   
   middleware_method
   >
   path 
   '/accounts/login/'
   request  
   , 
POST:, COOKIES:{'sessionid': 
'e567534679a1e0c44432fcf3f28d9160'}, META:{'ANT_HOME': 
'/usr/local/apache-ant', 'CATALINA_BASE': '/usr/local/tomcat', 
'CATALINA_HOME': '/usr/local/tomcat', 'CATALINA_TMPDIR': 
'/usr/local/tomcat/temp', 'CONTENT_LENGTH': '', 'CONTENT_TYPE': 
'text/plain', 'DJANGO_SETTINGS_MODULE': 'xxx.settings', 
'GATEWAY_INTERFACE': 'CGI/1.1', 'HOME': '/Users/administrator', 
'HTTP_ACCEPT': 
'text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5',
 
'HTTP_ACCEPT_CHARSET': 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 
'HTTP_ACCEPT_ENCODING': 'gzip,deflate', 'HTTP_ACCEPT_LANGUAGE': 
'en-us,en;q=0.5', 'HTTP_CACHE_CONTROL': 'max-age=0', 'HTTP_CONNECTION': 
'keep-alive', 'HTTP_COOKIE': 
'sessionid=e567534679a1e0c44432fcf3f28d9160', 'HTTP_HOST': 
'127.0.0.1:8000', 'HTTP_KEEP_ALIVE': '300', 'HTTP_USER_AGENT': 
'Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) 
Gecko/20060508 Firefox/1.5.0.4', 'JAVA_HOME': '/usr', 'JRE_HOME': 
'/usr', 'LOGNAME': 'administrator', 'OLDPWD': '/Users/administrator', 
'PATH': 
'/opt/local/bin:/usr/bin:/usr/local/bin:/bin:/opt/local/lib/mysql5/bin:/opt/local/lib/pgsql8/bin:/opt/local/Library/Frameworks/Python.framework/Versions/2.4/bin/',
 
'PATH_INFO': '/accounts/login/', 'PWD': '/Users/administrator/xxx', 
'QUERY_STRING': 'next=/', 'REMOTE_ADDR': '127.0.0.1', 'REMOTE_HOST': 
'poker.localhost', 'REQUEST_METHOD': 'GET', 'RUN_MAIN': 'true', 
'SCRIPT_NAME': '', 'SECURITYSESSIONID': '59b690', 'SERVER_NAME': 
'poker.localhost', 'SERVER_PORT': '8000', 'SERVER_PROTOCOL': 'HTTP/1.1', 
'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.4.2', 'SHELL': '/bin/bash', 
'SHLVL': '1', 'TERM': 'xterm-color', 'TERM_PROGRAM': 'Apple_Terminal', 
'TERM_PROGRAM_VERSION': '133', 'TZ': 'America/Chicago', 'USER': 
'administrator', '_': '/opt/local/bin/python', 
'__CF_USER_TEXT_ENCODING': '0x1F9:0:0', 'wsgi.errors': ', mode 'w' at 0x140b0>, 'wsgi.file_wrapper': , 'wsgi.input': 
, 'wsgi.multiprocess': False, 
'wsgi.multithread': True, 'wsgi.run_once': False, 'wsgi.url_scheme': 
'http', 'wsgi.version': (1, 0)}>
   resolver 
   
   response 
   None
   self 
   
   settings 
   
   urlresolvers 
   
 * 
/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/contrib/auth/views.py
 
in login
 21. redirect_to = '/accounts/profile/'
 22. request.session[SESSION_KEY] = manipulator.get_user_id()
 23. request.session.delete_test_cookie()
 24. return HttpResponseRedirect(redirect_to)
 25. else:
 26. errors = {}
 27. request.session.set_test_cookie()
 28. return render_to_response('registration/login.html', { ...
 29. 'form': forms.FormWrapper(manipulator, request.POST, errors),
 30. REDIRECT_FIELD_NAME: red

Re: DoesNotExist at /accounts/login/

[rob]

I'm completely new to django and don't know too much, but to me it
looks as though your urls.py doesn't include a regular expression that
matches "/accounts/login/". If this is the case, then
http://www.djangoproject.com/documentation/tutorial3/ should hopefully
cover what you'll need.

All the best,
Rob


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Help with multiple object added on a single form with addManipulator.

[Frankie Robertson]

This forces me to use non-compliant code by making me use multiple
controls with the same id. Since nobody seems to know the solution to
this problem I'm assuming it's a problem with documentation and have
filed a bug on it at http://code.djangoproject.com/ticket/2107.

Frankie.

On 06/06/06, Frankie Robertson <[EMAIL PROTECTED]> wrote:
> Oops, I just accidently hit send to early there.
>
> Anyway, when messing around with the manipulators in the shell and
> generate them as shown at
> http://code.djangoproject.com/wiki/NewAdminChanges I get a dictionary
> called _related_objects (or something like that) but I am unable to
> access it in the templates. I've hacked around this for the moment but
> I would like to know the Right Way(TM) of doing this.
>
> Thanks,
> Frankie
>
*snip*

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DoesNotExist at /accounts/login/

[Paul Childs]

I had the same troubles and then I found this...
http://www.carcosa.net/jason/blog/computing/django/gotchas-2006-04-19
You will notice some other goodies there too. :)

You may want these in your project's url.py file too

(r'^logout/', 'django.views.auth.login.logout'),
(r'', 'django.views.auth.login.login'),
(r'^login/', 'django.views.auth.login.login'),
(r'^accounts/login', 'django.views.auth.login.login'),

Hope this helps
/Paul


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DoesNotExist at /accounts/login/

[Charles F. Munat]

rob wrote:
> I'm completely new to django and don't know too much, but to me it
> looks as though your urls.py doesn't include a regular expression that
> matches "/accounts/login/".

My urls.py includes:

 (r'^accounts/login/$', 'django.contrib.auth.views.login'),

which I copied and pasted directly from

http://www.djangoproject.com/documentation/authentication/

> If this is the case, then
> http://www.djangoproject.com/documentation/tutorial3/ should hopefully
> cover what you'll need.

Nope. I read the tutorial from start to finish twice and managed to get 
the Poll site working. My current site is only a rough outline so far, 
but the Admin portion is working fine, so I know that the urls.py works. 
I've also looked into the django-project files and the auth.views.login 
method is there. I honestly don't know why I'm getting the error.

Thanks,

Chas. Munat
Seattle

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DoesNotExist at /accounts/login/

[Charles F. Munat]

Paul Childs wrote:
> I had the same troubles and then I found this...
> http://www.carcosa.net/jason/blog/computing/django/gotchas-2006-04-19
> You will notice some other goodies there too. :)

Jason McBrayer uses the following regexs in his urls.py file:

 (r'^accounts/login/', 'django.views.auth.login.login'),
 (r'^accounts/logout/', 'django.views.auth.login.logout'),

I am using

 (r'^accounts/login/$', 'django.contrib.auth.views.login'),

Note the $ symbol. I've tried it with and without the $. No difference.

Also note that he is using views.auth.login.login vs. 
contrib.auth.views.login, which is what the Authentication documents --

http://www.djangoproject.com/documentation/authentication/

use. I copied and pasted from them, in fact. When I use his regexs 
instead, I get the following error:

ViewDoesNotExist at /accounts/login/
Could not import django.views.auth.login. Error was: No module named 
auth.login

So I don't think his are correct for the current version I'm using. (I 
pulled it from SVN some two days ago.) And when I follow the path 
contrib/auth/, I do find a views.py file with a method called login, so 
I think that contrib.auth.views.login is correct.

Chas. Munat
Seattle

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Internalization: Two DB tables for one Model?

[tekNico]

Aidas Bendoraitis wrote:
> Hello Django Professionals!
>
> I am making a Django-based website that has to be multilingual.

Me too. :-)


> Everything is clear about making the admin section and the templates
> translatable. The problem is multilingual objects.
>
> I could think of several approaches to implement internationalization
> for Django objects:
>
> 1. Use special tagging inside the translatable fields, i.e.
> <%en%>Title<%/en%><%de%>Titel<%/de%><%lt%>Pavadinimas<%/lt%>
> (this is not usable for common people, administrating the site and
> tricky for implementing searches and other functionalities)

I don't like this.


> 2. Create class attributes for every single translatable field, i.e.
> title_en = models.TextField(verbose_name=_("English Title"));
> title_de = models.TextField(verbose_name=_("German Title"));
> title_lt = models.TextField(verbose_name=_("Lithuanian Title"));
> (it's not flexible, because you can't add languages dynamically)

I'm leaning toward this. Yes, it's not flexible, but it's YAGNI for me,
and the simplifying gains are huge.


> 3. Create a separate DB table for every model that has translatable fields
> The table would contain
> - model_id
> - translatable fields (title, description)
> - language_id (or code)
> (I find this way the most proper for implementing multilingual
> objects, but.. (read further))

Complex, ugly.


There's also another approach: use translation tables for content, same
as it is done for the app interface. I don't like that either.


--
Nicola Larosa - http://www.tekNico.net/

Continuation-based web frameworks (like Seaside) seem lame to me. I'm
so much more impressed by event-based programming, and continuations
(used in that way) seem like a way to avoid explicit events. Events are
the web. Continuations are people who want to make the web into an MVC
GUI. -- Ian Bicking, February 2006


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DoesNotExist at /accounts/login/

[Paul Childs]

I'm using version 0.91. That's the difference.

The only other thing I can suggest is to chekc if you have your login
and logout templates in the right place and that the template locations
are in your settings.py file.

Sorry I couldn't help out. Good luck.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django Article on Developerworks

[Wilson Miner]

Ha - that's great!
On 6/6/06, Ian Maurer <[EMAIL PROTECTED]> wrote:
Thanks guys for the feedback. Hopefully the changes will getincorporated tomorrow.Also, I like the art IBM put together for the front page of the linux section...
http://www-128.ibm.com/developerworks/linux/I hope it meets with the approval of the true fans of both Django's.regards,IanOn 6/6/06, Ian Maurer <
[EMAIL PROTECTED]> wrote:> IBM has just posted an article on mine on the IBM website (hasn't made> it to the front page, yet):>> 
http://www-128.ibm.com/developerworks/linux/library/l-django/>> If you notice any errors, kindly send them to me via email and I will> see if I can get them fixed.>> Thanks to all of the contributors of this great software... I hope
> this article gains the project some additional exposure.>> regards,> Ian>

--~--~-~--~~~---~--~~
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  -~--~~~~--~~--~--~---

Validation based on a related object field (ForeignKey) value

[strangy]

Hello,
Is there a way to validate a field in the model based on a value in a
related object (ForeignKey field) ??

For example:
I have an Activity object which definex a maxscore integer field and an
StudentActivity object which has a score field. Now i want to validate
that the value of the StudentActivity.score field is not greater than
Activity.maxscore.

Is this kind of validation 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
-~--~~~~--~~--~--~---

Re: Validation based on a related object field (ForeignKey) value

[strangy]

strangy wrote:
> Hello,
> Is there a way to validate a field in the model based on a value in a
> related object (ForeignKey field) ??
>
> For example:
> I have an Activity object which definex a maxscore integer field and an
> StudentActivity object which has a score field. Now i want to validate
> that the value of the StudentActivity.score field is not greater than
> Activity.maxscore.
>
> Is this kind of validation possible.

Just to add that I want this validation to work in the admin, and for
saving and updating an object.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Catching a failed response

[Jay Parlar]

On 6/6/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Ah... This is interesting :-). A web server will know that a client has
> been disconnected only when it will try to send it something. So if you
> have a long working view you can't know if it works for nothing until it
> finishes.
>
> It's good when you can do calculations and push results to the client
> iteratively. Then you can create an iterator and pass it to a
> HttpResponse. It then will call your code until it's done or an error
> writing data to the client occured. It looks like this:
>
> def long_process():
>   while not done:
> data_chunk = calculate_data_chunk()
> yield data_chunk
>
>
> def some_view(request):
>   return HttpResponse(long_process())
>
> P.S. In mod_python you can actually catch the write error in Dango's
> core/handlers/modpython.py because the loop iterating over response's
> iterator is there in 'populate_apache_response'. However in general case
> (WSGI) it's outside of Django and is not accessible.

Oh wow, you can pass an iterable to HttpResponse? I never noticed that before!

If the write fails before all the iterations are done though, I guess
I have no way to generically catch that, to do any kind of cleanup I
might need?

Jay P.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DoesNotExist at /accounts/login/

[Charles F. Munat]

Paul Childs wrote:
> I'm using version 0.91. That's the difference.
> 
> The only other thing I can suggest is to chekc if you have your login
> and logout templates in the right place and that the template locations
> are in your settings.py file.

I think so. The other templates are working. But one thing: the Auth 
docs say there should be a template at registration/login.html. So in my 
templates directory (which I know is set properly) I created a 
registration directory and added the template in it with filename 
login.html. That is my interpretation of how that should work. I've 
tried moving this file and directory around, but that doesn't seem to be it.

> Sorry I couldn't help out. Good luck.

No prob. All efforts greatly appreciated.

Chas. Munat
Seattle

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Validation based on a related object field (ForeignKey) value

[mamcxyz]

Overwrite the save() methon.

Example:

(I wanna test if at least 1 addr is added)

def save(self):
#Comprobar que existe al menos UNA direccion...
existe = False

for addr in self.restaurantaddress_set.all():
existe = True
break

Why this and not count()

Because count() go to the database, so this not work when add a fresh
object.

Why not len()?

The docs warning about this... load all the records...


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Catching a failed response

[Jeremy Dunck]

On 6/7/06, Jay Parlar <[EMAIL PROTECTED]> wrote:

> Oh wow, you can pass an iterable to HttpResponse? I never noticed that before!
>
> If the write fails before all the iterations are done though, I guess
> I have no way to generically catch that, to do any kind of cleanup I
> might need?

class ModPythonHandler(BaseHandler):
def __call__(self, req):
   ...
   populate_apache_request(response, req)

def populate_apache_request(http_response, mod_python_req):
"Populates the mod_python request object with an HttpResponse"
...
for chunk in http_response.iterator:
mod_python_req.write(chunk)


In other words, as it stands, no, I don't think you can catch an
exception raised while sending the bits down the wire.  Exception
middleware catches exceptions raised by the view, but the Response
isn't rendered to the pipe until well after that.

It sounds to me like "Exception Middleware" needs to be renamed to
"View Exception Middleware" and you should write a patch for "Response
Exception Middleware".  ;-)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: "Back-to-front" LDAP Authentication

[Ramiro Morales]

James,

On 6/7/06, James Mulholland <[EMAIL PROTECTED]> wrote:
>
> I've set up Django under Apache 2, so that users are prompted for their
> LDAP username/password when they try to visit my Django site. This
> authentication is the standard Apache http-auth dialog which has
> nothing to do with Django itself. I also created this (below) as a way
> to populate the Django user database and return a user object when the
> user fetches a page from the site (this lives in
> "intranet/httpauth/models.py"):
>
> [...]
> I'm guessing there has to be a smarter way to do
> this, and I would appreciate advice. I like that the code doesn't
> interfere (much) with the "raw" Django code, but it is an egregious
> offender against the DRY principle.
>

You may want to take a look at the multi-auth branch created and maintained
by  Joseph Kocherhans.

Joseph keeps it very up to date with respect to trunk by merging the changes
happening there to the branch periodically. The last merge was two days ago.

You can find more info at
http://code.djangoproject.com/wiki/MultipleAuthBackends
where even there is an example of a pluggable LDAP auth backend that allows
integrating Django apps with an existing user base maintained in a LDAP server.

HTH

-- 
 Ramiro Morales

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Catching a failed response

[Jay Parlar]

On 6/7/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:

>
> In other words, as it stands, no, I don't think you can catch an
> exception raised while sending the bits down the wire.  Exception
> middleware catches exceptions raised by the view, but the Response
> isn't rendered to the pipe until well after that.
>
> It sounds to me like "Exception Middleware" needs to be renamed to
> "View Exception Middleware" and you should write a patch for "Response
> Exception Middleware".  ;-)


What's the current definition of "Exception Middleware"? I can't find
a good one in the docs.

Jay P.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Catching a failed response

[Jeremy Dunck]

On 6/7/06, Jay Parlar <[EMAIL PROTECTED]> wrote:

> What's the current definition of "Exception Middleware"? I can't find
> a good one in the docs.

From
http://www.djangoproject.com/documentation/middleware/#process-exception :
"
process_exception

Interface: process_exception(self, request, exception)

request is an HttpRequest object. exception is an Exception object
raised by the view function.

Django calls process_exception() when a view raises an exception.
process_exception() should return either None or an HttpResponse
object. If it returns an HttpResponse object, the response will be
returned to the browser. Otherwise, default exception handling kicks
in.
"

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Subclassing in Trunk

[Scanner]

It does not work currently. Ticket #1656 at djangoproject refers to
this:

http://code.djangoproject.com/ticket/1656

This is apparently one of the projects being covered by the Google
Summer of Code.
Some discussion of it is at:

http://code.djangoproject.com/wiki/ModelInheritance

I myself need inheritance, and the 'join' method is unpleasant because
I use a lot of basically abstract-base-classes and this would be a big
performance hit.

I have found that you can basically mimic the 0.91 behaviour (until
they finish bringing in model-inheritance..at which time I expect this
backwards hack to break totally) by doing inheritance as you did it in
0.91 but you need to define the manager manually for your subclassed
objects.  This code seems to work:

class Foo(models.Model):
name = models.CharField(maxlength = 80)

def __str__(self):
return "Foo %s" % self.name

def commit(self):
print "Doing commit on %s" % str(self)

class Admin:
pass

class Bar(Foo):
sub_name = models.CharField(maxlength = 80)
objects = models.Manager()

def __str__(self):
return "Bar %s/%s" % (self.name, self.sub_name)

class Admin:
pass


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Validation based on a related object field (ForeignKey) value

[mamcxyz]

Forget this code... really not work :(

The reason is that is necesary save *first* the parent then go for
children.

I test several things, like do the save in the child (expecting that
"detect" is their parent is not saved) but this only insert orphan
childs...

Now we are 2 with the same question ;)


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Subversion Repository is Asking for a User Name and Password

[Paul Childs]

I would really like to download the developer version.

I am using TortoiseSVN.

When I perform an import I get a dialogue that says...

 Django SVN repository
Requests a username and a password

Could someone please help me out.

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
-~--~~~~--~~--~--~---

Re: Subversion Repository is Asking for a User Name and Password

[Jeremy Dunck]

On 6/7/06, Paul Childs <[EMAIL PROTECTED]> wrote:
>
> I would really like to download the developer version.
>
> I am using TortoiseSVN.
>
> When I perform an import I get a dialogue that says...

You don't want "import", you want "checkout".

(In explorer, right-click on the folder you'd like to check out to,
choose "SVN Checkout...", and put this in the "URL of repository"
input:
http://code.djangoproject.com/svn/django/trunk/

Cheers,
  Jeremy

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

LOST-theories.com

[Don Arbow]

I'm sure it just slipped his mind but Jeff Croft has a new website up  
that allows LOST fans to comment on theories about episodes. I'm not  
really a LOST fan, but the site is cool, and written in Django. The  
even cooler part is you can download the source code.

According to his blog, it took him less than two weeks to crank it  
out and he admits he's not a programmer, but one heckuva designer.

http://www2.jeffcroft.com/2006/jun/06/lost-theories-with-source-code/

http://lost-theories.com

Don

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Subversion Repository is Asking for a User Name and Password

[Paul Childs]

Thanks very much Jeremy. Worked like a charm.
Regards,
/Paul


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Weird behaviour

[Elver Loho]

request.session seems to be storing things beyond me closing the
Django development server. This is sort of weird. Is it a feature or a
bug? Because, I'd prefer a clean slate every time I run the devserver.


Example code:
def foo(request):

foo = request.session.get("foo", None)

print "foo is", str(foo)

if foo == None:
request.session["foo"] = "Haha! Not None!"

Behaviour:
# Server started
# First run: "foo is None"
# Second run: "foo is Haha! Not None!"
# Server closed

# Server started
# First run: "foo is Haha! Not None!"


This behaviour is just way too weird. I'm currently developing with
Django for work and with CherryPy for a side project and CherryPy
doesn't store sessions beyond the lifetime of the server. I sort of
didn't expect this behaviour from Django either.

So, this a bug or a feature? And how can I turn it off?


Elver

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Adrian Holovaty]

On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> This behaviour is just way too weird. I'm currently developing with
> Django for work and with CherryPy for a side project and CherryPy
> doesn't store sessions beyond the lifetime of the server. I sort of
> didn't expect this behaviour from Django either.
>
> So, this a bug or a feature? And how can I turn it off?

Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.

http://www.djangoproject.com/documentation/sessions/#browser-length-sessions-vs-persistent-sessions

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[arthur debert]

Hi Elver.

This is a feature.
This behaviour depends on wheter you want yor sessions to expire and
when. More details in the docs:
http://www.djangoproject.com/documentation/sessions/#browser-length-sessions-vs-persistent-sessions

arthur


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Admin site/ManyToManyField problem

[Dagur]

Hi,

I'm having problems with ManyToManyField not appearing in the admin
site. I think it's best explained with this screenshot (look at the
bottom): http://dagur.sytes.net/static/djangoshot.jpg
I also put the source for the models in on pasted:
http://paste.e-scribe.com/372/


I'm at the point where I think i've tried everything and have started
blaming Django. Is this a bug or am I overlooking something?


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Elver Loho]

On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > This behaviour is just way too weird. I'm currently developing with
> > Django for work and with CherryPy for a side project and CherryPy
> > doesn't store sessions beyond the lifetime of the server. I sort of
> > didn't expect this behaviour from Django either.
> >
> > So, this a bug or a feature? And how can I turn it off?
>
> Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.

That simply sets the cookie to expire when the browser is closed.
That's not a solution since I've got Firefox open in 3-4 workspaces
here, with several tabs in each instance. I'm sure as hell *not* going
to close every last instance every time I change something in the code
and want to start all over again...

I think it's a bug that Django's session variables survive when the
Django development server is closed. Yes, when I close the browser,
it's nice that I can start it again and be greeted with my session.
However, when I close the server, I expect the session to be lost.

How can I tell Django to store the sessions in memory and drop them
when the server is closed?


Elver

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Adrian Holovaty]

On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> I think it's a bug that Django's session variables survive when the
> Django development server is closed. Yes, when I close the browser,
> it's nice that I can start it again and be greeted with my session.
> However, when I close the server, I expect the session to be lost.
>
> How can I tell Django to store the sessions in memory and drop them
> when the server is closed?

Django sessions are stored in the database, not in memory. That
decision has its roots in the fact that Django's recommended
development platform is mod_python, and mod_python processes don't
share memory. Plus, the permanence of having session data in the
database is just more robust; personally, I'm scared by storing
important data only in memory.

If you want to do this nevertheless, you can easily write a middleware
class that works like Django's SessionMiddleware but saves its session
data in memory. You could also check out the patch here:

http://code.djangoproject.com/ticket/2066

Hope this helps,
Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Malcolm Tredinnick]

On Thu, 2006-06-08 at 02:21 +0300, Elver Loho wrote:
> On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > This behaviour is just way too weird. I'm currently developing with
> > > Django for work and with CherryPy for a side project and CherryPy
> > > doesn't store sessions beyond the lifetime of the server. I sort of
> > > didn't expect this behaviour from Django either.
> > >
> > > So, this a bug or a feature? And how can I turn it off?
> >
> > Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.
> 
> That simply sets the cookie to expire when the browser is closed.
> That's not a solution since I've got Firefox open in 3-4 workspaces
> here, with several tabs in each instance. I'm sure as hell *not* going
> to close every last instance every time I change something in the code
> and want to start all over again...
> 
> I think it's a bug that Django's session variables survive when the
> Django development server is closed. Yes, when I close the browser,
> it's nice that I can start it again and be greeted with my session.
> However, when I close the server, I expect the session to be lost.

Move beyond the development server for a moment and think about sessions
in the more general concept. Generally, it is not desirable for a
client's session to be lost just because the backend webserver is
restarted. Session-based cookies behave according to browser lifetime,
not server lifetime.

However, if you want the server to no longer recognise the client's
cookie, then the solution is to clear out the django_session table from
the database each time. I'm not sure this is really something we want to
do each time we stop and start -- because most of the time you don't
want to have to re-login and everything. But if you do need it all the
time, then it is easy enough to create a shell script that runs "delete
from django_session" prior to doing "exec manage.py runserver". Or catch
the termination the dev server and do the deletion at that point,
although that is a little more fiddly.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Elver Loho]

On 6/8/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2006-06-08 at 02:21 +0300, Elver Loho wrote:
> > On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > >
> > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > > This behaviour is just way too weird. I'm currently developing with
> > > > Django for work and with CherryPy for a side project and CherryPy
> > > > doesn't store sessions beyond the lifetime of the server. I sort of
> > > > didn't expect this behaviour from Django either.
> > > >
> > > > So, this a bug or a feature? And how can I turn it off?
> > >
> > > Turn it off with the SESSION_EXPIRE_AT_BROWSER_CLOSE setting.
> >
> > That simply sets the cookie to expire when the browser is closed.
> > That's not a solution since I've got Firefox open in 3-4 workspaces
> > here, with several tabs in each instance. I'm sure as hell *not* going
> > to close every last instance every time I change something in the code
> > and want to start all over again...
> >
> > I think it's a bug that Django's session variables survive when the
> > Django development server is closed. Yes, when I close the browser,
> > it's nice that I can start it again and be greeted with my session.
> > However, when I close the server, I expect the session to be lost.

> Move beyond the development server for a moment and think about sessions
> in the more general concept.

The point is, I'm doing this on the development server. It's the
*development* server. It's not Apache with mod_python. And in Django's
docs it is said that people should not use the development server for
anything but, well, development.

Everything you've just said makes a lot of sense on a production
rollout. Yes, do keep sessions after shutdown. It's a great feature!
But this "feature" on the development server simply makes development
more difficult.

So, um, could someone add a feature to the SVN version to let me turn
this off? Please? Pretty please? With sugar on top? :)


Elver

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Adrian Holovaty]

On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> Everything you've just said makes a lot of sense on a production
> rollout. Yes, do keep sessions after shutdown. It's a great feature!
> But this "feature" on the development server simply makes development
> more difficult.
>
> So, um, could someone add a feature to the SVN version to let me turn
> this off? Please? Pretty please? With sugar on top? :)

This is too much feature creep for my liking, and I don't see how it
makes development more difficult for the common case. Just put these
two commands in a shell script and off you go:

python -c 'from django.contrib.sessions.models import Session; \
Session.objects.all().delete()'
python manage.py runserver

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Elver Loho]

On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > Everything you've just said makes a lot of sense on a production
> > rollout. Yes, do keep sessions after shutdown. It's a great feature!
> > But this "feature" on the development server simply makes development
> > more difficult.
> >
> > So, um, could someone add a feature to the SVN version to let me turn
> > this off? Please? Pretty please? With sugar on top? :)
>
> This is too much feature creep for my liking, and I don't see how it
> makes development more difficult for the common case. Just put these
> two commands in a shell script and off you go:
>
> python -c 'from django.contrib.sessions.models import Session; \
> Session.objects.all().delete()'
> python manage.py runserver

Hmmm... I'll do some thinking on this. Anyhow, someone said earlier
that keeping session variables in the database is a good idea in case
the server is shut down or crashes or whatnot.

I think it's a bad idea. For the same reason.

Suppose you have a controller function that sets a number of session
variables throughout its execution. Suppose the server loses power or
whatnot when the function is half way done. Now, half the session
variables that would be set are set and in the database. The other
half are not.

When the server comes back on, this inconsistency in the database
could cause all sorts of weird problems and bugs.

Suppose the session variable "logged_in" is set to "True", but the
execution stops right before "username" is set to the user's username.
When the server comes back online, you have a potential security
issue.

It makes no sense to persist sessions beyond server lifetime. If you
want to commit some change, commit it to the database. Session
variables should be treated as regular variables.


Elver

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Honza Král]

and do you really think that sessions are saved after each variable
set into the database?
I hope not...

they are probably only saved after the return of the view, or
somewhere around that point...

On 6/8/06, Elver Loho <[EMAIL PROTECTED]> wrote:
>
> On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > Everything you've just said makes a lot of sense on a production
> > > rollout. Yes, do keep sessions after shutdown. It's a great feature!
> > > But this "feature" on the development server simply makes development
> > > more difficult.
> > >
> > > So, um, could someone add a feature to the SVN version to let me turn
> > > this off? Please? Pretty please? With sugar on top? :)
> >
> > This is too much feature creep for my liking, and I don't see how it
> > makes development more difficult for the common case. Just put these
> > two commands in a shell script and off you go:
> >
> > python -c 'from django.contrib.sessions.models import Session; \
> > Session.objects.all().delete()'
> > python manage.py runserver
>
> Hmmm... I'll do some thinking on this. Anyhow, someone said earlier
> that keeping session variables in the database is a good idea in case
> the server is shut down or crashes or whatnot.
>
> I think it's a bad idea. For the same reason.
>
> Suppose you have a controller function that sets a number of session
> variables throughout its execution. Suppose the server loses power or
> whatnot when the function is half way done. Now, half the session
> variables that would be set are set and in the database. The other
> half are not.
>
> When the server comes back on, this inconsistency in the database
> could cause all sorts of weird problems and bugs.
>
> Suppose the session variable "logged_in" is set to "True", but the
> execution stops right before "username" is set to the user's username.
> When the server comes back online, you have a potential security
> issue.
>
> It makes no sense to persist sessions beyond server lifetime. If you
> want to commit some change, commit it to the database. Session
> variables should be treated as regular variables.
>
>
> Elver
>
> >
>


-- 
Honza Král
E-Mail: [EMAIL PROTECTED]
ICQ#:   107471613
Phone:  +420 606 678585

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Using the database backend for a non web app.

[Zarrabeitia]

Hello.
I'm developing a short app based on django. It is composed by a few
agents, and a web app to show the results. The agents are, of course,
not web based, but I'd like to reuse as much code as I can from the
webapp ("DRY"), specially the model (and the configurations in my
project's settings.py).

What would be the bast way to do this?

Regards,

Zarrabeitia.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[Elver Loho]

On 6/8/06, Honza Král <[EMAIL PROTECTED]> wrote:
> and do you really think that sessions are saved after each variable
> set into the database?
> I hope not...
>
> they are probably only saved after the return of the view, or
> somewhere around that point...

Alright then, my mistake. However, it still doesn't make sense to
store sessions on the development server. IMO.

>
> On 6/8/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> >
> > On 6/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > >
> > > On 6/7/06, Elver Loho <[EMAIL PROTECTED]> wrote:
> > > > Everything you've just said makes a lot of sense on a production
> > > > rollout. Yes, do keep sessions after shutdown. It's a great feature!
> > > > But this "feature" on the development server simply makes development
> > > > more difficult.
> > > >
> > > > So, um, could someone add a feature to the SVN version to let me turn
> > > > this off? Please? Pretty please? With sugar on top? :)
> > >
> > > This is too much feature creep for my liking, and I don't see how it
> > > makes development more difficult for the common case. Just put these
> > > two commands in a shell script and off you go:
> > >
> > > python -c 'from django.contrib.sessions.models import Session; \
> > > Session.objects.all().delete()'
> > > python manage.py runserver
> >
> > Hmmm... I'll do some thinking on this. Anyhow, someone said earlier
> > that keeping session variables in the database is a good idea in case
> > the server is shut down or crashes or whatnot.
> >
> > I think it's a bad idea. For the same reason.
> >
> > Suppose you have a controller function that sets a number of session
> > variables throughout its execution. Suppose the server loses power or
> > whatnot when the function is half way done. Now, half the session
> > variables that would be set are set and in the database. The other
> > half are not.
> >
> > When the server comes back on, this inconsistency in the database
> > could cause all sorts of weird problems and bugs.
> >
> > Suppose the session variable "logged_in" is set to "True", but the
> > execution stops right before "username" is set to the user's username.
> > When the server comes back online, you have a potential security
> > issue.
> >
> > It makes no sense to persist sessions beyond server lifetime. If you
> > want to commit some change, commit it to the database. Session
> > variables should be treated as regular variables.
> >
> >
> > Elver
> >
> > >
> >
>
>
> --
> Honza Král
> E-Mail: [EMAIL PROTECTED]
> ICQ#:   107471613
> Phone:  +420 606 678585
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Using the database backend for a non web app.

[Zarrabeitia]

Nevermind... Problem solved.

export DJANGO_SETTINGS_MODULE=

did the trick.

Thanks IRC!

Zarrabeitia.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Weird behaviour

[limodou]

On 6/8/06, Elver Loho <[EMAIL PROTECTED]> wrote:
>
> On 6/8/06, Honza Král <[EMAIL PROTECTED]> wrote:
> > and do you really think that sessions are saved after each variable
> > set into the database?
> > I hope not...
> >
> > they are probably only saved after the return of the view, or
> > somewhere around that point...
>
> Alright then, my mistake. However, it still doesn't make sense to
> store sessions on the development server. IMO.
>
I think clearing all sessions after closing development server maybe
just suit for your situation. And in my case, I'd never thought about
this problem after reading your email :). And I think it's not a
normal behavior to web server. So you could do just like Adiran
advised, either applying the patch, or clearing the session table
yourself. Even using development server, I think it works more like
practical environment more better.

-- 
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

'ManyToManyField' attribute error

[Mikeal Rogers]

Hiya,

I'm using the django trunk and tried to generate the SQL for a model  
I just wrote and got the following traceback;

 execute_manager(settings)
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/django/core/management.py", line 1255, in  
execute_manager
 execute_from_command_line(action_mapping, argv)
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/django/core/management.py", line 1222, in  
execute_from_command_line
 output = action_mapping[action](mod)
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/django/core/management.py", line 116, in  
get_sql_create
 final_output.extend(_get_many_to_many_sql_for_model(klass))
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/django/core/management.py", line 225, in  
_get_many_to_many_sql_for_model
 table_output.append('%s %s %s %s (%s),' % \
AttributeError: 'ManyToManyField' object has no attribute  
'm2m_column_name'

I looked through the ManyToMany class for a minute and the  
m2m_column_name assignments weren't removed or anything so I'm a bit  
perplexed as to what the issue is.

I'm using sqlite3.

Thanks,

-Mikeal

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: 'ManyToManyField' attribute error

[Malcolm Tredinnick]

Hi Mikeal,

On Wed, 2006-06-07 at 19:17 -0700, Mikeal Rogers wrote:
> Hiya,
> 
> I'm using the django trunk and tried to generate the SQL for a model  
> I just wrote and got the following traceback;
> 
>  execute_manager(settings)
>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/django/core/management.py", line 1255, in  
> execute_manager
>  execute_from_command_line(action_mapping, argv)
>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/django/core/management.py", line 1222, in  
> execute_from_command_line
>  output = action_mapping[action](mod)
>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/django/core/management.py", line 116, in  
> get_sql_create
>  final_output.extend(_get_many_to_many_sql_for_model(klass))
>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/django/core/management.py", line 225, in  
> _get_many_to_many_sql_for_model
>  table_output.append('%s %s %s %s (%s),' % \
> AttributeError: 'ManyToManyField' object has no attribute  
> 'm2m_column_name'
> 
> I looked through the ManyToMany class for a minute and the  
> m2m_column_name assignments weren't removed or anything so I'm a bit  
> perplexed as to what the issue is.
> 
> I'm using sqlite3.

This is pretty unusual. Would you be able to post the model that is
causing the problems? That might help debug it.

Thanks,
Malcolm


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: 'ManyToManyField' attribute error

[Mikeal Rogers]

Sure, Here you go,

class BItem(models.Model):

 #Date stuff
 created_on = models.DateTimeField(auto_now_add=True)
 last_edited_on = models.DateTimeField(auto_now=True)
 #Last Edited By
 last_edited_by = models.ForeignKey(User)

 #B information
 name = models.CharField(maxlength=1000)
 description = models.CharField(maxlength=6000)
 brewer = models.ForeignKey('BRItem')
 ingredients = models.ManyToManyField('IngredientItem')

 class Admin:
 pass

class PItem(models.Model):

 #Date stuff
 created_on = models.DateTimeField(auto_now_add=True)
 last_edited_on = models.DateTimeField(auto_now=True)
 #Last Edited By
 last_edited_by = models.ForeignKey(User)

 #P Information
 name = models.CharField(maxlength=1000)
 description = models.CharField(maxlength=6000)
 locations = models.ManyToManyField('PLocationItem')

 class Admin:
 pass

class PLocationItem(models.Model):

 #Date stuff
 created_on = models.DateTimeField(auto_now_add=True)
 last_edited_on = models.DateTimeField(auto_now=True)
 #Last Edited By
 last_edited_by = models.ForeignKey(User)

 #P Location Infromation
 street = models.CharField(maxlength=1000)
 city = models.CharField(maxlength=1000)
 state = models.USStateField()
 zipcode = models.IntegerField()

 class Admin:
 pass

class BRItem(models.Model):

 #Date stuff
 created_on = models.DateTimeField(auto_now_add=True)
 last_edited_on = models.DateTimeField(auto_now=True)
 #Last Edited By
 last_edited_by = models.ForeignKey(User)

 #BR information
 name = models.CharField(maxlength=1000)
 description = models.CharField(maxlength=6000)

-Mikeal


On Jun 7, 2006, at 7:31 PM, Malcolm Tredinnick wrote:

>
> Hi Mikeal,
>
> On Wed, 2006-06-07 at 19:17 -0700, Mikeal Rogers wrote:
>> Hiya,
>>
>> I'm using the django trunk and tried to generate the SQL for a model
>> I just wrote and got the following traceback;
>>
>>  execute_manager(settings)
>>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/django/core/management.py", line 1255, in
>> execute_manager
>>  execute_from_command_line(action_mapping, argv)
>>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/django/core/management.py", line 1222, in
>> execute_from_command_line
>>  output = action_mapping[action](mod)
>>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/django/core/management.py", line 116, in
>> get_sql_create
>>  final_output.extend(_get_many_to_many_sql_for_model(klass))
>>File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/django/core/management.py", line 225, in
>> _get_many_to_many_sql_for_model
>>  table_output.append('%s %s %s %s (%s),' % \
>> AttributeError: 'ManyToManyField' object has no attribute
>> 'm2m_column_name'
>>
>> I looked through the ManyToMany class for a minute and the
>> m2m_column_name assignments weren't removed or anything so I'm a bit
>> perplexed as to what the issue is.
>>
>> I'm using sqlite3.
>
> This is pretty unusual. Would you be able to post the model that is
> causing the problems? That might help debug it.
>
> Thanks,
> Malcolm
>
>
> >


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: 'ManyToManyField' attribute error

[Malcolm Tredinnick]

Hi Mikael,

On Wed, 2006-06-07 at 19:41 -0700, Mikeal Rogers wrote:
> Sure, Here you go,
> 
> class BItem(models.Model):
> 
>  #Date stuff
>  created_on = models.DateTimeField(auto_now_add=True)
>  last_edited_on = models.DateTimeField(auto_now=True)
>  #Last Edited By
>  last_edited_by = models.ForeignKey(User)
> 
>  #B information
>  name = models.CharField(maxlength=1000)
>  description = models.CharField(maxlength=6000)
>  brewer = models.ForeignKey('BRItem')
>  ingredients = models.ManyToManyField('IngredientItem')

This is the problem line. You don't have an IngredientItem model in this
file. If your have defined IngredientItem elsewhere, then just import it
at the top of your file and reference it directly (remove the quotes and
just use IngredientItem there). Otherwise, work out what you renamed the
class to.

If I comment out this line, "manage.py sqlall ..." works for this
example.

Cheers,
Malcolm



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: 'ManyToManyField' attribute error

[Mikeal Rogers]

Thanks, that clears things up. I thought that if I sent it as a  
string rather than the class I could wait to define it until later.

-Mikeal

On Jun 7, 2006, at 8:30 PM, Malcolm Tredinnick wrote:

>
> Hi Mikael,
>
> On Wed, 2006-06-07 at 19:41 -0700, Mikeal Rogers wrote:
>> Sure, Here you go,
>>
>> class BItem(models.Model):
>>
>>  #Date stuff
>>  created_on = models.DateTimeField(auto_now_add=True)
>>  last_edited_on = models.DateTimeField(auto_now=True)
>>  #Last Edited By
>>  last_edited_by = models.ForeignKey(User)
>>
>>  #B information
>>  name = models.CharField(maxlength=1000)
>>  description = models.CharField(maxlength=6000)
>>  brewer = models.ForeignKey('BRItem')
>>  ingredients = models.ManyToManyField('IngredientItem')
>
> This is the problem line. You don't have an IngredientItem model in  
> this
> file. If your have defined IngredientItem elsewhere, then just  
> import it
> at the top of your file and reference it directly (remove the  
> quotes and
> just use IngredientItem there). Otherwise, work out what you  
> renamed the
> class to.
>
> If I comment out this line, "manage.py sqlall ..." works for this
> example.
>
> Cheers,
> Malcolm
>
>
>
> >


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django on Intel mac?

[Greg Harman]

Jeremy Dunck wrote:
> What error are you getting?

$ sudo python setup.py build
Password:
running build
running build_py
copying MySQLdb/release.py -> build/lib.macosx-10.4-fat-2.4/MySQLdb
running build_ext
building '_mysql' extension
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g
-bundle -undefined dynamic_lookup
build/temp.macosx-10.4-fat-2.4/_mysql.o
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o
build/temp.macosx-10.4-fat-2.4/_mysql_results.o -L/opt/local/lib/mysql
-L/opt/local/lib -lmysqlclient_r -lz -lm -lssl -lcrypto -o
build/lib.macosx-10.4-fat-2.4/_mysql.so
/usr/bin/ld: for architecture i386
/usr/bin/ld: multiple definitions of symbol __mysql_DataError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of __mysql_DataError
in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_DataError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_DatabaseError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_DatabaseError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_DatabaseError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_Error
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of __mysql_Error in
section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_Error in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_IntegrityError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_IntegrityError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_IntegrityError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_InterfaceError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_InterfaceError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_InterfaceError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_InternalError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_InternalError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_InternalError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_MySQLError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_MySQLError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_MySQLError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_NotSupportedError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_NotSupportedError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_NotSupportedError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_OperationalError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_OperationalError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_OperationalError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_ProgrammingError
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_ProgrammingError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_ProgrammingError in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_Warning
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of __mysql_Warning
in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_Warning in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol __mysql_server_init_done
build/temp.macosx-10.4-fat-2.4/_mysql.o definition of
__mysql_server_init_done in section (__DATA,__data)
build/temp.macosx-10.4-fat-2.4/_mysql_connections.o definition of
__mysql_server_init_done in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_results.o definition of
__mysql_DataError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_results.o definition of
__mysql_DatabaseError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_results.o definition of
__mysql_Error in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_results.o definition of
__mysql_IntegrityError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_results.o definition of
__mysql_InterfaceError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_results.o definition of
__mysql_InternalError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_results.o definition of
__mysql_MySQLError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4/_mysql_results.o definition of
__mysql_NotSupportedError in section (__DATA,__common)
build/temp.macosx-10.4-fat-2.4

Re: Django on Intel mac?

[Greg Harman]

Corey Oordt wrote:
> I have  MacBook, and although it was a challenge to get everything up
> and running, I ended up using darwinports to install apache 2, mysql
> 5 and python 2.4.
>
> Everything is working really well now

Yeah, the only cases I've read about where people have gotten this
working on the Intel Mac has been through darwinports.  I was really
hoping to avoid that and use independently-installed packages (such as
the pythonmac.org Universal distribution), and my currently-installed
MySql, which has been on my system for quite some time and has data I'd
like to keep - I'm not really keen on having two instances of MySQL or
having to port data from one to the other because of build/install
issues.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Context as Stack?

[mazurin]

Hi Eugene,

  Thanks for this example. I think it'll be helpful for me. I'm
working on something like this right now, where I need to generate a
whole bunch of small and simple subtemplates inside of a main layout
template.

  I was worried that I might have to write a custom tag -- I can, but
it didn't feel right -- but this solution seems much more logical.

mikah

--


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Catching a failed response

[Ivan Sagalaev]

Jeremy Dunck wrote:

>It sounds to me like "Exception Middleware" needs to be renamed to
>"View Exception Middleware" and you should write a patch for "Response
>Exception Middleware".  ;-)
>  
>
I don't think it's possible. In the wsgi.py it's just:

return response.iterator

.. and the WSGI server does all the iteration itself. So the only 
"effect" of write error would be cease of calls to the iterator.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---