Closed imalsogreg closed 6 years ago
@imalsogreg: You'll want to check out https://github.com/propublica/fbpac-api -- that's where these migrations live. (That repo contains a Rails API that runs the "admin" portion of the dashboard as well as, soon, the English language homepage.)
@jeremybmerrill Thank you for the info. That appears to be a private repo (I get a 404). Are the migrations there intended to be needed to run facebook-political-ads
locally?
My bad: https://github.com/propublica/fbpac-api-public
Yes, they are intended to be needed to run it locally.
Hm, after getting familiar with fbpac-api-public
and running a rake db:migrate
from there without error, the facebook-political-ads
server responds to /facebook_ads/ads
request (triggered by a "Policital Ad" button click in the extension) with a 400, while the server logs something sounding 500y to stderr:
2018-07-03T17:43:02.881525071-04:00 WARN server::server - Error(DataBase(DatabaseError(__Unknown, "column \"targetings\" of relation \"ads\" does not exist")), State { next_error: None, backtrace: None })
Mentioning here on the PR (rather than in an issue) because it sounds related to this PR - like a missing migration for targetings
column in ads
table. In fbpac-api-public
I see a mention of "targeting" in db/schema.rb
. And facebook-political-ads
has "targeting" in backend/server/migrations
, but no "targetings" there. "targetings" appears in the rust server's ORM code.
Have run the migrations incorrectly, or should I make a PR against fbpac-api-public
for adding the targetings
column?
My database (called fbpac
):
fbpac=> \d
List of relations
Schema | Name | Type | Owner
--------+----------------------------+----------+-------
public | __diesel_schema_migrations | table | fbpac
public | ads | table | fbpac
public | candidates | table | fbpac
public | candidates_id_seq | sequence | fbpac
public | close_races | table | fbpac
public | close_races_id_seq | sequence | fbpac
public | electoral_districts | table | fbpac
public | electoral_districts_id_seq | sequence | fbpac
public | parties | table | fbpac
public | parties_id_seq | sequence | fbpac
public | partners | table | fbpac
public | partners_id_seq | sequence | fbpac
public | schema_migrations | table | fbpac
public | states | table | fbpac
public | states_id_seq | sequence | fbpac
(15 rows)
fbpac=> \d ads
Table "public.ads"
Column | Type | Modifiers
-----------------------+--------------------------+------------------------
id | text | not null
html | text | not null
political | integer | not null
not_political | integer | not null
title | text | not null
message | text | not null
thumbnail | text | not null
created_at | timestamp with time zone | not null default now()
updated_at | timestamp with time zone | not null default now()
lang | text | not null
images | text[] | not null
impressions | integer | not null default 1
political_probability | double precision | not null default 0
targeting | text |
suppressed | boolean | not null default false
targets | jsonb | default '[]'::jsonb
advertiser | text |
entities | jsonb | default '[]'::jsonb
page | text |
lower_page | character varying |
Indexes:
"ads_pkey" PRIMARY KEY, btree (id)
"ads_lower_page_idx" btree (lower_page)
"index_ads_on_advertiser" btree (advertiser)
"index_ads_on_browser_lang" btree (lang)
"index_ads_on_english_html" gin (to_englishtsvector(html))
"index_ads_on_entities" gin (entities)
"index_ads_on_german_html" gin (to_germantsvector(html))
"index_ads_on_lang" btree (lang)
"index_ads_on_page" btree (page)
"index_ads_on_political_probability" btree (political_probability)
"index_ads_on_political_probability_lang_and_suppressed" btree (political_probability, lang, suppressed)
"index_ads_on_suppressed" btree (suppressed)
"index_ads_on_targets" gin (targets)
Triggers:
notify_on_update AFTER UPDATE ON ads FOR EACH ROW WHEN (old.* IS DISTINCT FROM new.*) EXECUTE PROCEDURE notify_update()
thx!
hey @imalsogreg sorry about that, our internal version got out of sync with the public one. I just added that migration.
These two columns are referenced in
backend/server/model.rs
Without the migrations, the server was throwing an error about these missing columns.