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

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.

Reply via email to