search

loopbackio / loopback-connector-elastic-search

Strongloop Loopback connector for Elasticsearch
MIT License
79 stars 56 forks source link

Multi-index automigration and per-model settings #23

Closed fabien closed 9 years ago

fabien commented 9 years ago

Automigrate now correctly recreates an index (delete, create, set mapping) - fixes #20 Additionally, Model.settings.elasticsearch can be used to set defaults (index, type).

@pulkitsinghal

pulkitsinghal commented 9 years ago

@raymondfeng - I'm not sure who is in charge of community tests, can you please point me to the right person so I can begin to understand how to make the tests pass?

fabien commented 9 years ago

@pulkitsinghal I was able to run all tests successfully by editing `test/resource/datasource-test.json' to point to my local ES install:

56 passing (1m)
  3 pending
  1 failing

The one failing test is related to the default sort order (by id).

pulkitsinghal commented 9 years ago

@fabien - can you paste a bit more info around the stack that it fails with after turning on trace level logging in `test/resource/datasource-test.json'? Thanks!

fabien commented 9 years ago

@pulkitsinghal 

 1) Connector should build a query for the WHERE filter:

      AssertionError: expected { Object (sort, query) } to deeply equal { query: { bool: { must: [Object] } } }
      + expected - actual

                 }
               }
             ]
           }
      +  }
      -  },
      -  "sort": [
      -    "id"
      -  ]
       }

      at Assertion.assertEqual (/Users/fabien/Development/github.com/fabien/loopback-connector-elastic-search/node_modules/chai/lib/chai/core/assertions.js:439:19)
      at Assertion.ctx.(anonymous function) [as equals] (/Users/fabien/Development/github.com/fabien/loopback-connector-elastic-search/node_modules/chai/lib/chai/utils/addMethod.js:40:25)
      at Context.<anonymous> (/Users/fabien/Development/github.com/fabien/loopback-connector-elastic-search/test/01.filters.test.js:43:24)
      at Test.Runnable.run (/usr/local/lib/node_modules/mocha/lib/runnable.js:196:15)
      at Runner.runTest (/usr/local/lib/node_modules/mocha/lib/runner.js:373:10)
      at /usr/local/lib/node_modules/mocha/lib/runner.js:451:12
      at next (/usr/local/lib/node_modules/mocha/lib/runner.js:298:14)
      at /usr/local/lib/node_modules/mocha/lib/runner.js:308:7
      at next (/usr/local/lib/node_modules/mocha/lib/runner.js:246:23)
      at Object._onImmediate (/usr/local/lib/node_modules/mocha/lib/runner.js:275:5)
      at processImmediate [as _immediateCallback] (timers.js:345:15)
pulkitsinghal commented 9 years ago

@fabien - i didn't mean the mocha tests, i meant that i don't know why the jenkins checks are failing or what they are even

fabien commented 9 years ago

@pulkitsinghal right, I was wondering about that, too. Jenkins is CI, but it appears to be misconfigured to run the tests correctly. I looked at one of the failed Jenkins attempts, but I couldn't immediately see what the issue was. I suspect here, too, a wrong ES connector host config was the issue.

Thanks for merging this!