ORM performance
Hi, I am looking at Django's performance with respect to modifying large numbers of objects, each in a unique way that cannot be batched. If I make a simple change to one of my Django models and save(), and then do the same thing in sqlalchemy, I notice a performance difference of about 48 times as far as the rate that the objects are processed to my postgresql db. The code is a simple property update and save, in a loop, trying to process as many objects as possible. Is the Django ORM known to be slower in this regard, or is it likely something that I'm doing? Thanks, Mike -- 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/9049bff2-470e-4560-b93f-dee56bc924d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: relative URLs in redirects
Damn. Missed that. Thanks. On Thursday, October 31, 2013 12:56:11 PM UTC-4, Tom Evans wrote: > > The Location header must always be a fully qualified URI, according to > every single version of the HTTP RFC from RFC 1945 onwards. > > Cheers > > Tom > -- 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/ed101fdb-5733-4940-b4b8-e9c3ec241862%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
relative URLs in redirects
Hi, If I return an HttpRedirect() with a relative URL in it, I notice that Django fully qualifies the redirect with a hostname and scheme. ie. Location /foo/bar/ goes to Location https:myserver.mysite.com/foo/bar/ Is there a reason to fully qualify like this? I've found relative URLs much more portable in the past, and they work through proxies, make no assumptions about SSL on or off, etc. Thanks, Mike -- 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/ac90be77-fa18-4577-8839-dce95cdec09d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
TemporaryFileUploadHandler leaving tempfiles behind on disk
Hi, I'm using a ModelForm to upload a large file that ends up being written to a tempfile on disk. When I call form.save(), the file gets copied to the final filename, but the tempfile is left behind on disk. I am using a custom handler, which is a TemporaryFileUploadHandler subclass, but each method I override calls the parent class' method first. Is the tempfile supposed to be left behind? Thanks -- 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: unable to save ModelForm with primary key change
On Nov 1, 1:27 pm, Tom Evans wrote:
> >> Please show the definition of MyForm.
>
> Please do show it.
Sorry, the model was in the previous email, here's the form.
class McdLoadForm(forms.ModelForm):
VERSIONPAT = re.compile(r'^(\d+\.){3}\d+$')
class Meta:
model = McdLoad
fields = ('version', 'mcdload', 'fromversions')
def clean(self):
cleaned_data = super(McdLoadForm, self).clean()
version = cleaned_data.get('version', '')
log.debug("cleaned_data: version is %s" % version)
if version:
version = re.sub(r'^\s+|\s+$', '', version)
if not McdLoadForm.VERSIONPAT.match(version):
raise forms.ValidationError, \
"Bad version, should be 4-digits separated by
commas"
cleaned_data['version'] = version
fromversions = self.cleaned_data.get('fromversions', '')
if fromversions:
fromversions = re.sub(r'\s', '', fromversions)
for version in fromversions.split(','):
if not McdLoadForm.VERSIONPAT.match(version):
raise forms.ValidationError, \
"Bad version, should be 4-digits separated by
commas"
cleaned_data['fromversions'] = fromversions
log.debug("clean: returning %s" % cleaned_data)
return cleaned_data
--
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.
unable to save ModelForm with primary key change
Hi, I'm trying to modify a model instance, specifically the field which is the model's primary key. When I save, nothing seems to happen. Everything in cleaned_data is good, but the model is not updated. No exception is thrown, the field isn't updated, nothing. All I'm doing is form = MyForm(request.POST, instance=model_instance) if form.is_valid(): form.save() I'm thinking that this might be an issue with respect to how sqlite handles changes to primary key fields. Perhaps I'm handling the change incorrectly. Help appreciated. Using Django 1.4.1 with python-sqlite2 2.6.3 and 3.6.20. Thanks, Mike -- 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: inconsistent fixture behaviour
On Apr 12, 1:44 pm, msoulier wrote: > > class Service(models.Model): > name = models.CharField(max_length=256) *sigh* I should have had primary_key=True on this. Red Herring, sorry. Mike -- 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.
inconsistent fixture behaviour
Hi,
I'm doing my development with sqlite and my production deployment with
postgres. I have this model
class Service(models.Model):
name = models.CharField(max_length=256)
description = models.CharField(max_length=4096, default='')
username = models.CharField(max_length=256)
password = models.CharField(max_length=256)
enabled = models.BooleanField(default=False)
access = models.CharField(max_length=16, default="private")
So I created this fixture
[
{
"pk": "ftpd",
"model": "main.service",
"fields": {
"description": "An FTP service for blah blah blah",
"enabled": false,
"access": "private",
"username": "mcd",
"password": ""
}
}
]
When I tried to load the fixture this error occurred
Installing json fixture 'initial_data' from '/home/msoulier/work/mitel-
msl-webproxy/root/etc/e-smith/web/django/webproxy/../webproxy/main/
fixtures'.
Problem installing fixture '/home/msoulier/work/mitel-msl-webproxy/
root/etc/e-smith/web/django/webproxy/../webproxy/main/fixtures/
initial_data.json': Traceback (most recent call last):
File "/usr/lib/pymodules/python2.6/django/core/management/commands/
loaddata.py", line 167, in handle
for obj in objects:
File "/usr/lib/pymodules/python2.6/django/core/serializers/json.py",
line 38, in Deserializer
for obj in PythonDeserializer(simplejson.load(stream), **options):
File "/usr/lib/pymodules/python2.6/django/core/serializers/
python.py", line 85, in Deserializer
data = {Model._meta.pk.attname :
Model._meta.pk.to_python(d["pk"])}
File "/usr/lib/pymodules/python2.6/django/db/models/fields/
__init__.py", line 471, in to_python
raise exceptions.ValidationError(self.error_messages['invalid'])
ValidationError: [u'This value must be an integer.']
Huh? I have no integers.
Curious, I changed the false to a for the boolean field, and it works.
?? I use false in other places for boolean fields without issue, why
does it matter here?
Thanks,
Mike
--
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.
validation in fields with custom forms
I have a custom field with takes an ipv4/v6 address or an fqdn, or a list of same, comma-separated. I'm using it in a form where I then have a custom validator for that field. ie. class SipTrunkForm(forms.Form): remote_addr = twcustomfields.SockaddrListField() remote_port = forms.IntegerField(min_value=1, max_value=65535) So, SockaddrListField has a clean() method, which seems to work fine. Meanwhile, in the SipTrunkForm I have a clean_remote_addr() validator to further validate the address and the port together. The problem is, when clean_remote_addr is called, the port value doesn't seem to be in cleaned_data yet. It appears soon after, as the view sees it and saves it just fine, but it doesn't appear in the validator for the form. This seems like a bug to me... Or am I doing this wrong somehow? When I validate remote_port instead by renaming clean_remote_addr to clean_remote_port, it all works fine. Mike -- 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.
debugging template inheritance
Hi,
I have a framework on a product that allows new django projects to
make use of
an existing project's code, so new projects can reduce duplication. It
does
this in templates by some trickery with the TEMPLATE_DIRS.
For example, I have a base project here
/var/www/django/base/templates/base.html
/500.html
/404.html
And then a project making use of it like so
/var/www/django/project1/templates/index.html
{% extends "base/templates/base.html" %}
And a TEMPLATE_DIRS of
(
"/var/www/django",
"/var/www/django/project1/templates"
)
In my main project, this works well. And, when there's a fatal error
and my
servererror view function says to render "base/templates/500.html",
everything
works.
500.html extends base.html, which is a key point. That has always
worked in
the past even though the /var/www/django/base/templates directory is
not in
the path. I always thought that it was a feature that 500.html could
extend
base.html and it worked because they were in the same directory
together.
And, it does work in project1. But, I just added a project2,
configured
identically AFAICT, and it's not working. When I try to render
500.html I get
File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/
django/shortc
uts/__init__.py", line 20, in render_to_response
File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/
django/templa
te/loader.py", line 108, in render_to_string
File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/
django/templa
te/__init__.py", line 178, in render
File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/
django/templa
te/__init__.py", line 779, in render
File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/
django/templa
te/__init__.py", line 792, in render_node
File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/
django/templa
te/loader_tags.py", line 71, in render
File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/
django/templa
te/loader_tags.py", line 66, in get_parent
TemplateSyntaxError: Template u'base.html' cannot be extended, because
it doesn'
t exist
So, should this work? Is it a fluke that it works in one project and
not the
other? If it should work, then some clues for helping figure out why
it's not
working would be appreciated.
Thanks,
Mike
--
Michael P. Soulier
"Any intelligent fool can make things bigger and more complex... It
takes a
touch of genius - and a lot of courage to move in the opposite
direction."
--Albert Einstein
--
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: cascade deletion happens before pre_delete signal is sent?
On Apr 3, 6:23 pm, Tomasz Zieliński wrote: > I believe that this question was asked on this group a long time ago, > and the answer was that pre_delete signal was fired *before* actual > deletion occured, > but *after* objects were collected for deletion (i.e. after list of > objects that were to be deleted > was created - you can think of this list as of "deletion tree" show in > Django admin). > > Writing this, I don't know if you've observed the same problem. It seems that way. The bottom line is that pre_delete is not helping to prevent unintended deletion. To solve this issue I've had to define my own signal and send that in my model's delete method. Mike -- 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.
cascade deletion happens before pre_delete signal is sent?
I have a model A, which has a ForeignKey to model B. A --> B When B is deleted I want to save the As that are pointing at B by repointing them at a different B if possible. To do this I have a pre_delete signal registered for B models. Unfortunately does doesn't work. Django follows the relationship from B to A, and deletes the As before signaling the pre_delete event for B. So, and event that could save the As happens too late. Now, I could use a pre_delete for A, but then I won't know that the A is about to be deleted as a direct result of B being deleted, so I can't possibly tell that B is about to go away, so I should move the pointer to B to another B. This could simply be an admin directly deleting an A. So, signals fail me here, do they not? The only way to do this is to override the delete method in B and take action there instead. I'd prefer to avoid that by using signals. Mike -- 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.
models and inheritance
Hi, I have an existing model that I've used for some time, and just recently I had to break it up into two related models that share a great deal, but have some difference, so I used inheritance to create two subclasses. I notice that syncdb is smart enough to not create an sql table for the base class (although this raises the question of what to do if I want a table for it), so this seems to be a supported solution. Still, I'm having problems using the related_name feature for ForeignKeys. Base | Derived --->ForeignKey--->Related If I add a related_name to this ForeignKey of "derived" I get: foo.derived: Accessor for field 'related' clashes with related field 'Related.derived'. Add a related_name argument to the definition for 'related'. All is well if I drop the related_name, but I don't understand the error. Thanks, Mike -- 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.
unique_together across foreign keys
Hi,
So I currently have two models
model Foo(models.Model):
model Bar(models.Model):
foo = models.ForeignKey(Foo)
address = models.IPAddress()
class Meta:
unique_together(('address', 'foo'),)
and this works fine to ensure that the address is unique across each
instance of foo.
Now I want to introduce an intermediary between the two classes, but I
want to keep the constraint.
So it becomes:
model Foo(models.Model):
model Intermediary(models.Model):
foo = models.ForeignKey(Foo)
model Bar(models.Model):
intermediary = models.ForeignKey(Intermediary)
address = models.IPAddress()
Now, is it still possible to specify that the addresses in Bar should
be unique across each instance of Foo? I could add another foreign key
directly from Bar to Foo but that seems ugly.
Thanks,
Mike
--
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.
use a model signal to affect the model's program flow
Hi, I wrote my current Django app in the 0.96 timeframe and have since upgraded, and now I have these cool signals available. I have some model code, like overriding the delete() method to prevent deletion of certain rows in the table, and I'm curious as to whether that can be done with the pre_save signal for the model. Do return values from signals affect the model's execution in any way? I don't see this mentioned in the docs. Thanks, Mike -- 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: auth unit tests fail because sites isn't used
On Jan 7, 7:25 am, Tomasz Zieliński wrote: > I'm also getting this, so I'm only running my own tests (by passing > app names to test). Ok, I suppose that's one solution, but it seems like this test makes bad assumptions and should first check to see if the sites contrib is even in the installed apps list. I guess I'll file a bug report. Mike -- 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.
auth unit tests fail because sites isn't used
I can't find anywhere in the django docs where it says that django.contrib.auth uses django.contrib.sites, but when I run my unit tests I get this == ERROR: test_current_site_in_context_after_login (django.contrib.auth.tests.views.LoginTest) -- Traceback (most recent call last): File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/contrib/auth/tests/views.py", line 191, in test_current_site_in_context_after_login File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/contrib/sites/models.py", line 22, in get_current File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/db/models/manager.py", line 120, in get File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/db/models/query.py", line 300, in get File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/db/models/query.py", line 81, in __len__ File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/db/models/query.py", line 238, in iterator File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/db/models/sql/query.py", line 287, in results_iter File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/db/models/sql/query.py", line 2369, in execute_sql File "/var/tmp/Django-1.1.1-root/usr/lib/python2.4/site-packages/ django/db/backends/sqlite3/base.py", line 193, in execute OperationalError: no such table: django_site -- Ran 45 tests in 22.375s FAILED (errors=1) I don't need the sites app, but it looks like auth needs it. Is that correct? It would be nice to just supress this test from running... Thanks, Mike -- 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: Session ID generated each time web server is restarted
On May 15, 11:42 am, Spk wrote: > It seems that everytime I restart the web server, I get a new session > ID which is why it thinks that there is data to be commited. The > browser still has the cookie for the previous session ID, and it is > stored in the database, so why is Django generating a new session ID > each time the web server is restarted? Yes, why indeed? Is not all information required to maintain the session persistent here? Otherwise, wouldn't you get a new session each time you hit an apache child that you'd never talked to? Mike --~--~-~--~~~---~--~~ 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: file upload docs obsolete?
On May 14, 3:51 pm, msoulier wrote: > I looked here > > http://docs.djangoproject.com/en/dev/topics/http/file-uploads/ > > and it mentions request.FILES being a dictionary, but the 1.0 porting > guide here > > http://docs.djangoproject.com/en/dev/releases/1.0-porting-guide/ > > says otherwise. > > Was this overlooked? I think the page needs an update. Oh, I misread. FILES is still a dictionary, but it no longer returns dictionaries, but UploadedFile objects. Gotcha. Is it Friday yet? Mike --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
file upload docs obsolete?
I looked here http://docs.djangoproject.com/en/dev/topics/http/file-uploads/ and it mentions request.FILES being a dictionary, but the 1.0 porting guide here http://docs.djangoproject.com/en/dev/releases/1.0-porting-guide/ says otherwise. Was this overlooked? I think the page needs an update. Thanks, Mike --~--~-~--~~~---~--~~ 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: custom sql with sqlite causes backtrace
On Apr 18, 1:42 pm, msoulier wrote:
> cursor.execute("""
> BEGIN;
> UPDATE clients
> SET connected = 'false'
> WHERE connected = 'true'
> AND tugid <> %s;
> COMMIT;""", [local_tugid])
And, of course, just after posting this I found the issue.
I put a BEGIN; COMMIT; around the snippet because in postgres the
commands didn't seem to do anything. I foolishly didn't find out why
it worked when I used a sub-transaction. So now my question is why
this didn't seem to work without using one.
The quest for truth continues...
Mike
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
custom sql with sqlite causes backtrace
My production code is using Python 2.3 and Django 0.96. Yes, I know.
Next release picks up Django 1.0.2 and Python 2.4. Yay.
In the meantime, I have a custom model manager with a method that
executes custom sql. Works fine with PostgreSQL, but when I'm
developing with SQLite I get a traceback.
Traceback (most recent call last):
File "", line 1, in ?
File "/home/msoulier/work/mitel-msl-tug/root/etc/e-smith/web/django/
teleworker/clients/models.py", line 43, in disconnectAll
cursor.execute("""
File "/home/msoulier/work/bin/msl8/lib/python2.3/site-packages/
django/db/backends/util.py", line 12, in execute
return self.cursor.execute(sql, params)
File "/home/msoulier/work/bin/msl8/lib/python2.3/site-packages/
django/db/backends/sqlite3/base.py", line 93, in execute
return Database.Cursor.execute(self, query, params)
Warning: You can only execute one statement at a time.
This is the method in question.
def disconnectAll(self, instanceid, nonlocal=False):
instanceid = int(instanceid)
cursor = connection.cursor()
log.debug("ClientManager.disconnectAll: disconnecting non-
local clients")
instance = TugInstance.objects.get(id=instanceid)
local_tugid = instance.tugid
log.debug("local tugid is %s" % local_tugid)
cursor.execute("""
BEGIN;
UPDATE clients
SET connected = 'false'
WHERE connected = 'true'
AND tugid <> %s;
COMMIT;""", [local_tugid])
Am I doing something wrong here?
Thanks,
Mike
--~--~-~--~~~---~--~~
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: PositiveIntegerField returning a string?
On Mar 14, 1:35 am, Russell Keith-Magee
wrote:
> It's possible that this is a known bug that has been fixed since v0.96
> was released. Where exactly did metrics object come from? Is is a
> newly created object, or was it obtained as the result of a query?
It was created as a result of a query.
> If metrics isn't a newly created object, then it would help if you
> could provide a test case that would let us reproduce the problem.
I'm not sure that I can reliably reproduce it, but I can provide what
code I have.
There's a background process that is receiving messages as an IPC
mechanism, and storing the numbers in the metrics table via the
TugMetrics class. The numbers are all strings initially but the daemon
casts them before calling save().
The code populating it looks like this
metrics.user_licenses_ca = int(
details.get('Max_users', '0/0/0').split('/')[2])
The Max_users field contains a '/' delimited sting of three numbers,
which is why I'm splitting like that.
The int() call should enforce an integer.
What's really odd is that when I use a django shell, all of the
properties seems to be integers instead of this one. I'm not sure why.
I'm currently working around it by calling int() when I pull the value
out again.
Mike
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
PositiveIntegerField returning a string?
Hi, Django 0.96 (yes, I know, we'll be at 1.0.2. soon), and I have a model full of PositiveIntegerField attributes. One of them is returning a string. >>> metrics.user_licenses_ca '315' >>> type(metrics.user_licenses_ca) PostgreSQL backend I thought that the PositiveIntegerField would enforce the correct type. Is that not true? I checked the code populating this too, and it's populated from a string inside of an int() call, so it should be an integer when it is set. I thought that was required... Thanks, Mike --~--~-~--~~~---~--~~ 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: transactions and locking in postgreSQL
On Dec 5, 10:43 pm, Jeffrey Straszheim <[EMAIL PROTECTED]> wrote: > I took a quick glance at transaction.py (where the TransactionMiddleware > class is defined), and it appears you are correct. However, it should > be pretty easy to roll your own transaction class that skips the > is_dirty check. > > This should probably be a bug report in any case. I'm going to have to do further investigation. I found the reason for the blocking that I was seeing and it is my own fault. However, I am now left wondering how this normally works. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
transactions and locking in postgreSQL
Looking at the transaction middleware that wraps a transaction around every HTTP request, I've found that it only commits if the transaction is "dirty" (you change something). So, if you use this middleware unconditionally, then in view functions that only read, the transaction will never be committed. Even when you read, postgres implicitly locks tables for reading. I am finding that since commit is never called in these cases, the locks persist. Is anyone using the transaction middleware with postgres? I have to assume so. If so, then what am I doing wrong? Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django table locking
On Dec 3, 2:16 pm, msoulier <[EMAIL PROTECTED]> wrote: > So one process was waiting to acquire an AccessExclusiveLock, and > there was already an AccessShareLock on it (the clients table). I've tried Django's transaction middleware, but I'm not sure that a commit is taking place in postgres, as the locks don't seem to be releasing. I've had to remove the transaction middleware to prevent the locks from being held forever. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django table locking
On Nov 18, 7:46 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Django doesn't do any explicit table locking, although there are > transactions involved. However, that shouldn't be affecting this. So Django is not safe to use in a concurrent environment? Well, it is if you don't mind two users stepping on one another's changes, which you would have to prevent with explicit, optimistic locking, I assume? > You just say "read locks", but that isn't a defined postgreSQL lock Sorry, my tables looked like this: relname | relation | database | transaction | pid | mode | granted -+--+--+-+--- +-+- pg_class| 1259 |17456 | | 12221 | AccessShareLock | t adminevents |17818 |17456 | | 31151 | AccessShareLock | t clients |17618 |17456 | | 10325 | AccessExclusiveLock | f clusternode |17759 |17456 | | 31151 | AccessShareLock | t pg_locks|16759 |17456 | | 12221 | AccessShareLock | t clients |17618 |17456 | | 31151 | AccessShareLock | t cluster |17746 |17456 | | 31151 | AccessShareLock | t So one process was waiting to acquire an AccessExclusiveLock, and there was already an AccessShareLock on it (the clients table). Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
django table locking
Hello, I have a daemon process running using the Django ORM API to access/ modify tables in PostgreSQL. I just ran into an issue where it looks like the process is keeping read-locks on the tables that it is reading, which is preventing a subsequent write lock from granting. Does the ORM API normally lock tables? If so, when are the locks released? Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: handling database restarts
On Sep 3, 3:44 pm, Rajesh Dhawan <[EMAIL PROTECTED]> wrote: > Hi Mike, > > Assuming that the DB restarts are rare, consider surrounding your > processing loop with a try..except block. When the exception occurs, > close the current connection so that the next iteration of your loop > gets a fresh connection. This way, you can reuse one connection as > long as it continues to work. Thanks, that's a good approach. I noticed an upstream patch to the postgres adapter to handle this automatically, hopefully that makes it into a future release. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
handling database restarts
I have a long-running process that, to save on code, is using the
Django models used in the web app to access the database.
ie.
os.environ['DJANGO_SETTINGS_MODULE'] = 'myapp.settings'
sys.path.append(os.path.abspath('/path/to/django/project'))
from myapp.subapp.models import MyModel
This works well at reducing the code requirements for the back-end
that is asynchronously populating the database from another source.
But, now and then something restarts the database. If this process it
not restarted, I then get constant exceptions:
/usr/lib/python2.3/site-packages/django/db/backends/
postgresql_psycopg2/base.py", line 50, in cursor
2008-09-03 09:19:24.170841500 InterfaceError: connection already
closed
I'm using postgres...
Now, I took a guess that if I closed the db connection, the framework
would open a new one, so I added this to each processing loop.
from django.db import connection
connection.close()
and this seems to work. No more exceptions when the db is restarted.
Now, I could have the service restarted when the db is, but I'm hoping
for a more elegant solution. I don't like either solution at the
moment, and I'm looking for recommendations.
Thanks,
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
sending large downloads
Hello, I saw some posts on this but not many useful responses. Apologies if there's already a known solution. For a web-based backup, I need to send a large file, basically the output of a tar process, to the browser. We have legacy Perl code doing this now but I'd like to use Django. Is there a way to stream this without reading the entire file into memory and writing it into the HttpResponse object? Or am I operating under a bad assumption? I see now that the docs show a flush() method. Could I say, read 1024 bytes at a time, write() them and flush() them without consuming large amounts of memory? Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: error with custom sql
On May 15, 2:23 pm, msoulier <[EMAIL PROTECTED]> wrote: > So, custom SQL in Django can't include a LIKE statement with a % > unless it's escaped? I'm > looking in the docs and I can't seem to find anything that mentions > that. In fact, I've replaced my % with %% and it's not matching anything now. So, I can't use LIKE at all in Django's custom SQL? Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
get_decoded in django shell results in SuspiciousOperation exception
I'm trying to inspect the session data in the db.
>>> from django.contrib.sessions.models import Session
>>> q = Session.objects.all()
>>> for s in q:
...print s.get_decoded()
...
Traceback (most recent call last):
File "", line 2, in ?
File "/var/tmp/django-0.96.2-root/usr/lib/python2.3/site-packages/
django/contrib/sessions/models.py", line 82, in get_decoded
SuspiciousOperation: User tampered with session cookie.
And yet...
>>> pickle.loads(base64.decodestring(s.session_data))
{'orderby': 'clientid', 'spp': u'20'}
There's my data. Doesn't look corrupt.
I have no issues in the UI, just when using the Django shell.
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: error with custom sql
On May 15, 2:13 pm, msoulier <[EMAIL PROTECTED]> wrote: > Actually, it fails in the Django shell, and there only, regardless of > the db backend. Oh, scratch that. I just got it to fail consistently in a simple script that runs only that code. So, custom SQL in Django can't include a LIKE statement with a % unless it's escaped? I'm looking in the docs and I can't seem to find anything that mentions that. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: error with custom sql
On May 14, 10:27 pm, msoulier <[EMAIL PROTECTED]> wrote: > This seems to work in production with postgreSQL, but on my laptop > with sqlite I'm seeing an issue. Actually, it fails in the Django shell, and there only, regardless of the db backend. Can anyone think of why? Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
error with custom sql
Hi,
I've subclassed the manager in a model to add a custom method.
class ClientManager(models.Manager):
"""This is a custom manager for the Client model, implementing
some custom
methods for bulk editing of clients in the database in a more
efficient
manner."""
def disconnectAll(self):
"""This method is run at tug startup and shutdown to ensure
that all
clients have the proper initial state of disconnected. It also
removes
all SIP clients, since they cannot be persistent."""
cursor = connection.cursor()
cursor.execute("""
UPDATE clients_client
SET connected = 'f'
""")
cursor.execute("""
DELETE FROM clients_client
WHERE clientid like '%SIP'
""")
This seems to work in production with postgreSQL, but on my laptop
with sqlite I'm seeing an issue.
Traceback (most recent call last):
File "", line 1, in
File "/home/msoulier/work/mitel-msl-tug/root/etc/e-smith/web/django/
teleworker/../teleworker/clients/models.py", line 22, in disconnectAll
""")
File "/home/msoulier/python/lib/python2.5/site-packages/django/db/
backends/util.py", line 21, in execute
'sql': sql % params,
TypeError: not enough arguments for format string
It looks like the util backend doesn't allow the standard % character
for a LIKE comparison.
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Logging framework (like log4j)?
On May 8, 2:54 pm, ydjango <[EMAIL PROTECTED]> wrote: > Is there a application level logging framework/utility in django or > python that I can use in views to log to file and/or database. > Something similar to log4j in java. I'm using the Python standard library's logging module. Works fine. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: The connection was reset
On May 5, 2:01 pm, msoulier <[EMAIL PROTECTED]> wrote: > Seems like an issue with the built-in web server. In fact, if I modify handlers/wsgi.py, and print the request object before it gets to get_response(), suddenly it's fine. try: request = WSGIRequest(environ) print "DEBUG:", request response = self.get_response(request) So it sounds like something going into get_response was perhaps not initialized? Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
The connection was reset
Hi,
I'm currently playing with my Django web interface on a windows XP box
with Python 2.5, Django 0.96. Sometimes when I send a redirect in view
code, Firefox says, "The connection was reset while the page was
loading."
Seems like an issue with the built-in web server.
Sample code:
elif request.method == 'POST':
log.debug("in a POST request")
request.session['error'] = "Operations not yet implemented"
log.debug("sending a redirect")
return HttpResponseRedirect(baseurl + 'clients/')
Has anyone else seen this?
Thanks,
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: using Q() with relations
On May 1, 11:39 am, msoulier <[EMAIL PROTECTED]> wrote:
> So, I narrowed it down to the OR of the resultant querysets.
Ah, it's an inner join, so this likely wouldn't work for any
database.
>>> p.pprint(q3._get_sql_clause())
( [ '"clients_client"."id"',
'"clients_client"."enabled"',
'"clients_client"."clientid"',
'"clients_client"."connected"',
'"clients_client"."description"',
'"clients_client"."enabledjl"',
'"clients_client"."compression"',
'"clients_client"."localstreaming"',
'"clients_client"."logverbosity"',
'"clients_client"."rtpframesize"',
'"clients_client"."activedn"',
'"clients_client"."inactivedn"',
'"clients_client"."settype"',
'"clients_client"."instance_id"',
'"clients_client"."icp_id"'],
' FROM "clients_client" INNER JOIN "icps_icp" AS
"clients_client__icp" ON "clients_client"."icp_id" =
"clients_client__icp"."id" WHERE (("clients_client"."description"
ILIKE %s) OR ("clients_client__icp"."name" ILIKE %s))',
['%soulier%', '%soulier%'])
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: using Q() with relations
On May 1, 11:16 am, msoulier <[EMAIL PROTECTED]> wrote: > I have a case where I'm trying to OR several conditions together in a > query, and I'm including a query against a field in a foreign key > field. > > queryset = queryset.filter( > Q(clientid__icontains=filter) | > Q(description__icontains=filter) | > Q(icp__name=filter) > ) > > here, icp is a foreign key, and we're trying to match it's field > "name". > > In some cases, icp is NULL, so there is no corresponding model to > follow, and in those cases, this query always fails to return models > that it otherwise would. So, I narrowed it down to the OR of the resultant querysets. >>> q1 [, , , ] >>> q2 [] >>> q1 | q2 [] q2 involves the foreign key lookup where 3 of the objects in q1 have a NULL in that place. Is this not a bug in how the querysets are OR'd? Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: concatenation of querysets
On May 1, 11:20 am, msoulier <[EMAIL PROTECTED]> wrote: > I looked in the docs and I've failed to find, so I apologize if it's > freakin' obvious, but how does one concatenate two querysets? Doh! http://groups.google.ca/group/django-users/browse_thread/thread/d22e8a8f378cf0e2 Forget it. :) Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
concatenation of querysets
I looked in the docs and I've failed to find, so I apologize if it's freakin' obvious, but how does one concatenate two querysets? ie. q1 = Client.objects.filter(name__icontains='foo') q2 = Client.objects.filter(description__icontains='bar') q3 = q1 + q2 ?? How would I merge these? They behave somewhat like Python lists, but not entirely. Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
using Q() with relations
I have a case where I'm trying to OR several conditions together in a query, and I'm including a query against a field in a foreign key field. queryset = queryset.filter( Q(clientid__icontains=filter) | Q(description__icontains=filter) | Q(icp__name=filter) ) here, icp is a foreign key, and we're trying to match it's field "name". In some cases, icp is NULL, so there is no corresponding model to follow, and in those cases, this query always fails to return models that it otherwise would. For example, in matching a description substring, 4 objects would be returned that have that substring, but if I OR with the final part of this where the icp.name is checked, and 3 of the 4 returned have NULL icps, then only 1 model is returned. I find this very non-intuitive, and I'm wondering if this is intentional. It is an OR condition, afterall, so I don't see why a non- null icp should be required here. Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: "data" is a reserved field in newforms?
On Apr 30, 9:26 pm, Doug Van Horn <[EMAIL PROTECTED]> wrote: > Seehttp://www.djangoproject.com/documentation/newforms/#accessing-clean-..., > check the 'Note' section. Ah, that explains much. Many thanks. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
"data" is a reserved field in newforms?
A coworker of mine created a form with a field called "data". ie. data = forms.CharField() This resulted in an exception being thrown when is_valid() was called on the form: form error - 'dict' is not callable The exception occurs at line 180 in \lib\site-packages\django\newforms\forms.py in Django 0.96. The reason is that the hasattr() call for "clean_data" returns true. We're just considering "data" as a reserved word in newforms now, but I wanted to check to see if this was known. If so, I'd expect an error saying so, instead of the cryptic one that we received. Thanks, Miker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
ensuring uniqueness in newforms
If I have a field, for example a CharField named 'name', which must be unique, what's the best way to ensure uniqueness whether creating a new entry or editing an existing one? By default, the form won't know if it is being used to edit or create, so if you look for duplicates in the db, how would you know whether any dup you found is just the current entry being edited? Or is the form the wrong place for this kind of thing? Should this instead be enforced in the model, and we should instead catch the exception throw during the save attempt? I'm guessing not, as I was once told that validation in the model is deprecated. Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: obeying the DRY principle in views
On Mar 31, 10:04 pm, Michael <[EMAIL PROTECTED]> wrote: > Not really a DRY issue moreover there is an easier logic to your code: Sad that I didn't see that. Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
obeying the DRY principle in views
I find myself doing this a lot in view code
if request.method == 'GET':
form = MyForm(initial=data)
return render_to_response('template.html',
RequestContext(request, {
'foo': foo,
'bar': bar
}))
elif request.method == 'POST':
form = MyForm(request.POST)
if form.is_valid():
# make new model object and save
else:
# same as the GET method code to display errors
The issue is that if the form validation fails, I end up using the
same code to display the page.
Is there a better way? I could put the template render in a function,
but I'm not sure how much that would save. What do the rest of you do?
Thanks,
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: problems with url tag
On Mar 5, 6:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> In the meantime, use the url(...) form for your url patterns and give
> each one that might cause confusion a unique name. That way you can
> refer to them uniquely in the {% url ... %} tag.
Ok, I'll do that when the next Django release is out, or I'll package
the trunk from SVN. The latter would make my coworkers nervous.
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
problems with url tag
So, my urlconf is
urlpatterns = patterns('teleworker.clients.views',
(r'create/$', 'create'),
(r'modify/(?P\d+)/$', 'modify'),
(r'delete/(?P\d+)/$', 'delete'),
(r'page/(?P\d+)/(?P\w+)/(?P\w+)/$',
'list'),
(r'page/(?P\d+)/$', 'list'),
(r'^$', 'list'),
)
The list function is
def list(request, page=1, orderby='clientid', direction='forward',
filter=None):
When I try to use the url tag to get a url to this function, it only
matches the last line of the urlconf.
{% url teleworker.clients.views.list
page=1,orderby=clientid,direction=forward %}
What am I missing?
Thanks,
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: loaddata on big fixture doesn't seem to end
On Feb 21, 10:57 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > I've logged this as #6643. I'm hoping to have some time tonight to > look at a few outstanding fixture tickets; I'll add this one to the > list. Thanks, you guys rock. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
loaddata on big fixture doesn't seem to end
Hi, I'm loading a fixture with 2500 objects in it into postgres 7.4. For some reason, loaddata is looking in a lot of additional places than the file I'm handing it. [EMAIL PROTECTED] teleworker]# PYTHONPATH=.. python manage.py loaddata /root/clients.json Loading '/root/clients.json' fixtures... Installing json fixture '/root/clients' from '/usr/lib/python2.3/site- packages/django/contrib/auth/fixtures'. Installing json fixture '/root/clients' from '/usr/lib/python2.3/site- packages/django/contrib/contenttypes/fixtures'. Installing json fixture '/root/clients' from '/usr/lib/python2.3/site- packages/django/contrib/sessions/fixtures'. Installing json fixture '/root/clients' from '/etc/e-smith/web/django/ teleworker/dashboard/fixtures'. Installing json fixture '/root/clients' from '/etc/e-smith/web/django/ teleworker/icps/fixtures'. Installing json fixture '/root/clients' from '/etc/e-smith/web/django/ teleworker/clients/fixtures'. Installing json fixture '/root/clients' from '/etc/e-smith/web/django/ teleworker/advanced/fixtures'. Installing json fixture '/root/clients' from '/etc/e-smith/web/django/ teleworker/proxies/fixtures'. Installing json fixture '/root/clients' from '/etc/e-smith/web/django/ teleworker/metrics/fixtures'. Installing json fixture '/root/clients' from '/etc/e-smith/web/django/ teleworker/js/fixtures'. Installing json fixture '/root/clients' from absolute path. Installed 27500 object(s) from 11 fixture(s) Is there a way to skip everything else and just load the one fixture I handed it? Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: backtrace trying to get django deployed with apache and mod_python
On Feb 16, 8:37 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > Are you trying to use mod_python 2.7.X on Apache 1.3 by chance? Indeed I am. > From memory ap_auth_type attribute may only be in Apache 2.X and thus > you need to be using mod_python 3.X, preferably 3.3.1, on Apache 2.X. Ok, thanks for the information. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: DATABASE_PORT ignored?
On Feb 16, 3:41 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Instead, you need to use 127.0.0.1 to force the connection to go via > TCP/IP. I'm pretty sure, without having tested it, that Django will be > fine with that (setting the HOST string to an IP address). We just pass > that information straight through to the MySQLdb python wrapper, so > whatever it accepts, we accept. I'll try that, thanks. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
backtrace trying to get django deployed with apache and mod_python
I'm trying to move an existing site to another server, and I'm getting
this error when I access the new site.
Mod_python error: "PythonHandler django.core.handlers.modpython"
Traceback (most recent call last):
File "/usr/local/python-2.5/lib/python2.5/site-packages/mod_python/
apache.py", line 193, in Dispatch
result = object(req)
File "/home/pawsitiveapproach/python/lib/python2.5/site-packages/
django/core/handlers/modpython.py", line 177, in handler
return ModPythonHandler()(req)
File "/home/pawsitiveapproach/python/lib/python2.5/site-packages/
django/core/handlers/modpython.py", line 150, in __call__
response = self.get_response(request)
File "/home/pawsitiveapproach/python/lib/python2.5/site-packages/
django/core/handlers/base.py", line 59, in get_response
response = middleware_method(request)
File "/home/pawsitiveapproach/python/lib/python2.5/site-packages/
django/middleware/common.py", line 28, in process_request
if request.META.has_key('HTTP_USER_AGENT'):
File "/home/pawsitiveapproach/python/lib/python2.5/site-packages/
django/core/handlers/modpython.py", line 92, in _get_meta
'AUTH_TYPE': self._req.ap_auth_type,
File "/usr/local/python-2.5/lib/python2.5/site-packages/mod_python/
apache.py", line 85, in __getattr__
raise AttributeError, attr
AttributeError: ap_auth_type
I tried searching for it but I didn't turn up much. Any ideas?
Thanks,
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: manage.py help message seems inaccurate
On Feb 11, 8:02 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > This is correct - SQL for data fixtures won't be dumped. The error > message is a little misleading in this respect, as it refers to > initial data, not custom SQL. I've clarified the text in [7106]. > > As for the --interactive error: what version of Django are you using? > I can't reproduce this problem. I'm using 0.96. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
DATABASE_PORT ignored?
I have a site where I need to use the mysql tcp port of 3306 instead of the unix domain socket, to talk to mysql. So, I did this in my settings.py DATABASE_HOST = 'localhost' DATABASE_PORT = 3306 Unfortunately, it seems to be ignored. _mysql_exceptions.OperationalError: (2002, "Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)") Is it possible to tell Django to tell MySQLdb to use the tcp port? Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
manage.py help message seems inaccurate
syncdb [--verbosity] [--interactive] Create the database tables for all apps in INSTALLED_APPS whose tables haven't already been created. python manage.py syncdb --interactive manage.py: error: no such option: --interactive sqlall [appname ...] Prints the CREATE TABLE, initial-data and CREATE INDEX SQL statements for the given model module name(s). When I ran sqlall with apps that have initial_data.json files, which syncdb does respect, the SQL for these were not dumped. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ForeignKey _id not so transparent
On Jan 27, 12:46 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > You can assign a numeric ID of a TugInstance object to 'instance_id' > on a Client object. > > You can assign an actual honest-to-goodness TugInstance object to > 'instance' on a Client object. Ah, that helps. The docs don't seem to cover that. Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
ForeignKey _id not so transparent
So, I have a Client model that includes an instance field instance = models.ForeignKey(TugInstance) When my form is submitted, I am assigning client.instance = form.clean_data['instance_id'] But this isn't working. I get an error on save() that 'instance_id' cannot be NULL. If I change my code to client.instance_id = , then it works. But, according to this page http://www.djangoproject.com/documentation/model-api/#relationships the _id is supposed to be transparent. Did I do something wrong? Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: templating javascript code
On Dec 2, 8:27 pm, Darryl Ross <[EMAIL PROTECTED]> wrote: > I've done this is CSS files before, so it should work just fine. Just > make sure you set the correct Content-Type header in your JS view. FTR, this works fine. I couldn't use render_to_response() as I had to supply the mimetype, but otherwise it works fine. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
django requires db access to dump sql that it would use in syncdb
I'm trying to write db initialization code for an existing db framework on a product that I work on. To do this I'm "asking" django to show SQL that it would use to create its db, so I can copy it into the initialization code. I can't though, as I haven't created the db yet, and for some reason it requires access to the db, even though it's not actually performing any operations on the db. [EMAIL PROTECTED] servermanager]# python manage.py sql main BEGIN; Traceback (most recent call last): File "manage.py", line 12, in ? execute_manager(settings) File "/var/tmp/django-0.96-root/usr/lib/python2.3/site-packages/ django/core/management.py", line 1672, in execute_manager File "/var/tmp/django-0.96-root/usr/lib/python2.3/site-packages/ django/core/management.py", line 1632, in execute_from_command_line File "/var/tmp/django-0.96-root/usr/lib/python2.3/site-packages/ django/core/management.py", line 123, in get_sql_create File "/var/tmp/django-0.96-root/usr/lib/python2.3/site-packages/ django/core/management.py", line 68, in _get_table_list File "/var/tmp/django-0.96-root/usr/lib/python2.3/site-packages/ django/db/backends/postgresql_psycopg2/base.py", line 48, in cursor psycopg2.OperationalError: FATAL: Password authentication failed for user "smeserver" Seems like a bit of a chicken and egg problem. I'll create the db and user now, but I don't see why it should be required when it's not being used by the command. I suppose it might not be fixable, as it may be in the psycopg2 module. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
templating javascript code
Hi,
I'm adding some Ajax effects to my Django site, and there are some
things in the javascript that I'd like to template. Currently my
javascript is inline in my index.html file, so I can template things
like
var debug = {{ debug }};
var refreshtime = {{ refreshtime }};
That way, settings in my javascript can be controlled by database
settings, and when I turn on debug, it's turned on everywhere.
I want to split this javascript out. Has anyone tried templating
javascript like any other file? I'm going to try it out, but I thought
I'd ask if anyone knew of any problems, or any better way to do this.
Thanks,
Mike
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
questions about form_for_model
I am using Django stable (0.96). When I use form_for_model on a model that includes CharFields that have choices attributes, the resulting form field is not a ChoiceField as specified in the documentation. Is this simply a bug in 0.96? Also, if I wish to return a different field type, not based on the model field type, but by the name of the model property, is that possible using formfield_callback? I'm debating just writing my own form class instead so all of my exceptions to the norm are explicitly advertised in the resulting class. If I do so, is there a simple way to tie the form attributes to the corresponding model? I've been doing this... thing = MyModel.objects.filter(id=id) params = thing.__dict__ del params['id'] form = MyForm(params) Seems like a hack, but I'm finding it difficult to customize the resulting form returned from the form_for_model call. Perhaps I've missed some flexibility here. Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: using multiple databases
On Sep 17, 11:00 pm, "Ben Ford" <[EMAIL PROTECTED]> wrote: > Hi Mike, > There is a branch that supports multiple databases in the repository. It's > quite out of date in the SVN repo but Koen put in some stirling work over > the period of the sprint and produced a patch against trunk at around r6100. Hmm. Looking at the repository, it looks like 0.96 was r4810. Sounds like a lot was done since then. :) > Multiple-db support is a feature that is asked for very regularly, > unfortunately there have been issues getting the latest changes into the > repo so others can use the branch. This is mainly due -as I understand it - > to quality of the code, lack of working tests, and the fact that the core > devs are busy on other things. I can send you a copy of the patch if you > like, or there's an earlier patch attached to ticket 4747 which is the > current version I'm using in production. Something that could just patch 0.96 would be nice. I don't mind trying it out. > Koen is busy this week I think, but we're probably going to discuss > refactoring the multi-db branch to take advantage of recent changes in the > backend code in the near future. > At present multi-db is usable, and as I said I have it in one of my projects > right now. Having said that, it's quite beta and to get the most out of it > you're going to have to be pretty happy digging through django's internals. > If you are happy doing that we'd love some help with it, as there's still a > lot to be done! If you want either patch then send me a mail, and of course > if you have any problem/comments/suggestions I'm more than happy to help. I was hoping to just point each application at a different database, nothing more. If the patch accomplishes that, then I don't mind looking. Thanks, Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
using multiple databases
I was hoping to use Django in a web management UI for a server that I support, where new UIs are added as new applications are installed. Due to this plugin requirement, I had planned to model that with one large Django project, where each new plugin was a Django application. Unfortunately it would appear that this would not work, as each application potentially needs its own database, and Django only permits a single one to be specified. In Rails I can specify new dbs at the model level to override the default. Is there any way to do this in Django? Surely the requirement for more than one database to drive an entire site's content is present. If not, I could use multiple Django projects, with one project per plugin, but I would still like to share some common code for inclusion tags, templates, etc., to ensure that the pages all have the same look and feel. Is there a recommended way to do this? Thank you for any help that you can offer. Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
