Closed grzesiek2010 closed 1 week ago
Marking this as "needs testing" early as the requested changes are just for tests.
In that Slack conversation, I had some questions about whether we should do this at all given how surprising the outcome is.
I think our only real alternative would be to throw an exception when processing. The advantage of an exception is that it would at least tell the user that something unexpected happened. But given that we're very likely going to address the issue on the server side, this case would only be for other hypothetical servers. Let's go with it.
Tested with Success
Verified on device with Android 15
Verified cases:
Tested with Success
Verified on device with Android 10
Closes #6501
Why is this the best possible solution? Were any other approaches considered?
The real issue here is that SQLite is case-insensitive, so attempting to add columns with names like
col
andCol
results in an exception. I don't think we need to implement any special handling for this, as it doesn't make much sense to add such properties in the first place. Therefore, I believe filtering out duplicates is a good solution.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
It should be enough to test entities with duplicate properties like
col
andCol
.Do we need any specific form for testing your changes? If so, please attach one.
No.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest
(or./gradlew testLab
) and confirmed all checks still passDateFormatsTest