-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ContentManagerSession in GetMany #8705
base: 1.10.x
Are you sure you want to change the base?
Use ContentManagerSession in GetMany #8705
Conversation
@BenedekFarkas forgot to tag you in the main post |
I'll need a few days to get down to testing it properly, but it looks good on first glance! |
@BenedekFarkas I just realized this is still open. My tests still look good, But I'm still not too fond of the code I wrote. |
Well, DefaultContentManager is very old, so there's probably a lot of stuff we could refactor (which sort of affects what you can achieve there). I wouldn't merge it without unit/Spec testing completing on it first but being able to run tests is still blocked by me (#8686). We could also add some specific tests to verify this change, if necessary. |
…t_many_skip_queries
this is targeted at 1.10.x, so I think specflows should be able to run... I'll get back to you on this. |
I merged the latest 1.10.x into the branch for this PR and I was able to run all specflows. |
…t_many_skip_queries
…onal duplicate queries
I'm still not 100% on this solution. |
This is the first hacky attempt. I'm not satisfied with the code: I look at it and it feels like it's doing some stuff too many times where it shouldn't.
Anyway, it does reduce the number of repeated calls to the database. In some setups, that may become significant.
I haven't had a chance to properly test this, or measure the timing performance, to make sure that we aren't losing time in the work we do to avoid calls to the db.
To summarize, my concerns with my code in this PR right now: