Re: ManyToManyField in both models/forms
Oops, sorry. I meant form's meta. Something like this: class GroupForm(ModelForm): class Meta: model = Group m2m_model = User Looks like more logical thing, than I suggested at the beginning. On Jan 24, 6:53 am, Malcolm Tredinnick wrote: > On Fri, 2009-01-23 at 00:12 -0800, Evgeniy Ivanov wrote: > > On Jan 23, 3:17 am, Malcolm Tredinnick > > wrote: > > > Addressing this only in the admin would be short-sighted, however. A for > > > field that new how to handle reverse relations would be the first step > > > and then allowing the admin to use that is the second one. > > > Maybe better approuch is in model's meta? It will give forms a chance > > to do this fancy thing. And it is a kind of logical, since model > > really has such relation. > > No. Because Meta is not about presentation. It's part of the model, > which is defining how the data is stored and retrieved. This whole issue > is *purely* presentational. Attempting to change the model class to > "solve" it is simply using the wrong shovel to hammer in your screws. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django-smtpd allows you to handle email messages just like Django processes HTTP requests.
Sorry about that. Do you think such a library, once stable, could make it to the trunk? Regards, Denis On Jan 23, 10:51 pm, Malcolm Tredinnick wrote: > On Fri, 2009-01-23 at 15:08 -0800, nside wrote: > > Hello, > > > I just started a new project that basically allows you to write email > > handlers in Django. It could be used in a user-registration > > application where the user could reply to the email instead of > > clicking on a URL. > > I drafted a quick documentation > > athttp://code.google.com/p/django-smtpd/wiki/GettingStarted > > It shows the basic design of the lib and I'm looking for comments/ > > suggestions/use cases if that's of interest of anyone on this list. > > Note that this is still in "hacking" phase so don't consider using > > this in a production system. > > I think you'll get better feedback by posting to the django-users > mailing list about this. This list is for the internal development of > Django itself, not external applications. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
old sqlite versions
In ticket #10113 I signalled two problems. The first was almost immediately fixed by Russel (thanks!). For the second problem I added a specific testcase that was giving me wrong results. It concerns an annotated query with ordering on a foreign key that was not yet included in the query. Russel reported no errors for this query for him though. It turns out this query was only giving wrong results on the sqlite version I was using (3.3.4 (pysqlite 2.3.2). When I tried this with a more recent version (pysqlite 2.5.1,i.e. sqlite 3.6.2), all went well. This solves my problem, but leaves a question: the version I was using was the one built-in in my windows python 2.5 install, which means it is probably not an uncommonly used version. Does this mean there is reason to try and work around the old sqlite bug in django, by preventing the kind of query that is causing the trouble ? I did not investigate to deeply and my SQLfoo is very poor, but a simple experiment suggests me that modifying the order of the joins might help. The troublesome query had some SQL like this "select ... sum(B.x) from A left outer join B on (...) inner join C on (...) group by ... order by C.y" which confuses sqlite 3.3.4 and produces wrong results. Changing it to "select ... sum(B.x) from A inner join C on (...) left outer join B on (...) group by... order by C.y" does seem to produce correct results however. Does this ring a bell to anyone, and more importantly, do we need to do something about this ? Koen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Flatpage signal?
On Fri, Jan 23, 2009 at 6:16 PM, Jeremy Dunck wrote: > I'd like to do some processing any time a flatpage is requested. > > I can accomplish this by using a view middleware and testing for the > resolved view, but it seems a like a signal would be useful so I could > have a reference to the flatpage object itself. > > Any opposition to the idea? Yes, this gets strong, strong opposition from me. The fewer signals we have in our framework, the better. It still bugs me that we have as many as we have now, frankly. Adrian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: old sqlite versions
On Sat, Jan 24, 2009 at 1:16 PM, koenb wrote: > > In ticket #10113 I signalled two problems. The first was almost > immediately fixed by Russel (thanks!). For the second problem I added > a specific testcase that was giving me wrong results. It concerns an > annotated query with ordering on a foreign key that was not yet > included in the query. Russel reported no errors for this query for > him though. > > It turns out this query was only giving wrong results on the sqlite > version I was using (3.3.4 (pysqlite 2.3.2). When I tried this with a > more recent version (pysqlite 2.5.1,i.e. sqlite 3.6.2), all went well. > > This solves my problem, but leaves a question: the version I was using > was the one built-in in my windows python 2.5 install, which means it > is probably not an uncommonly used version. Does this mean there is > reason to try and work around the old sqlite bug in django, by > preventing the kind of query that is causing the trouble ? > > I did not investigate to deeply and my SQLfoo is very poor, but a > simple experiment suggests me that modifying the order of the joins > might help. > The troublesome query had some SQL like this "select ... sum(B.x) from > A left outer join B on (...) inner join C on (...) group by ... order > by C.y" which confuses sqlite 3.3.4 and produces wrong results. > Changing it to "select ... sum(B.x) from A inner join C on (...) left > outer join B on (...) group by... order by C.y" does seem to produce > correct results however. > > Does this ring a bell to anyone, and more importantly, do we need to > do something about this ? > Yes, something needs to be done, but I'm not sure what. Sqlite + Windows Python 2.5 does ring a bell for being troublesome, though I think this particular problem is not yet known to us. That specific combo, however, is known to have at least two other problems. One Russell mentioned in his aggregate checkin announcement (though to me it sounds unrelated to what you are hitting): http://code.djangoproject.com/ticket/10031 This one is pending more investigation to see if it is possible to work around. Then there is this other one found a while ago: http://code.djangoproject.com/ticket/7570 which prompted this doc note: http://docs.djangoproject.com/en/dev/ref/databases/#versions-prior-to-3-3-6 after investigation revealed it couldn't be reasonably worked around in Django code. As more of these pile up I personally become less inclined to try to figure out workarounds and more inclined to just recommend that Windows users either use a more recent Python or at a minimum update their sqlite. But that's just me. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Model-validation: call for discussions
After several discussions with Honza, we are still on somewhat
different positions what the validator function signature should
be and how core validators should access the fields of a form or
a model instance.
In core validators, no special case handling of forms and models
is needed even in multi-value validators. All what is needed is
an abstraction of "the set of other values".
AlwaysMatchesOtherField, RequiredIfOtherFieldDoesNotEqual etc
will work with that abstraction, primary keys and other complex
model fields also work for same-type comparison.
My initial idea was to reduce the model instance to a dict (as
discussed previously), however, this is really too restrictive.
Passing the form or model instance and treating it in dict-like
manner provides much more flexibility.
That can be achieved by the following:
class Model(...):
...
def get_value(self, field_name, *args):
"Default is specified with the first positional argument"
if args:
return getattr(self, field_name, args[0])
return getattr(self, field_name)
class BaseForm(...)
...
def get_value(self, field_name, *args):
"Default is specified with the first positional argument"
if args:
return self.cleaned_data.get(field_name, args[0])
return self.cleaned_data[field_name]
(It's not possible to implement the __getitem__ protocol as it
already works differently in forms.)
In this case the form/model dichotomy is not required in
validator signature, simple validators work as follows:
def is_slug(value, instance=None):
(access only value)
and multi-value validators as follows:
class AlwaysMatchesOtherField(object):
...
def __call__(self, value, instance=None):
if value != instance.get_value(self.other):
raise ValidationError(...)
There are currently no model-specific complex validators. If a
need for them should arise, it's probably easiest to override
validate() in the corresponding class, calling super().validate()
and then perform any additional checks there.
Custom validators can either use the get_value() abstraction to
support both models and forms or be model/form-specific and use
the instance in whatever way they like. Checking whether you deal
with a model or form instance is generally not required -- if you
accidentally pass a custom form validator to a model, it will
visibly break and vice-versa.
Honza doesn't like this, mainly because it's too easy to shoot
yourself into foot with this (as outlined above, I disagree with
that) and as of now we are using the following instead to handle
model and form fields uniformly:
def _get_value(name, all_values, instance, do_rise=True):
if instance is not None and hasattr(instance, name):
return getattr(instance, name)
if name in all_values:
return all_values[name]
if do_raise:
raise AttributeError('%s not found in form values or model
instance'
% name)
return False
class AlwaysMatchesOtherField(object):
...
def __call__(self, value, all_values={}, instance=None):
if value != _get_value(self.other, all_values, instance):
raise ValidationError(...)
Honza's comments:
-
The problem is that I do not want Form class to be passed to
validators for several reasons:
Form shouldn't be anything except something that obtains data
from request and can validate them, passing it validators could
promote adding some methods and properties to be used in
validators, instead of in the form's clean() method.
Form and model treat data differently, that's just the way it is
and as it should be - pretending it's not true will just create
opportunity for nasty surprises.
Validators wouldn't work outside forms and models (it's easy to
pass in a dictionary of all_values, but fabricating a class with
the same method is work).
I would still have to check whether I am dealing with model or
form when I would like to access some model's methods and
properties that cannot be retrieved this way.
I have more reasons, but these are the major ones, if it's not
enough, contact me and we can talk ;).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
