sqlautocode：表中需要主键吗？
这与 SQLAlchemy 中的主键约束有关sqlautocode。 我有 SA 0.5.1 & sqlautocode 0.6b1 我有一个没有主键的 MySQL 表。 sqlautocode 吐出回溯“无法组装任何主键列”。
我可以用补丁来纠正这个问题，以便它能够反映没有主键的表吗？
谢谢， 维内特·迪奥达尔
This relates to primary key constraint in SQLAlchemy & sqlautocode.
I have SA 0.5.1 & sqlautocode 0.6b1
I have a MySQL table without primary key.
sqlautocode spits traceback that "could not assemble any primary key columns".
Can I rectify this with a patch sothat it will reflect tables w/o primary key?
Thanks,
Vineet Deodhar
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不这么认为。 ORM 如何在没有任何方法唯一标识记录的情况下将对象持久保存到数据库中？
但是，大多数 ORM 接受 Primary_key 参数，因此如果数据库中未显式定义该键，您可以指示该键。
I don't think so. How an ORM is suposed to persist an object to the database without any way to uniquely identify records?
However, most ORMs accept a primary_key argument so you can indicate the key if it is not explicitly defined in the database.
如果基础表上存在唯一标识它的列组合，我们就成功地伪造了 sqa。
如果这是您自己的表并且您不在现场，请添加主键整数列或其他内容。
我们甚至能够映射数据库中的现有旧表，a）没有 pk，b）其他列中没有主键的代理。这是Oracle而不是MySQL，但我们能够破解sqa以将Oracle的rowid视为pk，尽管这仅对于插入和查询是安全的...更新是不可能的，因为它无法唯一地标识应该更新哪一行。但这些都是丑陋的黑客行为，所以如果你能帮助的话，就不要走那条路。
We've succeeded in faking sqa if the there's combination of columns on the underlying table that uniquely identify it.
If this is your own table and you're not live, add a primary key integer column or something.
We've even been able to map an existing legacy table in a database with a) no pk and b) no proxy for a primary key in the other columns. It was Oracle not MySQL but we were able to hack sqa to see Oracle's rowid as a pk, though this is only safe for insert and query...update is not possible since it can't uniquely identify which row it should be updating. But these are ugly hacks so if you can help it, don't go down that road.
如果问题是 sqlautocode 不会生成您的类代码，因为它无法确定表的 PK，那么您可能能够更改该代码以满足您的需求（即使这意味着生成没有 PK 的 SQLA 代码） ）。最终，如果您使用 SQLA 的 ORM 端，您将需要定义为 PK 的字段，即使数据库没有明确地标记它们。
If the problem is that sqlautocode will not generate your class code because it cannot determine the PKs of the table, then you would probably be able to change that code to fit your needs (even if it means generating SQLA code that doesn't have PKs). Eventually, if you're using the ORM side of SQLA, you're going to need fields defined as PKs, even if the database doesn't explicitly label them as such.