Re: Model validation for non-django-orm databases

On 30/08/10 06:07, onelson wrote:

> I've read that a "hack" around this kind of issue is to use the meta
> unique_together property and almost arbitrarily set primary_key on one
> of the fields. That sounds great, except for the fact that I've got
> no guarantee that any given field will actually be unique -- which
> column do I add the primary_key to?

With the hack i think you mean, it doesn't matter, just pick one, the
point of the hack is you just shamelessly lie to the django ORM. So make
sure to make your model ummanaged and _don't_ try to save.

N.B. I would assume that you're thoroughly on your own with this hack, I
wouldn't expect django to officially support it. Maybe one day someone
will make something like (for argument's sake)

foo = models.PositiveIntegerField()
bar = models.PositiveIntegerField()
foobar = models.CompositeField(['foo', 'bar'], primary_key=True)

work, but right now it doesn't.

> loads/validates I'm happy.

I'm not sure about django 1.2+ model validation with the hack, though,
or even just django 1.2. We use the hack - but presently with 1.1.

Looking at the docs, you're presumably not using a ModelForm, and if
you're explicitly using Model.full_clean() or clean_fields() you can
probably pass in an exclude=... to exclude the field(s) that you're
lying to django about if need be. Based on the docs rather than
experience, I don't think django model calls validators on initial
load/init, it has to be by ModelForm calling them on the model, or just
explictly calling one of the model clean methods.

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.