Hi,
I just tried updating to the latest Relinq and discovered the clone bug is still present. It has been there a while now. 😊
Here is a test case in my forked repro showing the problem:
https://github.com/gordonwatts/Relinq/commit/06ba52ab38dbbbcaf22633a0227ab72738a58d37
And a code modification that fixed the problem:
https://github.com/gordonwatts/Relinq/commit/c9fb978dc2559bab2d969280e1931a2105d6d97b
When I first reported this you wanted to think through the cloning and make sure that it was doing the right (or not right) thing. And you were also in the middle of doing a big step in the version.
I’d love to move to the new version (I’m back on 2.0.X), but without getting this fixed I can’t. Any chance this could be slotted into the queue? I’ve not tried to move my code modifications to the head of the repro yet, but if you think my approach is right, then I am willing to form this into a pull request.
Many thanks in advance!
Cheers,
Gordon
Hi,
I don’t think I did? At anyrate, I’ve created a new one:
https://www.re-motion.org/jira/browse/RMLNQ-111
I do think this is a non-breaking issue. I made the modification below and I’ve been running it in production for about 6 months now – with very complex QM’s, and I’ve not seen any sign of a problem. So, unless the fact that the clone is executed twice in the first place indicates a deeper logic flaw, then this fix is fine, and I think it will perturb nothing else. While I’d be willing to bet beer on this, probably not $1000 bucks, if you are curious about my level of confidence. 😊
Cheers,
Gordon
To unsubscribe from this group and stop receiving emails from it, send an email to re-motion-users+unsubscribe@googlegroups.com.
To post to this group, send email to re-motion-users@googlegroups.com.
As always, thanks for all the time and effort you put into this. It is a great tool!