Программирование[9]

FeelYourDestiny said 20 minutes ago:

moonfangtopich said 34 minutes ago:

Бля какой же кайф работать в компании над внутренним продуктом, а не быть аутсорсным мясом в аренде у пендосов. Речь, понятно, про Украину, у москалей вроде и так нормально с этим.

Куда ты устроился?

> деанониться в интернете

Kant написал 8 минут назад:

вторая транзакция залочится после чтения строки и узнавания айдишки, которую она обновлять собралась

да, она подождет коммита первой, сходит в базу, ебнет туда поверх еще раз обсолет, который там и был, и ничего ей не помешает

для избежания такого надо принудительно лочить в таком случае еще и при селекте в этой же транзакции (у постгре есть для этого классный select for update, но я сомневаюсь, что ормка его вызывает)

М не совсем

U1

I1

U2 < обновит I1

I2

U апдейт, U2 обновит I1 строку, а не U1

У всех этих строк, как я понял, один общий по которому обновление и будет происходить. Верно же?

moonfangtopich написал 4 минуты назад:

FeelYourDestiny написал 24 минуты назад:

moonfangtopich написал 38 минут назад:

Бля какой же кайф работать в компании над внутренним продуктом, а не быть аутсорсным мясом в аренде у пендосов. Речь, понятно, про Украину, у москалей вроде и так нормально с этим.

Куда ты устроился?

> деанониться в интернете

ты мне не нужен

я работу искать скоро буду

Хотя чето ты меня в сомнения загнал, щас почитаю

1: селектит строку, локов нет

2: селектит строку, локов нет

1: апдейтит строку, вешает лок

2: апдейтит строку, получает по еблу, ждет освобождения лока

1: инсертит новую строку, коммитит транзакцию, локи слазят

2: лок свободен, апдейтит строку заново, лочит ее под себя

2: вставляет новую строку, коммитит транзакцию

и никаких проблем они не испытают, всё так же 2 строки

лочить надо еще на селекте, иначе никак

А селект там вообще зачем первый?

Ну, можно использовать тогда select for update и усе

Just.Doit написал 1 час назад:

 

Kant написал 1 час назад:

если делать это руками проще сдохнуть

лол что

5 строк кода

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

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

если ормка этого не умеет, то надо делать руками, что мягко говоря неудобно и проще нахуй ормку выкинуть

GoldRobot написал Только что:

А селект там вообще зачем первый?

 

Ну, можно использовать тогда select for update и усе

 

 

ну он же что-то обновлять собрался, что ему фронт прислал

ему этот его хуй надо сначала найти в базе, вот тебе и селект

если запросы так неудачно придут, что оба делают селект до апдейта, то вот и пизда

если один из них уже успел апдейтнуть и залочить, то всё заебись

и ормка по дефолту точно не будет вызывать select for update для всех запросов, база повесится нахуй от таких умников столько локов держать бесполезных.

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

так что колонка версии в каждой второй таблице наше всё

Я думал ему просто обновить нужно стейт и записать новую запись

Бля эти ваши ормки 

А базе к слову похуй ваще будет, зуб даю. Если ты конечно не иммел в виду что все запросы будут fupdate, а не только к конкретной таблице.

------

Да, read commited не поможет. Я думал что после лока перевыполнение запроса идет, но похоже нет, нихуя. Просто проверит подходит ли еще строка под запрос, или нет. А новые не найдет. 

Получается и правда или serializable/repeatable read или костыли select for update/через доп колонки.

еще можно просто замедлить фронтенд (sleep(100)) и не иметь (почти) проблем с канкаренси 

Посоветуйте плиз хорошую книгу по РБД. Читаю Дейта - ну просто пиздец водая водяная.

Желательно еще литературу какую-нить по перфоманс тюнингу в РБД. Где хорошо объяснянется про индексы (clustered non-cludtered).

Короче хочу Deep dive в этот вопрос.

GoldRobot написал 3 минуты назад:

Я думал ему просто обновить нужно стейт и записать новую запись

Бля эти ваши ормки 

 

 

дико плюсую

хуйня для прототипирования

Как всегда все беды от фронта...

GodSmack написал Только что:

Посоветуйте плиз хорошую книгу по РБД. Читаю Дейта - ну просто пиздец водая водяная.

 

Желательно еще литературу какую-нить по перфоманс тюнингу в РБД. Где хорошо объяснянется про индексы (clustered non-cludtered).

 

Короче хочу Deep dive в этот вопрос.

ну тут взять конкретную БД и курить её документацию + статьи на хабре

я бы посоветовал постгрес

GodSmack написал 21 минуту назад:

Посоветуйте плиз хорошую книгу по РБД. Читаю Дейта - ну просто пиздец водая водяная.

 

Желательно еще литературу какую-нить по перфоманс тюнингу в РБД. Где хорошо объяснянется про индексы (clustered non-cludtered).

 

Короче хочу Deep dive в этот вопрос.

дип дайвну тебе в 1 строку

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

рад был сэкономить тебе 2 минуты времени гугления

Вы уже спалили себе https://grep.app/? Вылезала недавно на хакер ньюс

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

Интересная штука, фильтрация хуйня

без регулярок и в гитхабе просто искать можно, плюс там можно сразу фильтрануть язык/расширение файла

Товарищи знатоки как пофиксить у себя на сайте в чем может быть проблема?

Oops! An Error Occurred

The server returned a "500 Internal Server Error".

Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.

Ну если это действительно ТВОЙ сайт, то тебе нужно лезть в логи, смотреть в чем дело и дебажить