On Thursday, December 13, 2018 at 12:43:42 PM UTC-8, Ben Alavi wrote: > > Oh yep just got there! > > So I think I see what you mean -- if a and o already had the same > reciprocal association set you could avoid the same issue by checking for > that as well...something like: > > remove_reciprocal_object(opts, a) if a && a.associations[opts.reciprocal] > != self > > ...and then you could still check no_set_assoc if that is indeed any > faster as a performance improvement for the case where a == o -- I'm not > sure if it would be any faster to justify the extra logic > > remove_reciprocal_object(opts, a) if a && (no_set_assoc || > a.associations[opts.reciprocal] != self) > > ...and then I guess it might make sense to do the same thing when adding > the reciprocal object (don't add it if it's already set) > > add_reciprocal_object(opts, o) if o && o.associations[opts.reciprocal] != > self > > ...again I'm not sure what the performance gain (if any) would be to skip > the extra add >
The logic I used ended up being similar: https://github.com/jeremyevans/sequel/commit/961f10d76ed93da708d0febe17d65f7d51f4a928 I think the new logic fixes the case where the set_associated_object_if_same flag is set and a one_to_one association is used, but the reciprocal of the already associated object doesn't match the current object. That shouldn't happen with nested_attributes, because you can't pass in an existing object, nested_attributes always instantiates new associated objects (either from scratch or from pulling the related rows from the database). Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
