Комментарии 23
Ваш логотип прочитал сначала как Perl Danger. После прочтения статьи понял, что не ошибся.
plackup -p 5000 bin/app.psgi # запускаем сервер
А сервер при этом какой используется? Апач/нгинх или свой, перловый,
из https://metacpan.org/dist/Plack/view/script/plackup:
If no option is given, plackup will try to detect the best server implementation based on the environment variables as well as modules loaded by your application in
%INC
plackup - это просто запускалка. Сервер по умолчанию, в большинстве случаев - это Starman. Всего их есть много, для разных задач и на любой вкус - https://plackperl.org
Разумеется, в продакшене перед этим следует ставить что-то типа nginx.
Делал как-то sql-over-http для Oracle базы, так ни один из языков прослойки (python/php/lua) не смог отдать полностью бооольшой выхлоп от базы. Только DBI-Oracle смог справиться с этой задачей как и N-цать лет назад..
Вообще странно. Использование курсоров, фетчинг данных пачкой и что стримить в респонз + flush - этого должно быть достаточно и доступно во всех наверное языках, кто имеет коннекторы к Ораклу.
Разве что с их подсистемой памяти (GC) могут быть нюансы.
не знаю как там с другими языками, но в случае с php вам как минимум нужно
отключить буфферизацию в PDO (или какой там драйвер вы используете)
отключить буфферизацию ответа самого php (ob_... функции)
отключить буфферизацию сервера (например, для nginx
fastcgi_buffering off;)
вы уверены, что выполнили хотя бы эти действия?
Тем не менее это факт, можете сами проверить. Да и не забывайте, что Oracle сама по себе оооочень странная BD. Так что, рановато ещё perl хоронить — откапывайте.
Здесь Oracle не причем. Дело либо в драйвере к нему, либо в клиентском коде.
Он у вас, случайно, не остался?
Здесь Oracle не причем.
Ни кто не утверждал что он причем. Странная СУБД Oracle - это да, но не ....
Дело либо в драйвере к нему, либо в клиентском коде.
Ну да, ну да. libclntsh.so во всех случаях одна и та же. Код проще некуда: connect/preparee/execute и последующий json. Но виноват кто угодно только не язык реализации коннектора.
Из тех кто завелись с первого раза и без каких либо вопросов/твиков - это DBI-Perl и JDBC. Возиться и подкручивать что то в драйвере языка-реализации(кроме lua, с ним повозился) не было ни желания ни времени, а с java'ой я не очень дружу. Да и DBI-Oracle просто работает.
P.S.
Сильно разочаровал lua, так как окружение openresty, то хотелось обойтись штатными средствами, но видать не судьба.
С первого раза завелись DBI-Perl и JDBC потому как это "тупые клиенты" к БД.
А в Python и PHP вы использовали фреймворки поверх них с кучей функционала. И этот функционал заточен под другие основные сценарии. Тем не менее, с помощью конфигурации можно и ваш запрос реализовать.
С первого раза завелись DBI-Perl и JDBC потому как это "тупые клиенты" к БД.
Что значит "тупые клиенты", почитайте POD по DBD/DBI, ознакомьтесь хотя бы с 10% его функционала что бы такое утверждать.
Тем не менее, с помощью конфигурации можно и ваш запрос реализовать.
Я не знаю какие танцы с бубном возле либы у вас практикуются, но у нас хоца что бы просто работало, а вот если где-то что-то неординарное, то можно и покрутить, но не наоборот.
del
Небольшая поправка. Книга "Learning Perl, 8th Edition" написана, отправлена в печать, но ещё не выпущена. Амазон честно пишет "This title has not yet been released"
В свое время Dancer был первым моим фреймворком на Perl(а он был первым промышленным языком). Сколько воды утекло...
Dancer2 или современное web-приложение на PERL