Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Provider specific ExpressionFragmentTranslators should override default ones #6691

Closed
maumar opened this issue Oct 5, 2016 · 1 comment
Closed

Provider specific ExpressionFragmentTranslators should override default ones #6691

maumar opened this issue Oct 5, 2016 · 1 comment
Assignees
@maumar
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone
1.1.0

Comments

@maumar
Copy link
Contributor

maumar commented Oct 5, 2016

Currently provider specific ExpressionFragmentTranslators will not be executed if we have a default translator for the same fragment. This happens because provider specific translators are added to the end of the list of translators, so the default ones run first. We should switch the order so that provider specific translators run first.
@maumar maumar mentioned this issue Oct 5, 2016
Merged
@maumar
Copy link
Contributor Author

maumar commented Oct 5, 2016

fixed in 886464b

@maumar maumar closed this as completed Oct 5, 2016
@maumar maumar added the type-bug label Oct 5, 2016
@maumar maumar added this to the 1.1.0 milestone Oct 5, 2016
@maumar maumar self-assigned this Oct 5, 2016
@rowanmiller rowanmiller added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Oct 12, 2016
@rowanmiller rowanmiller modified the milestones: 1.1.0-preview1, 1.1.0 Oct 12, 2016
@ajcvickers ajcvickers modified the milestones: 1.1.0-preview1, 1.1.0 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@maumar maumar

Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Projects
None yet
Milestone
1.1.0
Development

No branches or pull requests
3 participants
@ajcvickers @maumar @rowanmiller