LetoDb fork

Форум » LetoDB, HbNetio. » LetoDb fork » Ответить

LetoDb fork

PSP: https://github.com/elchs/LetoDBf https://github.com/elchs/LetoDBf/blob/master/README.md Кто-нибудь пробовал или использует в продакшене?

Ответов - 125, стр: 1 2 3 4 5 6 7 All

Sergy: SergKis пишет: На новые фичи перейти мне удалось только внедрением letodb Новые фичи - я имел в виду новые функции программы, никак не связанные со структурой/обработкой базы данных. Например, штрихкодирование документов, товаров, новые виды отчетов и тд и тп. с новой организацией базы на cdx (старая ntx) Вот это уже интересно для меня. Что такого принципиально интересного есть в cdx, чего нет в ntx ?

SergKis: Sergy пишет Что такого принципиально интересного есть в cdx, чего нет в ntx ? наличие тегов в одном индексном файле + SET AUTOPEN ON - подключение индекса автоматом, результат - целостность базы. INDEX ON DtoS(DATADOK)+CLIENT+VID_OPER+TIME_DOK TAG PERIOD INDEX ON CLIENT+DtoS(DATADOK)+VID_OPER+TIME_DOK TAG CLIENT И Ваш SET FILTER _FIELD->CLIENT $ hList... превращается в простые быстрые операции SET SCOPE ... OrdSetFocus('CLIENT') FOR i := 1 TO Len(hList...) cKli := ... SET SCOPE TO cKli, cKli // или leto_SetEnv(cKli, cKli,...) GO TOP // TBROWSE или что то еще ... тоже за период d1, d2 OrdSetFocus('PERIOD') FOR i := 1 TO Len(hList...) cKli := ... SET SCOPE TO DtoS(d1)+cKli, DtoS(d2)+cKli // или leto_SetEnv(DtoS(d1)+cKli,DtoS(d2)+ cKli,...) GO TOP // TBROWSE или что то еще ...

Dima: Таки да Scope или же BM фильтр работает очень шустро.

Sergy: Dima пишет: Таки да Scope или же BM фильтр работает очень шустро. SET SCOPE работает еще со времен Clipper, с DBFNTX - точно так-же, как и DBFCDX. Это базовые функции любой Харборовской RDD. Тоже самое и с bitmap фильтрами. AUTOPEN ... да, наверное это удобно - вместо [pre2]USE table INDEX table NEW[/pre2] писать [pre2]USE table NEW[/pre2]. Экономия - целых два слова в одной команде. )) Кстати, тут недавно наш админ поковырялся с 1с - там оказывается, народ извращается с этим монстром так: выносит индексные и прочие временные файлы на RAM-диск. Почему-то был уверен, что RAM-диски канули в лету вместе с DOS 6.22 - ан нет, в 2018 году этот метод ещё жив. Родилась идея - засунуть *.dbf файлы на шустрый SSD, а индексы - размещать на серверном RAM диске (чтобы флэш-память не изнашивалась понапрасну). Придется поковырять синтаксис команд USE ... INDEX ... - но мне кажется, овчинка будет стоить выделки. Может кто-то уже пробовал? SET AOUTOPEN тут точно не поможет...

Sergy: SergKis пишет: наличие тегов в одном индексном файле + SET AUTOPEN ON - подключение индекса автоматом, результат - целостность базы. Не очень понимаю - какая принципиальная разница - одна таблица и 2-3 индекса рядом с ней или одна таблица и один индексный файл. Кроме этого, в некоторых случаях (выборка по всей таблице с какими-нибудь экзотическими условиями, для которых нет смысла держать отдельный ntx/cdx) индекс может быть совсем не нужен - SKIP по нему будет выполняться гоооооорааааааздо медленнее, чем по dbf таблице без индекса. SergKis пишет: На новые фичи перейти мне удалось только внедрением letodb с новой организацией базы на cdx (старая ntx) Так и осталось непонятным, что именно ПРИНЦИПИАЛЬНО есть в CDX, чего нет в NTX ? Читал наших гуру (Viktor & Przemek) - они писали, что никаких сколь нибудь существенных отличий (для программиста) между DBFCDX и DBFNTX в реализации Harbour нет. CDX занимает меньше места на диске (легкая компрессия дерева), но требует чуть больше памяти (для того, чтобы развернуть сжатые данные). В общем и целом - тож на тож выходит.

PSP: Существенный прирост при использовании letodb можно получить, если использовать udf-функции, выполняемые на сервере. Все операции с базой выполняются локально на сервере. На клиент возвращается только результат.

Andrey: PSP пишет: Существенный прирост при использовании letodb можно получить, если использовать udf-функции, Да, это точно, подтверждаю. Можно посмотреть пример http://abonent4.ru/letodb/

SergKis: Sergy пишет SET SCOPE работает еще со времен Clipper обеспечивалось сторонними либами Comix, SixNsx,... индекс может быть совсем не нужен - SKIP по нему будет выполняться гоооооорааааааздо медленнее, чем по dbf таблице без индекса. Достаточно одной таблетки SET ORDER TO 0 и ок! letodb так, по умолчанию, делает при открытии таблица (AUTOPEN ON) и не важно кто и сколько раз ее открыл, нужны или нет тэги для работы, главное, модификация записей по части ключей, не сломает базу, с ntx надо правильно подключать все файлы, что бы не разрушить базу. одна таблица и 2-3 индекса рядом с ней или одна таблица и один индексный файл. это у справочников так, у инф. таблиц больше, на SixNsx есть 44 тега (работает оч.давно и очень надежно), а как если бы они были отдельными файлами ... "Чисто гтпотетичечки, ... теоретически ...", к примеру ваш CLIENT в таблице, добавим 2а тега INDEX ON CLIENT ... // список клиентов с информацией INDEX ON CLIENT ... UNIQUE // реал. список клиентов в информации если есть код территории еще INDEX ON KODTER ... UNIQUE // реал. список территорий в информации INDEX ON KODTER+CLIENT ... UNIQUE // реал. список клиентов по территория в информации INDEX ON KODTER+CLIENT ... // список всех территорий по клиентам в информации теперь можем без отборов давать 1.уник. список клиентов в tbrowse, ставить галочки и отработать выборку по галачкам по тэгу не уник. клиентов. 2. уник. список территорий в tbrowse, ставить галочки, по ним собрать для tbrowse (уник. KODTER+CLIENT) список клиентов, поставить галочки и отработать их по не уник. тэгу KODTER+CLIENT добавленные тэги не мешают жить таблице, но позволяют быстро работать при выборках. Если это отдельными ntx файлами, да в разных модулях\проектах - головная боль будет, при обеспечении надежности\целосности. между DBFCDX и DBFNTX в реализации Harbour нет и очень хорошо.

Pasha: Я бегло смотрел LetoDBf, когда он только появился, но до сих пор руки не доходили даже до простейшего теста. Наконец попробовал. Установил новую службу, благо название у нее отличается от старой. Если обе службы слушают один порт (2812), то они мешают друг другу, что понятно. Надо их запускать по очереди. Сделал простейший тест производительности, не самодостаточный, взял пару файлов master-detail, размером 2M и 8M. Запустил локально. Тест такой: Function Main( cPath ) Local i := 0, nSec Field CF1, CF2 REQUEST LETO RDDSETDEFAULT( "LETO" ) SET DATE FORMAT "dd/mm/yy" IF Empty( cPath ) cPath := "//127.0.0.1:2812/temp/" ELSE cPath := "//" + cPath + Iif( Right(cPath,1) $ "/\", "", "/" ) ENDIF ? leto_Connect(cPath) use f1 new index f1 use f2 new index f2 nSec := Seconds() select f1 go top while ! eof() select f2 dbSeek(f1->CF1+f1->CF2) while ! eof() .and. CF1 = f1->CF1 .and. CF2 = f1->CF2 i ++ skip enddo select f1 skip enddo ? Seconds() - nSec, i close all leto_disconnect() Return Nil Старый (оригинальный, "наш") letodb управился за 31 сек. Кстати, обратите внимание, команде use не надо указывать никаких дополнительных строк коннекта. Это было необходимо в ранних версиях. LetoDBf не смог открыть файлы в папке temp, хотя путь есть в строке коннекта. Но это думается мелочь, которую можно подработать в процессе. Зато тест он прогнал за 18 сек, что впечатляет. Другие тесты пока не гонял, и разницу в функциональности не исследовал. В любом случае можно сказать, что Рольф проделал не просто большую, а огромную работу, и проект интересный. Дима, кажется ты не стал использовать letodb из-за отсутствия серверных relations, которые есть в ads. Рольф судя по доке их сделал (я не пробовал), но только в режиме No_Save_WA = 1.

SergKis: Pasha пишет Рольф проделал не просто большую, а огромную работу, и проект интересный. README.md LetoDBf client lib ( used by your application ) became fully MultiThread save, each thread opens its own connection to the server. Threads, threads threads .., wherever you look. т.е. клиентская библиотека полностью MultiThread

Петр: Sergy пишет: Так и осталось непонятным, что именно ПРИНЦИПИАЛЬНО есть в CDX, чего нет в NTX ? Ну так и почитайте документацию (xhb-diff.txt). И multitag indexes, если что, NTX поддерживает.

Pasha: Обратил внимание, что тест для letodb отработал без No_Save_WA = 1, а для letodbf - с этой настройкой. Попытался запустить тест для letodbf без No_Save_WA = 1. Неудача: похоже файлы открыты без индекса, ошибка: workarea not indexed То есть шероховатости конечно имеются.

Sergy: Pasha пишет: LetoDBf не смог открыть файлы в папке temp, хотя путь есть в строке коннекта. Но это думается мелочь, которую можно подработать в процессе. Зато тест он прогнал за 18 сек, что впечатляет. Не вижу в тексте Leto_ToggleZip(1) - попробуй пожалуйста - интересно посмотреть на твой результат. Функция должна стоять сразу после Leto_Connect()

Sergy: SergKis пишет: т.е. клиентская библиотека полностью MultiThread С недавних пор MT для клиента LetoDBf можно отключить при сборке библиотеки. Не знаю, кому это может понадобиться, но при этом теряется одно из интересных преимуществ - "двухканальность", когда по одному порту идут сплошным потоком данные, а по соседнему - только редкая инфа об ошибках в пакетах.

Pasha: С Leto_ToggleZip(1) получилось резкое падение производительности: запустил 10 минут назад, и все жжжжжжжжддддддуууууууууууууу. Прошло 15 минут - надоело, нажал alt+c, ctrl+c - нифига, задача висит. Пришлось его кувалдой таскменеджером Впрочем, для локального теста так и должно быть, но не так же сильно. Так что я не стал бы использовать эту фичу. В letodb (я так буду называть оригинальный проект, в отличие от letodbf) тоже есть сжатие пакетов, но в своей работе я его тоже не использовал.

Sergy: Pasha пишет: Обратил внимание, что тест для letodb отработал без No_Save_WA = 1, а для letodbf - с этой настройкой. Паша, поясни пожалуйста, зачем самый "первый" режим (когда No_Save_WA = 0) нужен. Я правильно понимаю, что сервер открывает таблицу, делает по ней выборку и вместо того, чтобы закрыть её - отправляет в отстойник. Если она кому-то понадобится - сервер забирает ее из detached area и использует вновь. Но ведь в этот момент никто не может открыть эту таблицу? Какой вообще в этом смысл, если изначально планируется, что с базой работает более чем один юзер? Пока один делает выборку - другому предлагается пойти покурить? Вряд-ли - скорее всего, я что-то крупно не понял в англицком... Жесткий оффтопик: И ещё - вымораживает, когда программисты (сам когда-то был таким) пишут в диалогах: "Не использовать выборку тра-ля-ля [v]". Т.е. положительный ответ (галка) несет отрицательный результат (не использовать). Ппц... Напомнило - "Вы не придете сегодня на работу ?" - "Да. Не приду". Или "Нет. Не приду". Тоже самое - с No_Save_WA=1. Да. Единица. Не использовать сохранение рабочих областей.

Sergy: Pasha пишет: С Leto_ToggleZip(1) получилось резкое падение производительности: запустил 10 минут назад, и все жжжжжжжжддддддуууууууууууууу. Чет явно не то... Может Leto_ToogleZip(1) включил, а сервак был запущен - оригинальный, не форк ?

Pasha: Там же протокол совсем разный. Если перепутать клиент и сервер, то программа сразу свалится.

PSP: Sergy пишет: Паша, поясни пожалуйста, зачем самый "первый" режим (когда No_Save_WA = 0) нужен. Да, мне тоже интересны подробности работы этой настройки. Паша, если можно, просвети.

Sergy: SergKis пишет: INDEX ON KODTER ... UNIQUE // реал. список территорий в информации INDEX ON KODTER+CLIENT ... UNIQUE // реал. список клиентов по территория в информации INDEX ON KODTER+CLIENT ... // список всех территорий по клиентам в информации Не очень понятен смысл примера, в DBFNTX работает так: Если есть INDEX ON KODTER+CLIENT TO ... То SEEK cKodTer (без уточнения клиента) даст первое вхождение нужного KODTER. Можно указать SEEK cKodTer+cClient - тогда поиск будет по территории + нужному клиенту. Всё это - по одному индексу. Т.е. другими словами, вместо индексов, частично использующих одни и те-же данные: INDEX ON DTOS(table->date)+STR(table->seller,5)+STR(table->buyer,5)+STR(table->invoice) TO table1 INDEX ON DTOS(table->date)+STR(table->seller,5)+STR(table->buyer,5) TO table2 INDEX ON DTOS(table->date)+STR(table->seller,5) TO table3 INDEX ON DTOS(table->date) TO table4 Можно построить только один, первый. И все "неполные" выборки по нему будут работать норм: как выборка на дату, так и выборка по дате+продавцу, так и выборка по дате+продавцу+клиенту. Вот если нужно быстро найти все накладные покупателя - тогда да, нужен отдельный индекс, тк "перепрыгнуть" в выражении через "продавца" не выйдет. Думаю, что и DBFCDX так может. Поэтому мне не очень понятен смысл в 44 тегах/индексах... Для 99% моих ситуаций хватает одного-двух. Совсем недавно столкнулся с возможной (?) необходимостью в третьем индексе для одной из таблиц, но знакомство с LetoDBf дает возможность подумать - может и обойдусь без индекса, раз данные будут шустро выбираться на сервере...

полная версия страницы