Алексей Скобкин

mkvtoolnix

или нужно так
$from = $book->getFromBook()->getAlias();
вытаскивать значение сущности, а не саму сущность

Если alias - это не поле, которое является Id (судя по вашему маппингу, это не так), то у вас будет всё равно вытащена вся сущность Book.
Только в случае, если вы сделаете
$book->getFromBook()->getId()
У вас не будет запроса в БД.

дальше $from я передаю параметром в другой репозиторий, чтобы осуществить другой поиск

Понимаете, в чём дело. Если вы начинаете вместо объектов через ORM тащить из базы значения конкретных полей, возможно, вам вообще не нужна ORM.

А вообще, вполне вероятно, что вы пытаетесь экономить на спичках. У вас сколько таких запросов будет на странице делаться?

Современный фронтенд довольно плотно связан с node.js, npm, bower и прочим. Всё это удобнее использовать в Linux-системах. Работать это, конечно, будет и в Windows, но не так удобно.
С другой стороны, в Linux нет Photoshop и если вы занимаетесь вёрсткой по макетам - это может быть проблемой. Кто-то запускает его в Wine, кто-то использует виртуальную машину, кто-то пытается работать в GIMP.
Универсального решения, к сожалению, нет.

Несколько уточню, а то тут никто по делу так и не сказал.
Автоинкремент не убавляется потому, что это привело бы к проблемам с консистентностью. Если вы удалили строчку, а потом вставили новую - это уже другой ресурс и ID у него должен быть свой. Если вы хотите что-то обновить - для этого у вас есть UPDATE.
Вы, конечно, можете насильно вставлять с конкретным ID после удаления записи, но вероятнее всего, вы что-то делаете не так.

Если бы у нас передавалось две формы сразу, например Vendor и User, появился бы так же объект User и он бы автоматически присвоился переменной $user? Обычно, нужные данные я вытаскивал непосредственно из переменной $request и присваивал их "руками", куда мне нужно (хотя, такой вариант мне тоже безусловно нравится).

ParamConverter ориентируется на тайпхинтинг в параметрах экшена и автоматически вытягивает вам нужную сущность из БД согласно параметрам маршрута.

Здесь в первой строке идёт проверка на то, что форма заполнена, а дальше происходит какая-то магия не ясная мне. У нас нет никаких переменных, но делаем сброс буфера. Откуда Doctrine знает, что именно и куда нужно записать?

Никакой магии. Изучайте как работает ORM типа Data Mapper. У вас есть Entity Manager, который "перзистит" (persist) определённые сущности. В данном случае у вас в него сущность попадает при обработке формы прозрачно (как бы за кадром) через так называемые DataTransformers.

делаем сброс буфера

В общем, посмотрите, что такое Flush относительно этой ORM. Например, тут.

https://support.upwork.com/hc/en-us/articles/21106...

10% for total billings with a client between $500.01 and $10,000

Вот тут считается:
https://www.upwork.com/i/pricing/freelancers/?tsf=1

$var2 = $var1 ?: null;

Три варианта:
- fetch=EAGER у связи (см. ответ @BoShurik)
- setFetchMode() у запроса (см. ответ @BoShurik)
- Указать конкретно JOIN в запросе

Первый вариант, естественно, хорош только тогда, когда загружать коллекцию нужно ВСЕГДА.

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

Взять всех пользователей через аннотации и фильтровать на стороне пхп, сделать отдельный запрос без аннотаций или можно аннотациями как-то это сделать?

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

В гугле не забанен, просто даже не знаю как это загуглить.

Почитайте документацию по Doctrine ORM. В ней достаточно важных моментов, которые лучше узнать до начала работы, чтобы потом не переписывать всё, когда узнаете о них.

Зависит от разных факторов:

- Чем занимается эта программа
- Может ли использовать современные процессорные инструкции для оптимизации
- Какой набор флагов при сборке вы используете для 32-битных архитектур и для 64-битных.

Если взять сферический пример в вакууме, когда собирая 32-битную версию вы поддерживаете всё начиная от 486 процессора, а программа при этом занимается математическими расчётами и поддерживает все инструкции, которые появились с момента выхода 486 до появления, скажем, Athlon64, то при использовании 64-битной программы собранной со всеми возможными оптимизациями вы можете получить значительно более высокую производительность.
Либо же вы можете собрать программу исключительно под ваш очень новый процессор и получить ещё большее быстродействие. Если, конечно, программа предусматривает использование тех возможностей, которые появились в вашем поколении CPU.

В общем-то, всё несколько сложнее, чем написано у SyavaSyava в ответе. Однако, зачастую производители ПО определяют некую нижнюю планку поддержки для каждой архитектуры и ПО собирается с расчётом на поддержку процессоров определённой давности. Это, конечно, не исключает, что ПО может поддерживать оптимизации не только на уровне хардкода и директив компилятора, но и детектировать возможности железа в рантайме, и подключать модули для оптимизации.

UPD: Отвечая про Photoshop. Данный пакет, вероятнее всего, лучше будет работать в 64-битной версии, т.к. там многое завязано на математику и преобразование изображений (глупо было бы не использовать возможности новых процессоров). К тому же возможность использовать больше памяти ему точно лишней не будет.