Отправлено: 21.01.18 10:31. Заголовок: LetoDb fork

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

 Отправлено: 11.02.18 11:49. Заголовок: SergKis пишет: На но..

SergKis пишет:

цитата:

На новые фичи перейти мне удалось только внедрением letodb

Новые фичи - я имел в виду новые функции программы, никак не связанные со структурой/обработкой базы данных. Например, штрихкодирование документов, товаров, новые виды отчетов и тд и тп.

цитата:

с новой организацией базы на cdx (старая ntx)

Вот это уже интересно для меня. Что такого принципиально интересного есть в cdx, чего нет в ntx ?

 Отправлено: 11.02.18 13:57. Заголовок: Sergy пишет Что тако..

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 или что то еще
...

 Отправлено: 11.02.18 14:12. Заголовок: Таки да Scope или же..

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

 Отправлено: 11.02.18 20:44. Заголовок: Dima пишет: Таки да..

Dima пишет:

цитата:

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

SET SCOPE работает еще со времен Clipper, с DBFNTX - точно так-же, как и DBFCDX. Это базовые функции любой Харборовской RDD. Тоже самое и с bitmap фильтрами.

AUTOPEN ... да, наверное это удобно - вместо

USE table INDEX table NEW

писать

USE table NEW

. Экономия - целых два слова в одной команде. ))

Кстати, тут недавно наш админ поковырялся с 1с - там оказывается, народ извращается с этим монстром так: выносит индексные и прочие временные файлы на RAM-диск. Почему-то был уверен, что RAM-диски канули в лету вместе с DOS 6.22 - ан нет, в 2018 году этот метод ещё жив.

Родилась идея - засунуть *.dbf файлы на шустрый SSD, а индексы - размещать на серверном RAM диске (чтобы флэш-память не изнашивалась понапрасну). Придется поковырять синтаксис команд USE ... INDEX ... - но мне кажется, овчинка будет стоить выделки. Может кто-то уже пробовал?

SET AOUTOPEN тут точно не поможет...

 Отправлено: 11.02.18 20:59. Заголовок: SergKis пишет: налич..

SergKis пишет:

цитата:

наличие тегов в одном индексном файле + SET AUTOPEN ON - подключение индекса автоматом, результат - целостность базы.

Не очень понимаю - какая принципиальная разница - одна таблица и 2-3 индекса рядом с ней или одна таблица и один индексный файл.
Кроме этого, в некоторых случаях (выборка по всей таблице с какими-нибудь экзотическими условиями, для которых нет смысла держать отдельный ntx/cdx) индекс может быть совсем не нужен - SKIP по нему будет выполняться гоооооорааааааздо медленнее, чем по dbf таблице без индекса.

SergKis пишет:

цитата:

На новые фичи перейти мне удалось только внедрением letodb с новой организацией базы на cdx (старая ntx)

Так и осталось непонятным, что именно ПРИНЦИПИАЛЬНО есть в CDX, чего нет в NTX ?

Читал наших гуру (Viktor & Przemek) - они писали, что никаких сколь нибудь существенных отличий (для программиста) между DBFCDX и DBFNTX в реализации Harbour нет. CDX занимает меньше места на диске (легкая компрессия дерева), но требует чуть больше памяти (для того, чтобы развернуть сжатые данные). В общем и целом - тож на тож выходит.

 Отправлено: 11.02.18 21:10. Заголовок: Существенный прирост..

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

 Отправлено: 12.02.18 09:59. Заголовок: PSP пишет: Существе..

PSP пишет:

цитата:

Существенный прирост при использовании letodb можно получить, если использовать udf-функции,

Да, это точно, подтверждаю.
Можно посмотреть пример http://abonent4.ru/letodb/

 Отправлено: 12.02.18 11:06. Заголовок: Sergy пишет SET SCOP..

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 нет

и очень хорошо.

 Отправлено: 12.02.18 12:07. Заголовок: Я бегло смотрел Leto..

Я бегло смотрел 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.

 Отправлено: 12.02.18 12:18. Заголовок: Pasha пишет Рольф пр..

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

 Отправлено: 12.02.18 12:19. Заголовок: Sergy пишет: Так и ..

Sergy пишет:

цитата:

Так и осталось непонятным, что именно ПРИНЦИПИАЛЬНО есть в CDX, чего нет в NTX ?

Ну так и почитайте документацию (xhb-diff.txt).
И multitag indexes, если что, NTX поддерживает.

 Отправлено: 12.02.18 12:37. Заголовок: Обратил внимание, чт..

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

 Отправлено: 12.02.18 13:33. Заголовок: Pasha пишет: LetoDB..

Pasha пишет:

цитата:

LetoDBf не смог открыть файлы в папке temp, хотя путь есть в строке коннекта. Но это думается мелочь, которую можно подработать в процессе. Зато тест он прогнал за 18 сек, что впечатляет.

Не вижу в тексте Leto_ToggleZip(1) - попробуй пожалуйста - интересно посмотреть на твой результат. Функция должна стоять сразу после Leto_Connect()

 Отправлено: 12.02.18 13:36. Заголовок: SergKis пишет: т.е...

SergKis пишет:

цитата:

т.е. клиентская библиотека полностью MultiThread

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

 Отправлено: 12.02.18 13:48. Заголовок: С Leto_ToggleZip(1) ..

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

 Отправлено: 12.02.18 14:02. Заголовок: Pasha пишет: Обрат..

Pasha пишет:

цитата:

Обратил внимание, что тест для letodb отработал без No_Save_WA = 1, а для letodbf - с этой настройкой.

Паша, поясни пожалуйста, зачем самый "первый" режим (когда No_Save_WA = 0) нужен. Я правильно понимаю, что сервер открывает таблицу, делает по ней выборку и вместо того, чтобы закрыть её - отправляет в отстойник. Если она кому-то понадобится - сервер забирает ее из detached area и использует вновь. Но ведь в этот момент никто не может открыть эту таблицу? Какой вообще в этом смысл, если изначально планируется, что с базой работает более чем один юзер? Пока один делает выборку - другому предлагается пойти покурить? Вряд-ли - скорее всего, я что-то крупно не понял в англицком...


Жесткий оффтопик:

И ещё - вымораживает, когда программисты (сам когда-то был таким) пишут в диалогах: "Не использовать выборку тра-ля-ля [v]". Т.е. положительный ответ (галка) несет отрицательный результат (не использовать). Ппц...
Напомнило - "Вы не придете сегодня на работу ?" - "Да. Не приду". Или "Нет. Не приду".
Тоже самое - с No_Save_WA=1. Да. Единица. Не использовать сохранение рабочих областей.

 Отправлено: 12.02.18 14:06. Заголовок: Pasha пишет: С Leto..

Pasha пишет:

цитата:

С Leto_ToggleZip(1) получилось резкое падение производительности: запустил 10 минут назад, и все жжжжжжжжддддддуууууууууууууу.

Чет явно не то...
Может Leto_ToogleZip(1) включил, а сервак был запущен - оригинальный, не форк ?

 Отправлено: 12.02.18 14:20. Заголовок: Там же протокол совс..

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

 Отправлено: 12.02.18 16:06. Заголовок: Sergy пишет: Паша, ..

Sergy пишет:

цитата:

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

Да, мне тоже интересны подробности работы этой настройки. Паша, если можно, просвети.

 Отправлено: 12.02.18 16:20. Заголовок: SergKis пишет: INDEX..

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 дает возможность подумать - может и обойдусь без индекса, раз данные будут шустро выбираться на сервере...