Доступен (https://blog.couchdb.org/2018/12/06/2-3-0/) релиз распределённой документ-ориентированной базы данных Apache CouchDB 2.3.0 (http://couchdb.apache.org/downloads.html), относящейся к классу NoSQL-систем. Исходные тексты проекта распространяются (http://couchdb.apache.org/downloads.html) под лицензией Apache 2.0.В новом выпуске устранена (https://seclists.org/oss-sec/2018/q4/255) уязвимость (CVE-2018-17188 (https://security-tracker.debian.org/tracker/CVE-2018-17188)), позволяющая удалённо поднять свои привилегии в системе (пользователь с правами администратора СУБД может получить доступ к окружению операционной системы с правами пользователя, под которым запускается CouchDB). Так как за последние два года это пятая уязвимость, связанная изменением конфигурации СУБД во время работы (ранее были исправлены похожие уязвимости CVE-2018-8007 (http://docs.couchdb.org/en/stable/cve/2018-8007.html), CVE-2018-11769 (http://docs.couchdb.org/en/stable/cve/2018-11769.html), CVE-2017-12636 (http://docs.couchdb.org/en/stable/cve/2017-12636.html) и 2017-12635 (http://docs.couchdb.org/en/stable/cve/2017-12635.html)), разработчики Apache CouchDB приняли решение (https://blog.couchdb.org/2018/12/17/cve-2018-17188/) полностью запретить изменение ключевых настроек СУБД через API. Настройки теперь могут быть изменены только при наличии shell-доступа к серверу.
Улучшения, реализованные в Apache CouchDB 2.3.0:
- Добавлена поддержка кластерной очистки (http://docs.couchdb.org/en/2.3.0/cluster/purging.html#cluste... (clustered purge), позволяющая полностью удалить из БД любой документ (удалённый или не удалённый) с любым числом ревизий и конфликтов;
- Реализована новая настройка (seedlist), позволяющая администратору задать начальный список узлов, к которым новый узел должен обратиться на этапе запуска. Узды из данного списка, в случае доступности, автоматически будут добавлены в БД _nodes и использованы для репликации внутренних системных БД;
- Добавлена возможность репликации с обращением к пирам, доступным только по IPv6;
- Возвращено старое поведение CouchDB 1.x, связанное с указанием UUID сервера/кластера в ответе на запрос "GET /";
- В реализации операции пакетного выполнения запроса (_bulk_get) появилась поддержка типов контента multipart/mixed и multipart/related;
- Прекращено жёсткое задание размера буфера TCP для приёма данных (ранее устанавливался в 256KB), что позволяет операционной системе динамически корректировать размер буфера. Данное изменение существенно увеличило производительность передачи по сети больших вложений;- Упрощено включение SSL в файле конфигурации, теперь достаточно создать секцию "[ssl]" с опцией "enable = true";
- Все скрипты, написанные на языке Python, включая couchup и dev/run, для своего выполнения отныне требуют наличия Python 3.x;
- Обеспечена совместимость с Erlang 21.x.- Встраиваемая версия инструментария rebar (https://github.com/rebar/rebar), используемого для сборки CouchDB, обновлена до последней версии ветки rebar2, что улучшило поддержку сборки на платформах, отличных от x86.
Напомним, что CouchDB хранит данные в формате упорядоченного списка и позволяет производить частичную репликацию данных между несколькими БД в режиме «мастер-мастер» с одновременным обнаружением и разрешением конфликтных ситуаций. Каждый сервер хранит свой локальный набор данных, синхронизированный с другими серверами, которые могут переводиться в offline-режим и периодически реплицировать изменения. В частности, данная возможность делает CouchDB привлекательным решением для организации синхронизации настроек программ между разными компьютерами. Решения на базе CouchDB внедрены в таких компаниях как BBC, Apple и CERN.
Запросы к CouchDB и индексация данных могут выполняться в соответствии с парадигмой MapReduce (http://ru.wikipedia.org/wiki/MapReduce), используя для формирования логики выборки данных язык JavaScript. Ядро системы написано на языке Erlang, оптимизированного для создания обслуживающих множество параллельных запросов распределенных систем. View-сервер написан на языке Си и базируется на JavaScript-движке от проекта Mozilla. Доступ к БД производится при помощи протокола HTTP с использованием RESTful JSON API, что позволяет обращаться к данным в том числе из выполняемых в браузере web-приложений.В качестве единицы хранения данных выступает документ, имеющий уникальный идентификатор, версию и содержащий произвольный набор именованных полей в формате ключ/значение. Для организации псевдо-структурированного набора данных из произвольных документов (агрегирования и формирования выборок) применяется концепция формирования представлений (view), для определения которых используется язык JavaScript. На JavaScript также можно определять функции для проверки корректности данных при добавлении новых документов в рамках определенного представления.
URL: https://seclists.org/oss-sec/2018/q4/255
Новость: https://www.opennet.me/opennews/art.shtml?num=49798
Для тех, кто не осилил SQL.
Угу, вот только обычно SQL осилить проще чем очередной нескучный синатксис носкуэли.
>Угу, вот только обычно SQL осилить проще чем очередной нескучный синатксис носкуэли.SQL как и HTML это языки не для программистов, а околокомпутерного сброда.
У нормального программиста многостраничные портянки с RANK да PARTITION BY вызывает батхёрт.
Ещё и под каждую РСУБД совершенно свой велоси^W синтаксис.Посему все живые проекты на РСУБД используют ORM.
А вот у той же Монго java API это просто прорыв по сравнению с замшелым SQL. И встроенный ORM с версии 3.5
При использовании ORM производительность существенно ниже, чем без них с SQL
Извините за переход на личности, но Вы, батенька, неосилятор SQL с чрезмерно завышенным ЧСВ.
Нет. Скорее вы фанатик смузи-SQL.
> Нет. Скорее вы фанатик смузи-SQL.Нет, все объясняется проще - я уже стар для этих ваших ORM, а SQL - наше всё. Можете обзывать меня старым пеpдуном-ретроградом. Плюс уже пару раз был свидетелем, как более молодые коллеги применяли этот самый ORM (Hibernate), взахлеб, с восторгом, рассказывали, как все замечательно. Но потом, когда проект вырастал и усложнялся, накапливал кучу данных и все начинало тормозить, товарищи скисали и в новых проектах или конторах тихо переходили на JDBC/SQL (или чуть более высокоуровневые обертки над SQL - типа iBatis, JdbcTemplate...). В приложениях-"пет-шопах" ORM, конечно, рулит. Кстати, в очередной раз напоминаю себе что пора бы хоть раз попробовать это ваше смузи.
> Нет, все объясняется проще - я уже стар для этих ваших ORM, а SQL - наше всё. Можете обзывать меня старым пеpдуном-ретроградом.Настоящие ретрограды застали времена, когда ваш SQL был очередной хипстерской поделкой, а все базы был нереляционные. Не льстите себе.
> времена, когда ваш SQL был очередной хипстерской поделкой, а все базы был нереляционныеВыходит все эти новые NoSQL СУБД просто возврат к хорошо забытому старому???
Да, с подключением.
В итоге я запутался кто тогда ретроградные смузи-хипсто-хлёбы? Кто за RDBMS или кто за NoSQL? Если всё тут по спирали...
Всё развивается по спирали
>Плюс уже пару раз был свидетелем, как более молодые коллеги применяли этот самый ORM (Hibernate), взахлеб, с восторгом, рассказывали, как все замечательноПро Хибернейт с восторгом? Так они напросто идиёты :) Очевидно, что голый SQL это дно, а Хибернейт лишь костыль для дна. Проблемы не решает, а только прячет.
А нормальные люди переходят на более современные и вменяемые API, которые по странному совпадению, в РСУБД не завезли. Про criteria api не надо.
>Вы, батенька, неосилятор SQL с чрезмерно завышенным ЧСВ.Бизнес уже давно расставил всё по своим местам, SQL это много багов на ровном месте - пока не запустишь прожку, неизвестно выполнится запрос или не распарсится. Особенно феерично когда аргументы генерятся из кода, ни preparedStatement сделать низя, ни гарантировать, что запрос корректный.
Поэтому сейчас РСУБД уже почти вымерло, сколько минус не жамкай :)))
ну ты и олень
Чего, уже все банки перешли на No-SQL? Или исследователи и наука начали подзабивать на структурированность и математическую точность? No-SQL уже как-то стандартизирован и сертифицирован для того, чтобы быть использованным большим бизнесом, оборонкой и госкомпаниями? Чего у вас там за бизнес, который все уже расставил, и по каким местам? По туалетам что ли?
>No-SQL уже как-то стандартизированА этот ваш SQL когда стандартизируют? :D А то в орацле8 один запрос, в орацле11 другой, в слона третий, а мускуль вообще половину не умеет.
Вот уж нет. Лови минус. Тоже частично жабист, но больше быдлоораклоид. Запросы тоже можно сначала обкатать, до деплоя. И, если тебя не пугает привязка к конкретной БД (как упомянул выше - Oracle),внезапно, даже при "генерировании аргументов из кода", при использовании динамического SQL (на стороне БД) таки можно использовать PreparedStatement и переменные привязки. Просто передаешь с морды все возможные аргументы (их же не бесконечное число? а ненужные передаешь со значением null) в метод EJB-бина (или откуда ты собрался дергать БД), а дальше можно ручками низкоуровнево:
...
OracleCallableStatement stmt = null;
try {
// подготавливаешь запрос
stmt = (OracleCallableStatement)connection.prepareCall(
"begin :result := porders.GetOrders(:p_offset,:p_limit,:p_client_id,:p_order_type_id,:p_order_state_id,:p_order_date_begin, ... <все аргументы, которые тебе нужны>");
...
// далее привязываешь параметры
stmt.registerOutParameter("result", OracleTypes.CURSOR);
stmt.setInt("p_offset", offset);
stmt.setInt("p_limit", limit);
...
// выполняешь хранимку на стороне БД
stmt.execute();
// обрабатываешь курсор
OracleResultSet rs = (OracleResultSet) stmt.getObject("result");
...
----------а на сервере БД (Oracle), в хранимке (которая в пакете), используешь динамический SQL с ПЕРЕМЕННЫМИ ПРИВЯЗКИ, а не со склеиванием значений аргументов:
function GetOrders( p_offset in integer,
p_limit in integer,
p_client_id in clients.id%type default null,
...
return SYS_REFCURSOR
is
v_result SYS_REFCURSOR;
...
beginv_sql := 'SELECT .....'; -- Пишешь кусок SQL, НО НЕ СКЛЕИВАЕШЬ значения переданных в функцию аргументов, а пишешь конструкции типа:
if p_client_id is not null then
v_sql := v_sql || ' and ca.client_id = :p_client_id';
else
v_sql := v_sql || ' and :p_client_id is null';
end if;
...
open v_result
for v_sql
using -- "привязанные" переменные
p_client_id,
...
;
return v_result;
end;
--------------можно вместо вышеприведенной конструкциии спользовать "EXECUTE IMMEDIATE..." или пакет DBMS_SQL (тогда не нужен будет IF ... ELSE..., достаточно будет просто IF... ) - главное, что SQL будет динамическим и аргументы привязываются, а не склеиваются их значения.
Пишешь хранимку в БД, выполняешь ее со всеми интересными тебе значениями параметров (ненужные передаешь со значением NULL), можешь логгировать в отдельную табличку каждый раз меняющийся текст SQL-запроса, убеждаешься в корректности запросов и только потом деплоишься.
>но больше быдлоораклоидНе думаю, что вышенаписанная отвратительная простыня сработает для например API ElasticSearch
QueryBuilder qbPersonal = QueryBuilders.boolQuery()
.must(queryDate)
.should(QueryBuilders.boolQuery()
.should(QueryBuilders.matchPhraseQuery("text", "тут фразко"))
.should(QueryBuilders.matchQuery("text", "словечко"))
.should(QueryBuilders.matchQuery("text", "другое"))
.must(QueryBuilders.matchQuery("text", "печалька"))
.minimumShouldMatch(1))
.should(QueryBuilders.boolQuery()
.should(QueryBuilders.queryStringQuery("\"перестановочка допускается\"~2"))
.should(QueryBuilders.queryStringQuery("\"иНечеткийПоиск\"~"))
.minimumShouldMatch(1))
.minimumShouldMatch(1);А внезапно бывают и другие NOSQL, например монго API:
List<BasicDBObject> argsList = new ArrayList<>();
туда просто накидал разных аргументов, потом как угодно склеили (or/and/exists/in итд)
argsListUL.add(new BasicDBObject("blabla1", bubu));
и выполнили, на входе сразу собранные объекты.Про api Neo4j вообще молчу, можно наследовать траверсер и по графу ходить по своим правилам.
Ваш лохматый SQL закапывайте уже, осиляторы....
Вот оно, перескакивание на другую тему обсуждения, когда поймали на лжи... Лови жирный минус, демагог. Древний пример был приведен в ответ на утверждение про "запрос, который не посмотришь, PreparedStatement не применишь, аргументы динамически генерируются кодом и потому }|{опа", а тут вдруг... бац! Всё это можно. И тут, на лету, "Зато смотри как я лучше могу!". Значит, про аргументы из кода, PreparedStatement и недоступность запросов ты наврал?
Всё нужно рассматривать в комплексе. И учитывать скорость операций тоже.
Поддерживаю лютого жабиста - для динамических выборок всё это безнадёжно устарело.
А если большинство разработчиков - "ораклопогроммисты", логика обработки данных в основном - в самой БД, к БД обращаются из разных языков/платформ программирования? Если ядром системы издревле является БД, а не язык программирования/фреймворк с каким-нибудь контейнером (Spring/JEE на WildFly'е, .Net на IIS'е, Delphi и/или RoR)?
> логика обработки данных в основном - в самой БДВот это-то и печально. Когда логика вне БД, то можно без серьёзных проблем мигрировать на другую БД. А так вы сами подсадили себя на иглу.
Когда вся логика в БД можно без проблем мигрировать с одного сервера приложений на другой, более молодежный :).
> Когда вся логика в БД можно без проблем мигрировать с одного сервера
> приложений на другой, более молодежный :).Тут SQLщикам надо было просто помолчать. Переносимость кода в javaEE просто на порядок лучше, чем у SQL.
С прямыми ручками и без очумелых оптимизаторов вообще ничего не требуется для смены СП.
У Оракла переносимость PL\SQL идеальная. Куда встанет СУБД Оракл там и будет работать.
Вот именно. На одном из прошлых мест работы сначала была двузвенка, но основная бизнес-логика на PL/SQL в Oracle, потом многозвенка с кластером серверов приложений, реализованных в виде DCOM компонент, позже переход на дотНет. Всё это работало с плавно, постепенно развивающейся базой и логикой в ней. Причем хранимки можно было дергать из чего угодно. На другом месте работы, старые хранимки и схемы данных параллельно дергались и дельфёй (старыми приложениями) и из WebLogic'ов и из дотНет'а - основная логика реализована в единой точке в БД и работает для всех внешних систем одинаково. И эта реализация так же переносима между платформами - PL/SQL оракла одинаково работает и под виндой и под линухом.
Жирнота-то какая, жирнота.
> SQL как и HTML это языки не для программистов, а околокомпутерного сброда.
> У нормального программиста многостраничные портянки с RANK да PARTITION BY вызывает батхёрт."Нормальный" – это который в свое время прогулял реляционную алгебру и исчисление и теперь считает бывший Structured English Query Language (да-да, само название говорит уже о целевой аудитории - оно делалось для пользователей) непонятной и запутанной магией? :)
жЫр
Когда не понимаешь, что области применения реляционок и nosql - различаются
Когда не понимаешь, что нет :)
Ну если в вашем мире - нет, то я могу лишь пособолезновать
SQL и документоорентированные БД решают разные задачи. Это как говорить "машина для тех, кто не освол самолет"
> приняли решение полностью запретить изменение ключевых настроек СУБД через API. Настройки теперь могут быть изменены только при наличии shell-доступа к серверуЗамшелые ретрограды! Прогресс не остановить!!!!1
Что мешает написать cgi-скрипт?
>> Прогресс не остановить!!!!1
> Что мешает написать cgi-скрипт?Скрипт остановки прогресса? :)
(бабка на скамейке у подъезда, шёпотом, глядя исподлобья): - Ничего, ничего... Сейчас ваш прогресс прокрутит Большую чОрную Дыру в Большом Адронном Коллайдере и сам собой остановится... Или киданёт одну страпельку и усё, станет прогресс странным...