Well, it looks like Postgres doesn't mind bytea as a PK (the table definition shows that it's using it) so I don't think that is the problem. The objects themselves seem fine too, it was just the string representation that was an issue (AFAICT).
I did figure out a workaround however (although I'm not sure I like it), by checking the dialect.name in my BinAsciiType.process_result_value function and since postgres is doing essentially what I was having binascii.b2a_hex do, I'm just returning that value (minus the leading 'x' character) when talking to postgres and that seems to work okay. I'd rather not have to check that for every return value though, since that string comparison is probably more time consuming than I'd like, so I'll continue to try and figure out a better way around this in the future but at least now I can move the rest of my code along: get it working first, optimise later. :) If I can get the postgres layer (whether it be the server or psycopg2 side) to stop being helpful and just give the binary bytes back, I think that's a better answer. BTW, I started down the road of the plain psycopg2 test case too, but thought of that workaround in the middle of it so went with that for now. When I revisit the problem I'll probably start there as you suggested. And you are totally right to call me out on the pass in the except block. The only reason it is in there right now is because I wasn't sure on the right way to indicate there was a problem just yet (and too lazy to look for more info, apparently). Figured there is an SQLAlchemy "standard" exception I could/should (perhaps inherit from and) throw, but hadn't looked for that yet. But I will. :) Thanks! Chuck On Dec 29, 3:15 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > The only unusual thing about the app is the usage of a binary field as a > primary key. I'm not even sure postgresql supports bytea as a PK, but that > is a very likely candidate for where things are going wrong. If the bytea > actually works as a PK, the ORM may be tripping on it. Try building a test > that uses plain psycopg2 directly, then another that uses the SQL expression > language. Also definitely take out "try: ... except: pass", that's a > guaranteed way to add confusion and uncertainty to a test case. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
