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

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

 Отправлено: 12.02.18 16:30. Заголовок: Почитайте эту старую..

Почитайте эту старую тему:
http://clipper.borda.ru/?1-7-0-00000037-000-0-0-1486290536

В режиме No_Save_WA = 0, а этот режим является основным для letodb, сервер не открывает для каждого клиента одну и ту же таблицу, а использует одну и туже pArea, если таблица уже открыта. Соответственно сервер делает не физическую блокировку записи ли таблицы, а логическую.
Для No_Save_WA = 1 для каждой команды use с клиента сервер открывает свою копию рабочей области, и соответственно выполняет уже физические блокировки. Этот режим считался в letodb экспериментальным, я сам его никогда не использовал, и не скажу, допилил ли его Александр в конце концов.

В letodbf похоже основным сделан режим No_Save_WA = 1. Но точно я не скажу.
Так что для меня вопрос: "зачем самый "первый" режим (когда No_Save_WA = 0) нужен" стоит как бы наоборот: "зачем нужен второй ?".

 Отправлено: 12.02.18 16:34. Заголовок: Pasha пишет: Почита..

Pasha пишет:

цитата:

Почитайте эту старую тему:

Я читал ее. Но она как-то затухла. Поэтому остались вопросы.

 Отправлено: 12.02.18 16:46. Заголовок: В конце концов, смот..

В конце концов, смотрим доку:

LetoDB:

No_Save_WA = 0 - Когда этот режим установлен, при каждом вызове dbUseArea()
сервер действительно открывает файл и создает новую рабочую
область (workarea) - в режиме по умолчанию каждый
файл открывается сервером только один раз и образуется одна
реальная рабочая область для этого файла для всех клиентов.
Теоретически это режим может увеличить производительность
при большом количестве активных клиентов, но он недостаточно
тестировался, поэтому для рабочих приложений рекомендуется
использовать режим по умолчанию.

LetoDBf:

No_Save_WA = 1 - server mode of internally handling database tables
1 each dbUseArea() will cause a real file open operation by the OS,
identical to what client requested, so workareas at the server are same as
at client side. [ WA number, alias, filter conditions, relations ]
0 each table is opened only one time, this workarea 'exchanged' in between client
requests. so only one connection will have access to the table at a time.
No relations active at server, Alias names at server are different from
the client.
Recommend '1' if you plan to execute functions at server side ( UDF ).

 Отправлено: 12.02.18 16:59. Заголовок: Sergy пишет Не очень..

Sergy пишет

цитата:

Не очень понятен смысл примера...

Смысл в том, что введенные unique тэги уже являются готовой выборкой, переключив та тэг
INDEX ON KODTER ... UNIQUE // реал. список территорий в информации (в справочнике может быть стопятсот тыс. позиций)
SetOrdFocus('KODTR')
GO TOP
tbrowse(...) // связав со справочником территорий и взяв наименование и ...
имеем список реальных территорий, где можем поставить галочку\выбрать - для получения списка клиентов этой территории, т.е.
INDEX ON KODTER+CLIENT ... UNIQUE // реал. список клиентов на выбранной территории
SetOrdFocus('KODTER_CLI')
SET SCOPE TO cKodTer, cKodTer
GO TOP
tbrowse(...) // реал. список клиентов территории, связав со справочником клиентов берем наименование и ...
отмечаем галками\выбором нужных клиентов и у нас готовы параметры запроса для тэга
INDEX ON KODTER+CLIENT ... // список всех территорий по клиентам в информации
вот тут и выполняем запрос по установкам выше. территория+клиенты, помеченные галкой.
период я отбросил для упрощения примера.

цитата:

Поэтому мне не очень понятен смысл в 44 тегах/индексах

Смысл в том, что нет выборок типа select * from ..., а простыми переключениями тэгов отображаются таблицы в разных разрезах

 Отправлено: 12.02.18 17:07. Заголовок: Pasha пишет: В конц..

Pasha пишет:

цитата:

В конце концов, смотрим доку: LetoDB: No_Save_WA = 0 - Когда этот режим установлен, при каждом вызове dbUseArea() сервер действительно открывает файл и создает новую рабочую область (workarea) - в режиме по умолчанию каждый файл открывается сервером только один раз и образуется одна реальная рабочая область для этого файла для всех клиентов.

Сто раз смотрел)) Формулировка уж какая-то нечёткая)
Совпадает ли поведение letodb и letodbf при одинаковых установках этого параметра?
Как 0 или 1 отражается на выполнении udf? (это "Recommend '1' if you plan to execute functions at server side ( UDF )" применимо к оригиналу?)
Нет ли возможности выяснить, допилил ли Александр это?

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

Pasha пишет:

цитата:

В конце концов, смотрим доку: LetoDB: No_Save_WA = 0 - Когда этот режим установлен, при каждом вызове dbUseArea() сервер действительно открывает файл и создает новую рабочую область (workarea) - в режиме по умолчанию каждый файл открывается сервером только один раз и образуется одна реальная рабочая область для этого файла для всех клиентов. Теоретически это режим может увеличить производительность при большом количестве активных клиентов, но он недостаточно тестировался, поэтому для рабочих приложений рекомендуется использовать режим по умолчанию.

Сорри, для непонятливых:

Для LetoDb (не форк):

"Когда режим установлен": No_Save_WA = 1 ??
"Режим по умолчанию": No_Save_WA = 0 ?

Для обоих версий:
Если No_Save_WA = 0 - в каждый момент времени таблицей может пользоваться только один клиент:

цитата:

so only one connection will have access to the table at a time

???

Зачем такой режим нужен в принципе? Ведь заявлено, что "теоретически может дать прирост производительности при большом количестве клиентов". Получается, что-то типа USE table EXCLUSIVE ?
Что-то скорее всего, я не догоняю...

 Отправлено: 12.02.18 17:34. Заголовок: Вроде так было: No_S..

Вроде так было:
No_Save_WA = 0 - идет оптимизация открытий таблиц, одна таблица, открытая несколькими клиентами открывается один раз в области WA
при No_Save_WA = 1 каждый запрос на открытие любой таблицы получает новую область WA
А.Кресин занимался доводкой этого режима, кто то сильно тестировал и был положительный результат

 Отправлено: 12.02.18 20:59. Заголовок: Только Александр Кре..

Только Александр Кресин может ответить, видимо...

 Отправлено: 13.02.18 00:02. Заголовок: SergKis пишет: Смыс..

SergKis пишет:

цитата:

Смысл в том, что нет выборок типа select * from ..., а простыми переключениями тэгов отображаются таблицы в разных разрезах

Сергей, спасибо за разъяснения. Никогда не пользовался UNIQUE индексами, нужно будет посмотреть на них гораздо пристальнее.

 Отправлено: 13.02.18 09:59. Заголовок: PSP пишет: Только А..

PSP пишет:

цитата:

Только Александр Кресин может ответить, видимо...

Ну давайте еще раз разжуем режим No_Save_WA.
Пусть два клиента открывают одну и ту же таблицу.
Как это делается в режиме No_Save_WA = 0
Поток для 1-го клиента выполняет команду use в монопольном режиме. Поток для 2-го не делает use, а разделяет уже открытую таблицу с 1-м потоком. Причем запросы к таблице от обеих клиентов выполняются без задержки, одновременно.

В режиме No_Save_WA = 1 поток для 1-го клиента выполняет команду use shared. Поток для 2-го - аналогично, т.е на сервере эта таблица открыта два (несколько) раз.
Для letodb 1-й режим - основной, в работе оба режима отличаются способом блокировки: в 1-м выполняется логическая виртуальная блокировка, то есть создаются списки блокированных записей, во втором - блокировка средствами rdd.
Ну и во втором режиме поскольку таблицы открыты как shared, их может открыть стороннее приложение.

В letodbf основным является 2-й режим, ну и в нем судя по всему реализованы еще дополнительные возможности, я уже упоминал серверные relations.

Какой режим лучше - надо тестировать. Я этим не занимался.
Ну и вопрос "а нахрена вообще такой-то режим" наверное задавать не стоит. Для нас "мамы всякие нужны, мамы всякие важны". Наверное что-то лучше будет работать в первом режиме, а что-то во втором.

 Отправлено: 13.02.18 10:11. Заголовок: Sergy пишет: Сергей..

Sergy пишет:

цитата:

Сергей, спасибо за разъяснения. Никогда не пользовался UNIQUE индексами, нужно будет посмотреть на них гораздо пристальнее.

А есть еще индексы с условием for, тоже удобная штука. Поддерживаются и в ntx, и в cdx

 Отправлено: 13.02.18 10:43. Заголовок: Sergy пишет: Не виж..

Sergy пишет:

цитата:

Не вижу в тексте Leto_ToggleZip(1)

Не работает совсем этот Leto_ToggleZip. Тест зависает на первом use
В логе найдено:

02.13.2018 10:39:57 INFO: connected 127.0.0.1:51141 test_db.exe CP: EN DF: dd/mm/yy conn-ID 0
02.13.2018 10:40:01 ERROR thread2() leto_SockRec != ulRecvLen
02.13.2018 10:40:01 INFO: disconnect 127.0.0.1:51141 test_db.exe users=(1 : 1 : 1), tables=(0 : 0)

Сервер собран с harbour 3.2 + mingw64
Клиент harbour 3.2 + bcc55
letodbf скачивал вчера

 Отправлено: 13.02.18 11:11. Заголовок: Pasha пишет: Ну дав..

Pasha пишет:

цитата:

Ну давайте еще раз разжуем режим No_Save_WA.

Спасибо за разъяснения. Остался один вопрос: доделал ли Кресин режим "1".

 Отправлено: 13.02.18 12:17. Заголовок: Pasha пишет: Не раб..

Pasha пишет:

цитата:

Не работает совсем этот Leto_ToggleZip. Тест зависает на первом use

Ага, нашел, где собака порылась:

readme.txt
BCC55 and maybe also newer ones have a problem with compiling LZ4 compression library, you will
get this case slower ZLib compression. This must fit together for client lib and server when you
want to use network traffic compression. It is configured by this "{!bcc}" at top in the ".hbp" files.

 Отправлено: 13.02.18 12:58. Заголовок: Pasha пишет Ну и во ..

Pasha пишет

цитата:

Ну и во втором режиме поскольку таблицы открыты как shared, их может открыть стороннее приложение.

С No_Save_WA = 0 получить режим shared для таблиц можно, поставив в ini Share_Tables = 1, т.е. таблицы может открывать стороннее приложение.

цитата:

А есть еще индексы с условием for,

Замечание правильное. В индексных выражениях условие FOR я подразумевал обязательным, т.е.
INDEX ON KODTER ... FOR ! Deleted() UNIQUE
...
работа с инф. тэга не зависит от режима SET DELETAD ON\OFF подключенного модуля.
Что еще добавлять в FOR это уже по ситуации.
Наличие тега для доступа к удаленным записям
INDEX ON ID ... FOR Deleted()
считаю обязательным в таблицах задач.

 Отправлено: 13.02.18 13:34. Заголовок: Прогнал тест по сети..

Прогнал тест по сети.
LetoDB (клиент bcc, не пересобирал) - 184 сек
LetoDBf + mingw32:
несжатые пакеты 121 сек
сжатые пакеты 110 сек

 Отправлено: 13.02.18 15:51. Заголовок: Это большая разница...

Это большая разница.

 Отправлено: 14.02.18 08:55. Заголовок: SergKis пишет: Нали..

SergKis пишет:

цитата:

Наличие тега для доступа к удаленным записям INDEX ON ID ... FOR Deleted() считаю обязательным в таблицах задач.

Я при удалении записи полностью ее очищаю. Так что удаленные записи оказываются по индексу всегда "сверху".
И обхожусь без дополнительного тега.

 Отправлено: 14.02.18 10:10. Заголовок: Pasha пишет И обхожу..

Pasha пишет

цитата:

И обхожусь без дополнительного тега.

В записи есть поля ID_DTM_ADD, ID_DTM_MOD, ID_DTM_DEL отражающие TimeStamp (C или @ типов), запись никогда не очищается (длительность действия год) как и идентификатор записи - все это государственно отчетные показатели. Организация тэгов, как показано выше, позволила упростить запросы по отчетности (лог журналы тоже есть - они уже для доп. разбирательств). Да и для внутр. исп. тэг по удаленным оказался полезным, начальнику любого уровня глянуть на browse что где наколбасили.

 Отправлено: 14.02.18 10:28. Заголовок: SergKis пишет: В за..

SergKis пишет:

цитата:

В записи есть поля ID_DTM_ADD, ID_DTM_MOD, ID_DTM_DEL отражающие TimeStamp (C или @ типов), запись никогда не очищается

Это же неиндескные поля, для индекса их значение до лампочки. Может у вас задача другая ? У меня если запись удалена, она просто используется для добавления новых из пула удаленных. Схема простая: go top, если первая запись удалена и индексное выражение пустое - она используется, если нет - то dbAppend