Evgeny Novoselov

Во-первых, не особо понятно зачем это вообще нужно.
Тут не про хибернейт, а про базу данных, которую вы используете.

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

Навскидку так сделать можно: вешаете триггер на удаление и двигаете айдишники строк, обновляете sequence после. Однако это очень тяжелая операция - представьте, что пользователь удалил первую строку, а у вас их миллион, вам придется поменять айдишники миллиона записей.

Более того, если вы где-то в ссылке (например, /movies/123) будете использовать этот айди (а это обычный сценарий), то при удалении все такие ссылки станут уже невалидными.

Здравствуйте!
Запросто...
1) Создайте класс например,

@Configuration
@ConfigurationProperties(prefix = "custom")
public class AppProperties {

// названия полей должны соответствовать названиям из properties. 
private String baseUrl;
private String uploadPath;

// тут геттеры 
}

А вот, пример application.properties

custom.base_url=http://localhost:8080
custom.upload_path=/home/example.com/uploads

Spring сам уже связывает base_url к baseUrl и т.д.
Единственное, @ConfigurationProperties(prefix = "custom")
тут в prefix укажите тот префикс, который вам нужен. Т.е. тут custom.base_url custom является префиксом.

Подробности тут - https://www.baeldung.com/configuration-properties-...

Данный контроллер, указанный в шаблоне отрисовывает (создает) форму по пути bundle:controller:action, а вот обрабатывает другой/другие. Вообще текущий шаблон вызывается искомым контроллером или несколькими.

Ищем контроллер по обработке формы:

1a. Или открываете гугл-консоль вкладку Network -> XHR и при отправке формы смотрите — на какой роут идет отправка
1b. Или открываете дебаг-консоль Symfony и при отправке формы смотрите — на какой роут идет отправка

2. Ищите роут: bin/consol debug:route <route>, где <route> — путь от path, можно через grep искать: bin/console d:r | grep <route_part>

Команда выдаст вам примерно такую инфу:

$ bin/console d:r home

+--------------+----------------------------------------------------------------+
| Property     | Value                                                          |
+--------------+----------------------------------------------------------------+
| Route Name   | home                                                           |
| Path         | /{_locale}                                                     |
| Path Regex   | {^/(?P<_locale>en|ru)?$}sDu                                    |
| Requirements | _locale: en|ru                                                 |
| Class        | Symfony\Component\Routing\Route                                |
| Defaults     | _controller: \App\Controller\HomeController::index() |
|              | _locale: en                                                    |
| Options      | compiler_class: Symfony\Component\Routing\RouteCompiler        |
|              | utf8: true                                                     |
+--------------+----------------------------------------------------------------+

но там могут быть переменные (id например или слаг), нужно без них... в любом случае путь найдете по команде bin/consol debug:route название вашего роута (справа пути с выражениями, слева названия роута — его и подставить в первую команду нужно):

users.show           ANY      ANY      ANY    /admin/users/{id}                                 
app_login            ANY      ANY      ANY    /login                                            
app_logout           GET      ANY      ANY    /logout                                                               
oauth.fake           ANY      ANY      ANY    /fake_login                                           
auth.signup          ANY      ANY      ANY    /signup

3. Там где-то есть обработка формы, находите что-то типа if ($form->isSubmitted() && $form->isValid()) и уже внедряете свою капчу
4. PROFIT!

1. Проверьте синтаксическую корректность номера телефона. Все мобильные номера в РФ начинаются на +79 и имеют длину ровно 11 цифр. Проверку можно даже добавить в веб форму на уровне js. Это нельзя назвать защитой от хулиганов, но она отсеет реальные ошибки и опечатки, облегчив жизнь обычным пользователям.

2. Пробейте номер по базе россвязи (файл DEF-9xx). Так вы определите номера, на которые 100% не будет доставки. В отличии от проверки синтаксиса, не выдавайте пользователю ответ о некорректном номере. На все номера отвечайте "Одноразовый код отправлен, введите его сюда", но на невалидные номера не отправляйте сообщение.

3. Добавьте ограничение на количество отправляемых форм в минуту с одного IP и количество отправляемых сообщений на один и тот же номер (независимо от IP).

4. Оцените сколько может быть отправок форм в день и поставьте общий лимит на все отправки смс за день. Это единственный реальный способ контролировать атаку на сливание бюджета. Да, реальные пользователи пострадают при достижении лимита, но вы не должны доводить до него - настройте мониторинг количества отправляемых смс и алертинг при достижении порога в 90% от лимита, чтобы у вас было время среагировать на атаку и отбить её до полного исчерпания лимита. Либо если это всплеск реальных пользователей (например, неожиданно удачная реакция на рекламу), то у вас будет время скорректировать лимит. Можно рассчитывать лимит как 2 * среднее количество отправок смс за последние Х дней, чтобы не приходилось править его вручную по мере естественного роста посещаемости. Формулу и процент для алертинга, разумеется, подберёте под свои требования. Но можете взять и мои за основу.

Отдельно хочу рассказать про так называемые прямые мобильные номера. Они выглядят как городские (например, +7495), но в реальности являются мобильными и могут принимать смски. Проверка в пункте 1 не пропускает такие номера и нет никакого способа проверить без отправки смс является ли отдельно взятый городской номер прямым мобильным. Прямых номеров мало по сравнению с настоящими мобильными или настоящими городскими. К тому же у каждого прямого номера есть мобильный аналог, начинающийся на +79, которым пользователь может воспользоваться для регистрации. Поэтому предлагаю просто забить на прямые номера, а в случае жалоб на невозможность регистрации с прямым номером, рассказывать про существование мобильного аналога, который может быть прописан где-то в договоре с оператором на оказание услуг связи или узнать в техподдержке оператора и с которым можно спокойно зарегистрироваться.

Обязательное требование email'а не усилит схему защиты, так как не проблема наштамповать реальных адресов со скриптом, автоматически прокликивающим подтверждающие ссылки во входящих письмах.

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

Arithmetic.check(new int[] { 4 });

Вам бы учебник почитать.

Тут дали уже много хороших и правильных ответов, но хотелось бы уточнить, что вот эта метафора:

Виртуальня машина java это тоже интерпретатор по сути

может направить по весьма ложному пути!

У слов в названиях есть достаточно точный смысл, и JVM называется именно машиной, а не интерпретатором, и не компилятором совершенно не случайно. Компилятор в Яве есть (javac), и он нужен не для выполнения программы, а именно для ее компиляции (в байткод). Имено поэтому он не входит в состав JRE (среды выполнения), а содержится в JDK (среде разработки). В самой JVM есть еще один, JIT-компилятор, который компилирует байткод в инструкции процессора во время выполнения программы, но это уже другая история, и его тоже никак не назвать интерпретатором.

По сути JVM - это процессор, только виртуальный. И как у любого процессора (железного, типа x86, или виртуального, типа CLR в .NET), у него есть свой набор опкодов, называемый байткодом. Так же точно, как на х86 может выполняться код, порожденный компилятором с C++, или Pascal, или Go, так же и на JVM может выполняться байткод, скомпилированный из Java, или Scala, или Kotlin (или даже написанный вручную), а .class -файл, это, по сути, тот же .exe (точнее .so), скомпилированный под "процессор JVM". В этом и заключается кроссплатформенность. Так же, как код, скомпилированный под х86 будет выполняться на процессоре от Intel или AMD, так же и байткод JVM будет выполняться на JVM от Oracle, IBM, OpenJDK и т.д. И даже наличие JIT, компилирующего байткод в опкод конкретного железного процессора во время выполнения, все еще не дает повода обзывать честную стековую (SUN) или регистровую (Dalvik) VM интерпретатором, пусть даже и по сути :)

Дело в том, что сама эта классификация (интерпретируемый/компилируемый ЯЗЫК) последние лет эдак 25 уже практически лишена смысла. Языкам, изначально ориентированным на реализацию в виде интерпретатора (с просто анализируемой лексикой, чтоб интерпретатор был поменьше и мог оставить самой программе достаточно места в ограниченной по объему памяти) типа APL или BASIC, сейчас (кроме, разумеется, очень узкоспециального применения) почетное место разве что в старых учебниках, из которых эту самую классификацию, с достойным лучшего применения упорством, продолжают дословно переписывать в новые. При этом, почему-то, забывают уточнить, что эти два понятия уже давно не про сами языки, а всего лишь про некоторые методы их реализации, и что с тех пор помимо этих методов появилось еще много других хороших и разных концепций на эту тему (типа VM, JIT, сборщиков мусора, да и хотя бы тех же OOП, разных видов типизации и еще миллион чего), которых в тех учебниках еще просто не было в силу их года издания. И что на сегодня уже даже для языков, принципиально заточеных для компиляции под регистровую архитектуру, типа С, есть пруд пруди интерпретаторов (раз, два, три)... которые, опять же, никто не называет виртуальными машинами, т.к. это все суть разные понятия. Короче, это все равно что пытаться понять, где в квантовой механике огонь, вода, земля и воздух, в том виде, как их понимали Платон и Аристотель :)

P.S. Чтоб осознать, когда эта классификация еще была актуальна, рекомендую вот это . Там создатели APL, одного из первых настоящих интерпретируемых языков, обсуждают насущные проблемы языкостроения того времени. Если туго с английским, посмотрите хотя бы вступление... в тех железяках было меньше памяти и вычислительной мощности, чем в современной симке :)

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите SOLID, DRY, KISS и остальные модные словечки, постарайтесь всё это осознать, или, на крайняк - зазубрить. Всё придет с опытом, изначально все не понимали зачем всё так сложно, но эта сложность обусловлена неисчислимыми литрами слёз и потраченных нервов, всё не просто так.

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

В итоге у нас получается вполне сносная и, что важнее - расширяемая(в разумных пределах) архитектура, не забываем прописать класс клиента и определить конкретные реализации в одном месте - можно упороться и дописать сюда контейнер зависимостей.

К примеру: в итоге, если вас уже повысили, и вы вместо парсинга стали заниматься более высшими материями - новому программисту, чтобы дописать логику преобразования данных в Excel не нужно знать как конкретно вы преобразовывали когда-то эти данные в json, ему не нужно дебажить ваш код, ему достаточно посмотреть на интерфейс - отнаследоваться от него и написать свой собственный метод преобразования и дальше использовать его в нужном месте.

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности

При всем моем уважении, но такой подход крайне деструктивен для жизни.

1) Принцип, чем больше херачишь, тем больше получаешь - не имеет перспектив, так как в какой-то момент появится ощущение, что вся ваша жизнь - это херачинье. Плюс, если произойдет какой-то сбой в графике работы, то вы не сможете уделять время заработку - и потеряете свои добавочные деньги.

2) Поэтому рационально будет идти по двум путям:

- увеличивать доход на своей текущей работе (либо при смене работы)
- идти в полукоммерческую схему со своим продуктом.

Т.е. если вы просто найдете способ себя продать дороже на работе, то вы будете делать все ту же работу (то же время), но при этом вам станет в разы приятнее жить. Во-вторых, вкладывайте силы в развитие того, что потом можно будет продать, как за время, так и сделать на основании этого собственный проект (продукт), и уже получить совсем другие деньги, на совсем других условиях.

p.s. у меня в свое время была работа, поддержка ряда клиентов в it-инфрастуктуре, пару клиентов на поддержке сайтов, плюс контракты на продвижение сайтов. Просто вся жизнь превратилась в работу, как смог накопить на квартиру, сразу же от этого всего отказался в пользу жирной работы, и своих проектов.