Gregory's ServerЯ не хочу воспроизводить гит в реляционной базе но я не знаю как ещё корректно обойти этот граничный случай...
Можно обойти его не совсем корректно, и надеяться что коммитов с одинаковым таймштампом не будет среди тех что надо обработать
|
Top-level
 18 comments
У меня смутное ощущение что мне могут помочь оконные функции Как я понимаю, они позволяют нарезать селект на группы без собственно группировки, и потом эти группы можно отдельно друг от друга сортировать, и выбирать то самое максимальное значение что мне нужно Осталось только переделать тестовую базу под новую схему и потестировать.... стоп у меня кажется получился тот же самый group by... Поняв что я уперлась в тупик, я снова задалась вопросом «а что если» Почему я утром была такая бодрая и продуктивная, а щас смотрю на написанное для себя ТЗ как баран на новые ворота, и не могу додумать, что мне нужно поменять чтобы пробросить в API кусочек ещё одной сущности... Обидно, что как только я вроде бы подебила мозг, работать отказался ноутбук... Обидно, что как только я вроде бы подебила и ноутбук и мозг, пришёл РКН и сказал "сегодня без ваергарда" :blobcattableflip:  @oreolek это если айпишник белый. Белый там в лучшем случае IPv6. Который не факт что есть на том вайфае на котором я ща сижу @oreolek и через чьи сервера он из-за NAT вытаскивает порты? @mo звучит хрупко. Нужно будет постоянно следить за таймстампами при записи в БД. У меня недавно была возможно похожая ситуация. Я решил записать в таблицу истории статусов два статуса подряд. В одной транзакции. И я не учёл, что запрос на запись использует now в БД. И оно считается на момент коммита транзакции. А все запросы на чтение просто искали max по таймстампу. И в моём случае записей с максимальным таймстампом было две. И бралась первая по порядку, с неактуальным значением статуса. @mrcopperbeard да, но в моем случае таймштампы берутся из гита, и база знает только о тех коммитах которые засветились в CI |
Я потерялась в селектах и группировках и вспомнила о существовании вьюх в SQL