Отправлено: 31.01.08 11:36. Заголовок: Leto DB Server

Только что открыл на Sourceforge новый проект - Leto DB Server - https://sourceforge.net/projects/letodb

Это мультиплатформенный ( Windows, Unix/Linux ) сервер баз данных, предоставляющий клиентским программам доступ к dbf/cdx файлам, находящимся на удаленном сервере ( можно и на локальном компьютере запускать - в отладочных целях ). В общем, как ADS :).

Проект - на стадии разработки, не все даже базовые функции еще реализованы, до оптимизации дело еще не дошло. Но работает :).
Крутится у меня на сервере несколько дней, подключал до 15 клиентов, пока не падает. Мои программы работают с ним нормально.

Преимущества по сравнению с обычным файл-сервером:
1) Безопасность - базы могут быть в каталоге, недоступном для клиентских компьютеров - никто их случайно не удалит и не повредит.
2) Поскольку базы открываются серверной программой, а не клиентской, ее целостности ничего не грозит при случайном отключении клиентского компьютера.
3) значительное уменьшение сетевого траффика.
4) Должен быть, по идее, выигрыш в скорости.
5) Возможность контроля за пользователями с помощью утилиты manage ( можно придумать и другие формы контроля ).
6) Можно будет сделать транзакции, stored procedures на Харборе, ... и вообще все в наших руках :).

Кто хочет участвовать в разработке, тестировании - пишите.

 Отправлено: 01.02.08 21:15. Заголовок: Александр, не могу р..

Александр, не могу разобраться
При открытии таблицы под xHb на клиенте в leto1.c leto_ParseRec после строки 401
на pField = pArea->lpFields; происходит gpf при любом обращении к pField->any,
такое впечатление, что память не выделена под pArea->lpFields. xHarbour с CVS.
Еще одна мелочь. В console.prg замените ExeName() на HB_Argv(0), чтобы не
прилинковывать тулз. Я сам не стал, по changelog увидел, что модуль обновлялся
сегодня, а у меня еще версии 1.1

 Отправлено: 01.02.08 23:21. Заголовок: Память под pArea-..

Память под pArea->lpFields выделяется в верхнем слое RDD - workarea.c, hb_waSetFieldExtent() ( вызов SELF_SETFIELDEXTENT из letoOpen() ).
Она может быть не выделена, если в вызове SELF_SETFIELDEXTENT стоит 0 полей - это может произойти, если неправильно интерпретированы данные с сервера. А может случиться, что память была выделена, но потом значение указателя чем-то затерто.

 Отправлено: 02.02.08 10:34. Заголовок: Выяснил, что gpf воз..

Выяснил, что gpf возникает только на xHb CVS, на старой (июльской) весии ок
Делаю scope, еще не постил. Передаю команду на сервер, и на сервере отрабатываю
DBOI_SCOPETOP, DBOI_SCOPETOPCLEAR итд. Это правильный подход ? Еще не сбрасывал на CVS, проверяю
Как лучше делать DBOI_KEYVAL ? Вычислять на клиенте или запрашивать с сервера ?
Для DBOI_KEYSIZE думаю добавить еже один элемент в LETOTAGINFO. Правильно ?

Увидел такую несовместимость. После OrdListAdd() в dbfdcx автотматически устанавливается 1-й индекс, а в letodb надо еще выдавать dbSetOrder(1)

 Отправлено: 02.02.08 15:10. Заголовок: Нашел, в чем проблем..

Нашел, в чем проблема со свежим xHarbour. Вот она:

2008-01-10 11:47 UTC+0100 Miguel Angel Marchuet <miguelangel/at/marchuet.net>

Он изменил базовую структуру rdd AREA, зараза!

А в каждом RDD ( в т.ч. и у нас - rddleto.h ) эта структура дублируется, и в конце добавляются специфичные для этого RDD поля.
Что с этим делать, чтоб с предыдущими версиями xHarbour использовалась старая структура, а с новейшей - новая, я пока не знаю.

цитата:

Делаю scope, еще не постил. Передаю команду на сервер, и на сервере отрабатываю DBOI_SCOPETOP, DBOI_SCOPETOPCLEAR итд. Это правильный подход

В принципе, да, но этого недостаточно. Учти, что на сервере открывается одна копия таблицы для всех, и если ты установишь там scope, то он и у других пользователей, использующих эту таблицу, появится - представляю себе их удивление :).

цитата:

Как лучше делать DBOI_KEYVAL ? Вычислять на клиенте или запрашивать с сервера ?

На клиенте. Все, что можно, надо делать на клиенте, чтоб не загружать сервер лишней работой.

цитата:

Для DBOI_KEYSIZE думаю добавить еже один элемент в LETOTAGINFO. Правильно ?

Угу.

 Отправлено: 02.02.08 15:28. Заголовок: alkresin пишет: Учт..

alkresin пишет:

цитата:

Учти, что на сервере открывается одна копия таблицы для всех, и если ты установишь там scope, то он и у других пользователей, использующих эту таблицу, появится - представляю себе их удивление :).

Понятно. Я этого не заметил. Значит, буду делать по другому, так, как сделан bFilter
Relations тоже прийдется отрабатывать на сервере

 Отправлено: 02.02.08 15:32. Заголовок: alkresin пишет: Наш..

alkresin пишет:

цитата:

Нашел, в чем проблема со свежим xHarbour. Вот она: 2008-01-10 11:47 UTC+0100 Miguel Angel Marchuet <miguelangel/at/marchuet.net> Он изменил базовую структуру rdd AREA, зараза!

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

 Отправлено: 02.02.08 15:42. Заголовок: Не было там резервны..

Не было там резервных полей. Он вставил новое поле до lpfields и 2 - после. Поэтому workarea.c присваивает значение lpfields, а у нас оно попадает в другое место, lpfields остается неинициализированным.
И дело не в том, свежие сырцы или нет. Если б он это не сейчас сделал, а 3 месяца назад, какая разница ? Все равно - с одной версией работало б, с другой - нет.
Придется, наверное, 2 экземпляра rddleto.h держать и примечание оставить для пользователей xHarbour > 10.01.08, чтоб переименовывали свое xrddleto.h в rddleto.h ...

 Отправлено: 02.02.08 17:44. Заголовок: Добавил scope..

Добавил scope

 Отправлено: 02.02.08 21:53. Заголовок: Добавил OrdKeyVal()..

Добавил OrdKeyVal()

 Отправлено: 03.02.08 13:16. Заголовок: Александр, я столкну..

Александр, я столкнулся с необходимостью проверять существование файла на сервере. Например, если есть файл cdx - открывать его, если нет - индексировать

Сделал отдельный модуль на клиенте: letomgmt.c:

#include "hbapi.h"
#include "rddleto.h"


int leto_getIpFromPath( char * sSource, char * szAddr, int * piPort, char * szPath );
LETOCONNECTION * leto_ConnectionFind( char * szAddr, int iPort );
LETOCONNECTION * leto_ConnectionNew( char * szAddr, int iPort );
long int leto_Recv( HB_SOCKET_T hSocket );
char * leto_firstchar( void );
int leto_getCmdItem( char ** pptr, char * szDest );

static int leto_DataSendRecv( LETOCONNECTION * pConnection, char * sData, ULONG ulLen )
{
if ( hb_ipSend( pConnection->hSocket, sData, (ulLen)? ulLen:strlen(sData), -1, 1 ) <= 0 )
{
return 0;
}
return leto_Recv( pConnection->hSocket );
}

HB_FUNC( LETO_FILE )
{
LETOCONNECTION * pConnection;
char szFile[_POSIX_PATH_MAX + 1];
char szAddr[96];
int iPort;

if( ISCHAR(1) && leto_getIpFromPath( hb_parc(1), szAddr, &iPort, szFile ) &&
( ( pConnection = leto_ConnectionFind( szAddr, iPort ) ) ||
( pConnection = leto_ConnectionNew( szAddr, iPort) ) ) )
{
char szData[_POSIX_PATH_MAX + 16];

sprintf( szData,"file;%s;\r\n", szFile );

if ( !leto_DataSendRecv( pConnection, szData, 0 ) )
{
hb_retl( FALSE );
}
else
{
char * ptr = leto_firstchar();
leto_getCmdItem( &ptr, szData ); ptr ++;

hb_retl( szData[0] == 'T' );
}

}
else
hb_retl( FALSE );
}

снял static с используемых функций в leto1.c. Чтобы не добавлять LETO_FILE к rdd. Ok ?
Или организовать клиентскую библиотеку по другому ?
Сейчас отлаживаю

на сервере написал:

ELSEIF cItem == "file"
cReply := hs_file( oUser,Substr(cCommand,nPos1+1) )

...

Function hs_file( oUser,cCommand )
Local cFile, nPos := 1
IF Empty( cFile := GetCmdItem( cCommand,nPos,@nPos ) )
Return "-002"
ENDIF
Return "+" + File(oApp:DataPath+cFile)


Вообще, хорошо бы для сервера windows, да и для самбы сделать поиск IP-адреса по сетевому пути, если подключен сетевой диск. Это возможно ?
Было бы как в ADS
В целом, получается неплохо. И интернет-сервер (аналог AIS), и сервер по ЛВС в одном флаконе

 Отправлено: 03.02.08 19:40. Заголовок: Добавил LETO_FILE() ..

Добавил LETO_FILE() - аналог File(), а также обработку OrdBugExt() и OrdNumber()

 Отправлено: 03.02.08 22:27. Заголовок: Отлично! Я сам плани..

Отлично! Я сам планировал эту функцию сделать, а, может, и другие файловые - в ADS мне их сильно не хватало.
Вот только static int leto_DataSendRecv() по-моему, не стоило делать, надо использовать ту, что есть из leto1.c - избегаем дублирования кода и, главное, желательно, чтобы все функции, работающие непосредственно с сокетом, были собраны в одном месте - легче потом менять в случае чего.
И насчет scope - я считаю, что нет нужды возвращать тип и значение scope с сервера, все это прекрасно клиент сам может определить, зачем же сервер зря утруждать ...

цитата:

Вообще, хорошо бы для сервера windows, да и для самбы сделать поиск IP-адреса по сетевому пути, если подключен сетевой диск. Это возможно ?

Сделать то можно, раз ADS смогли :), но не знаю как. И, вообще-то, считаю это ненужным и даже вредным с точки зрения безопасности данных.
Все известные мне DBMS используют имя сервера/ip, порт, имя базы и таблиц, для доступа к данным, а где именно хранится база, пользователь не знает и знать не должен - это важное преимущество подобных систем. У тебя никогда не случалось, что пользователь случайно удалял данные с сервера, просто щелкая мышкой по окну файлового менеджера ? У меня было ... Поэтому важно, чтобы каталог с данными не был расшарен - и то, что наш сервер позволяет скрыть данные, я считаю существенным преимуществом.
А ADS позволяет это в силу исторических причин, он ведь начинался с версии для Novell 3.12 и IPX протокола.

 Отправлено: 03.02.08 22:53. Заголовок: alkresin пишет: Вот..

alkresin пишет:

цитата:

Вот только static int leto_DataSendRecv() по-моему, не стоило делать, надо использовать ту, что есть из leto1.c - избегаем дублирования кода и, главное, желательно, чтобы все функции, работающие непосредственно с сокетом, были собраны в одном месте - легче потом менять в случае чего. И насчет scope - я считаю, что нет нужды возвращать тип и значение scope с сервера, все это прекрасно клиент сам может определить, зачем же сервер зря утруждать ...

ok, переделаю

 Отправлено: 04.02.08 11:14. Заголовок: alkresin пишет: Поэ..

alkresin пишет:

цитата:

Поэтому важно, чтобы каталог с данными не был расшарен - и то, что наш сервер позволяет скрыть данные, я считаю существенным преимуществом.

Поддерживаю обеими руками !!! Сколько я намучился с SHARED папками, это можно целые рассказы писать....

 Отправлено: 04.02.08 11:20. Заголовок: Да, Pasha, поставь н..

Да, Pasha, поставь на letomgmn.c свой копирайт - ты же его original author.

 Отправлено: 04.02.08 11:43. Заголовок: Есть вопрос, не отно..

Есть вопрос, не относящийся к Leto DB
Можно ли сделать локализацию самого компилятора ?
Я пытался найти процедуру, проверяющую допустимость идентификатора, но безуспешно. Вернее, нашел, но не везде. Может быть, используются средства bison ?
Для чего это надо. Например, при использовании Ole многие классы поддерживают поля и методы с русскими идентификаторами. Аналогично в dbf-файлах могут быть русские имена полей. Напрашивается добавить эти средства в сам компилятор, то есть добавить возможность сборки с определенной кодовой страницей
Во многих языках уже есть поддержка национальных идентификаторов. Старые бастионы падают. Длинные идентификаторы, локализация... Почему не сделать такое и для харбора ?

 Отправлено: 04.02.08 13:05. Заголовок: В смысле, названия п..

В смысле, названия переменных и полей db - на русском, или что-то еще ?

 Отправлено: 04.02.08 13:17. Заголовок: alkresin пишет: В с..

alkresin пишет:

цитата:

В смысле, названия переменных и полей db - на русском, или что-то еще ?

Да, и не более того. Сейчас на такие идентификаторы компилятор выдаст ошибку

Leto. По поводу StoredProc: мысль такая. Подготовить модуль в виде hrb-файла на сервере
По команде с клиента загружать-выгружать его. Отдельная команда на вызов функции из этого модуля с передачей параметров и возвратом результата
На сервере перед вызовом функции из hrb устанавливать все окружение каждой открытой РО для этого пользователя: номер записи, фильтр итд.
Запоминать это состояние. После отработки функции передавать на клиент кроме результата еще и новое состояние изменившихся РО. На клиенте его отрабатываеть
Какие будут идеи ?

Кстати, Pritpal Bedi не говорил, чем он собирается заниматься ? Чтобы мы не делали одно и тоже.
Я, к примеру, думаю начать делать relations

 Отправлено: 04.02.08 13:52. Заголовок: Только алиасы РО на ..

Только алиасы РО на сервере и на клиенте будут отличаться. Нужна будет функция для получения истинного алиаса

 Отправлено: 04.02.08 15:16. Заголовок: Да, и не более того...

цитата:

Да, и не более того. Сейчас на такие идентификаторы компилятор выдаст ошибку

Ну что тут сказать ... Если кто-то заинтересован в таком локализованном компиляторе, пусть делает. Подними этот вопрос в developer'ском листе - может, кто заинтересуется. Лично я как-то привык уже, что имена переменных, команд, функций - на английском, мне это кажется удобным - легко отличать их от текстовых строк на русском. А программа с русскими идентификаторами показалась бы, пожалуй, неудобочитаемой... С полями в база вопрос еще интереснее - тогда ведь программы на других xBase диалектах не смогут открыть такой файл. Я бы такими средствами локализации не пользовался.

По stored procedures надо еще подумать. Может, стоит восстанавливать состояние РО после выполнения ? Сначала, мне кажется, надо реализовать схему запуска процессов и межпроцессного взаимодействия - мы же не будем выполнять их основным процессом, они могут быть достаточно длительными. Значит, загружать/выгружать hrb будет как раз тот дополнительный процесс.

О намерениях Pritpal Bedi ничего не знаю, он со мной после запроса write access не контактировал. Сегодня, кстати, обратился Miguel Angel Marchuet ( он сейчас один из основных контрибуторов в xHarbour ? ) - я его сразу озадачил той проблемой с изменением workarea :).

По алиасам - это предусмотрено:

имя алиаса, как его знает клиент, передается из letoOpen() сразу после имени файла - т.е., должно передаваться, сейчас там пустая строка.
И на сервере оно читается, но никак не используется. Надо будет создать HSArea:cAlias и присвоить ему это значение.