[oodisc] Re: Проект OpenOffice и "решения"

Dmitry Sorokin ds на ics.elcom.ru
Ср Дек 25 11:53:27 MSK 2002


On Wed, 25 Dec 2002, Raoul & Natalia Nakhmanson-Kulish wrote:

> Allin punchaw qampaq, Dmitry!
>
> В твоем письме от 25 декабря 2002 г., 9:54:51, нам удалось
> вычитать:
>
> DS> Посмотрел письмо в архиве. Ваш Wishes List интересует.
> Повторимся :)
> Вот что мы хотели бы видеть от Front End Database Tool (пусть
> условно
> это называется так, сокращенно FEDT).

Если рассматривать GnuEnterprise то по пунктам:

>
> 1. FEDT должна быть не самостоятельной базой данных, а лишь
> интерфейсом к существующим БД.

Да.

>
> 2. FEDT должна иметь DB Abstraction Layer, который
> предоставлял бы
> возможность использовать стандартный SQL-92 и некоторые
> популярные
> расширения SQL-99 (хранимые процедуры, BLOB). Некоторые
> функции,
> скажем, получение списка таблиц в базе, реализованы в разных
> базах
> по-разному, FEDT должна приводить их к общему знаменателю. То
> же
> справедливо в отношении наименования типов данных -
> программист
> сможет, например, использовать по стандарту NCHAR VARYING (n),
> не
> беспокоясь о том, что, например, в MSSQL это NVARCHAR (n), а в
> SAP -
> VARCHAR (n) UNICODE.
>

Возможно несколько специализированный, но DB Abstraction Layer есть.
Поскольку проект на Python, DB AL реализуется поверх стандартного Python
DB2 API. Introspection позволяющая получать мета информацию из базы
данных поддерживается насколько это возможно и необходимо (в основном
для Gnue Designer). Будет конструктор схем, когда из одного описания
можно сгенерить скрипты под любую базу данных из поддерживаемых. Сейчас
можно сгенерить для postgres, возможно mysql и oracle, если вручную
расписать схему в gsd-формате (gnue schema definition). Поскольку с
хранимыми процедурами переносимость можно потерять следующий этап это
перенос бизнес логики на application server (в стадии
написания-переписывания).


> То есть в результате FEDT станет кроссплатформенным и
> кросс-СУБДшным
> инструментом, позволяющим создавать легко переносимые проекты.
>

Да. Есть binary build для win32 с включенными драйверами для mysql,
postgres, interbase, возможно db2 и sapdb

> Возможно, в дальнейшем развитие DB Abstraction Layer приведет
> к тому,
> что он станет сервисом, предоставляющим интерфейс к
> виртуальной БД,
> которая приводит любую конкретную физическую БД к общему
> знаменателю.

DB AL вынесен в библиотеку Gnue Common которой будет пользоваться и сам
Application Server насколько это возможно и в итоге Application
Server со стороны форм представляется одним из вариантов хранилища данных
т.е. DB.

> 4. И последнее. Cамый мощный инструмент в Access - это,
> безусловно,
> формы. Хотелось бы видеть в FEDT возможность создания
> произвольных по
> сложности форм с обработкой их макроязыком (например, типа OO
> BASIC).
>

Самый мощный в gnue инструмент это Gnue Forms :)
Произвольные формы описанные в формате XML.
Любая обработка данных на стороне клиента через триггеры привязанные к
интерфейсным элементам и типам событий. Язык написания - python.

С уважением,
Дмитрий Сорокин





Подробная информация о списке рассылки Oo-discuss