…и это не ответило ни на один из моих вопросов

В приложение несколько схем используется? В database.yml для них несколько БД прописано?

class Blog::Base < ApplicationRecord establish_connection :blog_schema self.abstract_class = true end

…и это не ответило ни на один из моих вопросов

Т.е используется только одна база данных в зависимости от enviroment

…и это не ответило ни на один из моих вопросов

И в зависимости от того к какой схеме относятся модели, которые наследуют от Base класса, в database.yml выставляется соответствующий schema_search_path

т. е. в итоге в рамках одного environment в database.yml несколько БД с разными schema_search_path?

А на какую схему миграции накатываются?

т. е. в итоге в рамках одного environment в database.yml несколько БД с разными schema_search_path?

Получается что в рамках одного enviroment в database.yml одна БД с разными schema_search_path

ок, для рельс это разные БД

А на какую схему миграции накатываются?

Миграции накатываются не на деафултную public схему

А для рельс это какая БД? Миграции накатываются на единственную схему и при этом зависают?

до сих пор нифига не понятно что у тебя там и что ты пытаешься сделать

до сих пор нифига не понятно что у тебя там и что ты пытаешься сделать

У Postgres схемы это что то типо namespace для таблиц в пределах одной БД.

я понимаю что такое схема в postgres

но вот прямо сейчас я не понимаю на какую БД в database.yml накатываются миграции

если environment (production,staging,etc) — то рельсы это делают самостоятельно, если нет — ты себе что-то накостылил и проблема, вестимо, в этом накостыленном

Всем привет

но вот прямо сейчас я не понимаю на какую БД в database.yml накатываются миграции

Миграции накатываются на дефаултную public схему и на одну дополнительную. Зависает все при накате на дополнительную

я что то вообще отвык в послдеене время от работы с бд

может кто подсказать

SELECT SUM("orders"."amount") AS sum_amount, COUNT(orders.id) as orders_count, DATE(created_at) AS date_created_at FROM "orders" GROUP BY DATE(created_at)

как в activerecord запросе это выразить?

если environment (production,staging,etc) — то рельсы это делают самостоятельно, если нет — ты себе что-то накостылил и проблема, вестимо, в этом накостыленном

environment используются стандартнеы (production, staging, development)

весь вопрос в том, зачем тебе разграничение на схемы в рамках ПГ?

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

Миграции накатываются на дефаултную public схему и на одну дополнительную. Зависает все при накате на дополнительную

и [как я написал выше] непонятно как ты накатываешь миграции на дополнительную схему

если environment (production,staging,etc) — то рельсы это делают самостоятельно, если нет — ты себе что-то накостылил и проблема, вестимо, в этом накостыленном

И самое странное что зависает он не на всех миграциях на эти схемы. Ощущение такое что либо у него connection pool переполняется, либо он создает соединение к заданной схеме и потом его не закрывая пытается создать еще одно но при этом у него это не получается из за того что оно уже открыто

Схемы можно в адаптере задавать

кто-то нас опять запутать хочет

и [как я написал выше] непонятно как ты накатываешь миграции на дополнительную схему

default: &default adapter: postgresql encoding: unicode pool: 5 database: <%= "#{Rails.application.class.parent_name.downcase}_#{Rails.env}" %> production: &production <<: *default staging: &staging <<: *default development: &development <<: *default test: &test <<: *default blog_schema: <<: *<%= Rails.env %> schema_search_path: "blog" shop_schema: <<: *<%= Rails.env %> schema_search_path: "shop"

class Blog::Base < ApplicationRecord establish_connection :blog_schema self.abstract_class = true end

class Blog::Comment < Blog::Base self.table_name = "blog.comments" end

длинный код лучше в gist кидать

Ок. Не когда не приходилось им пользоваться до этого.

default: &default adapter: postgresql encoding: unicode pool: 5 database: <%= "#{Rails.application.class.parent_name.downcase}_#{Rails.env}" %> production: &production <<: *default staging: &staging <<: *default development: &development <<: *default test: &test <<: *default blog_schema: <<: *<%= Rails.env %> schema_search_path: "blog" shop_schema: <<: *<%= Rails.env %> schema_search_path: "shop"

миграция накатывается на БД = environment. Даже если ты укажешь в модели establish_connection — миграция об этом не знает и накатывается на БД = environment.

так что если ты хочешь использовать миграции для нескольких БД (в терминологии рельс) — бери какой-нибудь https://github.com/thiagopradi/octopus или пиши свой костылёк

миграция накатывается на БД = environment. Даже если ты укажешь в модели establish_connection — миграция об этом не знает и накатывается на БД = environment.

Ну да. А мне и не надо чтобы она накатывалась на другую БД.

оу, ты прямо в миграции указываешь create_table 'blog.comments'?

оу, ты прямо в миграции указываешь create_table 'blog.comments'?

Да, схемы я создавал по такому принципу. Но они уже давно есть и работают. Проблема возникает когда надо что то удалить из них (колонки или ряды).

оу, ты прямо в миграции указываешь create_table 'blog.comments'?

В миграции я просто делаю remove_column 'shop.products', :meta_title, :string

оу, ты прямо в миграции указываешь create_table 'blog.comments'?

В этом случае shop это название схемы а products таблица

а в логе какая последняя команда на момент подвисания?

(и постгреса, и рельс)

а в логе какая последняя команда на момент подвисания?

(0.6ms) ALTER TABLE "shop"."products" DROP "schema_name" (0.3ms) ALTER TABLE "shop"."products" DROP "schema_description"

а в логе какая последняя команда на момент подвисания?

В данном случае "schema_name" и "schema_description" это название колонок (так совпало).

чет вы дичь какую-то разводите - дефолт в конструкторе ставить

Чо?

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

если есть возможность валидировать/присваивать значения на уровне БД то это надо делать

Создаем constraint на каждую валидацию рельсовую? Везде задаем дефолты в бд?

Кто-нибудь знает надежный способ сделать артикулы? сейчас after_initialize { self.articul = Product.order(created_at: :desc).limit(1).pluck(:articul).first.succ rescue INITIAL_ARTICUL }

на уровне бд

или не на уровне

создать в БД sequence на колонку

Только еще должно чтобы некоторые данные входили из связанных таблиц

хотя не очень понятно что ты в итоге хочешь получить

Платье belongs_to :size & :color артикул 541254xxls

нене

452145-xxl-r

xxl и r это Size#name & Color#name[0]

А требования к артикулам какие? Есть вероятность что имеет смысл не писать size & color в артикул а отдельным методом в модели собирать из id+size+color.

будет поиск по артикулам

тогда ничего не мешает складывать в колонку id+size+color

Как в simple_form добавить data attributes к каждому option в select?

data: { foo: 1 } ?

http://stackoverflow.com/questions/8326355/simple-forms-custom-data-attribute

нужно для каждого элемента в collection свой

Необходимо перенести пользователей Битрикс в Рельцы а точнее в devise Кто нибудь делал подобное посоветуйте плиз

Битрикс использует вроде как md5 с солью а devise bcrypt просто копировать не получится наверно

ERROR: S client not available

https://github.com/plataformatec/devise/wiki/How-To:-Create-a-custom-encryptor

создаёшь encryptor, который повторяет действия битрикса, и всё работает

создаёшь encryptor, который повторяет действия битрикса, и всё работает

Спасибо! вроде как то что нужно

function isUserPassword($userId, $password) { $userData = CUser::GetByID($userId)->Fetch(); $salt = substr($userData['PASSWORD'], 0, (strlen($userData['PASSWORD']) - 32)); $realPassword = substr($userData['PASSWORD'], -32); $password = md5($salt.$password); return ($password == $realPassword); } хотя чтот не очень врубаюсь

битрикс такой битрикс..

а ты планируешь сделать переход с битры навсегда? ну т.е. ее больше не будет и у тебя будет приложение на рельсах?

Digest::MD5.hexdigest("#{salt}#{password[0, 32]}"), если я знаю php

хм

не, не так

хотя оно, кажется, соль в последних 32 символах хранит

причем тут даже не mb_subst... Кичмар какой

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

да точно, не углядел. Все равно кошмар )

а ты планируешь сделать переход с битры навсегда? ну т.е. ее больше не будет и у тебя будет приложение на рельсах?

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

у вас будет какая-то отдельная БД для нового сервиса или как?

ага

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

я как-то соединялся с WordPress (правда с YII2) чтобы была общая авторизация админки WP и Yii2 админки. Это было то еще приключение. Вообще им скорее всего да, придется переносить. Там жеж структура таблиц ад )

и просто после авторизации сразу ставить флаг

что мол залогился, генерить пароль нормальный в рельсах

и всегда теперь его авторизовывать через рельсы

еще интересно, можно ли объединить сессии :))) допустим пользователь зашел на сайт , и на рельцах авторизовать автоматом без ввода пароля, через кук или сессии как то так :)

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

думаю это будет геморно и костыльно...

я подхачил WP чтобы он в куку пихал WP юзера а потом его доставал из другого сайта, лез в БД WP и там проверял. Так что можно сделать :)

но да, мутить будет потом от этого кода)

про вариант, что я говорил выше, что просто логинится первый раз через битру, а потом переключаться на нормальную логику рельс, можно реализовать вот так - http://4trabes.com/2012/10/31/remote-authentication-with-devise/

Братцы, нутром чую что говнокод, надоумьте как лучше. Задача: проверить есть ли в базе юзер с заданным емейлом, если есть - переписать на него кое какое наследство и удовлетворенно сдохнуть текущему юзеру и залогинить нового. В противном случае апдейтнуть текущего. Это в контроллере код. if logged_in? && current_user.temporary_email? if exist_user = User.find_by_email(address.email) current_user.authentications.update_all(user_id: exist_user.id) user_to_destroy = current_user logout auto_login(exist_user) user_to_destroy.destroy else current_user.update_attribute(email: address.email) end end

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

т.е. тебе надо на текущего юзера перенести какие-то данные с юзера с определенным емейлом если такой есть?

Братцы, нутром чую что говнокод, надоумьте как лучше. Задача: проверить есть ли в базе юзер с заданным емейлом, если есть - переписать на него кое какое наследство и удовлетворенно сдохнуть текущему юзеру и залогинить нового. В противном случае апдейтнуть текущего. Это в контроллере код. if logged_in? && current_user.temporary_email? if exist_user = User.find_by_email(address.email) current_user.authentications.update_all(user_id: exist_user.id) user_to_destroy = current_user logout auto_login(exist_user) user_to_destroy.destroy else current_user.update_attribute(email: address.email) end end

Это devise?

А зачем такое могло понадобиться?