Skip to content
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

Support for Full Text Search Query #541

Merged
merged 3 commits into from
Jan 15, 2018

Conversation

dplewis
Copy link
Member

@dplewis dplewis commented Jan 10, 2018

Supersed: #470
Closes: parse-community/parse-server#4490, #476

To be used with Parse-Server 2.5.0+

  • Fixed docs typos
  • Lint Test files
  • Remove unnecessary code from past tests
  • Bump parse-server to 2.7.1

@codecov
Copy link

codecov bot commented Jan 10, 2018

Codecov Report

Merging #541 into master will increase coverage by 0.03%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #541      +/-   ##
==========================================
+ Coverage   84.59%   84.62%   +0.03%     
==========================================
  Files          48       48              
  Lines        3952     3960       +8     
  Branches      897      900       +3     
==========================================
+ Hits         3343     3351       +8     
  Misses        609      609
Impacted Files Coverage Δ
src/ParsePolygon.js 0% <ø> (ø) ⬆️
src/ParseQuery.js 94.13% <100%> (+0.12%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ee33c48...3cd3f7c. Read the comment docs.

@dplewis
Copy link
Member Author

dplewis commented Jan 10, 2018

@flovilmart and @SebC99 can you look over this?

@SebC99
Copy link
Contributor

SebC99 commented Jan 10, 2018

Why don't you use the diacritics, language and casesensitive options?
As for the doc I know the rest call needs a key but mongo doesn't, so we shouldn't say in the docs that the key will be the search field as mongo will use the text index without looking at the key.
Apart from that I'm ok with it! Thanks!

@dplewis
Copy link
Member Author

dplewis commented Jan 10, 2018

That is for Parse-Server as a service. We can include them but we have to think about the current and future database adapters. Postgres requires a key for example and you have to install an extension for diacritics option. We should go for something simple here out of the box. The RestApi should be sufficient for specific full text search queries.

Copy link
Contributor

@montymxb montymxb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, this looks pretty good for getting this in place. Some questions about removed code and suggestions for error test cases.

I wouldn't stress too much on the 'additional' features for full text, as this isn't going to be released just yet. It'll be nice to have this in place, we can guarantee we will at least have simplistic full text support in this sdk; rather than none.

@@ -13,15 +13,6 @@ var ParseSchema = require('../ParseSchema').default;
var ParsePromise = require('../ParsePromise').default;
var CoreManager = require('../CoreManager');

function generateSaveMock(prefix) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused?

Copy link
Member Author

@dplewis dplewis Jan 15, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I copied the jest test from another file when I added schema support. Forgot I left those in 😅

return ParsePromise.as([]);
};
var ajax = function(method, path, data, headers) {
var name = path.substr(path.indexOf('/') + 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused here as well?

try {
const query = new ParseQuery('Item');
query.fullText();
} catch (e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than just try/catching I would use expect(...).toThrow('my error...'), that would be much more explicit in terms of that we are expecting and what we are expecting to receive as the error. You can see an example in the parse-server tests.

try {
const query = new ParseQuery('Item');
query.fullText('key');
} catch (e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

try {
const query = new ParseQuery('Item');
query.fullText('key', []);
} catch (e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here

@dplewis
Copy link
Member Author

dplewis commented Jan 15, 2018

@montymxb Thanks for the review, changes added.

Copy link
Contributor

@montymxb montymxb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much better, I'd say this is approved :octocat: .

@dplewis
Copy link
Member Author

dplewis commented Jan 15, 2018

@montymxb I'll start working on the docs after this gets in

@montymxb
Copy link
Contributor

That would be good, that and aggregate as mentioned in #543 (we do have that here right?).

@montymxb montymxb merged commit 7ef1b0a into parse-community:master Jan 15, 2018
@dplewis
Copy link
Member Author

dplewis commented Jan 15, 2018

Yes, quick question should we have documentation in docs folder, the gh-pages branch or both?

@dplewis dplewis deleted the full-text-search branch January 15, 2018 23:45
@flovilmart
Copy link
Contributor

The docs are automatically generated and push by Travis based on the JSdocs in the gh-pages branch, so no need to worry about it

@montymxb
Copy link
Contributor

We'll want docs in the docs repo separately, but you should be good here.

@dplewis
Copy link
Member Author

dplewis commented Jan 15, 2018

@flovilmart Shouldn't http://parseplatform.org/Parse-SDK-JS/api/master/ be in the README so new users can see it or am I missing something?

I can add some examples to be auto generated for aggregate like I did for this PR.

@flovilmart
Copy link
Contributor

flovilmart commented Jan 15, 2018

This is linked into http://docs.parseplatform.org/js/api

@dplewis
Copy link
Member Author

dplewis commented Jan 15, 2018

@flovilmart Ah, I see. I'm so used to going to the guide in the readme instead of the api reference.

@flovilmart
Copy link
Contributor

Yeah, the guide is for the usage, also we have the API references in each repositories

@montymxb
Copy link
Contributor

We should have a link to the API reference on the README 🔖

@flovilmart
Copy link
Contributor

@montymxb
Copy link
Contributor

@flovilmart probably should clarify specifically from the README on github repo page, not already from within the parseplatform.org location. https://github.com/parse-community/Parse-SDK-JS/.

@flovilmart
Copy link
Contributor

Yes I agree ! let's do it, I just posted the links for reference.

@srameshr
Copy link

srameshr commented Jan 27, 2018

How do I install the version where this feature has been merged?

Im on Parse Server 2.7.1 which is installing Parse-JS-SDK @1.11.
The fullText is supported at master: http://parseplatform.org/Parse-SDK-JS/api/master/Parse.Query.html#fullText

Are you going to bump the version of JS-SDK and subsequently include the same version in Parse Server.

Its been 2 weeks since this has been merged. Hoping to see this merged to 1.11.0 at least without the need to upgrade parse server and parse server already points to 1.11.0.

@flovilmart @montymxb @dplewis

@srameshr
Copy link

Guys, can you release a version with this fix or update 1.11.0 to include this?

@srameshr
Copy link

Any updates?

@montymxb
Copy link
Contributor

montymxb commented Feb 1, 2018

@srameshr since this is an enhancement we'll probably wait a bit to bundle this with other features (if any are pending) and any fixes we may want. There's no official release schedule here, but if you feel that what we currently have is sufficient for a release go ahead and open up a separate issue for that. We can focus on talking about a release there, rather than mixing topics on this PR thread.

@srameshr
Copy link

srameshr commented Feb 1, 2018

@montymxb Yup, will do that.
But, I also think opening up an issue just to remind some other fix has to be merged would not make much sense.

@montymxb
Copy link
Contributor

montymxb commented Feb 1, 2018

If you open up another issue keep it focused on a request for a release and your reason why. We may still hold it back if we decide we want to add more than what we currently have. This isn't necessarily another fix that needs to be merged, this just brings it to our attention so we can evaluate it formally.

@srameshr
Copy link

srameshr commented Feb 1, 2018

Shouldn't what needs to be merged, be evaluated on current needs of the community / users instead of how big the fix is or you deciding what is more than what you currently have?

@montymxb
Copy link
Contributor

montymxb commented Feb 1, 2018

Absolutely, so please open up an issue for that topic so we can all deliberate on that specifically. Since this is a topic for a given PR that has been merged I would consider what you're talking about as a separate topic, i.e. drafting a release. Moving the convo there will allow us to have that focused on input for said topic specifically, and if it makes sense we'll go ahead and draft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants