Re: syncdb is not doing anything

[Luc Saffre]

I often got confused because when a modification in my models.py causes
it to raise an ImportError (for example you try to import a non-existing
module from your module.py), then several parts of Django (including
syncdb) simply act as if your application wasn't installed, without any
warning.
Maybe that's also your problem?
Luc

On 6.07.2009 8:17, chefsmart wrote:
> Hi,
> 
> I have been working on an app for some time now. I have been using the
> Django svn trunk.
> 
> I have a lot of data in the database. Today I modified a couple of
> fields and added a couple of fields (date and char fields) to three of
> my models. No fields have been removed from the original model
> definitions.
> 
> When I do "python manage.py sql myapp" the output shows some
> inconsistent sql that is syntactically wrong. I thought this may
> simply be a jumbled string output problem, so I ran syncdb anyway.
> However, syncdb is not doing anything. I mean no messages, no error
> outputs, nothing. It just simply exits with a blank line output. I
> checked my database (mysql) and there were no changes made. So syncdb
> is not doing anything, even though the sqlall output shows it wants to
> do a lot of sql commands.
> 
> Moreover, the manage.py sql myapp command shows that syncdb wants to
> drop and reconstruct tables that I have not modified, and that are not
> related to the modified models in any way.
> 
> What could be going on?
> 
> Regards,
> CM
> > 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

inheriting Model more than once

[Luc Saffre]

"""
Can somebody explain why this testcase fails? It looks as if the
attribute 'a' passed to the E instance just gets ignored.
I guess that it has to do with the fact that E inherits Model more than
once.

  >>> i1 = D(a='D')
  >>> i1.a
  'D'

  >>> i2 = E(a='E')
  >>> i2.a
  'E'

The failure is::

  Failed example:
  i2.a
  Expected:
  'E'
  Got:
  ''

To try this test, save the body of this mail as a file models.py
together with an empty __init__.py in some new directory on your
PYTHONPATH, add this to your INSTALLED_APPS and then run "manage.py test".

"""

from django.db import models

class A(models.Model):
a = models.CharField(max_length=100)
class Meta:
abstract = True

class B(A): pass
class C(A): pass

class D(B): pass
class E(B,C): 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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: inheriting Model more than once

[Luc Saffre]

On 14.07.2009 17:23, Alex Gaynor wrote:
> This looks like an instance of this:
> http://code.djangoproject.com/ticket/10808 bug.

Thanks, Alex. I applied patch 10808.diff and now it works.

Luc

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Unittests

[Luc Saffre]

On 16.04.2009 0:04, Daniel Joshua Worth wrote:
> I'm trying to learn unit test and have a unit test for a model in
> test.py and have a test set up to fail.
> When I run manage.py test it returns that all tests are OK.
> If I run manage.py test  it returns OK.
> If I run manage.py test . it returns OK.
> If I run manage.py test .. if Fails.
> What gives. Am I missing something as far as unittests are concerned? It
> should Fail every time or it's not much of a test.

Can you send your test.py file to the list?
You should rather not name it "test.py" because there is a standard
Python module with that name.

Luc

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

django.contrib.auth tests fail

[Luc Saffre]

Hello,

when I run ``manage.py test`` to test my Django applications, then I
also get a lot of test failures for django.contrib.auth. Most of them
are TemplateDoesNotExist errors (complete log see below). This even
happens in a virgin project:

1. Run ``django-admin startproject foo``
2. Edit oen line in foo/settings.py:
 DATABASE_ENGINE = 'sqlite3'
3. Run ``python manage.py test``

Is that normal? What can I do to get rid of these errors?

Luc


T:\svnwork\lino\trunk\src\mysites\authtest>python manage.py test
Creating test database...
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Installing index for auth.Permission model
Installing index for auth.Message model
EE..E...EEE..
==
ERROR: test_password_change_fails_with_invalid_old_password
(django.contrib.auth.tests.views.ChangePasswordTest)
--
Traceback (most recent call last):
  File "l:\snapshot\django\django\contrib\auth\tests\views.py", line
156, in test_password_change_fails_with_invalid_old
_password
'new_password2': 'password1',
  File "l:\snapshot\django\django\test\client.py", line 313, in post
response = self.request(**r)
  File "l:\snapshot\django\django\core\handlers\base.py", line 92, in
get_response
response = callback(request, *callback_args, **callback_kwargs)
  File "l:\snapshot\django\django\contrib\auth\decorators.py", line 78,
in __call__
return self.view_func(request, *args, **kwargs)
  File "l:\snapshot\django\django\contrib\auth\views.py", line 160, in
password_change
}, context_instance=RequestContext(request))
  File "l:\snapshot\django\django\shortcuts\__init__.py", line 20, in
render_to_response
return HttpResponse(loader.render_to_string(*args, **kwargs),
**httpresponse_kwargs)
  File "l:\snapshot\django\django\template\loader.py", line 103, in
render_to_string
t = get_template(template_name)
  File "l:\snapshot\django\django\template\loader.py", line 81, in
get_template
source, origin = find_template_source(template_name)
  File "l:\snapshot\django\django\template\loader.py", line 74, in
find_template_source
raise TemplateDoesNotExist, name
TemplateDoesNotExist: registration/password_change_form.html

==
ERROR: test_password_change_fails_with_mismatched_passwords
(django.contrib.auth.tests.views.ChangePasswordTest)
--
Traceback (most recent call last):
  File "l:\snapshot\django\django\contrib\auth\tests\views.py", line
167, in test_password_change_fails_with_mismatched_
passwords
'new_password2': 'donuts',
  File "l:\snapshot\django\django\test\client.py", line 313, in post
response = self.request(**r)
  File "l:\snapshot\django\django\core\handlers\base.py", line 92, in
get_response
response = callback(request, *callback_args, **callback_kwargs)
  File "l:\snapshot\django\django\contrib\auth\decorators.py", line 78,
in __call__
return self.view_func(request, *args, **kwargs)
  File "l:\snapshot\django\django\contrib\auth\views.py", line 160, in
password_change
}, context_instance=RequestContext(request))
  File "l:\snapshot\django\django\shortcuts\__init__.py", line 20, in
render_to_response
return HttpResponse(loader.render_to_string(*args, **kwargs),
**httpresponse_kwargs)
  File "l:\snapshot\django\django\template\loader.py", line 103, in
render_to_string
t = get_template(template_name)
  File "l:\snapshot\django\django\template\loader.py", line 81, in
get_template
source, origin = find_template_source(template_name)
  File "l:\snapshot\django\django\template\loader.py", line 74, in
find_template_source
raise TemplateDoesNotExist, name
TemplateDoesNotExist: registration/password_change_form.html

==
ERROR: Logout without next_page option renders the default template
--
Traceback (most recent call last):
  File "l:\snapshot\django\django\contrib\auth\tests\views.py", line
216, in test_logout_default
response = self.client.get('/logout/')
  File "l:\snapshot\django\django\test\client.py", line 281, in get
response = self.request(**r)
  File "l:\snapshot\django\django\test\client.py", line 225, in request
response = self.handler(environ)
  File "l:\snapshot\django\django\test\client.py", line 69, in __call__
response = self.get_response(request)
  File "l:\snapshot\django\django\core\handlers\base.py", line 134, in
get_response
return self.handle_uncaught_exception(request, resolver, exc_info)
  File "l:\snapshot\django\django\core\handlers\base.py", line 165

Re: django.contrib.auth tests fail

[Luc Saffre]

On 13.05.2009 18:55, Michael wrote:
> Auth leans on some templates in django.contrib.admin for the tests. This
> is known, though not ideal. If you added django.contrib.admin to your
> installed apps, the failures should go away.
> 
> I hope that helps,
> Michael

Thanks! That helped.

And I discovered that it also depends on django.contrib.sites.

The section "Installation" of the auth documentation page
http://docs.djangoproject.com/en/dev/topics/auth/
might mention that auth depends on sites and admin.

Luc

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Journals and Documents in an accounting application

[Luc Saffre]

Hello,

here is a code example that illustrates how I plan to implement journals
in an accounting application. The attached file models.py contains the
details. I saved it (together with an empty __init__.py) in a new
directory "journals" under django/tests/modeltests of my SVN working
copy (which I just updated to revision 10921), then I went to
django/tests and run the command::

  python runtests.py --settings=settings_memory -v1 journals

to test it. I'm almost happy, but I get an unexpected result in line 60::

  File "L:\snapshot\django\tests\modeltests\journals\models.py", \
 line 60, in modeltests.journals.models
  Failed example:
  INV.lastnum
  Expected:
  1
  Got:
  2

I don't understand why INV.lastnum returns 2 and not 1 at this place. If
you see the reason, then please tell me!

Also, I'd be glad to get feedback on my way of solving this particular
problem, and I suggest to add this to the Django tests collection once I
got it working.

Luc

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~----~--~~--~--~---

"""
Author: Luc Saffre 2009-06-04

A journal is a sequence of numbered documents in accounting applications.
A Journal instance knows the model used for documents in this journal.
A Document instance can look at its journal to find out which subclass 
of Document it is.
The journal also manages a counter "lastnum" to control the numbering
of documents. 

First we create two journals and some documents::

  >>> ORD = Journal(id="ORD",name="Orders",doctype=0)
  >>> ORD.save()
  >>> INV = Journal(id="INV",name="Invoices",doctype=1,force_sequence=True)
  >>> INV.save()
  >>> ORD.create_document().save()
  >>> INV.create_document().save()
  >>> ORD.create_document().save()
  >>> ORD.create_document().save()
  >>> INV.create_document().save()
  >>> for doc in Document.objects.all():
  ...print unicode(doc)
  ORD#1 (1)
  INV#1 (2)
  ORD#2 (3)
  ORD#3 (4)
  INV#2 (5)

You can delete any document, leaving a hole in the sequence, 
and this number will not be reused.

  >>> ORD.lastnum
  3
  >>> Document.objects.get(pk=1).delete()
  Deleting ORD#1 (1)
  >>> ORD.lastnum
  3
  >>> doc = ORD.create_document()
  >>> doc.save()
  >>> print doc
  ORD#4 (6)

For invoices, ``force_sequence=True`` means that it is not allowed to
delete documents in the middle because this would leave a hole in the
sequence::

  >>> Document.objects.get(pk=2).delete()
  Traceback (most recent call last):
  ...
  DocumentError: INV#1 (2) is not the last document in journal

It's okay to delete the last invoice of a journal. 
This will also decrement lastnum so that the number will be reused::

  >>> INV.lastnum
  2
  >>> doc = Document.objects.get(pk=5)
  >>> print doc
  INV#2 (5)
  >>> doc.delete()
  Deleting INV#2 (5)
  >>> INV.lastnum
  1
  >>> doc = INV.create_document()
  >>> doc.save()
  >>> print doc
  INV#2 (7)

Here is again the list of documents in the database after these
operations::

  >>> for doc in Document.objects.all():
  ...print unicode(doc)
  INV#1 (2)
  ORD#2 (3)
  ORD#3 (4)
  ORD#4 (6)
  INV#2 (7)

"""

from django.db import models

class DocumentError(Exception):
  pass
  
DOCTYPE_CLASSES = []
DOCTYPE_CHOICES = []

def register_doctype(cl):
n = len(DOCTYPE_CHOICES)
DOCTYPE_CHOICES.append((n,cl.__name__))
DOCTYPE_CLASSES.append(cl)

class Journal(models.Model):

id = models.CharField(max_length=4,primary_key=True)
name = models.CharField(max_length=100)
doctype = models.IntegerField(choices=DOCTYPE_CHOICES)
lastnum = models.IntegerField(blank=True,null=True,default=0)
force_sequence = models.BooleanField(default=False)

def create_document(self,**kw):
cl = DOCTYPE_CLASSES[self.doctype]
if not kw.has_key('number'):
kw['number'] = self.lastnum + 1
doc = cl(journal=self,**kw)
self.lastnum = kw['number'] 
self.save()
return doc

def on_delete_document(self,doc):
if doc.number == self.lastnum:
#print "foo", self.lastnum
self.lastnum -= 1
#print "bar", self.lastnum
self.save()
elif self.force_sequence:
raise Document

Re: Journals and Documents in an accounting application

[Luc Saffre]

On 4.06.2009 19:46, Karen Tracey wrote:
> Well the problems the test reveal with the in-memory Journal instance
> having a stale lastnum after documents are deleted is a bit of a gotcha
> with they way you have set this up.  Though it's easily fixed in the
> test, I fear actual code that uses these models would easily run afoul
> of the same problem.

Thanks, Karen, for your explanations. Now I understood the problem. Yes,
the other errors produced by this example were of course due to the same
mistake.

But what can I do to avoid this gotcha? Is there a better way to set
this up?

> And I don't see why you are focused on adding tests for these models to
> Django itself.  Tests for your app's models belong with your app, not in
> the Django test suite.

I thought that this simplified case has some didactic value... but you
are right, I won't insist on having them added to Django.

Luc

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Journals and Documents in an accounting application

[Luc Saffre]

On 5.06.2009 4:39, Karen Tracey wrote:
> My first thought would be to not store that value in a model at all, but
> rather pull it from the DB as max of the appropriate column when needed. 

Yes, that would make things easier and more straightforward.
But some features that are easy with my setup will then become more
difficult:
- leave out a series of numbers and create them later
- start a journal with another number than 1
- create a document with a manually attributed number to fill a hole

But thinking now about it, I have the feeling that you are right: I'll
use the straightforward method ,and I will just have to use different
ways to solve the exceptional cases.

Thanks for your thoughts and greetings from Estonia!
Luc

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: imported models

[Luc Saffre]

On 13.06.2009 21:19, Luc Saffre wrote:
> Can somebody explain what's going wrong there?

Okay, I now looked into Django's code and understood a few things:

I imagined that Django finds out the models of a project by looking into
the "models" module of each application. That's wrong.
django.models.loading just imports each "models" module. The models
register themselves (or rather, their metaclass does this job). So the
plugins_b table appears although it is not in models, just because it is
part of the p1 module.
And the tables didn't get created because the models in p1 and p2 have
"plugins" as their "application label". No application has this label,
so they get ignored in initdb. When defining models in such an unusual
place, you can use Meta.app_label. The example works when you add to
each model definition:

class Meta:
app_label = 'a1'


Luc

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: multitable inheritance - child doesn't accept parent link

[Luc Saffre]

On 18.06.2009 14:05, Ramiro Morales wrote:
> 
> Why do you thing there should be a automatically created one to one 
> relationship from Customer to Contact named "contact"?.

Why I think there should be a automatic one-to-one relation from
Customer to Contact? Because that's what the MTI documentation says (as
far as I understand it):

> Specifying the parent link field
>
> As mentioned, Django will automatically create a OneToOneField
> linking your child class back any non-abstract parent models. If you
> want to control the name of the attribute linking back to the parent,
> you can create your own OneToOneField and set parent_link=True to
> indicate that your field is the link back to the parent class.

http://docs.djangoproject.com/en/dev/topics/db/models/#specifying-the-parent-link-field

It's true that I didn't notice that the example
(http://www.djangoproject.com/documentation/models/one_to_one/) isn't
about MTI at all (rather a kind of emulation).

Okay, when I add an explicit parent link in my example:

contact = models.OneToOneField(contacts.Contact,parent_link=True)

then the TypeError disappears. But still I would now expect that the
following works:

  >>> c = Customer(contact=luc)
  >>> c.save()
  >>> c.last_name
  Saffre

But it fails, saying:

  Failed example:
  c.last_name

  Expected:
  Saffre
  Got:
  ''

It looks as if Django doesn't "copy" the values of the existing Contact
into the Customer. The last_name field was inherited (it didn't say
"AttributeError: 'Customer' object has no attribute 'last_name'") but it
is empty.

Note that I'm using Django development version, revision 11066...

I guess that this is a bug and that it has to do with ticket #7623
(http://code.djangoproject.com/ticket/7623).

Thus cc to django-developers and a new very short example showing the
problem. (Should I wait for feedback from developers before opening a
new ticket?)

Luc


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

"""

Small example for the problem described in ticket #7623
(http://code.djangoproject.com/ticket/7623)

With revision 11066, the following doctest fails::

Failed example:
r
Expected:

Got:



>>> p1 = Place(name='Demon Dogs')
>>> p1.save()

# Create a Restaurant from this Place. 
>>> r = Restaurant(place=p1, serves_hot_dogs=True)
>>> r.save()
>>> r


"""

from django.db import models

class Place(models.Model):
name = models.CharField(max_length=50)

def __unicode__(self):
return self.name

class Restaurant(Place):
  
serves_hot_dogs = models.BooleanField()

# the following explicit parent_link should not be necessary according to 
# http://docs.djangoproject.com/en/dev/topics/db/models/#specifying-the-parent-link-field
place = models.OneToOneField(Place,parent_link=True)

Re: Multi-table Inheritance: How to add child to parent model?

[Luc Saffre]

I had now a similar problem and started to write a generic solution
which is certainly not perfect, but works for me. Here is a detailed
description:

http://lino.saffre-rumma.net/autodoc/lino.test_apps.1.html

Looking forward to any comments.
Luc


On 7.11.2010 17:19, ringemup wrote:
> Thank you for the pointer to ticket #11618, Stefan.  At this point, I
> don't care if the workaround is ugly -- if it actually works, at least
> I'll be able to move forward with this project.  I'll test it out and
> check back in to confirm whether it does.
> 
> 
> On Nov 7, 9:03 am, Stefan Foulis  wrote:
>> As far as I know there is no existing api to convert a 'Place' into a
>> 'Restaurant' with multi-table inheritance in django. There is a ticket
>> about this [1]. And in another ticket [2] that is marked as a
>> duplicate but seems to have an example of how to solve this problem
>> until there is a standard api for the operation. Translated to the
>> Restaurant example this would be:
>>
>> restaurant = Restaurant(place_ptr = place)
>> for f in place._meta.local_fields: setattr(restaurant, f.name,
>> getattr(place, f.name))
>> restaurant.save()
>>
>> [1]http://code.djangoproject.com/ticket/7623
>> [2]http://code.djangoproject.com/ticket/11618
>>
>> On Nov 4, 9:25 pm, ringemup  wrote:
>>
>>> I have an existing model that I want to extend using multi-table
>>> inheritance.  I need to create a child instance for each parent
>>> instance in the database, but I can't figure out how.  I've scoured
>>> google and haven't come up with anything other than Ticket #7623[1].
>>> Here are some of the things I've tried...
>>
>>> Let's adapt the Place / Restaurant example from the docs:
>>
>>> class Place(models.Model):
>>> name = models.CharField(max_length=50)
>>> address = models.CharField(max_length=80)
>>
>>> class Restaurant(Place):
>>> place = models.OneToOneField(Place, parent_link=True,
>>> related_name='restaurant')
>>> serves_hot_dogs = models.BooleanField()
>>> serves_pizza = models.BooleanField()
>>
>>> I want to do the following, in essence:
>>
>>> for place in Place.objects.all():
>>>   restaurant = Restaurant(**{
>>> 'place': place,
>>> 'serves_hot_dogs': False,
>>> 'serves_pizza': True,
>>>   })
>>>   restaurant.save()
>>
>>> Of course, doing this tries to also create a new Place belonging to
>>> the new Restaurant, and throws an error because no values have been
>>> specified for the name and address fields.  I've also tried:
>>
>>> for place in Place.objects.all():
>>>   restaurant = Restaurant(**{
>>> 'serves_hot_dogs': False,
>>> 'serves_pizza': True,
>>>   })
>>>   place.restaurant = restaurant
>>>   place.save()
>>
>>> This, however, doesn't create any records in the restaurant table.
>>
>>> Any suggestions?
>>
>>> [1]http://code.djangoproject.com/ticket/7623
>>
>>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django for desktop app development

[Luc Saffre]

Hi Muhammad,

we do write and maintain desktop applications for our customers using
Django. But before feeling able to offer this we wrote Lino, a kind of
"intrusive" Django application which replaces the Admin by a new
desktop-like user interface (currently based on ExtJS). It also replaces
the permissions system by a class-based approach. Because of its
intrusiveness we consider it a framework based on Django. Our first
production site went alive in January 2011. We believe that Lino has a
bright future and should be used by other companies as well.
Lino framework: http://lino-framework.org
My company: https://saffre-rumma.net/

Luc

On 07.09.2018 15:16, Muhammad Dilshad Khaliq wrote:
> I am final year student of software engineering.My final year project
> is about fee management system where student submit fee online and
> administrator use this system for managing fee and scholarship of
> student and notifying them about their any issue.So can i  make web
> based application or desktop application for administration site and
> notify student through mobile application.?*Is it good idea to use
> Django for desktop application?*  
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users+unsubscr...@googlegroups.com
> .
> To post to this group, send email to django-users@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/199c0ed7-ce95-42e4-b391-462a491c22fe%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/891bbd90-86a1-54f7-e8d2-88c06d2a39ee%40gmx.net.
For more options, visit https://groups.google.com/d/optout.