Re: [Modeling-users] type('') and unicode

[Yannick G. <yan...@sa...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Okay, so Soif was right, database logging makes it fails (unsurprisingly
> I must admit).
>
> Could you tell what happens if you disable MDL_ENABLE_DATABASE_LOGGING?
> Does it fail and if yes, where? (traceback as well would be ok)
> [given that you disable the encoding in your makeMatchQual]

Sure !

[...]
  File "/usr/lib/python2.2/site-packages/Modeling/EditingContext.py", line
1304, in fetch
    return self.objectsWithFetchSpecification(fs)
  File "/usr/lib/python2.2/site-packages/Modeling/EditingContext.py", line
1218, in objectsWithFetchSpecification
    objects=3Dself.parentObjectStore().objectsWithFetchSpecification(fs, ec)
  File "/usr/lib/python2.2/site-packages/Modeling/ObjectStoreCoordinator.py=
",
line 420, in objectsWithFetchSpecification
    return store.objectsWithFetchSpecification(aFetchSpecification,
anEditingContext)
  File "/usr/lib/python2.2/site-packages/Modeling/DatabaseContext.py", line
1521, in objectsWithFetchSpecification
    anEditingContext)
  File "/usr/lib/python2.2/site-packages/Modeling/DatabaseChannel.py", line
381, in selectObjectsWithFetchSpecification
    entity)
  File
"/usr/lib/python2.2/site-packages/Modeling/DatabaseAdaptors/AbstractDBAPI2A=
daptorLayer/AbstractDBAPI2AdaptorChannel.py",
line 288, in selectAttributes
    db_info('Evaluating: %s'%statement)
  File "/usr/lib/python2.2/site-packages/Modeling/logging.py", line 56, in
log_stderr
    sys.stderr.write('%s\n'%msg)
UnicodeError: ASCII encoding error: ordinal not in range(128)

It sounds pretty much the same to me...

> > What I said earlier is that I manually utf-8 encode every thing the I
> > *store* in the DB.  I thought that I might be safe with queries but
> > well, utf-8 encoding queries too is not that much work.
>
> Ok. Sorry I did not understand you right. So this is as simple as that,
> just encode the attributes' value and that's it? I must try that on of
> these days.

Indeed it does the job but as it was discussed some time ago on the
mailling list, it does not enable case insensitive match.  A case
insentivice match with u"=E9=E9" encoded in utf-8 with look for "=C3=A9=C3=
=A9",
"=E3=A9=C3=A9", "=C3=A9=E3=A9" and "=E3=A9=E3=A9" wich does not make any se=
ns once put back in
unicode.  "=E9=E9", "=C9=E9" and "=C9=C9" are respectivly "=C3=A9=C3=A9", "=
=C3=C3=A9" and "=C3=C3"
once encoded.

So it may be wise to let the user make the utf-8 trick.  That way he
won't blame you for the weird result of case insensitive match.  On
the other hand, some databases like Postgresql detect encoding and
perform a descent case insitive match with utf-8 data.

=2D --
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468


=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/FaQJrhy5Fqn/MRARAtstAJ0ak6KfychPQ6IXORlB+coVpN2dPwCeIljY
ZFc9vy4sJZ8lIEOFVzWLvkE=3D
=3DwIdl
=2D----END PGP SIGNATURE-----