please forward an runnable example test case, preferably a single
file with 200 lines if possible.
you're also making usage of Column instances directly off the
selectable youre mapping, right ?
On Mar 5, 2007, at 1:55 PM, Pete Taylor wrote:
in regard to post-2309 revisions and the
yessir, when using selectables i always just use selectobj.c.colname...
i've attached a quick test case, and it throws the same error that my
live code does, so it at least proves i can break things the same way
twice :D i wouldn't be surprised if it's something easy that i'm just
doing wrong,
no problem, that test uncovered a place I could ratchet things down
some more so everybody wins. you want rev 2383.
On Mar 5, 2007, at 3:09 PM, Pete Taylor wrote:
yessir, when using selectables i always just use
selectobj.c.colname...
i've attached a quick test case, and it throws the
the current error message is:
raise exceptions.ArgumentError(Cant determine
relation direction for relationship '%s' - foreign key columns are
present in both the parent and the child's mapped tables. Specify
'foreign_keys' argument. %(str(self)))
are u on trunk ?
yes,
And another one - at same revision - maybe same thing?
IMO the UPDATE for a lazy post_update relations gets the dbapi
values swapped, e.g. (sqlite)
rev2308:
SA: INFO UPDATE Person SET friend_id=? WHERE Person.db_id = ?
* SA: INFO [2, 7]
rev2309-2344:
* SA: INFO UPDATE Person SET
sorry, on more file needed
something with lazy-relations, self-referential, but pointing to
another instance, not to _itself_. Happens regardless of
inheritance.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
I cant run the generator since theres a dependency Config not
found, but the standalones are using the foreignkey parameter which
is both deprecated and also more or less mutually exclusive with
remote_side.
the trunk now has the foreign_keys parameter which behaves
consistently as a
yeah actually foreignkey's legacy behavior is fine, those examples
are using it exactly incorrectlythe parameter takes on a
different meaning when used in a self-ref relationship (thats why its
been replaced) - its synonymous with remote_side in a self-ref
relationship.
On Feb 20,
foreignkey is out. dont use it at all.
remote_side, when the remote side of the relationship is ambiguous
based on the join condition, i.e. a self referential mapping
relationship. can be provided for otherwise non-ambiguous cases as
well.
foreign_keys, when your join condition contains
using the foreignkey parameter
which is both deprecated and also more or less mutually exclusive
with remote_side.
specifying foreign_keys explicitly, _and_ remote_side does work.
here the last fixed variant.
but if u comment out foreign_keys and lave only remote_side, in cases
like B
the current error message is:
raise exceptions.ArgumentError(Cant determine
relation direction for relationship '%s' - foreign key columns are
present in both the parent and the child's mapped tables. Specify
'foreign_keys' argument. %(str(self)))
are u on trunk ?
11 matches
Mail list logo
