OK, i think im getting this now...i think between the myghty list and here one can begin to see my lack of unicode awareness...
so basically, since your python file has the -*- coding attribute, you dont really have to put the u'' around strings that contain multibyte characters, since the multibyte encoding is implicit throughout the file. so the client_encoding pretty much is designed to match up with a python script that has a -*- declaration, is that accurate ? ill add the patch to my list. code says it all for me .... Vasily Sulatskov wrote: > Hello Michael, > > I know there's a database engine parameter "encoding". It tells > sqlalchemy in which encoding Unicode objects should be saved to > database. > > I suggest adding another encoding, let's say "client_encoding" which > will be used when convert_unicode is True and user assigns string > object to object attribute. Currently even if convert_unicode is set > to True string go to database as-is, bypassing convertion to unicode. > > This option will allow to assign string's in national/platform > specific encodings, like cp1251 straigt to object attributes and they > will be properly converted to database encoding (engine.encoding). > > > See, encoding on client machine may be different from encoding in > database. You can see changes that I suggest from attached diff. > > Suggested changes will can make life of users of > multilingual/multienconding enviromnents a little easier while not > affexcting all other users of SQLAlchemy. > > MB> On Apr 17, 2006, at 5:47 AM, Vasily Sulatskov wrote: > >>> In my opinion that's a bug and that behaviour should be changed to >>> something >>> like that: >>> 1. If object is unicode then convert it to engine specified >>> encoding (like >>> utf8) as it happens now >>> 2. If it's a string then convert it to unicode using some another >>> specifed >>> encoding (it should be added to engine parameters). This encoding >>> specifies >>> client-side encoding. It's often handy to have different encodings >>> in database >>> and on client machines (at least for people with "alternate >>> languages" :-) > > > MB> there already is an encoding parameter for the engine. > > MB> http://www.sqlalchemy.org/docs/dbengine.myt#database_options > > MB> does that solve your problem ? > > -- > Best regards, > Vasily mailto:[EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
