Python Sqlalchemy Inheritance-在psql中返回零结果rawsql工作得很好

在我的应用程序中，我有一个contact_types表，它被子类化为供应商/客户联系人类型。联系人类型有点像他们的标题，但并不总是这样。无论如何，下面的每个类都在三个不同的文件中。父项和两个子项的globals.py文件位于customer.py和vendor.py文件中。我还使用了我找到的函数来打印带有值的实际db查询，以便手动运行sql

class ContactType(DeclarativeBase,TimeUserMixin):
    __tablename__ = 'contact_types'
    id = Column(Integer,primary_key=True,autoincrement=True)
    _code = Column('code',Unicode(50),nullable=False)
    sort_order = Column(Integer,nullable=False,default=9999)
    type = Column(Unicode(1),nullable=False)
    __mapper_args__ = {'polymorphic_on':type}

    @hybrid_property  
    def code(self):
        return self._code

    @code.setter
    def code(self,code):
        self._code = code.upper()

    def __init__(self,code,sort_order=None):
        self.code=code
        if sort_order is not None:
            self.sort_order = sort_order

    @property
    def as_dict(self):
        return {
            'id':self.id,
            'code':self.code
        }

    @classmethod
    def all_as_dict(cls, ):
        return [c.as_dict for c in DBSession.query(cls).order_by(cls.code)]

    @classmethod
    def by_id(cls,id):
        return DBSession.query(cls).get(id)

    @classmethod
    def by_code(cls,code ):
        return DBSession.query(cls).filter(cls.code == code.upper()).first()

class VendorContactType(m_globals.ContactType):
    __mapper_args__ = {'polymorphic_identity':'v'}

class CustomerContactType(g.ContactType):
    __mapper_args__ = {'polymorphic_identity':'c'}


Table detail ...
 create_time    | timestamp without time zone | not null
 modify_time    | timestamp without time zone | not null
 id             | integer                     | not null default nextval('contact_types_id_seq'::regclass)
 code           | character varying(50)       | not null
 sort_order     | integer                     | not null
 type           | character varying(1)        | not null
 create_user_id | integer                     | not null
 modify_user_id | integer                     | not null
Indexes:
"contact_types_pkey" PRIMARY KEY, btree (id)
"ix_contact_types_create_user_id" btree (create_user_id)
"ix_contact_types_modify_user_id" btree (modify_user_id)
Foreign-key constraints:
"contact_types_create_user_id_fkey" FOREIGN KEY (create_user_id) REFERENCES tg_user(user_id)
"contact_types_modify_user_id_fkey" FOREIGN KEY (modify_user_id) REFERENCES tg_user(user_id)
Referenced by:
TABLE "contacts" CONSTRAINT "contacts_contact_type_id_fkey" FOREIGN KEY (contact_type_id) REFERENCES contact_types(id)

select id,code,type from contact_types where code='NEW';
  id  | code | type
------+------+------
 7242 | NEW  | c
 7251 | NEW  | v

现在的问题是，不管我做什么，应用程序说它找不到记录，当我将sqlalchemy使用的sql复制并粘贴到postgres中时，我得到了一个结果。真让人发疯！！！！我猜继承权有点奇怪，但我就是找不到

这是我得到的控制台输出

08:34:17,419 DEBUG [erp.model.m_ap] 0  <----- This is just a simple queryresult.count()
08:34:17,421 DEBUG [erp.model.m_ap] SELECT contact_types.code, contact_types.create_time,   contact_types.modify_time, contact_types.id, contact_types.sort_order, contact_types.type,   contact_types.create_user_id, contact_types.modify_user_id
FROM contact_types
WHERE contact_types.code = 'NEW' AND contact_types.type IN ('v') <--- output of printquery

---

给出了什么？

问题与会话相关。一些代码正在擦除表，导入一组行，然后尝试查找以前删除的行。会话回滚，物理数据库表看起来相同，没有变化。

检查每个数据库和架构所使用的是什么。它是相同的数据库和架构，只是为了过于偏执，我为不同的表向同一数据库添加了一些新数据，同一应用程序显示了新数据，没有问题。好主意，因为我们在应用程序的不同级别上有两个“相同”的数据库（测试版、beta版、本地测试副本）。这可能是一个侮辱性的问题（但是，嘿，我也这么做了），但是你的psql会话被提交了吗？这一行是通过sqlalchemy或其他方式添加的吗？一点也不侮辱人！数据是通过sqlalchemy添加的，它是不久前添加的。如果使用sqlalchemy添加另一行并尝试检索回来，您能看到它吗？

erp_beta=# SELECT contact_types.code, contact_types.create_time,   contact_types.modify_time,  contact_types.id, contact_types.sort_order, contact_types.type,   contact_types.create_user_id, contact_types.modify_user_id
erp_beta-#     FROM contact_types
erp_beta-#     WHERE contact_types.code = 'NEW' AND contact_types.type IN ('v')
erp_beta-# ;
 code |        create_time         |        modify_time        |  id  | sort_order | type | create_user_id | modify_user_id
------+----------------------------+---------------------------+------+------------+------+----------------+----------------
 NEW  | 2013-04-10 08:16:02.778212 | 2013-04-10 08:16:02.77822 | 7251 |          9 | v    |             46 |             46
(1 row)