Вопрос про распространение - это не передача заказчику, а условно размещение кода в репозитории и дальнейшее использование (внутри системы, организации или публично).
В частности, проблема с компилированием и использованием на разных архитектурах, версиях и окружении явно должна проявиться. Возможно, есть решение этого вопроса.
Компилируется код в версиях >5.5 под капотом и только в кэш, то есть не хранится на диске рядом с исходником.
Есть ли возможность вытаскивать, хранить и запускать opcode? Например, скомпилировать скрипт заранее и распространять в таком виде? И такой же вопрос про машинный код (JIT).
В версиях 5.x было интересное расширение bcompiler, которое позволяло делать это и сохранять в php-файл и нативно запускать php-скрипт (по факту opcode), но при условии что расширение bcompiler присутствует в среде исполнения и скрипт был "скомпилирован" в такой же версии и в такой же архитектуре. Изменение любого условия приводит скрипт в нерабочее состояние.
Забыли про НДС 20%, который разработчики будут обязаны сами начислять и уплачивать в бюджет.
PS: в зависимости от вида договора с конечным пользователем: если лицензионный, то не надо. А если договор на распространение ПО как у Apple или на услуги, то надо.
Только вместо юр.адреса теперь добавят поле "Фактический адрес", в котором в этом случае будет адрес прописки директора (или кто там в ЕГРЮЛ имеет право без доверенности). То есть одно поле меняют другим, ничего не меняется. Директор и сейчас может сделать юр.адрес по месту прописки. Поле E-mail уже давно есть в ЕГРЮЛ.
В целом нужно было отойти от фактического адреса тоже, оставить только город. Этого достаточно для определения территории Фондов и льгот.
Мониторим все домены, по ИНН можно потом искать. Там много веселого, например, на Гугл который в банкротстве, тоже любят домены регистрировать (safronov11.ru, steanmcomunity.ru)...
Мы запилили внешний сервис, которому делегировали эти записи. Сервис сам выпускает и продлевает сертификаты и кладет их в хранилище. Клиент при сборке/запуске контейнера просто забирает актуальный сертификат, хоть каждые 5 минут со 100 нод одновременно. Обычный lets encrypt забанит за частный перевыпуск сертификата если вы его случайно потеряете.
Делайте проще через DNS-01 challenge и делегирование CNAME для домена на сторонний домен. Например, для внутреннего домена и всех поддоменов *.secret.ru сделать запись: _acme-challenge.secret.ru CNAME _acme-challenge.publicdomain.ru
В записи _acme-challenge.publicdomain.ru сделать TXT со значением, который выдаст challenge.
Всё это дело упаковывается в скрипт, которому дать права на управление txt-записями доменам publicdomain.ru
В итоге у вас сертификат на все поддомены *.secret.ru, даже если к нему нет публичного доступа из вне (там конечно есть нюанс, что нужно будет указывать 2 домена при запросе сертификата: secret.ru и *.secret.ru, но wildcard поможет не светить все внутренности в логах crt.sh и подобных сканеров).
As long as there are pending records waiting to be fetched, the connection line will be busy and all subsequent calls will return error Commands out of sync.
Придется открывать отдельное соединение к базе только ради этого.
В кейсах работы с данными, например, переложить что-то в другую базу-коллекцию, почистить json или найти вот прям нужную запись и не вешать всю таблицу вместе с сервером. Это один из способов.
Похоже, что это уже слой ORM. Так как если сделать "select * from table" на 100 млн записей то все эти данные сначала летят клиенту (в processlist висит статус Sending data), а там уже разгребай их в foreach, если памяти хватит.
в php есть итераторы, которые в связке с ORM позволят сделать foreach на такой запрос быстрым, добавляя под капотом в запрос limit.
С типами данных в монге можно еще выстрелить в ногу - если поле string, и к нему есть индекс, то если передать для поиска переменную с типом int, то индекс уже не работает. Тоже самое наоборот. Приходится внимательнее следить за переменными.
Дело не limit, а в принципе отправки данных с сервера клиенту - если этот эффект делает под капотом ORM на запрос SELECT * FROM table, то ок, а если это by design самого mongodb, то вот и отличия.
Вопрос про распространение - это не передача заказчику, а условно размещение кода в репозитории и дальнейшее использование (внутри системы, организации или публично).
В частности, проблема с компилированием и использованием на разных архитектурах, версиях и окружении явно должна проявиться. Возможно, есть решение этого вопроса.
Компилируется код в версиях >5.5 под капотом и только в кэш, то есть не хранится на диске рядом с исходником.
Программы компилируют не для этого.
Есть ли возможность вытаскивать, хранить и запускать opcode? Например, скомпилировать скрипт заранее и распространять в таком виде? И такой же вопрос про машинный код (JIT).
В версиях 5.x было интересное расширение bcompiler, которое позволяло делать это и сохранять в php-файл и нативно запускать php-скрипт (по факту opcode), но при условии что расширение bcompiler присутствует в среде исполнения и скрипт был "скомпилирован" в такой же версии и в такой же архитектуре. Изменение любого условия приводит скрипт в нерабочее состояние.
Забыли про НДС 20%, который разработчики будут обязаны сами начислять и уплачивать в бюджет.
PS: в зависимости от вида договора с конечным пользователем: если лицензионный, то не надо. А если договор на распространение ПО как у Apple или на услуги, то надо.
Только вместо юр.адреса теперь добавят поле "Фактический адрес", в котором в этом случае будет адрес прописки директора (или кто там в ЕГРЮЛ имеет право без доверенности). То есть одно поле меняют другим, ничего не меняется. Директор и сейчас может сделать юр.адрес по месту прописки. Поле E-mail уже давно есть в ЕГРЮЛ.
В целом нужно было отойти от фактического адреса тоже, оставить только город. Этого достаточно для определения территории Фондов и льгот.
Мониторим все домены, по ИНН можно потом искать. Там много веселого, например, на Гугл который в банкротстве, тоже любят домены регистрировать
(safronov11.ru, steanmcomunity.ru)
...Там у сбера много доменов с левыми данными и проверенными доками:
domain: UMMAYA.RU
state: REGISTERED, DELEGATED, VERIFIED
org: Usumova Seda Khajievna
taxpayer-id: 7707083893
domain: KURSPRACTIKUM.RU
state: REGISTERED, DELEGATED, VERIFIED
org: Shagabudin
taxpayer-id: 7707083893
domain: NASHAOPALUBKA.RU
state: REGISTERED, DELEGATED, VERIFIED
org: "Symmetry", LLC
taxpayer-id: 7707083893
domain: NATA-FIT.RU
state: REGISTERED, DELEGATED, VERIFIED
org: 111111111
taxpayer-id: 7707083893
И еще 1618 доменов
Осталось попросить проверить Консорциум W3C на корректность предоставления доступа к заблокированным VPN-сервисам в РФ через TCP.
"Наши тарифы на услуги связи выгодно отличают нас от зарубежных конкурентов":
5200 рублей за передачу 1 Мб данных
Просто космос!
В любом решении есть своя стоимость косяков)
Мы запилили внешний сервис, которому делегировали эти записи. Сервис сам выпускает и продлевает сертификаты и кладет их в хранилище. Клиент при сборке/запуске контейнера просто забирает актуальный сертификат, хоть каждые 5 минут со 100 нод одновременно. Обычный lets encrypt забанит за частный перевыпуск сертификата если вы его случайно потеряете.
Делайте проще через DNS-01 challenge и делегирование CNAME для домена на сторонний домен. Например, для внутреннего домена и всех поддоменов *.secret.ru сделать запись:
_acme-challenge.secret.ru CNAME _acme-challenge.publicdomain.ru
В записи _acme-challenge.publicdomain.ru сделать TXT со значением, который выдаст challenge.
Всё это дело упаковывается в скрипт, которому дать права на управление txt-записями доменам publicdomain.ru
В итоге у вас сертификат на все поддомены *.secret.ru, даже если к нему нет публичного доступа из вне (там конечно есть нюанс, что нужно будет указывать 2 домена при запросе сертификата: secret.ru и *.secret.ru, но wildcard поможет не светить все внутренности в логах crt.sh и подобных сканеров).
https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation
А всё казалось таким простым:
Придется открывать отдельное соединение к базе только ради этого.
В кейсах работы с данными, например, переложить что-то в другую базу-коллекцию, почистить json или найти вот прям нужную запись и не вешать всю таблицу вместе с сервером. Это один из способов.
Посыл остался прежним - клиент эту проблему не решает. Выше меня пытались переубедить что нужно PDO, но нет.
Решить эту проблему - накрутить ORM? Который этот код превратит через итераторы в пагинацию...
Речь про реализацию драйвера. Тот же foreach в монге на 300гб коллекции не получает ее всю на клиента, а бегает по ней по сети:
С одной стороны, это удобней (не нужно строить цикл с перебором страниц). Код был чище.
А вы в курсе про тестирование?
php 8.1.11
memory_limit = 1024M
mysql 5.7.39
таблица 3гб
из коробки выкачивает все данные на сторону клиента.
Монга с таким подходом 300 гиговую базу спокойно отдает построчно в итерации.
Похоже, что это уже слой ORM. Так как если сделать "select * from table" на 100 млн записей то все эти данные сначала летят клиенту (в processlist висит статус Sending data), а там уже разгребай их в foreach, если памяти хватит.
в php есть итераторы, которые в связке с ORM позволят сделать foreach на такой запрос быстрым, добавляя под капотом в запрос limit.
С типами данных в монге можно еще выстрелить в ногу - если поле string, и к нему есть индекс, то если передать для поиска переменную с типом int, то индекс уже не работает. Тоже самое наоборот. Приходится внимательнее следить за переменными.
Дело не limit, а в принципе отправки данных с сервера клиенту - если этот эффект делает под капотом ORM на запрос SELECT * FROM table, то ок, а если это by design самого mongodb, то вот и отличия.