hello michael, friends, On 07/11/2012 10:31 AM, alex bodnaru wrote: > > hello michael, > > now it works. i also had to add uselist=False. > > i tried it the longest way possible, by adding a Pool first_connect listener, > but this was not really needed. just the uselist. > > thanks a lot, > alex > sorry, not yet:
the relationship should also allow assignment like this: class Lang(DeclarativeBase): lang_code = Column(String(20), primary_key=True) lang_name = Column(String(20)) class PageData(DeclarativeBase): lang_code = Column(String(20), primary_key=True) lang = relation('Lang', backref='pages', primaryjoin=lang_code==Lang.lang_code, foreign_keys=[Lang.lang_code], uselist=False) the PageData.lang_code foreign key is being added in an event on before create. before delaying creation of the foreign key, i could do like this: p = PageData() p.lang = Lang.get('en') and p.lang_code got assigned. why isn't lang_code being assigned now anymore? thanks in advance, alex > On 07/09/2012 04:25 PM, Michael Bayer wrote: >> >> On Jul 9, 2012, at 4:48 AM, alex bodnaru wrote: >> >>> >>> hello michael, friends, >>> >>> after successfuly fixing the ddl by the append_constraint event, the >>> relations >>> that needed the said foreign keys remained orphan, asking for a foreign_keys >>> argument and failing to load the remote table: >>> >>> class Lang(DeclarativeBase): >>> lang_code = Column(String(20), primary_key=True) >>> lang_name = Column(String(20)) >>> >>> class PageData(DeclarativeBase): >>> lang_code = Column(String(20), primary_key=True) # this foreign key is >>> being >>> successfully appended on before_create. >>> lang = relation('Lang', backref='pages', >>> primaryjoin=lang_code==Lang.lang_code) #this relationship won't work, since >>> at >>> the moment the class is being made, the foreign key is not there yet. >>> >>> the foreign_keys=Lang.lang_code arg does calm the exception, but doesn't do >>> the >>> work. >>> could i add the relationship to the mapper on the same event? >> >> I would think "foreign_keys" should fix the problem totally, what do you >> mean "doesn't do the work"? I'd have to work up a test case, can you just >> throw these two classes, the event, and some imports into a file for me ? I >> can just run it. >> > well, almost totally ;) > it also needed uselist=False. > >> >>> >>> thank in advance, >>> alex >>> >>> On 07/07/2012 05:13 PM, Michael Bayer wrote: >>>> sure engine and connection have .dialect.name. Foreign key constraints >>>> don't matter on SQLite unless you've actually enabled them, which is rare. >>>> I'd still use an event though so at least the behavior is transparent. >>>> >>>> @event.listens_for(my_table, "before_create") >>>> def add_fk(table, conn, **kw): >>>> if conn.dialect.name != 'mssql': >>>> table.append_constraint(ForeignKeyConstraint(...)) >>>> >>>> tricky though to modify the table metadata within a "create" event in the >>>> case that the table is created multiple times in an app. you can put a >>>> flag in table.info, like "table.info['added_the_fk'] = True", to keep >>>> track of things. >>>> >>>> >>>> >>>> On Jul 7, 2012, at 12:59 AM, alex bodnaru wrote: >>>> >>>>> >>>>> hello mike and thanks for your answer. >>>>> >>>>> no problem with ForeignKeyConstraint, but wouldn't AddConstraint go the >>>>> alter >>>>> way? in this case, it will be ignored by the sqlite dialect. >>>>> >>>>> what i was looking for was more like: >>>>> >>>>> from sqlalchemy... import get_dialect >>>>> >>>>> .... >>>>> fk_parms = dict(.....) >>>>> if get_dialect() != 'mssql': >>>>> fk_parms.update(onupdate='restrict') >>>>> fk = ForeignKey(**fk_parms) >>>>> >>>>> would the dialect be accessible from the engine, metadata etc? >>>>> >>>>> thanks in advance, >>>>> alex >>>>> >>>>> >>>>> On 07/06/2012 11:39 PM, Michael Bayer wrote: >>>>>> you'd use ForeignKeyConstraint along with the AddConstraint directive, >>>>>> and limit it per-dialect using create/drop events as documented at >>>>>> http://docs.sqlalchemy.org/en/rel_0_7/core/schema.html#controlling-ddl-sequences >>>>>> . >>>>>> >>>>>> >>>>>> On Jul 6, 2012, at 1:30 PM, alex bodnaru wrote: >>>>>> >>>>>>> >>>>>>> hello friends, >>>>>>> >>>>>>> i need to define a foreign key differently for different dialects: >>>>>>> ondelete='restrict' for most engines, but nothing (implied and not >>>>>>> recognized) >>>>>>> for mssql. >>>>>>> >>>>>>> could you help? >>>>>>> >>>>>>> thanks in advance, >>>>>>> alex >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "sqlalchemy" group. >>>>>>> To post to this group, send email to sqlalchemy@googlegroups.com. >>>>>>> To unsubscribe from this group, send email to >>>>>>> sqlalchemy+unsubscr...@googlegroups.com. >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/group/sqlalchemy?hl=en. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "sqlalchemy" group. >>>>> To post to this group, send email to sqlalchemy@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> sqlalchemy+unsubscr...@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/sqlalchemy?hl=en. >>>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sqlalchemy" group. >>> To post to this group, send email to sqlalchemy@googlegroups.com. >>> To unsubscribe from this group, send email to >>> sqlalchemy+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/sqlalchemy?hl=en. >>> >> > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.