Thanks, Malcolm! It's encouraging to hear that others are also
working on this. A follow-up question:
I'm inclined to try approach #1, by adding custom subclasses of Add-
and ChangeManipulator to the model (in this case called Thesis). If I
can figure out way to get the dispatch mechanism to associate these
new custom manipulators with the model class (it doesn't happen by
simply including these custom classes in the model definition), then I
should have (the stock ChangeValidator already get it in __init___) or
be able to pass (AddValidator would need such an __init__) access to
model instance info in the manipulator context, allowing me to write
model-aware validators here without changing any django code.
I haven't tried this yet. I'll keep you posted on how it goes. If
you have any insight on pros and cons of this approach, please let
know.
Mark
> 1. Add a custom field validator to validator_list -
> Field validator will only check at the individual field level where
> information about the model instance (i.e. User info) isn't in
> context. Also, there doesn't seem to be a good way to find out
> whether it is an "add" or a "change" operation, which need to be
> handled differently. Any way to get this out-of-context information?
If you field submission includes enough information to work out the
model, you can use the DB API to select the model. However, often that
information is in the URL and it kind of assumes all the other data is
valid. It's very hacky -- I'm using it in one application where there
was no other choice, but I hate it as a solution.
On Apr 6, 12:22 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-04-05 at 21:12 -0700, Mark Soper wrote:
> > I'm trying to figure out the best way to validate aunique_together
> > constraint. The relevant parts of the model are here:
>
> > ------------------------------------------
> > class Thesis(models.Model):
> > thesis_name = CharField('Thesis Name', maxlength=50,
> > core=True, validator_list=[???????])
> > thesis_owner = models.ForeignKey(User, editable=False)
>
> > def save(self):
> > if not self.id:
> > self.thesis_owner = threadlocals.get_current_user() ***
> > super(Thesis,self).save()
>
> > class Meta:
> > unique_together= (("thesis_name", "thesis_owner"),)
>
> > *** - using the threadlocals middleware from Luke Plant
> >http://lukeplant.me.uk/blog.php?id=1107301634
> > -----------------------------------------
>
> > I'm using the standard django admin interfaces. The thesis_owner
> > field is populated automatically with the user info, but not until
> > after user inputs have been validated. So the standard
> >unique_togethervalidation doesn't catch duplicate entries. They
> > aren't caught until the database issues an IntegrityError, generating
> > a fatal error to the user. Instead I'd like to raise the standard red
> > error banner with a message like "A thesis already exists with name
> > XXXXX. Please choose a different name".
>
> I can't offer much encouragement here... the drawbacks to all the
> solutions you list are very accurate. You've understood the problem. :-(
>
> This is the motivation behind getting model-aware validation in place in
> Django. We need it for exactly these types of cases.
>
>
>
> > Possible solutions:
>
> > 1. Add a custom field validator to validator_list -
> > Field validator will only check at the individual field level where
> > information about the model instance (i.e. User info) isn't in
> > context. Also, there doesn't seem to be a good way to find out
> > whether it is an "add" or a "change" operation, which need to be
> > handled differently. Any way to get this out-of-context information?
>
> If you field submission includes enough information to work out the
> model, you can use the DB API to select the model. However, often that
> information is in the URL and it kind of assumes all the other data is
> valid. It's very hacky -- I'm using it in one application where there
> was no other choice, but I hate it as a solution.
>
>
>
> > 2. Custom uniqueness check in the model's save method -
> > This approach allows for access to user info and checking for "add" or
> > "change" (see above). However, the save happens after the view's
> > error checking has completed, so raising a ValidationError at this
> > stage results in a fatal browser error rather than the red error
> > banner. Is it possible to cause save to raise the red banner instead?
>
> Saving should never raise validation errors for exactly the reason you
> mention. About the only thing saving might raise is database connection
> errors (we can't help it if somebody pulls out the network cable) or
> possibly IntegrityError: another thread or process beat you to the punch
> and we can't control that either.
>
> > 3. Supplement the user info into the POSTed data before it is passed
> > to the validation -
> > Theoretically the standard manipulator_validator_unique_together
> > function will catch the error. Can this be done through a custom
> > manager or manipulator or in some other way that doesn't require
> > changes to the admin views, models, etc.?
>
> Might be possible. Never tried it.
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
