Re: Problems creating a project with django-admin startproject (New Django user)
[EMAIL PROTECTED] skrev: > Just installed python/apache/django/mod_python with all the latest > versions. > > I think I got most of my PATH variables set up correctly. However, > when I try: > > C:\django>django-admin.py startproject testproject1 > Traceback (most recent call last): > File "C:\Python25\Scripts\django-admin.py", line 5, in > management.execute_from_command_line() > File "C:\Python25\lib\site-packages\django\core\management > \__init__.py", line > 255, in execute_from_command_line > utility.execute() > File "C:\Python25\lib\site-packages\django\core\management > \__init__.py", line > 215, in execute > self.fetch_command(subcommand).run_from_argv(self.argv) > File "C:\Python25\lib\site-packages\django\core\management\base.py", > line 70, > in run_from_argv > self.execute(*args, **options.__dict__) > File "C:\Python25\lib\site-packages\django\core\management\base.py", > line 84, > in execute > output = self.handle(*args, **options) > File "C:\Python25\lib\site-packages\django\core\management\base.py", > line 152, > in handle > label_output = self.handle_label(label, **options) > File "C:\Python25\lib\site-packages\django\core\management\commands > \startproje > ct.py", line 30, in handle_label > settings_contents = open(main_settings_file, 'r').read() > IOError: [Errno 2] No such file or directory: 'C:\\django\ > \testproject1\\setting > s.py' > > What might be wrong ? :/ Googling in general hasn't turned up much. > I'm pretty newb all around though so it very well may be something > simple and obvious. If more information is needed I can furnish that. > Was the directory "c:\django\testproject1" created? Is there a settings.py file? Is there something screwy going on with permissions? Which version of Windows is this - it seems "everyone" is having problems with permissions in Vista ... Nis --~--~-~--~~~---~--~~ 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 when trying to save unicode data
Kenneth Gonsalves skrev: > On 02-Oct-07, at 6:21 PM, Nis Jørgensen wrote: > > >>> get_or_create, *only* using the value of 'word' in the query - if >>> created, then I do an update to set the other fields - otherwise I >>> leave it alone. >>> >> You could also use the "defaults" argument to get_or_create: >> >> http://www.djangoproject.com/documentation/db-api/#get-or-create- >> kwargs >> > > tried that too - it didnt help. For what it's worth, I filed a bug, > although I am not completely sure whether it is a bug. > > http://code.djangoproject.com/ticket/5662 > Part of your description in the ticket - specifically this part """ If the row containing 'word' is got, then the row has to be updated with the remaining values. If it is created - again it needs to be updated with the remaining values. """ is different from the description in this thread (quoted above), as well as from the first part of the ticket """ If the 'word' exists, the no action should be taken, """ get_or_create with "defaults" does what you asked for originally - though the person commenting in the ticket got the syntax wrong. Nis --~--~-~--~~~---~--~~ 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 when trying to save unicode data
Kenneth Gonsalves skrev: > > I now do > get_or_create, *only* using the value of 'word' in the query - if > created, then I do an update to set the other fields - otherwise I > leave it alone. You could also use the "defaults" argument to get_or_create: http://www.djangoproject.com/documentation/db-api/#get-or-create-kwargs Nis --~--~-~--~~~---~--~~ 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 when trying to save unicode data
Kenneth Gonsalves skrev: > hi, > > I have a view that takes a sentence in unicode from a database, > splits it into words and dumps those words in the Word table. The > 'word' in word table is unique, and it is expected that duplicates be > rejected, so I put 'save()' within a try-except statement. If my view > does one record at a time - it works perfectly. If I try to loop > through all the records, I get a ProgrammingError complaining of > improper formatting - but am unable to find out where exactly the > formatting is improper. If I put this function in the 'save' method > of the model - I get the same error. This is an instance of the problem described here: http://code.djangoproject.com/ticket/5043 You may be able to get around this by using manual transaction handling. I see now that someone requested that I start a thread on django-dev about the issue ... will do so when time permits. --~--~-~--~~~---~--~~ 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: RSS feed reader in Python
stanleypark skrev: > We just finiched a really cool RSS feed news reader. I need people > comments on it. > here is the link of the web site. > I see no link at this point in your post. Anyway, who are "we"? > If you wish to know more about RSS feeds here is a group link that I > just started. > http://groups.google.com/group/adsense-and-rss-feeds/web/netsplorer-com?hl=en > all the best to everyone > If you want to attract people, you should make this readable to non-members. I am not going to sign up for something just to see if it is interesting. Nis --~--~-~--~~~---~--~~ 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: strange behavior of primary_key and ManyToManyField
zeliboba skrev: > actually, I understand how it works, it seems to be a bug anyway. > consider this: > > from django.db import models > > class Author(models.Model): > name = models.CharField(maxlength=50) > > class Reference(models.Model): > """ > >>> a = Author(name='some name') > >>> a.save() > >>> r = Reference(title='some title') > >>> r.authors.add(a) > >>> r.save() > """ > id = models.CharField(maxlength=5, primary_key=True) > title = models.CharField(maxlength=50) > authors = models.ManyToManyField(Author) > > I specified primary_key explicitly and it works without saving before > adding Author. Yes, this is a bug. This should definitely raise an error. I guess the reason it doesn't is that char fields (like your primary key) are automatically populated with an empty string. Still, I would expect the .add(a) to gfive a foreign key violation. Does your backend support foreign keys? Also, if you understand what is happening, why aren't you just doing what Leo is suggesting, rather than adding additional fields? Nis --~--~-~--~~~---~--~~ 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: Objects.get() need to limit 1 record
cschand skrev: > Thanks for you replies > > but one thing... there are some differences between get and filter > > from get return obj is user model obj > but in filter it is recordsets... (I don't know i am right or not) > .get(...) returns a model object .filter(...) returns a queryset - which can be treated like a list of model objects (almost). .filter(...)[0] returns a model object - or throws an error (IndexError I hope) if no records are found. Nis --~--~-~--~~~---~--~~ 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: baffling i18n problem after unicode update
Kenneth Gonsalves skrev: > On 20-Sep-07, at 4:42 PM, Werner F. Bruhin wrote: > > >>> other pdf reports. Not this particular one. I *know* there has to be >>> some very simple explanation for this - but cant for the life of me >>> find what it is. >>> >>> >> Does "Good" in Finish use some special characters? >> > > it does - but so do other words that are getting translated > successfully, and 'Good' itself is getting rendered properly in other > parts of the site and in other reports > Still, those other parts/reports may be doing something slightly different. I assume that the translations of "Average" and "Poor" are ascii. Try changing the translation of "Good" to something without special characters, and see if that helps. If it does, you at least know that this is a charset/encoding issue - although this doesn't solve it. Next, I would look at finding the difference between this report and the ones that work. Could it be that this report uses a different font, which has problems with the special characters? Nis --~--~-~--~~~---~--~~ 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: unknown encoding cp0
Benedict Verheyen skrev: > Hi, > > a while back i updated my python isntall to version 2.5.1. on a Windows > 2000 server. It also runs Apache 2.2 & mod_python for Django. > Since the python upgrade, i got this "unknown encoding cp0" error. > > I hadn't changed anything to the code. The errors always occured on > print commands. I found a workaround by adding str() > Thus > print "Blabla %s " % self.blabla > had to be changed to > print "Blabla %s " % str(self.blabla) > in order to solve the problem. > What is "self" referring to? Can you give us a stack trace? And which version of Django are you running (it is especially important to know if it is before or after the unicode branch got merged). Nis --~--~-~--~~~---~--~~ 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: cronjob
patrickk skrev: > now I get: > ImportError: No module named django.core.management > > the directory "django_src" is on my python-path. > It probably isn't on cron's python-path, though. Try adding PYTHONPATH=/your/python/path to the top of your crontab. -- Nis Jørgensen Who is NOT a relative of Christian --~--~-~--~~~---~--~~ 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: duplicate key violates unique constraint
Michal skrev: > Hello, > I have problem with inserting duplicate rows into DB. > > There is registration form on my site. User fill email address together > with additional parameters (form definition: http://dpaste.com/19959/). > After POST it to the server, email is checked in form against DB. If > user with same email exists, form error is generated. > > If form is valid (ie. user doesn't exists) I make another test in the > view and then call my function for creating whole new account: > >f_email = form.cleaned_data['email'] >if User.objects.filter(email__exact=f_email).count() == 0: > create_account(form.cleaned_data) > > In the create_account I try to create new user like this: > >user = User.objects.create_user(username, form['email'], > form['password1']) > What is the value of "username"? This is what gives you the problem, not "email", as indicated here: > IntegrityError: ERROR: duplicate key violates unique constraint > "auth_user_username_key" > Nis --~--~-~--~~~---~--~~ 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: ifequal function not working?
John M skrev: > the ID is the primary key ID generated by django on models. > > basically, it's not the syntax im having issue with, i think the > selected_id is being passed / parsed as a string not an intenger like > ID is. > So where do you get the selected_id from? GET/POST variables are always strings. Could you try converting it to an int before you pass it to the template? Nis --~--~-~--~~~---~--~~ 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: Deleting the relations and not the objects?
Xan skrev:
> class Aclass(models.Model):
> be = models.ForeignKey('B')
> ce = models.ManytoManyfield('C')
>
> class B(models.Model):
>[...]
>
> class C(models.Model):
> [...]
>
> Suppose that with admin interface, I put:
> be = b1 (b1 is B)
> ce has c1, c2, c3 objects (c1, c2 and c3 are in C)
>
> in an object p (p in Aclass)
>
> I want to delete the relation that ce has c1 without deleting c1.
> How can I do that with shell?
>
> Do you understand that I want? If I run:
> p = Aclass.objects.get(pk=1) # p is the object I have
> p.be.all()
>b1
> p.ce.all()
>c1, c2, c3
>
> I want that p.ce.all() will be empty set, but c1, c2 and c3 exits as
> intances of class C
>
Use
p.ce.clear()
or
p.ce = []
or
p.ce.remove(c1)
p.ce.remove(c2)
p.ce.remove(c3)
All found in the documentation at
http://www.djangoproject.com/documentation/models/many_to_many/ , not tested
This should work as well:
p.ce.remove(c1,c2,c3)
Found in http://www.djangoproject.com/documentation/db-api/
Nis
--~--~-~--~~~---~--~~
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: Only Simplified Chinese translation not working?
Ryan K skrev:
> Hi. I have a few languages I've translated my site into. They all work
> except Simplified Chinese. Any hints as to why?
>
Try being more specific than "does not work". Do you see English,
garbled characters, something else?
> This is in my settings file:
>
> LANGUAGES = (
> ('es', ugettext('Spanish')),
> ('fr', ugettext('French')),
> ('it', ugettext('Italian')),
> ('ru', ugettext('Russian')),
> ('zh-cn', ugettext('Simplified Chinese')),
> )
>
> And the .po and .mo files are under the zh-cn directory (in locale).
>
In my installation, the directory is called zh_CN, not zh-cn. zh_CN is a
locale-specification, zh-cn is a language specification. I am not sure
which one is correct, but there definitely is code in django which
translates from one to the other. Try renaming (or symlonking) to zh_CN
and see if this helps.
Nis
--~--~-~--~~~---~--~~
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: how to validate not blank field?
[EMAIL PROTECTED] skrev:
> thanks for your reply! i resolved using this code in the models.py
> before save(): def save(self): if len(self.title)<6: raise
> ValidationError("cannot be blank or small than 6 byte!") it works for
> me!
>
> but i find this code in django-tagging (http://code.google.com/p/
> django-tagging/): models.py: from tagging.validators import isTag
> name = models.CharField(validator_list=[isTag])
Hmmm, AFAICT the docs have no info about the behavior of validator_list
when used on a model field rather than a form field.
After a quick look at the source, it seems the validator_list is
"inherited" by form fields when an oldform is derived from the model.
So if you are using oldforms, what you are doing should work (with the
caveat about missing data). If you are not using oldforms, it probably
won't.
Nis
--~--~-~--~~~---~--~~
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: how to validate not blank field?
[EMAIL PROTECTED] skrev: > i used this: def isBlank(field,all_data): if field_data is None: > raise ValidattionError(u'Cannot be Blank.') > > it not work for me. It seems you are being bitten by the behavior described thus in the documentation: """ After a form has been submitted, Django validates each field in turn. First, if the field is required, Django checks that it is present and non-empty. Then, if that test passes /and the form submission contained data/ for that field, all the validators for that field are called in turn. The emphasized portion in the last sentence is important: if a form field is not submitted (because it contains no data -- which is normal HTML behavior), the validators are not run against the field. ... If you would like your validator to run /always/, regardless of whether its attached field contains any data, set the always_test attribute on the validator function. For example: def my_custom_validator(field_data, all_data): # ... my_custom_validator.always_test = True """ -- Nis Jorgensen Handcrafting signatures since 1996 --~--~-~--~~~---~--~~ 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: another complex SQL / extra() question
James Tauber skrev: > As before, I have a Thing model with a many-to-many relationship to > Source. > > For a given Source, I want to find those Things that come only from > that Source. > > This SQL works fine in dbshell (on sqlite): > > SELECT t > FROM ( > SELECT thing.thing_id AS t, COUNT > (thing.thing_id) AS c > FROM ( > SELECT thing_id > FROM myapp_thing_sources > WHERE source_id = ... > ) AS thing, myapp_thing_sources > WHERE thing.thing_id = myapp_thing_sources.thing_id > GROUP BY thing.thing_id > ) > WHERE c = 1; > > (where ... is the id of the given Source) > > > But I can't seem to get it to work with extra(). Firstly I wasn't > sure how to do a fully explicit select so I wrapped it in a WHERE id > IN (...): > > .extra(where=[""" > id IN ( > SELECT t > FROM ( > SELECT thing.thing_id AS t, COUNT > (thing.thing_id) AS c > FROM ( > SELECT thing_id > FROM myapp_thing_sources > WHERE source_id = %s > ) AS thing, myapp_thing_sources > WHERE thing.thing_id = myapp_thing_sources.thing_id > GROUP BY thing.thing_id > ) > WHERE c = 1 > ) > """], params=[source.id] > ) > > but that doesn't work either (even though the raw SQL does, even with > the WHERE id IN (...). ) > > Any ideas? > Idea #1: Be more specific than "does not work" #2: Find out what SQL is generated, and how it differs from what you run from the dbshell Yours, Nis Jørgensen No House IT --~--~-~--~~~---~--~~ 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: isnull lookup's contradicting result
Michael Radziej skrev: > On Thu, Sep 06, Russell Keith-Magee wrote: > > >> On 9/6/07, Michael Radziej <[EMAIL PROTECTED]> wrote: >> >>> I'd *love* to have a sneak preview of your changes, any way? ;-) >>> >> Hey! Get to the back of the line! No queue-jumping! I was here first! :-) >> > > ... checking Malcolm's Amazone wishlist ... > If Malcolm is into Amazones, perhaps we should ask the Brasillian who just registered for the sprint :-) -- Nis Jorgensen Hand crafting signatures since 1996 --~--~-~--~~~---~--~~ 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: Signing with mouse
Kelsey Ruger skrev: > I am looking for a python based utility that will allow a user to sign > their name with a mouse and save the resulting image for inclusion in > a PDF. Has anyone heard of something like this? > A word of warning: Users may not be able to prodcue anythin that looks like their normal written signature. I just tried, and I couldn't. Nis --~--~-~--~~~---~--~~ 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: Q lookup with both OR and AND
[EMAIL PROTECTED] skrev: > I'm having trouble piecing together a query for this model: > > class Ticket(models.Model): > ... > assigned_user = models.ForeignKey(User) > name = models.CharField(maxlength=255) > private = models.BooleanField(default=False) > > I'm trying to get all the tickets where the tickets are not private OR > the ticket is private and assigned to the current user. > > I'm foggy on where I use the comma, pipe, and ampersand characters to > get the query structured properly. In pseudo-sql, I'd say "select * > where private = False or (private=True and username='snewman') > > I thought I was close with this, but it only returned tickets assigned > to me. (The parenthesis around the 2nd and 3rd Q's obviously didn't > help) > > Ticket.objects.filter(Q(private__exact=False) | > (Q(private__exact=True) & Q(assigned_user__username__exact='snewman'))) > I don't know why this does not work. Could it be that the db somehow contains NULL's rather than False? Could you try the output of your_queryset._get_sql_clause()? Anyway, since A OR (NOT A AND B) <=> (A OR NOT A) AND (A OR B) <=> TRUE AND (A OR B) <=> A OR B your query can be reduced to Q(private__exact=False) | Q(assigned_user__username__exact='snewman') Which is simpler, but probably does not work either. Nis Jorgensen No House IT. --~--~-~--~~~---~--~~ 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: Q lookup with both OR and AND
Michael Radziej skrev: > On Thu, Sep 06, [EMAIL PROTECTED] wrote: > > >> I thought I was close with this, but it only returned tickets assigned >> to me. (The parenthesis around the 2nd and 3rd Q's obviously didn't >> help) >> >> Ticket.objects.filter(Q(private__exact=False) | >> (Q(private__exact=True) & Q(assigned_user__username__exact='snewman'))) >> > > Well, that's a known bug. Django uses inner joins even when combining > queries. A refactoring of the ORM is on the way, in the mean time you could > only either write custom SQL or resort to multiple queries. > Since "user" is a required field, this bug should not affect this case AFAICS. Nis --~--~-~--~~~---~--~~ 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: Problem with Mysql database
Nader skrev: > I have used 'inspectdb' to produce the model, because I had a dump > mysql file. In Meta section of model I have defined the table name: > > class Meta: > db_table = 'Dataset' > > Besides If I check the application model with "python manage.py sqlall > dataset" I see the same name which has been defined in Meta class. > > BEGIN; > CREATE TABLE `Dataset` > you may have both a table "Dataset" and a table "dataset": http://dev.mysql.com/doc/refman/4.1/en/identifier-case-sensitivity.html Nis Jorgensen No House IT --~--~-~--~~~---~--~~ 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: Djangonauts in Sweden?
Nis Jørgensen skrev: > Emil Björklund skrev: > >> Hi folks, >> >> Two part post: >> >> 1. Just wanted to introduce myself: Emil, web designer/developer from >> Malmö in southern Sweden, studying Information Architecture at Malmö >> University where I also work as a tutor. >> Come mostly from a php background, not much of a programmer in any >> language but I get by on curiosity and googling. Discovered Django >> about a year ago, got really into it because of an extremely rainy >> summer in Sweden. So far, I love it! My "research" so far into >> django-land has left the conclusion that pretty much everything about >> it is well thought-out and developer/designer friendly. >> >> 2. Any Swedish djangonauts out there? And more specifically, anyone in >> Malmö? I would love to get in touch with people around here, maybe >> grab a beer or coffee and talk shop. I'm no authority, so don't get >> your hopes up about learning much from me (apart from maybe some >> basics & terminology), but I still believe that anyone can learn from >> anybody else, pretty much... Sharing is caring! >> > Well, I am in Copenhagen and willing to travel. It would have to be at > least two beers to make it worthwhile, though ;-) > > About me: Freelance developer and general IT-person. Currently working > with php/mysql and Django/postgres (which currently is my framework of > choice). I'm into web standards[1] > > I would love to help arrange some kind of meet up - perhaps do a quick > introduction for people who don't know Django (I could imagine bringing > some along). > I just saw the plan for a sprint on September 14th . I could host an event in Copenhagen (quite close to the Central Station), or come to Malmö. Would you be interested and able? I will (probably) be able to offer sleeping on an office floor, anything fancier you would need to arrange yourself. So far, I have identified one other cluster of Danish Django developers - unfortunately in the other end of the country: They can hereby consider themselves invited as well. http://www.iola.dk/ (in Danish). Nis Jørgensen No House IT [1] At this point of my original mail, I was planning to insert some longer rant about web standards and why I find them important. Unfortunately, I completely forgot about this plan at the time when my fingers decided to press "send". --~--~-~--~~~---~--~~ 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 checkout doesn't work..
Devi skrev: > Hi, > > I was trying to get the developement version of django and that > doesn't work by this.. > svn co http://code.djangoproject.com/svn/django/trunk/ > What happens when you run that command? "Does not work" is not very specific ... > I'm able to see the files in the browser. Any ideas of what can be > done? > Some ideas: - Your svn was compiled without support for http (you should get an error message indicating this) - The machine you run the command from is behind a firewall requiring proxy settings, not allowing the methods used by svn or similar. In this case, ask your system administrator for help. Nis Jørgensen No House IT --~--~-~--~~~---~--~~ 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: Multiple one-to-one relationships for a single class
Malcolm Tredinnick skrev: > On Tue, 2007-08-21 at 21:21 -0700, Catriona wrote: > >> What I have is an event which has about 12 fields. Optionally any >> combination of a single weather record, a single event detail record, >> a single survey record and one of four event subclass records may be >> stored against this event. Each of these optional records has between >> 5 and 12 fields each. I could put everything in one big table with >> lots of nullable fields but that is not my preferred option. >> > > You can fake it with a ForeignKey, since that only allows one entry on > the source model's end. The slight drawback is that each target instance > (say, an event detail record) is not prohibited from being linked from > two different event models by the database. Some checking in the save() > method could fake this for you, though. Shouldn't unique=True on the ForeignKey fix that problem? Nis --~--~-~--~~~---~--~~ 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: unique_together and composite columns indexing
Peter Melvyn skrev:
> Hi all,
>
> if I'm not mistaken, if I have a model with unique constraint
> 'unique_together', Django does not support composite index of related
> columns, i.e.
>
> class AModel (models.Model):
> col_a = models.CharField(maxlength=20, db_index=True)
> col_b = models.CharField(maxlength=20, db_index=True)
> class Meta:
> unique_together = (('col_a','col_b'),)
>
> generates SQL commands:
>
> CREATE TABLE `xxx_amodel` (
> `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
> `col_a` varchar(20) NOT NULL,
> `col_b` varchar(20) NOT NULL,
> UNIQUE (`col_a`, `col_b`)
> );
> CREATE INDEX `xxx_amodel_col_a` ON `wss_amodel` (`col_a`);
> CREATE INDEX `xxx_amodel_col_b` ON `wss_amodel` (`col_b`);
>
>
> Should not be there another meta command, e.g.
>
> indexed_together = (('col_a','col_b'),)
>
> producing index
>
> CREATE INDEX `xxx_amodel_col_a_col_b`
>ON `wss_amodel` (`col_a`,`col_b`);
Postgresql will implicitly generate this index when it encounters the
UNIQUE constraint. My guess is that other backends will do the same.
A more interesting case is when you want to create multifield indices
which aren't unique. Your syntax could be used for this.
Nis
--~--~-~--~~~---~--~~
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: [Urgent] Freelance Django Developers Wanted
Siliconbits skrev: > [This is a repost] > > We are currently looking for more Django developers to join us on a > freelance basis. > > Location is irrelevant as long as you have a fast and reliable > Internet access. > > You will be working from home, so you should be able to work > independently, but also be able to demonstrate effective people and > time management skills, so as to deliver work within our deadlines. > > Send us your daily/hourly rates, your availability as well as a few > words about work you've done before. > > Any questions? Just send me an email. Who are "we"? Nis Jørgensen --~--~-~--~~~---~--~~ 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 app for locations? (countries, provinces, cities, venues...)
Austin Govella skrev: > Is there an existing Django app for managing locations? > > Specificall, countries, states/provinces, cities, and specific > locations with addresses. > > > > (I was just adding such an app to my project, but thought I might be > duplicating someone better effort...) > Greenpeace did something like this for their "Cool The Planet" project, AKA "Custard Melt. Blog is here: http://weblog.greenpeace.org/melt/ Not sure what the status is. Nis --~--~-~--~~~---~--~~ 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: Dynamic OR queries
Steven Armstrong skrev:
> Chris Hoeppner wrote on 08/25/07 18:40:
>
>> Hi there!
>>
>> I was just wondering how to dynamically "or" together an indetermined
>> quantity of Q objects. They're constructed from a string like q=a+b+c,
>> which would get stiched together as "(Q(field=a) | Q(field=b) |
>> Q(field=c))". Any clue on how to do it with unknown parameters? It will
>> need to work with a+b, just like a+b+c+d+e+f+g+h... You get it :)
>>
>
> from django.db.models import Q
>
> fields = 'a+b+c+d+e'.split('+')
>
> query = Q(field=fields.pop(0))
> for field_value in fields:
> query = query | Q(field=field_value)
> mylist = MyModel.objects.filter(query)
>
Or, if you prefer a more functional style:
from django.db.models import Q
import operator
fields = 'a+b+c+d+e'.split('+')
query = reduce(operator.or_,(Q(field=field_value) for field_value in fields),
Q())
mylist = MyModel.objects.filter(query)
(only tested for syntax)
Nis
--~--~-~--~~~---~--~~
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 Filter on a list of objects?
Greg skrev:
> Nis,
> Thanks for the help. We'll I got my view to work for website visitors
> searching by any combintation of Size, Price, and Color. My code is
> not the most efficient and I wonder how the performance is going to be
> once I add more products and take it off of developmental version and
> into a production environment.
>
> If anybody has any suggestions on how to make the code more optimized
> would be appreciated. Here is my view:
>
What Tim said, and this:
It would make your code much more readable if you used meaningful
variable names.
Python makes the need for explicit looping a lot less frequent than most
other programming languages. Whenever you are looping through a
list/dictionary and comparing each value to some other value, chance is
that you should really be using "if a in b".
In general, dont use
my_dictionary = {}
my_dictionary[x] = x
Use
myset = set()
myset.add(x)
And finally:
Don't Repeat Yourself. Whenever you have two blocks of code that looks
almost the same, try to refactor your code. Example:
> NO_COLOR = "---"
> styles =
> Choice.objects.get(id=h.id).style_set.all()
> if request['color'] <> NO_COLOR:
> styles =
> styles.filter(color_cat=request['color'])
> for j in styles:
> num = 0
> for a in dict:
> if a == j:
> num = 1
> if num == 0:
> dict[j] = j
> else:
> for p in styles:
> num = 0
> for a in dict:
> if a == p:
> num = 1
> if num == 0:
> dict[p] =
> p#assert False, styles
>
First step: Rename variables so they match in the two branches:
NO_COLOR = "---"
styles =
Choice.objects.get(id=h.id).style_set.all()
if request['color'] <> NO_COLOR:
styles =
styles.filter(color_cat=request['color'])
for style in styles:
num = 0
for key in dict:
if key == style:
num = 1
if num == 0:
dict[style] =
style
else:
for style in styles:
num = 0
for key in dict:
if key == style:
num = 1
if num == 0:
dict[style] =
style
Second step: Move the common block out of the conditional
NO_COLOR = "---"
styles =
Choice.objects.get(id=h.id).style_set.all()
if request['color'] <> NO_COLOR:
styles =
styles.filter(color_cat=request['color'])
for style in styles:
num = 0
for key in dict:
if key == style:
num = 1
if num == 0:
dict[style] = style
Third step: Replace the logic "If the key is not in the dictionary, put it
there" with "put the key in the dictionary". Since the value associated with
the key is
Re: Using Filter on a list of objects?
Greg skrev: > Tim, > I added your code into my view. However, it seems to error out on me > when I get to the line 'if 'color' in request and request['color'] <> > NO_COLOR: '. The error says: > > KeyError at /rugs/searchresult/ > '0 not found in either POST or GET' > The error message indicates that you did something equivalent to request[0] Are you sure you didn't do this: if 'color' in request and request[color] <> NO_COLOR: or this: if 'color' in request and request[color <> NO_COLOR]: ? --~--~-~--~~~---~--~~ 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: DB queries with filter and exclude
[EMAIL PROTECTED] skrev: > Wow, thanks for the reply. I can't get this to work though--I get an > "iteration over non-sequence". Can you take a look? > author.book_set is a Manager. You need author.book_set.all() (or author.book_set.all in a template) to get a QuerySet which you can iterate over. Nis --~--~-~--~~~---~--~~ 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: age in years calculation
Lucky B skrev: > how about surrounding the statement with a try and work the leap year > to regular year case with the exception? That seems like overkill. There isn't really any leap-year handling necessary: import datetime.date as date def age (d1, d2=None): if not d2: d2 = date.today() years = d2.year - d1.year if (d2.month,d2.day) < (d1.month,d1.day): years -= 1 return years Nis --~--~-~--~~~---~--~~ 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: How to get selected value set in newforms
[EMAIL PROTECTED] skrev: > I think the problem is related to passing the resultsdict dictionary to the > DisplayForms. > Once, I did not pass in the dictionary then the initial value works. > Yes. Passing in values creates a bound form. Initial data are used only for unbound forms. I think the documentation is quite specific on that issue: """ The initial argument lets you specify the initial value to use when rendering this Field in an unbound Form. ... This is why initial values are only displayed for unbound forms. For bound forms, the HTML output will use the bound data. Also note that initial values are /not/ used as "fallback" data in validation if a particular field's value is not given. initial values are /only/ intended for initial form display: """ Nis --~--~-~--~~~---~--~~ 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: Admin & Models
Nathan Ostgard skrev:
> list_display can use functions as their value... so, you can have:
>
> class Employee(models.Model):
> sub_dept = ForeignKey(SubDept)
>
> def company(self):
> return sub_dept.dept.company
>
> def dept(self):
> return sub_dept.dept
>
> class Admin:
> list_display = ('first_name, 'last_name', 'company', 'dept',
> 'sub_dept')
>
My guess is that the poster wanted this info available on the page for
an individual employee, not the list. At least that is what I need (and
haven't found an easy way of doing).
Nis
--~--~-~--~~~---~--~~
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: How to get selected value set in newforms
[EMAIL PROTECTED] skrev:
> I am still having problems setting the select widget to the 3rd value in the
> drop down list.
> Looking further it seems that the html does not have the selected="selected"
> value in any of the items.
> The documentation states that if use a bound form you will see that in the
> html.
"initial" data are showed in an UNBOUND form. If the form is bound, it
shows the data you bound it to. This is clearly stated in the
documentation - I assume you mistyped here.
> How would you go about getting the selected value in the html for a
> choicefield. I tried the initial parameter in the choicefield and that does
> not change which value is selected. It always happens to be the first in the
> list.
>
> Any help would greatly appreciated.
For an unbound form, it works for me:
"""
$ cat forms.py
from django import newforms as forms
class SearchForm (forms.Form):
campaign = forms.ChoiceField(required=False,choices
=(('choice1','Choice1'),('choice2','Choice 2')), initial = 'choice2' )
sf = SearchForm()
print sf
$ python forms.py
Campaign:
Choice1
Choice 2
"""
Can you please
a) Confirm that the above works for you
b) Post a self-contained example which shows your problem
Nis
--~--~-~--~~~---~--~~
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: Model Examples page, gone?
Nimrod A. Abing skrev: > Hello, > > I was just going through the current docs and wanted to look up some > examples and I noticed that the Model Examples page is gone: > > http://www.djangoproject.com/documentation/models/ > > though it can still be accessed in the older versions of the docs. > > http://www.djangoproject.com/documentation/0.95/models/ > Apparently that bit of documentation is broken - someone filed a ticket: http://code.djangoproject.com/ticket/5051 Nis --~--~-~--~~~---~--~~ 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: Postgresql and transactions, revisited
Russell Keith-Magee scribit:
> On 7/31/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote:
>
>> I had the problem that any db error in any of my tests (including
>> setups) would cause all following tests to fail (because the transaction
>> was not rolled back). This was made even worse by the fact that I used
>> the db in tearDown, which did not work very well either (I have since
>> started using django.test.TestCase, so I don't use tearDown much).
>>
>
> I can see how this problem could arise. The test framework doesn't
> have any special handling for errors, so if one test pushes the
> database into an error state, subsequent tests may fail.
>
> Ideally, test cases should be completely independent. It would be much
> nicer to have a single test fail with a clean error than have one test
> fail due to an error, and then all subsequent tests failing as a
> consequence of the first failure.
>
>
>> I think the problem at the base of all this is that postgresql's
>> transaction/error handling semantics are different from that of the
>> other backends - while Django treats it as if it was the same. I would
>> like to take a stab at fixing this (at the appropriate level, which I am
>> not too sure I have identified). But before I do that, I would like to
>> hear if anyone has any reasons why this should not be done ...
>>
>
> I doubt this is a postgres-specific problem. The exact exception that
> is thrown will be postgres specific, but all backends will throw
> exceptions, and will require transaction rollback (or some other
> handling) to allow the test suite to continue.
>
As far as I can tell, mySQL does not invalidate the current transaction
when it encounters an error. Thus you can do
"""
mysql> create table foo (bar varchar(20) primary key) engine innodb;
Query OK, 0 rows affected (0.28 sec)
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into foo values ('foo');
Query OK, 1 row affected (0.19 sec)
mysql> insert into foo values ('foo');
ERROR 1062 (23000): Duplicate entry 'foo' for key 1
mysql> insert into foo values ('bar');
Query OK, 1 row affected (0.00 sec)
"""
While in postgres you get:
"""
spider=> create table foo (bar varchar(20) primary key) ;
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"foo_pkey" for table "foo"
CREATE TABLE
spider=> begin;
BEGIN
spider=> insert into foo values ('foo');
INSERT 0 1
spider=> insert into foo values ('foo');
ERROR: duplicate key violates unique constraint "foo_pkey"
spider=> insert into foo values ('bar');
ERROR: current transaction is aborted, commands ignored until end of
transaction block
"""
For the record, I think mySQL is the one making sense here. sqlite
behave the same way. I don't have an Oracle installation to test on (nor
do I ever wish to get one).
> This does raise the larger issue of generic error handling for the
> database backends; It has been suggested that the various backend
> exceptions should be wrapped by a generic Django database failure
> exception. If database exceptions were normalized in this way,
> catching the type of errors you describe would become much cleaner -
> both in tests, and in the general case.
>
This sounds very much along the lines that I have been looking at for
solving the issue.
Out of interest, which versions of postgres are we supporting? I am
asking because I think the mySQL behavior can only be mimicked using
savepoints, which became available in 8.0.
I see that there are in fact no mention of version numbers of any of the
db products on the installation page. IMO, this should be fixed as well.
I guess I should log an issue ...
>> I will post some test cases with suggested behavior later (in a ticket).
>> If someone could give me a clue to how I can easily run the django test
>> suite, I would be glad.
>>
>
> Most certainly log this issue; test cases are most welcome; fixes even
> more welcome.
>
> I suspect the best approach will be to extend the django TestCase,
> overriding one of the test run methods to provide transaction
> checking. It may be helpful to define this behaviour as a decorator;
> this would also allow users with tests based on unittest.TestCase,
> rather than django.test.TestCase.
>
Thanks for the comments. I will log two issues:
1. Different backends have differen transaction semantics (and one of
them makes error handling distinctly hard to use, ie pg).
2. Testcases give problems because of this.
I am separating them since the second one is relatively easier to fix..
Nis
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Postgresql and transactions, revisited
I want to use the test framework with my application, using postgresql/psycopg2. I had the problem that any db error in any of my tests (including setups) would cause all following tests to fail (because the transaction was not rolled back). This was made even worse by the fact that I used the db in tearDown, which did not work very well either (I have since started using django.test.TestCase, so I don't use tearDown much). I also ran into this problem outside of tests, but do not remember details. Probably I was trying to use try ... except to catch a database error. My original solution was to edit base.py to enable autocommit (thus, as far as I can tell, disabling Django's transaction handling). This worked well for a while ... until I started using fixtures. Forward references don't work unless loaded within a transaction. I think the problem at the base of all this is that postgresql's transaction/error handling semantics are different from that of the other backends - while Django treats it as if it was the same. I would like to take a stab at fixing this (at the appropriate level, which I am not too sure I have identified). But before I do that, I would like to hear if anyone has any reasons why this should not be done ... I will post some test cases with suggested behavior later (in a ticket). If someone could give me a clue to how I can easily run the django test suite, I would be glad. Nis --~--~-~--~~~---~--~~ 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: Displaying the contents of a Dict (Using POST)...showing 'x' and 'y' keys?
Greg skrev: > I post some info to a view. When I do a 'assert False, request.POST' > I see the following > > [u'2'], u'5': [u'2'], u'4': [u'3'], u'7': [u'---'], u'6': [u'2'], > u'y': [u'4'], u'8': [u'---']}> > > It should only have 8 keys (1 through 8). Instead I see the keys 'x' > and 'y'? It's causing a problem when I try to loop through my POST > data. > > Does anybody know why this is happening? > I believe your form uses '' for the submit button. This will cause the x- and y-coordinates for the pixel clicked to be sent along with the rest of the form data. See http://www.w3.org/TR/html4/interact/forms.html#h-17.4.1 for more info. Nis --~--~-~--~~~---~--~~ 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: Best way to pass data to a HttpResponseRedirect?
Michael Lake skrev:
> Hi all
>
> Nis Jørgensen wrote:
>
>> The argument to HttpResponseRedirect is a url. You seem to be confusing
>> it with a template.
>>
>
> OK I can do this:
>
> code
> # some error occurs
> message = 'You have ... tell admin that '
> return HttpResponseRedirect('error/')
>
> and have in views.py
>
> def error(request, message):
> {
>return render_to_response('error_page.html', {'message':message})
> }
>
> But how to get the message into error() without passing it as a GET?
>
As others have said, you can stuff things into request.session (after
adding the right middleware incantations).
>> But if you have the data available, there is no reason to do a redirect.
>> Just render the error message etc to the relevant template, then return
>> that to the user.
>>
>
> Why I dont want to pass it like this ?message='You have ... tell admin that
> '
> is that its long and if the error is something like main?delete=100 but the
> user cant
> delete that id then a Redirect goes to a nice clean valid URL.
> A render_to_response leaves the incorrect URL in the browser.
What is so bad about leaving the url in the browser? I assume the error
message you display is the "correct" response for that url. Just
remember to add the correct status code - probably 400,403 or 404. Note
that if this is a GET url, it shouldn't have side effects, so your
"main?delete=100" example seems like a bad idea to begin with (unless
this is the page that shows an "Are you sure ...?" message). If it is a
POST, there is a lot of reason not to redirect it, since this will make
it harder for the user to use the back button to fix things.
Nis Jorgensen
--~--~-~--~~~---~--~~
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: Best way to pass data to a HttpResponseRedirect?
Michael Lake skrev:
> Hi all
>
> A really simple question:
>
> I'm mostly using code like this:
> data = {'message': 'Some message to user...'}
> return render_to_response('main.html', data)
>
> But for error messages to users if one wishes to use a redirect like this:
> return HttpResponseRedirect('/error_page.html')
>
> How can one add data into this page? The Redirect is nice in that it does not
> show
> the old URL which might be quite wrong - hence the error.
>
> The Django docs say that HttpResponseRedirect('/whatever/url/') takes just
> one
> argument. I'd like to use one error_page.html template for a range of errors.
>
> Do people use maybe HttpResponseRedirect('error/') where error is some
> defined
> function and somehow pass a message string to it?
The argument to HttpResponseRedirect is a url. You seem to be confusing
it with a template. If you want to display different content, you need
to pass a different url or (not recommended) store the data you want to
display, then display it to the user at the new url
But if you have the data available, there is no reason to do a redirect.
Just render the error message etc to the relevant template, then return
that to the user.
Nis Jorgensen
--~--~-~--~~~---~--~~
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: Problem when deleting a register from the database
AnaReis skrev:
> Hi all!
> I have a delete that isn't working properly. It deletes more than 1
> register when it shouldn't because I'm specifying the primary key in
> the filter.
> The class file is this:
> class UserInstrument(models.Model):
> user_name = models.CharField(primary_key=True, maxlength=60)
> instrument_name = models.CharField(blank=False, maxlength=60)
> permission = models.TextField(blank=True)
> def __str__(self):
> string="user_name: "+self.user_name+"; instr_name:
> "+self.instrument_name+"; permission: "+self.permission
> return string
> class Meta:
> db_table = 'User_instrument'
> unique_together = (("user_name", "instrument_name"),)
> In the view function I'm doing this:
> UserInstrument.objects.filter(user_name__exact=username,
> instrument_name__exact=itemid).delete()
>
> Oh and another detail, in the MySQL table, the primary key is the
> user_name and the instrument_name together.
>
I am not sure whether this is the cause of your problem, but
- Django doesn't support multi-field primary keys
- Your model class tells Django that "user_name" alone is the primary
key, which is wrong (and will lead to strange primary key lookups).
- Django implements its own cascading delete, independent of the
database. In this I believe it loops throught the queryset, and deletes
the objects based on the primary key. Since you "lied" to it about what
the PK is, it deletes the wrong objects.
Quick solution: Remove the primary_key=True from the model - this will
add the standard "id" autonumber field.
Slow solution: Add support for multi-field primary keys to the database.
Nis
--~--~-~--~~~---~--~~
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: Forms for complex model hierarchies
Jonathan Buchanan skrev: > On 7/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Hi group, >> >> I have a rather complex hierarchy of models. Say, I have a model A. A >> has a 1:N relation to model B, which itself has a 1:N relation to >> model C. >> >> What I want is a single web page, on which an instance of A and all >> its related B and C instances can be edited. >> >> What is the best way to achieve this? I am not sure wether it is worth >> the effort of coding something generic like a deepform function. >> >> What are your experiences? >> >> Regards, >> -Justin >> > > It's scarily easy to do this using the "prefix" argument when creating > forms. You might have something like the following: > That IS scary ... and should go on djangosnippets, IMO. Nis --~--~-~--~~~---~--~~ 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 - technology or magic?
to_see skrev: > "Any sufficiently advanced technology is indistinguishable from > magic." > Arthur C. Clarke, "Profiles of The Future", 1961 (Clarke's third > law) > > Snippet #26 solved my problem, essentially in two lines. I could not > write those lines for myself now, and I'm not certain I'll ever be > able to do so. > > Am I having a fairly normal introduction to a web framework? I cannot > see this as technology. All I see is magic. > FYI: I first looked at the Django source a year and a half ago. The first time I saw (*args, **kwargs) I ran away screaming, deciding that I would just try to use the magic, rather than understand it or control it. Since then I learned some more python, and recognized this as a standard python idiom. Yesterday I ran into almost exactly the same problem as you - how to populate my dropdown at the time of the request, rather than when the module was loaded. I then went on to write exactly the same code as the snippet, except for the identifiers and the "blank value" (with a bit of trial and error). So learn some python and you will be able to see how the magic works. Or just lean back and enjoy the show ... Nis --~--~-~--~~~---~--~~ 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: Related Field has invalid lookup: icontains
l5x skrev: > Hello, > > I have code for searching: > > news = News.objects.filter( > Q(title__icontains=phrase) > | Q(tags__icontains=phrase) > | Q(short__icontains=phrase) > | Q(content__icontains=phrase) > | Q(author__icontains=phrase) > | Q(source__icontains=phrase) > ) > News model looks like that: > > class News(models.Model): > title = models.CharField(maxlength="100") > tags = models.CharField(maxlength="75") > short = models.TextField() > content = models.TextField() > author = models.ForeignKey(User, editable=False) > source = models.CharField(maxlength="100") > date = models.DateTimeField(auto_now_add=True) > status = models.IntegerField(editable=False, default="0") > def __str__(self): > return '%s' % (self.title) > class Admin(): > pass > You need to specify which fields in the User/Author table to match on (the default is the primary key , which doesn't make sense here). Something like |Q(author__username__icontains=phrase) Nis --~--~-~--~~~---~--~~ 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: reverse pagination
Amit Upadhyay skrev:
> Hi,
>
> You are all aware of object pagination, search results, your photo on
> flickr, stories on reddit, all have a next page/previous page paradigm.
> Django makes it trivially easy to create such pages by providing object_list
> generic view. There are some problems with the current implementation of
> pagination that we see around, page no 0/1 is assigned to the latest objects
> in the list. While in search result this makes little difference, in other
> cases it has a few consequences.
>
Is there anything in your proposal that isn't solved by using something like
MyModel.objects.order_by('some_field')
for the queryset passed to the paginator?
Nis
--~--~-~--~~~---~--~~
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: 4 beginner's questions
Stefan Matthias Aust skrev: > > Let's assume you have users who are allowed to assign nick names to > theirselves and still all thoses nick names must be different. This is > want I call a random ID. > If a user assigns it, it is not random, by any definition of random I can think of. I do see the use case for random unique values - for instance to give each object a url without making it possible for a visitor to retrieve all the objects. Very weak security of course, but some kind of security still. Nis --~--~-~--~~~---~--~~ 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: How to loop through a Dict to add values?
Greg skrev: > Derek, > Ok...I made the change and I'm now getting the error: > > TypeError at /rugs/cart/1/4/ > unsupported operand type(s) for +: 'int' and 'Price' > > Is 'a['choice'].price' not an Int? It says it is in my model file. > No it doesn't - "price" is defined as a ForeignKey to Price, so it holds a Price object. > class Price(models.Model): > name = models.IntegerField() > > def __str__(self,): > return str(self.name) > > class Admin: > pass > > > class Choice(models.Model): > choice = models.ForeignKey(Collection, edit_inline=models.TABULAR, > num_in_admin=5) > size = models.ForeignKey(Size, core=True) > price = models.ForeignKey(Price, core=True) > def __str__(self,): > return str((self.size, self.price)) > The only integer defined is Price.name. Does this work: pr = pr + a['choice'].price.name ? I would suggest that you change the name of that field ... "name" does not really convey that this is the value of the price - it sounds more like a label for it (like "SuperSaver"). Perhaps you could get rid of the Price class altogether? If it just holds an integer, you could use an IntegerField directly in Choice ... Nis --~--~-~--~~~---~--~~ 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 fastcgi and pidfile
I cannot seem to get manage.py runfcgi pidfile=myfile.pid to work unless I have daemonize=false as well. I haven't started investigating what actually happens - thought I'd hear if I am doing something stupid first. Django is [EMAIL PROTECTED], Debian Etch, python 2.4.4, flup 0.2126-1 Sample output below. Any idea why this doesn't work. Nis # This is how I've been doing it until now: $ ./manage.py runfcgi host=127.0.0.1 port=8001 $ netstat -l |grep 8001 tcp0 0 nohouse.cust.gigah:8001 *:* LISTEN # This doesn't work for some reason $ ./manage.py runfcgi host=127.0.0.1 port=8001 pidfile=fcgi.pid $ netstat -l |grep 8001 $ ll fcgi.pid ls: fcgi.pid: No such file or directory # This does work. $ ./manage.py runfcgi host=127.0.0.1 port=8001 pidfile=fcgi.pid daemonize=false & [1] 9309 $ netstat -l |grep 8001 tcp0 0 nohouse.cust.gigah:8001 *:* LISTEN $ ll fcgi.pid -rw-r--r-- 1 nohouse nohouse 5 2007-07-20 07:49 fcgi.pid --~--~-~--~~~---~--~~ 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: Problem when inserting into a table with a MySQL auto_increment primary key
AnaReis skrev: > Hi all, > I have a problem when inserting a register into this table that I'm > working with. > This table belongs to a MySQL database and the storage engine is > MyISAM. The database that I'm using is a legacy database and I can't > change it in any way. > When I insert a register into the table it's MySQL who generates the > primary key for me. Which means that I fill all the required table > fields and leave the primary key field empty for MySQL to fill when I > insert the record. The problem is, since the ".save()" method doesn't > return any value there is no way for me to give any confirmation for > the user if the register was inserted or not. Have you added the primary key to the model, like this: my_legacy_id = AutoField() If you do, I believe you will be able to read the value of the field after calling .save(). At least you can with the standard id field when using postgresql. Nis --~--~-~--~~~---~--~~ 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: sessions - cookies in opera
Daniel Kontsek skrev: > Hello > > I have a web application with 2 views. The first view checks if the > session dictionary has a 'uid' key - if not it generates an random ID > and puts it into request.session dict. The second view reads the uid > from the session dict and creates a Project DB object with that uid. > This works fine in all browsers (FF, Safari, IE), except Opera. Looks > like Opera (Mac, 9.21.3678) doesn't accept the cookie with the session > info. although cookies are on. Any idea why? > Several possibilities come to mind: - The cookies may be somehow violating the standard. Other browsers may be more accepting of invalid data. - When receiving a cookie received as part of a redirect, it may not be immediately sent with the new request. It is not clear whether this is allowed by the standard - which talks about cookies which the client has "stored". Opera might not have stored the cookie at that point in time. . Opera may be configured to not accept cookies, or be very strict in what it accepts. - Opera may be caching the page that is supposed to set the cookie. This would probably not be happening consistently, though. I think it would be a good idea to look at what actually goes on in the HTTP communication - perhaps logging the two HttpRequests and corresponding HttpResponses /Nis --~--~-~--~~~---~--~~ 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: Unique=true
Nis Jørgensen skrev: > [EMAIL PROTECTED] skrev: > >> OK, fixed the above problem -- figured out that it was related to my >> setting unique=True on a field. But that raises the larger question... >> >> I have a bit of data that may or may not exist... a identifier on the >> user that not all users will have, but if they DO have it, it needs to >> be unique to that user. Apparently, unique=True isn't what I want, >> because the second user without it throws the above duplicate entry >> error, so how do I handle that? >> >> > I believe the behavior depends on your database backend. Postgresql does > what you want. > > Postgresql is, AFAICT, complying with at least one of the SQL standards > (but I don't have a copy of those) > It seems mysql 5 works the same way as postgres - and it seems the error message you quoted was from postgres. It seems to me you do not have null=True set for the Field. Thus blank values are stored as empty strings, which unlike NULLS are equal to each other. /Nis --~--~-~--~~~---~--~~ 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: Unique=true
[EMAIL PROTECTED] skrev: > OK, fixed the above problem -- figured out that it was related to my > setting unique=True on a field. But that raises the larger question... > > I have a bit of data that may or may not exist... a identifier on the > user that not all users will have, but if they DO have it, it needs to > be unique to that user. Apparently, unique=True isn't what I want, > because the second user without it throws the above duplicate entry > error, so how do I handle that? > I believe the behavior depends on your database backend. Postgresql does what you want. Postgresql is, AFAICT, complying with at least one of the SQL standards (but I don't have a copy of those) Nis --~--~-~--~~~---~--~~ 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: model managers of base classes
omat skrev: > Thanks for the pointer, Nis. > > Model inheritance made my models so much DRYer that it will be hard to > give up, at least psychologically... > > And, except for the managers, it worked just as I would expect, and > for the managers, it was easy to patch. > Just to make sure I understand, your expected behavior is - Each model gets a db table which include fields from its ancestors - Managers and (other) methods are inherited as if they were defined on the subclass - There is no common interface for subclasses of a model class. Correct? I would perhaps call this "class templating" rather than "subclassing", but I can definitely see its usefulness. Note that you get the probably undesired sideeffect of defining the Ortho class as a model - which may cause some confusion if people use syncdb and friends, and probably in other cases as well. Yours Nis Jorgensen --~--~-~--~~~---~--~~ 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: Greenpeace Source Code
FrostedDark skrev: > Does anyone have the Greenpeace source code... their svn server has > been down for over a week now and I would love to take a look at it. > It has moved here: https://svn4.cvsdude.com/greenpeace/custard Yours Nis Jørgensen Currently doing other Django work for Greenpeace --~--~-~--~~~---~--~~ 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: model managers of base classes
omat skrev:
> Hi all,
>
> I have a base class common for all my orthogonal models, that is,
> models that hold content for other models, such as tags. This base
> class also has a manager. Here are the classes:
>
>
> class OrthoManager(models.Manager):
> def get_for_object(self, object):
> ctype = ContentType.objects.get_for_model(object)
> return self.filter(content_type__pk=ctype.id,
>object_id=object.id)
>
> def get_for_model(self, model):
> ctype = ContentType.objects.get_for_model(model)
> return self.filter(content_type__pk=ctype.id)
>
>
> class Ortho(models.Model):
> content_type = models.ForeignKey(ContentType,
> editable=False,
> blank=True,
> null=True)
> object_id = models.PositiveIntegerField(blank=True,
> editable=False,
> null=True)
> object = generic.GenericForeignKey('content_type', 'object_id')
>
> objects = OrthoManager()
>
>
> When I define my orthogonal model like that:
>
> class Tag(Ortho):
> tag = models.CharField(maxlength=50)
>
> and try to access its manager, I get a:
>
> Programming Error: relation "models_ortho" does not exist
>
> i.e. it looks for the "models_ortho" table.
>
> If I add:
>
> objects = OrthoManager()
>
> to the Tag model class (the inherited class), it works fine.
>
> It seems that I cannot inherit the manager of the base class. Is this
> by design? Or am I doing something wrong?
>
This is by "current" design - subclassing of models is not supposed to
work yet. Here is a writeup of how it will likely work:
http://code.djangoproject.com/wiki/ModelInheritance
Since this is currently not supposed to work, I would think behavior is
undefined. Thus i would suggest that you do not subclass models, even if
you can get it to work.
Nis Jørgensen
(Eagerly awaiting model inheritance as well)
--~--~-~--~~~---~--~~
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: Cross Importing Model Problem
Bryan Veloso skrev:
(I am only commenting on the model (database and Django) in this post -
I don't really know enough about imports to help you with that bit)
> I have 2 models for an MMORPG control panel I'm building. Each set of
> data is within it's own app with related models, etc. So here's my
> example. It's run off an existing database so I really can't change
> any of the database fields.
>
It seems some of the tables are not normalized (see below). Are they set
in stone?
> I have a Character model that imports the Guild model.
>
> class Character(models.Model):
> char_id = models.IntegerField('Character ID',
> primary_key=True)
> account = models.ForeignKey(Account, unique=True,
> db_column='account_id')
> char_num= models.IntegerField('Character Slot')
> name= models.CharField('Name', maxlength=90)
> guild = models.ForeignKey('Guild',
> db_column='guild_id')
As far as I can see, this
account = models.ForeignKey(Account, unique=True,
db_column='account_id')
is equivalent to
account = models.OneToOneField(Account, db_column='account_id' )
but with a simpler interface ("account.character" rather than
"account.character_set.all()[0]".
You might want to consider this change - although it might be a bad idea
if you envision multiple characters per account int he future.
> But the app that contains Guild has another model that is linked to
> the Character model.
>
> class GuildMember(models.Model):
> guild = models.ForeignKey(Guild,
> db_column='guild_id', unique=True, primary_key=True)
> account = models.ForeignKey(Account,
> db_column='account_id', unique=True)
> character = models.ForeignKey(Character,
> db_column='char_id', unique=True)
>
The use of "unique=True" here looks wrong. As written, a Guild has at
most one Character, and a Character has at most one Guild. Is this
really what you want? If so you might again consider using two
OneToOneFields. But I suspect you really mean 'unique_together
(('guild'),('character')).
Anyway, the database design looks quite bad ... the "account" field in
GuildMember seems redundant (assuming it points to the account of the
character). It is not clear whether Character.guild corresponds to
Character.guildmember_set()[0].guild - if they are always the same, the
table structure is not normalized.
I guess the root cause of your problems is that you cannot easily model
a ManyToMany relationship between models in different apps. As Malcolm
suggests, the solution is probably to not have two apps.
Nis
--~--~-~--~~~---~--~~
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: Sybase support for Django
Russell Keith-Magee skrev: > Ok. In which case, a Sybase backend will probably hit the same > problems as the existing MS SQL backend. MS SQL doesn't contain > support for LIMIT/OFFSET in queries, which Django uses these keywords > to optimize the results obtained from large queries. (I think this > problem has been fixed in SQL Server 2005, but don't quote me on that. > I don't keep close tabs on MS SQL). > Perhaps we (that is, the people who want MS-SQL support) could use the technique described here: http://josephlindsay.com/archives/2005/05/27/paging-results-in-ms-sql-server/ I do believe there might be a subtle problem in the case where the sort key is not unique - in that case, TOP X can return more than X records, IIRC. We might have to add the primary key to the SORT BY as a last resort when sorting by a non-unique field. Nis --~--~-~--~~~---~--~~ 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: generating customized flyers (pngs or pdf)
KpoH skrev: > Hello, > use PIL (http://www.pythonware.com/products/pil/) for this > Note the nice logo in the left sidebar :-) Nis --~--~-~--~~~---~--~~ 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: reduce execution time of object.count()
Nis Jørgensen skrev:
>
> What is missing above is creating INSERT/UPDATE/DELETE rules for the
> "entity" view. I hacked together the ones below - they seem to work,
> but there might be subtle points of how this works that I have not
> understood.
>
[...]
> CREATE RULE entity_insert as ON INSERT TO entity DO INSTEAD (
> INSERT INTO entity_base (f1,f2,f3,f4,f5,f6,f7) VALUES (NEW.f1,
> NEW.f2, NEW.f3, NEW.f4, NEW.f5, NEW.f6, NEW.f7);
> INSERT INTO entity_idx VALUES (currval('entity_base_id_seq'::regclass))
> );
>
The naive approach for inserting the new id's didn't work - it tries to
insert the same value into all rows. If I use NEW.id instead, new
sequence values are generated for the entity_idx table.
It seems like this is (or at least was) a known limitation:
http://archives.postgresql.org/pgsql-bugs/2004-07/msg00209.php
Nis
--~--~-~--~~~---~--~~
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: reduce execution time of object.count()
Nis Jorgensen skrev:
> Paul Rauch wrote:
>
>> Is there a way to reduce execution time by counting objects?
>>
>> it's even splitted in two queries now, with only 2474487 entries ;)
>>
>> in django I use "model.objects.count()"
>>
>> SELECT COUNT(*) FROM "rainbowtables_hashes":34.552
>>
>> SELECT COUNT(*) FROM "rainbowtables_hashes":31.024
>>
>>
>
> I guess you are using postgresql. This is a known "issue" with that
> database - count(*) on an entire table (or large subsets) is slow (and
> takes time proportional to the rows found).
>
>
[snip]
> Hmm, i just realized a generic way of making this work in postgresql (if
> you are happy to do your own ddl). Basically use an updatable view,
> which maintains the additional table behind the scenes. Will write that
> up in more detail later.
>
If anyone is interested,. I did a little testing on this. It does seem
to work in some cases, but not using the query plan I thought it would.
My setup:
CREATE TABLE entity_base (id SERIAL PRIMARY KEY, f1 varchar(255), f2
varchar(255), f3 varchar(255), f4 varchar(255), f5 varchar(255), f6
varchar(255), f7 varchar(255));
CREATE TABLE entity_idx (id integer PRIMARY KEY REFERENCES entity_base
(id) ON DELETE CASCADE);
CREATE VIEW entity AS (SELECT * FROM entity_base NATURAL JOIN entity_idx );
-- Create one row of data
INSERT INTO entity_base (f1,f2,f3,f4,f5,f6,f7) VALUES ('Long random
string','must be random to avoid compression', ...);
-- Each line below doubles the amount of rows
INSERT INTO entity_base (f1,f2,f3,f4,f5,f6,f7) SELECT
f1,f2,f3,f4,f5,f6,f7 FROM entity_base;
INSERT INTO entity_base (f1,f2,f3,f4,f5,f6,f7) SELECT
f1,f2,f3,f4,f5,f6,f7 FROM entity_base;
-- ...
-- 21 times
-- ...
INSERT INTO entity_base (f1,f2,f3,f4,f5,f6,f7) SELECT
f1,f2,f3,f4,f5,f6,f7 FROM entity_base;
-- populate the "index table"
INSERT INTO entity_idx SELECT id FROM entity_base;
> EXPLAIN ANALYZE SELECT count(*) FROM entity_base;
QUERY
PLAN
---
Aggregate (cost=183116.80..183116.81 rows=1 width=0) (actual
time=16005.803..16005.803 rows=1 loops=1)
-> Seq Scan on entity_base (cost=0.00..182461.44 rows=262144
width=0) (actual time=58.861..15893.200 rows=262144 loops=1)
Total runtime: 16005.852 ms
>EXPLAIN ANALYZE SELECT count(*) FROM entity;
QUERY PLAN
Aggregate (cost=193688.18..193688.19 rows=1 width=0) (actual
time=2289.985..2289.986 rows=1 loops=1)
-> Merge Join (cost=0.00..193032.82 rows=262144 width=0) (actual
time=0.148..2178.405 rows=262144 loops=1)
Merge Cond: ("outer".id = "inner".id)
-> Index Scan using entity_base_pkey on entity_base
(cost=0.00..184324.58 rows=262144 width=4) (actual time=0.074..1253.894
rows=262144 loops=1)
-> Index Scan using entity_idx_pkey on entity_idx
(cost=0.00..4839.58 rows=262144 width=4) (actual time=0.067..291.596
rows=262144 loops=1)
Total runtime: 2290.056 ms
My hope was that the query could be satisfied by doing a seqscan on
entity_idx. This optimization is probably beyond the ability of
postgresql though. Apparently, however, the count can be satisfied
just by looking at the 2 indexes - which seems strange to me. I would
think at least one of the tables would need to be seqscanned, to ensure
that the rows have not been deleted.
What is missing above is creating INSERT/UPDATE/DELETE rules for the
"entity" view. I hacked together the ones below - they seem to work,
but there might be subtle points of how this works that I have not
understood.
CREATE RULE entity_delete as ON DELETE TO entity DO INSTEAD DELETE FROM
entity_base where id = old.id;
CREATE RULE entity_update as ON UPDATE TO entity DO INSTEAD UPDATE
entity_base SET f1=NEW.f1, f2=NEW.f2, f3=NEW.f3, f4=NEW.f4, f5=NEW.f5,
f6=NEW.f6, f7=NEW.f7 where id = NEW.id;
CREATE RULE entity_insert as ON INSERT TO entity DO INSTEAD (
INSERT INTO entity_base (f1,f2,f3,f4,f5,f6,f7) VALUES (NEW.f1,
NEW.f2, NEW.f3, NEW.f4, NEW.f5, NEW.f6, NEW.f7);
INSERT INTO entity_idx VALUES (currval('entity_base_id_seq'::regclass))
);
/Nis
--~--~-~--~~~---~--~~
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: applying patch
cesco skrev: > Hi, > > I'm trying to apply the patch given in > http://code.djangoproject.com/ticket/3297 > using tortoiseSVN on windows but I get the following error message: > > The line "Index: " was not found > Either this is not a diff file or the diff is empty. > > The file I downloaded and used as patch is: > http://code.djangoproject.com/attachment/ticket/3297/filefield.diff > I believe you should use http://code.djangoproject.com/attachment/ticket/3297/filefield.diff?format=raw which is the plain-text version of the patch. /Nis --~--~-~--~~~---~--~~ 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: Problem with postgres transactions
Joshua D. Drake skrev: > Nis Jørgensen wrote: >> [...] anytime a >> database error occurs, all subsequent calls to the database fails with >> the error message "ProgrammingError: current transaction is aborted, >> commands ignored until end of transaction block". >> > > That is how PostgreSQL works. Your only option at that point is to > rollback and start again. Unless you change your isolation level. > I (kind of) know that. But I would expect Django to take care of rolling back the transaction in case of failure. >> This causes unittesting to break, since the tearDown will try to use the >> existing database connection, as well as giving me strange error >> messages at other times. You vcan see an example of the latter at the >> bottom of my mail. >> >> I have found that I can eliminate the problem by substituting this line >> self.connection.set_isolation_level(1) # make transactions >> transparent to all cursors >> > > This will work fine. > From a quick glance at the source+documentation, it seems like this (replacing with 0 in the line above) would basically revert everything to autocommit - and thus remove the ability to use for instance commit_on_success. But since I don't have any need for transaction management at the moment, I will leave it as is. /Nis --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Problem with postgres transactions
Hello all I am using Django 0.96 with postgresql 8.1 and psycopg2. The error handling does not work as I would expect it to. Specifically, anytime a database error occurs, all subsequent calls to the database fails with the error message "ProgrammingError: current transaction is aborted, commands ignored until end of transaction block". This causes unittesting to break, since the tearDown will try to use the existing database connection, as well as giving me strange error messages at other times. You vcan see an example of the latter at the bottom of my mail. I have found that I can eliminate the problem by substituting this line self.connection.set_isolation_level(1) # make transactions transparent to all cursors with this one self.connection.set_isolation_level(0) in django/db/backends/postgresql_psycopg2/base.py However, I am worried that whoever wrote that code did so for a reason ;-) Can anyone tell me: - If this is intended behavior or a bug. - If my change is likely to break anything, and if so, if there is another recommended solution Yours, u'Nis J\xf8rgensen' Appendix: As an example of the problem, see the following interactive session ./manage.py shell Python 2.4.4 (#2, Apr 5 2007, 20:11:18) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from spider.models import Language >>> Language.objects.create(isocode='xx') >>> Language.objects.create(isocode='xx') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/site-packages/django/db/models/manager.py", line 79, in create return self.get_query_set().create(**kwargs) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 262, in create obj.save() File "/usr/lib/python2.4/site-packages/django/db/models/base.py", line 238, in save ','.join(placeholders)), db_values) File "/usr/lib/python2.4/site-packages/django/db/backends/util.py", line 12, in execute return self.cursor.execute(sql, params) IntegrityError: duplicate key violates unique constraint "spider_language_isocode_key" >>> Language.objects.create(isocode='yy') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/site-packages/django/db/models/manager.py", line 79, in create return self.get_query_set().create(**kwargs) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 262, in create obj.save() File "/usr/lib/python2.4/site-packages/django/db/models/base.py", line 238, in save ','.join(placeholders)), db_values) File "/usr/lib/python2.4/site-packages/django/db/backends/util.py", line 12, in execute return self.cursor.execute(sql, params) ProgrammingError: current transaction is aborted, commands ignored until end of transaction block --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
