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

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

 Отправлено: 14.02.18 10:29. Заголовок: PS letodb с триггеро..

PS
letodb с триггером, оказался ОЧЕНЬ полезным для решения этих задач.

 Отправлено: 14.02.18 10:37. Заголовок: Pasha пишет У меня е..

Pasha пишет

цитата:

У меня если запись удалена, она просто используется для добавления новых из пула удаленных

Так очищать запись нельзя и повторно использовать тоже. Если так делать, надо городить огород на текстовые логи для добывания инф. для проверяющих организаций. Скажу так, ВСЕ клиенты не хотят проверяющим давать инф. из этих логов, у проверяющих есть начальные данные (их системы) и им надо дать конечные, без промежуточных

 Отправлено: 14.02.18 10:49. Заголовок: PS Выделенный на зап..

PS
Выделенный на запись ID не должен повторно использоваться в течении года. Модификация по ID записи возможна, отражается в ID_DTM_MOD и user кто делал, при удалении запись "замораживается"

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

Pasha пишет:

цитата:

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

Спасибо за разъяснения.
Очень прошу не расценивать мои слова "а зачем такой режим вообще нужен" как персональное оскорбление. Просто у меня вызвала недоумение цитата Рольфа:

цитата:

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

Поэтому и не мог понять, в чем смысл. Нужно будет попробовать потестировать. Жаль, что в данном режиме не поддерживается прямое указание алиасов для полей таблиц. У меня с давних времен все компилируется с опцией -m, поэтому все поля во всех выражения, в тч фильтрах и relation всегда идут только с алиасом.

 Отправлено: 14.02.18 13:52. Заголовок: Sergy пишет У меня с..

Sergy пишет

цитата:

У меня с давних времен все компилируется с опцией -m, поэтому все поля во всех выражения, в тч фильтрах и relation всегда идут только с алиасом.

В чем "выгода" от применения алиаса для тек. обл. в уст. filtra ?
Со времен S87 с -m этого не делаю, в 5.2 какое то время писал определения FIELD ..., потом "забыл" и _FIELD->... так же не использую - все прекрасно понимается, для переменных памяти исп. венгерскую запись.
Для однообразного кода (это на любителя) отказался и от SET RELATION, перейдя на подводы с анализом - неудобств в связи с этим не испытал, а иногда и выигрывал, когда с течением времени, надо было менять алгоритм подвода, не нашли тут, делаем др. подводы или ищем в др. алиасах.
Когда много критериев для отбора (сложный фильтр), использую массив блоков кода для каждого критерия и если "условно" все элементы, выполненные по Eval, дадут .T. => запись в отборе.

 Отправлено: 14.02.18 14:36. Заголовок: SergKis пишет: Так ..

SergKis пишет:

цитата:

Так очищать запись нельзя и повторно использовать тоже. Если так делать, надо городить огород на текстовые логи для добывания инф. для проверяющих организаций. Скажу так, ВСЕ клиенты не хотят проверяющим давать инф. из этих логов, у проверяющих есть начальные данные (их системы) и им надо дать конечные, без промежуточных

У вас проверяющие в базах копаются, что ли ? Жесть.

 Отправлено: 14.02.18 14:45. Заголовок: Pasha пишет У вас пр..

Pasha пишет

цитата:

У вас проверяющие в базах копаются, что ли ? Жесть.

Сами не лезут, просят выгрузить в excel то то и то то, с ID, ID_DTM_ADD, ID_DTM_MOD, ID_DTM_DEL + ID_DTM_ANULIR (анулированные докум.). Ежемесячно для них форм. xml файлы для загрузки в eds систему (по налогам контролируют), маленькие фирмы вводят руками документы в эту систему, к примеру, через хром.

 Отправлено: 14.02.18 14:51. Заголовок: PS Когда просят выгр..

PS
Когда просят выгрузить, в лучшем случае сидят в соседней комнате или стоят над "душой", т.е. формировать надо быстро.

 Отправлено: 14.02.18 14:54. Заголовок: PPS Раньше проявлять..

PPS
Раньше проявлять сделки с клиентом, надо было при превышении 1000 eur за месяц, сейчас со 150 eur.

 Отправлено: 14.02.18 15:01. Заголовок: До чего дошел прогре..

До чего дошел прогресс :)

 Отправлено: 14.02.18 15:36. Заголовок: SergKis пишет Модифи..

SergKis пишет

цитата:

Модификация по ID записи возможна, отражается в ID_DTM_MOD и user кто делал, при удалении запись "замораживается"

А запись с пометкой удаленная? И делаете ли Вы когда-нибудь PACK?

 Отправлено: 14.02.18 16:33. Заголовок: ZAlex пишет А запись..

ZAlex пишет

цитата:

А запись с пометкой удаленная? И делаете ли Вы когда-нибудь PACK?

Да, запись с пометкой удаленная и команда PACK не используется от слова никогда.
Есть еще понятие свободная\занятая запись (осталась от времен S87), когда записи в таблицу добавляются страницей, к примеру по 300 (из ini установки берется) записей за раз. Но пока не определился оставлять этот механизм или нет для letodb.

 Отправлено: 15.02.18 12:40. Заголовок: SergKis пишет: В че..

SergKis пишет:

цитата:

В чем "выгода" от применения алиаса для тек. обл. в уст. filtra ?

Х.е.з., если честно. Это "сейчас" есть умный Харбор, а "тогда" нужна была четкая и полная уверенность в том, что переменная в каком-нибудь выражении не перепутается с именем поля. Поэтому для себя решил, что -m будет дисциплинировать и я не поленюсь добавлять к имени поля название алиаса. Со временем я оценил "лишний труд" и это дало определенные плоды: при модификации имен/типов/размеров полей простым текстовым поиском по исходникам можно легко найти и внести изменения в тех местах, которые могут затронуть эти изменения.

 Отправлено: 16.02.18 10:09. Заголовок: PSP пишет: Это боль..

PSP пишет:

цитата:

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

Я случайно заметил, что в letodb.ini, который идет с LetoDBf, стоит параметр:
Cache_Records = 21

Так что тест выполнялся в неравных условиях.
Добавил в тест вызов leto_SetSkipBuffer(21)

Собрал тест с letoDB + mingw32, чтобы условия были совсем уж равными.
Результат по сети - 123 сек, что практически совпадает с тестом LetoDBf
Тест для LetoDBf кстати собирал с флажком -mt, чтобы задействовать преимущество использования двух портов.

Я даже несколько обескуражен результатом. Конечно, может быть новшества LetoDBf сыграют в каких-то других условиях, тест то больно простой.

 Отправлено: 16.02.18 10:16. Заголовок: Это хорошо) У меня п..

Это хорошо)
У меня программа с letodbf в некоторых местах падает с GPF 0xc0000005 ACCESS VIOLATION.
Не могу найти причину. Пока нет времени разбираться. С оригинальным letodb всё нормально.

 Отправлено: 16.02.18 10:38. Заголовок: Pasha пишет Конечно,..

Pasha пишет

цитата:

Конечно, может быть новшества LetoDBf сыграют в каких-то других условиях, тест то больно простой.

Мои ощущения, letoDBf поведением приближен к стандартному rdd (+SIXCDX), добавлено поведение SBM сервера и попытка перенести public\private переменные (синхронизацией, кешированием) на сторону сервера, для использования в filtrах и т.д.
Даст это прирост скорости или нет - это не первостепенный вопрос.

 Отправлено: 16.02.18 10:47. Заголовок: SergKis пишет: попы..

SergKis пишет:

цитата:

попытка перенести public\private переменные (синхронизацией, кешированием) на сторону сервера, для использования в filtrах и т.д.

Хоть я не разбирался, для синхронизации нужен принудительный вызов Leto_VarExprSync ? При этом все значения public/private передаются на сервер, что ли ?
Не очень понятно, зачем это все нужно. Предположим, в строке для фильтра есть использование переменной памяти. При изменении значения переменной фильтр должен менять поведение, что ли ?
Я избегаю использовать переменные памяти, предпочитаю local/static. Фильтры, которые после установки динамически изменялись бы, мне не нужны. Это какая-то экзотика.
Сконструировать строку для фильтра, задав в ней нужные параметры, не составляет особой проблемы. И зачем городить этот огород ?

 Отправлено: 16.02.18 10:53. Заголовок: Pasha пишет Сконстру..

Pasha пишет

цитата:

Сконструировать строку для фильтра, задав в ней нужные параметры, не составляет особой проблемы. И зачем городить этот огород ?

Полностью согласен. С какой целю сделано, не ясно.

 Отправлено: 16.02.18 11:11. Заголовок: Глянул Leto_VarExprS..

Глянул Leto_VarExprSync.
Есть массив синхронизируемых переменных. Клиент хранит для каждой значение предыдущей синхронизации.
Если значение изменилось, на сервер передается команда LetoVarSet
Если изменилось значение скажем 20-ти переменных - будет 20 команд.
Как бы можно было бы обойтись одной, сделать что-то вроде LetoVarsSet.

 Отправлено: 16.02.18 11:13. Заголовок: PSP пишет У меня про..

PSP пишет

цитата:

У меня программа с letodbf в некоторых местах падает с GPF 0xc0000005 ACCESS VIOLATION. Не могу найти причину

Судя по Changelog.txt сборки пекутся как пирожки, т.е. сыровато еще состояние