New functionality: Comment search

[taddyb]

Description:

The user goes to analysis and can search for posts based on comments.

Use Case:

Burda wants to see everyone's scores who did a 4x10min workout. He can search 4x10min and see everyone's post from that workout.

[rmdmattingly]

That's a great idea

[rmdmattingly]

This expands on something I've been thinking about: analyses which take in an input. I think on the service/back end we should just continue to pass argv variables and expect them to be present when a given service is called. I can tweak the frontend to allow people to fill out parameters when a given analysis requires them

[rmdmattingly]

We'll also probably want this service to accept a date range for the case where I want a 4x10, but not every 4x10

[taddyb]

I started the code for the analysis in the commentSearch branch. Not requesting a pull at this time since the API doesn't accept inputs @rmdmattingly

Anything I can do in the API to help?

[rmdmattingly]

I might be able to get to this today, definitely by EoD tomorrow. It won't be too hard, just modifying an endpoint and making sure that the indexing looks right to handle querying on the comment field

[taddyb]

If we want to pass a comment through the command line, we would have to modify this line in main.py

def parseInput():
    if len(sys.argv) > 1:
        return sys.argv[1]
    return 'invalidService'

Would you want to have a second arg passed for the comment, or make something like a -c or -m since comments are optional search terms? @rmdmattingly

[rmdmattingly]

I'll make a change to how parseInput() works so that it returns all of sys.argv. From there we'll just need to make assumptions regarding what the parameters will be based on the service I think?

Like for the comment search service we'll know that sys.argv[2] is the parameter to be searched against comments in the db and can handle all that in its main.py container function (like, pass sys.argv[2] into the run method of the comment search service, rather than passing in all of sys.argv). Ideally never deal with sys.argv on the service level.

Does that make sense/sound good?

[rmdmattingly]

I'm also going to modify how we handle passing parameters to the getWorkoutData function, I think it'd be better to have optional params than have other functions be passing in empty strings for the comment var for no reason

[taddyb]

Sounds great. Since this is never run at the command level by the user, no need for -m options. 👍