а еще можно статической переменной в контроллере :D

нельзя. Это же не "передать в new из create"

у меня выводится список билетов, напротив каждого есть кнопка купить, эта кнопка через парамс передает информацию в экшен show контроллера tickets, в show выводится информация о билете и есть кнопка купить(типа подтверждение)

так это поле должен видеть пользователь или нет?

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

своим ключом каким-нибудь

потом расшифровать в create

только какой в этом смысл, если ты явно передаешь эти параметры в new, непонятно)

ох гемор

хотя

у меня выводится список билетов, напротив каждого есть кнопка купить, эта кнопка через парамс передает информацию в экшен show контроллера tickets, в show выводится информация о билете и есть кнопка купить(типа подтверждение)

Какую информацию?

ох гемор

Смотрие есть ассоциация has_one, belongs_to. Также вы можете устанавливать primary key - какой захотите. Почему вместо какого-то там поля не хранить просто ключь к другой таблице, в которой по этому ключу будет записано все что вам надо?

Смотрие есть ассоциация has_one, belongs_to. Также вы можете устанавливать primary key - какой захотите. Почему вместо какого-то там поля не хранить просто ключь к другой таблице, в которой по этому ключу будет записано все что вам надо?

Всмысле?

Всмысле?

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

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

Ну, ключом именуется

Есть у тебя таблица A с тремя записями с id 1, 2, 3 Есть у тебя таблица B с одной записью, которая относится к записи 2 из таблицы A У этой записи из B есть поле: a_id, где записано 2

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

В каком смысле?

если пользователь что-то наколобродит то просто уткнется в null

Мы же связываем одну ТАБЛИЦУ с другой, в другой может быть более чем одно значение

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

Менять по всем его записям?

Мы же связываем одну ТАБЛИЦУ с другой, в другой может быть более чем одно значение

это 100% правда. ну значит надо исползьовать has_and_belongs_to_many

Схерали?

воу-воу

Это если у поста может быть несколько авторов

Тогда надо

Я понял, тебя смущает has_one

habtm вообще спорный момент, даже когда он применим)

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

Схерали?

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

Нужно использовать has_many в авторе

И belongs_to в посте

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

Нет

Нет

а почему-то нет то?

а почему-то нет то?

В каком смысле скрыть

Связи не для этого нужны

изначалоьно был дана вводная: а как создать text_filed такой в котором нельзя изменить значени?

Через валидацию

можно передавть ключь от записи в базе данных. И потом проверять этот ключь на валидность.

(отошел на 20 мин собаку прогулять)

можно передавть ключь от записи в базе данных. И потом проверять этот ключь на валидность.

Что за херню ты несешь?

Что за херню ты несешь?

это ты понять не можешь общей мысли.

которая связана на паре постов.

Котооыре написал Дмитрий и Илья

Я понял их мысль, я не понял каким боком тут связи

Я понял их мысль, я не понял каким боком тут связи

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

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

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

Там вообще даже модель ни при чём в той задаче

Там вообще даже модель ни при чём в той задаче

возможно

Задача данные из одного экшона в другой передать

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

Передать.

Сессии явно подойдут больше

Учитывая, что передать нужно два айдишника

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

так я же вроде так и написал)

так я же вроде так и написал)

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

не, не из другой

ты просто код не смотрел

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

но лучше не смотри)

@lbvf50 STI это же

Просто запихать в сессию - не вариант?

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

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

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

ERROR: S client not available

по сути сессия это то же самое

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

Что бы рейсов не было

Дима, я про это http://api.rubyonrails.org/classes/ActiveSupport/MessageEncryptor.html

crypt = ActiveSupport::MessageEncryptor.new(Rails.configuration.secret_key_base) encrypted_data = crypt.encrypt_and_sign('my confidental data')

тот же сикрет кей можно хранить в Redis

@lbvf50 STI это же

Single Table Inheritance ?

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

да не хило быстрей: user system total real dbrequest: 3.730000 5.430000 9.160000 ( 11.379886) encript: 0.190000 0.070000 0.260000 ( 0.260771) decript: 0.270000 0.070000 0.340000 ( 0.337252)

не когда не думал что 2 раза тыкнуться в базу данных в 30 раз дороже чем зашифрвоать строку

а сколько в таблице строк?

которую тестил

https://gist.github.com/lbvf50mobile/eeda5bcbdcdf32a201013ef943bece0c

да не, ты не понял)

сколько записей в таблице?

да не, ты не понял)

fff

да

5

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

он кешируется

самой базой скорее всего

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

http://rubylearning.com/blog/2013/06/19/how-do-i-benchmark-ruby-code/

интересная статья про benchmarks

http://www.planttext.com/planttext

http://www.planttext.com/planttext

спасибо

Это чат об Исламе? Скажите, goto харам или нет?

харам)

хуям

хуям

привет, сладенький, чатиком ошибся

Ну не я почти