在使用带有属性g的SQLAlchemy的ilike方法时遇到问题

Question

我正在实现一个用户名搜索功能。有些名称有重音字符，但我希望能够用最接近的ascii字符近似值来搜索它们。例如：Vû Trån可以用Vu Tran进行搜索。在

我找到了一个名为unidecode的Python库来处理这种转换。它按预期工作，接受我的unicode字符串Vû Trån并返回Vu Tran。很 完美。在

当我开始查询我的数据库时，问题就出现了——我使用SQLAlchemy和Postgres。在

下面是我的Python查询：

Person.query.filter(Person.ascii_name.ilike("%{q}%".format(q=query))).limit(25).all()

ascii_name是my name列的getter，实现如下

^{pr2}$

我在这段代码背后的意图是，因为我在数据库中存储了名字和姓氏的unicode版本，所以在检索人名时需要有一种方法来调用unidecode(unicode(name))。因此，我使用descriptor=property(fget=...)，这样每当我调用Person.ascii_name时，我都会检索“unidecoded”name属性。这样，我就可以简单地编写Person.ascii_name.ilike("%{my_query}%")...并将最近的ascii_名称与搜索查询匹配，搜索查询也是ascii字符。在

这并不完全有效。当查询中没有任何已转换的字符时，带有ascii_name的ilike方法可以工作。例如，ilike查询对名称“Bob Smith”有效，但对“BøB Smíth”无效。当遇到第一个被转换的字符时，它就失败了，在“BøB Smíth”的情况下是字母“o”。在

我不知道为什么会这样。ascii_namegetter返回我期望的字符串“Bob Smith”或“Vu Tran”，但是当与ilike方法结合使用时，它就不起作用了。在

1. 为什么会这样？我找不到关于这个问题的任何信息。在
2. 我怎样才能修复我现有的代码使其正常工作，或者有更好的方法来完成这项工作呢？我不想改变我的数据库模式。在

谢谢。在

Answer 1

您想做的事情根本行不通，因为ilike只对数据库中的实际列有效。column_property和{}只是sqlalchemy提供的语法糖，有助于简化前端。如果您想利用后端以您预期的方式使用LIKE进行查询，那么您需要那里的实际值。恐怕您必须在数据库中生成/存储ascii全名，这意味着您需要更改您的模式，将ascii_name作为一个真正的列，并确保它们被插入。要自己验证这一点，您应该转储表中的数据，并查看手动构造的查询是否可以工作。在