Комментарии 37
А теперь под ios можно же писать на настоящем руби. Проект можно закрывать, я считаю :)
Здорово, буду пробовать. По идее можно пробрасывать не только данные, но и части кода куда угодно. Этакие фабрики с паттернами.
classes = malloc(sizeof(Class) * numClasses);
Здесь утечка (нет вызова free) — лучше так:
Class classes[sizeof(Class) * numClasses];
User *user = [User newRecord];
user.name = @"Alex";
[user save];
По коду мне кажеться что объект создан в autorelease pool, он не освобождается. Согласно правил именования сообщений:
You own any object you create
You create an object using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy).
Может ваш пример конечно использует ARC, но тогда об этом нужно явно говорить.
А по проекту, мне не ясно в чем именно преимущество этого подхода, почему нужно использовать это вместо CoreData?
У CoreData есть неоспоримое преимущество — с ним знакомы все Cocoa разработчики, поэтому код автоматически будет намного более понятен для других разработчиков (а это очень большое преимущество).
Поэтому чтоб использовать какие-нибудь альтернативы — нужно для этого иметь весомые причины.
ну и CoreData очень хорошо оптимизирован как по производительности, так и по использованию ресурсов: у вас все объектв грузяться в память, а в CoreData есть механизм кэширования и прозрачной подгрузки объектов по требованию (faulting), подержка уникальности объектов в пределаз одного контекста.
Поэтому я бы воспользовался лучше CoreData.
Поэтому я бы воспользовался лучше CoreData.
Да, объект нужно освобождать, просто не привел этого в примере.
Я не утверждаю что мой велосипед лучше чем CoreData, или, не дай бог, он идеален =)
Просто от скуки написал такую вещь, судя по отзывам с гитхаба кому-то это пригодилось, у кого-то была задача использовать существующую БД на sqlite, и CoreData'у туда было тяжело прикрутить.
Я не утверждаю что мой велосипед лучше чем CoreData, или, не дай бог, он идеален =)
Просто от скуки написал такую вещь, судя по отзывам с гитхаба кому-то это пригодилось, у кого-то была задача использовать существующую БД на sqlite, и CoreData'у туда было тяжело прикрутить.
А чем именно не нравится CoreData? Спрашиваю не ради споров, возможно что-то новое в копилку подводных камней добавите.
Ну к примеру я создал две сущности, одна из них невалидна, и я не смогу сохранить другую, т.к. получу ошибку о невалидности какой-то сущности в данном контексте. Прийдется одну удалять, а затем создавать снова. Столкнулся с такой проблемой в одном из проектов, где было несколько связанных сущностей, и все это лихо валилось, при чем с exception'ом и совершенно непонятной ошибкой из серии Error -912.
Создание объектов там не прозрачное, при создании нужно обязательно запихивать в контекст, как-то это неудобно, на мой взгляд.
Но скорее дело в том что я плохо знаю CD.
И как бы то ни было, я получил новые знания во время разработки, так что для меня польза как минимум в этом :)
Создание объектов там не прозрачное, при создании нужно обязательно запихивать в контекст, как-то это неудобно, на мой взгляд.
Но скорее дело в том что я плохо знаю CD.
И как бы то ни было, я получил новые знания во время разработки, так что для меня польза как минимум в этом :)
Добавьте ещё индексы, а то в больших SQLite базах без них очень грустно.
И всё же, если писать поверх чистой sqlite, я бы писал на FmDb — фактически ваша либа — тот же SQL, только называется как методы в Objective-C. Вы хорошо это прописали, написали и расписали, но вопрос в другом — нужна ли такая прослойка?
И всё же, если писать поверх чистой sqlite, я бы писал на FmDb — фактически ваша либа — тот же SQL, только называется как методы в Objective-C. Вы хорошо это прописали, написали и расписали, но вопрос в другом — нужна ли такая прослойка?
механизм миграций несколько смущает… в статье упоминается, что идёт проверка не добавились ли новые сущности или свойства. А как насчет переименовывания, изменения типа, удаления?
Если ты работал с rails, то имеешь представление о механизме миграций там. Наверное и тут было бы удобно иметь что-то подобное. Схему базы можно например хранить в plist. При запуске приложения смотришь есть ли файлик с базой, если нету, то создаёшь базу из plist. Если файлик базы есть, то смотришь какая версия, а затем применяешь миграции от текущей версии до последней если таковые имеются. При примерно таком раскладе мне кажется будет более гибкий механизм. В точ числе можно будет добавлять индексы на поля, чем сейчас сделать как я понял нельзя. Ну и прочие фишки)
Механизм с пропертями, которые автоматически являются и полями в базе мне не очень нравится. А ещё в добавок и надо указывать какая проперти не лежит в базе. Не удобно это и лишний раз люди могут допускать ошибки. Может аналогично как в CoreData стоит сделать? Т.е. да, для того, чтобы они были видны и всё такое придётся в h файле объявлять эти проперти. Но синтесайзить их где-нибудь в твоих классах на основе той же схемы. А в m файле люди будут для них писать
Отдельное спасибо за поддержку CocoaPods ;)
Если ты работал с rails, то имеешь представление о механизме миграций там. Наверное и тут было бы удобно иметь что-то подобное. Схему базы можно например хранить в plist. При запуске приложения смотришь есть ли файлик с базой, если нету, то создаёшь базу из plist. Если файлик базы есть, то смотришь какая версия, а затем применяешь миграции от текущей версии до последней если таковые имеются. При примерно таком раскладе мне кажется будет более гибкий механизм. В точ числе можно будет добавлять индексы на поля, чем сейчас сделать как я понял нельзя. Ну и прочие фишки)
Механизм с пропертями, которые автоматически являются и полями в базе мне не очень нравится. А ещё в добавок и надо указывать какая проперти не лежит в базе. Не удобно это и лишний раз люди могут допускать ошибки. Может аналогично как в CoreData стоит сделать? Т.е. да, для того, чтобы они были видны и всё такое придётся в h файле объявлять эти проперти. Но синтесайзить их где-нибудь в твоих классах на основе той же схемы. А в m файле люди будут для них писать
@dynamic. Плюс это позволит ещё сделать удобную фичу, которой лично мне в core data не очень хватает: работа с обычными типами данных, особенно BOOL часто бывает нужен. Ну оборачивать BOOL в NSNumber ну совсем не прикольно. Иногда специально дополнительный геттер и сеттер, чтобы работать с ним как с BOOL, а не NSNumber. Так вот если синтесайз пропертей будет проиходить где-то в твоих классах либы, то наверное и получится как раз дать пользователю работать с обычными BOOL если надо! Имхо было бы удобненько)Отдельное спасибо за поддержку CocoaPods ;)
Индексы будут =)
Переименование и удаление не реализовано в самой sqlite, а делать миграции через создание временной таблицы может быть очень затратно, если таблица большая.
Если сразу пытаться создать продукт с поддержкой всего на свете, всех ньюансов и требований, то в итоге может выйти какой-то монстр. Все что сейчас реализовано было нужно мне в тот или иной момент, постепенно функционал расширяется, что-то добавляется, что-то улучшается. Всему свое время :)
И главное что я хотел видеть в своей поделке — это простота. Мне надоело делать массу телодвижений с CoreData'ой для создания простой сущности =)
Переименование и удаление не реализовано в самой sqlite, а делать миграции через создание временной таблицы может быть очень затратно, если таблица большая.
Если сразу пытаться создать продукт с поддержкой всего на свете, всех ньюансов и требований, то в итоге может выйти какой-то монстр. Все что сейчас реализовано было нужно мне в тот или иной момент, постепенно функционал расширяется, что-то добавляется, что-то улучшается. Всему свое время :)
И главное что я хотел видеть в своей поделке — это простота. Мне надоело делать массу телодвижений с CoreData'ой для создания простой сущности =)
CoreData может работать с обычными типами
Выглядит удобно! Ставлю +1 за индексы. И теперь главный вопрос: что с основной болью core data — многопоточностью? Если хочу обновлять базу в фоне — как это обрабатывается? Можно ли передавать сущности между потоками?
Честно говоря над всем этим не думал, т.к. пока не было таких, но я открыт для предложений и готов внедрять новый функционал.
Можете предоставить мне подобный use case, а я это реализую. Проблем возникнуть не должно.
Самый простой use case: приложение с новостями, синхронизация происходит в фоне — из интернета скачиваем новости в sqlite и уже из sqlite их отображаем.
Sqlite вообще штука однопоточная, нельзя с одним соединением работать из нескольких потоков, если у нас ActiveRecord, значит в сущности хранится ссылка на соединение с БД, так? Получается если мы создали сущность в одном потоке — передать ее в главный и сделать update уже нельзя. Я долго мучился, чтобы это исключить с CoreData, но до сих пор иногда приложение крешится в непонятных местах.
В Яндексе рассказывали, что они в контроллерах сохраняют только id-шники, сущности не хранят, и у них есть специальный менеджер контекстов, который смотрит в каком мы потоке и выдает соответствующий контекст. Еще встает вопрос с изоляцией соединений (если сделали update в одном, когда это увидим во втором).
А вообще у вас как — каждой сущности в БД соответствует только один объект или может быть два объекта, ссылающихся на одну и ту же строку в БД? И у них может быть два разных состояния.
Еще проблема — если мы сохранили сущность в каком-то контроллере, а в фоне (или даже в том же потоке) у нас вообще все сущности из базы удалили. Что будет в вашем ORM? В CoreData креш, и это часто напрягает.
Sqlite вообще штука однопоточная, нельзя с одним соединением работать из нескольких потоков, если у нас ActiveRecord, значит в сущности хранится ссылка на соединение с БД, так? Получается если мы создали сущность в одном потоке — передать ее в главный и сделать update уже нельзя. Я долго мучился, чтобы это исключить с CoreData, но до сих пор иногда приложение крешится в непонятных местах.
В Яндексе рассказывали, что они в контроллерах сохраняют только id-шники, сущности не хранят, и у них есть специальный менеджер контекстов, который смотрит в каком мы потоке и выдает соответствующий контекст. Еще встает вопрос с изоляцией соединений (если сделали update в одном, когда это увидим во втором).
А вообще у вас как — каждой сущности в БД соответствует только один объект или может быть два объекта, ссылающихся на одну и ту же строку в БД? И у них может быть два разных состояния.
Еще проблема — если мы сохранили сущность в каком-то контроллере, а в фоне (или даже в том же потоке) у нас вообще все сущности из базы удалили. Что будет в вашем ORM? В CoreData креш, и это часто напрягает.
У меня менеджер для работы с базой — синглтон, обращения к которому лочатся через @synchronized, так что по идее пока кто-то пишет в базу, другие не смогут читать, и наоборот. Это если я ничего не ошибаюсь в механизме @synchronized.
Как будет больше свободного времени постараюсь проработать ваш use case, и вообще подумать над доступом из разных потоков.
Спасибо
Как будет больше свободного времени постараюсь проработать ваш use case, и вообще подумать над доступом из разных потоков.
Спасибо
Выглядит здорово. Намучался года два назад с sqlite3 — обновления записей встроенной в приложение базы данных стоили недели бессоных проклятий.
Обещаете, что теперь все будет летать?
Посоветуйте, стоит ли переходить на Вашу библиотеку для следующей задачи
1) есть приложение в которую встроена база данных sqlite3, содержащая 1000 записей о банкоматах (адреса и прочее)
2) в оффлайн режиме приложение показывает в разных ипостасях эти банкоматы
3) в онлайн режиме приложение в редких случаях меняет записи, если банкомат поменял адрес или уничтожен, или добавляет новые записи
Спасибо
Обещаете, что теперь все будет летать?
Посоветуйте, стоит ли переходить на Вашу библиотеку для следующей задачи
1) есть приложение в которую встроена база данных sqlite3, содержащая 1000 записей о банкоматах (адреса и прочее)
2) в оффлайн режиме приложение показывает в разных ипостасях эти банкоматы
3) в онлайн режиме приложение в редких случаях меняет записи, если банкомат поменял адрес или уничтожен, или добавляет новые записи
Спасибо
Думаю можно, но нужно пробовать. Сейчас использую это решение в одном из проектов, заодно правлю баги и улучшаю существующий функционал, делая его удобнее для использования.
Опять таки, я открыт для предложений, и готов вносить новый фичи по требованию.
Опять таки, я открыт для предложений, и готов вносить новый фичи по требованию.
можно делать это на любом движке — на 1000 записях о производительности думать не имеет смысла. На реализации DAO на чистом sqlite / fmdb потратите 1 день, Core Data — 1.5 дня, но последующие правки будут проходить мягче, фрэймворке от автора — тоже, скорее всего, день
отличная библиотека, спасибо. давно такой ждал. обязательно попробую.
Очередная попытка надрать задницу CoreData. Очередная неудачная попытка.
Если честно от макросов выпали глаза, какая то смесь руби и обж-с.
А как насчет NSFetchedResultsController? Это очень удобная штука, даже не знаю как без нее жить, какой-то аналог будет у Вас реализован?
Никогда им не пользовался, потому и не думал о подобном функционале.
Можете расказать чем он хорош и удобен? Как там с кастомизацией ячеек?
Можете расказать чем он хорош и удобен? Как там с кастомизацией ячеек?
Хотя даже если этот котнроллер и очень крутой и очень удобный, то все равно не буду его реализовывать в рамках AR.
Не должны UI и логика находится в одном месте.
Не должны UI и логика находится в одном месте.
Это не UI вовсе, этот класс позволяет следить за результатами запросов при изменении самих записей. Например если создать запрос с каким то предикатом и параметрами сортировки, то при изменении набора записей, соответствующих предикату, или их порядка согласно критериям сортировки, этот класс уведомляет и говорит что куда переместилось, вставилось и удалилось. Конечно он очень удобно сочетается с использованием UITableView, но ничто не мешает использовать его где угодно.
Это как раз та логика, которая позволяет легко и удобно изменять отображение, когда меняется модель, хотя этим не ограничивается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Очередная реализация ActiveRecord на Objective-C