Architectural from-to relation NoSql

Question

I'm struggling with this architectural problem on my Parse.com document. I have the following "schema", called Debit :

"createdAt": "2014-12-12T02:31:06.026Z",
"creator": {
    "__type": "Pointer",
    "className": "_User",
    "objectId": "objectId"
},
"date": {
    "__type": "Date",
    "iso": "2014-12-12T02:31:14.437Z"
},
"debitStatus": 0,
"description": "Gdfvgg",
"from": {
    "__type": "Pointer",
    "className": "_User",
    "objectId": "Sd9B1XyZVL"
},
"has_accepted": false,
"objectId": "objectId",
"to": {
    "__type": "Pointer",
    "className": "_User",
    "objectId": "objectId"
},
"updatedAt": "2014-12-12T06:00:46.528Z",
"value": "6.48"

The from and to "columns" are pointers to _User table. The problem is, in my Android app I'd like to display both from and to debits according to the Logged User, but on my adapter only show the "not logged user" user.

I tried doing an or query on Parse to get all the debits queries but I can't include the User pointer because on or queries Parse doesn't support.

Like this:

ParseQuery<ParseObject> query1 = new ParseQuery<ParseObject>("UserBalance");
query1.whereEqualTo("user_from", ParseUser.getCurrentUser());
ParseQuery<ParseObject> query2 = new ParseQuery<ParseObject>("UserBalance");
query2.whereEqualTo("user_to", ParseUser.getCurrentUser());

ParseQuery<ParseObject> query = ParseQuery.or(Arrays.asList(query1, query2));

But the problem is when showing the "not me" adapter:

Adapter:

 ParseUser user = null;
 ParseUser user1 = (ParseUser) object.get("user_to");
 if (user1 == ParseUser.getCurrentUser())
     user = (ParseUser) object.get("user_from");
 else
     user = user1;

Of course I need to fetch the user, which in the adapter is not a good idea. So, is there a better approach on the Database side to improve this ?

Thanks

Answer 1

Parse is a database and the API will send you the records as they are in the database. You could create a Parse.com cloud function if you want to compute the "other party" of your transactions on the Parse.com side of the line. The function will be provided with the current user and has the entire JavaScript API at its disposal so that should work.

But it seems overkill to me. Their example aggregates information of many review rows into a single rating which should speed up the transmission of the result. In your case, you compute a new column which you can just as well compute on the client, just like you do.

So I don't see anything wrong with your current approach. I think it's not weird that it's your adapter's job to show the "other party". I'd call it view logic, a choice in how to display the data to the user. So if the adapter needs to show the "other party", then the adapter needs to know which of the two users to filter out.

To separate things a bit more, you could create a currentUser field in the adapter class and fill it in the constructor or use a setter. Then the adapter need not call ParseUser.getCurrentUser() itself. This may for example help you create unit tests for the adapter.

If you want the rest of your code to be more independent of Parse.com, you can create some kind of Data Access Object that computes the "other party" column and also transforms the data to non-Parse.com objects. Seems like a different kind of overkill to me though.