> > > Perfectly. Although all the hassle makes me think even harder > > > if there is really no other way of connecting these two > > > database tables. A casted join with string comparison gets > > > dirtier every time I look at it. :( > > > > excuse me if it sounds dumb... what about a middleman table of > > proper (casted) values that is automaticaly build by some > > trigger? i can guess at least 3 objections right now, but it is > > an option in general principle... > > Doesn't sound dumb at all. I assume you are thinking of an > intermediary table that is connecting primary keys like "row 10 of > dns table is connected to row 515 of dhcp table". no, i was thinking of a "facade" table having just 1 column, a casted copy of the to-be-casted original column. i guess some primarykey sync/join would be needed too. and u use that table/column instead of the original column. it also looks a bit like multitable inheritance, this table being the child in the inheritance with one new attribute - but it is not real inheritance; and has a calculable attribute done by triggers, both ways. or u may copy+cast the whole original table...
but your new idea of association-table may also work. whatever. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
