[5.8] Fixed queue jobs using SerializesModels losing order of passed in collections#29136
Conversation
|
Are there performance implications on large collections with this? I'd rather default to the current implementation and order, if necessary, in the job itself. |
|
Serialization tests are failing. |
|
Fixed the failing tests by skipping the order recovery step for pivot records. Kinda share the performance concern, but with collections of tens or hundreds of thousands of items you'd run into memory limitations before cpu imo. The memory footprint shouldn't be too bad since both original and sorted collections are referencing the same objects. But I'm just guessing. 🙃 The current fix makes for some awkward code, maybe someone else has a better idea? Alternatively we could document this as a known limitation as it's definitively an unexpected behaviour atm. |
|
StyleCI is failing. |
|
Sorry, thought these get merged automatically, fixed now. |
SerializesModelsis a trait for queue jobs that converts passed in models and collections to keys on serialization and restores them back from database when unserialized.The current implementation loses the intended order for passed in collections.
Eg. let's say we have a queue job exporting users sorted by email address.
Now on unserialization, Laravel doesn't know about the order clause and runs a simple WHERE IN query, which returns the records in the original order as inserted into db.
The proposed fix adds an extra step where the restored collection is re-mapped based on the serialized collection of keys which is in the correct order, thus restoring the intended order.
Included an integration test demonstrating the issue.