Comments 11
Спасибо большое за туториал. Только прочитал, но еще не пробовал, но очень интересно :)
поддерживаю ) особенно интересны возможности которые появились в derby 0.6. И еще, наверно, сообществу будет интересно вот это обновление которое, как я понял, позволяет более гибко работать с правами на коллекции в базе данных.
Права на коллекцию? Там же просто указываются, какие поля документа отсылаются пользователю или о чём речь?
Ну да — просто куказываются поля, например в server.js можно прописать:
А потом можно через racer-access запретить доступ к коллекции users и пользователь сможет увидеть только то, что есть в users_small, обращаясь к ней как к обычной коллекции
// Добавляем проекцию к колекции users
store.shareClient.backend.addProjection("users_small", "users", "json0", {id: true, name:true, email:true});
А потом можно через racer-access запретить доступ к коллекции users и пользователь сможет увидеть только то, что есть в users_small, обращаясь к ней как к обычной коллекции
Ну это никак не «гибко работать с правами на коллекции» (-:
Это, цитата, «can expose a fake collection which maps a few fields from a real collection». Это просто усечённая версия исходной коллекции, а вот потом «можно через racer-access запретить доступ к коллекции users». Разве это чем-то сильно отличается создания users и auths? Просто сейчас это две коллекции, а потом будет одна (по сути — users+auths), из которой создаётся фейковая — users.
Мне видится, что это никак не связано с гибкостью и уж точно не с правами доступа, а с тем, чтоб поменьше трафика гонять на больших коллекциях, когда много не нужной пользователям и служебной информации…
Это, цитата, «can expose a fake collection which maps a few fields from a real collection». Это просто усечённая версия исходной коллекции, а вот потом «можно через racer-access запретить доступ к коллекции users». Разве это чем-то сильно отличается создания users и auths? Просто сейчас это две коллекции, а потом будет одна (по сути — users+auths), из которой создаётся фейковая — users.
Мне видится, что это никак не связано с гибкостью и уж точно не с правами доступа, а с тем, чтоб поменьше трафика гонять на больших коллекциях, когда много не нужной пользователям и служебной информации…
на гитхабе в package.json
«derby»: «0.6.0-alpha6»,
должно быть -alpha7 с 6 не работает.
«derby»: «0.6.0-alpha6»,
должно быть -alpha7 с 6 не работает.
Поправил, спасибо. Обновился racer (там тоже альфа-версии 0.6), там немного api поменялось, а в зависимостях у дерби указано racer 0.6+. В результате derby 0.6.0-alpha6 щас вообще не заработает ни при каких условиях. Нужно сделать скиднку на то, что мы работаем с альфами — создатели об этом у себя написали — возможно изменение api.
(по поводу разделение клиента/сервера попозже напишу, после работы)
(по поводу разделение клиента/сервера попозже напишу, после работы)
Новый модуль авторизации для Derby 0.6 с проекциями и на чистом js.
github.com/vmakhaev/derby-login
Версия derby-starter с авторизацией: github.com/vmakhaev/derby-starter/tree/auth
Пример приложения: github.com/vmakhaev/auth-example
github.com/vmakhaev/derby-login
Версия derby-starter с авторизацией: github.com/vmakhaev/derby-starter/tree/auth
Пример приложения: github.com/vmakhaev/auth-example
Sign up to leave a comment.
Изучаем Derby 0.6, пример #3