Re: ProgrammingError with PostgreSQL: operator does not exist: integer ~~* unknown

2008-04-19 Thread Merrick

I understand what you are saying the problem is. In my case here is
what sets this off:

class Meta:
unique_together = ('city', 'title',)

where city is a foreign key and now I see the mixed types.


On Apr 18, 8:58 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Fri, 2008-04-18 at 17:26 -0700, Merrick wrote:
> > I get the same problem as described here:
>
> > #6523
> >http://code.djangoproject.com/ticket/6523
>
> > There is a diff file which says it fixes the problem, how should I
> > proceed? If implement the diff, anyone care to tell me how please.
>
> We had a discussion about this behaviour on the dev list a while back
> and have decided that using inappropriate operators on the wrong field
> types (e.g. using LIKE on an integer) is just not going to work if the
> database doesn't auto-case. It's actually bad data design to rely on
> that and Django shouldn't have to carry the overhead for working around
> that (it would be extra overhead for every database backend, since every
> time the operator is used, we need to do a check for the backend type
> and then change the behaviour). Using casts everywhere at the database
> level also slows down query time quite a bit and, again, we aren't going
> to penalise people who are doing the right thing to accommodate those
> with bad design. Basically PostgreSQL 8.3 has started reporting an error
> for something that has always been more or less an error, but has been
> previously disguised.
>
> However, we still need to audit the internal uses to make sure we aren't
> inadvertently using these wrong types ourselves, which is why #6523
> (and, related, #6605) are still open.
>
> The short answer is to work out why you are trying to use these
> text-based operators on non-text fields and avoid doing that. It's
> wrong. However, it may not be your fault if it's something Django is
> doing, which is part of fixing that problem.
>
> Regards,
> Malcolm
>
> --
> If it walks out of your refrigerator, LET IT 
> GO!!http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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: ProgrammingError with PostgreSQL: operator does not exist: integer ~~* unknown

2008-04-18 Thread Malcolm Tredinnick


On Fri, 2008-04-18 at 17:26 -0700, Merrick wrote:
> I get the same problem as described here:
> 
> #6523
> http://code.djangoproject.com/ticket/6523
> 
> There is a diff file which says it fixes the problem, how should I
> proceed? If implement the diff, anyone care to tell me how please.

We had a discussion about this behaviour on the dev list a while back
and have decided that using inappropriate operators on the wrong field
types (e.g. using LIKE on an integer) is just not going to work if the
database doesn't auto-case. It's actually bad data design to rely on
that and Django shouldn't have to carry the overhead for working around
that (it would be extra overhead for every database backend, since every
time the operator is used, we need to do a check for the backend type
and then change the behaviour). Using casts everywhere at the database
level also slows down query time quite a bit and, again, we aren't going
to penalise people who are doing the right thing to accommodate those
with bad design. Basically PostgreSQL 8.3 has started reporting an error
for something that has always been more or less an error, but has been
previously disguised.

However, we still need to audit the internal uses to make sure we aren't
inadvertently using these wrong types ourselves, which is why #6523
(and, related, #6605) are still open.

The short answer is to work out why you are trying to use these
text-based operators on non-text fields and avoid doing that. It's
wrong. However, it may not be your fault if it's something Django is
doing, which is part of fixing that problem.

Regards,
Malcolm

-- 
If it walks out of your refrigerator, LET IT GO!! 
http://www.pointy-stick.com/blog/


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---