alexbhill / project-pip

According to Urban Dictionary:
8 stars 4 forks source link

Fix "magic numbers" in SQL queries #7

Closed ughitsaaron closed 8 years ago

ughitsaaron commented 8 years ago

A lot of the SQL queries are currently based around an understanding of the names of the columns, etc. used in our data set, so you wind up with strings like, where p.own_id like '%var%'k or where p.propaddr like'%addr%'`, etc. in our codebase.

A future maintainer or open source contributor shouldn't have to have to know p.own_id is the name of the specific column in our data set to contribute to our project.

These values, then, are like "magic numbers".

These constants would be best replaced with a named variable.

ughitsaaron commented 8 years ago

Store everything SQL related in an independent service (called 'sql' or something) that includes,

1) the SQL class being used to query CartoDB, 2) named vars for every SQL var, e.g., p.own_id, etc. with explicit, descriptive names and sufficiently descriptive comments, tables ('e.g., 'property_praxis'), etc. 3) boiler plate strings for SQL queries, e.g. defaultQuery, 4) methods for constructive comparative searches and queries, e.g., like, having, etc.

Ideally, somebody could walk into this and help maintain without having to learn much about SQL.

ughitsaaron commented 8 years ago

Use squel

ughitsaaron commented 8 years ago

squel doesn't actually help. (actually it kind of feels like it adds more boilerplate and confusion.)

i'm going to make a service called sql use that to manage some of the magic numberiness going on.

ughitsaaron commented 8 years ago

fixed in https://github.com/alexbhill/project-pip/commit/ef3b488e7845b9bb775d98861c031052ba4719aa