angus
(Angus McLeod)
July 12, 2019, 10:46am
4
Yes, it’s cropped up a few times in the past. This latest rash seems to coincide with recent work on the has_custom_fields.rb
concern, so there may be something to review there.
This doesn’t fix it, but helps to address it if it arises:
discourse:master
← angusmcleod:add_limit_to_custom_field_ordering
opened 10:36AM - 12 Jul 19 UTC
While not likely, it is possible to end up with two rows in a custom field table… with the same related id.
See further: https://meta.discourse.org/t/custom-field-casting-affected-by-recent-update/122746
For example: https://discourse.angusmcleod.com.au/t/events-code-error-500/1254/4
The data will look something like this.
``topic_custom_fields``
| id | topic_id | name | value |
| ------------- | ------------- | ------------- | ------------- |
| 9180 | 62 | event_start | 1563100201 |
| 9179 | 62 | event_start | 1563100201 |
In most respects this eventuality can be handled in a plugin, however there is one place where this causes a cardinality issue that can't be handled in a plugin: ordering by the custom field in a ``TopicQuery``.
This PR adds a LIMIT to the custom field ordering statement in ``TopicQuery`` to handle that eventuality.