#463, Add API to query for open orders of one account in one market #849

cryptocifer · 2018-04-15T07:18:40Z

Local tests ok:

call this api through websocket
call this api through cli_wallet

But I'm not very sure if this pr meets the requests of #463, pls help pointing out if not.

Update:

may fix #811 btw

abitmore

Please submit fix for how to use database API in cli_wallet for example get_full_accounts method? #811 as a new PR.
Pagination is needed for Update / Add API to query for open orders with pagination #463. I was thinking about limit_order only, since you've coded call_order and settle_order, I think we can add 3 APIs in total.

abitmore · 2018-04-16T00:07:59Z

Wanted parameters: account, market (base and quote) and fields for pagination.

cryptocifer · 2018-04-16T04:57:19Z

the get_account_orders() api I added mostly copied from get_full_account(), the first parameter is a array of accounts.

Per the requests and for simplicity, I think new api's first parameter can just be one account name (or id), is there any case that will request multiple accounts' orders at one time?

abitmore · 2018-04-17T10:03:35Z

@cifer-lee IMHO the new APIs should only use single account, but not an array. Thanks.

abitmore

I didn't see why querying by expiration makes sense. Please explain?
Need a way to query for the second page and more. Usually we use two parameters: a start and a limit.
I think it's best to sort orders by price, and the best field for pagination is order's ID (as start of each page). Please think a bit more.

Thank you.

abitmore · 2018-04-18T19:39:21Z

libraries/app/database_api.cpp

+   auto quote_id = assets[1]->id;
+
+   // Add the account's orders
+   auto order_range = _db.get_index_type<limit_order_index>().indices().get<by_account>().equal_range(account->id);


Perhaps best to add an index for this API? Iterating with continue below is inefficient.

abitmore · 2018-04-18T19:42:12Z

libraries/app/database_api.cpp

+}
+
+vector<limit_order_object> database_api_impl::get_account_limit_orders( const string& name_or_id, const string& base, const string& quote, fc::time_point_sec expire, uint32_t limit)
+{


Please check if limit is too big. Since limit_order is relatively small, I think we can return a bit more per page.

cryptocifer · 2018-04-19T03:51:25Z

@abitmore Thanks for your comments, I had think before made these changes.

IMHO by expiration maybe simple to use, since client would not know order id? But client could easily fetch account's orders by specifying an timestamp and a limit.

Shortcomings are that expiration is not ordered in limit_order_index, and many orders not specifying expiration may default to year 2038. Actually, I wish limit order could have a create time, so we can querying account's orders this way: query 100 of Sam's limit orders before 2018-04-18, time descending.

abitmore · 2018-04-19T07:56:23Z

Clients software do know order id, although perhaps aren't showing it on UI.

My thoughts about pagination:

with a given id, get price of the order;
* query with by_price index, with lower bound from tuple (price,id) as lower bound, then iterate forward.
query with an appropriate index, with lower bound from tuple (price,id) as lower bound, then iterate forward.

// Update:
For this approach, we need a (price,account,id) or (account,price,id) index. Since by_price is related to consensus about order matching, we'll avoiding changing that. But I guess it's fine to change by_account index to (account,price,id), since it's only used by API. Please correct me if I'm wrong.

cryptocifer · 2018-04-19T08:12:48Z

query with by_price index, with lower bound from tuple (price,id) as lower bound, then iterate forward.

But this means filter the target account iteratively, not this back to the inefficiency issue you pointed above?

abitmore · 2018-04-19T09:57:46Z

@cifer-lee sorry, I've noticed the issue then updated the comment later. Please check again.

cryptocifer · 2018-04-19T16:23:26Z

@abitmore yeah I noticed your updates but no time to fix daytime, now I am working on it.

update:

Sorry i think there still exists a trouble, when we get an index (account, price, id), we can't do pagination by id, since orders will first sorting by account and price, they will mostly not in order by id, thus pagination by id won't work too.

So it seems if we want pagination by id, we shouldn't sort by price, but it also depend on sorting by price to select out target market. And I found no method of just getting orders by market without sorting.

In my opinion, we may need to query orders by (account, id) index, and filter out the target market in iterative way, which means orders not sorted by price. If must, we can sort it by price manually before response to client, while client may need to traverse the received orders to find out the max order id - using it to request the next page

abitmore · 2018-04-25T21:55:37Z

@cifer-lee my thoughts about pagination (two steps for one API query):

with a given id, get price of the order;
query with an appropriate index, with lower bound from tuple (account,price,id) as lower bound, then iterate forward.

abitmore · 2018-04-30T12:05:47Z

@cifer-lee some changes in the last commit are not ideal:

we need "base" and "quote" in parameter list, otherwise there is no good way to query for the first page;
we need (account,price,id) index to query for the 2nd page, but not (account,id,price).

cryptocifer · 2018-05-01T08:44:55Z

@abitmore Have fixed per to discussion on telegram, please check~

abitmore

Please wrap long lines which are more than 120 characters.

abitmore · 2018-05-01T12:43:29Z

libraries/app/database_api.cpp

+   for ( ; lower_itr != upper_itr ; ++lower_itr) {
+      const limit_order_object &order = *lower_itr;
+
+      if (count++ >= limit)


Why not move this into for?

abitmore · 2018-05-01T12:44:50Z

libraries/app/database_api.cpp

+
+vector<limit_order_object> database_api_impl::get_account_limit_orders( const string& name_or_id, const string &base, const string &quote, uint32_t limit, optional<limit_order_id_type> ostart_id, optional<price> ostart_price)
+{
+   FC_ASSERT( limit <= 100 );


Change to 101 for easier pagination.

ok, but why 101 easier for pagination?

Usually we use 100, 50 or etc as page size. Since we use lower_bound here, if pass in the last item of last page, with 100 as limit we can get only 99 new items (although it's possible to get around it e.g. pass in last_id+1 but it's not convenient).

abitmore · 2018-05-01T12:50:13Z

libraries/app/database_api.cpp

+   if (!ostart_id && !ostart_price) {
+       lower_itr = index_by_account.lower_bound(std::make_tuple(account->id, price::max(base_id, quote_id)));
+       upper_itr = index_by_account.upper_bound(std::make_tuple(account->id, price::min(base_id, quote_id)));
+   } else if (ostart_id) {


Please avoid using optional::bool(). Use ostart_id.is_valid() instead. BTW using operator!() is fine.

got it, but why avoid using optional::bool()?

for consistent, I will change both these two lines to use ostart_id.valide()

https://github.com/bitshares/bitshares-fc/blob/master/include/fc/optional.hpp#L190-L192

// this operation is not safe and can result in unintential // casts and comparisons, use valid() or !! explicit operator bool()const { return _valid; }

I can be wrong though. Since operator bool() is explicit, I didn't get what conversion will be done when calling if(ostart_id).

abitmore · 2018-05-01T12:54:35Z

libraries/app/database_api.cpp

+       // in case of the order been deleted during page querying
+       if (!_db.find_object(*ostart_id)) {
+           if (ostart_price) {
+               lower_itr = index_by_account.lower_bound(std::make_tuple(account->id, (*ostart_price).max(), *ostart_id));


I think we need to use ostart_price here but not max().

abitmore · 2018-05-01T12:57:42Z

libraries/app/database_api.cpp

+               return results;
+           }
+       } else {
+           const limit_order_object &loo = _db.get(*ostart_id);


With this we searched same object twice, which is unnecessary.

By the way, we need to check if the order is in base:quote and is owned by that account. If not, IMHO best to throw out an exception.

abitmore · 2018-05-01T13:14:48Z

libraries/app/include/graphene/app/database_api.hpp

+       * @param quote  Quote asset
+       * @param limit  Max items to fetch
+       * @param start_id  Start order id, fetch orders which price lower than this order
+       * @param start_price  Fetch orders with price lower than this price


lower is not accurate.

abitmore · 2018-05-01T13:15:31Z

libraries/app/include/graphene/app/database_api.hpp

+       * @param base  Base asset
+       * @param quote  Quote asset
+       * @param limit  Max items to fetch
+       * @param start_id  Start order id, fetch orders which price lower than this order


lower is not accurate. BTW if the price is the same, order id should be equal or higher?

abitmore · 2018-05-01T13:17:39Z

libraries/app/include/graphene/app/database_api.hpp

+       * @return List of orders from @ref name_or_id to the corresponding account
+       *
+       * @note
+       * 1. if @ref name_or_id cannot be tied to an account, empty results will be returned


Change results to result.

abitmore · 2018-05-01T13:18:41Z

libraries/app/include/graphene/app/database_api.hpp

+       * @param name_or_id  Each item must be the name or ID of an account to retrieve
+       * @param base  Base asset
+       * @param quote  Quote asset
+       * @param limit  Max items to fetch


Please mention the limitation of this parameter.

abitmore · 2018-05-01T13:19:59Z

libraries/wallet/include/graphene/wallet/wallet.hpp

@@ -378,6 +378,7 @@ class wallet_api
     vector<operation_detail>  get_relative_account_history(string name, uint32_t stop, int limit, uint32_t start)const;

      vector<bucket_object>             get_market_history(string symbol, string symbol2, uint32_t bucket, fc::time_point_sec start, fc::time_point_sec end)const;
+      vector<limit_order_object>        get_account_limit_orders( const string& name_or_id, const string &base, const string &quote, uint32_t limit = 100, optional<limit_order_id_type> ostart_id = optional<limit_order_id_type>(), optional<price> ostart_price = optional<price>());


Please add docs.

abitmore

Good job so far.

Please wrap long lines to fit this page in screen: https://github.com/bitshares/bitshares-core/pull/849/files;
best if test cases are added.

abitmore · 2018-05-01T18:41:01Z

libraries/wallet/include/graphene/wallet/wallet.hpp

+      vector<limit_order_object>        get_account_limit_orders( const string& name_or_id,
+                                            const string &base,
+                                            const string &quote,
+                                            uint32_t limit = 100,


abitmore · 2018-05-01T18:44:25Z

libraries/app/database_api.cpp

+       // in case of the order been deleted during page querying
+       const limit_order_object *p_loo = nullptr;
+
+       if (!(p_loo = static_cast<const limit_order_object *>(_db.find_object(*ostart_id)))) {


Move the assignment to the line above?

By the way, no need to convert with static_cast if use _db.find().

_db.find() will throw exception on fail, give me no change to use ostart_price getting lower bound

I think find() won't throw exception, but get() will.

maybe I'm wrong? I found _db.find() has roughly the same logic with _db.get(), especially both of them have an assert clause, maybe not throw exception like FC_ASSERT, but also abort the program.

https://github.com/bitshares/bitshares-core/blob/master/libraries/db/include/graphene/db/object_database.hpp#L109-L122

find() can return nullptr, so should be fine.

In regards to the use of assert(), actually I'm not sure if it's better to change them to FC_ASSERT. Main reason is assert() will be skipped when building in Release mode for better performance, but by doing so we may have skipped some important checking; another reason is the abortion behavior you've noticed. More info in #511.

abitmore · 2018-05-01T18:45:23Z

libraries/app/database_api.cpp

+   const account_object*        account = nullptr;
+   uint32_t                     count = 0;
+   limit_order_id_type          start_id;
+   price                        start_price;


Unused variables?

abitmore · 2018-05-01T18:47:57Z

libraries/app/database_api.cpp

+       if (!(p_loo = static_cast<const limit_order_object *>(_db.find_object(*ostart_id)))) {
+           if (ostart_price.valid()) {
+               lower_itr = index_by_account.lower_bound(std::make_tuple(account->id, *ostart_price, *ostart_id));
+               upper_itr = index_by_account.upper_bound(std::make_tuple(account->id, (*ostart_price).min()));


(*x). can be replaced with x->.

abitmore · 2018-05-01T18:50:51Z

libraries/app/include/graphene/app/database_api.hpp

+       * @param name_or_id  The name or ID of an account to retrieve
+       * @param base  Base asset
+       * @param quote  Quote asset
+       * @param limit  The limitation of items each query can fetch, currently 101


limit can be 101 or smaller.

abitmore · 2018-05-01T18:56:14Z

libraries/app/include/graphene/app/database_api.hpp

+       * @param base  Base asset
+       * @param quote  Quote asset
+       * @param limit  The limitation of items each query can fetch, currently 101
+       * @param start_id  Start order id, fetch orders which price are lower than or equal to this order


Need a clearer description here. Perhaps something like "price lower than this order, or price equal to this order but order ID greater than this order".

abitmore · 2018-05-01T18:59:24Z

libraries/app/include/graphene/app/database_api.hpp

+       * @note
+       * 1. if @ref name_or_id cannot be tied to an account, empty result will be returned
+       * 2. @ref start_id and @ref start_price can be empty, if so the api will return the "first page" of orders;
+       *    if start_id is specified and valid, its price will be used to do page query preferentially, otherwise the start_price will be used 


Need description about the scenario when both start_id and start_price will be used.

abitmore · 2018-05-01T19:01:31Z

libraries/app/include/graphene/app/database_api.hpp

@@ -268,6 +268,25 @@ class database_api
       */
      vector<optional<account_object>> get_accounts(const vector<account_id_type>& account_ids)const;

+      /**
+       * @brief Fetch all orders relevant to the specified account sorted descendingly by price


Need to describe somewhere that this API is to query for orders of one specified market but not all markets.

By the way, do we need an API to query for orders of all markets?

depend on wether ui need it?
if needed I can add this api

There are use cases, but not popular: "I have many open orders, I don't remember what markets are they in, just want to get them all". I think it's low priority.

abitmore

Good job.

BTW best if coding style can be same to most of existing code:

{ in new line
3 white spaces as indentation
white spaces e.g. if( condition ) and call_function( a, b );
wrap long lines

abitmore · 2018-05-15T08:42:34Z

libraries/app/database_api.cpp

+
+   const auto& index_by_account = _db.get_index_type<limit_order_index>().indices().get<by_account>();
+   limit_order_multi_index_type::index<by_account>::type::const_iterator lower_itr;
+   limit_order_multi_index_type::index<by_account>::type::const_iterator upper_itr;


Actually upper_itr can be initialized here, no need to be initialized in if/else block below, since the results will be the same.

Update: actually it's better to initialize it after the if/else block (than before the block).

has initialize upper_itr in each of if/else if/else branch, is it ok?

abitmore · 2018-05-15T08:45:43Z

tests/tests/database_api_tests.cpp

+   // query with no constraint, expected:
+   // 1. up to 101 orders returned
+   // 2. orders were sorted by price desendingly
+   results = db_api.get_account_limit_orders(seller.name, "BTS", "CNY");


Change "BTS" to the corresponding macro or use a local variable, otherwise this test case will fail in testnet branch.

abitmore · 2018-05-15T08:47:40Z

tests/tests/database_api_tests.cpp

+   BOOST_CHECK(results.size() == 101);
+   for (int i = 0 ; i < results.size() - 1 ; ++i) {
+     BOOST_CHECK(results[i].sell_price >= results[i+1].sell_price);
+   }


Check if the first item and the last item are correct (also best to add this check to test cases below).

abitmore · 2018-05-15T08:48:07Z

tests/tests/database_api_tests.cpp

+   // 1. up to specified amount of orders returned
+   // 2. orders were sorted by price desendingly
+   results = db_api.get_account_limit_orders(seller.name, "BTS", "CNY", 50);
+   results = db_api.get_account_limit_orders(seller.name, "BTS", "CNY", 50);


Redundant code?

abitmore · 2018-05-15T08:53:11Z

tests/tests/database_api_tests.cpp

+                          // of the lowest price 150 orders
+   results = db_api.get_account_limit_orders(seller.name, "BTS", "CNY", 101,
+       limit_order_id_type(o.id), o.sell_price);
+   BOOST_CHECK(results.size() <= 101);


We know how many records should be returned, so not good to use <=.

abitmore · 2018-05-15T08:55:26Z

tests/tests/database_api_tests.cpp

+   for (int i = 0 ; i < results.size() - 1 ; ++i) {
+     BOOST_CHECK(results[i].sell_price >= results[i+1].sell_price);
+   }
+


Test the scenarios that will return an empty vector or throw an exception?

cryptocifer · 2018-05-19T06:43:41Z

@abitmore have fixed reviews so far except the initialization of upper_itr, hard to initialize it at defining point because it depend on wether ostart_price is valid. And IMO it's ok to assign upper_itr in each if/else branch since more clearly to read.

btw, about code formatting, maybe we can uniform code style using an auto-formatting tool?

abitmore · 2018-05-20T12:55:22Z

@abitmore have fixed reviews so far except the initialization of upper_itr, hard to initialize it at defining point because it depend on wether ostart_price is valid. And IMO it's ok to assign upper_itr in each if/else branch since more clearly to read.

upper_itr is only related to base and quote.

Update: actually it's better to initialize it after the if/else block (than before the block).

btw, about code formatting, maybe we can uniform code style using an auto-formatting tool?

Of course you can use a tool. However, usually we only format new code and sometimes related old code for easier review (via diffing tool).

abitmore · 2018-05-20T12:57:23Z

@cifer-lee your commit history is not clear (duplicated commits and unrelated commits), please rebase.

abitmore · 2018-05-21T14:17:07Z

libraries/app/database_api.cpp

@@ -680,12 +680,13 @@ vector<limit_order_object> database_api_impl::get_account_limit_orders( const st
   {
      // in case of the order been deleted during page querying
      const limit_order_object *p_loo = _db.find(*ostart_id);
+      upper_itr = index_by_account.upper_bound(std::make_tuple(account->id, price::min(base_id, quote_id)));


This change slightly reduced performance under certain circumstances :)

Before this change, if an exception is thrown due to FC_ASSERT below, this database query won't be executed.

performance reduction means if run into FC_ASSERT, upper_itr initialization is vain here?

litepresence · 2018-05-24T23:09:25Z

not sure if this helps, but this is how I sort my limit orders in one market / one account; sorted by orderNumber... on client side using websocket-client w/ call get_full_accounts, in python, without pybitshares

https://pastebin.com/Bg2L78qB

returns of list of dicts with keys:
price, amount, market, orderNumber, orderType

cryptocifer · 2018-05-25T03:14:19Z

@litepresence Thanks~ but as have talked above, better to sorted first by price, then by order id

abitmore

Code looks fine.
Test cases didn't cover all FC_ASSERTs in the code.
(In my own opinion) name of the API is debatable.

@ryanRfox and other core devs please take a look.

jmjatlanta

I agree with abit. The code looks good, and compiling/testing works.

As for the naming, I'm assuming "limit" is talking about "limit orders" and not the size of the returned vector. As to how the name fits with the rest of the API, I'll defer to those with more maturity in the project.

soapbox:
I believe that we have to be reasonable and not overly pedantic about testing / code coverage. But the more we cover in our tests the better. A bug caught in a test is much cheaper than a bug caught by the user. (even more-so in the blockchain world). But the corollary is also true: if you try to make it idiot proof, someone will build a better idiot.
/soapbox

cryptocifer · 2018-05-30T18:31:23Z

@abitmore @jmjatlanta Thanks for your comments, I feel sorry for the partially covered test cases and the ambiguous api name. I have never written test cases before, so have no conscious about coverage, I will supplement the missing cases sooner.

The api name is derived from get_limit_orders api, I have no good idea how to make it clearer, maybe get_limit_orders_by_account looks clearer but the parameters indicates it was obviously not just "by account". Hearing from maturity too..

abitmore self-requested a review April 15, 2018 23:58

abitmore requested changes Apr 16, 2018

View reviewed changes

abitmore reviewed Apr 18, 2018

View reviewed changes

abitmore requested changes May 1, 2018

View reviewed changes

abitmore reviewed May 1, 2018

View reviewed changes

abitmore added this to the 201805 - Non-Consensus-Changing Release milestone May 2, 2018

abitmore requested changes May 15, 2018

View reviewed changes

cryptocifer added 9 commits May 21, 2018 13:55

Add get_account_orders api

0d1d389

filter by market and support pagination

205d389

check limit

466e150

modify by_account index

fca8cbf

Adjusted implementation after talk with abit

352817f

make this api more commonly by supporting query by price and order_id

a102db8

use optional template to represent optional parameters

8f41ab0

fixed some bugs pointed by abit

4c1fd77

fix defects

59b5b1b

cryptocifer added 7 commits May 21, 2018 16:19

avoid static_cast

ec7ef61

update

1e0c369

update test cases

50b6d62

fixed some checks and wrap long lines

7e67682

fix code style

a5077e8

fix indent

fc0fc1d

initialize upper_itr in common place

cbc4d05

abitmore reviewed May 21, 2018

View reviewed changes

abitmore modified the milestones: 201806 - Non-Consensus-Changing Release, 201807 - Next Non-Consensus-Changing Release May 21, 2018

elimanating pontential perfromance reduction

7f18c59

abitmore approved these changes May 29, 2018

View reviewed changes

jmjatlanta approved these changes May 30, 2018

View reviewed changes

cryptocifer mentioned this pull request Jun 14, 2018

Update / Add API to query for open orders with pagination #463

Open

8 tasks

abitmore requested a review from ryanRfox July 21, 2018 19:25

Merge branch 'develop' into issue463

5ff8fea

abitmore removed the request for review from ryanRfox July 21, 2018 19:31

abitmore merged commit 523ccd8 into bitshares:develop Jul 21, 2018

abitmore mentioned this pull request Jul 21, 2018

Refactor get_account_limit_orders API account name support #1164

Closed

abitmore mentioned this pull request Aug 4, 2018

Dummy issue for release note for (test-)2.0.1808xx #1234

Closed

roma219 mentioned this pull request Nov 21, 2018

Active Orders: getting open orders bitshares/vuex-bitshares#36

Closed

#463, Add API to query for open orders of one account in one market #849

#463, Add API to query for open orders of one account in one market #849

Conversation

cryptocifer commented Apr 15, 2018 • edited Loading

abitmore left a comment

Choose a reason for hiding this comment

abitmore commented Apr 16, 2018

cryptocifer commented Apr 16, 2018

abitmore commented Apr 17, 2018

abitmore left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cryptocifer commented Apr 19, 2018

abitmore commented Apr 19, 2018 • edited Loading

cryptocifer commented Apr 19, 2018

abitmore commented Apr 19, 2018

cryptocifer commented Apr 19, 2018 • edited Loading

abitmore commented Apr 25, 2018

abitmore commented Apr 30, 2018

cryptocifer commented May 1, 2018

abitmore left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abitmore left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cryptocifer May 3, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cryptocifer May 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abitmore left a comment • edited Loading

Choose a reason for hiding this comment

abitmore May 15, 2018 • edited Loading

Choose a reason for hiding this comment

cryptocifer May 21, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cryptocifer commented May 19, 2018

abitmore commented May 20, 2018 • edited Loading

abitmore commented May 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

litepresence commented May 24, 2018 • edited Loading

cryptocifer commented May 25, 2018

abitmore left a comment

Choose a reason for hiding this comment

jmjatlanta left a comment • edited Loading

Choose a reason for hiding this comment

cryptocifer commented May 30, 2018

cryptocifer commented Apr 15, 2018 •

edited

Loading

abitmore commented Apr 19, 2018 •

edited

Loading

cryptocifer commented Apr 19, 2018 •

edited

Loading

cryptocifer May 3, 2018 •

edited

Loading

cryptocifer May 2, 2018 •

edited

Loading

abitmore left a comment •

edited

Loading

abitmore May 15, 2018 •

edited

Loading

cryptocifer May 21, 2018 •

edited

Loading

abitmore commented May 20, 2018 •

edited

Loading

litepresence commented May 24, 2018 •

edited

Loading

jmjatlanta left a comment •

edited

Loading