Мне нужно связать две таблицы, используя SQLAlchemy 0.7;одна находится в базе данных MySQL, а другая - в базе данных Oracle.
Я уже успешно связал подобные таблицы, где ключи одного типа:
Base = declarative_base()
class Survey(Base):
__tablename__ = 'SURVEY'
survey_id = Column(Integer, primary_key=True)
term_id = Column(Integer, nullable=False)
# Because the TERM table is in Oracle, but the SURVEY table is in
# MySQL, I can't rely on SQLAlchemy's ForeignKey. Thus,
# I need to specify the relationship entirely by hand, like so:
term = relationship("Term",
primaryjoin="Term.term_id==Survey.term_id",
foreign_keys=[term_id],
backref="surveys"
)
class Term(Base):
__tablename__ = 'TERM'
term_id = Column(Integer, primary_key=True)
term_name = Column(String(30))
start_date = Column(Date)
end_date = Column(Date)
mysql_engine = create_engine(MYSQL)
oracle_engine = create_engine(ORACLE)
Session = scoped_session(sessionmaker(
binds={
Term: oracle_engine,
Survey: mysql_engine
}
))
Однако,Я столкнулся с ошибкой, когда один из первичных ключей таблиц Oracle (PERSON.person_id
) - VARCHAR2(30)
, а связанный ключ в таблице MySQL (ANSWER.person_id
) - тип INT.Я не могу изменить таблицу Oracle, и я бы предпочел избежать изменения таблицы MySQL.Когда я пытаюсь получить объект PERSON
через отношения на ANSWER
, Oracle выдает:
ORA-01722: invalid number
, что, по-видимому, связано с попыткой запроса, подобного:
SELECT * from PERSON where person_id = 12345;
вместо
SELECT * from PERSON where person_id = '12345';
Итак, я ищу способ сообщить SQLAlchemy, что ANSWER.person_id
следует преобразовать в строку перед использованием в запросах к таблице Oracle.Я пытался использовать конструкцию func
SQLAlchemy, но:
Answer.person = relationship(Person,
primaryjoin=Person.person_id == func.TO_CHAR(Answer.person_id),
foreign_keys=[Answer.person_id]
)
заставляет SQLAlchemy вызвать эту ошибку:
sqlalchemy.exc.ArgumentError: Could not determine relationship direction for primaryjoin condition 'PERSON.person_id = TO_CHAR(ANSWER.person_id)', on relationship Answer.person, using manual 'foreign_keys' setting. Do the columns in 'foreign_keys' represent all, and only, the 'foreign' columns in this join condition? Does the mapped Table already have adequate ForeignKey and/or ForeignKeyConstraint objects established (in which case 'foreign_keys' is usually unnecessary)?
Любые идеи будут оченьоценили!