python - SQLAlchemy 数据库交互失败取决于我如何运行 python 脚本

Question

这似乎是我迄今为止处理过的最晦涩的问题。我在努力奋斗。

我有一个应用程序可以从某些硬件收集远程数据并将其保存到数据库中。我使用 alembic 重命名了其中一列。我有一个开发数据库和一个测试数据库。两者都在同一台服务器上(MySQL 通过 CentOS 7 上的 MariaDB)。

我通过在我的笔记本电脑上运行的应用程序与开发服务器进行交互，而测试数据库通过在生产服务器的克隆上运行的应用程序进行交互。

所有服务器和数据库均使用 Ansible 设置，因此差异仅限于用户名和密码。

下面是升级脚本中的ansible片段

def upgrade():
    op.alter_column('units', 'ip_address', new_column_name='ipv4', existing_type=sa.String(100))

如果我从我的笔记本电脑(使用我的 IDE)运行应用程序，数据保存正常。

如果我在测试服务器上手动运行脚本 (env)$ python app.py，数据保存正常。

但是，问题来了，如果我使用 supervisord 运行脚本，我会收到 SQLAlchemy 错误。 (以下摘录，full traceback)

...
File "thefile.py", line 64, in run
    self.data['my_wellsites'][w.name]['ipv4'] = wellsite.unit.ipv4
...
sqlalchemy.exc.InternalError: (InternalError) (1054, u"Unknown column 'units.ipv4' in 'field list'") 'SELECT units.id AS units_id, units.unittype_id AS units_unittype_id, units.serial AS units_serial, units.ipv4 AS units_ipv4, units.mac_address AS units_mac_address, units.engine_hours AS units_engine_hours, units.gen_odometer AS units_gen_odometer, units.gen_periodic AS units_gen_periodic, units.notes AS units_notes \nFROM units \nWHERE units.id = %s' (1,)
...

SQLAlchemy 模型..

class Unit(Model):
    __tablename__ = 'units'
    __table_args__ = {'mysql_engine': 'InnoDB'}

    id = Column(Integer, Sequence('unit_id_seq'), primary_key=True)
    wellsites = relationship('Wellsite', order_by='Wellsite.id', backref='unit')
    ipv4 = Column(String(16), unique=True)
    ...

class Wellsite(Model):
    __tablename__ = 'wellsites'
    __table_args__ = {'mysql_engine': 'InnoDB'}

    id = Column(Integer, Sequence('wellsite_id_seq'), primary_key=True)
    unit_id = Column(Integer, ForeignKey('units.id'), nullable=False)
    ...

etc/supervisord.conf..

...
[program:datacollect]
command = /home/webdev/mydevelopment/git/ers_data_app/env/bin/python /home/webdev/mydevelopment/git/ers_data_app/data_monitoring/collection_manager.py
stdout_logfile=/home/webdev/logs/datacollect.log
stderr_logfile=/home/webdev/logs/datacollecterr.log
autostart=true
autorestart=unexpected
startsecs=10

我尝试使用

运行额外的 alembic 升级

op.create_unique_constraint('uq_ipv4', 'units', ['ipv4'])

没有骰子。

除了时间戳之外，traceback 是相同的(使用 diff 程序)

下面是units表的两个数据库描述(相同)

MariaDB [ers_DEV]> show columns from units;
+--------------+--------------+------+-----+---------+----------------+
| Field        | Type         | Null | Key | Default | Extra          |
+--------------+--------------+------+-----+---------+----------------+
| id           | int(11)      | NO   | PRI | NULL    | auto_increment |
| unittype_id  | int(11)      | YES  | MUL | NULL    |                |
| serial       | varchar(10)  | YES  | UNI | NULL    |                |
| ipv4         | varchar(100) | YES  | UNI | NULL    |                |
| mac_address  | varchar(17)  | YES  | UNI | NULL    |                |
| engine_hours | int(11)      | YES  |     | NULL    |                |
| gen_odometer | tinyint(1)   | YES  |     | NULL    |                |
| gen_periodic | tinyint(1)   | YES  |     | NULL    |                |
| notes        | mediumtext   | YES  |     | NULL    |                |
+--------------+--------------+------+-----+---------+----------------+


MariaDB [ers_TEST]> show columns from units;
+--------------+--------------+------+-----+---------+----------------+
| Field        | Type         | Null | Key | Default | Extra          |
+--------------+--------------+------+-----+---------+----------------+
| id           | int(11)      | NO   | PRI | NULL    | auto_increment |
| unittype_id  | int(11)      | YES  | MUL | NULL    |                |
| serial       | varchar(10)  | YES  | UNI | NULL    |                |
| ipv4         | varchar(100) | YES  | UNI | NULL    |                |
| mac_address  | varchar(17)  | YES  | UNI | NULL    |                |
| engine_hours | int(11)      | YES  |     | NULL    |                |
| notes        | mediumtext   | YES  |     | NULL    |                |
| gen_odometer | tinyint(1)   | YES  |     | NULL    |                |
| gen_periodic | tinyint(1)   | YES  |     | NULL    |                |
+--------------+--------------+------+-----+---------+----------------+

Answer 1

问题出在 /etc.supervisord.conf 文件的顶部。在其中，设置了一个环境变量，该变量将脚本指向错误的数据库，覆盖了从其他任何地方设置和检查的环境变量。此环境变量仅在脚本从 supervisor 运行并导致问题时设置