declarative needs to enforce structure of __table_args__

[Mike Bayer]

i.e.:

class Whatever(Base):
   ...

   __table_args__ = (ForeignKeyConstraint(...), )  # <- note no dict

ignores the fkconstraint and fails silently.

[Former user]

could the docs on table_args also be extended please, as at the moment there is only a brief mention of it in the declarative reference, and no indication of what entities should be put in this tuple/dict (though I get the impression it is something along the lines of non column entities..?), perhaps both a section in the declarative reference and a mention in each entity's reference?

also I'm curious why these entities are in effect reduced to second class citizens in the declaration? in SQL, they are on the same level as column declaration. eg:

create table blob (
  id integer
  other_id integer references other_table(id)
  foreign key (col1, col2) references...
)
class blob:
  id = Column(Integer)
  other_id = Column(Integer, ForeignKey(..)
  [not have the ForeignKeyConstraint here?](why)

also while I'm on the topic, could these constraints (UniqueConstraint has the same issues) be improved to accept columns as arguments as well as strings? not sure if this is an issue with the declarative ext or if I should be creating a seperate bug for this, sorry.

[Mike Bayer]

Replying to guest:

could the docs on table_args also be extended please, as at the moment there is only a brief mention of it in the declarative reference, and no indication of what entities should be put in this tuple/dict (though I get the impression it is something along the lines of non column entities..?), perhaps both a section in the declarative reference

the arguments are identical to those you would send to Table. (this would be the sentence to be added. the example using ForeignKeyConstraint is there so that people recognize this is what's being discussed. if you want to know what arguments Table takes, read http://www.sqlalchemy.org/docs/05/metadata.html#describing-databases-with-metadata . if this is not enough, please suggest the language you would like to see).

and a mention in each entity's reference?

not sure what this is referring to.

also I'm curious why these entities are in effect reduced to second class citizens in the declaration? in SQL, they are on the same level as column declaration. eg: {{{ create table blob ( id integer other_id integer references other_table(id) foreign key (col1, col2) references... ) class blob: id = Column(Integer) other_id = Column(Integer, ForeignKey(..) not have the ForeignKeyConstraint here? }}}

because Python classes do not allow unnamed attributes, and I don't think things like UniqueConstraint etc. should be given fake names which then become awkward class attributes (or if we zapped those names, that seems awkward as well. a __dundername__ OTOH seems like something that is stashed away).

also while I'm on the topic, could these constraints (UniqueConstraint has the same issues) be improved to accept columns as arguments as well as strings? not sure if this is an issue with the declarative ext or if I should be creating a seperate bug for this, sorry.

they do this in 0.6. no ticket is necessary.

[Former user]

Replying to zzzeek:

and a mention in each entity's reference?

not sure what this is referring to. I was thinking that in for example the ForeignKey documentation, it mentions that ForeignKeyConstraints should be added at the Table level (this didn't mean anything to me before but you've explained that now) - but it doesn't actually say that in the FKC's own section. I was thinking to add a sentence that explicitly says "when using declarative, this should be passed in using table_args", perhaps simply repeating the "at Table level" sentence would be enough. Ditto UniqueConstraint.

because Python classes do not allow unnamed attributes, and I don't think things like UniqueConstraint etc. should be given fake names which then become awkward class attributes (or if we zapped those names, that seems awkward as well. a __dundername__ OTOH seems like something that is stashed away). This makes sense I guess, however it'd be nice to have something in the declarative documentation that explicitly says what should be put into table_args, as I don't think it is clear. I guess it is anything that you wouldn't give a name? That's a little vague/ambiguous though!

they do this in 0.6. no ticket is necessary. Looking forward to this! :)

[Mike Bayer]

a510e9f23abe0df6eaa781094b191eb3178b2c7d

[Former user]

I'm glad this was solved with the current error message rather than silently failing. But... It seems awkward to require an empty dict at the end of table_args if we have no contents that we need to send in the dict. In my current case I only need to send a single ForeignKeyConstraint in, most of the time. Why make me tuple it up with an empty dict just to get by? I realize what I'm talking about is 'merely syntax', but it still seems a bit odd.

[Mike Bayer]

The rationale was TMTOWTDI as well as the exceedingly unlikely case that a dictionary were accepted as a Table positional argument. e7c5fd7b22dd21ec1c1cac177b9ee611779903e3

[Mike Bayer]

Removing milestone: 0.7.0 (automated comment)