Sequence issue with new fixture population code on postgres

[ErisDS]

I'm seeing a regular test failure on postgres only, that indicates that fixture population operations are not always happening in the correct order/sequence. I've definitely seen this on node v4, not sure about v0.12 and v0.10.

The error is with the "should populate all fixtures correctly" integration test that I added to core/test/integration/migration_spec.js before I did the refactor, in order to prove that both versions did the same thing. The problem is happening in a special assertion I wrote which is intended to check that each permission gets assigned to the correct roles.

The error is as follows:

�[0m  1) Database Migration (special functions) Fixtures should populate all fixtures correctly:
... (big perms object here) ...
 expected Array [ 'Editor', 'Administrator', 'Author' ] to equal Array [ 'Administrator', 'Editor', 'Author' ] (at '0', A has 'Editor' and B has 'Administrator')�[0m�[90m
      at Assertion.fail (node_modules/should/lib/assertion.js:91:17)
      at Assertion.Object.defineProperty.value [as CompletePermissions] (node_modules/should/lib/assertion.js:163:19)
      at core/test/integration/migration_spec.js:177:59
      at tryCatcher (node_modules/bluebird/js/release/util.js:16:23)
      at Promise._settlePromiseFromHandler (node_modules/bluebird/js/release/promise.js:503:31)
      at Promise._settlePromise (node_modules/bluebird/js/release/promise.js:560:18)
      at Promise._settlePromise0 (node_modules/bluebird/js/release/promise.js:605:10)
      at Promise._settlePromises (node_modules/bluebird/js/release/promise.js:684:18)
      at Promise._fulfill (node_modules/bluebird/js/release/promise.js:629:18)
      at PropertiesPromiseArray.PromiseArray._resolve (node_modules/bluebird/js/release/promise_array.js:125:19)
      at PropertiesPromiseArray._promiseFulfilled (node_modules/bluebird/js/release/props.js:78:14)
      at Promise._settlePromise (node_modules/bluebird/js/release/promise.js:565:26)
      at Promise._settlePromise0 (node_modules/bluebird/js/release/promise.js:605:10)
      at Promise._settlePromises (node_modules/bluebird/js/release/promise.js:684:18)
      at Async._drainQueue (node_modules/bluebird/js/release/async.js:126:16)
      at Async._drainQueues (node_modules/bluebird/js/release/async.js:136:10)
      at Immediate.Async.drainQueues [as _onImmediate] (node_modules/bluebird/js/release/async.js:16:14)

The order of attribution of roles to permissions is not actually important, so this could be fixed by updating the assertion to not care about order.

However, as all the operations are done using sequence, I would expect them to always be the same? The tests are not failing on sqlite3 or MySQL, so I'm interested to get some feedback from someone who knows postgres on why the behaviour here is different and what a correct fix to preserve order might be.

[jaswilli]

Disclaimer: I haven't looked at this specific problem. However, I know from experience with these errors in the past that sometimes it's actually a bug and Postgres just happens to work slightly faster/different and that's why you see the failure there.

[ErisDS]

Ok, I've been playing around with this, and I think I've figured out what's happening.

The roles and permissions are all getting inserted in the correct order, whoop. I've not seen a single case where they aren't.

However, the fetch for permissions with their roles don't provide a specific order to return the related results in. MySQL and SQLite both always seem to return these things ordered by their primary key by default no matter what, pg seems to be more flexible about the whole thing.

Seeing as the order doesn't actually matter in this case, I can update the assertions to not care and be happy that nothing horrid is happening here.