Re: WatchmanReloader does never reload
Hallöchen! Robbi Nespu writes: > On 18/1/2022 5:29 pm, Torsten Bronger wrote: > >> The reloader for “runserver” does not reload at all for me, and I >> have no clue how to debug this. I am using Django 3.2.10 under >> Ubuntu, and both the StatReloader and WatchmanReloader simply do >> nothing. Including no error output. >> >> [...] > > Do you use docker? No. Command line on bare metal. > anyway what is your DEBUG value on settings.py ? DEBUG is True. > Try to change port binding to another value, perhaps.. the target > port already occupied. I can open the test server in the browser. FWIW, watchman-wait if called directly works as I expect. Tschö, Torsten. -- Torsten Bronger -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87h7a1nz2t.fsf%40physik.rwth-aachen.de.
WatchmanReloader does never reload
Hallöchen! The reloader for “runserver” does not reload at all for me, and I have no clue how to debug this. I am using Django 3.2.10 under Ubuntu, and both the StatReloader and WatchmanReloader simply do nothing. Including no error output. That both do not work points to a really stupid error between screen and chair, but I really do modify files in the tree that I call manage.py in (and for). I would prefer the WatchmanReloader, so my question is, how do I get any debug info out of it? Tschö, Torsten. -- Torsten Bronger -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87zgnto0io.fsf%40physik.rwth-aachen.de.
@mark_safe decorator and filters & tags
Hallöchen! Up to Django 1.11, I had the following pattern frequently in my code: @register.filter @mark_safe def myfilter(value): ... Smilarly for tags. This has worked for years, however, with Django 2.0, this leads to the TemplateError saying that "myfilter requires 0 arguments, 1 provided". For tags, it results in an IndexError because the "params" list when processing the tag is empty. If I make @mark_safe the outmost (i.e. first) decorator, no exception occurs – but the output is escaped HTML instead of passed-through HTML. The safe and obvious workaround is to use mark_safe() as a function instead of @mark_safe. Would be a pity, though. Is this a bug or am I doing something wrong? Tschö, Torsten. -- Torsten Bronger -- 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/87vabxj2s4.fsf%40wilson.bronger.org. For more options, visit https://groups.google.com/d/optout.
Re: New-style middleware
Hallöchen! Carl Meyer writes: > [...] > > Yes, I agree with you that for middleware which don't implement > request or response processing (only process_exception, > process_view, or process_template_response), the new style is less > concise, because it requires implementing a boilerplate __init__ > and __call__. To be honest, the primary consideration in the new > middleware was request and response processing, and your case did > not receive as much attention as it perhaps should have. Thanks for the explanation! The boilerplate is ineed not too bad. I just wanted to make sure to not have overlooked something. Regards, Torste. -- Torsten Bronger -- 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/87inreqxer.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
New-style middleware
Hallöchen! Considering the following old-style middleware class: class ExceptionsMiddleware: def process_exception(self, request, exception): ... I convert this to new-style middleware by inserting two methods: class ExceptionsMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): return self.get_response(request) def process_exception(self, request, exception): ... Is this really correct? Actually, the old way looks more concise to me. In particular, is there a reason why Django does not provide a non-deprecated base class for middleware like: class Middleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): return self.get_response(request) (I know MiddlewareMixin but it is deprecated.) Tschö, Torsten. -- Torsten Bronger -- 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/87oa17kxsd.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: Python3 + makemessages = "invalid multibyte sequence"
Hallöchen! Torsten Bronger writes: > With Django 1.9.5 and Python 3, I get warnings like > > ./jb_common/templates/404.html.py:35: invalid multibyte sequence > > when I run "manage.py makemessages". The problem occurs only in > HTML files with (validly) UTF-8-encoded characters in them. In > the .po file, these characters are skipped. How can I fix this? > > The problem does not occur with Python 2. This seems to be the issue: https://code.djangoproject.com/ticket/26093 Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- 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/87d1p3tjrk.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Python3 + makemessages = "invalid multibyte sequence"
Hallöchen! With Django 1.9.5 and Python 3, I get warnings like ./jb_common/templates/404.html.py:35: invalid multibyte sequence when I run "manage.py makemessages". The problem occurs only in HTML files with (validly) UTF-8-encoded characters in them. In the .po file, these characters are skipped. How can I fix this? The problem does not occur with Python 2. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- 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/87zis81iwk.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Django docs confusing about timestamps and timezones
Hallöchen! On <https://docs.djangoproject.com/en/1.9/topics/i18n/timezones/#default-current-time-zone>, it says: For instance, use utcfromtimestamp() instead of fromtimestamp() – and don’t forget to set tzinfo to utc. But isn't it more senseful to say fromtimestamp(time.time(), utc) ? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- 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/87h9elgcuo.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: Test runner wants to run models package?!
Hallöchen! Tim Graham writes: > Could you try Python 3.4.x? The problem does not exist with Python 3.4.3. (Ubuntu 14.04) > I ran into some issues with Django's own test suite [0] due to > some import changes in Python 3.5 [1]. If I look at Python 3.5's release notes, the following is suspicious: Found packages are now checked for load_tests regardless of whether their path matches pattern, because it is impossible for a package name to match the default pattern. I understand this this way: The pattern still works for .py files but not for packages (__init__.py files). And since my models' __init__.py says from .physical_processes import * and the app is not yet set up, this breaks. Question is: Is is bad style to have a models *package* which collects alls models in its __init__.py, or has Django to be adapted to Python's new behaviour? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- 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/87potbc87j.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Test runner wants to run models package?!
Hallöchen! With Django 1.9.5 (rest are original Ubuntu 16.04 packages) and Python 3.5.1, "manage.py test myapp" tries to run the *models* package of myapp as a test module: user@localhost:~/src/myproject/myproject$ ./manage.py test myapp --pattern=invalid_pattern Creating test database for alias 'default'... Destroying old test database for alias 'default'... E == ERROR: myproject.myapp.models (unittest.loader._FailedTest) -- ImportError: Failed to import test module: myproject.myapp.models Traceback (most recent call last): File "/usr/lib/python3.5/unittest/loader.py", line 462, in _find_test_path package = self._get_module_from_name(name) File "/usr/lib/python3.5/unittest/loader.py", line 369, in _get_module_from_name __import__(name) File "/home/user/src/myproject/myproject/myapp/models/__init__.py", line 26, in from .physical_processes import * File "/home/user/src/myproject/myproject/myapp/models/physical_processes.py", line 66, in class Substrate(PhysicalProcess): File "/usr/local/lib/python3.5/dist-packages/django/db/models/base.py", line 102, in __new__ "INSTALLED_APPS." % (module, name) RuntimeError: Model class myproject.myapp.models.physical_processes.Substrate doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS. -- Ran 1 test in 0.000s FAILED (errors=1) Destroying test database for alias 'default'... I chose "invalid_pattern" to limit it to the models package. Without "--pattern", all *real* tests are run, too. Using Python2, everything is fine. Does anybody have an idea what's going on here? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- 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/87wpnkkoxl.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Wanted: Best practices for setting "_" (to ugettext/ugettext_lazy)
Hallöchen! This is not about where to use ugettext/ugettext_lazy. I know that. :-) But I was fed up with all those "_ = ugettext" scattered in my code and tried to find a more systematic approach. The following test program runs through: ugettext = lambda x: x ugettext_lazy = lambda x: x _ = ugettext_lazy def function(): assert _ == ugettext class A(object): assert _ == ugettext_lazy def method(self): assert _ == ugettext assert _ == ugettext_lazy assert _ == ugettext_lazy def function_b(): assert _ == ugettext _ = ugettext function() function_b() a = A() a.method() Do you think this is a good idea? Simply setting _ to ugetttext_lazy at the beginning of a module and to ugettext at the end (and dealing with the very few remaining exceptions)? How do you do that? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87sif07ejs.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: {% url ... %} does not work for callable?
Hallöchen!
Torsten Bronger writes:
> I cannot get the following working:
>
> In urls.py:
>
> url(r"^samples/(?P.+)/edit/$", sample.edit),
>
> In the template:
>
> {% url 'samples.views.sample.edit' sample_name="whatever" %}
>
> I constantly get a NoReverseMatch,
I solved the probem; it doesn't have directly to do with reverse
resolution of URLs. Instead, I failed to add @wraps() to one of my
own decorators, and reserve() could not "recognize" the view
function anymore.
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/87bnlrw788.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.
{% url ... %} does not work for callable?
Hallöchen!
I cannot get the following working:
In urls.py:
url(r"^samples/(?P.+)/edit/$", sample.edit),
In the template:
{% url 'samples.views.sample.edit' sample_name="whatever" %}
I constantly get a NoReverseMatch, even if I pass the view function
with its full path samples.views.sample.edit in urls.py. I know
that a named url() solves the problem. Is this the only way if I
use a callable in url() (which will become mandatory in Django 2.0)?
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/87wq4g2cfa.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.
Uniqueness of "."
Hallöchen!
According to
<https://docs.djangoproject.com/en/1.7/ref/contrib/auth/#django.contrib.auth.models.User.has_perm>,
the permission is defined with ".".
However, the unique_together option says (('content_type',
'codename'),). So, in an app "foo", one could define a permission
codename "edit_bar" in two different models, and foo.edit_bar would
not be unique.
Does this mean I must take care myself that such name clashs don't
occur?
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/87twzqinje.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.
Re: ANN: Django website redesign launched
Hallöchen! Cal Leeming writes: > I am inclined to agree that a site should try and look the same on > all devices (in terms of color/contrast etc) I didn't mean this. What I meant was that a webpage should work well on all devices in terms of legibility and usability. It may work better on one device than on the other, but there should be a minimal quality. As far as I am concerned, just add contrast and I'm fine with the new design. And I'm sure that the higher-contrast scheme would also work on Apple devices. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87mw6mlgyr.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: ANN: Django website redesign launched
Hallöchen! Cal Leeming writes: > [...] > > The footer menu contrast is a little bright with the white/light > green, however it's worth noting that the color/contrast > experience will vary depending on what equipment your > using. Typically if a site has been designed on an Apple > Thunderbolt/MBP Retina display, then it will look a bit crappy on > many PC monitors (even the higher quality ones). [...] I think this doesn't matter. Besides the fact that my screen is calibrated and I nevertheless tilt the screen when I visit the new website to gain contrast, a website should be optimized for sub-optimal conditions rather than the best ones. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87zjamzz30.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: Multi-table inheritance and primary keys
Hallöchen! Markus Holtermann writes: > It looks like you ran into the bug reported as > https://code.djangoproject.com/ticket/23956 . See my comment #6 > for a workaround. Thank you for the pointer, this is it indeed. I commented there. Regards, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87fvcmfhsq.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Multi-table inheritance and primary keys
Hallöchen!
Is it correct that when using multi-table inheritance, I must not
set an explicit primary key in the derived model class? Currently,
I get
...
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py",
line 65, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: column "process_ptr_id" of relation
"samples_deposition" already exists
while applying the initial migration and wonder whether that what I
try to achive is possible at all.
("samples" is the app name, "deposition" is the model name of the
derived model.)
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/87sigmfqxl.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.
Re: POSTing data to a django view from a stand alone script with CSRF
Hallöchen!
Larry Martell writes:
> I have a django view that normally receives POSTed data from a web
> page. That all works fine. But now we also want to call that view from
> a python script. That is failing with a 403 because of a CSRF
> mismatch. I can disable CSRF on my view and then it does work from the
> script.
>
> Is there some way I can have it work with CSRF with my script?
We make it like this (roughly, but you probably can fill the gaps
yourself):
class Connection(object):
cookie_jar = cookiejar.CookieJar()
opener =
urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cookie_jar))
http_headers = [("X-requested-with", "XMLHttpRequest"),
("Accept",
"application/json,text/html;q=0.9,application/xhtml+xml;q=0.9,text/*;q=0.8,*/*;q=0.7")]
opener.addheaders = http_headers
def do_http_request(self, url, data=None):
if data is None:
request = urllib.request.Request(url)
else:
# "Referer" is necessary for HTTPS communication.
headers = {"Content-Type": "application/x-www-form-urlencoded",
"Referer": url}
request = urllib.request.Request(url, urllib.parse.urlencode(data),
headers)
self.opener.open(request)
def set_csrf_header(self):
"""Copies the cookie to the header of the subsequent requests."""
csrf_cookies = {cookie for cookie in cookie_jar if cookie.name ==
"csrftoken"}
if csrf_cookies:
assert len(csrf_cookies) == 1
self.opener.addheaders = self.http_headers + [("X-CSRFToken",
csrf_cookies.pop().value)]
def login(self, username, password):
# First, a GET request to get the CSRF cookie used only for the
# following POST request. (It's some sort of bootstrapping;
# only necessary for the very first request.)
self.do_http_request("http://mysite.com/login;)
self.set_csrf_header()
self.do_http_request("http://mysite.com/login;, {"username": username,
"password": password})
# Now, set the CSRF token for the rest of the communication.
self.set_csrf_header()
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/87a92zle2u.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.
Re: How to deal with CSRF middleware from a crawler
Hallöchen! Carl Meyer writes: > [...] > > Unless you've modified the CSRF implementation locally, all it > does is check that the CSRF token provided in a cookie matches the > one provided in the POST data. [...] > > But this means that the CSRF protection is simple to bypass in a > case like yours: you can just set the CSRF cookie and the POST var > to the same value in all your crawler's requests. It doesn't > matter what that value is. Thank you. I was ignorant about the details of this anti-CSRF mechanism. It's working now, even for the login view itself. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87zjbf6khp.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: Meta inheritance across abstract base class
Hallöchen! Collin Anderson writes: > If you define a new class Meta on C, then it will _replace_ the > previous class Meta. [...] I indeed have a Meta class in C but it is derived from the upstream Meta class. The inheritance chain in my Meta's is uninterrupted. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/878uizqs1j.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
How to deal with CSRF middleware from a crawler
Hallöchen! We use crawlers, which in our case a Python scripts that read data from disk and send a lot of HTTP POST requests to the Django deployment. The POST requests hit the same URLs/Views that are also used by the browser to edit something with a web . If I activate the CSRF middleware, does this mean that our crawlers have to make GET requests before every POST in order to get the CSRF token? This would slow down them significantly ... Can one exclude certain usernames from the CSRF checks? Or do you see another way of keeping the number of HTTP requests small in the crawlers? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87mw7gqshq.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Meta inheritance across abstract base class
Hallöchen! I have the following model structure: class A(models.Model): ... class Meta: ordering = ["timestamp"] get_latest_by = "timestamp" class B(A): class Meta(A.Meta): abstract = True class C(B): ... Then, class C doesn't haven ordering or get_latest_by set. Is this expected behaviour? Then, I would simply re-define them in B. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87h9xospms.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: Primary keys vs. natural keys
Hallöchen!
Carl Meyer writes:
>> On Oct 31, 2014, at 4:19 AM, Torsten Bronger <bron...@physik.rwth-aachen.de>
>> wrote:
>>
>> [...]
>>
>> Do you mean this:
>>
>>class ExternalOperator(models.Model):
>>
>>name = models.CharField(_("name"), max_length=30, unique=True)
>>natural_key_field = "name"
>>
>> It works (at least, it doesn't abort) but I thought only fields
>> were allowed as attributes.
>
> Yes, that's what I mean (though usually for clarity I would place
> any non-field attributes in a separate visual block - separated by
> a blank line - from field attributes). There is no requirement
> that all class attributes of models must be fields. Django can
> tell which are subclasses of Field and ignores the others.
See https://code.djangoproject.com/ticket/5793 -- can't this be
solved by such attributes then? I wonder because I subscribed to
this ticket long ago for a similar reason.
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/87r3xogccd.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.
Re: Primary keys vs. natural keys
Hallöchen!
Carl Meyer writes:
> [...]
>
> There is no built in feature for this, but it doesn't seem like a
> hard problem to solve with your own conventions. For instance,
> rather than hardcoding the name of the natural key field inside
> the natural_key method, make it a model class attribute,
> e.g. MyModel.natural_key_field.
Do you mean this:
class ExternalOperator(models.Model):
name = models.CharField(_("name"), max_length=30, unique=True)
natural_key_field = "name"
It works (at least, it doesn't abort) but I thought only fields were
allowed as attributes.
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/8738a4h78e.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.
Primary keys vs. natural keys
Hallöchen!
Do I understand it correctly that in the Django community, it is
preferred to use surrogate primary keys (the auto ID field) instead
of explicitly setting primary keys? Currently, I add natural_key()
methods to many of my models, but some of them return only one
field. Now I wonder whether I made a mistake and should have chosen
that field as the primary key.
My use case is that I need to retrieve the natural keys of all
objects in the database of a particular model. As far as I can see,
this can only be achieved by fetching all objects and calling the
natural_key() method for all of them. In contrast,
model.objects.values_list("pk", flat=True)
is probably *much* faster.
Is it possibly to specify a single field a natural key somehow
(besides making it the PK)? For example, it is possible to add a
Meta attribute to the model?
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/87egtoha9w.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.
Importing models in app config module
Hallöchen! https://docs.djangoproject.com/en/dev/ref/applications/ says: You cannot import models in modules that define application configuration classes, but you can use get_model() to access a model class by name, like this: Does this also apply to models of other apps? In particular, I need import django.contrib.auth.models in my ready() method. Importing it seems to work. So is this the way to go? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8761faj058.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: Data migration fails because contenttypes not yet ready
Hallöchen! Markus Holtermann writes: > Are you talking about Django 1.7 migrations or South? In the > former case you need to make sure that your datamigration depends > on the contenttypes application. I'm talking about Django 1.7 migrations. Unfortunately, contenttypes is already migrated before my app. But this doesn't help because update_all_contenttypes is a post_migrate signal. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87lho91fy3.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Data migration fails because contenttypes not yet ready
Hallöchen! I want to implement an initial data migration (basically, the same thing initial_data.json used to do). The problem is that my initial data must be connected with ContentType instances. However, update_all_contenttypes() hasn't been called at this stage, so my migration fails. As far as I can see, update_all_contenttypes is idempotent. Can I safely call update_all_contenttypes during the data migration? I wonder whether the models may be available in an older version, and whether this may confuse update_all_contenttypes. That said, it *seems* to work ... Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87tx2x9y0k.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
How to log out a user
Hallöchen! I know that there is a logout(request) routine, but how to program a logout(user) routine? Background: Every night, a cronjob iterates over all active users in our Django deployment and checks whether they can still be found in our LDAP directory. Every user that is not found anymore is set to inactive. Unfortunately, this is not enough, he or she must be logged out. But how to do that? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/87egwlk18f.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: Feed uploaded file into process
Hallöchen! Serdar Dalgic writes: > I'm just brainstorming about the situation, I think the best > solution would be some kind of Javascript functions in the > frontend part, before implementing a file upload. You can tar the > file in a temporary directory, an upload that temp file with the > real file's name.tar.gz The data is supposed to be sent as one big compressed file und uncompressed on the web server. The tar'ing is done by the uploading person, before using the browser. Then, it is sent through the Internet. On my server, I whish to untar it *while* I receive it. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Feed uploaded file into process
Hallöchen! I want users to upload very large tar balls to my site. I think it is sensful to feed them to "tar -xzf" during the upload. Is this possible with Django? I think the standard way with iterating over chunks doesn't start before the whole file has been already stored on disk, does it? (I don't even need the original file.) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- 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 http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django Book
Hallöchen! Timothy Makobu writes: > The Django book is the best source of understanding Django I have > found http://www.djangobook.com/en/2.0/ All books about Django share the same problem: The original documentation is simply terrific, both for the beginner and the expert. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Which conferences for promoting a new FLOSS nanotech project?
Hallöchen! We have implemented a samples database in our nanotech research institute using Django. I did most of it, and we have a full time employee working on it for three years. So far, it's 60.000 LOC. I plan to make in open source, and I'm optimistic that the director of the institute will approve it. Now, it's time to plan to build a community around the project. I intent to go to DjangoCon this year, however, I wonder whether this is the right audience. What I'm looking for are geeks in nanotech/biotech institutes around the world who are interested in adapting the system to their institution. (Because the system is *very* flexible, this adaption process is important and tricky.) Of course, I hope that those people will also improve the core code so that other institutions can benefit. Where do you think I should go? Are there people like the ones I'm looking for at DjangoCon or its european counterpart? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Need to examine and act on old vs. new at .save() time
Hallöchen! Jeff writes: > [...] > > I found the 'm2m_changed' signal yesterday, read that you can't > determine *what* changed by using it, and also ended up directed > to some open bug reports... etc... and threw up my hands. But the "action" and "pk_set" arguments contain this information. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How do I prevent messages getting cached?
Hallöchen! Nathan Geffen writes: > I am using per-view caching in version 1.3 and would prefer to avoid > caching in my templates as far as possible. However, I've hit a snag. > If the messaging framework generates a message for a cached view, one > of two things happen: > > 1. If the page is not yet in cache, the page gets cached with the > message in it. So next time a user goes to the page, they get an old > message. > > 2. If the page is already in cache, the message isn't displayed. I think https://code.djangoproject.com/ticket/13894 is related to this. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Website Documentation Search broken?
Hallöchen! creecode writes: > I can't say for sure but for some time it seems to me that > searching has become more difficult. I can't put my finger on any > specifics. I have found that some phrases that are in my browser > form field cache I've used in that past no longer return results. > And I'm almost certain some of them were previously successful. I *think* (though I'm really not sure) that the search used to work through Google. Be that as it may, it used to be significantly better. Were there legal problems with the old search? If I searched for "queryset api", the first result was, well, the QuerySet API. Now, it is the fifth. With just "queryset", it is even position 9. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: What's the django convention for templates?
Hallöchen! Torsten Bronger writes: > [...] If someone wants to create a local variation of a template, > he simply creates > > my_app_local/templates/my_app/my_view.html > > and puts my_app_local instead of my_app into INSTALLED_APPS. Sorry, this was rubbish. It must read: "... and puts my_app_local before my_app into INSTALLED_APPS." Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: What's the django convention for templates?
Hallöchen! Mauro writes: > [...] > > Following the djangobook I've build a projects who has the following > strurcture: > > projects | > --- > | __init__.py > | manage.py > | settings.py > | urls.py > > | app folder | > -- >| many files >| templates | > > | > index.php > > As you can see the templates directory is stored inside the app > directory. I go even one step further: my_app/templates/my_app/my_view.html This is redundant but it makes overriding of templates easier. If someone wants to create a local variation of a template, he simply creates my_app_local/templates/my_app/my_view.html and puts my_app_local instead of my_app into INSTALLED_APPS. This way, you don't have to modify the original files. This assumes that you use django.template.loaders.app_directories.Loader in TEMPLATE_LOADERS. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Model Inheritance Downcasting
Hallöchen! Bastian Kuberek writes: > [...] > > What I need is to be able to query the Widget class and get back > subclasses based on their type: > >>>> widgets = Widget.objects.all() >>>> print widgets > [ 5>,] We do this very reliably with http://djangosnippets.org/snippets/2091/ but I find https://github.com/carljm/django-model-utils/blob/master/README.rst very interesting, too. This is a frequently-requested feature with many implementations, yet there is no canonical solution in Django, unfortunately. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: I18N and caching: page don't change language until I press F5 in browser
Hallöchen! Salvatore Iovene writes: > On Sat, Nov 5, 2011 at 7:43 AM, Torsten Bronger > <bron...@physik.rwth-aachen.de> wrote: > >> Sending e.g. "Expires: ..." so that the page expires immediately >> solved the problem. > > Sending an Expires header so that the page expires immediately > does work, but it feels like fixing a headache with a > guillotine. The browser should cache it's own version whenever > possible, even though we're caching server side with memcached. See <http://www-archive.mozilla.org/projects/netlib/http/http-caching-faq.html>. Other browsers have similar rules. If you don't tell the browser explicitly not to cache the page, it might just do this -- and so won't ask the server. Then, re-coding your web app won't help. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: I18N and caching: page don't change language until I press F5 in browser
Hallöchen! Salvatore Iovene writes: > On Friday, November 4, 2011 5:31:46 PM UTC+2, Salvatore Iovene wrote: >> >> if hasattr(request, 'session'): >> request.session['django_language'] = lang >> else: >> response.set_cookie(settings.LANGUAGE_COOKIE_NAME, lang) >> > > I have solved my problem by setting the cookie unconditionally (i.e. > outside of that else-statement). I copied that code from > django.views.i18n.set_language. I wonder if that's a bug. Strange. I had the very same problem, but I identified the browser's internal caching heuristics as the problem. If there are no explicit caching headers in the response, the browser guesses. Sending e.g. "Expires: ..." so that the page expires immediately solved the problem. (By the way, I didn't send those headers eventually. The browser's heuristics make the site faster in other cases, and users switch language only seldomly.) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Fixed fields in forms
Hallöchen! I have some fields in a model form that the user is not allowed to change. The set of fields must be determined at runtime because it depends on the permissions of the current user. Thus, I have defined a self.fixed_fields in my form's constructor which is a set of str. It contains the fixed fields' names. Then I can say at the end of the constructor: for field_name in self.fixed_fields: self.fields[field_name].widget.attrs["disabled"] = "disabled" self.fields[field_name].required = False And a clean method says: def clean_my_field(self): if "my_field" in self.fixed_fields: return self.task.my_field return self.cleaned_data["my_field"] >From security's point of view, this is sufficient. However, if the validation fails and the form has to be re-dislayed, the disabled fields are empty -- because they were not in request.POST. While still not problematic per se, this is confusing for the user. I can solve it by making the "data" parameter a *mutable* QueryDict and inject the missing values, basing on "instance" or "initial" -- whatever is available. However, here this is getting really cumbersome and error-prone. Is there an easier way? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
form.is_valid() changes a ModelForm's associated instance
Hallöchen! I was bitten by this behaviour today, so I'd like to revisit an old subject: See <http://groups.google.com/group/django-users/msg/2e31bfaefd8351cf>. If I give an "instance" to a model form constructor and later on call ".is_valid()" on that form, the given instance is changed in place. Is this intended behaviour? If so, is it documented somewhere? And it is true that this was introduced in 1.2, and not always the case? (Because if so, I'd have to audit my complete code.) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Strange traceback: DoesNotExist not callable
Hallöchen! Alasdair Nicol writes: > Hi João and Torsten, > > [...] > >> On Oct 7, 12:31 pm, Torsten Bronger<bron...@physik.rwth-aachen.de> >> wrote: >> >>> Hall chen! >>> >>> I examine a traceback that ends with >>> >>> ... >>> >>> File "/usr/lib/python2.6/dist-packages/django/db/models/query.py", line 351, >>> in get >>> % (self.model._meta.object_name, num, kwargs)) >>> >>> TypeError: 'DoesNotExist'objectisnotcallable >>> >>> [...] > > I've been caught out by this error before. In my case it was because > I was not catching exceptions correctly *elsewhere* in my code. In > another view, I had something like > > try: > sample = self.samples.get() # Here, the TypeError occurs > except Sample.DoesNotExist, Sample.MultipleObjectsReturned: >pass > > Without the parenthesis, Yes, this was it. It is now fixed here and works. Thank you! Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Strange traceback: DoesNotExist not callable
Hallöchen! João Pedro Francese writes: > I've just stumbled upon the same problem in my code. I have no > clue on why it happened either. Did you ever get any progress on > investigating this issue? No, I have not investigated this further so far. (But I still know how to reproduce it.) At first, it *looks* like a CPython interpreter bug. But I have to reduce it to a minimal example before I can tell more. Maybe next week. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Strange traceback: DoesNotExist not callable
Hallöchen!
I examine a traceback that ends with
...
File "/usr/lib/python2.6/dist-packages/django/db/models/query.py", line
351,
in get
% (self.model._meta.object_name, num, kwargs))
TypeError: 'DoesNotExist' object is not callable
The error-triggering source code in query.py says
def get(self, *args, **kwargs):
"""
Performs the query and returns a single object matching the given
keyword arguments.
"""
clone = self.filter(*args, **kwargs)
if self.query.can_filter():
clone = clone.order_by()
num = len(clone)
if num == 1:
return clone._result_cache[0]
if not num:
raise self.model.DoesNotExist("%s matching query does not exist."
% self.model._meta.object_name)
raise self.model.MultipleObjectsReturned("get() returned more than one
%s -- it returned %s! Lookup parameters were %s"
% (self.model._meta.object_name, num, kwargs))
The last line triggers the error. This is strange for two reasons:
First, DoesNotExist should be callable for all models. And
secondly, there is no DoesNotExist in the last line but a
MultipleObjectsReturned.
My source code that is responsible for the error is:
try:
sample = self.samples.get() # Here, the TypeError occurs
except (Sample.DoesNotExist, Sample.MultipleObjectsReturned):
pass
"self" is a model instance. "samples" is a M2M field of "self" to
the class "Sample". In my case, ther are 20 samples connected with
the "self" instances, so raising a MultipleObjectsReturned would be
correct.
Does anybody have an idea what is going on here? How should I
proceed with debugging?
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Parellel request from the same user in very short time
Hallöchen! Russell Keith-Magee writes: > [...] > > I might be missing something obvious here, but isn't this > *exactly* what database transactions are designed to fix? > Admittedly, you've got an unusual presentation born out of weird > browser behavior, but making sure that two overlapping operations > don't violate data integrity sounds like the textbook case for > using transactions. I agree that if the constraint can be expressed by an RDBMS conditions, it should be expressed this way. However, this is not always possible. By the way, in our project, we considered database integrity errors as internal errors that we never caught. Instead, we avoided them by pre-checking the input data. Is this a bad approach? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: request.user not pickable anymore
Hallöchen! Łukasz Rekucki writes: > On 16 September 2011 22:05, Torsten Bronger > <bron...@physik.rwth-aachen.de> wrote: > >> this means that we don't have to do anything. > > Not really. To 1.4 not be affected, someone needs to write a patch > for that ticket. Of course you are right. I was only refering to "Milestone 1.4" and "Release blocker" which means that it has high priority. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: request.user not pickable anymore
Hallöchen! Tim Shaffer writes: > Looks like there might already be a ticket open to fix this: > > https://code.djangoproject.com/ticket/16563 Wow, thank you! Since 1.3 is not affected and 1.4 won't be probably, this means that we don't have to do anything. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
request.user not pickable anymore
Hallöchen! Since <https://code.djangoproject.com/changeset/16305>, request.user is a SimpleLazyObject. This means that def my_simple_test_view(request): import pickle pickle.dumps(request.user) fails. Since we put objects in the cache which contain request.user, we saw a traceback when updating our SVN Django recently. I added a function def unlazy_object(lazy_object): if lazy_object._wrapped is None: lazy_object._setup() return lazy_object._wrapped user = unlazy_object(request.user) This works. But is this the way to go? Is it possible to make SimpleLazyObject pickable in the first place? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: memcached problems with cache.clear()
Hallöchen! Torsten Bronger writes: > Sometimes, we experience a massive increase in active connections > to the memcached server when calling cache.clear(). I think https://code.djangoproject.com/ticket/15324 is our problem, so I will upgrade from SVN-15005 to Django 1.3. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: memcached problems with cache.clear()
Hallöchen!
Tom Evans writes:
> [...]
>
>
>>>> from django.core.cache import cache
>>>> for i in xrange(2): cache.set(str(i), str(i))
> ...
>>>> cache.get('1')
> '1'
>>>> from django.conf import settings
>>>> settings.CACHES
> {'default': {'LOCATION': '10.0.12.11:11211', 'BACKEND':
> 'django.core.cache.backends.memcached.CacheClass'}}
Could you -- or anybody -- try this again for "93.129.33.177:11211"?
This is the IP of my private PC for the next 8 hours (ping
wilson(dot)homeunix(dot)com). For me, this fails. If it doesn't
fail for you, it is my client's configuration.
Thank you!
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: memcached problems with cache.clear()
Hallöchen! Tom Evans writes: > On Thu, Sep 15, 2011 at 3:49 PM, Torsten Bronger > <bron...@physik.rwth-aachen.de> wrote: >> Hallöchen! >> >> >> It works for me too if it only accesses localhost. However, if I >> say >> >> "LOCATION": ["192.168.26.130:11211", "192.168.26.131:11211"], >> >> I see that fatal behaviour. >> > > Not for me: Okay, thank you for your input; it narrowed the erroneous case a bit. But how to proceed? Is Django using the memcached module wrongly, or is the memcached module buggy? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: memcached problems with cache.clear()
Hallöchen!
Tom Evans writes:
> On Thu, Sep 15, 2011 at 2:31 PM, Torsten Bronger
> <bron...@physik.rwth-aachen.de> wrote:
>
>> [...]
>>
>> I found an easy way to reproduce this (with memcached activated in
>> settings.py):
>>
>> chantal@mandy:~/chantal$ ./manage.py shell
>> Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
>> [GCC 4.4.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> (InteractiveConsole)
>>>>> from django.core.cache import cache
>>>>> for i in xrange(2000): cache.set(str(i), str(i))
>> ...
>> Traceback (most recent call last):
>> File "", line 1, in
>> File
> "/usr/lib/python2.6/dist-packages/django/core/cache/backends/memcached.py",
> line 64, in set
>> File "/usr/lib/pymodules/python2.6/memcache.py", line 502, in set
>> File "/usr/lib/pymodules/python2.6/memcache.py", line 675, in _set
>> File "/usr/lib/pymodules/python2.6/memcache.py", line 278, in _get_server
>> File "/usr/lib/pymodules/python2.6/memcache.py", line 883, in connect
>> File "/usr/lib/pymodules/python2.6/memcache.py", line 897, in _get_socket
>> File "/usr/lib/python2.6/socket.py", line 182, in __init__
>> error: [Errno 24] Too many open files
>>
>> It *seems* (I don't know for sure) that a socket it opened by
>> cache.set() but not closed. Is this the expected behaviour?
>
> It behaves for me - different OS mind.
>
> [...]
>>>> from django.conf import settings
>>>> settings.CACHES
> {'default': {'LOCATION': '127.0.0.1:11211', 'BACKEND':
> 'django.core.cache.backends.memcached.CacheClass'}}
It works for me too if it only accesses localhost. However, if I
say
"LOCATION": ["192.168.26.130:11211", "192.168.26.131:11211"],
I see that fatal behaviour.
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: memcached problems with cache.clear()
Hallöchen! Torsten Bronger writes: > Sometimes, we experience a massive increase in active connections > to the memcached server when calling cache.clear(). This causes > server tracebacks because the server cannot open files > (e.g. Python modules) anymore: "error 24: Too many open files". I found an easy way to reproduce this (with memcached activated in settings.py): chantal@mandy:~/chantal$ ./manage.py shell Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from django.core.cache import cache >>> for i in xrange(2000): cache.set(str(i), str(i)) ... Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/dist-packages/django/core/cache/backends/memcached.py", line 64, in set File "/usr/lib/pymodules/python2.6/memcache.py", line 502, in set File "/usr/lib/pymodules/python2.6/memcache.py", line 675, in _set File "/usr/lib/pymodules/python2.6/memcache.py", line 278, in _get_server File "/usr/lib/pymodules/python2.6/memcache.py", line 883, in connect File "/usr/lib/pymodules/python2.6/memcache.py", line 897, in _get_socket File "/usr/lib/python2.6/socket.py", line 182, in __init__ error: [Errno 24] Too many open files It *seems* (I don't know for sure) that a socket it opened by cache.set() but not closed. Is this the expected behaviour? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
memcached problems with cache.clear()
Hallöchen! Sometimes, we experience a massive increase in active connections to the memcached server when calling cache.clear(). This causes server tracebacks because the server cannot open files (e.g. Python modules) anymore: "error 24: Too many open files". Increasing the allowed files for www-data in /etc/security/limits didn't help. Currently, the only solution I see is to replace cache.clear() with subprocess.call(["/etc/init.d/memcached", "restart"]). Has anybody had a similar problem? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Integrity Error
Thanks Thomas you helped me a lot these are my first step in python
and django.
And I really starting to like it
Torsten
On 26 Aug., 12:23, Thomas Orozco <g.orozco.tho...@gmail.com> wrote:
> While we're at it, here are a few suggestions.
> So long as you can, you should use unicode inside python code. The main
> logic would be that input should be converted to unicode as soon as
> possible, and that output should be encoded (likely to UTF-8) as late as
> possible.
>
> Consequently, you might want to rewrite your invoice methods so that they do
> the following.
> invoice_number = unicode(self.created_at.year) + u'/' + unicode(self.id)
> You could also write this the following way:
> return u'{0}/{1}'.format( self.created_at.year, self.id ), which would be
> more elegant (if you use format with a unicode string it calls your object's
> __unicode__ method, and if you use format with a string, it calls the
> __str__ method.).
>
> By the way, your __unicode__ method actually returns your invoice's
> invoice_number, so you might want to have __unicode__ return
> self.invoice_number().
> You could even use a single method for both in your code, but that might not
> be a very good idea: if one day you want to change your display, if you have
> __unicode__ return self.invoice_number() you can change it.
>
> Regarding your test code, you will need to add a few details I didn't point
> out first.
> None of your fields have "blank = True", so you're going to have to either
> give them default values or give them actual values in your tests.
>
> Hope this helps.
>
> Thomas
>
> 2011/8/26 Torsten <torstenzan...@googlemail.com>
>
>
>
>
>
>
>
> > Hi
>
> > I have the following model:
>
> > class Invoice(models.Model):
> > customer = models.ForeignKey(Customer)
> > project = models.ForeignKey(Project, blank=True, null=True)
> > sum = models.FloatField(default=0)
> > tax = models.IntegerField(default=16)
> > payed_at = models.DateField(blank=True, null=True)
> > payable_at = models.DateField('payable at')
> > created_at = models.DateTimeField(auto_now_add=True)
>
> > def invoice_number(self):
> > invoice_number = str(self.created_at.year) + '/' +
> > str(self.id)
> > return invoice_number
>
> > def __unicode__(self):
> > return unicode(str(self.created_at.year) + '/' + str(self.id))
>
> > class InvoiceItem(models.Model):
> > invoice = models.ForeignKey(Invoice)
> > text = models.TextField()
> > unit = models.CharField(max_length=255)
> > amount = models.IntegerField()
> > sum = models.FloatField()
>
> > and try to run this test
>
> > def test_save_invoice(self):
> > InvoiceItem.objects.create(sum=12, unit='Stunde', amount=100)
> > InvoiceItem.objects.create(sum=10, unit='Stunde', amount=120)
> > invoice = Invoice.objects.create(created_at="2011-07-28",
> > customer_id=1, payable_at='2012-12-12')
> > invoice.invoiceitem_set.all()
> > self.assertEqual(240, invoice.sum)
>
> > with this error:
> > IntegrityError: invoice_invoiceitem.invoice_id may not be NULL
>
> > since it is the relation id Django should take care for the
> > invoice_invoiceitem.invoice_id
>
> > Or is there anything wrong with the code ?
>
> > Torsten
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Integrity Error
Thanks Thomas
your are right concerning the sum there is no need for that.
But you say:
Your invoice items have no invoice attribute, as the error says.
Isn't this line which defines the attribute ?
invoice = models.ForeignKey(Invoice)
Thanks
Torsten
On 26 Aug., 11:41, Thomas Orozco <g.orozco.tho...@gmail.com> wrote:
> Your invoice items have no invoice attribute, as the error says.
>
> By the way, although I'm not sure of what you're trying to achieve, let me
> point out that there is not really a need for a sum field in your invoice as
> you can just sum all the invoice items' amount (and respect the DRY
> principle - you use a few other similar issues).
> Le 26 août 2011 11:35, "Torsten" <torstenzan...@googlemail.com> a écrit :
>
>
>
>
>
>
>
> > Hi
>
> > I have the following model:
>
> > class Invoice(models.Model):
> > customer = models.ForeignKey(Customer)
> > project = models.ForeignKey(Project, blank=True, null=True)
> > sum = models.FloatField(default=0)
> > tax = models.IntegerField(default=16)
> > payed_at = models.DateField(blank=True, null=True)
> > payable_at = models.DateField('payable at')
> > created_at = models.DateTimeField(auto_now_add=True)
>
> > def invoice_number(self):
> > invoice_number = str(self.created_at.year) + '/' +
> > str(self.id)
> > return invoice_number
>
> > def __unicode__(self):
> > return unicode(str(self.created_at.year) + '/' + str(self.id))
>
> > class InvoiceItem(models.Model):
> > invoice = models.ForeignKey(Invoice)
> > text = models.TextField()
> > unit = models.CharField(max_length=255)
> > amount = models.IntegerField()
> > sum = models.FloatField()
>
> > and try to run this test
>
> > def test_save_invoice(self):
> > InvoiceItem.objects.create(sum=12, unit='Stunde', amount=100)
> > InvoiceItem.objects.create(sum=10, unit='Stunde', amount=120)
> > invoice = Invoice.objects.create(created_at="2011-07-28",
> > customer_id=1, payable_at='2012-12-12')
> > invoice.invoiceitem_set.all()
> > self.assertEqual(240, invoice.sum)
>
> > with this error:
> > IntegrityError: invoice_invoiceitem.invoice_id may not be NULL
>
> > since it is the relation id Django should take care for the
> > invoice_invoiceitem.invoice_id
>
> > Or is there anything wrong with the code ?
>
> > Torsten
>
> > --
> > You received this message because you are subscribed to the Google Groups
>
> "Django users" group.> To post to this group, send email to
> django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
>
> django-users+unsubscr...@googlegroups.com.> For more options, visit this
> group at
>
> http://groups.google.com/group/django-users?hl=en.
>
>
>
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Integrity Error
Hi
I have the following model:
class Invoice(models.Model):
customer = models.ForeignKey(Customer)
project = models.ForeignKey(Project, blank=True, null=True)
sum = models.FloatField(default=0)
tax = models.IntegerField(default=16)
payed_at = models.DateField(blank=True, null=True)
payable_at = models.DateField('payable at')
created_at = models.DateTimeField(auto_now_add=True)
def invoice_number(self):
invoice_number = str(self.created_at.year) + '/' +
str(self.id)
return invoice_number
def __unicode__(self):
return unicode(str(self.created_at.year) + '/' + str(self.id))
class InvoiceItem(models.Model):
invoice = models.ForeignKey(Invoice)
text = models.TextField()
unit = models.CharField(max_length=255)
amount = models.IntegerField()
sum = models.FloatField()
and try to run this test
def test_save_invoice(self):
InvoiceItem.objects.create(sum=12, unit='Stunde', amount=100)
InvoiceItem.objects.create(sum=10, unit='Stunde', amount=120)
invoice = Invoice.objects.create(created_at="2011-07-28",
customer_id=1, payable_at='2012-12-12')
invoice.invoiceitem_set.all()
self.assertEqual(240, invoice.sum)
with this error:
IntegrityError: invoice_invoiceitem.invoice_id may not be NULL
since it is the relation id Django should take care for the
invoice_invoiceitem.invoice_id
Or is there anything wrong with the code ?
Torsten
--
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: AssertEquals __unicode__
Thanks for the hint:
self.assertEqual(u"2011/1", unicode(invoice))
works
On 25 Aug., 12:41, Alasdair Nicol <alasd...@memset.com> wrote:
> On 25/08/11 11:34, Torsten wrote:
>
>
>
>
>
>
>
> > Hi
>
> > How do I do that right ?
>
> > I have a class like:
>
> > class Invoice
> > ...
> > def __unicode__(self):
> > return unicode(str(self.created_at.year)+'/'+str(self.id))
>
> > and an test here:
>
> > def test_invoice_number(self):
> > invoice = Invoice.objects.create(created_at="2011-07-28",
> > customer_id=1, payable_at='2012-12-12')
> > invoice.save()
> > self.assertEqual("Invoice: 2011/1", invoice)
>
> > with the follwoing result:
>
> > File "/Users/torsten/PycharmProjects/invoiz/invoice/tests.py", line
> > 22, in test_invoice_number
> > self.assertEqual("2011/1", invoice)
> > AssertionError: '2011/1' !=
>
> > Thanks for help
>
> > Torsten
>
> You want to compare the unicode string for the object, so use the
> unicode function. The following should work:
>
> self.assertEqual("Invoice: 2011/1", unicode(invoice))
>
> Regards,
> Alasdair
>
> --
> Alasdair Nicol
> Developer, MEMSET
>
> mail: alasd...@memset.com
> web:http://www.memset.com/
>
> Memset Ltd., registration number 4504980. 25 Frederick Sanger Road,
> Guildford, Surrey, GU2 7YD, UK.
--
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.
AssertEquals __unicode__
Hi
How do I do that right ?
I have a class like:
class Invoice
...
def __unicode__(self):
return unicode(str(self.created_at.year)+'/'+str(self.id))
and an test here:
def test_invoice_number(self):
invoice = Invoice.objects.create(created_at="2011-07-28",
customer_id=1, payable_at='2012-12-12')
invoice.save()
self.assertEqual("Invoice: 2011/1", invoice)
with the follwoing result:
File "/Users/torsten/PycharmProjects/invoiz/invoice/tests.py", line
22, in test_invoice_number
self.assertEqual("2011/1", invoice)
AssertionError: '2011/1' !=
Thanks for help
Torsten
--
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: Newbe DateTimeField Question
Thanks for that, but I still get the error message:
Exception Type: IntegrityError
Exception Value:invoice_invoice.payed_at may not be NULL
here my models.py:
from django.db import models
class Customer(models.Model):
company = models.CharField(max_length=255)
branch = models.CharField(max_length=255)
firstname = models.CharField(max_length=255)
lastname = models.CharField(max_length=255)
street = models.CharField(max_length=255)
zip = models.CharField(max_length=6)
country = models.CharField(max_length=255)
email = models.CharField(max_length=255)
created_at = models.DateTimeField('date created')
def __unicode__(self):
return self.company
class Project(models.Model):
title = models.CharField(max_length=255);
created_at = models.DateTimeField('date created')
def __unicode__(self):
return self.title
class Invoice(models.Model):
customer = models.ForeignKey(Customer)
project = models.ForeignKey(Project, null=True)
sum = models.FloatField(default=0)
tax = models.IntegerField(default=16)
payed_at = models.DateTimeField(default=None)
payable_at = models.DateField('payable at')
created_at = models.DateTimeField(False, True)
class InvoiceItem(models.Model):
invoice = models.ForeignKey(Invoice)
text = models.TextField()
unit = models.CharField(max_length=255)
amount = models.IntegerField()
sum = models.FloatField()
On 21 Aug., 15:19, dm03514 <dm03...@gmail.com> wrote:
> you can set default=None, that way you don't have to explicityly save
> that value as none every time you save an object.
>
> On Aug 21, 7:33 am, Torsten <torstenzan...@googlemail.com> wrote:
>
>
>
>
>
>
>
> > Hi
>
> > I simply want the DateTime to be set to null.
>
> > payed_at = models.DateTimeField(null=True)
>
> > but always get this as an error:
>
> > IntegrityError at /admin/invoice/invoice/add/
> > invoice_invoice.payed_at may not be NULL
>
> > Thanks for help.
>
> > Torsten
--
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.
Newbe DateTimeField Question
Hi I simply want the DateTime to be set to null. payed_at = models.DateTimeField(null=True) but always get this as an error: IntegrityError at /admin/invoice/invoice/add/ invoice_invoice.payed_at may not be NULL Thanks for help. Torsten -- 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 1.1 performance versus django 1.2 performance
Hallöchen! Russell Keith-Magee writes: > [...] > > No - there isn't a plan to address this, because it isn't clear > what "this" is. > > While it is known that there has been a slowdown between versions, > that slowdown has been accompanied by a massive increase in > functionality -- for example, the 1.1->1.2 transition introduced > support for multiple databases. To the best of my knowledge, the > performance slowdown highlighted by Eric at Djangocon was > relatively small - 5-10%, not on the order of 30-50% > slowdown. This matches with my personal experience of upgrading. Does anybody have estimates or figures concerning the impact of middleware? I love the middleware framework and I make extensive use of it but sometimes I'm afraid it slows down every request significantly, especially if you have a project with cheap view functions. And then, the number of "canonical" middleware has increased between Django versions as far as I can see. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Primary keys in multi-table inheritance
Hallöchen! Can one rely on the fact that a model instance and its parent model instance share the same PK value in multi-table inheritance? (Given that there is only one non-abstract parent model, and no explicit link to the parent.) Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Sharable permalinks
Hallöchen! We create a central database for our research institute. One must be logged-in in order to access any pages. Sometimes, however, it is interesting to be able to send a deep link in an email to an external collegue who doesn't have an account. The collegue should then be able to see the link, and a couple of others (in particular, the embedded graphics). Thus, the sent link must be connected with a set of pages it grants access to. How would you solve this? A session key in the query string? How do I then propagate the query string to all the tags in the page? Or is a dynamically generated account better? Is there a better way to identify the set of accessable pages than by a set of URLs? Is there already middleware in existence that I could use? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Is there an official Django forum besides this mailing list?
Hallöchen! Kevin writes: > I checked the Community link on the Django website and am unable > to locate a web-based forum, but only this mailing list. [...] https://convore.com/ is getting some attraction recently. > I find that a forum is much more organized and easier to follow > than a mailing list. Forums can have separate sections, whereas > mailing lists are flat. A forum has a lower barrier for non-techies, and it offers fun gimmicks. Besides this, they are a nightmare to follow for any non-trivial discussion. Imagine to find related answers in a conversation with 100+ postings. Possibly you've used sub-optimal clients to read mailing lists so far. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Switching off URL normalisation
Hallöchen! Torsten Bronger writes: > [...] > > Currently, a URL like "http://www.example.com/super%2F/edit/; is > normalised to "http://www.example.com/super/edit/;. This is bad > because the entity to be edited is called "super/"(sic!) but this > way, you edit "super". > > [...] > > Somewhere in mod_wsgi or Django the URL is normalised, but where? > And can I switch it off? This *seems* to be a mod_wsgi qirk, see <http://code.google.com/p/modwsgi/source/browse/trunk/mod_wsgi/mod_wsgi.c#8140>. If this is true, you can't switch it off without recompiling. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Switching off URL normalisation
Hallöchen! My configuration: Apache + mod_wsgi + SVN Django. APPEND_SLASH is off. Currently, a URL like "http://www.example.com/super%2F/edit/; is normalised to "http://www.example.com/super/edit/;. This is bad because the entity to be edited is called "super/"(sic!) but this way, you edit "super". In Apache's httpd.conf it says AllowEncodedSlashes On (and it doesn't work without it). Somewhere in mod_wsgi or Django the URL is normalised, but where? And can I switch it off? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Long admin emails
Hallöchen! Russell Keith-Magee writes: > On Thu, Jan 27, 2011 at 3:12 PM, Torsten Bronger > <bron...@physik.rwth-aachen.de> wrote: > >> [...] >> >> Thank you, you are probably right. I invesitage this; I just >> sent an email to our IT department. It may be though that all I >> can do is to patch my local Django branch because the IT >> department might refuse to change their configuration. > > The good news here is that you won't need to patch your install at > all. One of the advantages of the new logging framework is that > you can handle this by simply installing a different email > handler. Thank you, this worked! Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Long admin emails
Hallöchen! Russell Keith-Magee writes: > On Thu, Jan 27, 2011 at 1:19 PM, Torsten Bronger > <bron...@physik.rwth-aachen.de> wrote: > >> [...] >> >> I had looked at the raw mail message, and the text/plain part >> looked exactly the same as I uploaded -- really. > > I don't know what's happening here, but I'm fairly certain it > isn't Django's fault. > > It's clear that *something* is processing your mail Thank you, you are probably right. I invesitage this; I just sent an email to our IT department. It may be though that all I can do is to patch my local Django branch because the IT department might refuse to change their configuration. If both MIME parts are so different, multipart/alternative may be a problematic approach anyway. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Long admin emails
Hallöchen! Torsten Bronger writes: > Russell Keith-Magee writes: > >> [...] >> >> Although we now send HTML error mails, we still send the original >> text mail, in exactly the same format as before. We do this by >> sending two MIME enclosures in the message; a text/plain >> enclosure with the raw-text version, and a text/html version with >> the full markup. The first MIME enclosure is always the >> text/plain enclosure. > > I had looked at the raw mail message, and the text/plain part > looked exactly the same as I uploaded -- really. I hope I didn't overlook any of our secrets but I posted the raw mail at http://wilson.homeunix.com/6966 Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Long admin emails
Hallöchen! Russell Keith-Magee writes: > [...] > > Although we now send HTML error mails, we still send the original > text mail, in exactly the same format as before. We do this by > sending two MIME enclosures in the message; a text/plain enclosure > with the raw-text version, and a text/html version with the full > markup. The first MIME enclosure is always the text/plain > enclosure. I had looked at the raw mail message, and the text/plain part looked exactly the same as I uploaded -- really. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Long admin emails
Hallöchen! I just upgraded from Django 13xxx to the current SVN. Before the upgrade, error emails from 500 errors to the admins lokked like <http://dpaste.com/357039/>. I liked that very much, especially because the traceback was easily readable. Now, they look like <http://dpaste.com/357032/>. It's the text/plain part of the email (my client can't display HTML). Is there a possibility to get the old, for me clearer emails back, at least almost? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: to iterate over two lists simultaneously in *.html
Hallöchen!
Masklinn writes:
> On 2011-01-16, at 14:42 , Torsten Bronger wrote:
>
>> [...]
>>
>> On the other hand, as somebody having zip() in a dozen of
>> render_to_response calls, I can say that
>>
>> {% for smth1, smth2 in list1, list2 %}
>>
>> would be a nice thing to have. ;-)
>
> Why don't you build a template tag doing that for you?
The level of suffering hasn't been big enough yet for me. It
shouldn't be too hard though, so I think sooner or later somebody
with better internal knowledge of Django (docs, unittests) will do
it anyway. Especially because it's so easy to remain compatibility,
plus it makes templates easier rather than more complicated in my
opinion.
If I create a patch, I'll upload it at the appropriate place of
course.
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: to iterate over two lists simultaneously in *.html
Hallöchen!
David Walker writes:
> [...]
>
> and the the {% for %} becomes:
> {% for smth1, smth2 in zipped %}
On the other hand, as somebody having zip() in a dozen of
render_to_response calls, I can say that
{% for smth1, smth2 in list1, list2 %}
would be a nice thing to have. ;-)
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Mailing Lists Vs. Forums
Hallöchen! Kevin Monceaux writes: > [...] > > My main complaint about Google Groups is that I can't download > message archives when I join a group. You can ready it as a newsgroup through Gmane. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: database migration
Hallöchen! Torsten Bronger writes: > Hallöchen! > > Michael P. Soulier writes: > >> On 29/12/10 Torsten Bronger said: >> >>> I don't recommend that. If the database exceeds a certain size >>> (and "certain" is MBs, not GBs), this simply fails. >> >> Is there a bug report for this issue? I find that very >> disappointing. > > [...] Sorry, an addition for Adblock occupied my clipboard. The real link is http://code.djangoproject.com/ticket/5423 Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: database migration
Hallöchen! Michael P. Soulier writes: > On 29/12/10 Torsten Bronger said: > >> I don't recommend that. If the database exceeds a certain size >> (and "certain" is MBs, not GBs), this simply fails. > > Is there a bug report for this issue? I find that very > disappointing. http://1.2.3.12/bmi/stc.celeb.gate.cc/banner/pi/0120.gif Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: database migration
Hallöchen! Michael P. Soulier writes: > On 28/12/10 Emmanuel Mayssat said: > >> I have a classic database dump question >> >> I would like to migrate from sqlite to mysql. >> How can I dump and import the data? > > See the manage.py dumpdata/loaddata commands. I don't recommend that. If the database exceeds a certain size (and "certain" is MBs, not GBs), this simply fails. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: turning a Model instance into an instance of one of it's subclasses
Hallöchen! Russell Keith-Magee writes: > On Tue, Dec 21, 2010 at 8:33 PM, Torsten Bronger > <bron...@physik.rwth-aachen.de> wrote: >> Hallöchen! >> >> Marc Aymerich writes: >> >>> [...] >>> >>> Morgan, take a look at the inheritanceManager of this app: >>> https://github.com/carljm/django-model-utils#readme >> >> Is anything like this planned for core Django? It's the third or >> forth time I see someone needing it. > > [...] > > At the time, we decided to omit support for 'narrowing' (to use > the CORBA parlance) as part of the default feature set because it > requires either: > > a) table overhead to store the type of the child instance > b) an expensive query (or list of queries) that isn't obviously expensive. > > We weren't (and I'm still not) willing to impose either of these > overheads by default. I must clarify my use of "core Django" above. Of course this may well be realised in contrib/ as an optional feature. However, I'd love to see it in the Django release with explanations in the Django docs. > The good news is that either strategy is easy to implement without > modifications to core. I've got several classes in production that do > narrowing-like behavior (for the record, both using strategy (a)). (a) is the way to go in my opinion. I think the table overhead itself is not so much of a problem but any migration of old databases necessary due to it. So, I understand that it cannot be default behaviour. > With a bit of extra effort, this should be easy to turn into a mixin > that could be shared as part of a third-party support library, much as > django-treebeard or django-mptt provide model support extensions > implementing tree-like structures. As somebody who has strugged with this problem for a along time and having seen a couple of solutions along the road, I find https://github.com/carljm/django-model-utils quite appealing and finished. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: turning a Model instance into an instance of one of it's subclasses
Hallöchen! Marc Aymerich writes: > [...] > > Morgan, take a look at the inheritanceManager of this app: > https://github.com/carljm/django-model-utils#readme Is anything like this planned for core Django? It's the third or forth time I see someone needing it. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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.
Testing an app: adding an optional test model
Hallöchen! In order to test my app, I need to add a model class just for testing. While it doesn't do much harm if it's always there because its DB table would remain empty, I'd like to add it only for the test runner. (Background: My app is extended by other apps. But for testing, I must simulate this extending.) However, using a custom test runner didn't work, probably because Django has detected all models already at that point. Similarly, I can't inject the model class into models.py from the test module. Thus, I must place the model class in models.py. Can I do this conditionally? For example: if settings.TESTING: class TestModel(models.Model): ... would be great. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: Choices vs. ForeignKeys
Hallöchen! Todd Wilson writes: > [...] > > [...] Instead of hard-coding the entity types here, you are using > a constant, presumably because you may want to introduce more > entity types later. But what are the trade-offs bewteen > representing types as CharFields with choices, as you are doing > here, versus a separate table of types to which this model has a > foreign-key relationship? I find choices much easier. Additionally, they behave more nicely in ModelForms as they create a proper widget automatically. I use FKs only if I want to attach additional information to the choices. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: restrict downloading files based on user-permission
Hallöchen! patrickk writes: > well ... yes, but if someond uploads "äöü.PDF" I want the user to > download "äöü.PDF" again ... and not > %C3%83%C2%A4%C3%83%C2%B6%C3%83%C2%BC.PDF. > > did you test your code with IE7/IE8? I just did and the name of > the downloaded file differs from the upload. Chrom and Firefox download äöü.pdf if the HTTP header field was UTF-8-encoded (instead of URL-escaped). However, I hesitate to say that IE is doing the wrong thing beacuse the UTF-8 encoding is never mentioned in the header field, so Chrome and FF just guess right. Or does Django encode unicode strings in HTTP header fields somehow? I haven't sniffed the HTTP communication so far. Is there a standard at all for how non-ASCII in the header field "Content-Disposition" is supposed to be encoded? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: Using Django's auth for Trac too
Hallöchen! Knut Ivar Nesheim writes: > See the following link to the docs. This should be exactly what > you want. > > http://docs.djangoproject.com/en/dev/howto/apache-auth/ We use WSGI. But if all else fails, switching to mod_python may be an alternative. Thank you! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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.
Using Django's auth for Trac too
Hallöchen! I know that my question has a strong Apache component, but can anybody here give me hints for how to use Django's auth system for a Trac installation running on the same Apache? I.e., iff someone is logged in in Django, it is also authenticated in Trac. I already have my own Django auth module that just needed to be fleshed out. Maybe Django keeps a file up-to-date with all logged-in users, which Apache uses for Trac authentication? Thank you! Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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 internationalized sites - are models.User internationalized?
Hallöchen! Andy writes: > [...] > >>> You mean you hope the field "email" is not allowed to contain >>> non- English or non-European characters? >> >>> But real email addresses do contain those characters: >>> http://en.wikipedia.org/wiki/Email_address#Internationalization >> >> I read "informal" and "experimental" there. > > Maybe, but I know people with real email addresses like that. Just my opinion: Then they will have constant trouble with them, and cause constant trouble to their contacts. Let us first have internationalised domain names gaining wide acception, *then* we can think of internationlised email addresses. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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 internationalized sites - are models.User internationalized?
Hallöchen! Andy writes: > On Oct 2, 1:45 am, Torsten Bronger <bron...@physik.rwth-aachen.de> > wrote: > > Thanks for responding. > >>> Are "first_name" & "last_name" limited to alphanumeric >>> characters or can they contain non-English characters like "ü" >>> or non-European characters like "黒"? >> >> Yes. > > "Yes" is in "first_name" & "last_name" can contain non-English > characters like "ü" or non-European characters like "黒"? The latter. > [...] > > You mean you hope the field "email" is not allowed to contain non- > English or non-European characters? > > But real email addresses do contain those characters: > http://en.wikipedia.org/wiki/Email_address#Internationalization I read "informal" and "experimental" there. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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 internationalized sites - are models.User internationalized?
Hallöchen! Andy writes: > According to documentation (http://docs.djangoproject.com/en/dev/ > topics/auth/), models.User contains: > > first_name > Optional. 30 characters or fewer. > last_name > Optional. 30 characters or fewer. > email > Optional. E-mail address. > > Are "first_name" & "last_name" limited to alphanumeric characters > or can they contain non-English characters like "ü" or > non-European characters like "黒"? Yes. > What characters are allowed in the "email" field? Again can it > contain non-English or non-European characters? I don't know, but I hope not! > Anyone who have built non-English or non-European websites using > Django? What is your experience? Any pitfalls I need to be aware > of? The support for translating a Django project into various languages is very good. The issues I know of are very minor: * You can't have comments on translation strings in templates * The directory structure for the translations is static and may collide with other tools * App names are untranslatable (yet) Another thing is localisation, i.e. decimal point, formatting of dates etc. Django has support for it but I haven't used it so far. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: return json format
Hallöchen! Imad Elharoussi writes: > I got readystate = 4 but status = 500 Is Django's setting DEBUG=True? If so, what does the error message page say? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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.
Manual schema migration
Hallöchen! Does anybody know a tutorial for Django-related schema migration by using the SQL console directly? (Preferably PostgreSQL.) We evaluate South at the moment, but we'd like to have the low-level knowledge as a fallback. Of course, general SQL knowledge can be assumed. It needn't be an online resource. If this is discussed in one of the published Django books, this would be great to know, too. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: Stability of auto IDs
Hallöchen! Steve Holden writes: > On 7/27/2010 12:38 PM, Torsten Bronger wrote: >> Hallöchen! >> >> bruno desthuilliers writes: >> >>> On 27 juil, 07:19, Torsten Bronger <bron...@physik.rwth-aachen.de> >>> wrote: >>> >>>> Currently, our Django app relies on the stability of various auto >>>> ID fields which are implicitly generated by Django/database >>>> backend. >>> >>> [...] From a practical POV, starting from a mint empty DB and >>> inserting records in the same order without any other client app >>> accessing to the DB, you should probably get the same IDs, but >>> there's absolutely no garantee. >> >> At least, they are explicitly mentioned in a "manage.py dumpdata" >> fixture, and probably in a SQL dump, too. But the DB may ignore >> autofields when loading that data, right? > > It couldn't do that without ruining the relationships, could it? A > dump includes the numerical values for the foreign keys, so the > related primary keys have to stay the same to maintain relational > integrity. Well, it could map them possibly ... granted that there would be no reason for it. Okay, then I must be more precise: If I have a model with an implicit primary key, and values of this key are used to identify associated files on disk, is this safe? Safe as far as restoring SQL backups, re-loading fixtures, and south migrations are concerned? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: Stability of auto IDs
Hallöchen! bruno desthuilliers writes: > On 27 juil, 07:19, Torsten Bronger <bron...@physik.rwth-aachen.de> > wrote: > >> Currently, our Django app relies on the stability of various auto >> ID fields which are implicitly generated by Django/database >> backend. > > [...] From a practical POV, starting from a mint empty DB and > inserting records in the same order without any other client app > accessing to the DB, you should probably get the same IDs, but > there's absolutely no garantee. At least, they are explicitly mentioned in a "manage.py dumpdata" fixture, and probably in a SQL dump, too. But the DB may ignore autofields when loading that data, right? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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.
Stability of auto IDs
Hallöchen! Currently, our Django app relies on the stability of various auto ID fields which are implicitly generated by Django/database backend. Is is better to have explicit ID fields for this or can one consider them stable? For example, many bitmap files on the DB server are connected with models by having the auto ID in their filename. If loading a previously dumped fixture, doing a schema migration (with south), etc would change those IDs, we would lose this connection for good. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: Dangerous "If-Modified-Since"
Hallöchen! Torsten Bronger writes: > We've programmed a Django app with mandatory login. Under > somewhat obscure circumstances, the browser (Firefox and Chrome) > sends spurious If-Modified-Since header fields and may take the > page of another user from the browser cache. [...] > > [...] > > The big question is: Why does the browser send the > If-Modified-Since in (*). > > And the even bigger question is: How can be prevent it? Some Internet research revealed that browsers don't really care about the Vary field. It is used primarily by cache servers. A workaround is to send an Etag which consists of (a hash of) the timestamp and the user ID. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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.
Conditional view processing: *one* function for timestamp and ETag?
Hallöchen! For timestamp and ETag in conditional view processing, I have to pass two function to the @conditional decorator. However, I've used this twice so far, and both times I needed common DB access in both methods. Thus, I embedded the common data in a custom attribute of the "request" object. Not beautiful. Wouldn't it make sense to have an etag_last_modified_func parameter for @conditional? Before I create a ticket, I'd like to see whether others have run into the same problem, or whether there is a solution that I've missed. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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.
Dangerous "If-Modified-Since"
Hallöchen! We've programmed a Django app with mandatory login. Under somewhat obscure circumstances, the browser (Firefox and Chrome) sends spurious If-Modified-Since header fields and may take the page of another user from the browser cache. It is like this: 1. User A logs in. 2. User A retrieves ressource (=URL) X. 3. User A logs out. 4. User B logs in in the same browser window. 5. User B retrieved ressource X. 6. User B sees the *same* page as user A! It was taken from the browser's cache. (6) is disastrous because it may even be that B was not allowed to see X in the first place. As far as I can see, "Vary: Cookie" is properly set. We added an "@last_modified" decorator to "/X" that always returns "2001/01/01 00:00". We sniffed the HTTP headers with the "Live HTTP headers" of Firefox: --8<---cut here---start->8--- http://127.0.0.1:8000/X GET /X HTTP/1.1 Host: 127.0.0.1:8000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.9) Gecko/20100402 Ubuntu/9.10 (karmic) Firefox/3.5.9 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://127.0.0.1:8000/ Cookie: csrftoken=ee7e82e6131a46aef229221e1e351987; sessionid=8c61c7f10b17435bd7b044222f1e9eb7 If-Modified-Since: Mon, 01 Jan 2001 00:00:00 GMT Cache-Control: max-age=0 HTTP/1.0 304 NOT MODIFIED Date: Wed, 21 Jul 2010 19:02:52 GMT Server: WSGIServer/0.1 Python/2.6.4 Last-Modified: Mon, 01 Jan 2001 00:00:00 GMT Content-Length: 0 Content-Type: text/html; charset=utf-8 Content-Language: de Vary: Accept-Language, Cookie -- [logout] -- http://127.0.0.1:8000/login POST /login HTTP/1.1 Host: 127.0.0.1:8000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.9) Gecko/20100402 Ubuntu/9.10 (karmic) Firefox/3.5.9 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://127.0.0.1:8000/login Cookie: csrftoken=ee7e82e6131a46aef229221e1e351987; sessionid=6c784d57f4b6f31e8b9a870afb1dec33 Content-Type: application/x-www-form-urlencoded Content-Length: 90 username=b.bunny=12345==ee7e82e6131a46aef229221e1e351987 HTTP/1.0 302 FOUND Date: Wed, 21 Jul 2010 19:03:20 GMT Server: WSGIServer/0.1 Python/2.6.4 Content-Language: de Expires: Wed, 21 Jul 2010 19:03:20 GMT Vary: Accept-Language, Cookie Last-Modified: Wed, 21 Jul 2010 19:03:20 GMT Etag: "d41d8cd98f00b204e9800998ecf8427e" Location: http://127.0.0.1:8000/ Cache-Control: max-age=0 Content-Type: text/html; charset=utf-8 Set-Cookie: sessionid=da1117b2a19755a53fbfc644d3a0e77a; expires=Wed, 04-Aug-2010 19:03:20 GMT; Max-Age=1209600; Path=/ -- http://127.0.0.1:8000/X GET /X HTTP/1.1 Host: 127.0.0.1:8000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.9) Gecko/20100402 Ubuntu/9.10 (karmic) Firefox/3.5.9 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://127.0.0.1:8000/ Cookie: csrftoken=ee7e82e6131a46aef229221e1e351987; sessionid=da1117b2a19755a53fbfc644d3a0e77a If-Modified-Since: Mon, 01 Jan 2001 00:00:00 GMT (*) HTTP/1.0 304 NOT MODIFIED Date: Wed, 21 Jul 2010 19:03:26 GMT Server: WSGIServer/0.1 Python/2.6.4 Last-Modified: Mon, 01 Jan 2001 00:00:00 GMT Content-Length: 0 Content-Type: text/html; charset=utf-8 Content-Language: de Vary: Accept-Language, Cookie --8<---cut here---end--->8--- That last If-Modified-Since causes my headaches. The server responds -- correctly -- with 304, and the browser takes the other user's page from the cache. The big question is: Why does the browser send the If-Modified-Since in (*). And the even bigger question is: How can be prevent it? Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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-us...@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: break/continue for templates
Hallöchen!
George Sakkis writes:
> On Jul 5, 2:25 pm, Torsten Bronger <bron...@physik.rwth-aachen.de>
> wrote:
>
>> [...]
>>
>> People will want to do *everything* in the template. The lowest
>> rated snippet on djangosnippets currently is an {% exec %}
>> tag. :-)
>
> But then again there is a {% switch %} tag [1] that has 8/8
> positive votes, let alone the "smart" {% if %} tag that is at last
> part of Django now.
The question is whether non-programmers can handle it. In this
context, a smart if was a good thing to do because it just made a
necessary control structure more intuitive. But the other things
are simply bringing full-blown programming into templates. Besides,
it is *very* easy to migrate them into the Python code.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.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-us...@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.
