Allow setting dynamic component templates from dictionary in ByCode #1941
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hazzik
reviewed
Feb 26, 2019
src/NHibernate.Test/MappingByCode/ExplicitMappingTests/DynamicComponentMappingTests.cs
Outdated
Show resolved
Hide resolved
fredericDelaporte
changed the title
fredericDelaporte
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Feel free to try your suggestions directly here if you wish. I have less time available currently for contributing, and I am not prioritizing this PR over other PRs. I will probably not look into the trouble raised by Alexander before next week-end. |
Ok I've checked the code and my suggestions are not really helpful. I don't know how to make this delegate work without huge refactoring |
hazzik
reviewed
Mar 13, 2019
src/NHibernate/Mapping/ByCode/Impl/CustomizersImpl/PropertyContainerCustomizer.cs
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
hazzik
reviewed
Mar 25, 2019
| #pragma warning restore 618 | ||
| } | ||
|
|
||
| [Obsolete("Please use GetRequiredPropertyOrFieldByName instead.")] | ||
| public static MemberInfo GetPropertyOrFieldMatchingNameOrThrow(string memberName) |
There was a problem hiding this comment.
Having this method static really sucks.
hazzik
reviewed
Mar 25, 2019
src/NHibernate.Test/MappingByCode/ExplicitMappingTests/DynamicComponentMappingTests.cs
Outdated
Show resolved
Hide resolved
bahusoid
reviewed
Mar 25, 2019
src/NHibernate/Mapping/ByCode/Impl/CustomizersImpl/PropertyContainerCustomizer.cs
Outdated
Show resolved
Hide resolved
bahusoid
previously approved these changes
Mar 25, 2019
hazzik
changed the title
hazzik
force-pushed
the
rjperes-ByCodeDynComp
branch
2 times, most recently
from
4e02aa9 to
492c29a
Compare
hazzik
previously approved these changes
Mar 29, 2019
Fixes nhibernate#913 - NH-3704 Co-authored-by: Alexander Zaytsev <hazzik@gmail.com> Co-authored-by: Frédéric Delaporte <12201973+fredericdelaporte@users.noreply.github.com>
fredericDelaporte
force-pushed
the
rjperes-ByCodeDynComp
branch
from
492c29a to
cc2ed3b
Compare
|
Rebased and squashed, for allowing merging while keeping its original author. |
hazzik
approved these changes
May 28, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #913 - NH-3704
Replaces #341. It is a rebase of it, with fixes required due to changes in NHibernate.
The original PR repository being deleted, I do not see any way to work with it other than opening a new PR.
The original PR was put in the 6.0 milestone, but it does not have breaking changes. It can be put in the 5.3 milestone.
There was a discussion about the implementation relying on dynamically building a type matching the component. It allows to re-use the existing By-Code logic working on anonymous types, rather than coding a whole new code path for mapping dynamic components by code. It is a bit runtime heavy way of doing things, but it seems doing it another way will require a bit to much changes in By-Code.
If approved, it should be manually squashed before merging, in order to keep Ricardo as the main author.