On Apr 23, 2006, at 6:45 PM, Jonathan Ellis wrote:
> Well I also think people should tell me what they think of
> that....its essentially more monkeypatching.
>
> Well, it comes down to the usual trade-offs, right? How hard is
> it to accomplish w/o monkeypatching, and how likely is it to screw
> someone up who isn't expecting your patch in a stdlib object?
>
> Unless I'm missing something, the answers here seem to be "not very
> hard" and "fairly likely." But, maybe I _am_ missing something. :)
>
OK, here is the architectural situation.
We have an object called "Unicode" which is used to represent a
String type in a database table that will do some unicode conversion
on data going in and out of the table.
The system has a set of "engine" APIs designed for different kinds of
databases, and each supports a function "reflecttable" which knows
how to go into the database, query some rows, and return a Table
object which represents the databases returned information about a
specific Table. Each database API, when it sees something like
VARCHAR or whatever, pulls up a new String object and sticks it in
the appropriate column in the Table object.
These guys want to write their own Unicode object, and make it so
that whenever those database libraries do "reflecttable" and see
VARCHAR, they pull up their custom Unicode object, not the default
String object.
so the most braindead way to do this is just to monkeypatch the
"String" with a "Unicode" class.
the more elaborate way is to have the "engine" take some map of
arguments that relates some kind of constant to the Unicode class, or
a callable, or some interface called a TableTypeFactory, what have
you. none that I can think of are not either a. some arbitrary
thing, which is messy since we have lots of other places where we
need to plug things in and we'd have an explosion of ***Factory
objects or arbitrary dictionaries of classes and stuff, or b.
something totally genericised like the "Dependency Injection" example
but also seems pretty overblown.
So how would you approach this ?
Well, it seems clear to me that data coming out of the db should be interpreted according to what the db says its encoding is. (I said before that we could allow SA to override what the db says the encoding is and use something else instead but I can't think of a use case for this. It would just confuse people more.)
There's no need to re-encode the data to a "client encoding"; just hand out raw unicode objects, which is usually more useful; if the client wants to encode to his locale (or another) leave that to him.
For data going into the db, same thing, encode it the way the db expects.
DB drivers may already help with this.
--
Jonathan Ellis
http://spyced.blogspot.com
