|
Notes |
|
|
|
|
Ну, отдельное окно ИМХО перебор, но закладочку в окно настроек вполне можно добавить. |
|
|
|
(0014658)
|
|
zed
|
|
16-09-2014 05:13
|
|
|
В какое окно настроек? Там где общие настройки программы? Мне кажется это слишком удалённое место и лучше таки кнопочка для быстрого доступа. Да и в глобальных настройках и так уже тесно. |
|
|
|
(0014659)
|
|
zed
|
16-09-2014 11:39
(edited on: 16-09-2014 11:42) |
|
Сделал инициализацию базы в отдельном потоке. Гуй пока никак не блокируется, поэтому вначале он переходит в режим только чтения, а когда метки подгружаются окончательно, включается нормальный режим. Пока не берусь предсказать, что будет с метками, если попробовать добавить метку, во время инициализации. Скорее всего отхватим дубль в id метки, хотя, может и сработает блокировка и ничего страшного не произойдёт. Сейчас зато уже возможно запустить программу, быстро что-то посмотреть и закрыть, не дожидаясь, пока загрузится 100Мб меток :)
Теперь как-то нужно делать блокировку и уведомление гуя. Какие будут предложения по реализации?
|
|
|
|
|
Я бы предпочел, что бы ты не трогал интерфейс IMarkSystemImpl, а реализовал это на уровень выше.
Где-то внутри TMarkSystem.
То есть, TMarkSystem создает какую-то заглушку IMarkSystemImpl, которая, не умеет ничего, только возвращать, что меток нет и ошибку при добавлении меток.
Потом TMarkSystem в отдельном потоке вызывает создание настоящей реализации IMarkSystemImpl, которая указана в настройках.
А после окончания инициализации уведомляет, что база изменилась.
Пока есть только одна реализация IMarkSystemImpl, то разницы никакой, но если реализаций станет много, то фоновую инициализацию придется добавлять в каждую версию, а если сделать как я предлагаю, то реализации конкретной базы меток, не должны будут заботится об отложенной инициализации - система все сделает за них. |
|
|
|
(0014661)
|
|
zed
|
|
16-09-2014 14:30
|
|
|
А по-моему, всё на своём месте. Ты представь, что изменится BasePath и нужно будет в Changeable создать новое хранилище. А нотифаер-то пришлёт сообщение из гуя и создание опять будет происходить в гуе. Так нам выходит нужно всю реализацию Changeable переносить на уровень выше? И следить за тем, когда прилетит AppStarted тоже придётся в TMarkSystem и за всеми возможными параметрами, что могут появиться у разных БД? Ну, тогда от Changeable можно вообще отказаться, раз все его функции будут уровнем выше. |
|
|
|
|
|
Может это хозяйство стоит и в TMarkSystemImplChangeable запихать. Не знаю. Но то что ему в IMarkSystemImpl не место, я почти уверен. IMarkSystemImpl должно быть максимально простым для реализации нового хранилища меток. Нужно думать как это лучше сделать. |
|
|
|
(0014663)
|
|
zed
|
|
16-09-2014 16:42
|
|
|
Не понял... оно ж и так в TMarkSystemImplChangeable. |
|
|
|
|
Я не совсем правильно понял ситуацию (смотрел в браузере на работе), но общая мысль в том что бы не добавлять IMarkSystemImpl тех методов. IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке.
А вот Initialize мне не нравится с точки зрения архитектуры. Объект должен полностью инициализироваться в конструкторе и после него должен быть готов для работы. То есть сам вызов конструктора делаем в отдельном потоке, а до его окончания запихиваем nil или какую-то заглушку, которая не умеет ничего делать. А после завершения конструктора заменять на созданное. |
|
|
|
(0014665)
|
|
zed
|
|
20-09-2014 11:58
|
|
> IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке.
БД на основе SQLite инициализировать не нужно. Зачем же и там испускать поток? Будет только лишний тормоз.
> А вот Initialize мне не нравится с точки зрения архитектуры.
Объясни тогда как реализовать Changeable по твоей схеме? |
|
|
|
|
>> IsInitializationRequired - имхо вообще не нужно - инициализировать все в отдельном потоке.
>БД на основе SQLite инициализировать не нужно. Зачем же и там испускать поток? Будет только лишний тормоз.
Ясно, тогда метод нужен, но не в здесь, а в IMarkSystemImplFactory. Такой интерфейс нужно будет сделать, что бы иметь возможность держать несколько разных реализаций.
>Объясни тогда как реализовать Changeable по твоей схеме?
Ну придется от наследования от текущего родителя TConfigDataElementWithStaticBaseEmptySaveLoad
А делать отдельную реализацию, которая при изменении параметров делать примерно то что делается сейчас, только в потоке вызывать не Initialize, а просто сам конструктор. |
|
|
|
(0014667)
|
|
zed
|
|
20-09-2014 12:23
|
|
|
Фишка с Initialize хороша тем, что в процессе можно информировать гуй об этапах инициализации и прерывать её в определённых местах. Ведь объект-то уже есть и с ним можно работать в штатном режиме. С конструктором такого не получится и я не представляю, как можно прервать/отменить создание объекта. |
|
|
|
|
|
Отменить или уведомить гуй можно так же как сейчас делается с операциями с выделенной областью. Просто передавать в фабрику еще и что-то типа IProgressInfo |
|
|
|
(0014669)
|
|
zed
|
|
20-09-2014 14:46
|
|
|
По-моему ты излишне вс усложняешь. У нас есть Changeable интерфейс, что говорит о том, что наш объект изменяем в широком смысле слова - может изменяться как состояние объекта так и его реализация. А ты сюда вносишь ещё какое-то дополнительное требование, что после создания объекта, его состояние уже изменяться не должно. Может тебе просто название метода не нравится? Это же по сути асинхронный AfterConstruction и ничего в нём криминального нету. |
|
|
|
|
|
В том то и дело, что я упрощаю. В моем варианте реализации не нужно задумываться об вызовах методов в процессе инициализации. Ты сам сказал, что не знаешь что произойдет, если кто-то успеет создать метку до окончания инициализации. |
|
|
|
(0014671)
|
|
zed
|
|
21-09-2014 17:06
|
|
Ничего не произойдёт - там захватывается WriteLock, так что гуй подвиснет, пока не закончится инициализация. Но эта ситуация вообще говоря существует из-за странного поведения, которое сложилось исторически: если БД открыта в режиме только для чтения (хотя и режим чтения там по-моему никак не проверяется, а проверяется только доступность на запись), в неё всё равно разрешается запись, но с условием, что данные не будут сохранены на диск (внутрях реализации sml нету никаких проверок на ReadWriteState при добавлении или чтении меток). И чтобы гарантировать такое поведение в БД, отличной от SML, нужно будет сильно постараться.
Сейчас, пока не закончена инициализация, БД отвечает, что в неё нельзя ни писать ни читать и если ориентироваться на это состояние, то ничего сломать не получится. Хотя, из-за лока на запись оно не поламается и сейчас, но чисто случайно.
P.S. А эти фабрики, что ты сейчас добавил вообще зачем? Чисто из-за IsInitializationRequired? Так его ж можно было в конфиг вынести. Хотя, для sml я планировал в конструкторе TMarkSystemSml принимать решение True или False, в зависимости от размера файла меток. Если там несчастные 5 Мб, то инициализацию можно было бы делать синхронной.
В подсистеме меток получилось какое-то нереально нагромождение интерфейсов... |
|
|
|
|
> P.S. А эти фабрики, что ты сейчас добавил вообще зачем?
Что бы иметь возможность выбирать реализацию базы меток и переключать по желанию. |
|