Comments 18
А где хитрости-то?
они мелкие :)
1) Довольно многие люди не знают что OData позволяет переходить по ссылкам как угодно далеко
/persons(person1)/likes/publisher/president
обычно рассматривают лишь получение объектов по прямой ссылке — /persons(person1)/likes
причем для обработки таких длинных ссылок вовсе не требуется что то писать на сервере — обычно OData провайдеры превращают такую ссылку в запрос автоматически
2) Также возникает проблема построить url — когда нет прямой ссылки на объект и разработчик сервера не позаботился об этом — OData провайдеры такую ссылку тоже превращают в запрос к базе данных автоматически создавая правильный SQL join запрос или аналогичный запрос для NoSQL баз данных
1) Довольно многие люди не знают что OData позволяет переходить по ссылкам как угодно далеко
/persons(person1)/likes/publisher/president
обычно рассматривают лишь получение объектов по прямой ссылке — /persons(person1)/likes
причем для обработки таких длинных ссылок вовсе не требуется что то писать на сервере — обычно OData провайдеры превращают такую ссылку в запрос автоматически
2) Также возникает проблема построить url — когда нет прямой ссылки на объект и разработчик сервера не позаботился об этом — OData провайдеры такую ссылку тоже превращают в запрос к базе данных автоматически создавая правильный SQL join запрос или аналогичный запрос для NoSQL баз данных
причем для обработки таких длинных ссылок вовсе не требуется что то писать на сервере — обычно OData провайдеры превращают такую ссылку в запрос автоматически
Что значит «обычно OData провайдер»? По-моему, как на той стороне сочтут нужным ограничить, так и будет.
А как в OData с обновлением вложенных свойств? Например для
Нужно обновить group, в которой job_name равен rnb. Как это правильнее сделать? Или тут правильнее хранить линк на job_id для списка jobs и просто обновлять job?
studio: {
addresses: [{
groups: [{
job_name: "rnb"
}, {
job_name: "test",
}]
}]
}
Нужно обновить group, в которой job_name равен rnb. Как это правильнее сделать? Или тут правильнее хранить линк на job_id для списка jobs и просто обновлять job?
можно прямо так сохранять — но нужно однозначно идентифицировать каждый job — если хочется его проапдейтить
мы обязательно расскажем подробнее про добавление вложенных объектов в следующих постах
мы обязательно расскажем подробнее про добавление вложенных объектов в следующих постах
идентифицировать — имеется в виду выставить ключевое поле — в разных реализациях OData это может быть поле id, _id и т.д. или же тот же набор полей, что в базе названы ключом
Да, было бы очень интересно прочитать. Недавно столкнулся с проблемой, что в монге просто так работать с вложенными объектами не получится (да, надо было читать матчасть сначала :))
1. А как получить все необходимые мне данные (понравившиеся книги, их издательства, кому они ещё понравились и тд) одним запросом, а не десятком последовательных запросов?
2. Прямые ссылки нормальные, а обратные через какие-то костыли. Почему бы не сделать модель с нормальными двусторонними ссылками (likedBook — likesPerson или in_likes — out_likes)?
2. Прямые ссылки нормальные, а обратные через какие-то костыли. Почему бы не сделать модель с нормальными двусторонними ссылками (likedBook — likesPerson или in_likes — out_likes)?
1) А как получить все необходимые мне данные (понравившиеся книги, их издательства, кому они ещё понравились и тд) одним запросом, а не десятком последовательных запросов?
для этого существует опция $expand
например получить понравившиеся книги с издательствами и авторами
.../person(person1)/likes?$expand=publisher,author
мы про $expand расскажем подробнее в следующих постах
2. Прямые ссылки нормальные, а обратные через какие-то костыли. Почему бы не сделать модель с нормальными двусторонними ссылками (likedBook — likesPerson или in_likes — out_likes)?
можно даже не предусматривать двусторонние ссылки а просто указать что обратная ссылка с именем likesPerson или out_likes является обратной от likes (или наоборот) — провайдер просто должен иметь информацию как генерить join запрос
вопрос был а если разработчики сервера не описали модель и не написали никаких кодов для обработки таких обратных ссылок — можно ли как то получить данные?
например если провайдер использует schemaless модель — типа сохраняем данные как они есть без описания модели (например, сохраняет данные в mongodb)
для этого существует опция $expand
например получить понравившиеся книги с издательствами и авторами
.../person(person1)/likes?$expand=publisher,author
мы про $expand расскажем подробнее в следующих постах
2. Прямые ссылки нормальные, а обратные через какие-то костыли. Почему бы не сделать модель с нормальными двусторонними ссылками (likedBook — likesPerson или in_likes — out_likes)?
можно даже не предусматривать двусторонние ссылки а просто указать что обратная ссылка с именем likesPerson или out_likes является обратной от likes (или наоборот) — провайдер просто должен иметь информацию как генерить join запрос
вопрос был а если разработчики сервера не описали модель и не написали никаких кодов для обработки таких обратных ссылок — можно ли как то получить данные?
например если провайдер использует schemaless модель — типа сохраняем данные как они есть без описания модели (например, сохраняет данные в mongodb)
для этого существует опция $expandТогда зачем что-то помимо expand? Я могу написать например: /person(person1)?$expand=likes.publisher,likes.author,likes.publisher.books
Да можно раскрыть объекты на любую глубину, но это:
1) Иногда увеличивает объем данных — например, каждая книга одного и того же автора в json будет содержать дублирующуюся информацию об авторе. Мы в одном из постов расскажем как избегать такого дублирования данных.
2) Иногда информация про промежуточные объекты бывает не нужна — например мы просто хотим получить список любимых издательств.
Еще пример, я хочу найти друзей друзей, которые учились со мной в одном институте — зачем мне тысячи человек? мне нужно только несколько.
1) Иногда увеличивает объем данных — например, каждая книга одного и того же автора в json будет содержать дублирующуюся информацию об авторе. Мы в одном из постов расскажем как избегать такого дублирования данных.
2) Иногда информация про промежуточные объекты бывает не нужна — например мы просто хотим получить список любимых издательств.
Еще пример, я хочу найти друзей друзей, которые учились со мной в одном институте — зачем мне тысячи человек? мне нужно только несколько.
1) Иногда увеличивает объем данных — например, каждая книга одного и того же автора в json будет содержать дублирующуюся информацию об авторе. Мы в одном из постов расскажем как избегать такого дублирования данныхВыдавать сущности не развесистым деревом, а плоским списком — не будет никакого дублирования.
Еще пример, я хочу найти друзей друзей, которые учились со мной в одном институте — зачем мне тысячи человек? мне нужно только несколько.
1. Ну так и пляшите от института, а не от друзей.
2. Но даже если выдадут 1000 айдишников — ничего страшного.
3. $expand=likes,likes.publisher и $expand=likes.publisher вполне могут выдавать разный набор данных. Второй вариант просто не выведет информацию о лайках, только список издательств.
Выдавать сущности не развесистым деревом, а плоским списком — не будет никакого дублирования.
OData предполагает выдачу в виде дерева в случае $expand — это оговорено в стандарте
Глупый какой-то стандарт. И как решается проблема дублирования? Данные выдаются только для первого вхождения, а для остальных только айдишник?
Sign up to leave a comment.
OData REST API — мелкие хитрости (часть 1)