This week, most of my work concerned design logic.
Since ads may need to be re-used or shown in multiple communities, I explored ways to make ads community-agnostic. I experimented with a couple of DB schemas and settled on one I thought was most efficient.
Things I considered included:
- avoiding blockchain bloat (for example, using just one ad post to submit the same ad to multiple communities)
- avoiding unnecessary DB growth (not recording every ad action an account takes, but just effecting its changes to state)
- future flexibility
By separating ad posts from communities, and linking the two through ad submission ops, we can build a table that shows the state of a particular "ad post" in relation to the communities it was submitted to. The other ad ops will serve to manipulate this state.
From this, the hive_ads_state table was born.
post_id integer NOT NULL REFERENCES hive_ads (post_id),
community_id integer NOT NULL REFERENCES hive_communities (id),
time_units integer NOT NULL,
bid_amount numeric(10,3) NOT NULL,
bid_token varchar(5) NOT NULL,
start_time timestamp,
status smallint NOT NULL DEFAULT 0,
mod_notes varchar(500) DEFAULT '',
UNIQUE (post_id, community_id)
All logic for storing state-related info like bid_amount, bid_token or time_units has been moved to this new table.
The following commit sums up the preparatory work done to support community agnostic ads:
community agnostic ads preparation
That's all for this update!
This coming week, I will be working on implementing community ad settings and the actual ad operations that will be used to manipulate ad state.
See my current branches on GitHub: