Closed sqlalchemy-bot closed 16 years ago
Michael Bayer (zzzeek) wrote:
as discussed on IRC i think the foreign key attribute on the class being automatically "hidden" is an implicit behavior that's better suited for Elixir itself - elixir would place a foreign key column_property() on the mapper using a private name (like underscored or similar).
For SA, the "allow_column_override" flag is redundant versus "exclude_properties" and should probably be removed for that reason. Its usage has never been encouraged (except for its presence in the error message) and removing it will make it clearer that its up to the end user to re-target the same-named foreign key column. If you truly want a column ignored entirely, then using exclude_columns will make it clearer that thats what you're doing.
Michael Bayer (zzzeek) wrote:
allow_column_override means, "I don't care about this column being part of my mapping, just get rid of it". It's a less relevant flag now that we have "exclude_properties" and "include_properties", then again it still may be convenient for those cases when you just want to build relation names that may or may not step on columns you don't care about.
However in this case, SQLAlchemy clearly needs access to the "parent_table.c.column" column in order to handle the relation, like the error indicates. So the correct pattern for this specific case is:
mapper(Parent, parent_table,
properties=dict(
child_fkey=parent_table.c.child,
child=relation(Child)
),
)
Anonymous wrote:
(original author: ged) I know SA needs the column, but, since the user clearly indicates he doesn't care about this column (ie doesn't want to access it -- a user usually think in terms of what he does/doesn't need, what the underlying library does or need), we could somehow have that column still present in a private (not accessible from the outside) or anonymous way so that the relation can still work. This is the behavior I'd expect when "allow_column_override" is set.
Changes by Michael Bayer (zzzeek): set state to "invalid"
Issue created by Anonymous
(original reporter: ged) This fails even when specifying allow_column_override to the mapper. The attached test case, produce the following traceback.
FWIW: it was first reported as an Elixir ticket: http://elixir.ematia.de/trac/ticket/39
I'm personally not sure whether this should be allowed or not, but I don't see the point of having the allow_column_override option if this particular use case is not allowed.
Attachments: test_rel_col_same_name.py