Add endpoints in view instead of model about webvoteview HOT 5 CLOSED

I agree 100% with the concept and it looks like the code is right! 👍

Three questions:

1. Would we prefer to keep slope/intercept and calculate mid/spread, or the reverse?

2. I think the title might be slightly mis-named. we're not talking about moving the code from model to view; we're talking about moving the code from static precalculation in the db into the model. Typically the view should not do anything in MVC or similar architectures. We're pretty fast and loose about how we implement MVC but still.

I would imagine that this would be added into the searchVotes/downloadVotes API as something that's done while assembling votes?

3. Are there any metadata, dump, or db scripts that depend on both sets of data being available? If so, we'll have to update those as well as the WebVoteView stuff.

from webvoteview.

1. Mid-spread are what come straight out of Keith's DW-NOMINATE and pynominate as they are currently written. Of course, rewriting pynominate is no problem, and having the slope and intercept being computed when the numbers are being ingested into the DB upon updates or conditional estimation is also no problem. However, you can generate the slope and the intercept from the midpoint and the spread them but the reverse is not true. The DB should probably have the mid/spread instead of slope/intercept.

2. One problem with adding it to downloadVotes is if we intend to pull straight from mongo... then we have the same problem where we duplicate this kind of code. I don't know the issues with storing more information in the DB but I think this should remain as a static precalculation in to the DB. The mid/spread will be updated every time we run nominate, so we might as well just reingest it along with the mid/spread. Then this code only lives in one place.

Again, I don't know about the costs to large dbs in mongo.

from webvoteview.

There shouldn't be much penalty besides if we are querying by these fields (we don't) or indexing them (we don't). The main issue raised would be Adam's suggestion that the mid/spread and slope/intercept might be desynced due to people failing to sync them.

from webvoteview.

Aaron - I agree about the terminology.

Having both in the db shouldn't be a problem in terms of performance. In
general, we want to avoid duplicating (1) code and (2) data. In the ideal,
whatever database schema we use should therefore avoid redundant data like
having only mid/spread, not also slope/intercept. Then to avoid duplicating
code, a function could be introduced into the api that generates the
slope/intercept as needed. Then any routine that wants slope/intercept
could go through that api procedure to get them.

On Thu, Sep 22, 2016 at 4:00 PM, Luke Sonnet [email protected]
wrote:

1. Mid-spread are what come straight out of Keith's DW-NOMINATE and
   pynominate as they are currently written. Of course, rewriting pynominate
   is no problem, and having the slope and intercept being computed when the
   numbers are being ingested into the DB upon updates or conditional
   estimation is also no problem. However, you can generate the slope and the
   intercept from the midpoint and the spread them but the reverse is not
   true. The DB should probably have the mid/spread instead of slope/intercept.

2. One problem with adding it to downloadVotes is if we intend to pull
   straight from mongo... then we have the same problem where we duplicate
   this kind of code. I don't know the issues with storing more information in
   the DB but I think this should remain as a static precalculation in to the
   DB. The mid/spread will be updated every time we run nominate, so we might
   as well just reingest it along with the mid/spread. Then this code only
   lives in one place.

Again, I don't know about the costs to large dbs in mongo.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#37 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AS6Qi1BRKQWImHv2wQMnF6qrhp5PhLdFks5qswiWgaJpZM4KEMna
.

from webvoteview.

This is done. The download votes API now deletes x, y, slope, and intercept from what it gets out of the database and then re-generates them using the above code (if spread/mid are present and valid). So everything on the dev server is using the above code, even on the old schema, and we'll be ready for the new schema.

from webvoteview.