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

时间:2015-07-15 20:29:18

标签: python mysql sqlalchemy supervisord alembic

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

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

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

所有服务器和数据库都是使用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)
    ...

等/ 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    |                |
+--------------+--------------+------+-----+---------+----------------+

1 个答案:

答案 0 :(得分:0)

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