[sqlalchemy] Re: [Sqlalchemy-users] named cursor

if you are using SA strictly for its connection pool, the pool returns regular psycopg2 connections to you (well, inside a proxy) with which you can do whatever psycopg2-specific stuff you want. however if you are using SA's generated SQL and/or ORM, these systems abstract away the under

[sqlalchemy] Re: Backend for Sybase

heres the most recent thread: http://groups.google.com/group/sqlalchemy/browse_frm/thread/b1876fdc04c8c0c7?tvc=1&q=sybase --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group,

[sqlalchemy] Backend for Sybase

Has anyone written a backend for Sybase? Toyed with the idea? How involved of a project is it to write a new backend? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send

[sqlalchemy] Re: Update on MS-SQL work

Good idea Michael, I have added a patch for this to the ticket. And I'm just going to try adding a test as well. I'm a bit new to unit tests, so wish me luck! Paul another thing we might do if you want Unicode to act database-neutral is add a step at line 85 of types.py to ask the dialect f

[sqlalchemy] Re: Update on MS-SQL work

That sounds preferable to me instead of forcing everyone to use a subclass. Any feedback from MSSQL users? If we were to do this, then all Columns specified as type Unicode() would now be CREATE'd as NVARCHAR instead of VARCHAR. Note again that regular VARCHAR works for utf-8, so nothing is goin

[sqlalchemy] Re: Update on MS-SQL work

another thing we might do if you want Unicode to act database-neutral is add a step at line 85 of types.py to ask the dialect first for a type_descriptor of "Unicode", then if not found to ask for the "impl" version which is normally String. The MSSQL dialect would return NVARCHAR for the "Unico

[sqlalchemy] Re: Update on MS-SQL work

its using type_descriptor(), but when you use a TypeDecorator, such as the Unicode type, it calls type_descriptor given an "impl" type, which is a class-level variable (and if you look at types.Unicode youll see its "String"). since there is no "database" type for Unicode or PickleType, for exam

[sqlalchemy] Re: Mapping special child rows

Jonathan Ellis wrote: Hmm, another undocumented option... :) How is a viewonly relation on the class different from a relation on a non_primary mapper? oh theyre both documented. a non_primary mapper means, you load instances from the DB using an alternate table/selectable. once those ins

[sqlalchemy] Re: Mapping special child rows

On 1/8/07, Michael Bayer <[EMAIL PROTECTED]> wrote: and in both cases here im thinking first of the actual SQL id want to write, then i mentally translate that to an expression. Yeah, that is what I was shooting for, only I need more practice and got confused. :) Thanks. the mapping thing y

[sqlalchemy] Re: Update on MS-SQL work

So the SQL type to use for create() is no longer determined solely by the Dialect.type_descriptor() method? Some "implicit type" is determined before that? When did all that happen? Rick On 1/8/07, Michael Bayer <[EMAIL PROTECTED]> wrote: like i said in the ticket, all TypeDecorator types def

[sqlalchemy] Re: bitwise operators?

this is a bug, which I fixed in rev 2192. the op() function was previously being treated as a "compare" operation, using the operator given to the function. a "compare" returns a BooleanExpression which is more restrictive than a BinaryExpression, which is used by operators such as "+"/"-" etc.

[sqlalchemy] Re: Mapping special child rows

Jonathan Ellis wrote: o2 = orders.select().alias('o2') max_orders = orders.select(orders.c.order_id==max_order_id).alias('max_orders') youre not really showing me what you did there fully so its hard for me to tell how you got that result. - I take it SA doesn't really support subselects i

[sqlalchemy] Re: Update on MS-SQL work

like i said in the ticket, all TypeDecorator types define what type they are "wrapping" using the "impl" class member. dialect-specific Unicode types which want to subclass Unicode need only define a different "impl" member so that they wrap whatever String subclass you want. --~--~-~-

[sqlalchemy] Re: Update on MS-SQL work

Paul Johnston wrote: 3) unicode fields Ticket #298 had been created for this, but is not a complete solution. I have re-opened the ticker, with this comment: Unicode columns are still created as VARCHAR. The problem is that Unicode is a TypeDecorator