Yo.!пересказывать, что утверждалось, когда есть текст на предыдущей странице мне лень. еще раз, теперь что я имел ввиду фразой "процедурный код сторед процедуры на SQLJ выполняются сторонней жава машиной, которая о принятых в SQL DB2 правилах не в курсе" надеюсь ясно ?Не надейтесь, не ясно. Даже после того, как Вам стало лень :)
Еще раз - ни одна JVM о правилах SQL не в курсе. Т.к. любой SQL выполняется движком SQL, а Java-код - JVM.
По поводу фразы - процедурный код Java SP в любом случае выполняется какой-то JVM, а собственно SQLJ-вставки в него, т.е. #sql директивы - в любом случае выполняются движком SQL. Или Оракл JVM сама SQL выполняет, без собственно Oracle Database? :)
Поэтому что сторонняя Java машина, что своя - о правилах SQL конкретной СУБД должен знать SQLJ препоцессор, с СУБД поставляемый, а вовсе не сама JVM.
Кстати, с DB2 всегда в комплекте поставляется именно IBM JVM.
Yo.!по мне так спроектированная под нужды субд, интегрированная в структуру SGA JVM существенно отличается от работающей во внешнем процессе JVM общего назначения.Уже обсуждали, так что замнем для ясности :) В любом случае, к выполнению SQLJ все это никакого отношения не имеет.
Yo.!не выполняется. там создается такой же profile как и в дб2, структура этого profile файлика описана в стандарте. просто перед созданием profile валидируется SQL...
1. все то же самое, что и у дб2, все согласно стандарту. к статик SQL прислоняется любая JVM, рядом кладутся profile, только JDBC через который дергается база зовется чуть по другому.
У DB2 - совсем не так. Разница в том, что в DB2 создается package не только в виде стандартного файлика, а как объект внутри БД, содержащий все запросы SQLJ. И объект этот валидируется с последующими изменениями в БД, и может стать инвалидным, запретив выполнение ставшей "неправильной" SP. JDBC при этом вообще не используется, у них с SQLJ просто общий универсальный драйвер, но внутри драйвера механизмы разные.
Yo.!2. не совместимая со стандартом загрузка SQLJ как единое целое в субд, где выполняется под интегрированной в ядро JVM. второй вариант естественно гораздо быстрее. думаю тут просто SQLJ транслируется в обычную Java stored procedure. вот они, по моему, имеют такие же зависимости как и pl/sqlХотелось бы поглядеть на какую-либо инфу по варианту 2. Я в свое время искал на тему SQLJ по доке Оракла, но ничего похожего не видел.
Yo.!возвращаясь к нашим нулам: для меня выглядит дико когда говорят, что когда я обрабатываю нулл языком сторед процедур, то это один нулл, а когда я обрабатываю ту же сущность из той же таблицы, из того же поля но уже на уровне апп-сервера это уже какой-то другой нулл.И что делать, если это действительно разные нуллы в разных языках? В JDBC, чтобы не было путаницы, даже функцию wasNull() ввели. Не isNull(), чтобы не было нездоровых ассоциаций :)
Да, в SQLJ, в отличие от JDBC, можно использовать Java null для индикации SQL NULL. ИМХО, это неправильно и путает - хороший шанс получить в лоб эксепшн в рантайме при случайном использовании простых типов в хост-переменных.
Лучше по-старинке пользоваться indicator переменными . Меньше путаницы будет.