Автор | Сообщение |
|
| постоянный участник
|
Пост N: 1362
Зарегистрирован: 27.01.07
|
|
Отправлено: 21.01.18 10:31. Заголовок: LetoDb fork
|
|
|
Новых ответов нет
, стр:
1
2
3
4
5
6
7
All
[см. все]
|
|
|
| Администратор
|
Пост N: 3671
Зарегистрирован: 23.05.05
|
|
Отправлено: 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) нужен" стоит как бы наоборот: "зачем нужен второй ?".
|
|
|
|
| постоянный участник
|
Пост N: 1368
Зарегистрирован: 27.01.07
|
|
Отправлено: 12.02.18 16:34. Заголовок: Pasha пишет: Почита..
Pasha пишет: цитата: | Почитайте эту старую тему: |
| Я читал ее. Но она как-то затухла. Поэтому остались вопросы.
|
|
|
|
| Администратор
|
Пост N: 3672
Зарегистрирован: 23.05.05
|
|
Отправлено: 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 ).
|
|
|
|
| постоянный участник
|
Пост N: 1730
Зарегистрирован: 17.02.12
|
|
Отправлено: 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 ..., а простыми переключениями тэгов отображаются таблицы в разных разрезах
|
|
|
|
| постоянный участник
|
Пост N: 1369
Зарегистрирован: 27.01.07
|
|
Отправлено: 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 )" применимо к оригиналу?) Нет ли возможности выяснить, допилил ли Александр это?
|
|
|
|
| |
Пост N: 597
Зарегистрирован: 08.07.06
|
|
Отправлено: 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 ? Что-то скорее всего, я не догоняю...
|
|
|
|
| постоянный участник
|
Пост N: 1731
Зарегистрирован: 17.02.12
|
|
Отправлено: 12.02.18 17:34. Заголовок: Вроде так было: No_S..
Вроде так было: No_Save_WA = 0 - идет оптимизация открытий таблиц, одна таблица, открытая несколькими клиентами открывается один раз в области WA при No_Save_WA = 1 каждый запрос на открытие любой таблицы получает новую область WA А.Кресин занимался доводкой этого режима, кто то сильно тестировал и был положительный результат
|
|
|
|
| постоянный участник
|
Пост N: 1370
Зарегистрирован: 27.01.07
|
|
Отправлено: 12.02.18 20:59. Заголовок: Только Александр Кре..
Только Александр Кресин может ответить, видимо...
|
|
|
|
| |
Пост N: 598
Зарегистрирован: 08.07.06
|
|
Отправлено: 13.02.18 00:02. Заголовок: SergKis пишет: Смыс..
SergKis пишет: цитата: | Смысл в том, что нет выборок типа select * from ..., а простыми переключениями тэгов отображаются таблицы в разных разрезах |
| Сергей, спасибо за разъяснения. Никогда не пользовался UNIQUE индексами, нужно будет посмотреть на них гораздо пристальнее.
|
|
|
|
| Администратор
|
Пост N: 3673
Зарегистрирован: 23.05.05
|
|
Отправлено: 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. Какой режим лучше - надо тестировать. Я этим не занимался. Ну и вопрос "а нахрена вообще такой-то режим" наверное задавать не стоит. Для нас "мамы всякие нужны, мамы всякие важны". Наверное что-то лучше будет работать в первом режиме, а что-то во втором.
|
|
|
|
| Администратор
|
Пост N: 3674
Зарегистрирован: 23.05.05
|
|
Отправлено: 13.02.18 10:11. Заголовок: Sergy пишет: Сергей..
Sergy пишет: цитата: | Сергей, спасибо за разъяснения. Никогда не пользовался UNIQUE индексами, нужно будет посмотреть на них гораздо пристальнее. |
| А есть еще индексы с условием for, тоже удобная штука. Поддерживаются и в ntx, и в cdx
|
|
|
|
|
| Администратор
|
Пост N: 3675
Зарегистрирован: 23.05.05
|
|
Отправлено: 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 скачивал вчера
|
|
|
|
| постоянный участник
|
Пост N: 1371
Зарегистрирован: 27.01.07
|
|
Отправлено: 13.02.18 11:11. Заголовок: Pasha пишет: Ну дав..
Pasha пишет: цитата: | Ну давайте еще раз разжуем режим No_Save_WA. |
| Спасибо за разъяснения. Остался один вопрос: доделал ли Кресин режим "1".
|
|
|
|
| Администратор
|
Пост N: 3676
Зарегистрирован: 23.05.05
|
|
Отправлено: 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.
|
|
|
|
| постоянный участник
|
Пост N: 1732
Зарегистрирован: 17.02.12
|
|
Отправлено: 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() считаю обязательным в таблицах задач.
|
|
|
|
| Администратор
|
Пост N: 3677
Зарегистрирован: 23.05.05
|
|
Отправлено: 13.02.18 13:34. Заголовок: Прогнал тест по сети..
Прогнал тест по сети. LetoDB (клиент bcc, не пересобирал) - 184 сек LetoDBf + mingw32: несжатые пакеты 121 сек сжатые пакеты 110 сек
|
|
|
|
| постоянный участник
|
Пост N: 1372
Зарегистрирован: 27.01.07
|
|
Отправлено: 13.02.18 15:51. Заголовок: Это большая разница...
Это большая разница.
|
|
|
|
| Администратор
|
Пост N: 3678
Зарегистрирован: 23.05.05
|
|
Отправлено: 14.02.18 08:55. Заголовок: SergKis пишет: Нали..
SergKis пишет: цитата: | Наличие тега для доступа к удаленным записям INDEX ON ID ... FOR Deleted() считаю обязательным в таблицах задач. |
| Я при удалении записи полностью ее очищаю. Так что удаленные записи оказываются по индексу всегда "сверху". И обхожусь без дополнительного тега.
|
|
|
|
| постоянный участник
|
Пост N: 1733
Зарегистрирован: 17.02.12
|
|
Отправлено: 14.02.18 10:10. Заголовок: Pasha пишет И обхожу..
Pasha пишет цитата: | И обхожусь без дополнительного тега. |
| В записи есть поля ID_DTM_ADD, ID_DTM_MOD, ID_DTM_DEL отражающие TimeStamp (C или @ типов), запись никогда не очищается (длительность действия год) как и идентификатор записи - все это государственно отчетные показатели. Организация тэгов, как показано выше, позволила упростить запросы по отчетности (лог журналы тоже есть - они уже для доп. разбирательств). Да и для внутр. исп. тэг по удаленным оказался полезным, начальнику любого уровня глянуть на browse что где наколбасили.
|
|
|
|
| Администратор
|
Пост N: 3679
Зарегистрирован: 23.05.05
|
|
Отправлено: 14.02.18 10:28. Заголовок: SergKis пишет: В за..
SergKis пишет: цитата: | В записи есть поля ID_DTM_ADD, ID_DTM_MOD, ID_DTM_DEL отражающие TimeStamp (C или @ типов), запись никогда не очищается |
| Это же неиндескные поля, для индекса их значение до лампочки. Может у вас задача другая ? У меня если запись удалена, она просто используется для добавления новых из пула удаленных. Схема простая: go top, если первая запись удалена и индексное выражение пустое - она используется, если нет - то dbAppend
|
|
|
Новых ответов нет
, стр:
1
2
3
4
5
6
7
All
[см. все]
|
|