[sqlalchemy] Re: sqlalchemy migration/schema creation
On Thursday 17 April 2008 00:07:28 Lukasz Szybalski wrote: On Wed, Apr 16, 2008 at 1:03 AM, [EMAIL PROTECTED] wrote: a separate feature - no. but it's not much to do it. here my attempt at this. try copyall or copydata+autoload from here: svn co http://dbcook.svn.sourceforge.net/dbcook/trunk/dbcook/misc/metadata/ At which point here is the table created in dst database? metadata = autoloader.metadata() here you get the src metadata about tables?!! yes dst_engine= sqlalchemy.create_engine( dbdst) Here you change the engine?? metadata.bind = dst_engine This will create tables from the first line statement? metadata.create_all() yes, create all stuff autoloaded from src, but into dbdst (using dst_engine). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] To select a tree with PG connectby() in a single request
Hi all,
I'm trying to load a whole Tree of Account objects (Mapped instances)
in a single SELECT with unlimited depth.
I'm using PostgreSQL connectby function from the tablefunc module.
It returns rows of each nodes in a depth first visit.
sql =
SELECT acc_accounts.* FROM connectby('acc_accounts', 'account_id',
'parent_id', 'name', '%s', 0)
AS t(keyid int, parent_keyid int, level int, name int),
acc_accounts where keyid = account_id
accounts = Session.query(Account).from_statement(sql %
root_account_id).all()
After that, I try so iterate over the result list in order to set the
account.children relation myself.
But the problem is that as soon as I initialize the relation, a SQL
select is issued:
account.children = []
How can I avoid these unnecessary selects on all nodes?
Is there a better way to let SA populate the relation with the rows
returned?
Thanks for help.
jean-philippe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Sqlautocode error
Hi I'm trying to use this Sqlalchemy exstension ( http://code.google.com/p/sqlautocode/ ) to auto import a model from a legacy database. While I tried runtime reflection, I was thinking to avoid it to have a static defined model. I found this tool to automate this, but it gives me an error and I don't understand it. Here is how i launch it python autocode.py postgres://user:[EMAIL PROTECTED]/dbname -o model.py and here is what I get Starting... Traceback (most recent call last): File autocode.py, line 4, in module sqlautocode.main() File /home/taglia/Desktop/sqlautocode-0.5.1/sqlautocode/ __init__.py, line 19, in main reflection_schema = db.dialect.get_default_schema_name(db) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.4.5-py2.5.egg/ sqlalchemy/engine/base.py, line 1885, in decorated return connection.info[key] AttributeError: 'Engine' object has no attribute 'info' I'm using Autocode-0.5.1 and SQLAlchemy-0.4.5 Thank you --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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 wire-protocol
representations of datetime types, and your dates are going to be off.
In order to use more characters the FreeTDS should be configured to
use TDS protocol 7.0 which:
Even that one is old: MSSQL switched to TDSv7 back in MSSQL 7.0 (circa 1997)
They're now on TDSv8 as of MSSQL-2000
Here's a chart:
http://www.freetds.org/tds.html
It beats me why FreeTDS still defaults to Sybase instead of MSSQL, the
installed base has to run at least 100 to 1 in favor of MSSQL. Oh well.
When you get all this set up correctly, you may want to update the
sqlalchemy wiki with all this stuff.
What I have found out is that in dsn less connection is not going
through the freetds.conf.
So me settings things there has no point.
So the way we passed DRIVER={TDS} I would also have to pass TDS_Version
cnxn = pyodbc.connect(SERVER=xxx;UID=xxx;PWD=xxx;DRIVER={TDS};TDS_Version=7.0)
this actually returns results that are longer then 30.
Lucas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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 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 off.
In order to use more characters the FreeTDS should be configured to
use TDS protocol 7.0 which:
Even that one is old: MSSQL switched to TDSv7 back in MSSQL 7.0 (circa
1997)
They're now on TDSv8 as of MSSQL-2000
Here's a chart:
http://www.freetds.org/tds.html
It beats me why FreeTDS still defaults to Sybase instead of MSSQL, the
installed base has to run at least 100 to 1 in favor of MSSQL. Oh well.
When you get all this set up correctly, you may want to update the
sqlalchemy wiki with all this stuff.
What I have found out is that in dsn less connection is not going
through the freetds.conf.
So me settings things there has no point.
So the way we passed DRIVER={TDS} I would also have to pass TDS_Version
cnxn =
pyodbc.connect(SERVER=xxx;UID=xxx;PWD=xxx;DRIVER={TDS};TDS_Version=7.0)
this actually returns results that are longer then 30.
Lucas
On Thu, Apr 17, 2008 at 11:09 AM, Rick Morrison [EMAIL PROTECTED] wrote:
Two points:
- Unless you're running Sybase, it's possible to set the default TDS version
in the TDS config file, which would eliminate the need for this.
- The end point of all of these parms is to simply build an ODBC connection
string. Wouldn't a parm that just allowed the specification of the string
as-is be just as useful but a lot more flexible/simpler?
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.
pyodbc takes this TDS_Version parameter with no problems.
here is what freetds said:
to use TDS 7.0 in a DSN-less connection, your options are:
1. Rebuild FreeTDS --with-tdsver=7.0, or
2. Set the environment variable TDSVER=7.0 before starting Python, or
3. Add TDS_Version=7.0; to your connection string.
4. Use Servername in your connection string.
options 3 seems the easies to me.
Let me know
Lucas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: sqlalchemy migration/schema creation
On Thursday 17 April 2008 18:27:22 Lukasz Szybalski wrote: On Thu, Apr 17, 2008 at 3:51 AM, [EMAIL PROTECTED] wrote: On Thursday 17 April 2008 00:07:28 Lukasz Szybalski wrote: On Wed, Apr 16, 2008 at 1:03 AM, [EMAIL PROTECTED] wrote: a separate feature - no. but it's not much to do it. here my attempt at this. try copyall or copydata+autoload from here: svn co http://dbcook.svn.sourceforge.net/dbcook/trunk/dbcook/misc/metada ta/ At which point here is the table created in dst database? metadata = autoloader.metadata() here you get the src metadata about tables?!! yes dst_engine= sqlalchemy.create_engine( dbdst) Here you change the engine?? metadata.bind = dst_engine This will create tables from the first line statement? metadata.create_all() yes, create all stuff autoloaded from src, but into dbdst (using dst_engine). Have you ever tried this with mssql to mysql? Any potential problems? never tried mysql. apart of naming.. and some weird type.. what else can go wrong? just try and tell us how it goes... mysql to whatever may need additional stuff in Autoload, e.g. for indexes if u want them too. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Sqlautocode error
u may also look at svn co http://dbcook.svn.sourceforge.net/dbcook/trunk/dbcook/misc/metadata/ run autoload.py dburl YMMV On Thursday 17 April 2008 17:40:02 Vortexmind wrote: Hi I'm trying to use this Sqlalchemy exstension ( http://code.google.com/p/sqlautocode/ ) to auto import a model from a legacy database. While I tried runtime reflection, I was thinking to avoid it to have a static defined model. I found this tool to automate this, but it gives me an error and I don't understand it. Here is how i launch it python autocode.py postgres://user:[EMAIL PROTECTED]/dbname -o model.py and here is what I get Starting... Traceback (most recent call last): File autocode.py, line 4, in module sqlautocode.main() File /home/taglia/Desktop/sqlautocode-0.5.1/sqlautocode/ __init__.py, line 19, in main reflection_schema = db.dialect.get_default_schema_name(db) File /usr/lib/python2.5/site-packages/SQLAlchemy-0.4.5-py2.5.egg/ sqlalchemy/engine/base.py, line 1885, in decorated return connection.info[key] AttributeError: 'Engine' object has no attribute 'info' I'm using Autocode-0.5.1 and SQLAlchemy-0.4.5 Thank you --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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, which is the default used unless overridden in a different [dataserver] config. here is what freetds said: to use TDS 7.0 in a DSN-less connection, your options are: 1. Rebuild FreeTDS --with-tdsver=7.0, or 2. Set the environment variable TDSVER=7.0 before starting Python, or 3. Add TDS_Version=7.0; to your connection string. 4. Use Servername in your connection string. or 5. Change the default version to the desired version options 3 seems the easies to me. OK. I'm just suggesting that if you'd rather specify the version in the dburi instead of changing it on the server, that we allow the specification of the ODBC connect string directly, rather than provide a bunch of separate parameters that are in turn only used to build an ODBC connection string anyway. Finally, as I mentioned in an earlier thread, you should most likely be using TDS version 8.0, not 7.0. 7.0 is for SQL Server 7, 8.0 is for SQL Server 2000 and 2005 Rick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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:
http://www.freetds.org/userguide/freetdsconf.htm
The way I read the comment from freetds
http://lists.ibiblio.org/pipermail/freetds/2008q2/023126.html
connection string:
cnxn = pyodbc.connect(SERVER=xxx;UID=xxx;PWD=xxx;DRIVER={TDS};TDS_Version=7.0)
Connecting this way does not read the freetds.conf, it goes directly
to the driver.
I'm talking about the [global] setting, which is the default used unless
overridden in a different [dataserver] config.
I have changed it in the global settings and it made no difference. It
was only when I emailed them I have found out that the way we connect
is not using freetds.conf. So in order to get the higher version I
would have to recompile freetds.
here is what freetds said:
to use TDS 7.0 in a DSN-less connection, your options are:
1. Rebuild FreeTDS --with-tdsver=7.0, or
2. Set the environment variable TDSVER=7.0 before starting Python, or
3. Add TDS_Version=7.0; to your connection string.
4. Use Servername in your connection string.
or 5. Change the default version to the desired version
Not if you use direct connection. It would if we used ?dsn=
OK. I'm just suggesting that if you'd rather specify the version in the
dburi instead of changing it on the server, that we allow the specification
of the ODBC connect string directly, rather than provide a bunch of separate
parameters that are in turn only used to build an ODBC connection string
anyway.
I don't see an easy option to change it. If it was as easy as changing
freetds.conf then I would do it, but its not.
Finally, as I mentioned in an earlier thread, you should most likely be
using TDS version 8.0, not 7.0.
Thanks,
I'll use 8.0
Lucas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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', odbc_autotranslate='No', odbc_tds_ver='8.0')
how about this:
create_engine('mssql://user:[EMAIL PROTECTED]/database',
odbc_connect='DRIVER=TDS; TDS_Version=8.0; OtherODBCStuff=goes here')
do you see the difference? Instead of providing a hundred and one
ODBC-specific keyword options, we just allow you to specify part of the ODBC
connect string directly.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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 .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', odbc_autotranslate='No', odbc_tds_ver='8.0')
how about this:
create_engine('mssql://user:[EMAIL PROTECTED]/database',
odbc_connect='DRIVER=TDS; TDS_Version=8.0; OtherODBCStuff=goes here')
how about:
odbc_options='DRIVER=TDS; TDS_Version=8.0; OtherODBCStuff=goes here'
do you see the difference? Instead of providing a hundred and one
ODBC-specific keyword options, we just allow you to specify part of the
ODBC
connect string directly.
This would be perfect, since who knows what other options might need
to be specified as things progress.
Let me know when I would be able to try this out.
Lucas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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 recent call last):
File stdin, line 1, in ?
File sqlalchemy/engine/__init__.py, line 160, in create_engine
return strategy.create(*args, **kwargs)
File sqlalchemy/engine/strategies.py, line 114, in create
raise TypeError(
TypeError: Invalid argument(s) 'odbc_options' sent to create_engine(),
using configuration MSSQLDialect_pyodbc/QueuePool/Engine. Please
check that the keyword arguments are appropriate for this combination
of components.
Does it matter what case are the parameters? DRIVER in pyodbc, we used
'driver' in previous connection strings etc...
Lucas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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 'odbc_options' keyword itself. Are you sure you're running the
current trunk?
svn update
At revision 4518.
[EMAIL PROTECTED]:~/tmp/sqlalchemy/sqlalchemy/lib$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type help, copyright, credits or license for more information.
import sqlalchemy
sqlalchemy.__version__
'svn'
e = sqlalchemy.create_engine('mssql://xxx:[EMAIL
PROTECTED]:1433/xxx',odbc_options='DRIVER={TDS};TDS_Version=8.0')
Traceback (most recent call last):
File stdin, line 1, in ?
File sqlalchemy/engine/__init__.py, line 160, in create_engine
return strategy.create(*args, **kwargs)
File sqlalchemy/engine/strategies.py, line 114, in create
raise TypeError(
TypeError: Invalid argument(s) 'odbc_options' sent to create_engine(),
using configuration MSSQLDialect_pyodbc/QueuePool/Engine. Please
check that the keyword arguments are appropriate for this combination
of components.
not sure why strategies.py would complain?
Are you converting:
'mssql://xxx:[EMAIL
PROTECTED]:1433/xxx',odbc_options='DRIVER={TDS};TDS_Version=8.0'
to
SERVER=xxx;UID=xx;PWD=xxx;DRIVER={TDS};TDS_Version=7.0
I have added the print line that we had used before that outputs the
connection string:
import sqlalchemy
e = sqlalchemy.create_engine('mssql://xx:[EMAIL
PROTECTED]:1433/xxx',odbc_options='Driver=TDS;TDS_Version=8.0')
DRIVER={SQL Server};Server=xxx;Database=xxx;Port=1433;UID=xxx;PWD=xxx
The driver is not changed and tds_version is not added
Lucas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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]
wrote:
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 'odbc_options' keyword itself. Are you sure you're running the
current trunk?
svn update
At revision 4518.
[EMAIL PROTECTED]:~/tmp/sqlalchemy/sqlalchemy/lib$ python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type help, copyright, credits or license for more information.
import sqlalchemy
sqlalchemy.__version__
'svn'
e = sqlalchemy.create_engine('mssql://xxx:[EMAIL PROTECTED]
:1433/xxx',odbc_options='DRIVER={TDS};TDS_Version=8.0')
Traceback (most recent call last):
File stdin, line 1, in ?
File sqlalchemy/engine/__init__.py, line 160, in create_engine
return strategy.create(*args, **kwargs)
File sqlalchemy/engine/strategies.py, line 114, in create
raise TypeError(
TypeError: Invalid argument(s) 'odbc_options' sent to create_engine(),
using configuration MSSQLDialect_pyodbc/QueuePool/Engine. Please
check that the keyword arguments are appropriate for this combination
of components.
not sure why strategies.py would complain?
Are you converting:
'mssql://xxx:[EMAIL
PROTECTED]:1433/xxx',odbc_options='DRIVER={TDS};TDS_Version=8.0'
to
SERVER=xxx;UID=xx;PWD=xxx;DRIVER={TDS};TDS_Version=7.0
I have added the print line that we had used before that outputs the
connection string:
import sqlalchemy
e = sqlalchemy.create_engine('mssql://xx:[EMAIL PROTECTED]
:1433/xxx',odbc_options='Driver=TDS;TDS_Version=8.0')
DRIVER={SQL Server};Server=xxx;Database=xxx;Port=1433;UID=xxx;PWD=xxx
The driver is not changed and tds_version is not added
Lucas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: mssql, Linux, unixODBC - Could not locate column in row for column
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 out.
well I don't know if that is a right place to add that?
from the code this what it would expect
e = sqlalchemy.create_engine(mssql://xxx:[EMAIL
PROTECTED]:1433/xxx?odbc_options=Driver=TDS;TDS_Version=8.0)
vs you said you wanted:
sqlalchemy.create_engine('mssql://xxx:[EMAIL
PROTECTED]:1433/',odbc_options='DRIVER={TDS};TDS_Version=8.0')
to create
Server=xx;Database=xx;Port=1433;UID=xx;PWD=xxx;Driver={TDS};TDS_Version=8.0
Lucas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Get Mapper for Table
Got it, thanks!
On Apr 16, 4:26 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 16, 2008, at 10:13 AM, Koen Bok wrote:
Hey all,
Before 0.4.5 I used this code to get the mapped class for a table. It
worked fine, but mapper_registry was made private in 0.4.5 and the
private function does not behave the same way for some reason. But as
this code is pretty nasty anyway I was wondering if there was a better
way to do this. If not, can anyone hint me how to make this work
again?
from sqlalchemy.orm import mapper as _mapper
my_table_registry = {}
def mapper(cls, tbl, **kwargs):
my_table_registry[tbl] = cls
return _mapper(cls, tbl, **kwargs)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: To select a tree with PG connectby() in a single request
Thank you for the suggestion but the extension method doesn't fired,
even without raw sql:
mapper(Account, table_accounts, extension=AccountLoader(),
properties=dict(
children = relation(Account, lazy=None,
primaryjoin=table_accounts.c.parent_id==table_accounts.c.account_id,
#cascade=all,
collection_class=attribute_mapped_collection('name'),
backref=backref('parent',
primaryjoin=table_accounts.c.parent_id==table_accounts.c.account_id,
remote_side=table_accounts.c.account_id)
),
chart = relation(Account, lazy=None, uselist=False,
post_update=True,
primaryjoin=table_accounts.c.chart_id==table_accounts.c.account_id,
remote_side=table_accounts.c.account_id,
backref=backref('descendants', lazy=None,
join_depth=1,
primaryjoin=table_accounts.c.chart_id==table_accounts.c.account_id,
viewonly=True)
),
class AccountLoader(MapperExtension):
def append_result(self, mapper, selectcontext, row, instance,
result, **flags):
isnew = flags.get('isnew', False)
if instance.parent_id is None:
result.append(instance)
else:
if isnew or selectcontext.populate_existing:
key =
mapper.identity_key_from_primary_key(instance.parent_id)
parentnode = selectcontext.session.identity_map[key]
parentnode.children.append(instance)
return False
accounts = Session.query(Account).filter(Account.c.chart_id==1).all()
How can I fire the extension callback without eager loading
descendants?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: To select a tree with PG connectby() in a single request
On Apr 17, 2008, at 5:51 PM, jean-philippe dutreve wrote:
class AccountLoader(MapperExtension):
def append_result(self, mapper, selectcontext, row, instance,
result, **flags):
isnew = flags.get('isnew', False)
if instance.parent_id is None:
result.append(instance)
else:
if isnew or selectcontext.populate_existing:
key =
mapper.identity_key_from_primary_key(instance.parent_id)
parentnode = selectcontext.session.identity_map[key]
parentnode.children.append(instance)
return False
accounts = Session.query(Account).filter(Account.c.chart_id==1).all()
i cant see any problem from what I see here. The example script
definitely works and append_result is called, so just try to see
what's different here vs. that script, and try stepping through with
pdb for more detail. If all else fails, send along a full reproducing
test case.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] subquery and inheritance
I have several tables derived from a base
base = Table ('base', ...,
Column ('id'), Integer, primarykey=True))
d1= Table ('derived1',
Column ('id', Integer, ForignKey('base.id' ),
primarykey=True)
Column ('parent_id', Integer, ForignKey('base.id' ))
d2 = Table ('derived2',
Column ('id', Integer, ForignKey('base.id' ),
primarykey=True)
.Column ('parent_id', Integer,
ForignKey('base.id' ))
class B(object): pass
class D1(B):pass
class D2(B):pass
mapper (B, base)
mapper (D1, d1, inherits=Base)
mapper (D2, d2, inherits=Base)
I am building a tree structure of D1 and D2 nodes..
I am progressively generating a query as before execution using
subqueries.
s = session.query(D1).filter (...)._values(D1.c.id).statement
...
q = session.query (D2).select_from (s).filter (s.base_id ==
D2.parent_id)
print q
SELECT anon_1.base_id AS anon_1_base_id
FROM
(SELECT base.id AS base_id
FROM base JOIN derived1 ON base.id = derived1.id
WHERE ) AS anon_1,
base, derived2
WHERE anon_1.base_id = derived2.parent_id ORDER BY anon_1.base_id
This seems to generating extra join expression with 'base' without
the filtering
the inheritance expression D2.c.id = Base.c.id
I tried adding the above expression to the filter directly:
q = session.query (D2).select_from (s).filter (and_(s.base_id ==
D2.parent_id,
B.c.id==D2.c.id)
but this produced
SELECT anon_1.base_id AS anon_1_base_id
FROM
(SELECT base.id AS base_id
FROM base JOIN derived1 ON base.id = derived1.id
WHERE ) AS anon_1,
base, derived2
WHERE anon_1.taggable_id = derived2.parent_id AND anon_1.base_id =
anon_1.base_id ORDER BY anon_1.taggable_id
Any help appreciated.
Kris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
