set up database

[morkeltry]

and distribute secrets on gitter

We will discuss this, but at first guess:

• BORROWERS: {ethAddr; phoneNo}
• LENDERS: {id; name; capitalAvailable; minAmount; maxAmount; minduration; maxDuration; preferredAmount; preferredDuration}
• OFFERED: { id; startDate; endDate; amount; repaymentSchedule; lenderName; lenderEthAddr; BorrowerEthAddr}
• ACCEPTED: {id; fullyPaid; startDate; endDate; amount; repaymentSchedule; lenderName; lenderEthAddr; BorrowerEthAddr}
• HISTORIES: (copy of blockchain data) {BorrowerEthAddr; lenderEthAddr; startDate; endDate; earlyRepaymentDays; lastSyncAddress}

repaymentSchedule should be an stringified object with numbered keys (cumulativeDays) having properties cumulativeAmount. So a loan of QI100 issued on the 4th with repayments due of QI25 on the 9th, 14th, 19th and 24th of the month would have

repaymentSchedule = {
  '5': 25, 
  '10': 25, 
  '15': 25, 
  '20': 25 
}

to reduce on-chain processing.

[Parissai]

[Parissai]

Please check out the schema here and comment if changes are needed. @morkeltry

[morkeltry]

Pretty tired when I made this. lastSyncAddress should be lastSyncTime. I'll change it in the branch. It's intended for the backend to check if it is up to date, to save consulting the blockchain.

early_repayment_days was intended to be a smallint, representing only how many days early the loan was finally repaid (which could be negative if overdue). In the smart contract, however, histories have an actualRepayments object which stores a mapping (consider it an array) containing each repayment, not just the final state. It could be useful to correlate this to a stringifed array early_repayment_days in the DB. I don't know if this was your plan (assuming you will be taking on #5), so I've left it as varchar.