Форум » LetoDB, HbNetio. » Leto DB Server » Ответить
Leto DB Server
alkresin: Только что открыл на 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 на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
Pasha: Александр, не могу разобраться При открытии таблицы под 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
alkresin: Память под pArea->lpFields выделяется в верхнем слое RDD - workarea.c, hb_waSetFieldExtent() ( вызов SELF_SETFIELDEXTENT из letoOpen() ). Она может быть не выделена, если в вызове SELF_SETFIELDEXTENT стоит 0 полей - это может произойти, если неправильно интерпретированы данные с сервера. А может случиться, что память была выделена, но потом значение указателя чем-то затерто.
Pasha: Выяснил, что gpf возникает только на xHb CVS, на старой (июльской) весии ок Делаю scope, еще не постил. Передаю команду на сервер, и на сервере отрабатываю DBOI_SCOPETOP, DBOI_SCOPETOPCLEAR итд. Это правильный подход ? Еще не сбрасывал на CVS, проверяю Как лучше делать DBOI_KEYVAL ? Вычислять на клиенте или запрашивать с сервера ? Для DBOI_KEYSIZE думаю добавить еже один элемент в LETOTAGINFO. Правильно ? Увидел такую несовместимость. После OrdListAdd() в dbfdcx автотматически устанавливается 1-й индекс, а в letodb надо еще выдавать dbSetOrder(1)
alkresin: Нашел, в чем проблема со свежим 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. Правильно ? Угу.
Pasha: alkresin пишет: Учти, что на сервере открывается одна копия таблицы для всех, и если ты установишь там scope, то он и у других пользователей, использующих эту таблицу, появится - представляю себе их удивление :). Понятно. Я этого не заметил. Значит, буду делать по другому, так, как сделан bFilter Relations тоже прийдется отрабатывать на сервере
Pasha: alkresin пишет: Нашел, в чем проблема со свежим xHarbour. Вот она: 2008-01-10 11:47 UTC+0100 Miguel Angel Marchuet <miguelangel/at/marchuet.net> Он изменил базовую структуру rdd AREA, зараза! Я из-за этого не спешу использовать свежие сырцы. Появляются несоотсвествия с прежней структуроой заголовкка. Раньше допускались произвольные значения в резервных полях, а сейчас - результат непредсказуемый
alkresin: Не было там резервных полей. Он вставил новое поле до lpfields и 2 - после. Поэтому workarea.c присваивает значение lpfields, а у нас оно попадает в другое место, lpfields остается неинициализированным. И дело не в том, свежие сырцы или нет. Если б он это не сейчас сделал, а 3 месяца назад, какая разница ? Все равно - с одной версией работало б, с другой - нет. Придется, наверное, 2 экземпляра rddleto.h держать и примечание оставить для пользователей xHarbour > 10.01.08, чтоб переименовывали свое xrddleto.h в rddleto.h ...
Pasha: Добавил scope
Pasha: Добавил OrdKeyVal()
Pasha: Александр, я столкнулся с необходимостью проверять существование файла на сервере. Например, если есть файл 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), и сервер по ЛВС в одном флаконе
Pasha: Добавил LETO_FILE() - аналог File(), а также обработку OrdBugExt() и OrdNumber()
alkresin: Отлично! Я сам планировал эту функцию сделать, а, может, и другие файловые - в ADS мне их сильно не хватало. Вот только static int leto_DataSendRecv() по-моему, не стоило делать, надо использовать ту, что есть из leto1.c - избегаем дублирования кода и, главное, желательно, чтобы все функции, работающие непосредственно с сокетом, были собраны в одном месте - легче потом менять в случае чего. И насчет scope - я считаю, что нет нужды возвращать тип и значение scope с сервера, все это прекрасно клиент сам может определить, зачем же сервер зря утруждать ... Вообще, хорошо бы для сервера windows, да и для самбы сделать поиск IP-адреса по сетевому пути, если подключен сетевой диск. Это возможно ? Сделать то можно, раз ADS смогли :), но не знаю как. И, вообще-то, считаю это ненужным и даже вредным с точки зрения безопасности данных. Все известные мне DBMS используют имя сервера/ip, порт, имя базы и таблиц, для доступа к данным, а где именно хранится база, пользователь не знает и знать не должен - это важное преимущество подобных систем. У тебя никогда не случалось, что пользователь случайно удалял данные с сервера, просто щелкая мышкой по окну файлового менеджера ? У меня было ... Поэтому важно, чтобы каталог с данными не был расшарен - и то, что наш сервер позволяет скрыть данные, я считаю существенным преимуществом. А ADS позволяет это в силу исторических причин, он ведь начинался с версии для Novell 3.12 и IPX протокола.
Pasha: alkresin пишет: Вот только static int leto_DataSendRecv() по-моему, не стоило делать, надо использовать ту, что есть из leto1.c - избегаем дублирования кода и, главное, желательно, чтобы все функции, работающие непосредственно с сокетом, были собраны в одном месте - легче потом менять в случае чего. И насчет scope - я считаю, что нет нужды возвращать тип и значение scope с сервера, все это прекрасно клиент сам может определить, зачем же сервер зря утруждать ... ok, переделаю
Andrey: alkresin пишет: Поэтому важно, чтобы каталог с данными не был расшарен - и то, что наш сервер позволяет скрыть данные, я считаю существенным преимуществом. Поддерживаю обеими руками !!! Сколько я намучился с SHARED папками, это можно целые рассказы писать....
alkresin: Да, Pasha, поставь на letomgmn.c свой копирайт - ты же его original author.
Pasha: Есть вопрос, не относящийся к Leto DB Можно ли сделать локализацию самого компилятора ? Я пытался найти процедуру, проверяющую допустимость идентификатора, но безуспешно. Вернее, нашел, но не везде. Может быть, используются средства bison ? Для чего это надо. Например, при использовании Ole многие классы поддерживают поля и методы с русскими идентификаторами. Аналогично в dbf-файлах могут быть русские имена полей. Напрашивается добавить эти средства в сам компилятор, то есть добавить возможность сборки с определенной кодовой страницей Во многих языках уже есть поддержка национальных идентификаторов. Старые бастионы падают. Длинные идентификаторы, локализация... Почему не сделать такое и для харбора ?
alkresin: В смысле, названия переменных и полей db - на русском, или что-то еще ?
Pasha: alkresin пишет: В смысле, названия переменных и полей db - на русском, или что-то еще ? Да, и не более того. Сейчас на такие идентификаторы компилятор выдаст ошибку Leto. По поводу StoredProc: мысль такая. Подготовить модуль в виде hrb-файла на сервере По команде с клиента загружать-выгружать его. Отдельная команда на вызов функции из этого модуля с передачей параметров и возвратом результата На сервере перед вызовом функции из hrb устанавливать все окружение каждой открытой РО для этого пользователя: номер записи, фильтр итд. Запоминать это состояние. После отработки функции передавать на клиент кроме результата еще и новое состояние изменившихся РО. На клиенте его отрабатываеть Какие будут идеи ? Кстати, Pritpal Bedi не говорил, чем он собирается заниматься ? Чтобы мы не делали одно и тоже. Я, к примеру, думаю начать делать relations
Pasha: Только алиасы РО на сервере и на клиенте будут отличаться. Нужна будет функция для получения истинного алиаса
alkresin: Да, и не более того. Сейчас на такие идентификаторы компилятор выдаст ошибку Ну что тут сказать ... Если кто-то заинтересован в таком локализованном компиляторе, пусть делает. Подними этот вопрос в developer'ском листе - может, кто заинтересуется. Лично я как-то привык уже, что имена переменных, команд, функций - на английском, мне это кажется удобным - легко отличать их от текстовых строк на русском. А программа с русскими идентификаторами показалась бы, пожалуй, неудобочитаемой... С полями в база вопрос еще интереснее - тогда ведь программы на других xBase диалектах не смогут открыть такой файл. Я бы такими средствами локализации не пользовался. По stored procedures надо еще подумать. Может, стоит восстанавливать состояние РО после выполнения ? Сначала, мне кажется, надо реализовать схему запуска процессов и межпроцессного взаимодействия - мы же не будем выполнять их основным процессом, они могут быть достаточно длительными. Значит, загружать/выгружать hrb будет как раз тот дополнительный процесс. О намерениях Pritpal Bedi ничего не знаю, он со мной после запроса write access не контактировал. Сегодня, кстати, обратился Miguel Angel Marchuet ( он сейчас один из основных контрибуторов в xHarbour ? ) - я его сразу озадачил той проблемой с изменением workarea :). По алиасам - это предусмотрено: имя алиаса, как его знает клиент, передается из letoOpen() сразу после имени файла - т.е., должно передаваться, сейчас там пустая строка. И на сервере оно читается, но никак не используется. Надо будет создать HSArea:cAlias и присвоить ему это значение.
полная версия страницы