Native Ads Weekly Dev Update #2

in #hivemindlast year (edited)

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:

https://github.com/imwatsi/hivemind/branches