Предупреждение в yy_find_shift_action очень похоже на ложное срабатывание. Если бы они хотели проверить тем условием границы индеса, то не было бы assert далее, разве нет?
Согласен, что не всегда получается все написать на чистом SQL. Хотя, в общем случае, SQL всегда должен быть быстрее динамики.
По поводу доработки функции — так вы ее еще бесконечно будете дорабатывать, а со вью такого не было бы. И не используйте like как вы предлагаете, вы так потеряете индекс на department_id и все станет медленным (а еще само условие там некорректное). Лучше разбить строку и делать непосредственный join уже по pk.
В общем, все что я хотел сказать своим первым комментарием — пример некорректный и кто-то может ошибочно подумать, что pipelined-функции хорошо так использовать.
Если у вас 1000 подразделений вы будете 1000 запросов выполнять? Думаю, будет что-то такое все-таки:
select dep.department_id, avg(emp.salary_recom) as avg_salary from hr.departments dep cross join table (hr.test.get_employees_dep(dep.department_id)) emp group by dep.department_id
И как вы считаете, производительность тут не упадет?
Oracle может очень сложные запросы обрабатывать, если их правильно написать. Хотя, тут от случая к случаю, конечно.
Описанный пример значительно лучше реализовать в виде вьюхи. С вьюхой, например, потом можно было бы не напрягаясь посчитать среднюю зарплату по всем подразделениям, а с такой функцией никак, придется новую писать. И хорошим плюсом было бы сохранение индексов для планировщика.
Вероятность того, что за N бросков выпадет только решка, равна 2^(-N). Вероятность того, что за N бросков выпадет только решка, когда N-1 бросков уже сделаны и выпадала только решка, равна 2^(-1),
Во-первых, можно реализовать на стандартном g_fxx, он для этого и нужен.
Во-вторых, по каждому клику происходит целых два запроса к серверу, причем оба запроса асинхронные и второй не ждет завершения первого.
В-третьих, зачем там вообще обновление региона?
Если-таки изобретать велосипед, то думаю, не проще, но правильнее было бы класть состояния чекбоксов в json и отправлять через apex.ajax.clob непосредственно перед самим действием и по before refresh, а запрос переписать с нативным парсингом этого json из clob_content. Либо, если не хочется парсить json на лету, можно отправить в свой процесс и так же по коллекции разложить. Если совсем не хочется json, то можно все отправить в процесс в тех же g_fxx. А можно не изобретать велосипед.
Хм, а может это не лучшая идея просто игнорировать возвращенное значение? Ведь функция все-таки зачем-то вызывается. Мне кажется, стоило проверить, что на самом деле не так…
Кроме того, я не вижу, как функция явным образом меняет eax, да и код функции приведен не весь (куда ведет je 0x7fffe288d568?)
Далеко не всегда при добавлении экстраполятора нулевого порядка в контур система будет устойчива, лишь в том случае, если корни замкнутой дискретной системы будут внутри единичного круга. Может случиться так, что для непрерывной модели коэффициенты работают, а для дискретной — нет.
Если мы закрыли stdin/stdout/stderr, то нужно открыть их хотя бы в /dev/null, иначе при следующем open() мы попадем на стандартный дескриптор, а это вроде как не есть хорошо.
Согласен, что не всегда получается все написать на чистом SQL. Хотя, в общем случае, SQL всегда должен быть быстрее динамики.
По поводу доработки функции — так вы ее еще бесконечно будете дорабатывать, а со вью такого не было бы. И не используйте
likeкак вы предлагаете, вы так потеряете индекс на department_id и все станет медленным (а еще само условие там некорректное). Лучше разбить строку и делать непосредственныйjoinуже по pk.В общем, все что я хотел сказать своим первым комментарием — пример некорректный и кто-то может ошибочно подумать, что pipelined-функции хорошо так использовать.
И как вы считаете, производительность тут не упадет?
Oracle может очень сложные запросы обрабатывать, если их правильно написать. Хотя, тут от случая к случаю, конечно.
Во-вторых, по каждому клику происходит целых два запроса к серверу, причем оба запроса асинхронные и второй не ждет завершения первого.
В-третьих, зачем там вообще обновление региона?
Если-таки изобретать велосипед, то думаю, не проще, но правильнее было бы класть состояния чекбоксов в json и отправлять через apex.ajax.clob непосредственно перед самим действием и по before refresh, а запрос переписать с нативным парсингом этого json из clob_content. Либо, если не хочется парсить json на лету, можно отправить в свой процесс и так же по коллекции разложить. Если совсем не хочется json, то можно все отправить в процесс в тех же g_fxx. А можно не изобретать велосипед.
Кроме того, я не вижу, как функция явным образом меняет eax, да и код функции приведен не весь (куда ведет je 0x7fffe288d568?)
viktprog[ ~ ]$ ./fail
[ 637.380714] VFS: file-max limit 25112 reached
viktprog[ ~ ]$
Под рутом так же завершается почти сразу
Opera 10.70 (3483)