Rick Morrison wrote:
Sounds nice, thanks for the heads-up.
There'll be opportunities for dialects to set up pool events as well.
One of the things I'm looking to see is better reconnect support for
dead database connections from network partitions, sql server restarts,
etc.
Is
I was thinking of a user-level option for liveliness checking on pool
checkout, with dialect-specific implementations (e.g. execute a 'SELECT
1', or something more efficient if the driver allows). Is that in line
with what you were thinking?
I had in mind something more of a optimistic /
Rick Morrison wrote:
I was thinking of a user-level option for liveliness checking on pool
checkout, with dialect-specific implementations (e.g. execute a 'SELECT
1', or something more efficient if the driver allows). Is that in line
with what you were thinking?
I had
On Tue, Apr 22, 2008 at 9:35 AM, Lukasz Szybalski [EMAIL PROTECTED] wrote:
e = sqlalchemy.create_engine(mssql://xxx:[EMAIL
PROTECTED]:1433/xx?driver=TDSodbc_options='TDS_Version=8.0')
here is a patch to mssql.py that makes above line work.
805c805,808
There's a Dialect refactor underway for 0.5.0 that will likely change the
way that options are fed to db engines:
http://groups.google.com/group/sqlalchemy/browse_thread/thread/36fd2e935b165d70
Part of that work will probably have some influence on the dburi and
create_engine(**kwargs) option
Rick Morrison wrote:
There's a Dialect refactor underway for 0.5.0 that will likely change
the way that options are fed to db engines:
Currently the munging of url params and connect_args into a connect()
lambda is happening outside of the dialect's control. In 0.5 that's all
moving into
Sounds nice, thanks for the heads-up.
There'll be opportunities for dialects to set up pool events as well.
One of the things I'm looking to see is better reconnect support for dead
database connections from network partitions, sql server restarts, etc.
Is that going to be fully Dialect
Look, relax:
No one is suggesting that we *eliminate* DSN-less connections, only to come
up with a reasonable *default* for ODBC connection specifications. A
mechanism for non-DSN connections will certainly be provided.
Well,
Based on :
http://www.4guysfromrolla.com/webtech/070399-1.shtml
e = sqlalchemy.create_engine(mssql://xxx:[EMAIL
PROTECTED]:1433/xx?driver=TDSodbc_options='TDS_Version=8.0')
here is a patch to mssql.py that makes above line work.
805c805,808
connectors.append(keys.pop('odbc_options'))
---
odbc_options=keys.pop('odbc_options')
Reading this thread, I keep wondering why you are trying to put
all that connection setup configuration into the connection string...
Such setting are normally configured in the odbc.ini file and then
you just reference data source name in the connection string.
That's the standard way of
Rick Morrison wrote:
Yeah, I was under the impression that config args passed in via
create_engine() ctor and via dburi were treated the same, but looking
over engine/strategies.py, it looks as if they have two separate
injection points. I'll see if I can get it to allow either, stay
hey thanks Jason, that's a nice shortcut.
Lukasz, can you please give that a try?
On Fri, Apr 18, 2008 at 12:07 PM, jason kirtland [EMAIL PROTECTED]
wrote:
Rick Morrison wrote:
Yeah, I was under the impression that config args passed in via
create_engine() ctor and via dburi were treated
Yeah, I was under the impression that config args passed in via
create_engine() ctor and via dburi were treated the same, but looking over
engine/strategies.py, it looks as if they have two separate injection
points. I'll see if I can get it to allow either, stay tuned.
On Thu, Apr 17, 2008 at
On Fri, Apr 18, 2008 at 11:07 AM, jason kirtland [EMAIL PROTECTED] wrote:
Rick Morrison wrote:
Yeah, I was under the impression that config args passed in via
create_engine() ctor and via dburi were treated the same, but looking
over engine/strategies.py, it looks as if they have two
On Fri, Apr 18, 2008 at 1:36 PM, Rick Morrison [EMAIL PROTECTED] wrote:
Err, on a second look, that's no good. The connect_args are passed directly
through to connect().
This thing needs to construct an ODBC connection string from some fragments
provided by the dburi, and from some engine
nope. Seems like the SQLA connection is still not using the
appropriate magical incantation to get all that ODBC stuff to behave
reasonably.
might I suggest just circumventing the URL entirely and just using
creator=lambda:
pyodbc
.connect
(DRIVER
On Mon, Apr 7, 2008 at 4:37 PM, Rick Morrison [EMAIL PROTECTED] wrote:
The limitation here I guess is 30 char identifier limit but I will
need to test it.
Ah yeah, you're going to have bigger problems than 30 char identifiers with
the Sybase TDS settings. MSSQL uses a different set of
On Thu, Apr 17, 2008 at 10:02 AM, Lukasz Szybalski [EMAIL PROTECTED] wrote:
On Mon, Apr 7, 2008 at 4:37 PM, Rick Morrison [EMAIL PROTECTED] wrote:
The limitation here I guess is 30 char identifier limit but I will
need to test it.
Ah yeah, you're going to have bigger problems
Here are the options as specified by free TDS. What you are talking
about is setting it in conf file which is used only for dsn
connection.
No, I meant as the *default* TDS version here. See here:
http://www.freetds.org/userguide/freetdsconf.htm
I'm talking about the [global] setting,
On Thu, Apr 17, 2008 at 12:14 PM, Rick Morrison [EMAIL PROTECTED] wrote:
Here are the options as specified by free TDS. What you are talking
about is setting it in conf file which is used only for dsn
connection.
No, I meant as the *default* TDS version here. See here:
ok, ok, assuming that dsn-less connections actually do ignore the .conf file
and require all that stuff to be specified.
here's the question that I'm trying to ask:
instead of something like this:
create_engine('mssql://user:[EMAIL PROTECTED]/database',
odbc_driver='TDS',
It's in trunk r4518. Take 'er for a spin and let me know how it works out.
On Thu, Apr 17, 2008 at 2:54 PM, Lukasz Szybalski [EMAIL PROTECTED]
wrote:
On Thu, Apr 17, 2008 at 1:22 PM, Rick Morrison [EMAIL PROTECTED]
wrote:
ok, ok, assuming that dsn-less connections actually do ignore the
On Thu, Apr 17, 2008 at 2:07 PM, Rick Morrison [EMAIL PROTECTED] wrote:
It's in trunk r4518. Take 'er for a spin and let me know how it works out.
got an error:
e = sqlalchemy.create_engine('mssql://xxx:[EMAIL
PROTECTED]:1433/',odbc_options='DRIVER={TDS};TDS_Version=8.0')
Traceback (most
Does it matter what case are the parameters? DRIVER in pyodbc, we used
'driver' in previous connection strings etc...
No the parameters are a straight pass-through, that traceback is complaining
about the 'odbc_options' keyword itself. Are you sure you're running the
current trunk?
On Thu, Apr 17, 2008 at 2:35 PM, Rick Morrison [EMAIL PROTECTED] wrote:
Does it matter what case are the parameters? DRIVER in pyodbc, we used
'driver' in previous connection strings etc...
No the parameters are a straight pass-through, that traceback is complaining
about the
It's a two-line change that pops the new keyword out of the config dict just
like the others that were added.
Mike, can you take a quick look at mssql.py line 804 and see why this might
be complaining? I've got to run out.
On Thu, Apr 17, 2008 at 3:58 PM, Lukasz Szybalski [EMAIL PROTECTED]
On Thu, Apr 17, 2008 at 3:04 PM, Rick Morrison [EMAIL PROTECTED] wrote:
It's a two-line change that pops the new keyword out of the config dict just
like the others that were added.
Mike, can you take a quick look at mssql.py line 804 and see why this might
be complaining? I've got to run
The limitation here I guess is 30 char identifier limit but I will
need to test it.
Ah yeah, you're going to have bigger problems than 30 char identifiers with
the Sybase TDS settings. MSSQL uses a different set of wire-protocol
representations of datetime types, and your dates are going to be
also of concern is that, nobodys ever going to know they need to use this
parameter when this issue arises.
Well the idea is that this is a workaround for what I suspect is a broken
Unix + pyodbc configuration, not a long-term solution.
its only because I narrowed the issue down to where I knew
you can mix both freely. any class that has max_identifier_length on it,
if you set self.max_identifier_length, that overrides it.
Oh ok, nice.
Alright, this is in trunk r4429 as a keyword parameter named
max_identifier_length
Lukasz: to use it, add the max_identifier_length as a keyword to
On Wed, Apr 2, 2008 at 6:22 PM, Rick Morrison [EMAIL PROTECTED] wrote:
also of concern is that, nobodys ever going to know they need to use this
parameter when this issue arises.
Well the idea is that this is a workaround for what I suspect is a broken
Unix + pyodbc configuration, not a
On Apr 2, 2008, at 7:06 PM, Rick Morrison wrote:
you can mix both freely. any class that has max_identifier_length
on it, if you set self.max_identifier_length, that overrides it.
Oh ok, nice.
Alright, this is in trunk r4429 as a keyword parameter named
max_identifier_length
So how would I find out if this is pyodbc or unixodbc?
On Unix, it's both.
pyodbc is the Python DB-API module that provides the DB-API2 interface for
sqlalchemy it in turn relies on an underlying ODBC layer.
unixodbc is the ODBC-for-Unix implementation that provides an ODBC interface
(the ODBC
On Apr 2, 2008, at 7:22 PM, Rick Morrison wrote:
hey not to be impolite, but I burned a little oil on this one too,
ya know.
absolutely ! oil burned all around.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
On Wed, Apr 2, 2008 at 6:35 PM, Rick Morrison [EMAIL PROTECTED] wrote:
So how would I find out if this is pyodbc or unixodbc?
On Unix, it's both.
pyodbc is the Python DB-API module that provides the DB-API2 interface for
sqlalchemy it in turn relies on an underlying ODBC layer.
unixodbc
35 matches
Mail list logo
