You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tortoise.exceptions.OperationalError: table receiving_books has no column named custom_books_id
Since the names for relations are created: student_id and book_id, according to the names described in the model, in the format [association_model_field_name]_id, while they are requested in a different format [relation_table_name]_id - for the field, in which defines the relation and [association_model_field_name]_id for the second field.
This problem is solved by specifying the backward_key property in the relation definition, which is commented out in this example for demonstration purposes. But this is rather non-obvious behavior. In the event that the associated table needs to be expanded with additional data, as in this example, the source of the problem becomes unclear, since it is not clear where custom_books_id came from, especially when looking at a table whose columns are marked as described in the model:
Since the most expected behavior is for the developer to be unaware of these subtleties and expect the code to work as described, is it possible to make this situation more consistent?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
With the following model description:
The following code:
Ends with an exception:
Since the names for relations are created:
student_id
andbook_id
, according to the names described in the model, in the format[association_model_field_name]_id
, while they are requested in a different format[relation_table_name]_id
- for the field, in which defines the relation and[association_model_field_name]_id
for the second field.This problem is solved by specifying the
backward_key
property in the relation definition, which is commented out in this example for demonstration purposes. But this is rather non-obvious behavior. In the event that the associated table needs to be expanded with additional data, as in this example, the source of the problem becomes unclear, since it is not clear wherecustom_books_id
came from, especially when looking at a table whose columns are marked as described in the model:Since the most expected behavior is for the developer to be unaware of these subtleties and expect the code to work as described, is it possible to make this situation more consistent?
Beta Was this translation helpful? Give feedback.
All reactions