Ada_Ru форум

Обсуждение языка Ада

Re: [ada_ru] Интерфейс к MYSQL

Оставить новое сообщение

Сообщения

Vadim Godunko
Re: [ada_ru] Интерфейс к MYSQL
2008-01-06 14:12:49

Dmitry A. Kazakov wrote:

On Mon, 17 Dec 2007 11:49:31 +0300, you wrote:

 

Dmitry A. Kazakov wrote:

 

GNADE ODBC с MySQL определенно работает, я его использую для реализации

persistence layer-a.

 

А можно про persistence layer поподробне?

 

Это часть simple components:

 

http://www.dmitry-kazakov.de/ada/components.htm#persistent_objects

 

Одна из реализаций "abstract persistent storage" построена на GNADE ODBC и

работает со всем, что может ODBC. Я тестировал ее на MySQL, PostgreSQL

(Windows, Linux) и MS Access (только Windows).

 

Спасибо!

 

А Вы не пробовали обдумывать идею orthogonal persistence? (Это когда сохранение/восстановление состояния объектов происходит незаметно для клиентсткой программы)

On Sun, 06 Jan 2008 17:12:49 +0300, you wrote:

 

А Вы не пробовали обдумывать идею orthogonal persistence? (Это когда сохранение/восстановление состояния объектов происходит незаметно для клиентсткой программы)

 

Разумеется. В принципе, только один корневой объект должен иметь имя, все остальные могут тянуться за ним. Если persistent объект ссылается на не persistent, то последний сохраняется и восстанавливается автоматом. Или что-то другое?

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

On Sun, 06 Jan 2008 17:12:49 +0300, you wrote:

 

А Вы не пробовали обдумывать идею orthogonal persistence? (Это когда сохранение/восстановление состояния объектов происходит незаметно для клиентсткой программы)

 

Разумеется. В принципе, только один корневой объект должен иметь имя, все

остальные могут тянуться за ним. Если persistent объект ссылается на не

persistent, то последний сохраняется и восстанавливается автоматом. Или

что-то другое?

 

Я видимо не совсем точно выразился :-(

 

Под "незаметно для клиентской программы" подразумевалось что классы приложения не наследуются от какого-то предопределённого класса, равно как и не имею методов типа Load/Save, Seialize/Deserialize.

 

Максимально что требуется от программы что бы устойчиво сохранить объект - открыть сессию и указать объекты для устойчивого хранения. Всё остальное осуществляется уже средствами библиотеки.

 

Совсем в таком виде сделать нельзя (в Ada нет "корневого" типа а-ля any или Object). Но искать всё же можно, например с помощью generic.

On Sun, 06 Jan 2008 17:52:34 +0300, you wrote:

 

Dmitry A. Kazakov wrote:

 

On Sun, 06 Jan 2008 17:12:49 +0300, you wrote:

 

А Вы не пробовали обдумывать идею orthogonal persistence? (Это когда сохранение/восстановление состояния объектов происходит незаметно для клиентсткой программы)

 

Разумеется. В принципе, только один корневой объект должен иметь имя, все остальные могут тянуться за ним. Если persistent объект ссылается на не persistent, то последний сохраняется и восстанавливается автоматом. Или что-то другое?

 

Я видимо не совсем точно выразился :-(

 

Под "незаметно для клиентской программы" подразумевалось что классы приложения не наследуются от какого-то предопределённого класса, равно как и не имею методов типа Load/Save, Seialize/Deserialize.

 

Максимально что требуется от программы что бы устойчиво сохранить объект - открыть сессию и указать объекты для устойчивого хранения. Всё остальное осуществляется уже средствами библиотеки.

 

Совсем в таком виде сделать нельзя (в Ada нет "корневого" типа а-ля any или Object). Но искать всё же можно, например с помощью generic.

 

На самом деле, достаточно было бы множественного наследования. Можно так же попробовать Storage_Pool, который инжектирует необходимые данные при размещении объектов в нем. В тех же components так сделаны списки.

Проблема в другом. Только сам объект знает как себя сохранить. Так что прозрачность иллюзорна, все равно, нужно Load/Save иметь. Если, положим, 'Input/'Output Stream атрибуты использовать, так чем они лучше чем Load/Save?

 

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

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

Проблема в другом. Только сам объект знает как себя сохранить. Так что

прозрачность иллюзорна, все равно, нужно Load/Save иметь. Если, положим,

'Input/'Output Stream атрибуты использовать, так чем они лучше чем

Load/Save?

 

Это можно было-бы решить введением некоторого описания отображения свойств объекта на базу данных. Тогда возможно сделать универсальную реализацию Load/Save: зная какой тип имеет объект получаем значения атрибутов и сохраняем их в базе/загружаем значения из базы и конструируем объект.

 

Описание такое можно делать с использованием директив компилятора или просто отдельных файлов.

 

Я для получения/установки значений совйств объекта сделать некоторое подобие reflection.

On Mon, 11 Feb 2008 13:29:30 +0300, you wrote:

 

Dmitry A. Kazakov wrote:

 

Проблема в другом. Только сам объект знает как себя сохранить. Так что прозрачность иллюзорна, все равно, нужно Load/Save иметь. Если, положим, 'Input/'Output Stream атрибуты использовать, так чем они лучше чем Load/Save?

 

Это можно было-бы решить введением некоторого описания отображения свойств объекта на базу данных. Тогда возможно сделать универсальную реализацию Load/Save: зная какой тип имеет объект получаем значения атрибутов и сохраняем их в базе/загружаем значения из базы и

конструируем объект.

 

Это бы означало, что не Ада программа описывает объекты, а некое загадочное описание, которое вроде-бы и Ада, а может, и нет. В какой мере "не-Ада" будет влиять на объект в Аде?

 

Описание такое можно делать с использованием директив компилятора или просто отдельных файлов.

 

Разумеется. Но принципиально это автоматически ограничивало бы семантику того, что может быть сохранено к тому, что может быть описано. Далее такой вопрос, при наличии расхождений между семантикой объекта в Аде и ее же, но как по-описанию, кто, как, и когда мог бы это заметить?

 

Вообще, я не люблю языки в языках. Ада уже имеет два мета-языка: прагмы и generics. Ничего хорошего от такого рода решений я не жду. Если уж расширять язык, то следовало бы рассматривать проблему "абстрагирования представления объекта" на уровне языка, а не заплаток к нему. В-принципе, какие-то зачатки в виде атрибутов встроенных типов существуют. Скорее всего, это должно вести к first-class типам, значения которых, и есть желаемые описания, тупо пихаемые в базу. Если есть значения, то можно было бы их трансформировать, т.е. приводить типы. Так что, если отображение свойств понимать как преобразование значения типа, то да, согласен. Возражение по-существу в том, что к одним атрибутам это, скорее всего, не сводимо. На счет директив компилятора, так, - лирика.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти