I added another updated patch to the tracker. Please check it out and
give me seom feedback. This is just a start but I want to know if I'm
going in the right direction.
Aaron Spike
-
Take Surveys. Earn Cash. Influence the Fu
Michael Bayer wrote:
> im inclined to just get something in there that does the job for
> now...the patch thats on ticket #155 is very close to whats needed. if
> you can try it out and maybe link to a "quote=True" keyword argument on
> Table and Column, make some test cases, we're in business.
On Aug 1, 2006, at 9:18 AM, Aaron Spike wrote:
> Michael Bayer wrote:
>> thats a good point. although you can use any literal name for a
>> column
>> name:
>>
>> mytable.c["somecolumn"]
>>
>> but if you want to go the "key" route we can, but im pretty sure
>> theres
>> going to be a lot
Michael Bayer wrote:
> thats a good point. although you can use any literal name for a column
> name:
>
> mytable.c["somecolumn"]
>
> but if you want to go the "key" route we can, but im pretty sure theres
> going to be a lot of new ORM bugs that will need repairing. most of the
> effort wi
thats a good point. although you can use any literal name for a
column name:
mytable.c["somecolumn"]
but if you want to go the "key" route we can, but im pretty sure
theres going to be a lot of new ORM bugs that will need repairing.
most of the effort with this ticket is the testi
Michael Bayer wrote:
> the "key" argument to column doesnt work very well when you get into
> crazier mapping scenarios; there arent a lot of test cases that use it
> and it complicates things. it would be better if identifiers knew to
> quote themselves in a database-agnostic manner.
The proble
the "key" argument to column doesnt work very well when you get into
crazier mapping scenarios; there arent a lot of test cases that use
it and it complicates things. it would be better if identifiers
knew to quote themselves in a database-agnostic manner.
On Jul 30, 2006, at 7:42 AM, Aaro
Aaron Spike wrote:
> What do you think of this direction at the problem? Do you see any
> hidden gottchas?
I've updated ticket #155 with examples of identifiers that could cause
problems. I've also attached an alternative patch.
http://www.sqlalchemy.org/trac/ticket/155
Please comment.
Aaron Sp
Michael Bayer wrote:
> ticket #155. theres some patches there that are very close to how it
> should be done. i didnt like the "quote_string" function being called so
> often but there might not be any way around that (i.e. maybe the
> quote=True flag not really worth it).
>
> what this patch wo
ticket #155. theres some patches there that are very close to how it
should be done. i didnt like the "quote_string" function being called so
often but there might not be any way around that (i.e. maybe the
quote=True flag not really worth it).
what this patch would need is, support for other DB
Michael Bayer wrote:
> theres a ticket in Trac to support quoted identifiers. its not
> implemented yet, but it will involve you putting a flag "quote=True" on
> your Table definition (since i dont want impose the quoting stuff on
> people unless people specifically want it).
Are you refering to
theres a ticket in Trac to support quoted identifiers. its not
implemented yet, but it will involve you putting a flag "quote=True" on
your Table definition (since i dont want impose the quoting stuff on
people unless people specifically want it).
Aaron Spike wrote:
> In my first few minutes ex
Aaron Spike wrote:
> sqlalchemy.exceptions.SQLError: (ProgrammingError) parser: parse error
> at or near ":" at character 148
> 'SELECT "vPersons"."Person_ID", "vPersons"."Person_LastFirstM",
> "vPersons"."Person_LastName" \nFROM "vPersons" \nWHERE "vPersons"."Person_La
> stName" = :"vPersons"_"Pe
In my first few minutes experimenting with SQLAlchemy I ran into the
following error. I've been staring at it for a day now and I think I
understand what is going on. The PostgreSQL schema I'm working with
makes use of delimited or quoted identifiers. SQLAlchemy seems to be
having dificulties parsi
14 matches
Mail list logo
