Re: blessing db data as utf8

[prev] [thread] [next] [Date index for 2004/06/09]

On Wed, Jun 09, 2004 at 06:23:01AM +0100, Tony Bowden wrote:
> On Wed, Jun 09, 2004 at 12:07:39AM +0300, Gaal Yahas wrote:
> > Is there a CDBI way to implement the workaround described here for straight DBI?
> >      http://perlmonks.thepen.com/314423.html
> > Briefly, the problem is getting perl to think of a string as utf8
> > "even when it IS".
> > What I'm looking for is a way for Class::DBI to perform the autoconversion
> > for me transparently.
> 
> I don't really understand the utf8 issues well enough to know whether
> this conversion needs to happen at a certain point, but if it's just a
> matter of calling Encode::_utf8_on on each value fetched from the
> database, you can probably do somehing in sth_to_objects(), or possibly
> construct(), or even _init() if there's no problem in doing it on data
> you're passing to create() yourself.
 
Regarding creation, it's safe to call Encode::_utf8_on multiple times
on a string that is utf8, though of course it slows things down and
it's reasonable to require the application to hand over utf8 strings
to the database. (BTW, there's a pack/unpack hack to do the same thing
as Encode::_utf8_on but without the overhead.)

> It may be better doing it in DBIx::ContextualFetch though, or even in
> DBI itself...

The problem is that the database doesn't know better: as far as it is
concerned, the data is (say) latin1. This is true at least for mysql 4.0.20
which I have been using. This means that the metadata about encoding type
of a table or a column can't come from the database, even though ideally
it should. I don't know DBIx::ContextualFetch to say, but DBI seems at the
moment to be too low-level for this kind of knowledge.

That said, *my* data is all utf8, so I don't mind a global switch :)

        -- 
        Gaal Yahas <gaal@xxxxxx.xxx>
http://gaal.livejournal.com/