Repository navigation
Bring the groups extension to 3.0 - #233
Open
DavidBadura wants to merge 2 commits into
Open
DavidBadura wants to merge 2 commits into
DavidBadura wants to merge 2 commits into
Conversation
|
Hello 👋 Here are the most recent benchmark results, compared against GeneratedHydrator
StackHydrator
StackHydratorWithLazy
StackHydratorWithCryptography
GeneratedHydratorWithCryptography
This comment gets updated every time a new commit comes in. |
DavidBadura
force-pushed
the
populate-without-defaults
branch
from
October 18, 2026 17:48
b756ea4 to
625c869
Compare
DavidBadura
force-pushed
the
groups-property-filter
branch
from
October 18, 2026 17:48
66c312c to
d39ced9
Compare
Hydrating with OBJECT_TO_POPULATE set promoted properties to their default value if their field was missing, so an update overwrote values which were not part of the data. Defaults are now only used for new objects. The generated mappers get an own populate path for classes with promoted defaults, so the code for new objects stays the same.
The GroupsMiddleware of 2.1 passed filtered metadata down the stack, which the mapper chain of 3.0 does not allow anymore. The groups are now applied by the mappers themselves through a new PropertyFilter, which extensions register on the builder. The GroupsExtension registers a GroupsPropertyFilter instead of the middleware. The ReflectionMapper only reads the properties the filter keeps and treats the fields of the others as missing. The generated mappers get an extractFiltered() method and a FilteredMapper which applies the filter around them. The factory only adds it for hydrators with a property filter, so the generated code of all other hydrators stays the same.
DavidBadura
force-pushed
the
groups-property-filter
branch
from
October 19, 2026 06:05
d39ced9 to
bd7b2a0
Compare
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
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.
Closes #231. Builds on #232, which should be merged first, after that the diff only contains the groups.
In 2.1 the
GroupsMiddlewarefiltered the metadata and passed it on in the stack. With the mapper chain of 3.0 a middleware can't change what the mapper reads anymore, so the groups are now applied by the mappers themselves. For that the core gets a small extension point, thePropertyFilter. It is registered withStackHydratorBuilder::addPropertyFilter()and returns the properties to map for a class and a context, ornullfor all of them. TheGroupsExtensionregisters aGroupsPropertyFilter(the selection logic of the old middleware) next to the metadata enricher. The attribute and the context keys stay the same as in 2.1.The
ReflectionMapperonly reads the properties the filter keeps and treats the fields of the others as missing. Their aliases from #237 are removed with them, so a kept property is still read from an alias while the alias of a filtered property is ignored. So groups break circular references again and uninitialized properties outside the groups are not read. The generated mappers get anextractFiltered()method which only reads the kept properties, also private ones of parent classes. The filter itself is applied by aFilteredMapperaround the generated mapper, which the factory only adds for hydrators with a property filter. A first version checked the filter inline and made the generated extract 2.5 to 5% slower in interleaved benchmark runs, with the wrapper there is no measurable difference. TheReflectionMapperchecks inline and is about 1 to 3% slower, I left that for now.The groups tests of 2.1 run against both the reflection and the generated mappers. The docs page of 2.1 is back, and the extensions page explains the property filters. Custom mappers of a
MapperFactoryhave to apply the filter as well,StackHydrator::propertyFilter()returns it.