Remove SpecialistDocumentEdition#document_type #849
Merged
Conversation
This file contains 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
chrisroos
approved these changes
Mar 13, 2017
|
@chrisroos: Thanks. Rebasing against master and force-pushing in preparation for merging. |
This makes the code more consistent and more of a standard Rails app. A nice side effect is that it serves to distinguish the 'manual' strings from those used in conjunction with `SpecialistDocumentEdition#document_type`.
I want to remove `SpecialistDocumentEdition#document_type` which is now always set to 'manual'. In this commit I'm trying to make it clearer that `ManualIndexableFormatter#type` is not related to `SpecialistDocumentEdition#document_type`; it's a document type for use in Rummager and not used *internally* within this app.
I want to remove `SpecialistDocumentEdition#document_type` which is now always set to 'manual'. In this commit I'm trying to make it clearer that the 'manual' strings used in `ManualPublishingAPIExporter` are not related to `SpecialistDocumentEdition#document_type`; in this case they're the name of the schema and the document type sent to the Publishing API and are not used *internally* within this app.
I want to remove `SpecialistDocumentEdition#document_type` which is now always set to 'manual'. In this commit I'm trying to make it clearer that these 'manual' strings are not directly related to `SpecialistDocumentEdition#document_type`; in this case they're just used by `PermissionChecker`.
I want to remove `SpecialistDocumentEdition#document_type` which is now always set to 'manual'. In this commit I'm trying to make it clearer which magic strings do actually relate to this attribute.
Since this commit [1] this can only ever be 'manual' and so we can simplify the code by making this the default value of the Mongoid field and avoiding specifying it in all the places where it was previously being set. [1]: 723ce32
Since this commit [1] all editions are of 'manual' document type, so these `where` conditions are redundant. [1]: 723ce32
To keep thing simpler, I'm going to hold off adding a migration to remove this field from existing persisted instances for the moment.
floehopper
force-pushed
the
remove-specialist-document-edition-document-type
branch
from
ea7f8f2
to
de67f0d
Compare
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.
Since this commit all editions have had a
document_typevalue of 'manual' and so the field had become redundant.Unfortunately the string literal, 'manual', appeared rather a lot throughout the code, so some of the early commits extract these occurrences out into a number of different constants in order to better express their meaning. A couple of these which internal to the app are then gradually refactored away, leaving only ones relating to the Publishing API and Rummager.
For simplicity I've decided not to take the final step of unsetting the
document_typefield on all existing persisted instances ofSpecialistDocumentEditionwithin this pull request, but I would expect to do it very shortly.