Simi Hartstein
Simi Hartstein
@MichaelSwigerAtBentley Thanks for taking care of this. Looks like the PR is approved. Any reason it's being held up?
@khanaffan Thanks I will verify the effect of `usePrimaryConnection` option. However, I'm fairly certain this problem persists through calls to `iModel.saveChanges()`, seeing as the properties grid is still broken after...
@khanaffan I can confirm: * The issue does not happen with the `usePrimaryConn: true` setting. * I am calling `iModel.saveChanges()` between invocations of `iModel.createQueryReader`. It does not pick up changes...
Someone else on my team can't reproduce the issue with simplified code. I will need to look into my use-case more...
It's still relevant... I will be refactoring the code where I saw the issue shortly and will test it out again afterward.
Thanks @GytisCepk. The entity object comes directly from core using `iModel.relationships.getInstance`, so if that is the issue, it would need to be fixed in this repo.
@MichaelSwigerAtBentley Hi Michael. Sorry for the delay and confusion. Despite the Github issue title (that I corrected), I am using the new `Entity.forEach` in 5.0. I am travelling and won't...
I can still reproduce this as of 5.0.4. I can send you a briefcase with the issue if that would help
Ah. I thought this had been backported. I updated to 5.1 and can confirm it's fixed!
Hmm. That's a good point. I guess we don't have a system to internally try to grab locks again... Adding it to `cancelTo` would still be an improvement, but by...