Всем привет. Есть неймспейс Api::V1::Admin, и есть модель Admin, когда инициализирую модель в этом неймспейсе, то рельса начинает ругаться. Есть способ это побороть или придется менять имена?

обращаться через fully qualified name, i. e. для верхнего неймспейса писать ::Admin вместо Admin

обращаться через fully qualified name, i. e. для верхнего неймспейса писать ::Admin вместо Admin

да, точно, спасибо

Кто-то пробовал кастомизировать экшны в activeadmin?

да, не понравилось

На "javascript_include_tag" указывает

Не знаете как заставить роуты нормально отображаться?

это чё за убунту такая красивая

Не знаете как заставить роуты нормально отображаться?

а что не так с ними кроме того что в строку не влазит?)

Вот я об этлм

Дома размера монитора хватает

А на работе нет

Неудобно так искать что-то

мне кажется никак

это чё за убунту такая красивая

Обычная юнити

а что за версия

поиграй со шрифтами)

а то у меня дизайн как у 14.04

хотя стоит 17.10

поиграй со шрифтами)

Зрение слабое, не вариант уменьшать

напиши свою рейк задачу которая будет выводить роуты как хочешь

16.04

ну вот у меня стояла 17 и чёт вообще не так красиво выглядела

кто-то сталкивался с проблемой работы дебаггера в рубимайн?

не реагирует на брэйкпоинты

Народ, а с помощью интерфейса запросов AR можно написать типа тагого запроса BEGIN; INSERT INTO votes (post_id, value, created_at, updated_at) VALUES (#{post_id}, #{value}, current_timestamp, current_timestamp); UPDATE Posts SET avg_rating = temp.avg_rating From (Select ROUND(AVG(Votes.value),3) as avg_rating From Votes Where post_id = #{post_id} Group by post_id) as temp Where id = #{post_id}; COMMIT; ? ну чтобы не голым sql? чисто из интереcа

ну вот у меня стояла 17 и чёт вообще не так красиво выглядела

Так темы, иконки и тд на любой версии можно менять Тема - flatabulos master, иконки - numix circle

Народ, а с помощью интерфейса запросов AR можно написать типа тагого запроса BEGIN; INSERT INTO votes (post_id, value, created_at, updated_at) VALUES (#{post_id}, #{value}, current_timestamp, current_timestamp); UPDATE Posts SET avg_rating = temp.avg_rating From (Select ROUND(AVG(Votes.value),3) as avg_rating From Votes Where post_id = #{post_id} Group by post_id) as temp Where id = #{post_id}; COMMIT; ? ну чтобы не голым sql? чисто из интереcа

интересует транзакция, insert или update?

обе в одном запросе

но это же два запроса

Народ, а с помощью интерфейса запросов AR можно написать типа тагого запроса BEGIN; INSERT INTO votes (post_id, value, created_at, updated_at) VALUES (#{post_id}, #{value}, current_timestamp, current_timestamp); UPDATE Posts SET avg_rating = temp.avg_rating From (Select ROUND(AVG(Votes.value),3) as avg_rating From Votes Where post_id = #{post_id} Group by post_id) as temp Where id = #{post_id}; COMMIT; ? ну чтобы не голым sql? чисто из интереcа

плюс-минус можно навскидку

у тебя в любом случае будет 2 запроса, но можно в 1 транзакции

те как один запрос сделать с помошью AR нельзя?

так у тебя и тут 2 запроса

в AR будет тоже самое

смотри http://prntscr.com/j19sa5

первый запрос уйдет как чистый sql и сразу выполнятся два селекта, да я понимаю что это бесполезный запрос, но так для примера

во втором случае как я понимаю открывается транзация т летит первый запрос

потом рещультатат возвращается

и летит второй запрос в рамках этой же транзакции

нельзя

вот

ок спс

не понимаю чего конкретно ты пытаешься добиться.. как ни крути, в том коде что ты скинул, у тебя 2 SQL запроса (INSERT и UPDATE) обернутые в 1 транзакцию. На AR это будет что-то вроде такого Post.transaction do create_vote update_post_rating end

Да два, два, только выполнение разное, почитай мой пример выше

create_vote - выполнится и вернет id, а потом удетит второй!

те как я понимаю запрос ->данные на сервер, и снова запрос с сервера

не понимаю чего конкретно ты пытаешься добиться.. как ни крути, в том коде что ты скинул, у тебя 2 SQL запроса (INSERT и UPDATE) обернутые в 1 транзакцию. На AR это будет что-то вроде такого Post.transaction do create_vote update_post_rating end

он пытается добится выполнения нескольких запросов за один запрос к БД/ (i. e. если до БД задержка 100мс — потратить на это 100мс, а не 200).

а к меня запрос на сервер и вначале выполнился инсрт и сразу апдейт без колбека на app сервер

да

ojab правильно говорит!

теперь понял

правда не вижу особой нужды в этом

Это же норм практика?

ну скорость

я понимаю ято мелочи но все же

В современном мире главное скорость разработки, а не скорость работы...

инетересно было

сомнительный выигрыш, тут не такие тяжелые запросы

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

да можно и подругому рейтинг считать, просто тут спич можно так сделать или нет)) Спасибо)

https://www.rubyjobs.ru/vacancies/5457

они делают Gemfile.lock >> .gitignore

Чёт я проморгал факт, что в 5.1 рельсе выпилили зависимость jquery

Да

А с этой траблой, вопрос вроде решён

На "javascript_include_tag" указывает

Магия rails, только сказал и снова сломалось)

Всем привет! Разбираюсь с синатрой. У синатры есть возможность выставить 'thin' сервер, однако чтобы заюзать асинхронные запросы, нужно ставить async-sinatra. У меня тогда вопрос, а в чем фишка использовать thin без этого гема? Могу я в таком случае в роутингах синатры использовать методы эвент машины и посылать отложенные ответы на запросы?

чтобы несколько запросов одновременно обрабатывались

webrick одновременно обрабатывает только один запрос, например

ну и thin уже не модно, puma моднее (то бишь развивается, в отличие от. И в рельсах по умолчанию puma, например)

Попробуй url вида /v1/vacancies/published.json - тогда jbuilder view должно подцепиться

Подскажите, правильная ли структура: class User < ApplicationRecord end class Manager < User belongs_to :admin end class Admin < User has_many :managers end Мне нужно чтобы админ мог иметь много менеджеров и менеджеры принадлежали к определенному админу. Использование STI структуры в этом случае норм?

А зачем наследоваться от юзера?

потому что это STI

А зачем наследоваться от юзера?

админ должен уметь все что умеет юзер к примеру создавать или редактировать посты, свои или менеджерские

может тогда модуль include сделать

лучше

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

Админ так же должен млчь делать что может менеджер

Ну и почему не модулями объединять логику?

Ну и почему не модулями объединять логику?

вот да, спс наверное модулями лучше

Реал

Мне кажется так очевиднее

Подскажите, правильная ли структура: class User < ApplicationRecord end class Manager < User belongs_to :admin end class Admin < User has_many :managers end Мне нужно чтобы админ мог иметь много менеджеров и менеджеры принадлежали к определенному админу. Использование STI структуры в этом случае норм?

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

и тогда не будет никаких проблем

та поле Роль добавить всем, а манагерам admin_id

чем плохой вариант?

ну тут все от задачи зависит, если тебе нужны реально разные юзеры, с своими интерфейсами, логинами, я бы советовал юзать несколько моделей, раздельных без STI, а так можно просто через роли

как написал Роман

а например менеджеров ты лобо по форинкею сделаешь, либо можно промежуточную таблицу

та поле Роль добавить всем, а манагерам admin_id

ага, типа как тут https://stackoverflow.com/a/8493406

промежуточная таблица как по мне удобнее будет, не надо хламить ИД