Githawk: Сброс закладок (снова)

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

Это дает те же проблемы с обработкой БД / миграций. 🤦‍♂️

_{Отправлено с помощью GitHawk}

Подождите, может ли codable не обрабатывать изменения структуры? Итак, если мы добавим новое свойство, оно не десериализуется?

Если это так, мы можем вернуться к NSCoding .

_{Отправлено с помощью GitHawk}

Точно, если вы обновитесь, вы просто получите кучу ошибок в консоли, говоря, что она не знает, что это за объект, и выйдет из строя (таким образом, сбросив)

Если NSCoding справится с этим лучше, то да, возможно, это стоит того 😞

Да, с NSCoding у вас есть полный контроль, и вы просто делаете новые значения необязательными или предоставляете значение по умолчанию в initWithCoding.

Мы должны изменить это до 1.12.

_{Отправлено с помощью GitHawk}

Таким образом, это можно сделать с помощью Codable, как я предлагал выше, но проблема в том, что нет значения по умолчанию, которое вы можете использовать, и не иметь ошибок. Я имею в виду, да, конечно, вы можете возразить "крайний случай", но на самом деле нам нужна система миграции, которая может запрашивать и обновлять закладки новой информацией 🤔

@Sherlouk приходит на ум что-то вроде

_{Отправлено с помощью GitHawk}

В этом смысле у нас уже есть ошибки. Что происходит, когда репо меняет свою ветку по умолчанию?

Это больше похоже на то, что нам нужна система для обновления предметов, когда вы их посещаете.

_{Отправлено с помощью GitHawk}

В смысле закладок очень верно. Issues / Search / и т. Д. - это все актуальные ссылки на репозиторий, поэтому их информация будет верной.

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

Черт возьми, если бы мы это сделали, мы могли бы начать показывать количество звезд на репозиториях и ярлыках по проблемам. Можно было бы сделать это простым и обновлять только при входе в вещь (по сравнению с какой-то службой синхронизации).

Боковое примечание, вы не можете запрашивать несколько репозиториев в одном запросе gql, верно? Так как один запрос на 4 репо по имени?

_{Отправлено с помощью GitHawk}

Насколько я знаю, думаю, это 1: 1. Звездочки, ярлыки, информация о фиксации 🤔🤔

_{Отправлено с помощью GitHawk}

Мысли о том, что тут делать? Хотел бы представить 1.12 на этой неделе. Я не особо переживаю по поводу этого банкомата, просто нужно подумать о плане миграции.

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

Может быть, нам просто нужно немного реорганизовать закладки, чтобы мы могли выполнять поиск O (1) на основе идентификатора и обновлять объекты?

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

_{Отправлено с помощью GitHawk}

Мы бы никогда не выпустили версию, стирающую закладки, я с этим не согласен. Любые изменения, которые могут уничтожить закладки, должны включать миграции, даже если они выполняются вручную.

_{Отправлено с помощью GitHawk}

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