don't enum motion_classification, as it makes votes useless for non-Sunlight projects #149
Conversation
| @@ -7,7 +7,7 @@ | |||
| "properties": { | |||
| 'identifier': {"type": "string", "blank": True,}, | |||
| 'motion_text': {"type": "string" }, | |||
| 'motion_classification': {"items": {"type": "string", "enum": common.VOTE_CLASSIFICATIONS}, | |||
| 'motion_classification': {"items": {"type": "string"}, | |||
There was a problem hiding this comment.
Hurm, I'm not super sure if we want to entirely get rid of all checking here, but I see what you're saying.
Hurmm.
There was a problem hiding this comment.
If Sunlight needs to ensure motion_classification sticks to a few values for its purposes, then it can patch the schemas in its scrapers like I do in ours: https://github.com/opencivicdata/scrapers-ca/blob/master/patch.py
It makes no sense for a generic library to limit motion classification to such a restricted set.
For our Toronto vote scraper, we just store the raw classification - we don't care about normalizing it because we don't need to.
There was a problem hiding this comment.
Well, I assumed we'd just add to that set as time goes on, let me think it over.
There was a problem hiding this comment.
(I'd hate to see everyone spell stuff differently for kicks, but I guess it's hard to nail down all the terms)
There was a problem hiding this comment.
The thing is, I'm not normalizing motion classification, and I shouldn't have to. If I just add the raw Toronto values to python-opencivicdata-django, it's going to be a messy list.
There was a problem hiding this comment.
What if these are settings and if it is blank then no validation is
performed (by dynamically checking for that in the schema nad not adding
the enum key if so)
On Tue, Feb 24, 2015 at 2:50 PM, James McKinney notifications@github.com
wrote:
In pupa/scrape/schemas/vote.py
#149 (comment):@@ -7,7 +7,7 @@
"properties": {
'identifier': {"type": "string", "blank": True,},
'motion_text': {"type": "string" },
'motion_classification': {"items": {"type": "string", "enum": common.VOTE_CLASSIFICATIONS},'motion_classification': {"items": {"type": "string"},The think is, I'm not normalizing motion classification, and I shouldn't
have to. If I just add the raw Toronto values to
python-opencivicdata-django, it's going to be a messy list.—
Reply to this email directly or view it on GitHub
https://github.com/opencivicdata/pupa/pull/149/files#r25285718.
James Turk
Labs Director | Sunlight Foundation http://www.sunlightfoundation.com/
202-558-8723 | @jamesturk https://twitter.com/jamesturk
[image: Sunlight Foundation] http://sunlightfoundation.com/
There was a problem hiding this comment.
Euch, I just saw your comment after I merged, sorry @jamesturk
(but I think we agree, and I filed a bug #153 )
There was a problem hiding this comment.
That would work for me. If the solution can be applied for all enums, that'd be even better!
No description provided.