On May 23, 2007, at 3:20 PM, Randall Smith wrote:
>
> Responding to myself. As I wrote the first message, I started
> thinking
> how just deleting the FK after metadata.create_all() wouldn't be so
> bad
> and now I think that's a pretty good solution.
you can also use foreign_keys and expl
Responding to myself. As I wrote the first message, I started thinking
how just deleting the FK after metadata.create_all() wouldn't be so bad
and now I think that's a pretty good solution.
Randall
Randall Smith wrote:
> Michael Bayer wrote:
>> I should learn to explain better what "syncrules
Michael Bayer wrote:
> I should learn to explain better what "syncrules" are about, so heres
> an attempt:
>
> when you have a table A and a table B, and then a mapping relationship
> between A and B, theres a join condition set up between the two tables.
> By default, it draws from the foreign
basically the "foreignkey" property was originally meant as a way to
"fool" the relationship into reversing the the direction of a
one-to-many self referential relationship, and is mostly an internal
variable used to figure out the "direction" of a relationship in other
cases. in fact in the case
Michael Bayer wrote:
> I should learn to explain better what "syncrules" are about, so heres
> an attempt:
[snip]
Thanks Michael, that's informative. Here's what I still don't
understand, though:
1) When I add viewonly=True to the relation definition in the above
code, I still get the very sam
I should learn to explain better what "syncrules" are about, so heres
an attempt:
when you have a table A and a table B, and then a mapping relationship
between A and B, theres a join condition set up between the two tables.
By default, it draws from the foreign keys of the tables.
Alternatively
hi Gaƫtan,
I'm using the latest release from sqlalchemy.org (0.3.1), downloaded and
installed yesterday. Maybe I should try trunk. Though at this point
just defining the ForeignKey relationships in the table definitions
is fine for me.
Thanks,
Carl
Gaetan de Menten wrote:
> I don't have much
On 12/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Oops, put the first table schema with the code by mistake.
>
> Anyway, I realized I can work around this by explicitly specifying the
> columns and foreign keys for just the association table, instead of
> autoloading them. Then I can r
Oops, put the first table schema with the code by mistake.
Anyway, I realized I can work around this by explicitly specifying the
columns and foreign keys for just the association table, instead of
autoloading them. Then I can remove all the primaryjoin and
secondaryjoin stuff, and it works fine