Feature/voyages past merge #200
Open
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
…ing identities. Bumping the migration stage to 2 (see settings.py)
(owner/captain) in the migration code. The legacy table source is used to override the non-specific role in the voyage connection if it already exists for voyage and enslaver.
Implemented a function to execute the migration actions in a db transaction.
JohnMulligan
suggested changes
May 26, 2023
I removed the specific versions and upgraded the ubuntu image to 20.04.
specific information, namely, an exported count field, which is modeled as a single-enslaver relationship of type 'Export' with unnamed_enslaved_count set to the exported count.
Multidigit role ids, e.g., "11" could cause false positive matches
when say, searching for role=1. We now ensure that the cached
role strings are surrounded by commas so that we can search
by ',{role},' and thus avoid this bug.
throughout the code base. Where appropriate, the names are fetched using the helper, which means no further changes will be required for those.
- Some of the imputed variable names used abbreviations instead of the prefix (e.g. FEML instead of FEMALE).
The empty contents (original voyage info) would apply a ".blank" class on the div, which in turn caused the element to be hidden and the other cells would shift left. We now apply the class to the span child of the div, so that the div still occupies the space to keep the proper layout.
The issue was that the old entries were not being deleted first which would cause a duplicate key.
single objects being indexed (e.g. by the Haystack Realtime signal processor) are fully pre-loaded through the use of VoyagesFullQueryHelper).
search_indexes.py and publication.py, and this class loads EnslaverRole objects in the constructor, which means that if that table does not exist (e.g. before applying a migration that creates it) we get an error that blocks applying the very migration that is needed to get it working. Fixed by using a singleton pattern for the helper where the actual instance is created only when get_instance is called and we are *not* placing such calls eagerly.
i) Python's expression "not <variable>" evaluates an empty enumerable <variable> as True, which was not the behavior we want to yield a BadRequest. ii) When emitting the bad request, we should use the f-string to print the list, the concatenation causes an Error to be thrown.
The internal column headers can now assume two values (e.g. FEMALE vs FEML) and in order to properly save the cell contents, we have to pick one of those. Luckily, only the IMP (imputed) rows, use the shorter headers, so we can easily reconstruct the right var name for serialization.
(SlaveNumbersTable) overwriting pre-existing values if necessary.
…ST Database pages
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.
This work moves the captain and ship owner data to PAST, linking the Voyages (TAST/IAM) and PAST databases.
VOYAGE_ENSLAVERS_MIGRATION_STAGE is set in settings.py to determine which "stage" of the migration we are in. This PR puts us at stage 3, meaning that after a Solr update index, the data displayed on the Voyages interfaces will be coming from PAST tables (we still keep the legacy Captain and ShipOwner tables around in this stage).