Move Spree::Address#name attribute to the db #3908
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
houndci-bot
reviewed
Jan 22, 2021
1d72ede
to
aaf6b9c
Compare
c1caebe
to
b246e59
Compare
kennyadsl
reviewed
Jan 25, 2021
3782935
to
b50c24d
Compare
tvdeyen
reviewed
Jan 26, 2021
This will avoid having automatic getters and setters for these fields and also be present in the list of attributes when the Address is converted into other formats, for example, .as_json
b50c24d
to
a494722
Compare
tvdeyen
approved these changes
Jan 27, 2021
spaghetticode
approved these changes
Jan 27, 2021
4 tasks
spaghetticode
pushed a commit
to nebulab/solidus
that referenced
this pull request
Feb 15, 2021
After solidusio#3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running rake solidus:migrations:migrate_address_names:up will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again.
spaghetticode
pushed a commit
to nebulab/solidus
that referenced
this pull request
Feb 16, 2021
After solidusio#3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running rake solidus:migrations:migrate_address_names:up will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again.
spaghetticode
pushed a commit
to nebulab/solidus
that referenced
this pull request
Feb 26, 2021
After solidusio#3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running rake solidus:migrations:migrate_address_names:up will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again.
spaghetticode
pushed a commit
to nebulab/solidus
that referenced
this pull request
Feb 26, 2021
After solidusio#3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running `rails solidus:migrations:migrate_address_names:up` will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again. Running this task is required when upgrading to Solidus 3.0.
spaghetticode
pushed a commit
to nebulab/solidus
that referenced
this pull request
Mar 5, 2021
After solidusio#3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running `rails solidus:migrations:migrate_address_names:up` will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again. Running this task is required when upgrading to Solidus 3.0.
spaghetticode
pushed a commit
to nebulab/solidus
that referenced
this pull request
Mar 5, 2021
After solidusio#3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running `rails solidus:migrations:migrate_address_names:up` will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again. Running this task is required when upgrading to Solidus 3.0.
spaghetticode
pushed a commit
to nebulab/solidus
that referenced
this pull request
Mar 5, 2021
After solidusio#3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running `rails solidus:migrations:migrate_address_names:up` will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again. Running this task is required when upgrading to Solidus 3.0.
spaghetticode
pushed a commit
to nebulab/solidus
that referenced
this pull request
Mar 8, 2021
After solidusio#3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running `rails solidus:migrations:migrate_address_names:up` will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again. Running this task is required when upgrading to Solidus 3.0.
kennyadsl
pushed a commit
that referenced
this pull request
Mar 9, 2021
After #3908 the table spree_addresses includes the name field, so it can be populated with historical data already present in the table by joining the content of firstname and lastname. Running `rails solidus:migrations:migrate_address_names:up` will take care of the job. The task is arranged in steps that require user input in order to proceed: * the task will exit no-op when no record with blank name is found; * if records are found, the user is asked to confirm before proceeding; * the user is now asked for the record batch size to be used. My tests showed that 100'000 records per batch should balance the necessity to avoid locking records for long and have the script complete without too much overhead; * before migrating data, the user is asked to confirm once again. Running this task is required when upgrading to Solidus 3.0.
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.
Description
Ref #3234
This PR pushes forward the migration to
Spree::Address#nameto replacefirstnameandlastnameattributes. It adds a corresepondingnamecolumn to the DB and replaces all the remaining direct attribute accesses tofirstnameandlastnamewithname.The DB migration contains a blocking warning to force users to evaluate the impact of the upgrade and to choose the correct strategy to handle it in their store. In a future PR we will provide a complementary rake task to migrage existing data fromfirstnameandlastnamecolumns to the newnamecolumns. New stores won't receive any warning and will be able to start working with thenamefield from scratch.☝️ This piece will be moved into a separate rake task.
Checklist:
[ ] I have updated Guides and README accordingly to this change (if needed)[ ] I have added tests to cover this change (if needed)[ ] I have attached screenshots to this PR for visual changes (if needed)