The ProductVariationStorageInterface offers a function loadEnabled(ProductInterface $product), that returns the enabled product variations for the given product. The implementing class filters by status and additionally dispatches an event to allow further filtering by contrib modules.
By doing the filter query, the original order of the varation, defined by its field delta, gets dismissed. The DB query returns the items in its natural order (which equals the entity id ascending normally), and so does the function. This is unexpected behaviour and leads to strange, inexplicable results, when you resort the variation references and save the product, but still see the same variation selected per default, when you view the product page.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 2691591-11.patch | 3.54 KB | agoradesign |
Comments
Comment #2
agoradesign commentedI'll assign this to me, as I'm currently writing test + patch
Comment #3
agoradesign commentedComment #4
bojanz commentedGreat work! I'll commit after dinner.
Comment #5
agoradesign commentedThanks - enjoy your meal! :-)
Comment #6
agoradesign commented@bojanz: hmmm apparently you had a great romantic dinner with the testbot yesterday! :DDD
Comment #7
bojanz commented@agoradesign
I feel asleep :)
There is no testbot here, DrupalCI doesn't support Composer, that's why we use GitHub and Travis.
I gave this another review:
Unused use statements.
Could we make this a kernel test instead of a web test? We're not testing any UIs, and the kernel tests are much faster.
See the ProductAttributeFieldManagerTest test as an example.
Comment #8
agoradesign commentedI didn't know that about DrupalCI -> daily lesson learned :)
Good points. Will do the change later this day!
Comment #9
agoradesign commentedBefore I'll bang my head into the wall, I'll go home now and watch The Simpsons on tv ;)
I tried to write a kernel test instead, but kept failing...
My testLoadEnabled() function would fail silently without any test results, if I'd try to save the product entity that I create. But here I can "cheat", as I don't need to save product at all becuase ProductVariationStorage::loadEnabled will only fetch the attributes from the product and do the filtering stuff afterwards.
The remaining problem is, that the call to ProductVariationStorage::loadEnabled returns an empty result. So it seems, my variations didn't get saved at all. Given the API documentation and ProductAttributeFieldManagerTest example, kernel tests do have access to the database, so no need to mock queries, etc. But there must be still something missing here... Here's my code so far:
Comment #10
agoradesign commentedIt seems, I'm making progress now... hopefully can add the new patch soon.. Ok, still need more time, but at least I know, what's missing and why the tests fail
Comment #11
agoradesign commentedSo here's the updated patch. Now the test extends \Drupal\system\Tests\Entity\EntityUnitTestBase, which may be changed later to \Drupal\KernelTests\Core\Entity\EntityKernelTestBase, once Commerce is compatible with 8.1.x. I've also moved the class into the Drupal\Tests\commerce_product\Kernel namespace
Comment #12
agoradesign commentedComment #14
bojanz commentedUpdated the test to use EntityKernelTestBase (since we now require Drupal 8.1) and committed. Thanks!
Comment #15
agoradesign commentedYou're welcome :-)
If I was nitpicky, I'd change the assertEqual() calls to assertEquals(), now that EntityKernelTestBase is used, since the first one is now deprecated :D
Comment #16
bojanz commentedFixed that in #2689767: Remove usage of deprecated methods.
Comment #17
agoradesign commentedWow, you're really fast :)
Comment #18
rszrama commentedI loaned him my time machine. : D