Re: Custom Model field, to_python() / from_db_value() and unittests...

[Jens Diemer]

Am 17.06.2015 um 16:48 schrieb charettes:

I suggest you use the following pattern which also accounts for py2/3:

...

This is stepping into the django-user@ territory so I suggest we move the
discussion over there if the provided example doesn't match your needs but you
are really just trying to write a portable third-party field.


Thanks for you suggestion.

I "moved" it to django-user list ;)

--


Mfg.

Jens Diemer



http://www.jensdiemer.de

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/mls207%24lkp%242%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: Custom Model field, to_python() / from_db_value() and unittests...

[Jens Diemer]

Am 16.06.2015 um 18:43 schrieb Tim Graham:

The doc about how to ignore warnings in tests is here:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature

Alternatively, you can temporarily remove these lines in runtests.py:

warnings.simplefilter("error", RemovedInDjango20Warning)
warnings.simplefilter("error", RemovedInDjango21Warning)


Thanks!

But then, there can't exists tests that will raise a warning while importing ?!?




So i try to make it clear:

With v1.7 the "__metaclass__ = models.SubfieldBase" is needed. So i remove the 
tests without it.


And i found a existing Bug https://code.djangoproject.com/ticket/9619 for:

to_python not called when fetching data with .values(...)


I update the tests and create a ticket and pull request here:
* https://code.djangoproject.com/ticket/24993
* https://github.com/django/django/pull/4874

I can also made pull request for v1.8.x and master...





I also found the Solution for: "to_python() didn't call with Python 3":
The "__metaclass__" syntax changed in Python 3.

The Problem: I didn't read the doc carefully here:

https://docs.djangoproject.com/en/1.7/howto/custom-model-fields/#the-subfieldbase-metaclass

There are three code examples:
* for Python 2 only
* for Python 3 only
* for Python 2+3 using six.with_metaclass()

What's about to remove the first two examples and leave only the 
six.with_metaclass() example?!?


I made also a ticket/pull request for this:
* https://code.djangoproject.com/ticket/24992
* https://github.com/django/django/pull/4873













On Tuesday, June 16, 2015 at 12:30:05 PM UTC-4, Jens Diemer wrote:


I try to create a custom model field, that should "Converting values to 
Python
objects" as described in the documentation here:


<https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#converting-values-to-python-objects

<https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#converting-values-to-python-objects>>


It doesn't work with Python 2.7 and 3.4 with Django 1.7.x and 1.8.x...


I search around and found no unittest case for this 
"howto/custom-model-fields"

So i created a simple test case to investigate why my code not worked.


I made a unittest against "stable/1.7.x", "stable/1.8.x" and "master" here:

https://github.com/jedie/django/branches/yours
<https://github.com/jedie/django/branches/yours>

compare links:

stable/1.7.x

<https://github.com/jedie/django/compare/stable/1.7.x...test_custom_model_fields_1.7.x

<https://github.com/jedie/django/compare/stable/1.7.x...test_custom_model_fields_1.7.x>>


stable/1.8.x

<https://github.com/jedie/django/compare/stable/1.8.x...test_custom_model_fields_1.8.x

<https://github.com/jedie/django/compare/stable/1.8.x...test_custom_model_fields_1.8.x>>


master

<https://github.com/jedie/django/compare/master...test_custom_model_fields_master

<https://github.com/jedie/django/compare/master...test_custom_model_fields_master>>



I run these test and here the result:


*** 1.7.x with Py2:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok
test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL


*** 1.7.x with Py3:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL



*** 1.8.x with Py2:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok


*** 1.8.x with Py3
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok



*** master with Py2 - doesn't run:
Traceback (most recent call last):
File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 12, in

  from django.apps import apps
    File "/home/jens/PyLucid_env/src/django/django/apps/__init__.py", line
1, in

  from .config import AppConfig   # NOQA
    File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 6, 
in

  from django.utils.module_loading import module_has_submodule
File "/home/jens/PyLucid_env/src/django/django/utils/module_loading.py",
line
4, in 
 

Custom Model field, to_python() / from_db_value() and unittests...

[Jens Diemer]

I try to create a custom model field, that should "Converting values to Python 
objects" as described in the documentation here:


<https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#converting-values-to-python-objects>

It doesn't work with Python 2.7 and 3.4 with Django 1.7.x and 1.8.x...


I search around and found no unittest case for this "howto/custom-model-fields"

So i created a simple test case to investigate why my code not worked.


I made a unittest against "stable/1.7.x", "stable/1.8.x" and "master" here:

https://github.com/jedie/django/branches/yours

compare links:

stable/1.7.x
<https://github.com/jedie/django/compare/stable/1.7.x...test_custom_model_fields_1.7.x>

stable/1.8.x
<https://github.com/jedie/django/compare/stable/1.8.x...test_custom_model_fields_1.8.x>

master
<https://github.com/jedie/django/compare/master...test_custom_model_fields_master>


I run these test and here the result:


*** 1.7.x with Py2:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok
test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL


*** 1.7.x with Py3:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel1Tests) ... FAIL
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... FAIL
test_values (custom_model_fields.tests.TestModel2Tests) ... FAIL



*** 1.8.x with Py2:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok


*** 1.8.x with Py3
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok



*** master with Py2 - doesn't run:
Traceback (most recent call last):
  File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 12, in 

from django.apps import apps
  File "/home/jens/PyLucid_env/src/django/django/apps/__init__.py", line 1, in 


from .config import AppConfig   # NOQA
  File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 6, in 


from django.utils.module_loading import module_has_submodule
  File "/home/jens/PyLucid_env/src/django/django/utils/module_loading.py", line 
4, in 

from importlib import import_module
  File "/home/jens/PyLucid_env/src/django/django/utils/importlib.py", line 6, 
in 

ImportError: cannot import name RemovedInDjango19Warning



*** master with Py3:
test_custom_model_field (custom_model_fields.tests.TestModel1Tests) ... ok
test_values (custom_model_fields.tests.TestModel1Tests) ... ok
test_custom_model_field (custom_model_fields.tests.TestModel2Tests) ... ok
test_values (custom_model_fields.tests.TestModel2Tests) ... ok




So the biggest problem is django 1.7.x...
But it should work in the same way:
<https://docs.djangoproject.com/en/1.7/howto/custom-model-fields/#converting-database-values-to-python-objects>


With 1.8.x i must remove the test with existing:
__metaclass__ = models.SubfieldBase


Otherwise the test will not run:

Testing against Django installed in '/home/jens/PyLucid_env/src/django/django'
Importing application custom_model_fields
Traceback (most recent call last):
  File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 448, in 

options.debug_sql)
  File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 235, in 
django_tests

state = setup(verbosity, test_labels)
  File "/home/jens/PyLucid_env/src/django/tests/runtests.py", line 214, in setup
apps.set_installed_apps(settings.INSTALLED_APPS)
  File "/home/jens/PyLucid_env/src/django/django/apps/registry.py", line 324, 
in set_installed_apps

self.populate(installed)
  File "/home/jens/PyLucid_env/src/django/django/apps/registry.py", line 108, 
in populate

app_config.import_models(all_models)
  File "/home/jens/PyLucid_env/src/django/django/apps/config.py", line 198, in 
import_models

self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/home/jens/PyLucid_env/src/django/tests/custom_model_fields/models.py", 
line 41, in 

class CommaSeparatedModelField2(CommaSeparatedModelField1):
  File 
"/home/jens/PyLucid_env/src/django/django/db/models/fields/subclassing.py", line 
22, in __new__

RemovedInDjango20Warning)
django.utils.deprecation.RemovedInDjango20Warning: SubfieldBase has been 
deprecated. Use Field.from_db_value instead.




Maybe i miss something to handle warnings with tests, but didn't find something 
about warnings he

form validation in contrib.auth

[Jens Diemer]

The default auth.form.AuthenticationForm() did not set a max_length for the 
password field:


https://github.com/django/django/blob/72f6513ebaa7a3fd43c26300e9a8c430dc07cdb5/django/contrib/auth/forms.py#L120-L126

Ok there is not really a max_length constraint. Because in the end the 
auth.models.User must only store the hash value.


The available hashers will consume more RAM if the password is very long. (The 
CPU usage is very similar to a short password)
Only if the server has a POST data limit, the password size is limited. But it 
seems that POST limits are not set or very large on default installations...



On the other side: I didn't see any side effects with a limitation e.g.: 
max_length=1024





Another thing: The auth.models.AbstractUser has the 'username' field with 
max_length=30 and validators.RegexValidator(r'^[\w.@+-]+$',...)


The AuthenticationForm has max_length=254 and no validator...



IMHO one principle is: Validate incoming data as soon as possible, isn't it?



Next thing is "auth.signals.user_login_failed"

This signal will only fired if the auth backends was called.
IMHO it should be called on every failed login. Also if the form is not valid.






--


Mfg.

Jens Diemer



http://www.jensdiemer.de

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/mis98k%24n71%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

contrib.contenttypes.generic importing from contrib.admin causing trouble

[Jens Ådne Rydland]

Not really sure what to use as subject here, or whether this qualifies
to be called a bug, but I don't think it belongs on django-users due to
being an issue in Django itself so I figured I'd ask here before opening
a ticket.

So, we have a project that doesn't use contrib.auth, and it doesn't use
contrib.admin, it does, however, use contrib.contenttypes.generic. And
c.c.generic imports InlineModelAdmin and flatten_fieldsets from
contrib.admin.options, which does some more imports which down the line
causes various models to be imported from contrib.auth.models, and this
in turn causes the auth models to be registered in AppCache, and thus to
be found by db.models.Options' get_all_related_objects() which is used
by db.models.deletion.Collector.collect().

This hasn't caused us any trouble so far, but now that we needed to
delete some stale ContentTypes we suddenly got weird crashes related to
contrib.auth tables not existing when delete() tried to find foreign
keys pointing to ContentType. 

I've tested moving the admin related bits from contenttypes/generic.py
to contenttypes/admin.py, which seems to have fixed our immediate
problem, but haven't really tested if it breaks anything else. And I
guess this could be considered a too obscure corner case to care about,
but would appreciate some feedback anyway. 


-- 
Jens Ådne Rydland

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

Re: Adding Support for PyMySQL (for Python 3)

[Jens Diemer]

Am 07.12.2011 21:38, schrieb Ian Clelland:

PyMySQL is a pure python implementation of PEP 249 for MySQL, and supports
Python 2.4 - 3.2, and MySQL 4.1 and higher.


Another goal of PyMySQL would be to use Django + MySQL with PyPy, isn't it?

See also: 
https://groups.google.com/group/django-users/browse_thread/thread/cbef429d014c1ad9/


--

Mfg.

Jens Diemer



http://www.jensdiemer.de

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

Re: The state of per-site/per-view middleware caching in Django

[Jens Diemer]

Hi...

For PyLucid i made a simple cache middleware [1] simmilar to Django per-site 
cache middleware [2]. But i doesn't vary on Cookies and don't cache cookies. I 
simply cache only the response content.


Of course: This doesn't solve the problem if "csrfmiddlewaretoken" in content.

Here some pseudo code from [1]:
-
def process_request(self, request):
if not self.use_cache(request):
return

response = cache.get(cache_key)
if response is not None:
return response

def process_response(self, request, response):
if not self.use_cache(request):
return response

# Cache only the raw content
response2 = HttpResponse(
content=response._container, status=200,
content_type=response['Content-Type']
)

patch_response_headers(response2, timeout)

cache.set(request.path, response2, timeout)

return response

-

[1] 
https://github.com/jedie/PyLucid/blob/master/pylucid_project/middlewares/cache.py

[2] https://docs.djangoproject.com/en/1.3/topics/cache/#the-per-site-cache


Mfg.

Jens D.

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

Re: CSRF token not validated?

[Jens Diemer]

Am 12.09.2011 22:32, schrieb Carl Meyer:

Sanity-checking the length sounds reasonable to me - do you mind opening
a ticket for this and attaching your patch?


Done ;)

Ticked:
https://code.djangoproject.com/ticket/16827

Patch:
https://github.com/django/django/pull/45


--

Mfg.

Jens Diemer



http://www.jensdiemer.de

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

CSRF token not validated?

[Jens Diemer]

I wonder that the CSRF token send from the client didn't be validated.

Don't know if a DOS attack is possible by sending many request with very long 
CSRF tokens?


IMHO it's a good idea to check the length before do anything with it.

e.g.:
--
diff --git a/django/middleware/csrf.py b/django/middleware/csrf.py
index b5a8579..8e03635 100644
--- a/django/middleware/csrf.py
+++ b/django/middleware/csrf.py
@@ -72,7 +72,10 @@ def get_token(request):
 def _sanitize_token(token):
 # Allow only alphanum, and ensure we return a 'str' for the sake of the 
post
 # processing middleware.
-token = re.sub('[^a-zA-Z0-9]', '', str(token.decode('ascii', 'ignore')))
+if len(token) != 32:
+token = ""
+else:
+token = re.sub('[^a-zA-Z0-9]', '', str(token.decode('ascii', 
'ignore')))
 if token == "":
 # In case the cookie has been truncated to nothing at some point.
 return _get_new_csrf_key()
------


--

Mfg.

Jens Diemer



http://www.jensdiemer.de

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

Re: PHP-inspired user-friendly in-browser DJango install

[Jens Diemer]

Am 09.09.2011 08:23, schrieb Aymeric Augustin:

Nothing prevents you from altering the settings file dynamically and telling 
the user to restart the webserver. You can run wih an in-memory SQLite database 
until this is done.

So your question isn't related to the development of Django itself; it would be 
more appropriate on django-users.

Note that deploying a Django project is a bit more complicated than a PHP 
project (just throw the files in WWW_ROOT). IMO setting up the database isn't 
the most difficult step. I don't know any projects that provide this feature.



For PyLucid CMS i created a "standalone package" with a Web-GUI installation. 
You need not shell to install it.


Here some screenshots:

http://www.pylucid.org/permalink/340/pylucid-screenshots/PyLucid-standalone/

The Web-GUI install is a simple CGI script for running syncdb, south migrate and 
create a first superuser etc.


The script is here:
<https://github.com/jedie/PyLucid/blob/master/scripts/standalone/install_pylucid.cgi>


The install procedure is really simple:
* Upload all files via FTP to webserver
* request http://www.my_server.tld/install_pylucid.cgi
* run "syncdb", "migrate", "create superuser", "loaddata"

Complete instruction here:
http://www.pylucid.org/permalink/331/1b-install-pylucid-standalone-package



But the prefered way to install PyLucid is a bootscript which creates a 
virtualenv:
<http://www.pylucid.org/permalink/333/1a1-create-a-pylucid-environment-with-pylucid-boot>


--

Mfg.

Jens Diemer



http://www.jensdiemer.de

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

Re: Suppressed template errors in admin

[Jens Diemer]

Am 25.08.2011 06:19, schrieb h3:

But this would have side effects on the non-admin templates too.. so
it's not ideal.

Maybe something like this:

TEMPLATE_STRING_IF_INVALID = {'default: '!! Invalid var !!',
'django.contrib.admin': ''}


I do a hack in my admin.py:
-

# some django admin stuff is broken if TEMPLATE_STRING_IF_INVALID != ""
# http://code.djangoproject.com/ticket/3579
if settings.TEMPLATE_STRING_IF_INVALID != "":
# Patch the render_to_response function ;)
from django.contrib.auth import admin as auth_admin
from django.contrib.admin import options

def patched_render_to_response(*args, **kwargs):
old = settings.TEMPLATE_STRING_IF_INVALID
settings.TEMPLATE_STRING_IF_INVALID = ""
result = render_to_response(*args, **kwargs)
settings.TEMPLATE_STRING_IF_INVALID = old
return result

options.render_to_response = patched_render_to_response
auth_admin.render_to_response = patched_render_to_response
-

So you can use TEMPLATE_STRING_IF_INVALID, but it's excluded from django admin 
;)


--

Mfg.

Jens Diemer



http://www.jensdiemer.de

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

widget attribute order and unittests...

[jens]

Check the path output in unittests are difficult, if a form widget
should be checked.

The Problem:
The widget html attribute order is not contingent and may change from
test to tests, because they come from a python dict witch is
unordered...

A simple patch could fix this, by adding sorted() to
forms.util.flatatt():

---
diff --git a/django/forms/util.py b/django/forms/util.py
index 1a1d823..8a48009 100644
--- a/django/forms/util.py
+++ b/django/forms/util.py
@@ -13,7 +13,7 @@ def flatatt(attrs):
 XML-style pairs.  It is assumed that the keys do not need to be
XML-escaped.
 If the passed dictionary is empty, then return an empty string.
 """
-return u''.join([u' %s="%s"' % (k, conditional_escape(v)) for k,
v in attrs.items()])
+return u''.join([u' %s="%s"' % (k, conditional_escape(v)) for k,
v in sorted(attrs.items())])

 class ErrorDict(dict, StrAndUnicode):
 """
---
see also: https://gist.github.com/976467

Should i open a ticked for this?

Mfg.

Jens D.

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

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

[jens]

On Mar 15, 3:44 pm, Yuri Baburov  wrote:
> How do you like the following idea:
> startproject command puts a fixture for django.contrib.sites (and
> fixture for superuser probably) to the root folder or whatever, to be
> loaded with syncdb?

IMHO it would be a great, if django can set the SITE_ID dynamic, based
on the current domain.

There exist some old links related to this:
http://groups.google.com/group/django-developers/browse_thread/thread/d9f1088de7944de3
http://code.djangoproject.com/ticket/4438
http://www.djangosnippets.org/snippets/1099/

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

Re: dbsettings, and user configurable app settings

[jens]

This was the initial question:

On Feb 26, 8:11 am, Jared Forsyth <ja...@jaredforsyth.com> wrote:
> I have been looking around for a way of managing user-configurable
> application settings

In this discussion we must IMHO different between "low-level
settings",  "admin configurable settings" and "user configurable
settings":

1. low level setting
- configuration that is needed to start up the project
- Stored in settings.py
- e.g.: database connection data

2. Admin configurable settings
- project wide configuration
-  e.g.: "min. search term length", "min. time out between login"

2. User configurable settings
- User specific configuration
- e.g.:  "Your preferred markup", "Your preferred JavaScript Editor"

Admin- and user settings are not needed at start up, so they can be
stored into the database. It should be possible to change them in a
nice way, with validation.
In my django-dbpreferences [1] app, the settings are organized with a
form.


A other problem with the current settings.py in django is the
namespace.
IMHO every app should have this own namespace. To handle variable name
conflicts i organized it in this way:

Every app had this own settings file, e.g: .../FooApp/Foo_settings.py

VAR1 = "Bar"
VAR2 = 123



In the global project settings, i do this:

...
# Bind the FooApp settings to the name FOO
from FooApp import Foo_settings as FOO
try:
# User can overwrite everything in his separated settings file
from local_settings import *
except ImportError:
pass



To access the settings, e.g.:

from django.conf import settings

def foobar_view(request):
var1 = settings.FOO.VAR1
var2 = settings.FOO.VAR2
...
----

[1] http://code.google.com/p/django-dbpreferences/


Mfg.

Jens

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

Calling update() on EmptyQuerySet updates all rows in database

[Jens Ådne Rydland]

Came across an issue with EmptyQuerySet today, it seems it does not
behave correctly with regard to update(). (or that the documentation is
lacking, I suspect it's the former)

Assuming I have a model Foo of which I have say 42 stored instances in
the database, each with a CharacterField "bar".

If I do Foo.objects.none().count() I get the expected result 0.
However, Foo.objects.none().update(bar='baz') returns 42, and all 42
rows in the database have been updated.

This seems to be caused by EmptyQuerySet not overriding update(),
shouldn't this just return 0?

-- 
best regards, Jens Ådne Rydland

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