Re: Django password_change

[Mark L.]

Thanx for the responses guys. This is what solved my problem.

#url.py
 (r'^accounts/password/change/$', 'password_change', {},
'password_change_form'),
 (r'^accounts/password/done/$', 'password_change_done', {},
password_change_done'),

...and added password_change_form.html and password_change_done.html
to my ...templates/registration folder. Now after login I can got to
accounts/password/change and change the users password. I still need
to added the redirections, but I think this the hard part.


On Jun 23, 5:40 pm, Yuri Piratello <yuri.pirate...@gmail.com> wrote:
> I use in that project
>
> https://github.com/yuripiratello/nilo
>
> (r'^alterarSenha/$', 'nilo.views.alterarSenha'),
>
> My template: /templates/alterarSenha.html
>
> Att;
>
> Yuri Zanola Piratello
> =
> blog:http://yuri-piratello.blogspot.com<http://yuripiratello.orgfree.com>
> msn: yuri_zp...@hotmail.com
> Skype: yuri_zpira
> Gmail: yuri.pirate...@gmail.com
> Twitter:http://twitter.com/yuri_zpira
> GNU/Linux user number: 530410
>
> On Thu, Jun 23, 2011 at 3:53 PM, Mark L. <marklockl...@gmail.com> wrote:
> > Hey guys, I'm a newb to Django, but have some experience with Rails.
> > Its fun to see the similarities and differences in both!
>
> > After looking through
> >https://docs.djangoproject.com/en/dev/topics/auth/#module-django.cont...
> > Under the section 'Other built-in views' I think password change is
> > what I want. I did find this on stackoverflow...
>
> >http://stackoverflow.com/questions/388800/django-how-do-i-use-the-bui...
>
> > ...this focuses on password_reset, but I'm thinking it would apply
> > also to password_change.
>
> > So in my urls.py I added these 2 lines...
>
> > (r'^/accounts/password/change/$',
> > 'django.contrib.auth.views.password_change',
> >            {'post_change_redirect' :
> > 'django.contrib.auth.views.password_reset_done'}),
>
> > ...and I also copied password_change_form.html and
> > password_change_done.html to /templates/registration/
> > So after logging in to my system I'm simply trying to go to the /
> > accounts/password/change/ url. Oh course I'm getting a 404. So I'm not
> > sure how close I am, but I would appreciate any ideas. Thanx!
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.

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

Django password_change

[Mark L.]

Hey guys, I'm a newb to Django, but have some experience with Rails.
Its fun to see the similarities and differences in both!

After looking through 
https://docs.djangoproject.com/en/dev/topics/auth/#module-django.contrib.auth.views
Under the section 'Other built-in views' I think password change is
what I want. I did find this on stackoverflow...

http://stackoverflow.com/questions/388800/django-how-do-i-use-the-built-in-password-reset-change-views-with-my-own-templat

...this focuses on password_reset, but I'm thinking it would apply
also to password_change.

So in my urls.py I added these 2 lines...

(r'^/accounts/password/change/$',
'django.contrib.auth.views.password_change',
{'post_change_redirect' :
'django.contrib.auth.views.password_reset_done'}),


...and I also copied password_change_form.html and
password_change_done.html to /templates/registration/
So after logging in to my system I'm simply trying to go to the /
accounts/password/change/ url. Oh course I'm getting a 404. So I'm not
sure how close I am, but I would appreciate any ideas. Thanx!

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

Strange behaviour with select_related and model inheritance

[Mark L.]

Hello,

Here is an extremely simple scenario:

class Base(models.Model):
f1 = models.CharField(max_length=64)

class A(Base):
f2 = models.CharField(max_length=64)

class B(models.Model):
f3 = models.CharField(max_length=64)
b = models.OneToOneField('A', null=False, related_name="b_obj")

If you then try and do "print A.objects.select_related('b_obj').query'
it produces
Traceback (most recent call last):
  File "", line 1, in 
  File "django\db\models\sql\query.py", line 147, in __str__
sql, params = self.get_compiler(DEFAULT_DB_ALIAS).as_sql()
  File "django\db\models\sql\compiler.py", line 59, in as_sql
self.pre_sql_setup()
  File "django\db\models\sql\compiler.py", line 33, in pre_sql_setup
self.fill_related_selections()
  File "django\db\models\sql\compiler.py", line 616, in
fill_related_selections
chain = opts.get_base_chain(f.rel.to)
  File "django\db\models\options.py", line 440, in get_base_chain
% model._meta.module_name)
TypeError: 'a' is not an ancestor of this model

Incidentally, if I try to actually evaluate the queryset it turns out,
that no queries are run at all. Is it supposed to be like that?
In plain SQL this would be an inner join from A to Base followed by a
left outer join with B. Is it possible to make it work at all?

If you don't derive A from Base, it works perfectly (creates a left
outer join from A to B).

I hope, this makes sense

Mark

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

Re: Initial values for formwizard form

[Mark L.]

On Nov 19, 1:28 am, geraldcor  wrote:
> Ok,
>
> Here is how I do it if I am using a regular form with a regular view:
>
> profile = request.user.get_profile()
> form = MyForm('company': profile.defaultcompany, 'contact':
> profile.defaultcontact, etc...})
> return render_to_response('forms/submit.html', {'form': form},
> context_instance=RequestContext(request))
>
> pretty simple and basic.
>
> How do I do this with a form wizard?
>
> Greg
>
> On Nov 17, 3:39 pm, geraldcor  wrote:
>
> > Hello all,
>
> > I began making a form that used request.user.get_profile to get
> > default values for company name, phone, email etc. I have since
> > decided to move to a formwizard to split things up. I have no idea how
> > to override methods for the formwizard class to be able to include
> > those initial values in the form. Can someone please help me with this
> > problem or point me to the proper help? I have come up short with all
> > of my searching. Thanks.


Hello,

The *initial* values for the forms in a form wizard are stored in the
self.initial[] list. It means, that to set set initial values for the
form in step X you do the following:

init = {
'key1':'val1',
'key2':'val2',
etc..
}

self.initial[X] = init

The best (and, indeed, about the only place to handle this) is the
process_step method of the wizard instance (or parse_params, if you
need to set initial values for the form in step 0).

Hope that helps

Mark

--

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

Re: Keeping state in the FormWizard: instance attributes considered harmful?

[Mark L.]

On Nov 6, 5:36 pm, txranger <txran...@gmail.com> wrote:
> yes this is very similiar to what I am working on right now. Being a
> newbie it seems much harder than it should be. I ended up setting a
> state variable within self.extra_context. It is set by overriding the
> process_step function in the FormWizard class based on the results of
> the previous forms values.  This state variable is also used in the
> get_template function(also overridden) to control which template is
> displayed.
>
> In my case I have 10 forms/sections and the quickest way through will
> show 6 of them and the longest will show 9 forms.
>
> When you say  " Form2 (must be dynamically set based on the submitted
> values in Form1)"  do you mean which form or which fields within that
> form?
>
> I am currently struggling with the display of pending changes and if
> the user does not like them allowing them to go back and change them
> so any ideas or solutions would be appreciated.
>
> txranger
>
> On Nov 3, 1:30 pm, "Mark L." <mark.l...@gmail.com> wrote:
>
> > Just to sparkle your imagination, the desired workflow of aFormWizard
> > I am trying to implement is as follows: Form1 -> Form2 (must be
> > dynamically set based on the submitted values in Form1) -> Form3 (show
> > a preview of pending changes to the user) -> done() (apply the
> > changes). I know, it sounds a bit complicated, but that is the way it
> > *has* to be.


Hello

To be honest, I've spent quite a time messing around with FormWizard
(especially, since I was using it wrong at first).

Do remember, that extra_context also persists between requests (which
is bad and can _not_ be depended upon). The thing is, you can set any
instance attributes and they *will* persist between the requests,
pointing to the same instance of the wizard. This, however, seems to
be extremely unsafe and not a good thing to do at all, because you
have no way of knowing which particular request set an attribute. In
short - don't try it.

What I've ended up doing is the following: I've stopped instantiating
the wizard in urlconf (as suggested by the examples in the dev
documentation), but instead I make sure, that the wizard is
instantiated on every request by wrapping it in a simple "view"
function and then using that function in the urlconf. The function
looks literally like this:

def my_wizard(request, *args, **kwargs):
wiz = MyWizard([Form1, Form2, ... FormN])
# where FormX are my form classes
return wiz(request, *args, **kwargs)

A wizard's __call__ method is just like any other view function, - it
takes a request and other arguments and returns a response. So it will
work perfectly, while ensuring, that you start with a clean plate on
every request.

When I say "Form2 must be dynamically set.. etc", means Form2 must be
of a different form class (it is a ModelForm autogenerated from a
Model, so it makes no sense to mess with the fields). It can be
handled in process_step by altering self.form_list, I've already
figured that one out.

As for displaying pending changes, I do it like this. Presumably,
there is a number of "actions" to be performed based on the submitted
data in the forms, right? Those "actions" are, basically, functions,
that need to be run in done(), right? You can associate each of that
"action" with a "description", that can be displayed in the last form
(the "Confirmation form"). In my case, the "actions" are represented
by self-contained ("curried") functions. You, basically, keep a list
of tuples where the first element of the tuple is a description of an
action and the second element is that action itself.

So in the last form's handler you do something like this:

if step == last_step:
self.extra_context['actions'] = [act[0] for act in self.actions]
# so that you have access to the descriptions in the template

def done(self):
for action in [act[1] for act in self.actions]:
action()
return HttpResponseRedirect('/done/')

Or something like that.

Another option would be using sessions to store state data, but this
is complicated by the fact, that only picklable objects can be stored
in the session. And you have to worry about clearing the state at the
appropriate time as well. I haven't explored this possibility yet.

Hope that helped

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

Re: Trace SQL back to python statement

[Mark L.]

On Nov 4, 3:44 pm, Knut Nesheim <knut.nesh...@mtab.se> wrote:
> 4 nov 2009 kl. 13.34 skrev Mark L.:
>
> > I guess by "debug toolbar" you mean the django-debug-toolbar (http://
> > pypi.python.org/pypi/django-debug-toolbar/0.8.0). If that is the case,
> > django-debug-toolbar has a number of options and among them
> > HIDE_DJANGO_SQL (set to True by default), which makes django' function
> > calls not to appear in query stacktraces. If you set it to "False",
> > you will be able to see the whole stacktraces. You can read up on the
> > rest of the options on the related package index page (at least,
> > that's where I've learned about them).
>
> Thank you for your help.
>
> If I set this to False, I see all sql queries executed, but what I  
> want is to see the actual python code responsible for executing the  
> query in the first place. I've read the documentation on the options  
> and I cannot find such an option.
>
> Regards
> Knut
> --
> Knut Nesheim  | MTAB Transport & Spedition AB
> Box 20164 | SE-161 02 Bromma | Visiting address: Ranhammarsvägen 26
> Phone: +46 8 54 600 153
> E-mail: knut.nesh...@mtab.se  | Web:www.mtab.se
>
> Vi utför alla uppdrag på grundval av NSAB 2000.
> All transactions are carried out according to our standard conditions  
> covered by NSAB2000

When you are in the SQL tab, to the left of the actual query, isn't
there a "Toggle Stacktrace" link? Clicking it reveals the stacktrace,
which has precisely the information you need.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Trace SQL back to python statement

[Mark L.]

On Nov 4, 2:02 pm, Knut Nesheim  wrote:
> Hello all,
>
> I'm trying to do some profiling on an application so I know where to  
> optimize and how I can expect it to perform with large datasets. I use  
> the debug toolbar to inspect sql queries.
>
>  From time to time certain pages will generate ~100 duplicated extra  
> queries. These pages lists orders and every order has two foreign keys  
> to Country. I use select_related to select the countries.
>
> All duplicated queries retrieve the same country. I have sifted  
> through the codebase and cannot find any rogue loop or such.
>
> Is there a way to trace an sql statement back to the offending python  
> statement?
>
> Regards
> Knut
> --
> Knut Nesheim  | MTAB Transport & Spedition AB
> Box 20164 | SE-161 02 Bromma | Visiting address: Ranhammarsvägen 26
> Phone: +46 8 54 600 153
> E-mail: knut.nesh...@mtab.se  | Web:www.mtab.se
>
> Vi utför alla uppdrag på grundval av NSAB 2000.
> All transactions are carried out according to our standard conditions  
> covered by NSAB2000

Hello,

I guess by "debug toolbar" you mean the django-debug-toolbar (http://
pypi.python.org/pypi/django-debug-toolbar/0.8.0). If that is the case,
django-debug-toolbar has a number of options and among them
HIDE_DJANGO_SQL (set to True by default), which makes django' function
calls not to appear in query stacktraces. If you set it to "False",
you will be able to see the whole stacktraces. You can read up on the
rest of the options on the related package index page (at least,
that's where I've learned about them).

Hope that helped

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

Re: Strange SQL Query

[Mark L.]

On Nov 4, 11:20 am, Maksymus007  wrote:
> I'm trying to use modelformset for my model using specified form.
> Everything works well unless i try to save forms - ale changes are
> saved, but for 22 forms django generates 91 queries (some of them are
> for auth, other parts etc - but this number should not exceed 30
> counting one query for each form). Nevertheless, i got 22 queries like
>
> SELECT (1) AS "a" FROM "finances"."gates_approvals" WHERE
> ("finances"."gates_approvals"."gate_approval_id" = 45 AND NOT
> ("finances"."gates_approvals"."gate_approval_id" = 45 ))
>
> which is totally useless. Did anyone meet such a strange behaviour?

Hello

Yes, I've seen this behaviour, all right. This looks like a
misbehaving uniqueness check and I've seen it happen in the .clean()
method of the model (in model-validation branch), and, while this is
certainly not where *you* are seeing it, the queries look just the
same.

This is the way Django handles uniqueness checks (and, quite frankly,
this is the only way to do it), however it should not be performed for
primary keys. If it wasn't a primary key field but some other
"other_unique_field" the query would look like this 'select (1) as "a"
from "table" where ("table"."other_unique_field" = 45 and not
("table"."id" = 45))', which makes perfect sense to me (this
observation was made by another django-users member, so I am not the
one to be thanked here).

Anyway, I haven't (yet) read the source of ModelFormSet, so I can't
give you any direct advice as to how to get rid of these queries.
Could you post your model declaration, by the way?

I hope my explanation helped at least a little bit.

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

Keeping state in the FormWizard: instance attributes considered harmful?

[Mark L.]

Since FormWizard is instantiated only once (in the urlconf, as
proposed in the documentation), no assumptions can be made about the
integrity and validity of its instance methods/attributes. It is very
easy to run into a situation, when self.form_list is altered and not
restored to a value, with which the FormWizard was initialized.
self.extra_context is also available at all times and doesn't get
cleaned up.

The question is, how to store the state inside the step and between
the steps?

For intra-step state (for example, if I want to set something in
parse_params and then access it in process_step) it seems rather
trivial, - just set an instance attribute and unset it later. This is,
however, not safe, because if something goes wrong during the
__call__, that attribute will not get unset. Nevertheless, it is not
so hard to implement, I guess.

What about inter-step state, though? I don't see an easy way to do it.
At first, I thought, that instance attributes are ok to use for this,
but then I've of course realized, that once FormWizard is initialized
in the urlconf, there will be only one of it, ever (__call__ will get
called, but that's it - there will be only once instance).

One possible way to work with it is sessions, but they have their own
limitations, - you cannot store unpicklable objects in them (so you
can't store a model or a curried function inside a session, right?). I
guess, this is all I can think of right now.


Just to sparkle your imagination, the desired workflow of a FormWizard
I am trying to implement is as follows: Form1 -> Form2 (must be
dynamically set based on the submitted values in Form1) -> Form3 (show
a preview of pending changes to the user) -> done() (apply the
changes). I know, it sounds a bit complicated, but that is the way it
*has* to be.

Obviously, the best way to work with it would be actually generating
the resultant changes as curried functions with attached descriptions,
that can be shown to the user, somehow pass them between the steps and
then actually call those functions in done(). This, however, seems
impossible to implement.


I'd be most grateful, if someone could give me an idea or two or, at
least, point me into a right direction.

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

Re: model-validation: Excessive (and weird) queries during validation

[Mark L.]

On Nov 2, 10:27 pm, Karen Tracey <kmtra...@gmail.com> wrote:
> On Mon, Nov 2, 2009 at 1:41 PM, Mark L. <mark.l...@gmail.com> wrote:
>
> > As the subject states, I am using the model-validation branch at the
> > moment, which allows me to do, well, validation in the models.
>
> > I've however, noticed a very strange behaviour of the validation
> > logic, - any time  the clean() method is fired on the
> > "materialized" (saved or retrieved from the database) model, that
> > contains unique fields, the following query is fired (let me just give
> > you an example):
>
> > from django.db import models
>
> > class A(models.Model):
> >    pass
>
> > a = A.objects.create()
> > a.clean()
>
> > a.clean() results, among everything, in this: 'SELECT (1) AS "a" FROM
> > "val_a" WHERE ("val_a"."id" = 1 AND NOT ("val_a"."id" = 1 ))'
>
> > I might be missing something vital, but what is that "where" clause
> > there for? What is it supposed to check?
>
> It's trying to verify the uniqueness of the supposed-to-be-unique field id.
> The query makes sense for fields other than the primary key, where the WHERE
> clause turns out more like:
>
> WHERE model.unique_field = proposed_value AND NOT model.id =
> current_instance.pk
>
> That is, it's asking "Is there any other instance in the DB, besides this
> one I'm looking at, that has the proposed_value for this
> supposed-to-be-unique field?"  If the answer is no, then all is fine, the
> proposed value doesn't violate the unique constraint.  If the answer is yes,
> then the validation check needs to fail because saving this model instance
> to the DB would violate the unique constraint.
>
> Of course, it doesn't make sense for the primary key field.  For that field,
> when you exclude the current instance from the search the WHERE clause
> becomes impossible to satisfy.  The model validation code, I'd guess, has
> been moved from where it was initially implemented (ModelForms).  In its
> original place the primary key field would not ordinarily have been included
> in the list of unique fields to check because it wouldn't ordinarily be on
> the form, and only values on the form are checked for uniqueness.
>
> The code in the new place likely needs to realize the primary key field
> shouldn't be checked for uniqueness.  You could check to see if this has
> been reported in trac and if not open a ticket for it.  I don't recall it
> having been brought up by anyone else but I could have missed it.
>
> Karen

Thanks for the quick reply, Karen

I've investigated a bit and it seems, that the problem is just what
you've said - the logic, that decides whether the field needs to be
checked for uniqueness or not, just doesn't take into account the
fact, that the field might be a primary key. Should be an easy fix,
especially since it doesn't seem to affect the ModelForm validation.

I've created a ticket on the issue tracker with a demonstration of the
problem and the fix.

Either way, it should be noted, that adding unique fields to the
models (besides the obvious pk field), can cause extreme performance
drops. Imagine cleaning a collection of 200 or objects causing 200 db
queries to be run (I'll benchmark it later). Perhaps the uniqueness
check for the Model could be moved to save() instead of clean() just
for this one reason?

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

Re: Formwizard and customizing the template layout

[Mark L.]

> Is there any way to have individual templates for each form

To define, which template should be used for which step, you can
override the get_template(self, step) method of the wizard (it must
return the name of the template), that way you can use separate
templates for certain steps (step numbers).

def get_template(self, step):

last_step = self.num_steps()-1

if step == last_step:

return 'confirm.html'

elif step == 1:

return "generic_wizard_step.html"

> and be able to perform the following
>
> 1. control the placement of fields
> 2. Allow for additional text inbetween fields
> 3. Control how check boxes are shown i.e. not one over another but
> side by side.

As for this, yes, this can be done by accessing the inner attributes
(and methods) of the "form" variable, that is passed to the template.
The best way to see it in action is to, actually, check the docs on
the forms (http://docs.djangoproject.com/en/dev/topics/forms/
#customizing-the-form-template). Sorry for not including the example,
but the documentation has those examples a-plenty.

Hope that helped.


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

model-validation: Excessive (and weird) queries during validation

[Mark L.]

As the subject states, I am using the model-validation branch at the
moment, which allows me to do, well, validation in the models.

I've however, noticed a very strange behaviour of the validation
logic, - any time  the clean() method is fired on the
"materialized" (saved or retrieved from the database) model, that
contains unique fields, the following query is fired (let me just give
you an example):

from django.db import models

class A(models.Model):
pass

a = A.objects.create()
a.clean()

a.clean() results, among everything, in this: 'SELECT (1) AS "a" FROM
"val_a" WHERE ("val_a"."id" = 1 AND NOT ("val_a"."id" = 1 ))'

I might be missing something vital, but what is that "where" clause
there for? What is it supposed to check? The stacktrace for the query
is the following:
787  clean django/db/models/base.py
619   validate django/db/models/base.py
624   validate_unique django/db/models/base.py
683   _perform_unique_checks django/db/models/base.py
112   __nonzero__ django/db/models/query.py
106   _result_iter django/db/models/query.py
692   _fill_cache django/db/models/query.py
756   iterator django/db/models/query.py
287   results_iter django/db/models/sql/query.py
2369 execute_sql django/db/models/sql/query.py

Apparently, it is happening inside the uniqueness check. Anyway, the
most strange thing, is that calling clean() results in a query. I've
noticed it when I was displaying a set of a few hundred objects (each
of them has to be cleaned before sending the data to template), which
resulted in a few hundred of queries (for a single request), which
brought my dev-machine to the knees. It becomes worse if the cleaned
model is a part of a table-inheritance hierarchy, - clean() is called
sequentially for every model "up" the hierarchy, which results in a
tremendous number of queries executed per single request.

I must say, however, that I, at this moment, have no idea how to check
for uniqueness *without* issuing a query and, from what I see, django
doesn't like to assume things, so the db hits *will* be made.

Obviously, I can swindle Django into not checking uniqueness on clean
(by rolling my own clean method in models.Model subclasses), however,
that doesn't sound like a very good idea (if alternatives exist).

Sorry if this is an inappropriate list/group for this question. Maybe
I should instead address it to the django-developers or the issue
tracker.

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