Все дальнейшие примеры используют следующую простую схему данных
- persons
- books
- companies
person properties:
|
book properties:
|
company properties:
|
Тестовая база выложена на сайте databoom.space
Тестовые данные можно посмотреть используя OData URL samples.databoom.space/api1/sampledb/collections/allobjects
1. Как получить массив объектов, на которые кто-то ссылается
Предположим мы хотим получить список книг, которые нравятся какому-либо человеку
Чтобы получить человека с id 'person1', мы можем написать
.../persons(person1)
Чтобы получить книги, которые нравятся этому человеку, добавим к URL имя свойства likes
.../persons(person1)/likes
Теперь мы можем пойти дальше и найти все издательства, издавшие книги, которые нравятся person1
.../persons(person1)/likes/publisher
2. Как получить массив объектов которые на кого-то ссылаются
В предыдущем примере мы получали список книг, которые нравятся какому человеку с id 'person1'.
Теперь мы хотим получить всех людей которым нравится книга с id 'book2'. Обратите внимание человек через свойство likes ссылается на книги которые он любит, а книги не ссылаются на людей, которые их любят.
Чтобы получить книгу с id ‘book2’, мы можем написать
.../books(book2)
Мы не можем написать .../books(book1)/persons_who_likes — у книги нет такого свойства
Тогда мы пишем
.../books(book1)/_backlink(likes)
_backlink(likes) — это как бы обратный линк для линка likes
likes — что любят
_backlink(likes) — кто любит
В некоторых реализациях OData преполагается что разработчик должен завести псевдо свойство поименованное например persons_who_likes и самостоятельно написать обработчик таких запросов. Оператор _backlink не входит в стандарт, но может иногда существенно упростить работу.
Если Вас заинтересовал данный пост, Вы можете также посмотреть нашу документацию и примеры использования REST API, а также примеры с использованием JavaScript библиотеки
В следующем посте мы расскажем, как отфильтровать объекты с учетом их взаимосвязей.
Комментарии (18)
drakmail
18.07.2015 09:29А как в OData с обновлением вложенных свойств? Например для
studio: { addresses: [{ groups: [{ job_name: "rnb" }, { job_name: "test", }] }] }
Нужно обновить group, в которой job_name равен rnb. Как это правильнее сделать? Или тут правильнее хранить линк на job_id для списка jobs и просто обновлять job?
databoom Автор
18.07.2015 13:30можно прямо так сохранять — но нужно однозначно идентифицировать каждый job — если хочется его проапдейтить
мы обязательно расскажем подробнее про добавление вложенных объектов в следующих постахdataboom Автор
18.07.2015 13:40идентифицировать — имеется в виду выставить ключевое поле — в разных реализациях OData это может быть поле id, _id и т.д. или же тот же набор полей, что в базе названы ключом
drakmail
18.07.2015 14:56Да, было бы очень интересно прочитать. Недавно столкнулся с проблемой, что в монге просто так работать с вложенными объектами не получится (да, надо было читать матчасть сначала :))
vintage
18.07.2015 20:231. А как получить все необходимые мне данные (понравившиеся книги, их издательства, кому они ещё понравились и тд) одним запросом, а не десятком последовательных запросов?
2. Прямые ссылки нормальные, а обратные через какие-то костыли. Почему бы не сделать модель с нормальными двусторонними ссылками (likedBook — likesPerson или in_likes — out_likes)?
databoom Автор
18.07.2015 21:351) А как получить все необходимые мне данные (понравившиеся книги, их издательства, кому они ещё понравились и тд) одним запросом, а не десятком последовательных запросов?
для этого существует опция $expand
например получить понравившиеся книги с издательствами и авторами
.../person(person1)/likes?$expand=publisher,author
мы про $expand расскажем подробнее в следующих постах
2. Прямые ссылки нормальные, а обратные через какие-то костыли. Почему бы не сделать модель с нормальными двусторонними ссылками (likedBook — likesPerson или in_likes — out_likes)?
можно даже не предусматривать двусторонние ссылки а просто указать что обратная ссылка с именем likesPerson или out_likes является обратной от likes (или наоборот) — провайдер просто должен иметь информацию как генерить join запрос
вопрос был а если разработчики сервера не описали модель и не написали никаких кодов для обработки таких обратных ссылок — можно ли как то получить данные?
например если провайдер использует schemaless модель — типа сохраняем данные как они есть без описания модели (например, сохраняет данные в mongodb)
vintage
18.07.2015 21:52для этого существует опция $expand
Тогда зачем что-то помимо expand? Я могу написать например: /person(person1)?$expand=likes.publisher,likes.author,likes.publisher.books
databoom Автор
18.07.2015 22:13Да можно раскрыть объекты на любую глубину, но это:
1) Иногда увеличивает объем данных — например, каждая книга одного и того же автора в json будет содержать дублирующуюся информацию об авторе. Мы в одном из постов расскажем как избегать такого дублирования данных.
2) Иногда информация про промежуточные объекты бывает не нужна — например мы просто хотим получить список любимых издательств.
Еще пример, я хочу найти друзей друзей, которые учились со мной в одном институте — зачем мне тысячи человек? мне нужно только несколько.
vintage
18.07.2015 22:361) Иногда увеличивает объем данных — например, каждая книга одного и того же автора в json будет содержать дублирующуюся информацию об авторе. Мы в одном из постов расскажем как избегать такого дублирования данных
Выдавать сущности не развесистым деревом, а плоским списком — не будет никакого дублирования.
Еще пример, я хочу найти друзей друзей, которые учились со мной в одном институте — зачем мне тысячи человек? мне нужно только несколько.
1. Ну так и пляшите от института, а не от друзей.
2. Но даже если выдадут 1000 айдишников — ничего страшного.
3. $expand=likes,likes.publisher и $expand=likes.publisher вполне могут выдавать разный набор данных. Второй вариант просто не выведет информацию о лайках, только список издательств.
databoom Автор
18.07.2015 22:50Выдавать сущности не развесистым деревом, а плоским списком — не будет никакого дублирования.
OData предполагает выдачу в виде дерева в случае $expand — это оговорено в стандартеvintage
18.07.2015 23:56Глупый какой-то стандарт. И как решается проблема дублирования? Данные выдаются только для первого вхождения, а для остальных только айдишник?
databoom Автор
19.07.2015 00:54Вообще то в стандарте это проблема — там в сообществе ведутся споры как это делать — предлагается несколько вариантов — но пока ни один не вошел в текущий стандарт.
Вопрос не в том как сделать а вопрос скорее в синтаксисе с которым согласится большинство :)vintage
19.07.2015 11:16Ну да, а толпа глупа и очень инертна, так что уверен победит самое бестолковое решение :-)
lair
А где хитрости-то?
databoom Автор
они мелкие :)
1) Довольно многие люди не знают что OData позволяет переходить по ссылкам как угодно далеко
/persons(person1)/likes/publisher/president
обычно рассматривают лишь получение объектов по прямой ссылке — /persons(person1)/likes
причем для обработки таких длинных ссылок вовсе не требуется что то писать на сервере — обычно OData провайдеры превращают такую ссылку в запрос автоматически
2) Также возникает проблема построить url — когда нет прямой ссылки на объект и разработчик сервера не позаботился об этом — OData провайдеры такую ссылку тоже превращают в запрос к базе данных автоматически создавая правильный SQL join запрос или аналогичный запрос для NoSQL баз данных
lair
Что значит «обычно OData провайдер»? По-моему, как на той стороне сочтут нужным ограничить, так и будет.
databoom Автор
могут лишь ограничить доступ к таким длинным ссылкам — но не поменять семантику — если мы по ссылке
/persons(person1)/likes/publisher/president — получим не президентов компаний издавших книги, которые нравятся person1 — то это уже самодельный REST API а не OData
lair
Ну, достаточно ограничить, чтобы уменьшить количество запросов.