-
Notifications
You must be signed in to change notification settings - Fork 121
Add siteID and keyword attributes to Customer and CustomerSearchResult entities
#7860
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.
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
Conversation
Adds siteID attributes to Customer & CustomerSearchResults. Currently the migration test 74_75 is failing when attempting to migrate()
You can test the changes from this Pull Request by:
|
siteID and keyword to siteID and keyword attributes to Customer and CustomerSearchResult entities
| func insertCustomerSearchResult(to context: NSManagedObjectContext, forModel modelVersion: Int) -> NSManagedObject { | ||
| if modelVersion < 75 { | ||
| let customerSearchResult = context.insert(entityName: "CustomerSearchResult", properties: [ | ||
| "customerID": 1]) | ||
| return customerSearchResult | ||
| } else { | ||
| // Required since model 75 | ||
| let customerSearchResult = context.insert(entityName: "CustomerSearchResult", properties: [ | ||
| "siteID": 1, | ||
| "keyword": "" | ||
| ]) | ||
| return customerSearchResult | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly, here I had to use this logic rather than the one I used on insertCustomer(to:forModel:), as we're removing the customerID attribute entirely, migration tests were failing due to incompatibility between models. Happy to refactor if there's a better way to test this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. You might just want to do the old version in-line in the test which uses it, since it'll never be relevant again, but up to you on that one...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
joshheald
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good... a question about the optional keyword, and some general observations, but feel free to merge with or without the optional change.
|
|
||
| @NSManaged public var customerID: Int64 | ||
| @NSManaged public var email: String? | ||
| @NSManaged public var firstName: String? | ||
| @NSManaged public var lastName: String? | ||
| @NSManaged public var billingFirstName: String? | ||
| @NSManaged public var billingLastName: String? | ||
| @NSManaged public var billingCompany: String? | ||
| @NSManaged public var billingAddress1: String? | ||
| @NSManaged public var billingAddress2: String? | ||
| @NSManaged public var billingCity: String? | ||
| @NSManaged public var billingState: String? | ||
| @NSManaged public var billingPostcode: String? | ||
| @NSManaged public var billingCompany: String? | ||
| @NSManaged public var billingCountry: String? | ||
| @NSManaged public var billingPhone: String? | ||
| @NSManaged public var billingEmail: String? | ||
| @NSManaged public var shippingFirstName: String? | ||
| @NSManaged public var shippingLastName: String? | ||
| @NSManaged public var shippingCompany: String? | ||
| @NSManaged public var billingFirstName: String? | ||
| @NSManaged public var billingLastName: String? | ||
| @NSManaged public var billingPhone: String? | ||
| @NSManaged public var billingPostcode: String? | ||
| @NSManaged public var billingState: String? | ||
| @NSManaged public var customerID: Int64 | ||
| @NSManaged public var email: String? | ||
| @NSManaged public var firstName: String? | ||
| @NSManaged public var lastName: String? | ||
| @NSManaged public var shippingAddress1: String? | ||
| @NSManaged public var shippingAddress2: String? | ||
| @NSManaged public var shippingCity: String? | ||
| @NSManaged public var shippingState: String? | ||
| @NSManaged public var shippingPostcode: String? | ||
| @NSManaged public var shippingCompany: String? | ||
| @NSManaged public var shippingCountry: String? | ||
| @NSManaged public var shippingPhone: String? | ||
| @NSManaged public var shippingEmail: String? | ||
| @NSManaged public var shippingFirstName: String? | ||
| @NSManaged public var shippingLastName: String? | ||
| @NSManaged public var shippingPhone: String? | ||
| @NSManaged public var shippingPostcode: String? | ||
| @NSManaged public var shippingState: String? | ||
| @NSManaged public var siteID: Int64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay inconsistent code generation... this isn't a problem, but this is what I meant when I mentioned that I'll often just run the generation to check it works, then revert it and add/update properties on the generated files so that the change is easier to see. No need to do anything, but it's a good practical example.
|
|
||
| @NSManaged public var customerID: Int64 | ||
| @NSManaged public var siteID: Int64 | ||
| @NSManaged public var keyword: String? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add optional keyword property to CustomerSearchResult
Why optional? I don't think it makes sense to have a search result with a nil keyword...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙇 Made the changes discussed in Slack here: 312e9fd by changing keyword to be non-optional and providing a default value so we're sure that the entity conforms to the new schema when migrating
Since we’re making the “keyword” attribute non-optional, we’re also providing a default value to the CustomerSearchResult entity so we can migrate between data models without issues, as any existing CustomerSearchResult would need to have a “keyword” set to it when we’re migrating data sets. With this we also altered the 74_to_75 tests to check migrated entities between data models, rather than new entities in the new data model.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ Looking at the changes here, I think we won't have the correct siteID for Customer and CustomerSearchResult after the migration between 74 and 75 - since the attributes didn't exist in version 74 (the default values will be 0). Do you think we should do heavyweight migration to handle the missing attributes instead?
Thanks for your help on this! In db370f8 a new |
|
Quick update: There's a step missing and tests were passing because of an error here: https://github.com/woocommerce/woocommerce-ios/pull/7860/files#diff-03c54fe20fd9822d0011069f12658bf05260422a448742db92b81c339a6882deR1418-R1419 Currently, in the MigrationTests we're checking if the entities deletion happens in the The missing step is to use |
itsmeichigo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work 🎉
Part of #7741
Apologies for the ~4.5k diff, most of it comes from regenerating the data entities, and the mapping model migration from 74 to 75, when adding
siteIDto the entities that previously didn't have them.Description
When we created the Storage layer and data model for
CustomerandCustomerSearchResulton #7841, we (I) didn't realize that we share the same storage across all sites a merchant may have (we do not hold 1 different database per site, but 1 per all sites). This may cause unintended consecuences when a merchant has more than 1 store in their account, as we wouldn't have a way to filtercustomerIDper site basis when we store fetched customers and results.Changes
This PR updates the
CustomerandCustomerSearchResultby adding a siteID to both entities, as well as substitutingcustomerIDattribute for thekeywordattribute in theCustomerSearchResultentity.CustomerandCustomerSearchResultskeywordproperty toCustomerSearchResultcustomerIDproperty fromCustomerSearchResultWooCommerceModelV74toV75.xcmappingmodelto removeCustomerandCustomerSearchResultsentities in model version 7474_to_75test to MigrationTests to confirm that the properties are correct after the data model migration.MIGRATIONS.mdTesting instructions