On Thu, Apr 10, 2008 at 4:54 AM, firtzel <[EMAIL PROTECTED]> wrote:
>
>
> > A few details on what "does not seems to work properly" looks like might
> > help people help you.
>
> Thanks for your reply. You're absolutely right. Here are some more
> details:
> In the admin, when I try to save a catalog with more than one BadItem,
> I get the following error:
>
> Exception Value: ERROR: IN types character varying and integer
> cannot be matched SELECT "testapp_baditem"."name" FROM
> "testapp_baditem" WHERE "testapp_baditem"."name" IN (12,34)
> Exception Location: c:\Python25\Lib\site-packages\django\db\backends
> \postgresql\base.py in execute, line 43
>
> I added the djangologging application, and saw that the first
> problematic SELECT is in main.change_stage, line 325.
>
> djangologging's relevant log output:
>
> SQL 11:49:35,187 main.change_stage:325 SELECT "
> testapp_baditem"."name" FROM "testapp_baditem" WHERE "
> testapp_baditem"."name" IN (12,34) 0 ms
> SQL 11:49:35,296 pprint._safe_repr:292 SELECT "testapp_baditem
> "."name" FROM "testapp_baditem" WHERE "testapp_baditem"."
> name" IN (12,34) 0 ms
> SQL 11:49:35,296 pprint._safe_repr:292 SELECT "testapp_baditem
> "."name" FROM "testapp_baditem" 0 ms
> SQL 11:49:35,296 pprint._safe_repr:292 SELECT "testapp_baditem
> "."name" FROM "testapp_baditem" WHERE "testapp_baditem"."
> name" IN (12,34) 0 ms
>
> ("main" is file django/contrib/admin/views/main.py)
>
> This is all with django-0.96.1, although django trunk version causes
> the same problems.
>
> I found something that may be related to this problem here:
>
> http://code.djangoproject.com/changeset/5647
>
> The problem is, this is a bug fix in django-0.91, and the discussed
> file in this changeset (/django/core/meta/__init__.py) no longer
> exists.
>
> If there is more data that can help which I neglected, please let me
> know.
>
> > One thing I find odd is that you decided to limit your
> > CharField to only digits -- if you are going to do that, why not just
> > convert it to a numeric field instead? That would make it more like the
> > default primary key field, so might fix the problem. (Though I'm also
> not
> > sure how wise it is to be trying to use the name field as a primary key
> in
> > the first place.)
>
> When I did not limit the field to digits, and tried to add a single
> BadItem to the catalog, the add form gave me this error:
> "Enter only digits separated by commas."
> I guess It's related to the previous problem, since the admin may
> refer to these ID's as numeric instead of their real type, CharField
> in this example.
>
> This example is indeed a bit strange, but it's a simplified version of
> the original models.
>
OK, there seems to be an assumption in the old manipulator/validator code
that raw_ids are numeric. You ran into this first when you tried to add a
non-numeric raw_id and were told to enter only digits. 'Fixing' that by
allowing only digits in your (character) primary key field got you past that
hiccup but not much further. Next problem is when the manipulator/validator
code goes to retrieve the items you have listed in your many-to-many field
it constructs a query that assumes your primary key field is numeric, which
it isn't, so the database raises an error. (Actually only some databases
raise the error. Postgres 8.3 does, MySQL 5.0 doesn't, I didn't try any
others.)
I do not think this will ever be made to work with the old
manipulator/validator code. Good news, maybe, is it does work OK with
newforms-admin. You do not even need to limit your primary key field to
only digits. (You do need to be sure not to include extraneous spaces in
between your comma-separated list of ids.) One big caveat: I have no idea
if this works intentionally or only by accident on newforms-admin. I do not
know whether allowing non-numeric primary keys in raw_id fields is something
anyone ever gave any thought to.
Karen
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
