Здравствуйте, Sinclair, Вы писали:

S>2. Скоро до нас должен доехать превью Yukon от MS. Есть мнение, что в него можно запихивать почти произаольный .NET код, что вызывает неудержимое желание набросать маппер из объектной модели в него, который уже будет поддерживать 11 требований.

Гы . Вобще то юкон, судя по синтаксису, один черт может вернуть только датасет. Т.е. запуск нетовского кода выглядит так:
select * from DotNetClass

Здравствуйте, Morgun, Вы писали:

M>Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного.

Orion это Orion Application Server?

Здравствуйте, Sinclair, Вы писали:

S>Ну давай посмотрим. Дла сверхкоротких запросов такая ситуация может иметь место, но таких запросов в конечной системе не может быть много. Для оптимизации фазы синтаксического разбора все современные СУБД предоставляют двухстадийный механизм — подготовку стейтмента, и собственно выполнение. Между первой и второй стадиями могут менять параметры, и вторую стадию можно выполнять многократно.

Еще есть ХП, которые тоже храняться в прекомпилированном виде.

Здравствуйте, Serginio1, Вы писали:

S>>Подходы — нужны. Иначе зачем монстрам развивать свои продукты?
S> Может Net сдвинет эту скалу.

Java пока не сдвинула.

Здравствуйте, AndrewVK, Вы писали:
AVK>А чем это будет принципиально отличаться от EJB, если не секрет?
Ну, вообще-то я написал в реферате список требований. Насколько я знаю, никакая реализация их не удовлетворяет. Если я ошибаюсь — можно меня ткнуть.
В частности, я не видел ни одного сервера, который умеет что-то типа

ISomeEntity[] entities = DB.Select("ISomeEntity.IntVirtualMethod1()<60");

Все, что можно кверить — это поля. Что является вопиющим нарушением инкапсуляции.

Здравствуйте, AndrewVK, Вы писали:

AVK>Гы . Вобще то юкон, судя по синтаксису, один черт может вернуть только датасет. Т.е. запуск нетовского кода выглядит так:
AVK>select * from DotNetClass
Ну, вроде как так писать нельзя
Я пока что понял следующее:
1. Сторед процедуры можно будет писать на дотнете. При этом они могут делать все, что угодно, и даже возвращать resultset на клиента — точь-в-точь как обычные процедура на T-SQL. Но они должны быть статическими методами класса.
2. Функции теперь можно писать на дотнете. Причем как скалярные, так и датасетные. С теми же особенностями. Отличия — будет поддерживаться статистика и индексирование по функциям.
3. В сервере теперь можно хранить value-типы, в дополнение к встроенным.

Вот, в общем-то, и все. Никаких from DotNetClass писать нельзя, если только DotNetClass не имя таблицы или view. Дальше пока спекулировать смысла нету — надо щупать ево за мягкие места. А то, как известно, при смешивании килограмма повидла с килограммом дерьма получается два килограмма дерьма.

Здравствуйте, Sinclair, Вы писали:

S>Вот, в общем-то, и все. Никаких from DotNetClass писать нельзя, если только DotNetClass не имя таблицы или view.

Или функция, которая может быть дотнетным классом .

Здравствуйте, AndrewVK, Вы писали:
AVK>Или функция, которая может быть дотнетным классом .
А как это функция может быть дотнетным классом?

Здравствуйте, Sinclair, Вы писали:

S>В частности, я не видел ни одного сервера, который умеет что-то типа
S>

S>ISomeEntity[] entities = DB.Select("ISomeEntity.IntVirtualMethod1()<60");

S>

Все, что можно кверить — это поля. Что является вопиющим нарушением инкапсуляции.

в cachё можно методы класса в запросах использовать.

Здравствуйте, Sinclair, Вы писали:

S>В частности, я не видел ни одного сервера, который умеет что-то типа
S>

S>ISomeEntity[] entities = DB.Select("ISomeEntity.IntVirtualMethod1()<60");
S>

Все, что можно кверить — это поля. Что является вопиющим нарушением инкапсуляции.

Насколько я помню в EJB 2.0 добавлен язык запросов, EJB-QL. В частности селект имеет такой синтаксис:

SELECT OBJECT(variable)
FROM abstractSchemaName [AS] variable
[WHERE value comparison value]

где value:

The value can be a parameter, the result of a numeric or string function, a variable (e.g. hotel), a member inside this variable separated using the dot '.' operator (e.g. hotel.name), or a constant (e.g. 'Pleasant Inn', 23, TRUE).

Так что, насколько я понимаю, все EJB 2.0 compatible сервера должны такое уметь.

Здравствуйте, Sinclair, Вы писали:

AVK>>Или функция, которая может быть дотнетным классом .
S>А как это функция может быть дотнетным классом?

Ну как — функцию в юконе можно написать на дотнете.

Здравствуйте, AndrewVK, Вы писали:

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

Здравствуйте, _MarlboroMan_, Вы писали:
_MM_>в cachё можно методы класса в запросах использовать.
Еще раз — это статические невиртуальные методы! Кроме того, это не интерфейсы, а классы.

Здравствуйте, AndrewVK, Вы писали:

AVK>Так что, насколько я понимаю, все EJB 2.0 compatible сервера должны такое уметь.
А вот как у них интересно с производительностью таких запросов?
Если там реализована нормальная инкапсуляция, тгда кждое сравнение — это новый вызов метода, и индекс фиг построишь...

Здравствуйте, AndrewVK, Вы писали:
AVK>Насколько я помню в EJB 2.0 добавлен язык запросов, EJB-QL. В частности селект имеет такой синтаксис:

AVK>

AVK>SELECT OBJECT(variable)
AVK>FROM abstractSchemaName [AS] variable
AVK>[WHERE value comparison value]

AVK>где value:
AVK>

AVK>The value can be a parameter, the result of a numeric or string function, a variable (e.g. hotel), a member inside this variable separated using the dot '.' operator (e.g. hotel.name), or a constant (e.g. 'Pleasant Inn', 23, TRUE).

AVK>Так что, насколько я понимаю, все EJB 2.0 compatible сервера должны такое уметь.
Ну, все ODMG 1.0 совместимые сервера тоже должны такое уметь. Именно поэтому пока что никто не может похвастаться такой совместимостью. Как только увидишь хотя бы один, который и вправду может выполнить запрос по виртуальному методу — свистни, а?

Здравствуйте, AndrewVK, Вы писали:

AVK>Ну как — функцию в юконе можно написать на дотнете.
Ну да. Но только она тогда будет статическим мембером класса. Что не есть класс. Когда я пишу select * from EmployeeClass, то я ожидаю, что инстансы EmployeeClass будут объектами "сотрудник". А фактически мы имеем просто некоторую функцию, которая где-то взяла какой-то рекрдсет и отдает его нам. При этом надо понять, что она никак не может вернуть "коллекцию дотнетовских классов". Она может вернуть набор записей, некоторые поля которых суть дотнет классы.

Здравствуйте, Merle, Вы писали:

M>Если там реализована нормальная инкапсуляция, тгда кждое сравнение — это новый вызов метода, и индекс фиг построишь...

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

Здравствуйте, Sinclair, Вы писали:

S>Ну, все ODMG 1.0 совместимые сервера тоже должны такое уметь. Именно поэтому пока что никто не может похвастаться такой совместимостью.

Нет, я к тому чтобы тебе хотя бы в архитектурном плане велосипедов не изобретать. А реализацию ты можешь конечно и свою придумать.

S>Как только увидишь хотя бы один, который и вправду может выполнить запрос по виртуальному методу — свистни, а?

ОК

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, AndrewVK, Вы писали:

AVK>>Ну как — функцию в юконе можно написать на дотнете.
S>Ну да. Но только она тогда будет статическим мембером класса. Что не есть класс. Когда я пишу select * from EmployeeClass, то я ожидаю, что инстансы EmployeeClass будут объектами "сотрудник". А фактически мы имеем просто некоторую функцию, которая где-то взяла какой-то рекрдсет и отдает его нам.

Так и я о том же — юкон в деле создания OODBMS сильно не поможет, просто позволит проще писать ХП.

Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, я к тому чтобы тебе хотя бы в архитектурном плане велосипедов не изобретать. А реализацию ты можешь конечно и свою придумать.
Я согласен. Вот только за 10 лет этот велосипед никто не сделал. Может, от того что постановка задачи неверна? Вот я и хочу пересмотреть это все.