Алексей Николаев

select o1.*, o2.*
from order_products p1
join order_products p2 on p1.product_id = p2.product_id
    and p1.order_id != p2.product._id
join orders o1 on o1.id = p1.order_id
join orders o2 on o2.id = p2.order_id

ЗЫ за подсветку синтаксиса простите - я с телефона)

UPD отформатировал

Тырк

pre-commit hook?

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

Штатная возможность в драйвере принтера Windows.
Называется "Печать в файл".

Вы гуглили printer emulator ?

просто раздели на несколько блоков, задай рамки и склей.

Значит так, берем толстую тетрадь, ручку и пишем фразу "Статические методы не имеют отношения к ООП" до тех пор, пока не запомним это на всю жизнь.
Суть объектно ориентированного программирование, как понятно из названия, заключается в том, что должен существовать объект. Статика существует не в контексте объекта, а в контексте класса! Из этого вытекает то, что на протяжении всего жизненного цикла вашего кода будет существовать лишь одно глобальное состояние статических членов класса.

Использовать статику нужно в случае, если то, что вы ей описываете принадлежит всей группе объектов, а не одному. Например, у класса Human может быть статический метод numberOfLegs(), который возвращает количество ног у людей. Количество ног - это общее свойство для всех людей (Речь идет о здоровых людях). В данном случае можно было использовать константу класса, но это не так важно, ведь, по сути, константа - это тоже статический контекст. А вот имя - это уже свойство каждого отдельного человека. И очень важно чтобы статические методы не изменяли состояние системы в целом, не содержали побочных эффектов.
В статические методы можно выносить какую либо служебную логику. Например, метод перевода числа из арабской в римскую запись следует сделать статическим.

Есть ли у статического варианта какие-то подводные камни

Большое количество. При чем, не таких уж и подводных. Из-за того, что статика глобальна, она плохо поддается тестированию, ее нельзя замокать. Глобальное состояние плохо поддается отладке. Отсутствует возможность подменить реализацию, так как это позволяют сделать объекты.

А зачем вам понадобилась подобная интеграция роутинга с Redux? Я к тому, что многие люди пихают в стор все подряд, сами не понимая зачем.

смена роута > dispatch > обновление state

Непонятно зачем вообще в этой схеме dispatch > обновление state, почему бы не использовать
dispatch(push('/somePlace')); раз уж в проекте используетеся react-router-redux?

Насколько я знаю, redux предполагает несколько иную очередность: dispatch > смена роута в ответ на dispatch > обновление state.

Непосредственно Redux предполагает только dispatch > обновление state. Остальное это middleware и сайд эффекты.

Мы в последних двух проектах вообще не использовали react-router-redux.