tigra

$title = '\u0417\u0438\u043c\u043d\u0435\u0435';
print_r(json_decode('"'. $title .'"')); // => Зимнее

Инициализация, что публичных, что приватных - ленивая.

НАШЁЛ РЕШЕНИЕ

У меня была раскладка «США — международная PC», заменил на стандартную
маковскую «ABC» и всё стало работать, как надо :)

php://input возвращает все необработанные данные после HTTP-заголовков запроса, независимо от типа контента.

Данные, могут быть:

• application/x-www-form-urlencoded ( application/x-www-form-urlencoded тип application/x-www-form-urlencoded для простых форм- application/x-www-form-urlencoded ) или
  
• multipart/form-data-encoded (в основном multipart/form-data-encoded для загрузки файлов)
  

Это связано с тем, что это единственные типы контента, которые должны поддерживаться браузерами. Поэтому сервер и PHP традиционно не ожидают получения какого-либо другого типа контента (что не означает, что они не могли бы).

Если вы просто отправляете POST-ом обычную HTML-форму, запрос выглядит примерно так:

POST /page.php HTTP/1.1
key1=value1&key2=value2&key3=value3

Но если вы много работаете с Ajax, может понадобиться обмен более сложными данными с типами (строка, int, bool) и структурами (массивы, объекты), поэтому в большинстве случаев JSON является лучшим выбором. Но запрос с JSON-полезной нагрузкой выглядел бы примерно так:

POST /page.php HTTP/1.1
{"key1":"value1","key2":"value2","key3":"value3"}

Теперь содержимое будет application/json (или, по крайней мере, ни один из вышеперечисленных), так что $_POST -wrapper из PHP не знает, как с этим справиться (пока).

Данные всё еще там, вы просто не можете получить к нему доступ через $_POST. Поэтому вам нужно получить его с "сыром" виде помощью file_get_contents('php://input') (если он не закодирован в формате multipart/form-data).

Это также способ доступа к XML-данным или любому другому нестандартному типу контента.

нашел ошибку, проблема была в декодирование. Так заработало $datas = file_get_contents("php://input");

наверное все таки на хосте в прод нету./swagger который становится в контейнере docs

volumes:
      - ./swagger:/docs

для файла простейшим вариантом будет реализовать поведение подобное утилите tail или вызвать tail и забирать вывод с нее

$handle = popen("tail -f /path/to/my/logfile.log 2>&1", 'r');

while(!feof($handle)) {
    $buffer = fgets($handle);
    // здесь будет вызов API
    ob_flush();
    flush();
}
pclose($handle);

Если у вас SUNION, то у вас множества, а во множествах значения и так уникальны.

$ redis-cli
127.0.0.1:6379> sadd set1 a b c
(integer) 3
127.0.0.1:6379> sadd set2 b c d
(integer) 3
127.0.0.1:6379> sunion set1 set2
1) "b"
2) "c"
3) "d"
4) "a"

Можно ставить прямо в блоке server без добавления location.

rewrite ^/index$ / permanent;
rewrite ^(.+)/index$ $1 permanent;

Можно объединить в одно правило.
rewrite ^/((.+)/)?index$ /$2 permanent;

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Самое простое - полные пути.
Рклоните корневой каталог (родительский для /uploads) и через флаги include или exclude ограничиваете скоуп синхронизации на конкретные папки где лежат файлы.

С "только именами файлов" простого пути нет, поскольку рклон при синхронизации просто конвертирует путь файла относительно текущего каталога в имя объекта в облачном хранилище.
Вариант - писать скрипт, который будет ковырять конкретные файлы, но тогда уж проще будет забросить конкретный файл средствами api конкретного облака. (для aws например через awscli) с указанием конкретного имени объекта.

Не забывайте что rclone это не средство загрузки файлов, а в основном средство синхронизации.

https://stackoverflow.com/questions/8678989/how-ca...
sphinxsearch.com/forum/view.html?id=3984