PostGres store backend

[bstrie]

Breaking down this task into more manageable goals:

• [x] configuration option for selecting redis or sqlite (possibly via parsing the scheme of the given store URL?)
• [x] crate features for enabling/disabling redis and sqlite backends (both enabled by default?)
• [x] logic in ilp-node to select appropriate backend crate
• [ ] dynamically determine whether to instantiate a prior existing node or a new node based on whether the sqlite file already exists (or configuration parameter, for use with redis as well?)
• [x] "hello world" demo for a node that answers the / (status) endpoint without having the redis crate enabled at all
• [ ] one-by-one implement the store traits for SQLite (TODO: prioritize)
  • [ ] api::NodeStore
  • [ ] btp::BtpStore
  • [ ] ccp::RouteManagerStore
  • [ ] http::IdempotentStore
  • [ ] http::HttpStore
  • [ ] router::RouterStore
  • [ ] service::AccountStore
  • [ ] service::AddressStore
  • [ ] service_util::BalanceStore
  • [ ] service_util::ExchangeRateStore
  • [ ] service_util::RateLimitStore
  • [ ] settlement::LeftoversStore
  • [ ] settlement::SettlementStore
  • [ ] stream::StreamNotificationsStore

[emschwartz]

abstract redis-specific logic out of ilp-node

I wouldn't work on much abstraction here. Instead, I would replace these lines with a method on the node called connect_to_store or something like that. That method would parse the database_url parameter to see whether it's a redis, redis+unix, or sqlite URL and use the appropriate builder to create and connect to the store. That method would return an impl Future<Item = ..., Error = ()> where ... is a thing that implements all the store traits.

dynamically determine whether to instantiate a prior existing node or a new node based on whether the sqlite file already exists (or configuration parameter, for use with redis as well?)

This should only be necessary if the SQLite store does anything to create the tables on startup. If the tables are created dynamically when they're used, its behavior would be the same whether you gave it a path to a file that didn't yet exist or one a path to a previously used database.

[KevinWMatthews]

Is this happening on a branch somewhere? I'm curious to watch these changes take shape.

[bstrie]

@KevinWMatthews I haven't pushed any of my WIP commits yet, but I'll try to get something up today that people can look at.

[bstrie]

@KevinWMatthews I've got the initial groundwork laid in https://github.com/interledger-rs/interledger-rs/issues/474.

[sappenin]

@bstrie Any updates here?

[gakonst]

Given that we haven't had any progress on this, we decided with @sappenin to move forward with PostGRes and tokio-postgres for this task

[sappenin]

In Java we have all account-related data stored in Postgres (only balance tracking is still persisted in Redis). I suggest we replicate the DDL that we have in the Java project here. See here for the table structure used by the Java Connector.