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错误。 （以下摘录， 完整的追溯 ）

...
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)
    ...

等/ 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运行脚本并导致问题时才设置此环境变量