Far-NetBox
Far-NetBox copied to clipboard
michaellukashov
Can't delete or edit stored sessions
I can't delete or edit my saved sessions. Steps to reproduce were as follows:
I was using a stable version of Far 3.0 x64 that was before the stable build 4040 (current now) and everything was working fine. I then accidentally upgraded my installation to a nightly build (one of 4127 to 4130). After the upgrade all my stored sessions became empty. By that point I noticed that I have installed a nightly build, so I downgraded to a stable build 4040, but the sessions db was apparently already corrupted - I was unable to delete or edit them in the stable build as well.
- Backup all session in to netbox.farconfig using comad
far /export nebox.farconfig
- Open in editor this XML file and delete any record excluded NetBox records started on section
<pluginsconfig>
at block
<plugin guid="42E4AEB1-A230-44F4-B33C-F195BB654931">
<hierarchicalconfig>
<key name="42E4AEB1-A230-44F4-B33C-F195BB654931" description="NetBox">
.........................
</key>
</hierarchicalconfig>
</plugin>
- Edit plug-in old version to value
<value name="Version" type="text" value="2.1.39"/>
and save this file. 4) Import backup use command
Far /import netbox.farconfig
and add any missing value.
Ready. See https://github.com/michaellukashov/Far-NetBox/issues/117 (Russian) for details...
VictorVG, но это как временная мера, лучше конечно же исправить баг.
Это скорее не баг, а последствия изменений в SQLite - внутрений формат БД поменялся, но решать не мне, а ребятам.
@sergeevabc
Вы бы хоть какие-то подробности привели. У меня в примеру с v2.4.5.531 данная проблема не воспроизводится. Может у вас БД конфига защищена от записи? Например антивирусом. Тут телепатов нет, а потому если вам нужна помощь то чётко объясните начальные условия и постановку вопроса. Иначе увы, но кроме моральной поддержки ничем...
@VictorVG, работая с последним билдом Фара x64 в портативном варианте (профиль находится в папке запуска), лишён возможности удалить пару SSH подключений (названных по-английски) из Netbox (хотя другие подключения удаляются). В итоге, удалил пару *.db из профиля Фара, относящихся к Netbox, что обнулило настройки, но заодно и решило проблему.
Хорошо, уже теплее.) , но:
-
версии фара и нетбокса никак между собой не связаны т.к. нетюокс может работать с любой версией старше той под которую он собран;
-
по прежнему я должен гадать в каких условиях и как воспроизвести то, что вы наблюдаете? и потому кроме слов "у меня такого не происходит сейчас вам ничем не могу помочь хотя думаю причина явления где-то рядом, просто вы её не замечаете из-за привычности.
У меня аналогичная проблема. Пользуюсь FAR'ом уже очень много лет, поэтому некоторые настройки были сохранены очень давно и в старых версиях. Сейчас уже не вспомню когда и на каких версиях. Так вот, в текущей версии FAR (3.0 build 5354 x64) некоторые старые FTP сессии не удаляются. Точнее очищается их содержимое (host, user, etc.), но сама сессия остается и она как бельмо на глазу. Точнее их у меня таких 3 штуки. Аналогичным образом ведет себя и переименование (Shift-F6): создаётся копия, а оригинал очищается, но не удаляется.
Я пробовал решить проблему через экспорт-импорт настроек FAR, как показано в первом комментарии. Кстати, там опечатка ("nebox"), но безуспешно. Я не понял что там надо менять в версии. Да и версия сейчас уже другая, то сообщение от 2014 года. Я пробовал просто удалить проблемные сессии из XML и импортировать обратно, но похоже, что import не делает очистку, соответственно, то, что удалено, не исчезает.
Подскажите, как можно очистить настройки FAR перед импортом?
И ещё, в комментариях @sergeevabc упоминал о том, что удалил из профиля пару *.db файлов с SQLite, относящихся к Netbox, но у себя в профиле я нашел только:
(в AppData/Local/Far Manager/Profile) history.db localconfig.db plugincache64.db shortcuts.db
(в AppData/Roaming/Far Manager/Profile) associations.db colors.db filters.db generalconfig.db highlight.db panelmodes.db pluginhotkeys.db
Ничего похожего на netbox нет.
@gugglegum
Импорт и не должен делать очистку т.к. он просто добавляет то чего нет в SQLite БД %FARPROFILE%\PluginsData\42E4AEB1-A230-44F4-B33C-F195BB654931.db . Потому вариантов два:
Способ первый - экспорт настроек их чистка, затем импорт:
- Far /export default.farconfig
- в корне находим раздел_pluginsconfig_ и ищем там ключ
отвечающий за настройки NB, там находим ключ Sessions и открыв его находим и удаляем лишние ключи сессий, аналогично проверяем ключ CDCache и если они там есть стираем строки с именами удалённых сессий. - стираем БД 42E4AEB1-A230-44F4-B33C-F195BB654931.db.
- far /import default.farconfig
имя файла конфига любое, главное правильно указать его в командах импорта/экспорта.
недостаток - возня;
Способ второй либо редактором SQLite либо через её оболочку вручную удалить ошибочные записи в БД. Тут недостаток один - нужно знать как и что удалять, недостаток тот же возня.
А так - Shift-F8 из панели сессий должен удалить не нужные. Не сможет только если БД повреждена. Тогда придётся её восстанавлить чем-то типа SQLite Database Browser или SQLite Expert либо командами SQLite Shell...
Это скорее не баг, а последствия изменений в SQLite - внутрений формат БД поменялся
С самого начала был поражён самой идеей хранить настройки в базе данных. Это как от элементарного решения в линуксе перейти к реестру виндоуз со всеми вытекающими. И, в итоге всё равно приходится выгружать в xml, править и загружать обратно. Ну, или пользоваться сторонними инструментами для обслуживания и поддержки. Простите... просто много лет назад удивило так это, и вот, прошло время...
В общем, вся эта возня вокруг БД была так предсказуема и до боли очевидна. С тех пор FAR не только стал загружаться как бы с паузой, но и подарил другие "бонусы" в использовании :)
Для чего... всё это, чтобы подгрузить одним обращением с диска 60 килобайт выгруженного мной только что полнотекстового xml со всеми-всеми-всеми настройками? Использовать SQLite ещё и при живом-то реестре... Есть и другие варианты, но БД... хуже вряд ли возможно придумать в принципе для этой задачи - выбранный проигрывает по всем статьям - производительность, ресурсоёмкость, обслуживание, зависимость от других производителей ПО, надёжность, унификация... по всем, без исключения.
@mr-older А что именно вы предлагаете вместо БД? Хранение в XML или в ini-файлах? Этот способ имеет право на жизнь, но парсинг XML довольно ресурсоёмкая операция, а ini-файлы не очень удобны для списков. Есть ещё JSON, его парсить легче, но он начал набирать популярность когда? Лет 7 назад? Да и то больше в веб-среде. Возможно, когда принималось решение о хранении настроек в SQLite тогда JSON был не распространён. Кроме того, хоть на малых объемах настроек, SQLite проигрывает в скорости перед полным парсингом и хранением всех настроек в ОЗУ, но если настроек много, то использование SQLite избавляет от необходимости читать и хранить в ОЗУ то, что мы может быть не будем использовать.
SQLite -- это легковесный быстрый способ хранить списки структурированной информации. Вместо него, разработчикам пришлось бы изобретать частично свой велосипед. А тут сразу готовый поиск (причём возможно с индексами), сортировка, фильтрация. И всё это масштабируемо, без лишнего использования памяти и линейного роста времени операции с ростом кол-ва данных.
Для примера Chrome и Firefox тоже хранят свои настройки в SQLite, а не в реестре. На самом деле и в реестре тоже хранят, и Far тоже хранит в реестре, но то разные настройки. Например, Far хранит в реестре текущий каталог, историю команд, историю поиска и т.п. То есть реестр Windows в Far играет роль кэша. Там хранятся настройки, которые можно относительно безболезненно потерять, и которые в значительной степени привязаны именно к данному компьютеру, и которые нет смысла переносить на другой компьютер.
Основная проблема не в SQLite, а в том, что структура таблиц в БД поменялась и нет нормальных миграций между версиями структуры БД, а код работает только с новой структурой и некорректно работает со старой. В случае, если бы мы использовали хранение настроек в JSON, изменение структуры там имело бы примерно тот же эффект.
Кстати, подвисание при запуске у меня тоже было раньше. Около секунды. Я не думаю, что как-то напрямую связано именно с использованием SQLite, скорее с каким-то мусором, который накопился где-то в настройках. Я не помню точно как я решил эту проблему. Вроде бы я как-то экспортировал настройки, снёс текущие настройки, что-то подправил вручную и импортировал заново. И задержка при запуске пропала. Сейчас у меня FAR запускается где-то за 0.5 секунды.
@gugglegum
А тут сразу готовый поиск (причём возможно с индексами), сортировка, фильтрация. И всё это масштабируемо, без лишнего использования памяти и линейного роста времени операции с ростом кол-ва данных.
Ну это классический случай преждевременной оптимизации. Какой рост количества данных ожидается здесь? Это же конфиг.
Хранение в XML или в ini-файлах? Этот способ имеет право на жизнь, но парсинг XML довольно ресурсоёмкая операция
Более ресурсоёмкая, чем подгружать SQLite? Даже самые хилые XML-парсеры выжимают 50 мб/с на среднем железе - на чтение 60кб конфига потребуется 1мс.
Друзья!
Механизм чтения-записи конфигов в БД встроен в Far, а плагины только зовут сервисные функции из Far.exe. Так что ваш приятный академический спор в данном случае бессмысленнен ибо никто не станет возится с собственной реализацией если есть готовое решение отвечающее задаче.
@bazzilic
Ну это классический случай преждевременной оптимизации. Какой рост количества данных ожидается здесь? Это же конфиг.
Дело в том, что FAR поддерживает плагины, которые имеют свои собственные настройки. Плагинов может быть сколько угодно, и настроек у плагинов может быть много. Это ведь сильно зависит от специфики плагина. Это у вас плагин использует 60 кб, у меня например 117 кб. При том, что я из нештатных плагинов использую разве что только Colorer.
Более ресурсоёмкая, чем подгружать SQLite? Даже самые хилые XML-парсеры выжимают 50 мб/с на среднем железе - на чтение 60кб конфига потребуется 1мс.
SQLite очень даже быстрая СУБД. А XML-данные нужно не только прочитать, но и найти нужное, отсортировать, сгруппировать, объединить с чем-то. А уж если захотелось что-то изменить в конфиге, то это надо весь XML-файл целиком генерировать и писать на диск. И при этом контролировать, чтобы другая копия FAR не начала делать чтение из XML в то время, как производится запись этого XML, т.е. реализовать файловые блокировки. И если конфиг меняется достаточно часто, то хранение в XML уже не выглядит такой уж хорошей идеей. А если делать так, чтоб это хорошо работало не только на чтение, но и на изменение, то вы очень быстро придёте к какой-то упрощенной реализации SQLite.
@VictorVG ну да, но как не потрындеть в комментах? )
@gugglegum ну камон, о чем вообще речь? Вы часто одновременно меняете настройки в трёх открытых фарах, чтобы ради вот такого случая что-то предпринимать? Тогда непонятно, зачем останавливаться на SQLite - он тоже далеко не всё умеет. Так можно дойти до хранения настроек в географически распределённом кластере БД с кэшами, кастомной репликацией, мониторингом и т.д.
@bazzilic
ну камон, о чем вообще речь? Вы часто одновременно меняете настройки в трёх открытых фарах, чтобы ради вот такого случая что-то предпринимать?
А то есть вы предлагаете ничего не делать с этим, посчитав эту ситуацию слишком маловероятной? Нужно помнить о том, что настройки могут меняться не только из окна настроек FAR, а самими плагинами в фоне, когда пользователь не совершает никаких активных действий. И делать он это может хоть каждую секунду. Можно ли будет назвать архитектуру FAR удачной, если есть риск потери всего конфига из-за слишком частого изменения настроек?
SQLite -- это легковесный быстрый способ
Вы и близко не понимаете, что тут сами же и написали. Как разработчик в т. ч. специфических СУБД (!), могу подсказать, что:
-
СУБД - это самый медленный и ресурсоёмкий способ, который только можно придумать для сохранения и получения данных в чистом виде. Из-за чего же тогда вообще используют СУБД? Если крайне примитивно, то СУБД = поиск (!). Безусловно, полезная вещь на больших объёмах. Для загрузки конфига нужен поиск? Если да, то не проще ли загрузить копейки данных в индексированный массив в памяти и там поискать... Не уверены? Тогда читаем дальше.
-
Даже самая быстрая СУБД требует загрузки себя и своих драйверов только для того, чтобы начать обращаться к файлам БД. То есть требует медленных дисковых обращений, CPU для собственной инициализации + отъедает RAM. Немного в случае с SQLite, но уже сравнимо с обработкой конфига - пока грузили СУБД, конфиг уже обработан (см. про вишенку внизу).
-
Файлы данных в БД не представляют собой простую структуру. И сами они, как правило, представляют наборы данных, распределённых по таблицам + каждая таблица сопровождается индексными файлами.
-
Иногда всё это хозяйство лежит одной кучкой раздельных файлов. Иногда, как в Access, прячется в одном большом. Но суть от этого не меняется: огромные затраты на инициализацию всего этого хлама по сравнению с чтением обычного файла XML или хоть чего + парсинг.
-
Драйвера СУБД работают также, в общем-то: делают то же чтение, только могут игнорировать для обработки часть данных. Также присутствует как парсинг запросов, так и выходных данных. Но могут эффективно искать за счёт индексирования (которое, само по себе, весьма затратная операция). Но на 60-200 обрабатываемых килобайт никто не получит никакого выигрыша от слова "совсем" - загрузите это всё в память и ищите там, получая плюс в эффективность на малых объёмах данных (память гораздо быстрее, чем диск, отсюда скорость за счёт использования памяти, сравнимой по объёму с занимаемой памятью самой СУБД). Кроме этого, получите независимость от производителя СУБД и, как результат, работа будет сделана раз и навсегда. Это когда продукт делается с прицелом на будущее, а не решается текущая задача абы как. Отсюда выше качество ПО, меньше затрат на дальнейшее обслуживание.
Теперь про транзакции:
- У любой СУБД есть болезнь - проблема, когда несколько экземпляров приложения вносят изменения в одну таблицу одновременно, при этом могут быть обращения к другим таблицам, а там другие вносятся изменения. В этом случае создаётся очередь и запросы обрабатываются в порядке очереди (транзакциями). В случае с текстовым конфигом такой проблемы нет - кто успел записать вперёд, тот и молодец. И всё, это вся разница касательно нескольких экземпляров приложения. Хорошо, что напомнили, только это не плюс к СУБД: вы реально не знаете, о чём написали ещё и позднее.
Теперь пример исторический, про сложность работы с БД и текстовыми файлами для программистов, который вы упустили из моего прошлого поста:
- Весь линукс работает на обычных текстовых конфигах с 60-х годов прошлого века. И никто ещё не жаловался ни на производительность, ни на неудобства для разработчиков: никто из разработчиков или пользователей ~90% устройств в мире, имеющих ОС. Да, подавляющее количество устройств в нашем мире работает именно на линуксе и на текстовых конфигах.
Теперь вишенка на торте:
- У каждой БД, как правило, есть свой конфиг (.sqliterc, например), который вы, видимо, тоже планируете хранить в БД. Возможно, в другой, ещё более быстрой. А конфиг той ещё в одной. И так до бесконечности. Только потому, что не знаете эффективных способов не хранить что-то в БД. Смею допустить, что эффективность чтения двух мелких конфигов не может быть выше, чем одного. И это ещё не считая всего остального, разумеется. Интересный момент, не правда ли?
Теперь итог:
- Не дайте невежеству победить себя: абсолютно все ваши опасения выдуманы, а преимущества БД надуманы в данном конкретном случае. Просто сделайте тесты с любой БД и парсингом любого текстового конфига, чтобы убедить себя в том, что разработчикам известно со времён появления первых СУБД в принципе. А меня увольте от долгих объяснений принципов работы СУБД - всё, что сказано мной выше, можно просто загуглить.
Теперь пример исторический, про сложность работы с БД и текстовыми файлами, который вы пропустили почему-то из моего прошлого поста:
- Весь линукс работает на обычных текстовых конфигах с 60-х годов прошлого века. И никто ещё не жаловался ни на производительность, ни на неудобства для разработчиков: никто из пользователей 90% устройств в мире и их производных.
Вы немного ошиблись - в 60=х годах ХХ века г-на Линуса Торвальдса с которым я встретился по работе в 1993-м когда он собирался демонстрировать Совмину РФ ОС Linux v1.0.1 (правда благополучно спалив видеокарту QVISION-1280 и шину EISA в DEC Server 2000 из-за чего плату-маму пришлось из Ирландии самолётом везти :) ) ещё и в проекте не было, а о появлении AT&T UNIX никто и не задумывался. Были разные ОС, и в конце 60-х наиболее популярной была IBM OS/360 PCP и только только появилась IBM OS/360 MFT, а OS/360 MVT только проходила тестирование, равно как идеи загнать процессорную стойку в кристалл считались недостижимой мечтой. И машинный зал с установленными там стойками ОЗУ, процессоров, каналов I/O, НМЛ, НМД, групповыми и дисплейными стойками был нормой ещё в начале - середине 80-х. Я сам работал на этих комплексах. Начинал с Минск-22, а после перешёл на IBM S/360 mod 169 (?) и ЕС ЭВМ Ряд 1 - ЕС-1010, 1022 и 1033. И только в 86-м по решению Совмина мы получили несколько ЕС-1045 (Ряд 2) под OS/360 MVT и единственную в отрасли ЕС-1067 (Ряд 3) под OS/370 VM. И конфиг OS/60 - OS/370 представляет собой таблицу содержащую адреса всех устройств I/O и стоек машины хранившуюся на магнитной кассете с программой IPL/NIP.
Но в одном вы правы - все ОС семейства UNIX и их потомки исторически используют простой текстовый конфиг хранящийся в /etc . Не исключение и особо надёжные ОС для бизнес-задач DEC OpenVMS и DEC OSF/1. А впервые с монолитным конфигом я лично встретился в IBM OS/2 - её файл config.sys представлял собой примерно 400 кб контейнер управлявшийся встроенной в ОС микроСУБД и что-то поправить в нем было можно ... в хекс-редакторе ибо это файл был бинарным. А ОС Windows начиная с Windows 3.0 - самой первой её версии (Windows 1.0 и 2.0 были просто GUI оболочками над DOS) использовали текстовый конфиг в виде INI файла с ограничением на его размер до 16к, после увеличенный до 64к что снизило время реакции ОС на внешние события.
А механизм БД (Реестр) стал применяться начиная с Windows NT 3.1 из-за того, что был достигнут предел сложности управления набором текстовых конфигов для данной архитектуры ОС и время нужное на поиск той или иной настройки в них значительно превышало время её поиска в иерархической БД.
Потому в системах АСУ ТП ещё в начале 80-х применялось правило - локальные настройки храним в текстовых конфигах, глобальные в иерархической БД. Это упрощает управление и снижает время реакции системы на внешние события, что критично для систем реального времени.
Но в одном вы правы
Во всём остальном, надо полагать. Речь шла про выбор БД исключительно с целью хранения небольшого конфигурационного файла. Тем не менее, спасибо за расширенный и весьма увлекательный исторический экскурс :) Помню и перфокарты и программирование на фортране с хранением на лентах. Те времена, когда считали каждый байт памяти и каждый тик процессора. Не чета нынешним.
@mr-older
Вы и близко не понимаете, что тут сами же и написали. Как разработчик в т. ч. специфических СУБД (!), могу подсказать, что
Для лучшего понимания, могли бы вы уточнить разработчиком каких именно специфических СУБД вы являетесь, и каков ваш вклад в разработку этих самых СУБД? Просто вы говорите это с таким пафосом, при этом утверждаете, что ваш собеседник "близко не понимает, что он написал", а у самого в профиле всего 2 репозитария, из которых один "hello-world" на HTML, а другой — форк на PHP, в который вы ничего не коммитили. Ну и небольшая активность в виде создания багрепортов в чужих проектах. Не то, чтобы я сомневаюсь в вашем профессионализме, я вовсе не из тех людей, что говорят "сначала добейся, а потом критикуй", но просто хотелось бы лучше представлять с кем я имею дело и стоит ли на вас тратить своё время. Тем более, что вы сами упомянули о своих достижениях.
СУБД - это самый медленный и ресурсоёмкий способ, который только можно придумать для сохранения и получения данных в чистом виде. Из-за чего же тогда вообще используют СУБД? Если крайне примитивно, то СУБД = поиск (!). Безусловно, полезная вещь на больших объёмах. Для загрузки конфига нужен поиск? Если да, то не проще ли загрузить копейки данных в индексированный массив в памяти и там поискать... Не уверены? Тогда читаем дальше.
Я уже писал, что в конфиг могут сохранять свои настройки плагины. Какие именно и сколько этих настроек будет в общем объёме — зависит исключительно от плагина и его специфики. FAR, как материнская платформа, предоставляет плагину API для хранения настроек, чтобы разработчику плагина не требовалось маяться с сохранением текстовых конфигов.
На счёт того, что СУБД — это самый медленный способ. С чего вы это взяли? На чём зиждется утверждение, что это самый медленный способ, т.е. не существует (не может существовать) более медленного способа? Собственно, то, что вы предлагаете — хранить конфиг в текстовых файлах, если это оформлено в виде какого-то API или библиотеки, то по сути это тоже СУБД, согласно определению этого термина. И раз так, то вы сами себе противоречите, когда противопоставляете текстовые конфиги и СУБД.
Даже самая быстрая СУБД требует загрузки себя и своих драйверов только для того, чтобы начать обращаться к файлам БД. То есть требует медленных дисковых обращений, CPU для собственной инициализации + отъедает RAM. Немного в случае с SQLite, но уже сравнимо с обработкой конфига - пока грузили СУБД, конфиг уже обработан (см. про вишенку внизу).
Это ерунда. Вы наверно больше PHP программист. Там действительно, если вы используете PDO, то нужно подключать дополнительный драйвер конкретной СУБД. Но FAR написан на C++, там нет PDO. Если вам нужен SQLite, вы просто подключаете его. Вы даже можете подключить его как статическую библиотеку, и тогда вам даже не придётся дополнительный файловый хэндлер открывать для загрузки кода из sqlite3.dll. Код SQLite станет частью вашей программы (исполняемого файла) совершенно бесшовно, увеличив размер исполняемого файла лишь на несколько сотен килобайт.
Драйвера СУБД работают также, в общем-то: делают то же чтение, только могут игнорировать для обработки часть данных. Также присутствует как парсинг запросов, так и выходных данных. Но могут эффективно искать за счёт индексирования (которое, само по себе, весьма затратная операция). Но на 60-200 обрабатываемых килобайт никто не получит никакого выигрыша от слова "совсем" - загрузите это всё в память и ищите там, получая плюс в эффективность на малых объёмах данных (память гораздо быстрее, чем диск, отсюда скорость за счёт использования памяти, сравнимой по объёму с занимаемой памятью самой СУБД). Кроме этого, получите независимость от производителя СУБД и, как результат, работа будет сделана раз и навсегда. Это когда продукт делается с прицелом на будущее, а не решается текущая задача абы как. Отсюда выше качество ПО, меньше затрат на дальнейшее обслуживание.
Если бы требовалось только читать конфиги, то вопросов бы не было — текстовые конфиги наше всё. Но FAR сам сохраняет свои настройки, равно как и плагины. И если FAR сохраняет настройки не очень часто, плагины могут делать это хоть каждую секунду, если им так надо. И вот при сохранении текстовых конфигов начинается самый геморрой, потому что ради одного измененного параметра приходится перезаписывать целиком весь файл. А возможность править текстовые конфиги вручную не очень-то полезна, поскольку, ручные правки могут быть легко перезаписаны FAR'ом при автосохранении конфига, т.е. при правке текстовых конфигов необходимо следить за тем, чтобы не было запущено ни одной копии FAR'а. Плюс возникает проблема, если одна копия FAR'а читает конфиг, другая в него пишет. Хотя это легко решается блокировками файлов, это, тем не менее, может приводить к конфликтам версий аналогично тем, которые случаются в традиционных СУБД (см. "deadlock").
У любой СУБД есть болезнь - проблема, когда несколько экземпляров приложения вносят изменения в одну таблицу одновременно, при этом могут быть обращения к другим таблицам, а там другие вносятся изменения. В этом случае создаётся очередь и запросы обрабатываются в порядке очереди (транзакциями). В случае с текстовым конфигом такой проблемы нет - кто успел записать вперёд, тот и молодец. И всё, это вся разница касательно нескольких экземпляров приложения. Хорошо, что напомнили, только это не плюс к СУБД: вы реально не знаете, о чём написали ещё и позднее.
А вот тут похоже вы не понимаете то, о чём пишете. То, о чём вы говорите — это не болезнь, как вы выразились, а проблема синхронизации параллельных запросов. И СУБД предоставляет разработчику возможность эту проблему выявлять и соответствующим образом обрабатывать. Не хотите обрабатывать, хотите всё отдать на волю случая — пожалуйста, не используйте транзакции. Делов-то! Транзакции нужны, чтобы при проводимых изменениях обеспечить целостность и непротиворечивость как сохраняемых данных, так и читаемых в момент сохранения изменений. Ваш же вариант "кто успел записать вперёд, тот и молодец" — это скорее в стиле Шарикова у Булгакова: "Взять всё, да и поделить".
Про Линукс 60-ых годов вам выше уже ответили, я не буду дополнительно глумиться.
У каждой БД, как правило, есть свой конфиг (.sqliterc, например), который вы, видимо, тоже планируете хранить в БД. Возможно, в другой, ещё более быстрой. А конфиг той ещё в одной. И так до бесконечности. Только потому, что не знаете эффективных способов не хранить что-то в БД. Смею допустить, что эффективность чтения двух мелких конфигов не может быть выше, чем одного. И это ещё не считая всего остального, разумеется. Интересный момент, не правда ли?
Мы ведь всё ещё про SQLite говорим? Если так, то ваша вишенка на торте — мимо тазика. Потому что для подключения к SQLite БД нужен только путь к .db-файлу и всё. Для этого не нужно никаких дополнительных конфигов. Путь к БД вычисляется через переменные окружения типа %APPDATA%\Far Manager\Profile\имя_файла.db. Файл .sqliterc не является обязательным и используется только для интерактивных консольных команд. В случае использования SQLite из FAR нам никакой интерактивности не требуется.
Перечитайте прошлый мой пост, найдите те пункты, где согласны (по факту, почти ни к чему не было замечаний) и задумайтесь, с чем спорите. Таких пунктиков полно и в этом как раз суть - те самые, к которым не было придирок :)
Конечно, очень неприятно получать ответ того, кто судит о других по прокачке профиля.
Вкратце, последний в теме пост, потому что не люблю общаться с человеками, кто начинает с фраз "А ты кто такой?" (одна из причин, почему меня нет на гитхабе - тут столько неучей, что вот сейчас, донести очевидную мысль невозможно тяжело):
-
Частая запись в конфиг плагинов - забота самих плагинов (стоит задуматься, что ты делаешь не так). Их конфиги хранить надо в отдельных файлах - один плагин = один конфиг. Конфиги не будут сохраняться быстрее, если делать это через индексируемую БД, см. построение индексов. Чётко, ясно и просто. Как в Линуксе - грузится какой-нидь nginx, считывает все конфиги всех сайтов, несколько сотен по 50 килобайт - и парсит, и вуаля - доли секунды на запуск. Допускается вложенность конфигов один в один ссылками изнутри. Так очень удобно было бы сделать. Так работает система на любом смартфоне, например. Иначе говоря, всё это давным давно пройденный этап, есть стандартные решения с прошлого века (чтобы не цеплялись к конкретным годам, это неважно сейчас).
-
По Линуксу не понял: всё хранится в текстовых конфигах, в чём я был не прав? Можете поглумиться, мне не жалко, вы не первый такой, но даже повода не вижу :) "Вам даже написали" - так я понял, что мне написали, а вы?
-
PHP написан на С, в нём изначально не было PDO и сохранилась возможность работать без оного. Какое это отношение имеет к поднятому вопросу, не смог представить. Загрузка библиотеки = инициализация модуля СУБД. Ведись дальнейшая работа через унифицированный PDO или другой программный интерфейс... никакой разницы. Теперь я уверен, что вы не были в курсе, что такое PDO на момент написания прошлого поста. Но это ничего, местный уровень, он невысок в большинстве своём. И продолжает падать - в конце объясню, почему.
-
Вишенка на тортике: как только понадобится внедрить только один недефолтный любой параметр = вишенка со всеми вытекающими, хотя это просто демонстрация неэффективности - ни одна СУБД не хранит свой конфиг в другой БД. Но главное вы не заметили, прошли мимо, защищая непонятно что. То есть даже про вишенку не поняли, - для чего она вообще дана была.
-
Про транзакции - они не нужны в случае, если мы не используем БД. То есть всё делается проще: через файловую систему и её кеш. Но вместо понимания сути, вами написано, зачем они нужны в принципе. В курсе, спасибо: первую свою СУБД с нуля разработал ещё в 95-м (это ещё одна из причин, почему меня нет на гитхабе).
Да о чём мы говорим: только аутентификация при первом обращении к СУБД занимает больше времени, чем чтение одного конфигурационного файла вместе со всеми данными моих плагинов.
хранить конфиг в текстовых файлах, если это оформлено в виде какого-то API или библиотеки, то по сути это тоже СУБД, согласно определению этого термина. И раз так, то вы сами себе противоречите, когда противопоставляете текстовые конфиги и СУБД.
Вы даже не представляете, как сохранить конфиг в файл и на догадках строите выводы о несуществующих противоречиях. Как не видите разницы между API и СУБД. При этом рискуете потратить на меня своё время :) Общение свелось не к измерениям скорости / памяти, которые просил проделать, а к тому, что вы отчаянно пытаетесь сохранить своё лицо путём голословия и предположений. Это как если я скажу, что не использую много плагинов и зачем мне тогда БД? Никому тут не нужно ваше лицо, как СУБД Far`у :)
Написал изначально, что Far будет работать эффективней, если не использовать СУБД. Он будет работать быстрее, потреблять меньше памяти, станет проще в обслуживании и не зависеть от третьих фирм. При этом без ущерба в лёгкости написания кода, что вы там понавыдумывали. Как по мне, выгоды очевидны. Кто-то когда-то решил, что это всё не нужно, можно принести в жертву - он тоже не знал, видимо, как сохранить в файл конфиг. Вы пытаетесь защитить его позицию: мы услышали здесь разное - про время выхода в свет JSON, про то, что СУБД не всегда нужен конфиг, что такое транзакции и прочую википедийную инфу, но ничего, что опровергало хоть как-то моё замечание. Просто воздух.
Учитесь, пожалуйста. Пока живы такие, как мы: те, кто экономили каждый байт. А кто-то тут ещё и проволокой его на катушку наматывал. Жизненная рекомендация: попробуйте составить своё мнение в процессе общения, а не по дурацким профилям. Поверьте, оно будет куда правдивей - я вот уже своё о вас составил, хотя в профиль и не заглядывал :) И уже точно не потрачу ни капли времени, оставляя другим пример, как бывает, что вместо аргументов начинаются домыслы и им нет конца. Вы понимаете, что до сих пор не предоставили ни единого аргумента за своё возражение? Боюсь, что нет...
P/S Гитхаб, кстати, не нахожу чем-то хорошим в принципе: бОльшую часть кода здесь можно затереть навсегда и мир станет только лучше. Этот ресурс способствует тому, что программисты становятся более узкопрофильными и не понимают, что там, под капотом, что там в чёрной коробочке, которую кто-то другой сделал и этот теперь - просто пользователь этой коробочки, он уже не программист, он юзер! А ведь двигатель был рассчитан на другую коробку передач... Ошибки копятся без единой архитектуры, вот, к чему это ведёт в текущем виде. Сейчас уже никто не напишет дисковый редактор на ассемблере, это понятно... Но там, где нужна эффективность, её не хватает. В итоге на смартфоне, который равен по своим мощностям целому городу конца 80-х, тормозит какой-нидь арканоид. И попробуй, что скажи - клевать будут до последнего - разрабы Far`а круты и потому правы: это вам не Рошаль, который всё в текстовых конфигах хранил, по-старинке, наверное :)
@mr-older Экстраординарные заявления требуют экстраординарных доказательств. Именно поэтому я и спросил у вас про подтверждение вашего опыта. В интернете полно троллей и просто сумасшедших людей, которым доставляет удовольствие кидаться умными фразами и всячески изображать из себя супер-профессионала, призывая полагаться на истину авторитета, а не на авторитет истины. В англоязычных странах существует поговорка: "If you are so smart show me your money". Смысл которой в том, что если человек много умничает, но не может заработать денег, то не такой уж он и умный. В нашем случае деньги можно заменить на код.
Гитхаб тем и хорош, что позволяет сразу всё расставить по своим местам и понять кто есть кто. Кто реально умеет код писать, а кто только языком чесать. Глупо не пользоваться этой бесплатной возможностью. На гитхабе есть разные люди, как и в реальной жизни. Если брать среднее значение, то уровень конечно невысок, как и в реальной жизни. Но здесь есть люди, которые значительно умнее и талантливее и вас, и меня. Отказ признавать это попахивает шизофренией. Вы случайно не ощущаете себя особенным человеком? У вас нет сверхценной идеи вроде стремления к минимизации расхода процессорной мощности и оперативной памяти? Даже если нет, у вас явно завышенное ЧСВ, при этом всех вокруг считаете необразованными болванами, которым надо учиться, учиться и учиться. Желательно у таких как вы. Вы похожи на старика, который думает, что познал жизнь и то и дело причитает "вот в моё время..." просто потому что его мозг закостенел и он не может вписаться в изменившийся новый мир.
Если что, я знаю ценность каждого байта памяти не понаслышке. В том же 1995 я пусть и не разрабатывал СУБД, я тогда всего лишь учился в 5-6 классе. Но именно в это время на скучных уроках вроде литературы я писал на последних страницах тетрадей коротенькие программы на ассемблере под 8-битный процессор Z80 с памятью 48К (хотя реально доступной было около 41К). А приходя домой набирал их в TASM, сохранял на магнитофонную ленту, загружал и смотрел как они работают.
Но времена меняются, одни ценности уходят, другие приходят им на смену. Меняйся или сдохни -- вот девиз, который я разделяю. Кто есть хороший программист сегодня -- это тот, кто способен решать задачу бизнеса наилучшим образом за наименьшее время и деньги. А вовсе не тот, кто способен добиться максимально возможного быстродействия (даже там, где с ним проблем нет) и минимального расхода памяти. И уж тем более не тот, кто может много рассказывать про программирование. Точно так же как хороший водитель не тот, кто может доехать из пункта А в пункт Б с максимальной скоростью, потратив минимальное кол-во топлива, а тот, кто может сделать это безопасно и комфортно для себя и пассажиров, не создав неудобств другим участникам движения.
Конфиги не будут сохраняться быстрее, если делать это через индексируемую БД, см. построение индексов
Во-первых, будут, поскольку для изменения одной записи не требуется перезаписывать весь файл. Во-вторых, будут, поскольку обновление индекса при изменении, удалении или вставке -- это не перезапись всего индекса, а лишь небольшой его части. При этом для его обновления задействуется двоичный поиск, что гораздо быстрее последовательного.
Как в Линуксе - грузится какой-нидь nginx, считывает все конфиги всех сайтов, несколько сотен по 50 килобайт - и парсит, и вуаля - доли секунды на запуск
Разница только в том, что nginx не сохраняет свои конфиги в текстовые файлы потому что nginx это сервис, у которого нет пользовательского интерфейса, поэтому неудобства в виде необходимости работать с текстовыми файлами оправданы. Более уместно было бы сравнивать с Midnight Commander, и там действительно конфиги хранятся в тексте, но у MC нет плагинов в традиционном понимании (а не биндинги на определенные типы файлов).
Для любой платформы, предоставляющей возможность создания плагинов сторонними разработчиками, первостепенной является задача максимального упрощения всех рутинных процессов, чтобы не отпугнуть своей сложностью потенциальных авторов плагинов. Я думаю, что именно поэтому вместо предложения авторам самим как-то читать конфиги из текстовых файлов и разбираться с блокировками при одновременном обращении к конфигам, был предложен максимально удобный метод работы с конфигом в первую очередь именно для стороннего разработчика, который будет делать на голом энтузиазме.
Кстати, Chrome и Mozilla хранят свои конфиги в SQLite. Они тоже не понимают что они делают? А что если кто-то захочет в FAR сделать плагин веб-браузера на подобии Links, то что тогда?
И ещё кстати, у меня FAR тоже запускается за долю секунды. Примерно за 0.3 секунды, сопоставимо с оконной анимацией открытия нового окна. Nginx, кстати, дольше запускается. Но я не утверждаю, что это связано с типом конфигов.
По Линуксу не понял: всё хранится в текстовых конфигах, в чём я был не прав? Можете поглумиться, мне не жалко, вы не первый такой, но даже повода не вижу :) "Вам даже написали" - так я понял, что мне написали, а вы?
Вы писали про Линукс, работающий с 60-ых годов прошлого века, тогда как самая первая версия Линукса, причём не операционной системы, а всего лишь голого ядра без ничего появилась в 1991 году. Даже Юникс с самим языком Си берёт начало с 1970 года. Нормальным было бы признать свою ошибку и отшутиться, сославшись на возраст и память. Но вы же просто проигнорировали возражение и ведёте себя так, как будто не понимаете о чём речь. Запустили "дурочку", в общем.
PHP написан на С, в нём изначально не было PDO и сохранилась возможность работать без оного. Какое это отношение имеет к поднятому вопросу, не смог представить. Загрузка библиотеки = инициализация модуля СУБД. Ведись дальнейшая работа через унифицированный PDO или другой программный интерфейс... никакой разницы. Теперь я уверен, что вы не были в курсе, что такое PDO на момент написания прошлого поста.
Вы опять делаете поспешные выводы о людях, с которыми вы не знакомы. Вы видимо забыли, так я вам напомню. Всё началось с того, что вы сказали:
Даже самая быстрая СУБД требует загрузки себя и своих драйверов только для того, чтобы начать обращаться к файлам БД.
Я вам возразил, что при использовании SQLite в компилируемых языках не требуется загрузка никаких драйверов, а в случае статической линковки не требуется даже динамически подключаемых библиотек. То есть ваше утверждение про то, что любая СУБД требует загрузки себя и своих драйверов ошибочно. Вы спрашивали про то, с какими пунктами из того, что вы написали, я не согласен -- вот этот пункт.
Про PDO я упомянул и предположил, что вы знакомы только с ним, лишь потому, что вы использовали слово "драйвер", который как раз из терминологии PDO. Плюс в вашем профиле есть проект на PHP. И тут неважно через PDO или без PDO, в любом случае PHP будет загружать отдельную DLL-ку для работы с SQLite. В этом плане накладные расходы от использования SQLite можно принять во внимание. Тогда как при использовании статической линковки -- нет.
Вишенка на тортике: как только понадобится внедрить только один недефолтный любой параметр = вишенка со всеми вытекающими, хотя это просто демонстрация неэффективности
Про вашу вишенку я написал в прошлом сообщении. Нет никакой вишенки в случае использования SQLite, т.к. нет никаких параметров там.
ни одна СУБД не хранит свой конфиг в другой БД.
Но многие СУБД хранят свои конфиги в своей собственной БД.
Но главное вы не заметили, прошли мимо, защищая непонятно что. То есть даже про вишенку не поняли, - для чего она вообще дана была.
Так вы изъясняйтесь точнее. А то кидаетесь какими-то абстрактными и просто некорректными примерами как в случае с .sqliterc, а потом жалуетесь, что вас не поняли, и отказываетесь дальше уточнять свою мысль.
В курсе, спасибо: первую свою СУБД с нуля разработал ещё в 95-м (это ещё одна из причин, почему меня нет на гитхабе).
О, теперь я ещё вижу у вас признаки шизофазии. Это когда грамматически предложение построено верно, но его содержание совершенно бессмысленно. Как связано то, что вы разработали СУБД с нуля в 95-ом и то, что вас нет на гитхабе? Всякий ли разработчик СУБД должен отсутствовать на гитхабе? Или только такой избранный разработчик как вы?
Да о чём мы говорим: только аутентификация при первом обращении к СУБД занимает больше времени, чем чтение одного конфигурационного файла вместе со всеми данными моих плагинов.
Какая аутентификация в SQLite? Вы точно представляете то, о чём говорите? Я не буду опускаться до вашего уровня, говоря что-нибудь в духе "теперь я точно знаю, что вы понятия не имеете о том, о чём говорите". В SQLite нет никакой аутентификации.
Вы даже не представляете, как сохранить конфиг в файл и на догадках строите выводы о несуществующих противоречиях.
Что навело вас на эту мысль?
Как не видите разницы между API и СУБД.
Если у чего-то, что обладает признаками СУБД, т.е. позволяет сохранять и извлекать данные, есть API, то мы условно можем называть это СУБД. Ваш довод почему нет? Или опять продолжите говорить про не имение понятия?
а к тому, что вы отчаянно пытаетесь сохранить своё лицо путём голословия и предположений.
А вот тут реально улыбнуло. Изначально глупости написали вы, вас мокнули в них лицом, но вы этого не поняли и искренне считаете, что это кто-то другой пытается сохранить лицо.
Это как если я скажу, что не использую много плагинов и зачем мне тогда БД? Никому тут не нужно ваше лицо, как СУБД Far`у :)
Вот в этом ваша главная глупость. Вы делаете суждения о том, что нужно и что не нужно на основании вашего личного опыта использования. То, что лично вы не используете много плагинов, это не значит что все должны использовать их в небольшом кол-ве. Вы не избранный, и разработчики FAR не обязаны подстраиваться под вас. Они решают задачу в общем, с учётом всех возможных нюансов. Не забивают на одновременное обращение к файлам, считая эту ситуацию пренебрежимо маловероятной. Не отдают на волю случая "кто успел записать - тот и молодец". Кто-то может посчитать это преждевременной оптимизацией. Что ж, это дискуссионный вопрос. Но внедрение SQLite по сложности сопоставимо с чтение текстовых конфигов, по быстродействию тоже.
Вы пытаетесь защитить его позицию: мы услышали здесь разное - про время выхода в свет JSON, про то, что СУБД не всегда нужен конфиг, что такое транзакции и прочую википедийную инфу, но ничего, что опровергало хоть как-то моё замечание. Просто воздух.
Кто "мы"? Вас там несколько? У вас голоса в голове и вы с ними общаетесь? Или с кем вы здесь объединились, чтобы причислять себя к социальной группе "мы"? Опровержение было, я уже устал его повторять, вы его не видите и твердите лишь про свои 60 кб.
Учитесь, пожалуйста. Пока живы такие, как мы: те, кто экономили каждый байт
Опять в ваших словах чувствуется избранность и сверхценная идея. Чему учиться у динозавров? Тому как эффективно вымирать? Вот если откровенно, насколько вы сейчас востребованы на рынке труда как программист? Можно ссылочку на ваше резюме? Ну или хотя бы порядок зарплаты? Если стесняетесь, можно в личку, я никому не расскажу. Деньги конечно не идеальный инструмент, но это лучшее, что у нас есть. И если один человек зарабатывает меньше другого, то чему он может научить?
Жизненная рекомендация: попробуйте составить своё мнение в процессе общения, а не по дурацким профилям. Поверьте, оно будет куда правдивей - я вот уже своё о вас составил, хотя в профиль и не заглядывал :)
Я должен вам верить только потому что вы так говорите? Если бы я так делал, то я бы каждый день попадался на разводы всевозможных мошенников. Я пока что знаю о вас лишь то, что вы мастак составлять поспешные мнения о людях по их словам. Я же больше доверяю делам, а не словам. А людей, которые ведут себя подобно вам я называю троллями. Пока они не подтвердят свои слова фактами, которые можно проверить.
P/S Гитхаб, кстати, не нахожу чем-то хорошим в принципе: бОльшую часть кода здесь можно затереть навсегда и мир станет только лучше. Этот ресурс способствует тому, что программисты становятся более узкопрофильными и не понимают, что там, под капотом, что там в чёрной коробочке, которую кто-то другой сделал и этот теперь - просто пользователь этой коробочки, он уже не программист, он юзер! А ведь двигатель был рассчитан на другую коробку передач...
Вы -- динозавр, который не понимает одну простую вещь, что достижения новых поколений основываются на достижениях прошлых поколений. Развитие и движение вперед в программировании невозможно без использования чужих наработок. Давно прошли те времена, когда программист разрабатывал программу целиком с нуля, в идеале на языке программирования, придуманном для этой программы, и которая включала в себя поддержку оборудования на низком уровне, от чего программа могла работать только с каким-то конкретным железом, например, джойстиком, и не работала с другим.
По сути, использование сторонних библиотек и стороннего кода в общем -- это один из базовых принципов ООП -- инкапсуляция. То есть намеренное сокрытие деталей внутренней реализации, создание чёрного ящика с несколькими дырочками, в которые можно что-то засовывать, и что-то получать в ответ. Внутри черного ящика происходит какая-то условная магия, которую разработчику программы знать не обязательно. Таким образом происходит разделение зон ответственности между программистами, которые разрабатывают программу, и программистами, которые разрабатывают библиотеки, используемые в программе.
Такое разделение показало свою эффективность и проверено десятилетиями. Это во времена MS DOS можно было наизусть выучить все системные прерывания и все функции MS DOS, вызываемые через прерывание 21h. Сейчас же объём предметной области настолько велик, что даже мельком невозможно освоить и 10%. Поэтому отсутствие погружения программиста во внутреннюю реализацию тех или иных сложных вещей -- это не недостаток нового поколения программистов, а по сути условие, при котором возможно разработать что-то сложнее, чем "Hello World" (или примитивной СУБД с нуля). Это конкурентное преимущество, позволяющее сосредоточить все усилия на основной задаче, не отвлекаясь на то, что уже было сделано другими программистами ранее. Это также и дань программистам прошлых лет, что их труд был сохранён, а не просто перезаписан новыми программистами. Это как в математике: если какая-то теорема была доказана, то мы можем просто опираться на неё в доказательстве новых теорем, при этом нам даже не обязательно знать доказательства старых. Мы просто знаем что они уже доказаны и их не нужно доказывать снова.
Поэтому разработка делится на определенные ниши, на которых программист специализируется. Если программист не разрабатывает драйвера видеокарты, то ему не нужно знать как видеокарты работают изнутри. Если программист не разрабатывает графическую библиотеку типа OpenGL, то ему не нужно знать все её тонкости общения с драйверами. Если программист не разрабатывает игровой движок, то ему не нужно знать все тонкости работы с OpenGL/DirectX/Vulkan. Достаточно просто подключить библиотеку и использовать, согласно документации. Чтобы выполнить поставленную задачу. Заказчику в конечном счёте неважно как получена работающая программа: написал ли программист каждую строчку лично сам, или частично использовал чей-то готовый код, проверенное многими другими людьми на гитхабе.
Так что вот ещё один пункт, по которому я с вами не согласен. Программист, использующий библиотеки с того же гитхаба -- это программист, причём более квалифицированный, чем тот, который не использует чужие библиотеки, а всё пишет сам с нуля.
Ладно вам спорить. Лучше почините https://forum.ru-board.com/topic.cgi?forum=5&topic=50439&start=1440#19 ибо снова сломали.
Не смог прочитать весь пост внимательно после первого же ляпа:
Во-первых, будут, поскольку для изменения одной записи не требуется перезаписывать весь файл. Во-вторых, будут, поскольку обновление индекса при изменении, удалении или вставке -- это не перезапись всего индекса, а лишь небольшой его части. При этом для его обновления задействуется двоичный поиск, что гораздо быстрее последовательного.
У динозавров учиться можно, если захотеть: представьте, что у нас есть где-то весь индекс (грубо - отсортированный набор пар значений), после добавления записи мы его перестроили - после сортировки изменилось содержимое, что нужно сделать? Правильный ответ: "отмотать магнитную ленту на начало файла" и сохранить всё пересортированное содержимое заново. Да, можно хранить индексы с разбитием на файлы-куски - такая тактика применяется для огромного массива данных, чтобы не писать на диск каждый раз весь набор индексов - очень долго. Тогда перезапишем не весь набор, а какую-то его часть, но всё равно перезапишем эту часть, потому что после сортировки содержимое изменилось. Согласны? Вы можете возразить только одно - индексов очень мало, так что всё это будет быстро. Так если их мало, нужна ли БД?
А теперь нам надо сохранить сами данные. Ресурсы мы также потратили на обработку запросов. На инициализацию СУБД. На подключение к конкретной БД. На загрузку её индексов. На авторизацию приложения.
Итог: нет понимания, как работают индексы в БД = нет понимания, как работает БД. Нет понимания разницы между API и СУБД (интерфейс и СУБД, это совсем разные вещи) = нет представления о СУБД в принципе. Как и понять собеседника нет никакого желания. Прочитал мельком и бросил - на каждый пункт с десяток ответов, но это всё не имеет никакого смысла в данном случае: вы не смогли для себя согласиться ни с одним моим пунктом, что изначально (прочитайте свой первый пост), ставит под сомнение потребность в этом. Вы правы, и точка.
По делу
В индексах была приведена потребность (где-то выше) только для поиска конфига для того или иного плагина. Конфиги плагинов храним в файлах, адрес к которым и есть "индекс", который хранится в головном конфиге файла / высчитывается при подгрузке файла плагина из папки. В любом случае все эти данные загружаются в память. Размер хранимых данных сравним с затратами на саму СУБД (без БД). Всё, в таких условиях СУБД не нужна: её применение в данном случае несёт исключительно негативные последствия. Одно из них - тема этой ветки.
Чтобы применить кирпичик с гитхаба или откуда-то ещё, программист должен знать, что под капотом. И диалог выше - прямое доказательство, как не зная подробностей, лезут на рожон, надеясь, что там всё хорошо.
Про гитхаб
Спросил как-то у одного в своей команде, где взял этот вот кусок кода, вижу, что не твой?
- С гитхаба...
- Тут же 20 строк тебе только надо отсюда и всё?
- Ну, а зачем изобретать велосипед...
- Откуда знаешь, что оно рабочее?
- Так вот, же, 300+ коммитов...
- А ты за этот код премией ручаешься?
- ....
- Обслуживать его потом кто будет, всё отверил, оттестил, подробные комменты есть?
- ....
- А почему всё куском схватил, не вырезал хотя бы только нужное нам?
- ...
Молодёжь :) Вот так, говорю, и будешь объяснять заказчику, что у того, у кого ты взял этот "код", был крутой профиль на гитхабе.
В этом вся разница: динозавры делали Продукты, у которых не было "горячих обновлений". Только Версии. А не альфа-"ПО", которое кое-как работает от апдейта к апдейту. 300+ коммитов... навсегда запомнилось. И, главное, спорят же. Все спорят. Сами не знают, как толком работает файловая система, как это, сохранить не весь индексный файл, а только его часть. Как минимум, это уже один кластер в 4к стандартно на NTFS. Если бы не дино-Торвальдс, щас бы андроида не было бы, чему у нас учиться, действительно. Скорость разработки затмила качество и рады.
@mr-older весь абзац про индексы показывает ваше незнание предметной области. Не знаю, какие вы там СУБД писали в 1995м, но сейчас так не носят (мне кажется, и в 1995м не носили). В частности, и в SQLite индексы работают не так. Очень забавно, что при этом вы с таким апломбом пишете, что непонимание, как работают индексы полностью инвалидирует участника этой дискуссии.
Я выше отмечался, что считаю SQLite плохим выбором для хранения конфигов (по крайней мере в фаре), но ваша аргументация - это уж извините. Вы после 1995го года писали еще программы? Есть ощущение, что нет.
Индексы описаны были "грубо" - оставлял пометку. С SQLite не работал в принципе. И вы правы, давно не лез во внутренности современных СУБД. Специально только что прочитал документацию к SQLite: индексы действительно не хранятся в отдельном файле. Как когда-то строил бинарное дерево именно для этого, но тут другая технология.
Прошу прощения, времена действительно изменились. Что, правда, не делает СУБД хорошим выбором для хранения конфигов FAR`а. Как им многое другое, что выше. С индексами пролёт, виноват, отстал от жизни... всё не успеешь. А по теме снова ноль. То поймают на том, что юникс с линуксом оговорюсь, то ещё за что-нибудь, а по теме ноль.
непонимание, как работают индексы полностью инвалидирует участника этой дискуссии.
Вот так? И это всё? :))) Ну так другой собеседник отличить АПИ от СУБД не может с третьей попытки. Признавать свои ошибки надо, и, что поделать, "и на старуху бывает проруха". Хотя бы это понимаю и делаю. Вы ещё обозлитесь все вместе на меня: вот он, гитхаб во всей красе - не доказать очевидное. Даже потенциальный союзник инвалидировал из дискуссии :)) Какая от этого польза?
Вы после 1995го года писали еще программы? Есть ощущение, что нет.
Доделываю прямо сейчас whitepool.net, весь проект целиком мой, на неделе запуск этого хобби по вечерам последние пару-тройку месяцев. Ядро на С + PHP обёртка + БД само собой. Сайт сам, хостинг, сервера, да всё своё. С гитхаба только нода. И она - единственное, что есть глючного, за что переживаю. Следующий шаг - писать ноду, наверное... :)
И да, всё по возможности делаю сам - мне так спокойней. Если не для себя, то заказчик тоже уверен, что всё будет хорошо. Потому что минимум чужого кода и максимум оптимизации. Потому что если нет удовлетворения от работы, то зачем ты её делал? Только ради денег, на скорость... А для чего тогда жизнь?
Я не вижу особого смысла продолжать этот разговор, ваш позиция мне понятна, я ее считаю нежизнеспособной, но переубеждать не собираюсь. Если вы с таким подходом в состоянии найти клиентов или работу и выдавать результат в срок - здорово. Отвечу только предметно.
Как и не делает из неё API
SQLite предоставляет API для работы с БД, не вижу противоречий. Нигде в словах @gugglegum ничего некорректного про API / СУБД сказано не было.
Даже потенциальный союзник инвалидировал
Вы сначала пишете какую-то дичь и ересь про БД и индексы, потом говорите, что непонимание устройства БД - это вылет из дискуссии, а затем говорите, что нынче программист пошел не тот и пользуется инструментами их не понимая, не то что вы, но постойте-ка...
Доделываю прямо сейчас whitepool.net, весь проект целиком мой, на неделе запуск этого хобби по вечерам последние пару-тройку месяцев. Ядро на С + PHP обёртка + БД само собой
Как же это вы БД используете, если не знаете как она работает? Своим же приниципам изменяете.
А по теме снова ноль.
По какой теме? По теме, что раньше трава была зеленее? Не была.
Ну, дорогие мои Мелехов и Сидоров... довели ж. Посмотрел я ваши профили!
Инвалидировал я вас :))))))) По удалёнке школьник у меня работал в том году, ЕГ на 100 баллов сдал, в Москве университет выбирал любой, вот у кого вам обоим учиться и учиться, вот у кого портфолио. Апломб..... мда. Могу себе позволить, при том значительный, очень-очень-очень значительный в вашем отношении. Дёрнул меня чёрт, но всё оказалось ещё хуже. Лучше б не смотрел. Простите, это вот совсем не в тему, развели на эмоции. Тысяча извинений, ведь догадывался, что перед студентами распинаюсь.... Тысяча и одно :)))))))))))) Досадный гитхаб...
Понимаете теперь, почему меня на нём нет? И не будет, всё, так прокалываться, это сильно. Вон, Виктора VG помню ещё с пелёнок, наверное, и логотип он не менял сто лет, есть с кого брать пример. Учитесь, учитесь, учитесь. Да прибудет с вами надежда!
SQLite предоставляет API для работы с БД, не вижу противоречий. Нигде в словах @gugglegum ничего некорректного про API / СУБД сказано не было.
Горе мне :) Связался. Предметный ответ называется. ДВА! Садитесь. API - это интерфейс СУБД. Нельзя говорить, что API = СУБД, потому что курица и лоток с яйцами - это разные вещи.
На счёт того, что СУБД — это самый медленный способ. С чего вы это взяли? На чём зиждется утверждение, что это самый медленный способ, т.е. не существует (не может существовать) более медленного способа? Собственно, то, что вы предлагаете — хранить конфиг в текстовых файлах, если это оформлено в виде какого-то API или библиотеки, то по сути это тоже СУБД, согласно определению этого термина. И раз так, то вы сами себе противоречите, когда противопоставляете текстовые конфиги и СУБД.
И поэтому (см. контекст предыдущего горе-оратора) оно по ресурсоёмкости (!) одинаково (!) с любым другим API ?! С чем согласны? С философским замечанием насчёт теоретически более медленного способа или с тем, что по определению термина СУБД, это есть API? Или с тем, что раз там, и там API, то работать будет одинаково эффективно? Здесь кто-то попытался меня задеть тем, что можно ещё медленней, вот уж правда, можно. Хотя мне кажется, что ещё медленней только кому-то что-то тут объяснять.
Как же это вы БД используете, если не знаете как она работает? Своим же приниципам изменяете.
Есть разница между тем, чтобы разрабатывать каждый раз свой инструмент под себя и тем, чтобы использовать код, уже созданный на этом инструменте. Ехидство ваше неуместно - оно обнажает непонимание разницы между инструментом и продуктом, полученным с его помощью.
Вкратце: есть языки программирования, СУБД, и т. д. Это инструменты. И есть нечто, созданное другими с помощью этих инструментов. Любой понимает, что доверия разработчикам СУБД / языка программирования всегда больше, чем тем, кто написал какой-нибудь фреймворк на этом же языке. Или тем более тем, кто написал что-то ещё, например, с использованием фреймворка. Всё оттого, что ошибки имеют накопительный эффект. Вот почему, чем меньше прослоек, тем надёжней программа, тем дороже она в разработке, но тем дешевле в поддержке. Но это вовсе не значит, что надо каждый раз писать свою СУБД. И вы снова невнимательны: про то, что знать, надо, что под капотом, я писал про чужие программы, не про языки программирования, на котором они созданы. Два за внимательность :)
Я много писал для себя. И многие из моих проектов не работали бы, если бы сделал их плохо - просто не было бы времени на поддержку и не смог бы написать что-то ещё. Поэтому максимально качественно привык делать - сделал и забыл, чтобы потом не тратить время. А у вас так: денег срубил и побежал дальше. Работает? Всё, платите. А то, что через месяц встанет - так снова платите. Дурной этот капитализм. И спорят же ещё, спорят-то как горячо, только без аргументов и не по теме.
Читайте, гуглите, а с меня всё, хватит :) Я за индексы извинился, у меня жизненный опыт достаточный, чтобы иметь в себе силы признавать ошибки. Но тут полная бесполезность, 300+ коммитов... :)))
Тысяча извинений, ведь догадывался, что перед студентами распинаюсь....
Вот опять вы не разобрались, опять неловко вышло. Видимо, увидели у меня университет в месте работы. Я там не учусь, я там преподаю докторантам и магистрантам курсы по обработке больших данных и веду исследовательскую группу в области безопасности баз данных.
Нельзя говорить, что API = СУБД
СУБД собственно и есть API вокруг БД. Вы, вероятно, понимаете API исключительно как контракт, но вполне можно понимать API как контракт+реализация.
Вот почему, чем меньше прослоек, <...> тем дешевле в поддержке
Сколько раз я видел как компании от мала до велика тратили горы на переписывание велосипедов на популярные технологии отттого, что поддерживать велосипеды было неподъёмно дорого. В Яндексе была эпичная история (детали рассказхать не могу), где человек не хотел использовать фреймворки и написал в одно рыло своё жутко оптимизированное (без сарказма) изделие на ассемблере. Человека потом, конечно, выгнали и переписали на обычных технологиях, а чтобы не тормозило закинули еще серверов потолще.
А то, что через месяц встанет - так снова платите
Есть много областей, где через месяц уже и не надо. То, что что-то не ломается еще не значит, что это что-то хорошее или кому-то нужно.
Я за индексы извинился
Медленная работа с индексами - это был единственный внятный аргумент от вас, почему SQLite не надо использовать.