https или http?

поменял proxy_set_header Host $host; на proxy_set_header Host $http_host; просто по чутье и все заработала

хотя пишут Однако, если это поле отсутствует в заголовке запроса клиента, то ничего передаваться не будет. В этом случае лучше воспользоваться переменной $host - её значение равно имени сервера в поле “Host” заголовка запроса, или же основному имени сервера, если поля нет:

Кроме того, можно передать имя сервера вместе с портом проксируемого сервера: proxy_set_header Host $host:$proxy_port;

а так не работает

а теперь сделал так proxy_set_header Host $host:$server_port; вроде тоже работает че кчему

https://semaphoreci.com/blog/2017/08/09/faster-rails-eliminating-n-plus-one-queries.html?utm_source=rubyweekly&utm_medium=email

Уже обсуждали

но напомнте

зачем каждый месяц писать подобную статью?

в рубивикли из выпуска в выпуск пихают что-то типа "Вся правда про N+1"

Потому что у каждого в выпуске есть кусочек уникального контента

что нибудь крутое для логирование воркеров есть у вас на примете?

resque

обычный логгер?

или что тебе надо?

Да

Rails.logger ?

Или нужно что то вроде rollbar?

Ребят, есть paperclip, есть рекорды, каждый из которых имеет image. Задача в том что бы сделать копию, в теории будет много копий одной записи. Изначально даже не подумал, и просто дублировал всё как есть. Теперь начал думать о том что таким образом будет создаваться много одинаковых файлов image на сервере. Есть какой-нибудь тривиальный путь решения проблемы? предложили связывать новые записи с уже существующим файлом. Мне кажется что это не безопасно, я ошибаюсь?

hardlink

правда реализацию придется самому писать

где-то в недрах обработки файлов

вообще paperclip не очень то дает модифицировать свой код, так что я бы посоветовал переехать на carrierwave

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

Не вариант переходить. По простому подменить линки я так понимаю не получится

Ребят, есть paperclip, есть рекорды, каждый из которых имеет image. Задача в том что бы сделать копию, в теории будет много копий одной записи. Изначально даже не подумал, и просто дублировал всё как есть. Теперь начал думать о том что таким образом будет создаваться много одинаковых файлов image на сервере. Есть какой-нибудь тривиальный путь решения проблемы? предложили связывать новые записи с уже существующим файлом. Мне кажется что это не безопасно, я ошибаюсь?

А что небезопасного?

Много записей становятся зависимыми от одного файла в системе

дернул destroy на одной модельке - снес у всех файлы

Не вариант переходить. По простому подменить линки я так понимаю не получится

ну тогда придется код самого paperclip править

https://github.com/thoughtbot/paperclip#file-preservation-for-soft-delete

https://github.com/thoughtbot/paperclip#file-preservation-for-soft-delete

забавно, а как потом его удалить?

А при каких условиях надо удалять?

ну когда-нибудь файлы обчно надо удалять

что бы место не занимали

https://github.com/thoughtbot/paperclip#custom-attachment-processors

Таску написать, которая будет периодически запускаться и по условию удалять.

можно попробовать написать свой процессор который будет делать картинку хардлинком имеющейся при дублировании

и дергать его как-то именно при дублировании

md5 вычисляй файла

и проверяй, есть ли уже запись с таким md5

можно попробовать написать свой процессор который будет делать картинку хардлинком имеющейся при дублировании

hardlink это просто линк в системе? запись в бд будет распозновать это как другой image под другим путём?

я думал записывать напрямую с таким путём к фалу как оригинальная запись

хардлинк это такая хитрая штука в файловой системе, которая указывает на наборт блоков на жестком диске, где хранится информация

пока ссылка есть - файл есть

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

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

и удалится он только с последней ссылкой

предлагать решения изходя из предположений - странновато

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

это ты щас has many through описал

нет

в чем разница?

https://ru.wikipedia.org/wiki/%D0%96%D1%91%D1%81%D1%82%D0%BA%D0%B0%D1%8F_%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B0

это вообще не иеет отношения к базе данных

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

это структура файловой системы

ааа, ну в целом да

да всем пофиг :)

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

почти

в котором один image как сущность с одним image как файл будет иметь возможность прицепиться к множеству объектов

has many

возможно полиморфно, если есть желание

ERROR: S client not available

Но нужно что бы у оригинаьной записи картинка была одна, а у всех скопированных была вторая (которая копия первой)

что есть картинка, оригинальная запись, копия?

копия - две одинаковых копия - ссылка на первую?

картинка - сущность хранящее расположение файла с изображением? или сам файл с изображением?

кароче в этой задаче большая смысловая размытость

все неоперделено

На данный момент есть таблица в бд, предположм она называется Item(author_id, image, parent_id : polymorph) Владелец Item создаёт запись, эта запись - оригинал. Далее другой User копирует эту запись (это копия). Задача в том, что бы не создавать новый файл в системе каждый раз, когда новый юзер делает копию оригинала Item, но при этом что бы изменение файла оригинальной записи не повлекло изменения во всех скопированных записях

эээ

это как

ну так нельзя :)

типа файл мы имеем один, но если его изменить, то все остальные начинают иметь другой?

но есть событие - изменение оригинальной записи в этот момент все копии должны стать самостоятельными и не ссылаться на оригинал

но лучше это сделать сразу и не экономить на спичках

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

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

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

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

это нужно специально запрограммировать

если специально не программировать проблему - не будет проблемы

Копии должны ссылаться на файл, и этот файл не будет меняться

Копии должны ссылаться на файл, и этот файл не будет меняться

в чем тогда проблема?

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

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

проблемы нет, есть вопрос который я спрашиваю решал ли кто то, и есть ли тривиальный способ его решения. И так - как связать много записей с одним файлом?

image это attachement, реализован через carrierwave

1 запись хранит 1 файл => class Image объекты, копии, пофиг кто имеют не поле image а референс к Image

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

?

да

столько флуда ради решения из учебника

для меня это возможный вариант решения, спасибо. Может для кого то тоже. То что это флуд это субъективное мнение