Genie app #1
Genie app #1
Conversation
… total number of applications they have
| job_query = job.query_as(:job). | ||
| # match Jobs which received applications from users who also also applied to the given job | ||
| match("(job:Job) <-[:APPLIED_TO]- (similarUser:User) -[:APPLIED_TO]-> (recommendedJob:Job)"). | ||
| break. |
There was a problem hiding this comment.
Just discovered that
match
(job:Job) <-[:APPLIED_TO]- (similarUser:User) -[:APPLIED_TO]-> (recommendedJob:Job),
(recommendedJob) <-[applications:APPLIED_TO]- ()
is not the same as
match
(job:Job) <-[:APPLIED_TO]- (similarUser:User) -[:APPLIED_TO]-> (recommendedJob:Job)
match
(recommendedJob) <-[applications:APPLIED_TO]- ()
We need the break to produce 2 match statements.
In the first case, it would basically select all the jobs which had applicants if I'm not mistaken. In the second case, the second match works off of the results of the first match, which is what we want.
| job_query = job.query_as(:job). | ||
| # match Jobs which received applications from users who also also applied to the given job | ||
| match("(job:Job) <-[:APPLIED_TO]- (similarUser:User) -[:APPLIED_TO]-> (recommendedJob:Job)"). | ||
| with("recommendedJob", "similarUser"). |
There was a problem hiding this comment.
edit: I replaced the break statement, with a WITH statement, which might be faster from what I've read.
Just discovered that
match
(job:Job) <-[:APPLIED_TO]- (similarUser:User) -[:APPLIED_TO]-> (recommendedJob:Job),
(recommendedJob) <-[applications:APPLIED_TO]- ()
is not the same as
match
(job:Job) <-[:APPLIED_TO]- (similarUser:User) -[:APPLIED_TO]-> (recommendedJob:Job)
match
(recommendedJob) <-[applications:APPLIED_TO]- ()
We need the break to produce 2 match statements.
In the first case, it would basically select all the jobs which had applicants if I'm not mistaken. In the second case, the second match works off of the results of the first match, which is what we want.
| before_action :find_user | ||
| before_action :find_job | ||
|
|
||
| attr_accessor :user, :job |
There was a problem hiding this comment.
I like this. We should do this more often.
| class RecommendationConsumer | ||
| include Hutch::Consumer | ||
|
|
||
| consume "copro.recommendations.*" |
There was a problem hiding this comment.
we can have multiple wild cards. Since it seems like we want model and the action, it could be like copro.recommendations.*.* . I feel like this is the more natural way to handle it with routing keys rather than splitting
| gem 'sqlite3' | ||
| gem "rails", "~> 4.2.6" | ||
| # Use Postgres as the database for Active Record | ||
| gem 'pg' |
There was a problem hiding this comment.
do we need pg if we are using active nodes?
There was a problem hiding this comment.
It's just to keep heroku happy. I would have had to create the app with the option to exclude the ORM fully I think. I didn't bother with that, because I thought we might want it later as well, if we want to have an admin or something like that.
| gem 'rails', '4.2.5.1' | ||
| # Use sqlite3 as the database for Active Record | ||
| gem 'sqlite3' | ||
| gem "rails", "~> 4.2.6" |
| group :test do | ||
| gem "capybara", "~> 2.7" | ||
| gem "launchy" | ||
| end |
There was a problem hiding this comment.
Some comments of what gems are for would be nice, Im thinking of a junior coming in and not knowing anything about the gems.
There was a problem hiding this comment.
Versions need to be properly filled as well, otherwise, as it's the case on platform it's gonna be impossible to properly update the gems with bundle update
…t clause, because it creates the wrong query WHERE NOT(a AND b AND c)
No description provided.