Closed patcon closed 8 years ago
this is a nice idea. related to #38
Haven't tested this yet, but this was the gist
Confirmed that this works during regular running of instance, but loaddata needs fixing
kk - lemme know when you've got loaddata working, & I'll review
Ok, this should be good for review, currently using it for tor-councilmatic :)
@cathydeng Def lemme know if anything needs fix-ups to make things pythonic!
Oh hey, this is your call, but should I use CITY_COUNCIL_NAME
instead of a new OCD_CITY_COUNCIL_NAME
? The former was for copy and kinda cosmetic, and the latter is new and must match the name in the OCD API. I used OCD_CITY_COUNCIL_NAME
as it's consistent and clear that it relates to OCD_CITY_COUNCIL_ID
when xomeone comes across it.
Fwiw, whenever the OCD_CITY_COUNCIL_ID
is present, it takes precedent over OCD_CITY_COUNCIL_NAME
.
Any thoughts on those choices?
I like having a clear separation between display settings & data loading settings, so let's keep OCD_CITY_COUNCIL_NAME
looks good! this is great, thank you 👍
In the Canadian scrapers in scrapers-ca repo (hosted at http://scrapers.herokuapp.com/), we've made the choice to blow away the db regularly, and so OCD ids change. This is arguably something that we should eventually rethink, but for now, it's not an issue. Except in one place :)
https://github.com/datamade/django-councilmatic/blob/6d81da28435a31eff1e7f35662515a20aa935417/councilmatic_core/models.py#L67
https://github.com/datamade/chi-councilmatic/blob/master/councilmatic/settings_jurisdiction.py#L7
Would it be possible to instead use
_organization__name
instead oforganization__ocd_id
as the filter, as this is consistent and won't lead to odd behaviour whenever we re-run loaddata.cc: @jpmckinney