Александр, их нет смысла проверять на работоспособность. у меня был такой скрипт поиска когдато. Первый запрос - отвал. Второй прошел. Третий пинг 10 сек, но прошел. Я мерил количество отвалов в подряд и удалял после 20. а по времени пинга сортировал очередность использования. пока очередь доходила, они или полностью отваливались, либо остывали. все равно это было неэффективно и долго. куча запросов терялось, приходилось делать очередь... но в целом как план Б оставил эту идею.
Сергей, насколько я помню, она создавалась именно для метрики. что бы хранить много и быстро оперировать. Умеет собираться в кластер и масштабироваться. Ребята с яндекса на devconf как то давно рассказывали что она собирает запросы sql и распределяет между серверами как то хитро. отсюда скорость выборки. И заверяли что положить кх запросами нереально при правильной настройке.
Штука то мощная. Только это не БД, это хранилище данных. там вроде как нет даже метода удаления данных, что говорит о предназначении. Да и использовать только в большом продакшне оправдано.
Сергей, вообще то может и используется. может и предназначен разные понятия. Микроскоп тоже не предназначен для забивания гвоздей, однако он может это делать (наверное). Я бы не стал доверять на 100% сервису, который хранит данные в памяти. В зависимости от вашей нагрузки, можно в этой схеме отказаться от редиса, или даже от кх заменив их мускулем, пока нет потребности в большем. Есть у людей привычка собирать истребитель что бы съездить за хлебом =)
Та не усложняйте вы, врядли там такая нагрузка что бы делать связь в отдельную таблицу. Вы еще про индекс ему рассказывать начните... Парню въехать банально нужно. Просто в таблицу со статьей делаем столбец user_id (или owner_id как предлагалось) и при выборке указываем нужные where user_id=1 где 1- ваш идентификатор. Сам ид берется из таблицы users и у каждого он свой. Храните его в сессии после авторизации.
Игорь Воротнёв, не согласен. На тостере обьяснят как правильно и почему именно так. А сам наговнокодит чего нибудь и будет рад что работает. И знать не будет что вместо сотни строк все можно одной сделать. Опытный товарищ всегда полезен
Да. мне уже объяснили причину.
То о чем вы говорите у alamofireImage это выглядит так:
let URL = NSURL(string: filename)!
let placeholderImage = UIImage(named: "icon")!
cell.image.af_setImageWithURL(URL, placeholderImage: placeholderImage)
Антон Марунько: Обновил немного вопрос. Происходит все в методе collectionView. который создает ячейку. только он почему то создает ее на основе тех, что были созданы ранее. таким образом я вижу например картинки № 1, 2, 3 вместо 10, 11, 12 . потом они быстренько заменяются нужными. Причем такой фокус повторяется если проскролить вверх, потом обратно вниз. А если поставить условие на проверку существования изображения в imageView тогда остаются дублированные. Т.е. там уже есть изображение в тот момент, когда cell создается впервые. во как!
ManWithBear: Видимо да. объясню ситуацию, может что получше посоветуете. У меня есть менеджер для запросов к серверу. Само собой он не является вьюхой. это отдельный класс для работы с api. если ему возвращается ошибка на обновление токена. Тогда нужно кинуть человека на авторизацию. Это не зависит от запроса. Это нужно проверять при каждом запросе. По тому крайне не хочется в каждой вьюхе прописывать отдельный метод для этого. Или я не прав?
let storyboard = UIStoryboard(name: "Main", bundle: nil)
let vc = storyboard.instantiateViewControllerWithIdentifier("LogIn") as! LogInViewController
self.presentViewController(vc, animated: true, completion: nil)
Был послан лесом. говорит следующее:
Warning: Attempt to present on whose view is not in the window hierarchy!
Что в принципе понятно. я то вызываю из класса, который не принадлежит сториборду.
