А что именно в реализации не так? :) предлагайте, а мы уже разработчикам передадим, если будет интересно. По поводу комбинирования я и написал — удобно сочетать, т.к. КФС не решает всех проблем. Да и задача у нее немного другая — гибкость и расширяемость системы в целом.
Тут, ИМХО, главная проблема в том, что новые прошивки постепенно теряют поддержку старых моделей. У меня старенький 2G, и многие программы просто не могут быть установлены, т.к. требуется iOS 4.
Совет: используйте один и тот же ранее созданный экземпляр модели. Не надо создавать их несколько раз (особенно если в цикле), есть ведь метод reset() для сброса состояния. Сейчас это может показаться мелочью, но потом может сказаться на скорости работы.
Не надо сравнивать ID с нулем. Вообще-то должно быть что-то вроде: $starting_day = ORM::factory('day', $day);
if ( ! $starting_day->loaded()) { // запись не найдена}
А save() не убирали, там должна идти переадресация на create() или update().
Ну, тут может и не будет проблем — мы передаем конкретное значение ключа. Но, в целом, я бы все равно добавил автоинкремент. Не уверен, что ORM способен полноценно работать без автоинкрементных ID, надо проверять
Там же в ошибке все написано! Пустой внешний ключ `starting_day` видите? ORM воспринимает ID как autoincrement, и после создания новой записи пытается запихать в ID последний сгенерированный ИД. Сделайте для таблицы days нормальный автоинкрементный идентификатор и ссылайтесь на него.
Скажите, а как Вы к такой мысли пришли? У Вас крупный, популярный сайт? Просто мы наоборот хотим уйти от хранения всяких там логинов/паролей, и использовать только авторизацию через OAuth/OpenID… Сейчас ведь наверное трудно найти пользователя без аккаунта в популярном сервисе типа Google/Twitter/FB/etc
По сути, об этом говорят в каждом холиваре при публикации «hello world»-бенчмарков. Другое дело, как сравнивать эти приложения? Помимо сухих цифр скорости загрузки есть еще трудозатраты на написание кода, а также его читабельность и т.д. Факторов много, и они в целом субъективны.
Поэтому я и говорю об абстрактной табличке, показывающей только общую информацию о типовых возможностях фреймворка, типовых же проблемах и т.д.
Топик-ссылку? Вероятно так и сделаю. По поводу КФС могу предложить сотрудничество :) Вы знаете Yii, я работаю с Kohana. Давайте напишем статью со сравнением по каким-то основным тезисам.
Спасибо, это мой блог и моя статья :) Предполагаемая тема собственно является логическим продолжением (после аналогичных описаний OAuth v2 и OpenID применительно к Kohana). Я планирую описать созданный специально для нашего проекта
модуль аутентификации, а также его непосредственное использование.
Получается свой Auth, только работающий не с локально зарегистрированными пользователями (пароли, соли и т.д.), а с пришедшими из внешних социальных сервисов. Соответственно есть свои проблемы, интересные моменты и т.д. Правда, сейчас еще далеко не все реализовано в проекте, поэтому окончательная версия статьи (со ссылкой, которую можно будет потестить) появится в лучшем случае в начале следующего месяца.
Насчет архитектуры… Мне казалось, что о ней достаточно сказано. А YII я не пользовал, не могу сравнивать. И, кстати, не сказал бы, что Kohana сложна и неочевидна. Все достаточно просто, если понять принципы Каскадной Файловой Системы. На форуме кстати обсуждались плюсы и минусы, причем я вроде видел и русский топик, и англоязычный.
Прошу прощения, если обидел :) Повторюсь — вопрос в том, понравится ли ей. Просить помогать, обосновывая это только финансовой стороной, ИМХО, неправильно.
