Добавляешь свою функцию в постгресс через миграцию, а потом вызываешь как я выше написал

т.е. по имени процедуры?

query = "SELECT CASE WHEN extract_long_from_ip('#{ip}') <= endip\n THEN geo_ip_city_id\n ELSE NULL END AS geo_ip_city_id\n FROM geo_ip_addresses\n WHERE startip <= extract_long_from_ip('#{ip}')\n ORDER BY startip DESC\n LIMIT 1;" result = ApplicationRecord.connection.execute(query).to_a

да это то что я ожидал, а юзается на практике ?

extract_long_from_ip это функция, которую я добавил в postgres

в контроллере в action format.json render json: { orders: orders } orders разматить или до или после

Да,да и тогда можно отдать заказы через сериалайзер. И в нем удобно прописать все что нужно возвращать. Не собирая результат руками

контроллер заказа?

простите за глупый вопрос

ну да

ну index например

ага, спасибо за помощь)

def index orders = Order.all.includes(:dishes) respond_with orders, serializer: OrderSerializer end class OrderSerializer < ActiveModel::Serializer root false attributes :id, :dishes_names, :total_price def dishes_names object.dishes.pluck(:name) end def total_price object.dishes.sum(:price) end end Что-то в таком духе

понял)

def index orders = Order.all.includes(:dishes) respond_with orders, serializer: OrderSerializer end class OrderSerializer < ActiveModel::Serializer root false attributes :id, :dishes_names, :total_price def dishes_names object.dishes.pluck(:name) end def total_price object.dishes.sum(:price) end end Что-то в таком духе

Кстати, а ты не проверял, что быстрее? Например получить коллекцию из базы, потом вызвать на нее .map , а потом render json?

Хотя тут очевидно через сериалайзер быстрее

сегодня прям день готовых ответов на канале

Хотя тут очевидно через сериалайзер быстрее

Не очевидно. Мое решение явно неоптимальное. Потому что скорее всего0 получается по два запроса на каждый заказ =)) Зато красиво )) Самое правильное все таки собрать через JOIN или еще как, но одним запросом.

Не очевидно. Мое решение явно неоптимальное. Потому что скорее всего0 получается по два запроса на каждый заказ =)) Зато красиво )) Самое правильное все таки собрать через JOIN или еще как, но одним запросом.

Я про другое. Вопрос был быстрее прогнать .map на готовую коллекцию, а потом render json или сразу отправить в сериалайзер

Потому что не только сам запрос в базе выполняется несколько раз но и задержки на вызов и получение из базы из ruby будут отнимать много времени.

сам задал вопрос, сам ответил, быстрее через сериалайзер

Мне кажется тож на тож ))

object.dishes.sum(:price) если вот это заменить на object.dishes.pluck(:price).sum

то будет 2 запроса на всю коллекцию

ага

в базах данных Join самая дорогая операция же ?

не будет один запрос

а sum вызовется у массива

в базах данных Join самая дорогая операция же ?

Там в базах столько наворочено штук что я думаю наверняка найдется что то дороже =))

в моем случае да, а массив объектов вложенных выгрузится вместе с массивом заказов

в базах данных Join самая дорогая операция же ?

Так судить нельзя ) ну COUNT не дешевая кстати, если много строк

читаю просто книгу - пишут : Одной из наиболее дорогостоящих операций при выполнении оператора select является операция соединения таблиц.

ILIKE тоже думаю не дешевая на больших объемах

там это пишут в рассуждениях о количестве отношений

по русски таблиц

я не проверял, но считаю, что на небольших объемах дешевле сделать 2 запроса в БД, чем 1 но джоин, может я ошибаюсь.

тоесть есть 2 большие таблицы, надо выбрать из одной 10 элементов и потом из другой на основании предыдущей выборки выбрать еще 20

может Андрей меня поправит

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

и тут можно поспорить

в базу есть задержка на вызов, как говорил Андрей выше

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

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

Нормализуй не нормализуй все равно приходится дублировать информацию. Чтобы поменьше join делать.

вот выше пример, посчитать из массива сумму в РАЗЫ быстрее, чем для каждого элемента из БД

Собрать все данные со всеми расчетами в базе будет все же быстрее. Но код сложнее пишется и выглядит.руби медленней постгреса :)

есть над чем подумать)

есть над чем подумать)

Хватит думать. Ищи работу.

Пока ты думаешь кто то получает реальный опыт. И потом будет твоим начальником не прочитав и половины того ты прочитал. И будет получать в пять раз больше. Вот.

золотые слова

Хотя я ему по белому завидую, я наверняка и половины того, что он прочитал не прочту за ближайшие год - два

если смогу собеседование пройти, обязательно перестану заниматься фигней)

На счет чтения

Может модератор составит список литературы обязательной к прочтению.

?

это надо у Ro спрашивать

а и не будет единого мнения что читать

у меня свой список для рекомендации, и вряд-ли с ним согласятся) знаю только с какими двумя книгами тут всерее всего все согласятся)

Если не сложно скинь ссылки на них поглядеть

Если не сложно скинь ссылки на них поглядеть

https://vk.com/wall-54530371_22 https://www.htbook.ru/kompjutery_i_seti/setevye_tekhnologii/ruby-on-rails-dlya-nachinayuschih желательно это же на английском в последних изданиях

Спасибо

ERROR: S client not available

Одмины, взываю к вам!!!

Прибери пожалуйста

ERROR in ./source/stylesheets/app.css.scss Module parse failed: Unexpected character '@' (1:0) You may need an appropriate loader to handle this file type. | @charset "utf-8"; | | @import "normalize"; @ ./source/javascripts/all.js 13:0-23

кто в вебпаке силен?

что написано я понимаю

но непонятно как пофиксить. пока гугление ни к чему не привело

@ не нравится в самом начале

И тебе 'может быть нужен соответствующий лоадер (модуль) для того, чтобы работать с файлами такого типа'

Как-то так, но в вебпэке особо не шарю

https://sass-scss.ru/documentation/ispolzovanie_sass/kodirovka.html тут написано что UTF-8 по дефолту. в другом месте писали что надо UTF-8 обязательно в верхнем регистре писать

но я не шарю )

крут

на майские праздники если есть #админы, то на лого поставят ;) @ro31337 @dronixa @svetarybalkina

Здравствуйте, позвольте задать глупый вопрос, над которым ломаю голову два дня. Очень глупый Я настроил elastcsearch, и из консоли он ищет то что нужно. вопрос, а как сделать это чтобы через вьюху можно было найти? то есть, на 1 странице поиск и вывод ней же, только ниже. я пробовал сделать нечто такое: view: <%= form_tag(controller: 'catalog', action: 'search_ajax', method: "get") do %> <input class="form-control" id="search-text" type="text" name="search" placeholder="Поиск по ..." data-search> <button class="btn btn-default btn-search">Искать</button> <% end %> controller: def search_ajax @article = Article.search(params[:search]).results.to_a end

дебажить надо

скорее всего у тебя под это вьюхи нет и потому надо делать что-то вида def search_ajax articles = Article.search... render json: articles end

а потом при помощи js надо парсчить json и отрисовывать

скорее всего у тебя под это вьюхи нет и потому надо делать что-то вида def search_ajax articles = Article.search... render json: articles end

Отдельной нет. Но вывод же должен быть на той же странице к которой привязан контроллер.

ох...

ты представляешь как работает ajax ?

по сути твой клиент при помощи js отправляет отдельный запрос на сервер, который ищет данные и возвращает ответ, который при помощи JS как-то обрабатывается

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

лопни мои глаза

Мдааа

? это пздец

патриотично же(нет)

Похоже, эта красная штука в логотипе чатика символизирует перекованное орало (символ трудолюбия и твердости), которым пашут гранит науки с таким задором, что искры летят!

рубин науки