[Bug] Performance issues with complex models #238
Comments
|
Thanks for input. In the new year I'll take on reworking the whole property resolution issues. |
|
One thing to look out for is recursion in non-primitive properties, in particular Guid. From my basic exploration, #204 is including static properties, which means that it will get stuck on Guid.NewGuid(). |
|
We have the same issue. Noticed that when our model has a collection of objects, and those objects have datetime/string, the PropertyPathHelper.ToFluentPropertyPath goes into an infinite-loop of adding different nodes to check. It also seemed to add every character of a string as a node to check (because string implement IEnumerable). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using the code from #205, we experience serious performance issues, making this package unusable for us.
We have hundreds of fields in our model with lists of more complex models. Because our form is user-configurable, we have effectively a tree of those complex models. We suspect the performance of
PropertyPathHelper.ToFluentPropertyPathto be the problem.We use this package since 2021 and had never issues with the default MemberNameValidatorSelector.
Concerning the original issue from #204, I think there should be a better way to select the validator of the root model, if needed. It should at least be configurable, as for our project, the previous selection strategy worked better.
It seems like a difficult problem, though, considering #235, #76, and #104.
The text was updated successfully, but these errors were encountered: