Архитектура от-до отношения NoSql

Question

Я борюсь с этой архитектурной проблемой на моем документе Parse.com. У меня есть следующий «схема», которая называется дебет:

"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" 

от и до «колонны» являются указателями на _User таблице. Проблема в том, что в моем приложении для Android я хотел бы отображать как from, так и to дебетов в соответствии с зарегистрированным пользователем, но на моем адаптере отображается только пользователь «не зарегистрированного пользователя».

Я пробовал сделать запрос or на Parse, чтобы получить все запросы дебетов, но я не могу включить указатель пользователя, потому что на or запросов Parse не поддерживает.

Как это:

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)); 

Но проблема при показе "не я" адаптер:

адаптер:

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

Конечно, мне нужно получить пользователь, который в адаптере это не очень хорошая идея. Итак, есть ли лучший подход к стороне базы данных, чтобы улучшить это?

Благодаря

Answer 1

Анализировать представляют собой базу данных и API будет посылать вам запись, поскольку они находятся в базе данных. Вы можете создать Parse.com cloud function, если вы хотите вычислить «другую сторону» ваших транзакций на стороне Parse.com линии. Функция будет предоставлена ​​текущему пользователю и имеет в своем распоряжении весь API JavaScript, который должен работать.

Но это кажется излишним для меня. Их пример объединяет информацию многих строк обзора в единый рейтинг, который должен ускорить передачу результата. В вашем случае вы вычисляете новый столбец, который вы можете просто вычислить на клиенте, как и вы.

Поэтому я не вижу ничего плохого в вашем текущем подходе. Я думаю, что не странно, что задача вашего адаптера - показать «другую сторону». Я бы назвал это логикой просмотра, выбор в том, как отображать данные пользователю. Поэтому, если адаптеру необходимо отобразить «другую сторону», адаптер должен знать, какой из двух пользователей должен отфильтровать.

Чтобы отделить вещи немного больше, вы можете создать поле класса currentUser в классе адаптера и заполнить его в конструкторе или использовать установщик. Тогда адаптер не должен звонить сам ParseUser.getCurrentUser(). Это может, например, помочь вам создать модульные тесты для адаптера.

Если вы хотите, чтобы остальная часть вашего кода была более независимой от Parse.com, вы можете создать какой-то объект доступа к данным, который вычисляет столбец «Другая сторона», а также преобразует данные в объекты nonParse.com , Похоже, что для меня это слишком много.