> Когда ORM скатывается в raw SQL это очевидным образом fail, вам так не кажется?
почему?
орм пытаются быть универсальными, универсальность, обычно, накладывает ограничения, как по перфомансу, так и по функционалу. Если у орм есть вменяемый маппер, который сможет замапить результат голой сиквел квери в объекты, то что кроме религии, мешает это использовать? особенно учитывая, что все эти тонкости реализации остаются внутри репозитория, а наверх отдаются только объекты.
Из чистого любопытства. Привидете, пожалуйста, пример когда это может быть полезно. Если я правильно понимаю пример из статьи, то он стандартным джанговским орм решается примерно так (по памяти)
class User(models.Model):
name = models.CharField()
groups = models.ManyToManyField(Group, through='Membership')
class Group(models.Model):
name = models.CharField()
members = models.ManyToManyField(User, through='Membership')
class Membership(models.Model):
user = models.ForeignKey(User)
group = models.ForeignKey(Group)
ну и соответсвенно потом можно как и User.groups — список групп, так и Group.members — список участников.
У вашего простого, легкого, красивого и быстрого решения, наверняка есть масса достоинств, но у него есть один маленький недостаток — оно не решает проблемы логгирования.
Все что вы можете узнать это при каких параметрах запроса случилась проблема. И то, нужно хорошо постараться, чтобы это узнать. Где она случилась и что это за проблема вы не узнаете. Если вы ставили себе именно такую задачу — вы справились блестяще.
Но если вернуться в реальность — вы сами создали себе и, что характерно, заказчику, с которым вы работаете напрямую — бааааальшой геморрой.
Врядли ошибусь, если предположу, что решение вы внедрили вчера-сегодня, думаю первый месяц его полета будет для вас незабываем. Но кто предупрежден, тот вооружен :)
Если вам хочется себя в этом убедить — ради бога. Мой опыт подсказывает, что заказчику нужно решение его задачи, а какой логгер вы используете ему фиолетово. Это в реальности.
Что касается работоспособности вашего решения попробуйте просто ответить на следующие вопросы.
1. что произойдет, если длина одного из значений формы будет больше 1001 байт или больше?
2. что произойдет, если в вашем супер методе Application_PreRequestHandlerExecute случится эксепшен?
3. как такая реализация логгинга просадит производительность веб-приложения в котором она применяется?
4. как сильно будет расти база данных лога при увеличении нагрузки? как вы планируете по ней чтото искать, если индекс у вас только по id которое никому никуда не уперлось.
5. Что вы запишете в лог, если эксепшен произойдет непосредственно при обработке запроса?
6. Каждый раз, чтобы записать в чтото в лог вам надо создавать объект LogEntry. вы действительно думаете что это удобно? особенно учитывая его жестко заданный формат?
Уверен, когда программисты начнут сначала изучать имеющиеся решения задач, и лишь потом начинать изобретать свои велосипеды (деревянные, без руля, передач, звонка и даже сидения), тогда мир станет чуточку совершенее :)
Хотите я предложу вам работу с доходом примерно в 200к в месяц? надо немножко работать в поле, копать ямки, ставить там муфты, расшивать их, задовить кабель в кросс станции, опять расшивать. общаться с путейцами. с бомжами. работа 2 недели в степях, 2 дома. это зимой. летом вы 90% времени в степях. жить будете в вагончике. удобсва на улице, хотя чаще в кустах.
оформление по КЗОТ, белая зп, отпуск 36 календарных деней. раз в год проезд по ЖД бесплатный куда угодно.
ну примерно в томже в чем разница между грорением и взрывом.
вот одна относительно молодая компания увеличилась за год с 52 человек до почти 300. тоесть каждый месяц они нанимали половину своего начального штата.
кандидатов нельзя выбрать например потому, что он один. и какой есть. и очень нужный. область достаточно специфичная. или живете не в дефолт сити. или надо сразу и много, потому, что особо успешный манагер по продажам продал крупному заказчику тонну воздуха под видом мегасофта.
факторов очень много. я больше про то, что все эти универсальные правила озвученные в статье очень хорошие и кним можно стремиться, но от реальной жизни они достаточно далеки, что, в прочем, не исключает того, что есть компании в которых они работают. как долго и как успешно — покажет время
почему?
орм пытаются быть универсальными, универсальность, обычно, накладывает ограничения, как по перфомансу, так и по функционалу. Если у орм есть вменяемый маппер, который сможет замапить результат голой сиквел квери в объекты, то что кроме религии, мешает это использовать? особенно учитывая, что все эти тонкости реализации остаются внутри репозитория, а наверх отдаются только объекты.
class User(models.Model):
name = models.CharField()
groups = models.ManyToManyField(Group, through='Membership')
class Group(models.Model):
name = models.CharField()
members = models.ManyToManyField(User, through='Membership')
class Membership(models.Model):
user = models.ForeignKey(User)
group = models.ForeignKey(Group)
ну и соответсвенно потом можно как и User.groups — список групп, так и Group.members — список участников.
или я что-то пропустил?
Все что вы можете узнать это при каких параметрах запроса случилась проблема. И то, нужно хорошо постараться, чтобы это узнать. Где она случилась и что это за проблема вы не узнаете. Если вы ставили себе именно такую задачу — вы справились блестяще.
Но если вернуться в реальность — вы сами создали себе и, что характерно, заказчику, с которым вы работаете напрямую — бааааальшой геморрой.
Врядли ошибусь, если предположу, что решение вы внедрили вчера-сегодня, думаю первый месяц его полета будет для вас незабываем. Но кто предупрежден, тот вооружен :)
Что касается работоспособности вашего решения попробуйте просто ответить на следующие вопросы.
1. что произойдет, если длина одного из значений формы будет больше 1001 байт или больше?
2. что произойдет, если в вашем супер методе Application_PreRequestHandlerExecute случится эксепшен?
3. как такая реализация логгинга просадит производительность веб-приложения в котором она применяется?
4. как сильно будет расти база данных лога при увеличении нагрузки? как вы планируете по ней чтото искать, если индекс у вас только по id которое никому никуда не уперлось.
5. Что вы запишете в лог, если эксепшен произойдет непосредственно при обработке запроса?
6. Каждый раз, чтобы записать в чтото в лог вам надо создавать объект LogEntry. вы действительно думаете что это удобно? особенно учитывая его жестко заданный формат?
P.S. И да, добро пожаловать в реальность?:)
простите за злую иронию.
передача фактического состояния ||
передача текущего состояния
так сказать ситуация на местах
оформление по КЗОТ, белая зп, отпуск 36 календарных деней. раз в год проезд по ЖД бесплатный куда угодно.
с какого чила выходите?
вот одна относительно молодая компания увеличилась за год с 52 человек до почти 300. тоесть каждый месяц они нанимали половину своего начального штата.
кандидатов нельзя выбрать например потому, что он один. и какой есть. и очень нужный. область достаточно специфичная. или живете не в дефолт сити. или надо сразу и много, потому, что особо успешный манагер по продажам продал крупному заказчику тонну воздуха под видом мегасофта.
факторов очень много. я больше про то, что все эти универсальные правила озвученные в статье очень хорошие и кним можно стремиться, но от реальной жизни они достаточно далеки, что, в прочем, не исключает того, что есть компании в которых они работают. как долго и как успешно — покажет время