On Thursday 13 July 2006 19:44, Michael Bayer wrote:
we havent gotten around to supporting INSERT from a SELECT, as a
python-constructed SQL clause, as of yet. is there any reason you
cant just use a plain text() query for this ?
No, not at all. I was just hoping that there was some way of
Sanjaya Kumar Patel wrote:
Dear All,
I am not being able to figure out how relate to a table having composite
primary key. To illustrate my problem, I am giving below a schema. Any
guidence on how to code this in SQLAlchemy (and in ActiveMapper, if
possible) is more than appreciable. I
Charles Duffy wrote:
I don't think autoloading is possible with ActiveMapper (doesn't it
defeat the point?)
Its not *currently* possible, however I don't think it would be hard
at all to put in something like this into ActiveMapper:
class Person(ActiveMapper):
class mapping:
On Jul 14, 2006, at 9:29 AM, Jonathan LaCour wrote:
I don't really know anything about how relationships are detected in
SQLAlchemy when you use autoloading, so I am not sure if doing that
part is possible, but using the existing infrastructure to load the
columns themselves should be fairly
On Jul 14, 2006, at 11:04 AM, Jonathan LaCour wrote:
Note that you absolutely *must* have the activemapper metadata bound
before you declare your classes, or everything will blow up. It does
not yet support relationships (and might not ever, from what Mike
stated in his response to me
Sanjaya Kumar Patel wrote:
Is something like this possible, that the tables are autoloaded, along
with foreign keys, but the relations are defined in the code. I think
this is what is done in SQLAlchemy when you do autoload?
So, something like this?
[snip snip code]
This is what I would
OK, in continuing with the UNIQUE issue of the other day, id like to
continue making the whole constraint methodology as simple and
consistent as possible, including getting all the reflection to
work. this is more complicated than I first realized.
So, Id like to move all the logic for
On 7/14/06, Jonathan LaCour [EMAIL PROTECTED] wrote:
Really, when you think about it, defining the schema in the code ismore adherent to DRY than autoloading, since instead of having 1 DDLscript for every database you support, you just have it stated in codeone time ;)
Except you still cant define
On Fri, 2006-07-14 at 10:46, Jonathan Ellis wrote:
On 7/14/06, Jonathan LaCour [EMAIL PROTECTED] wrote:
Really, when you think about it, defining the schema in the
code is
more adherent to DRY than autoloading, since instead of having
1 DDL
script for
William K. Volkman wrote:
Additionally that is a programmer centric view, something that would
only be applicable to small projects. Once you get 10s of developers
involved chaos ensues until a DBA is appointed to analyze, normalize,
and document the data requirements. Even in small systems
On Jul 14, 2006, at 2:21 PM, David Shoemaker wrote:
This is actually somewhat unrelated, but how are circular foreign
key dependencies handled? In the example above, what if table lala
had to be created after table foo because of such a dependency?
While you're refactoring this
OK, you can see what ive done so far in rev 1709, over at:
http://www.sqlalchemy.org/trac/changeset/1709
unit tests work for postgres, sqlite, and mysql so far, including
composite foreign key reflection. oracle/mssql/firebird probably work
at least as good as they used to.
for
12 matches
Mail list logo
