-
-
Notifications
You must be signed in to change notification settings - Fork 67
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
added requestcounts endpoint #393
Conversation
Request.ncname.in_(ncList) if ncList else True, | ||
Request.requesttype.in_(requestTypes) if requestTypes else True | ||
] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im thinking that we might want to adjust this to hit data service with countFields and filters and create an aggregateQuery method in dataservice....so functionality will look like
select [countFields] from table where [filters]
Then do a pandas groupby(countFields).size()
Should follow something like this https://stackoverflow.com/a/38933130
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason behind this is to keep the database logic separate from any of the services which will make testing/validation much easier(when we get around to it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that makes sense, I can move the database logic into the dataservice. We might want to get away from constructing SQL queries by string concatenation though, it's kind of error-prone and hard to read. The ORM in sqlalchemy basically generates (and executes) SQL queries in a cleaner way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah i agree, we can def tweak the existing query method to use the orm instead of creating a 💩 query string
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created #398 in the meantime so whoever takes it can use your code as an example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok cool, yeah I'll take that one. I can work on it while I'm creating the aggregationQuery in the dataservice. I like the aggregationQuery concept, could be useful for other endpoints down the line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thanks!!
Im hoping that with query and aggregationQuery itll keep the backend to easy categorization of services. Either getting a single thing, a lot of stuff, or a summary of groupings
That way there wont be weird complex querying per endpoint
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I gave the aggregationQuery a shot, also removed SQL string concatenation and used ORM instead in the pins service and request detail service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏 bravo!! I like what you've done,
The endpoint provides data for both of the pie charts -- request types and how people contact 311.