да, транзакции тоже вроде как лечат. но тут проблема не большая. внутри фара использовать транзакции не проблема, но вот как это красиво вынести в api для настроек плагинов, оставив api максимально абстрактным. или же опять, с PRAGMA synchronous = 0; и без транзакций всё хорошо.
насчёт выноса настроек. очень хотелось бы иметь в новой версии возможность дефолтных настроек для всех юзеров. то есть где б они ни хранились, в %APPDATA% или ещё где, при первом запуске каждого юзера они должны браться не с потолка, а с %FARHOME%\Settings\Default\*.db или как-то так. чтобы можно было настроить однозначно всем, а дальше - пусть уж каждый юзер себе сам.
что, кстати, решит проблему портабельности при использовании ключика вроде /SaveSettingsToDefaultLocation
GMax wrote:насчёт выноса настроек. очень хотелось бы иметь в новой версии возможность дефолтных настроек для всех юзеров. то есть где б они ни хранились, в %APPDATA% или ещё где, при первом запуске каждого юзера они должны браться не с потолка, а с %FARHOME%\Settings\Default\*.db или как-то так. чтобы можно было настроить однозначно всем, а дальше - пусть уж каждый юзер себе сам.
что, кстати, решит проблему портабельности при использовании ключика вроде /SaveSettingsToDefaultLocation
Что то мне кажется это уже перебор. Может админы меня поправят но в винде для этого должны быть настройки и без фара.
GMax wrote:насчёт выноса настроек. очень хотелось бы иметь в новой версии возможность дефолтных настроек для всех юзеров. то есть где б они ни хранились, в %APPDATA% или ещё где, при первом запуске каждого юзера они должны браться не с потолка, а с %FARHOME%\Settings\Default\*.db или как-то так. чтобы можно было настроить однозначно всем, а дальше - пусть уж каждый юзер себе сам.
что, кстати, решит проблему портабельности при использовании ключика вроде /SaveSettingsToDefaultLocation
Что то мне кажется это уже перебор. Может админы меня поправят но в винде для этого должны быть настройки и без фара.
в винде можно в дефолтном профиле реестр заранее подготовить и при создании нового профиля эти настройки будут использоваться. а раздать настройки всем возможно при помощи logon scripts. в новом раскладе можно и новые DB разложить, но в плане апгрейда это не катит.
а при моём предложении по-моему решается весь комплекс проблем с портабельностью и дефолтными настройками. с точки зрения реализации тоже проблем быть не должно.
при запуске if exists(%appdata%/settings) { use %appdata%/settings } else { use %default%/settings || import_old_from_registry }
при созранении настроек if ("/SaveSettingsToDefaultLocation") { saveto %default%/settings } else { saveto %appdata%/settings }
таким образом портабельность(и изменение настроек "для всех") обеспечивается при запуске с ключом, а дефолтные настройки "для всех" - в случае первого запуска под юзером без ключа. для полностью портабельной версии можно будет заюзать предлагаемый здесь ini, в котором прописать что-нибудь вроде SaveSettingsToDefaultLocation=1
если плагин начал транзакцию, то он её должен закончить перед тем как возвращает управление в фар, а то это будет влиять на другие плагины.
можно конечно каждый плагин держать в отдельной базе, но это уже как то криво.
foobar2000 держит конфигурацию каждого плагина в отдельном файле - вроде как ничего плохого в этом нет, обыкновенный юзер всё равно не полезет в %appdata%
t-rex wrote:если плагин начал транзакцию, то он её должен закончить перед тем как возвращает управление в фар, а то это будет влиять на другие плагины.
я не большой спец именно по sqlite, но в обычных субд проблемы возникают только если параллельные транзакции обновляют одну и ту же запись. у нас каждый читает своё.
ну тут тоже есть проблемы.
скажем есть разные базы на разные плагины.
1.create открывает базу и начинает транзакцию а free коммитить транзакцию и закрывает базу - т.е. реально запись происходит при free и пока не сделали free даже прочитать то что записали незя.
2. скажем есть плагин который часто юзает базу на чтение и много туда пишет - т.е. чтоб работать быстро ему нужно держать базу всё время открытой а вот чтоб данные реально записались нужно как то закоммитить транзакцию.
И что делать?
Кроме как добавить в API комманды BEGIN END (или OPENROOT CLOSEROOT) я ничего придумать не могу.
t-rex wrote:если плагин начал транзакцию, то он её должен закончить перед тем как возвращает управление в фар, а то это будет влиять на другие плагины.
я не большой спец именно по sqlite, но в обычных субд проблемы возникают только если параллельные транзакции обновляют одну и ту же запись. у нас каждый читает своё.
я тоже не знаю как это в sqlite но я не о конфликтах, а о том что пока транзакция не закрыта данные то реально никуда не записываются.
но эту проблему легко решает наличие разных баз для разных плагинов если уже до того дело дойдёт.
t-rex wrote:1.create открывает базу и начинает транзакцию а free коммитить транзакцию и закрывает базу - т.е. реально запись происходит при free и пока не сделали free даже прочитать то что записали незя.
плагин прочитать может. остальным — зачем?
2. скажем есть плагин который часто юзает базу на чтение и много туда пишет - т.е. чтоб работать быстро ему нужно держать базу всё время открытой а вот чтоб данные реально записались нужно как то закоммитить транзакцию.
ну так он сделает free и транзакция закомитится. в чём проблема?