also, what im considering doing, is having assert_unicode only be
implicitly turned on for the Unicode type specifically. the engine-
wide convert_unicode and String convert_unicode would not implicitly
set the assert_unicode flag.
That makes more sense to me, and I would prefer it. The
the assert_unicode thing only happens with python SQL expressions,
usually DDL is issued using textual SQL. if youre using a SQL
expression for your DDL
The creates/drops are via Metadata.create_all() / .drop_all(), so perhaps
there's an expression in that path? Didn't trace it yet (as I
Running much better this way...
I think this will make the next release and adoption of the feature a
lot easier.
Me too, many thanks for the quick turnaround!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Is there any way to configure logging on an engine instance after the engine
has been instantiated?
it looks to me as if the engine init checks the module logger status and
sets a couple of flags _should_log_info and _should_log_debug. (I'm
guessing these are there to keep the logging function
Hi Marco,
There is a DB2 driver in the works, but I haven't heard much noise about it
lately, so I don't know what kind of progress is being made.
As for supported drivers, the three engines you mention are all supported, I
think that PG is probably has better test coverage than either Oracle or
i have non-ORM updates happening inside
ORM transaction (in after_insert() etc). How to make them use the
parent transaction? i have a connection there.
You can pass in the Session and use Session.execute() to reuse the session
connection.
--~--~-~--~~~---~--~~
in the after_*() there are (mapper, connection, instance) arguments -
but there's no session. Any way to get to that? mapext.get_session()
does not look like one
http://www.sqlalchemy.org/docs/04/sqlalchemy_orm.html#docstrings_sqlalchemy.orm_modfunc_object_session
I use a similar technique with a Pylons controller, but instead of
engine.begin(), I use session.begin(). Then by passing around the session
for all calls made by that controller, I can use Session.execute() for
expression-based and text-based SQL mixed with ORM ops, and it all commits
in one shot
The issue is that in essence, both answers are right. ANSI SQL specifies
different data types for DATE fields and DATETIME fields, where DATE fields
do not hold the time portion. Oracle, SQL Server and other database engines
have their own ideas about how best to handle dates / datetimes.
SA
I guess you know that storing the actual bytecodes (or the source) of a
Python function in the database itself is not going to buy you much:
Since the function bytecodes or source
would be in Python, only a Python interpreter could run it to produce
the function result, and if you know you're
Also depending on how you are starting the subprocess, you may have control
over open file handle inheritance. The subprocess module, for example allows
you to close all open inherited files, which would include open sockets for
DBAPI connections (or a file handle in the case of SQLite). You could
Ah good thanks: I had noticed that too and was just ignoring it until it
bugged me enough. Laziness pays off again!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email
Most database engines support a couple of SQL functions that help in cases
like this, read your database docs for either the ISNULL or the COALESCE
function.
Another technique is to use an SQL CASE statement.
For all three methods the idea is to supply a default value to substitute
when the
This is going to be messy, as the support for unicode varies among the
various MSSQL DBAPIS (which is in lart part why multiple DBAPI support is
needed by the MSSQL driver). ODBC looks to me to tell the best story:
The newer ODBC drivers have an autotranslate feature that somehow
retrieves the
One of the reasons that Query.select() is deprecated is that the way it was
named led to this kind of confusion.
The Query() class is used for ORM operations, and when it's used as mapped
against a table, it's going to give you all the columns from the table by
default. There are ways of defining
all of them? same as any Python object:
obj_attributes = [k for k in obj.__dict__]
On 11/6/07, Christophe Alexandre [EMAIL PROTECTED] wrote:
Hi,
I am also interested in retrieving all the attributes resulting from the
ORM.
The loop on '.c' will list only the database columns. Is there
Seems that when multiple mapper extensions are used, only the first is run.
Testcase attached
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to
Ah. OK, thanks!
I checked in a small update to the 3.x - 4.0 migration guide in the docs to
note this.
On 11/5/07, Michael Bayer [EMAIL PROTECTED] wrote:
you need to return EXT_CONTINUE for your TimestampExtension methods.
Rick
--~--~-~--~~~---~--~~
You
with that (also that its not trying
to make some bizarre self-referential join on the table). id
actually want to file a bug report that this didn't raise a whole
bunch of errors and alarms...
On Nov 2, 5:23 pm, Rick Morrison [EMAIL PROTECTED] wrote:
Please have a look at the attached
, and mutliple
dicts arent helping in that case anyway. keys can be placed as tuples
(such as ('myext', 'somekey')) if namespace collisions are a concern, but
that kind of thing has to be done by conventions regardless.
On Nov 1, 2007, at 10:40 AM, Rick Morrison wrote:
That sounds reasonable
Please have a look at the attached testcase that mixes single-table
polymorphic inheritance, primaryjoin overides on the relation() and a
secondary table.
SA seems to add a WHERE clause to filter for the polymorphic type on
relations that it calculates, but forgets to add it for the test case. Is
That sounds reasonable to me; my knee-jerk thought was that we might need to
worry about memory usage, but these references are only on low-count
instances like tables, columns, sessions and mappers, not ORM object
instances.
On 10/31/07, Paul Johnston [EMAIL PROTECTED] wrote:
Hi,
Ah sure,
personal opinion: I'm not wild about either 'attributes' or 'properties',
(a) they seem too long, and
(b) yes, they are too similar to generic ORM terms
many many moons ago (pre Windows-1.0) I used an Ascii-GUI thing called
C-scape (I think it's called vermont views now).
anyway, most of its
The core can (and does) use these buckets too, so I'm not sure about the
user-y moniker.
Hold it. I thought the whole point of this was to separate core usage from
user usage? To create a safe-zone for library user's private data.
But if that were it, I'd only be +1 on a spelled out
Ah sure, so it's to be a namespace for namespaces, a shared dict() parking
lot. Got it.
So then, how about
aux
etc
other
or maybe
miscdata
extra
more
additional
supplemental
auxiliary
adjunct
appendix
surplus
spare
augment
--~--~-~--~~~---~--~~
You received
If you don't want to pollute the current namespace, then make an indirect
reference.
1) Make a module of your own, say db.py
2) In db.py:
...
from sqlalchemy import *
from sqlalchemy.orm import *
...
table1 = Table('footable', ...)
...
# other
..coincidentally released on the self-same day when I am finally taking the
wraps off 0.4.0 for a spin on a new project.
Congrats on this huge release, everybody!
On 10/17/07, Michael Bayer [EMAIL PROTECTED] wrote:
Hey list -
I'm very happy to announce that we've put out 0.4.0 final.
Yes, that would be the only thing that has a hope of working across database
engines. LIMIT with UPDATE is MySQL-only AFAIK.
For SA, joins in updates can be tricky, so the correlated query would best
be a IN() or EXISTS() query that has the limit you want. To get a
deterministic set of records
BTW the assume autoincrement for integer PK behavior is a hangover from
the early days of the module, where I originally copied from the PG
module. Since PG doesn't have the funky it's ok to explicit ID insert now
mode, the problem doesn't surface there.
I think the behavior was meant more for
It's on the to-do. This would be a great place to start hacking on SA if
you're interested, it's a feature that's been requested a few times now.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To
This is Python, after all, and it would be trivial to simply put whatever
attribute you want on a Table, Column or any SA object.
SA would just need to stay out of the way and agree not to use a certain
attribute like description or userdata, or whatever.
Don't build SQL strings up from fragments that contain user input -- it's
what makes the application subject to SQL injection in the first place.
Safest would be to use a bound parameter for the literal. See here for
details:
Yes, those are called subqueries; they're fully supported by SA. Your query
above has a couple of items of note:
a) it's a correlated subquery: the inner query references items in the
outer query. (supported by SA)
b) it's a self-join: the inner query and outer query reference the same
table.
Hi Scott,
...to develop on Windows and deploy on Linux. It sounds
like pyodbc is the best option
pyodbc works well in Windows, but I've heard on Linux, not so much. pymssql
is your best bet for Linux. Note that pymssql does not work with unicode,
limits SQL identifiers to 30 characters, and
Im not sure about creation, but I've not had any problems using
cross-schema foreign keys, relations, joins and so forth using
SQLAlchemy 0.3 and PostgreSQL.
..and of course the test case I wrote up to show the problem worked fine.
Turns out the issue was in the PK declaration for the table
I think it might be more historical than anything else. Back when what is
now filter() was a single argument to the select() call, on the SQL-API
side, and there couldn't take any additional arguments, as the select() call
was already pretty heavy with keyword arguments and it was easy to get
I believe the 0.4 unit tests have profiling support, have a look there.
On 9/14/07, Hermann Himmelbauer [EMAIL PROTECTED] wrote:
Hi,
I'd like to know if there is some profiling support in SQLAlchemy. It
would be
nice if there would be some data accompanying SQL statements in the
logfiles
SA 0.3* doesn't seem to handle relationships between tables in different
schemas very well: it seems to think that
schema.A - public.B
is:
schema.A - schema.B
and even specifying primaryjoin= in the mapper won't help it. There seems
to be no directive to say use the default /
SQL Server provides no facilities for retrieving a GUID key after an insert
-- it's not a true autoincrementing key. The MSSQL driver for SA uses either
@@IDENTITY or SCOPE_IDENTITY() to retreive the most-recently inserted
autoincrement value, but there is no such facility for getting GUID keys.
You should find it at z.USER_SID after the flush.
Not sure about your save() and flush() calls howevershould be
session.save_or_update(z) and session.flush()
On 9/11/07, Lukasz Szybalski [EMAIL PROTECTED] wrote:
Hello,
I am saving to my column in this way. How do I get the primary key
there's just a few odd places, and I wonder if drop table is one of
them, resulting in the original cause of this thread.
I don't think that DROP is a special case. Look upthread. The incorrect DROP
happened in the same wrong schema as the incorrect CREATE. The problem is
that the check-table
It's for the delete (which then does not happen because the table is not
found)
Sure, but the drop is being issued in the correct default schema (dbo). The
error is not that the drop is being issued in the wrong schema, it is that
the table was *created* in the wrong schema, and so is not where
Sure, but the drop is being issued in the correct default schema (dbo).
No it's not. If I don't enable checkfirst the table is dropped, which
means both statements are issued on the wrong schema (considering that
the check is right).
Ah OK I didn't get that from the previous
messages. Then it
Should ansisql recognize and use default schemas,
or should the DB dialect somehow override the construction of the table
name?
The more I think about this, the more I'm becoming convinced that specifying
an implicit default schema in all generated SQL is a pretty bad idea. The
reason is that
That SQL log is from the table existence check.
Although it's unclear from the trace and log as to whether the check
is for the table create or for the table drop, it is correctly using
the default schema, which is 'dbo' on all MSSQL platforms.
So, the table check and the drop are working
It's an SQLite-ism. See the recent thread on the type system. I've had
exactly this issue with SQLite vs. MSSQL.
On 8/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
i'm Wondering if all the unicode strings (at least table/column
names) should be converted back into plain strings as they
but it would be more sane
if power(connect_args) = power(url_args), that is, connect_args is
the more general/powerful/ way, and url allows a subset (or all) of
connect_args items; and not vice versa -- connect_args is the
programatical way, so that should do _everything_..
If we ever get
FYI I believe there is a ticket to make improvements in the type system that
would allow strings to be given as date input (among other conveniences),
and I don't think it's a bad thing. Lots of databases make the conversion
anyway, and it's ultimately pretty confusing thing to have various
I think there's something a little simpler we need - some
documentation. For all the SA types we should document the type that
convert_result_value returns, and that convert_bind_param expects, and
check that all the DBAPIs stick to this (probably with unit tests). I'm
pretty sure there's
Yeah of course date formats vary, it's one of the trickier issues in type
adaption, can be computationally expensive, etc. A full-on date
parser is probably just way out of scope for SA (the excellent
dateutil package already
handles it pretty well). I'm of the opinion that it would not be so
MSSQL is case-sensitive, and wants to see queries to INFORMATION_SCHEMA in
UPPER CASE.
See mssql.py.uppercase_table() for the gory details, or rather, THE GORY
DETAILS ;-)
On 7/27/07, Christophe de VIENNE [EMAIL PROTECTED] wrote:
Hi svil,
Still no luck. I don't know if the
you may do better to focus your efforts on getting PyODBC working better
on Unix.
Agreed here. One stable and supportable DBAPI for MSSQL would be really
nice.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
I'm going to reply here, as I can't seem to login to trac again. I did
manage to get comments in for #685
#679 - committed in r3050
#684 - committed in r3051
#685 - needs more discussion see the Trac comments
Thanks for the patches!
Rick
On 7/26/07, Christophe de VIENNE [EMAIL PROTECTED]
what needs to be modified?
can it be done by a src-patch? maybe i can apply it runtime (;-)
I think the patch has been out for a few weeks now, so it will likely be in
the next release of pyodbc.
There is also an easy workaround, pass use_scope_identity = False to the
Engine ctor, and it
Thanks for having a look at the tests, Christophe.
Responses below:
The reason is that MSSQLDialect.get_default_schema_name takes no
argument, while the unittext gives it an engine. The Mssql dialect,
for example, does take an argument.
It looks to me like get_default_schema_name() has
The dependancy chains looks like this (more or less):
pymssql == DBlib == FreeTDS == wire
pyodbc (Unix) == iodbc / unixodbc == FreeTDS == wire
pyodbc (Win) == ms-odbc == OLEdb == wire
The unicode problem for pymssql is in DBlib, not FreeTDS
Rick
On 7/26/07, Christophe de VIENNE [EMAIL
The list is useful only for a hacker on the MSSQL module, not for general
users, but FWIW, I've added it to
http://www.sqlalchemy.org/trac/wiki/DatabaseNotes
I generally try to respond directly to help encourage anyone willing to
offer a hand on the MSSQL module, as I don't have the time these
ugh...i was so happy that Dialect could be written with normal
keyword arguments.while i want comprehensive, i didnt
necessarily want to require a getopt layer for every dialect (as
well as every Engine class, every Pool class, etc).
Well the enumeration of the options targeted for a
Sorry about the sporadic posts, I'm travelling
if we are going whole hog with query strings (basically we're talking
about adding pool options mostly), a comprehensive solution needs to
be added in DefaultEngineStrategy.
All that sounds fine, if Paul is still interested, I'll work with him on
On 7/8/07, Michael Bayer [EMAIL PROTECTED] wrote:
thats ugly to me. if you know your DBAPI uses a certain argument,
you should be able to just pass it through. similarly i dont want
SA's args with some ugly prefix. prefixing is just a hack for
something this fundamental.
Well the DBAPI
Updates and inserts on the ORM side of the street are single-object kinds of
things. The pattern is to load a list of objects, make the appropriate
modifications to the those in-memory objects, and then issue a session
flush().
This type of
bulk operation is best done with the SQL generation
The SA MSSQL module currently supports the three DBAPI modules mentioned
above (pyodbc, pymssql, adodbapi).
You'll need to either get one of those three to import under IronPython, or
add support for the IPCE adaptor.
On 6/20/07, d_henderson [EMAIL PROTECTED] wrote:
I recently tried SA
Sounds like the invalid cursor state bug that I thought might have been
fixed for pyodbc in r2729. Maybe not...
Try adding the keyword parameter
use_scope_identity = False
to the create_engine() call and see if that clears it up.
On 6/15/07, che [EMAIL PROTECTED] wrote:
forgot to
Just tried it here on a Linux + pymssql box and it worked fine.
The 'NoSuchTable' error would indicate that the table is not found, as you
surmised. Check to make sure the table is really persisting after your first
session with the table create. In the meantime, I'll see if I can get
pymssql
Works in Windows, too, sqlalchemy 0.3.8, Python 2.5, pymssql 0.8.0, MSSQL
2005
Try upgrading your pymssql if you're not at 0.8.0. If that won't work, then
I would suggest a switch to pyodbc
Rick
On 6/12/07, one.person [EMAIL PROTECTED] wrote:
one.person
View profile
More
That looks OK to me.
Try pasting that query (cleaned-up) into a query window on Enterprise
Manager and see what kind of results you get. The ? arguments are
positional, so the first would be the table 'zone'; the second the schema
'dbo'.
On 6/12/07, one.person [EMAIL PROTECTED] wrote:
try:
t.commit()
except:
print 'Holy cow, this database is lame'
On 6/8/07, Andreas Jung [EMAIL PROTECTED] wrote:
is there a way to determine if the underlying MySQL DB is able to perform
a commit() operation? The following code fails (likely because the
underlying MySQL db is pretty
Well it's not so evil if all you're doing is testing to see if commit() is
available -- I wasn't trying to suggest that it was a great pattern for your
whole application.
On 6/8/07, Andreas Jung [EMAIL PROTECTED] wrote:
--On 8. Juni 2007 14:05:39 -0400 Rick Morrison [EMAIL PROTECTED]
wrote
] wrote:
Hi,
If you could mail the output off list to both myself and Rick Morrison,
that would be magic.
Well, the summary is: FAILED (failures=20, errors=245)
Looks like making this solid on Unix would be a mammoth task. Not one
I'm prepared to take up at the moment, being mostly
MSSQL has a history of confusion about what is owner and what is schema,
and there has been shifting back and forth over the years as they tried to
decide if they wanted to be like Oracle, or like Sybase.
Recently the 2005 version added real schemas as well, so a table
identifier can I believe
Beyond the API littering, there may be instances where it is difficult or
impossible to remove a query attribute, because adding the attribute caused
a join calculation or reordered parenthesis, or whatever.
The second pattern is better, e.g. save a copy, rather than mucking things
up with
Yeah, I'm +1 on .where() as well.
On 6/6/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 5, 2007, at 10:30 PM, Mike Orr wrote:
I do think .append_whereclause should be changed to .append_to_where.
A SQL statement can have only one WHERE clause; what you're actually
appending is an
I'm interested in the results too, as well as the ODBC config. I'm still in
the process of setting up a buildbot slave on Ubuntu that's going to be
running pyodbc as well. I normally use pymssql, and it'll be my first
serious go with pyodbc.
If it's OK with the list, maybe you can post the
. that of labels...its because of some issues
that arise with some auto-labeling that happens inside of
ansisql.pyso its fortunate i dont have to get into that.
On May 1, 2007, at 12:57 PM, Rick Morrison wrote:
The underlying DBlib limits *all* identifier names, including
column names to 30
I don't think so, not directly.
Short-term, here's a couple of things to try:
-- you may be able to create views in the local database that reference the
warehouse tables, and access these views as if they were local tables.
-- you may be able to hack up something by using the schema support in
it through pyodbc with a hard-coded string, and if that
works, then along
with the owner construct, it should just a few tweaks to MSSQL dialect.
On 6/5/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 5, 2007, at 4:05 PM, Rick Morrison wrote:
I don't think so, not directly.
Short-term
The use of scalar() here seems out of place with both the common CS usage of
the word (e.g. scalar == single-valued), and the use of scalar() in the SQL
layer. Single row results in the ORM are rows, not a single datatype. It's
another potential point of confusion, like the ORM .select() is/was.
:
On Jun 4, 2007, at 9:56 AM, Rick Morrison wrote:
The use of scalar() here seems out of place with both the common CS
usage of the word (e.g. scalar == single-valued), and the use of
scalar() in the SQL layer. Single row results in the ORM are rows,
not a single datatype. It's another potential
Bayer [EMAIL PROTECTED] wrote:
On Jun 4, 2007, at 9:56 AM, Rick Morrison wrote:
The use of scalar() here seems out of place with both the common CS
usage of the word (e.g. scalar == single-valued), and the use of
scalar() in the SQL layer. Single row results in the ORM are rows
That's one of the reasons I prefer to treat Query() like an iterator and
roll my own first-order functions like first() etc. -- see my other
message regarding this.
On 6/4/07, Mike Orr [EMAIL PROTECTED] wrote:
On 6/4/07, Rick Morrison [EMAIL PROTECTED] wrote:
The use of scalar() here
Isn't this the very thing that the session / UOW constructs are supposed to
address for case #1?
This can all break in a web application that doesn't want to maintain any
in-memory state at all -- for those you can serialize via
pickle/JSON/whatever the objects being manipulated and hold them in
Hi Jim,
The autoload feature for SQLAlchemy sometimes guesses wrong about
auto-sequenced columns. Check that your users.user_id column has an
auto-generating key (IOW, is it of type IDENTITY)?
If so, please post your version of MSSQL and pyodbc. IDENTITY insert for
MSSQL columns has recently
Hey Mike,
I've really gotten to like the generative style of query building that the
ORM layer uses, and
I find myself developing a number of patterns that use that style to
good advantage.
Today I found myself struggling with a query in the low-level SQL-API layer
that the generative approach
, 2007, at 11:43 AM, Rick Morrison wrote:
Hi Mike,
Pursuant to our discussion on another thread regarding buildbots, I've got
a preliminary buildbot slave VM set up as follows:
Ubuntu 6.10
VMware tools
Python 2.4
Buildbot 0.7.4
Postgres 8.2.2
MySQL 5.0.37
Sqlite 3.3.17 (also known
s/DBAPI/DBlib/
On 5/1/07, Rick Morrison [EMAIL PROTECTED] wrote:
The label-truncation code is fine. The issue isn't SA. It's the DBAPI that
pymssql rides on top of...identifier limit is 30
chars, is deprecated by Microsoft, it will never be fixed.
Try pyodbc, which has no such limitation
The underlying DBlib limits *all* identifier names, including column names
to 30 chars anyway, so no issue there.
Where does the character limit go in the dialect? Can I follow Oracle as an
example?
On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
On May 1, 2007, at 11:18 AM, Rick
I wouldn't think that pysqlite being installed on the master is an issue:
the tests would be run on the slave and in the slave environment.
I think that Skip's sqlite issue is more likely one of:
a) using the included pysqlite in Python 2.5+ and issues with that
or
! :-)
Paul
Rick Morrison wrote:
.3.6 was stable (at least for me).
One of the issues to address is going to be the multi-DBAPI support.
Keeping all three stable at the same time can be tough. So starting
.3.7, making pyodbc the only supported configuration is OK with me,
although
, this would also depend on some ODBC provider on Unix like
unixodbc/iodbc/some commercial stack.
Rick
On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote:
On May 1, 2007, at 4:17 PM, Rick Morrison wrote:
The 0.3.7 bug is my fault, I checked in the changes without testing
on pyodbc. Didn't know
Hey where are we with this? Does #476 fix #545, or are they unrelated? What
is the current behavior in 0.3.7 with an empty IN() list?
On 4/21/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 13, 2007, at 4:17 PM, Ants Aasma wrote:
I'll try to create a test suite for it next week, I
Hi Mike,
Pursuant to our discussion on another thread regarding buildbots, I've got a
preliminary buildbot slave VM set up as follows:
Ubuntu 6.10
VMware tools
Python 2.4
Buildbot 0.7.4
Postgres 8.2.2
MySQL 5.0.37
Sqlite 3.3.17 (also known as version du semaine these days...)
FreeTDS / UnixODBC
Done in rev #2577
On 4/16/07, Rick Morrison [EMAIL PROTECTED] wrote:
Unless there's any objections, I think it's time to make pyodbc the
preferred access method for MSSQL.
Currently the MSSQL module checks for DBAPI interfaces in this order if
one isn't specified explicitly:
adodbapi
] wrote:
On Apr 26, 2007, at 6:31 PM, Rick Morrison wrote:
Sounds like a great idea -- is there an existing buildbot master to
tie into, or will the whole thing be new?
well my limited understanding of buildbots says that we would need to
make one that responds to SQLAlchemy version
only like four tests that don't
pass now, and I would wager those are because of database feature issues,
not overt bugs. Maybe it's time to start putting MSSQL on the regular test
rotation.
On 4/26/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 26, 2007, at 5:53 PM, Rick Morrison wrote
Sounds like a great idea -- is there an existing buildbot master to tie
into, or will the whole thing be new?
On 4/26/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 26, 2007, at 6:15 PM, Rick Morrison wrote:
.3.6 was stable (at least for me).
One of the issues to address is going
It sounds like its getting to be time to make pyodbc the preferred DBAPI
interface for MSSQL. I'll start a new thread to see if there's any
objections.
On 4/16/07, Victor Ng [EMAIL PROTECTED] wrote:
Sweet! This seems to work well now.
Is there a way I can update the documentation for the
Unless there's any objections, I think it's time to make pyodbc the
preferred access method for MSSQL.
Currently the MSSQL module checks for DBAPI interfaces in this order if one
isn't specified explicitly:
adodbapi
pymssql
pyodbc
I'd like to change it to the exact opposite:
pyodbc
...and while I'm making this thread unnecessarily long, I should add that
while pymssql may not understand Unicode data, the pyodbc DB-API interface
does. Thanks to recent work by Paul Johnston, it's on fast-track to becoming
the preferred MSSQL db-api for SA.
On 4/10/07, Rick Morrison [EMAIL
Last I heard, pyodbc was working on any POSIX system that supports odbc
(most likely via unixodbc or iodbc)
http://sourceforge.net/projects/pyodbc/
-- check out the supported platforms
On 4/11/07, Marco Mariani [EMAIL PROTECTED] wrote:
Rick Morrison wrote:
...and while I'm making
I've noticed that if you specify a primaryjoin criteria for a mapper
relationship, SA automatically aliases the table/column names when doing an
eager load of that relationship.
But this doesn't seem to work if within that primary join, a column is
referenced inside of a .func; SA leaves the
201 - 300 of 359 matches
Mail list logo
