[sqlalchemy] Cannot autoreflect MySQL table with minus sign ('-') in table name.
Configuration: CentOS 5 (64bit), SA (trunk), Python 2.4.4, py- MySQLdb-1.2.1, MySQL 5.1-current Traceback (most recent call last): File ./indexer.py, line 79, in ? table[database][conf] = Table(conf, metadata, autoload=True) File /usr/lib/python2.4/site-packages/sqlalchemy/schema.py, line 166, in __call__ File /usr/lib/python2.4/site-packages/sqlalchemy/engine/base.py, line 809, in reflecttable File /usr/lib/python2.4/site-packages/sqlalchemy/databases/ mysql.py, line 1095, in reflecttable sqlalchemy.exceptions.NoSuchTableError: 'ford-focus' Plain SQL works perfectly: SELECT * FROM `ford-focus` WHERE 1 ORDER BY `ford-focus`.`date` DESC LIMIT 0 , 30 --~--~-~--~~~---~--~~ 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: Cannot autoreflect MySQL table with minus sign ('-') in table name.
Dirty fix (works for me):
Index: mysql.py
===
--- mysql.py(revision 2873)
+++ mysql.py(working copy)
@@ -1090,7 +1090,7 @@
table.name = table.name.lower()
table.metadata.tables[table.name]= table
try:
-c = connection.execute(describe + table.fullname, {})
+c = connection.execute(describe ` + table.fullname +
`, {})
except:
raise exceptions.NoSuchTableError(table.name)
found_table = False
@@ -1153,7 +1153,7 @@
runs SHOW CREATE TABLE to get foreign key/options
information about the table.
-c = connection.execute(SHOW CREATE TABLE + table.fullname,
{})
+c = connection.execute(SHOW CREATE TABLE ` + table.fullname
+ `, {})
desc_fetched = c.fetchone()[1]
if not isinstance(desc_fetched, basestring):
--~--~-~--~~~---~--~~
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: SAContext 0.3.0
Hi, SAContext is a SQLAlchemy front end that organizes your engines, metadatas, and sessions into one convenient object, while still allowing access to the underlying objects for advanced use. Mike, this looks like good work and something that is needed. I notice for instance that the current TurboGears SA integration is a little hacky (to say the least!) Does SAContext do anything in the way of assosciating transactions/sessions with requests? To explain why I'm interested, I'm having some data freshness problems with a TG/SA app. I believe SessionContext has some inherent thread-safety issues, primarily that old data will build up in each thread's identity map, unless you periodically start a new session (e.g. at the start of a request). Is this something that SAContext tries to address? Another thing SAContext could potentially do is handle database disconnection errors (i.e. reconnecting and retrying a block of code). This is something people often notice with MySQL. Automatic recovery is probably not appropriate for the SQLAlchemy layer, but perhaps SAContext is a layer where this can be done. Paul --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
Hi, SAContext is strictly a configurational object, it doesnt add any new I see. I had wondered if this was WSGI middleware that took care of database transactions (as has been mooted in the TG area recently). Obviously as a config object, it can't do either of the things I suggested. Paul --~--~-~--~~~---~--~~ 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] relative insert performance
I've noticed some large (10x) performance differences between sqlalchemy (no
ORM) and plain DB API when using sqlite and was wondering if that is
something expected even when I'm (trying to) avoid the ORM stuff or if I'm
just doing something wrong.
We have lots of CSV files and I wanted to turn each file into a sqlite db to
make another project easier. I wrote an importer using the raw sqlite3
dbapi and then again using sqlalchemy (no ORM I hope). All the importer
does is loop over the lines of the file and insert rows into the database.
The raw dbapi version can insert ~5000-7000 rows per second whereas the
sqlalchemy version does about ~300-500 rows per second.
When I turned on metadata.engine.echo I didn't see sqlalchemy doing anything
beyond what I expected it to; just a bunch of inserts followed by a commit
when I tell it to.
Is this performance disparity expected?
Normally, I wouldn't mind. Unfortunately, the data I'm importing is *huge*
(each file can have 50,000-100,000 rows) so the difference between 400
rows per second and 5000 rows per second becomes important for the end-user
app that is being developed.
The essence of the two scripts are reproduced below; maybe I'm doing
something horribly wrong in sqlalchemy.
Thanks for any help,
Justus
sqlimporter-dbapi.py:
connection = sqlite.connect(sqlfile)
cursor = connection.cursor()
for row in get_csvdata(f):
cursor.execute('insert into results value (?,?,?,?,?)', row)
connection.commit()
sqlimporter-alchemy.py:
db = sqlalchemy.create_engine('sqlite:///' + sqlfile)
metadata = sqlalchemy.MetaData()
metadata.connect(db)
results_table = sqlalchemy.Table('results', metadata, autoload=True)
insert_results = results_table.insert()
connection = db.connect()
trans = connection.begin()
for row in get_csvdata(f):
connection.execute(insert_results, test_guid=row[0],
timestamp=row[1], )
trans.commit()
---
Justus
--~--~-~--~~~---~--~~
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: SAContext 0.3.0
Well I would prefer not using None and rather making the user pass the correct key, so that way default become no different they using any other key and users could just as simply call their key main or what ever else turns them on. Assuming that they use the correct syntax in the ini file (sqlalchemy.key.uri). So what I would advocate is eliminating the special default and just make users specify the correct key, I think that would be much less ambiguous then None Jose On 7/11/07, Mike Orr [EMAIL PROTECTED] wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Idea for 0.4: URI params / create_engine arguments
Hi, take a look at the current implementation. we are doing this part already, we're using inspect to look at kwargs. its not fragile at all. so im just proposing we add extra sniffing of dbapi.connect(), and that we also look in the query string for the full range of those parameters. this will allow 90% of what people want to pass to be allowed within the URI. Having kicked off this thread, I think my take now is to keep things more-or-less as they are - from all the points people have made, it's clear major changes will be more painful that it's worth. Having DefaultEngineStrategy.create pass the URI to the dialect's constructor would be great - that would let MSSQL have the module_name as a URI parameter. Just this change would statisfy my needs. Paul --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
On Wednesday 11 July 2007 21:49:48 Mike Orr wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). i would create a dummy class, in your case class DEFAULT: pass under SAcontext, and use that one instead of None: if x is SAcontext.DEFAULT: ... works quite well. --~--~-~--~~~---~--~~ 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: relative insert performance
On Jul 11, 9:02 pm, Justus Pendleton [EMAIL PROTECTED] wrote: I've noticed some large (10x) performance differences between sqlalchemy (no ORM) and plain DB API when using sqlite and was wondering if that is something expected even when I'm (trying to) avoid the ORM stuff or if I'm just doing something wrong. Looking at http://www.sqlalchemy.org/trac/attachment/wiki/ProfilingResults/sqla.insert.prof.png this is in the ballpark of whats expected. You can about double your performance by compiling the insert and using the result instead of the insert clause. And if that is not enough you can buffer insertable data into a list and execute many rows at a time, this should dramatically decrease SQLAlchemy overhead. Ants --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
I've just reread the sacontext doc string and realize that what I've said really does not make any sense. To go back a step I would advocate using default rather then None Jose On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Well I would prefer not using None and rather making the user pass the correct key, so that way default become no different they using any other key and users could just as simply call their key main or what ever else turns them on. Assuming that they use the correct syntax in the ini file (sqlalchemy.key.uri). So what I would advocate is eliminating the special default and just make users specify the correct key, I think that would be much less ambiguous then None Jose On 7/11/07, Mike Orr [EMAIL PROTECTED] wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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] simple query and prop.get_join()
Lets say there are Employee, Engineer, Manager, etc whole tree, with Employee in the root; all levels do have instances and its polymorphical multitable inheritance. Let's the Employee has attribute age - number, and manager - pointing to some other Employee. how to get all Employees which have a manager of age less than 40? a straight forward sql-like thing would look like: mgr = tableEmployee.alias() r = session.query( Employee).select( (tableEmployee.c.manager_id == mgr.id) (mgr.c.age 40) ) but can i do something smarter... e.g. some .join, .filter or something similar? The reason of talking about Property.get_join() here is that i am actualy creating the above clause on the run, autoconverting from an expression func (e.g. lambda self: self.manager.age40). After lots of other machinery, i am using mapper.props[key].get_join() to guess/add the (implicit) join-conditions. The property here is self-referential. If the mapper (Employee) is not polymorphic - e.g. none of the other subclasess exist - all is okay, get_join() returns something that i ClauseAdapt to use an aliased table instead the original: tblemployee.manager_id == tblempluyee.db_id - tblemployee.manager_id == tblemployee_0123.db_id But if the mapper is polymorphic, prop.get_join() returns the (mapper.select_table's) polymunion put on both sides: pu_employee.manager_id == pu_employee.db_id which my code does not recognise - its looking for tblemployee.db_id. so the question is: is there any way to make the get_join() to not return polymunions on _both_ sides? i see they come from some ClauseAdaptor (many2one case) being applied... And why it has to apply to both sides? what i need is something like replacing only one side: pu_employee.manager_id == tblemployee.db_id anyway, i can roll my own get_join() replacement, i am already workarounding the cache u have there, and having my own join_via... (and back to the first question, the .join_to() and .join_via() finaly use the prop.get_join() - hence i dont see how to get out of the loop..) btw are there any changes in these mechanics in the 0.4? i haven't looked there yet. ciao svil --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
On 7/11/07, Mike Orr [EMAIL PROTECTED] wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. I released 0.3.1 which accepts default, sacontext.DEFAULT, or None interchangeably to refer to the default engine. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: simple query and prop.get_join()
anyway, i copied prop.get_join and removed all polymorphic stuff + cache, and now such expressions work. Gaetan, u still interested in this db-cooker of mine? i think i have something to show... --~--~-~--~~~---~--~~ 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: Autoload problem with my MySql server
I've run into this problem as well when working with MySQL 4.0.20c. I believe the code needs to read: decode_from = connection.execute(show variables like 'character_set').fetchone()[0] When issuing that sql at the command prompt, i get back the following: mysql show variables like character_set; +---++ | Variable_name | Value | +---++ | character_set | latin1 | +---++ 1 row in set (0.01 sec) On Jul 3, 9:48 am, Michael Bayer [EMAIL PROTECTED] wrote: its this code decode_from = connection.execute(show variables like 'character_set_results').fetchone()[1] this bug is because you have a very old version of MySQL..if you can figure out what the above code needs for your mysql we can patch it. --~--~-~--~~~---~--~~ 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: relative insert performance
On Jul 11, 2007, at 2:02 PM, Justus Pendleton wrote: I've noticed some large (10x) performance differences between sqlalchemy (no ORM) and plain DB API when using sqlite and was wondering if that is something expected even when I'm (trying to) avoid the ORM stuff or if I'm just doing something wrong. We have lots of CSV files and I wanted to turn each file into a sqlite db to make another project easier. I wrote an importer using the raw sqlite3 dbapi and then again using sqlalchemy (no ORM I hope). All the importer does is loop over the lines of the file and insert rows into the database. The raw dbapi version can insert ~5000-7000 rows per second whereas the sqlalchemy version does about ~300-500 rows per second. When I turned on metadata.engine.echo I didn't see sqlalchemy doing anything beyond what I expected it to; just a bunch of inserts followed by a commit when I tell it to. Is this performance disparity expected? you should definitely call it via executemany() semantics, where you issue just a single execute() call (or a small set of them), each one containing a list of parameter sets to be inserted. the form is the last example here: http://www.sqlalchemy.org/docs/ sqlconstruction.html#sql_insert . using this method, all of the overhead of compiling and executing within SQLAlchemy is cut down to a negligble amount and the work is placed almost totally within the DBAPI. you also optimize the operation on the database side, as various databases can pre-prepare a statement handle that is used repeatedly. the performance overhead by calling individual executes() is that of compiling the statement into a string each time, creating an execution context, doing some guesswork on the given bind parameters and checking for defaults, and then executing. a lot of automatic stuff is done for you. like ants said, you can reduce the compile overhead by compiling the statement ahead of time: statement = table.insert().compile() --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
On Jul 11, 2007, at 2:49 PM, Mike Orr wrote: It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. i've no problem with positional arguments. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). id -1 on that, if possible. if theres some way for no arguments to do the right (i.e. expected) thing, thats best. --~--~-~--~~~---~--~~ 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: simple query and prop.get_join()
at first glance it seems like you need just session.query
(Employee).join('managers').filter(mgr.c.age 40) ?
oh, but the issue is that managers is self-referring and needs to
be an alias ?
we have a mini feature in 0.4 so far which creates aliases, but its
not quite what you want yet, it looks like:
session.query(Employee).filter_by(['managers'], age=40)
that will create an anonymized join to the same table. this is
using get_join() with the keyword create_aliases (which you can
also try out. for your stuff, you should be working with 0.4
directly right now since youre on the cutting edge).
But also, due to recent inclement weather, we want to try to expand
out this feature from filter_by() into something that can use any
operator. this would look like...well..it would look like
Class.prop == whatever . *cue dramatic music* since multiple
class.prop==whatevers will combine together using AND semantics,
they probably will have to create aliased joins.
so yeah, everyone's wanted that since version 0.1, sonow you'll
all get it.
On Jul 11, 2007, at 4:56 PM, [EMAIL PROTECTED] wrote:
Lets say there are Employee, Engineer, Manager, etc whole tree, with
Employee in the root; all levels do have instances and its
polymorphical multitable inheritance.
Let's the Employee has attribute age - number, and manager - pointing
to some other Employee.
how to get all Employees which have a manager of age less than 40?
a straight forward sql-like thing would look like:
mgr = tableEmployee.alias()
r = session.query( Employee).select(
(tableEmployee.c.manager_id == mgr.id) (mgr.c.age 40) )
but can i do something smarter... e.g. some .join, .filter or
something similar?
The reason of talking about Property.get_join() here is that i am
actualy creating the above clause on the run, autoconverting from an
expression func (e.g. lambda self: self.manager.age40). After lots
of other machinery, i am using mapper.props[key].get_join() to
guess/add the (implicit) join-conditions.
The property here is self-referential.
If the mapper (Employee) is not polymorphic - e.g. none of the other
subclasess exist - all is okay, get_join() returns something that i
ClauseAdapt to use an aliased table instead the original:
tblemployee.manager_id == tblempluyee.db_id
- tblemployee.manager_id == tblemployee_0123.db_id
But if the mapper is polymorphic, prop.get_join() returns the
(mapper.select_table's) polymunion put on both sides:
pu_employee.manager_id == pu_employee.db_id
which my code does not recognise - its looking for tblemployee.db_id.
so the question is: is there any way to make the get_join() to not
return polymunions on _both_ sides? i see they come from some
ClauseAdaptor (many2one case) being applied...
And why it has to apply to both sides?
what i need is something like replacing only one side:
pu_employee.manager_id == tblemployee.db_id
anyway, i can roll my own get_join() replacement, i am already
workarounding the cache u have there, and having my own join_via...
(and back to the first question, the .join_to() and .join_via() finaly
use the prop.get_join() - hence i dont see how to get out of the
loop..)
btw are there any changes in these mechanics in the 0.4?
i haven't looked there yet.
ciao
svil
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
