On Sun, 2012-04-15 at 05:32 -0700, Kyle Schaffrick wrote: > Wow, a blast from the past! :)
Yes.
> Which version of SQLAlchemy does your new version work with? It's
> great that you are now able to get rid of the HStoreComparator, that
> really makes it easier to use. The version of SQLA I was using 2 years
> ago when I wrote it required the custom comparator to make the
> operators work on the ORM InstrumentedAttribute as well as on the Core
> Column. I suppose the new version doesn't require this duplication?
I've gone back through the thread and I can't find a link to your work
[regarding the hstore implementation]. Can you post one?
> On your question, I think that PostgreSQL's hstore supports unicode
> just fine; the keys and values are of type "text". It is just a bug in
> my code that it does not work. I think the main issue would be to
> replace .encode('string_escape') in _serialize_hstore()
> and .decode('string_escape') in _parse_hstore() with something that
> will do the same job but work for both unicode and string, and to make
> sure the regexes are unicode safe (or replace them with a proper
> parser).
signature.asc
Description: This is a digitally signed message part
