Лол, манька умудрилась обосраться даже на решённой задаче:
IZHJYP/5EJ
Я ебал в рот такие постановы, в моих вьюхах :photo_number это offset, это сделано для того, чтобы упростить листалку, право-лево это инкремент-декремент
Во-первых, при чём здесь листалка, во-вторых, перечитай про удаление записей, дебилушка. С твоим оффсетом всё к хуям поедет.
Иначе при листании тебе придется передать в шаблон заранее подготовленные id каждой следующей картинки (а лучше нескольких)
Шаблон, блядь, лол. 2017 на дворе, у нас даже в самом замшелом госсекторе уже SPA на реакте, а он там шаблончики рендерит.
Олсо ты неправильно модели нарисовал, у меня photos есть многие-ко-многим, потому что одна фота может быть в нескольких альбомах тоже.
Маньке виднее, что у меня в моём приложении может быть, лол. Долбоёбику невдомёк, что альбомы и фотки тут как котята для примера, в реальном кейсе сущности совсем другие. Но спиздануть и блеснуть умишком (Я ЗНАЮ ПРО МЭНИТУМЭНИ (!!!)) надо.
Олсо у фоты (которая на самом деле тот же UploadedFile с exif) есть file_id, который автоинкремент и который остается потстоянным даже при удалении.
Опять же, маньке виднее, что у меня там за филды в моделях, что я за ORM использую, и т.п.
Так что твой вопрос про модели вообще не к месту, здесь дело во вьюхе, а модели удовлетворяют задаче.
Тут уже и нехуй добавить на фоне вышеизложенной манькой хуеты.
У тебя здесь полная дичь нарисована и в рот нужно выебать дизайнера таких моделей.
Дичь — это твоё существование на рынке IT. И выебать тут только тебя нужно. Каким же надо быть долбоёбом, чтобы буквально воспринимать фубары из вопроса.
IZHJYP/O4D
Олсо обосрался от твоего желания сериализовать доступ к базе через одну очередь для вставок, ты что блядь комара перечитал? СУБД сама сериализует доступ
Давай, давай, расскажи мне, как постгрес имплементирует сериализацию транзакций, со ссылками на спеку (ответ: никак, клали они на ANSI SQL).
на каждую транзакцию до коммита создаются временные таблицы и сессии могут повисать, пока не завершатся другие.
Что несёт, ой, что несёт…
С другой стороны у тебя есть какое-то предложение как ты собираешься сериализовать доступ? Тупо очередь на инсерты и делеты неинтересно.
НЕИНТЕРЕСНО ему, блядь. Долбоёбик, люди задачи решают, а не интересы. И, опять же, читаешь жопой, я как раз не собираюсь очередь наворачивать. А вот транзакции мы с помощью комара уже сериализовали (вообще, синхронизацию через селект-фо-апдейтевский лок на что-то сторонее мы даже упомянули вчера в рассуждении с коллегой, но списали на шутку («ну да, давайте примитивы синхронизации имитировать на SELECT FOR UPDATE левых таблиц, лол… а, стой, ещё advisory_lock есть, давай его, лол») и не рассматривали.
@komar Да не, тут ты не прав. Зависит от криворукости фронтендера. У нас толковый фронтендер, который с реактом со времён, когда о нём ещё мало кто слышал, знает его потроха, узкие места, что-то там уже наоптимизировал. И у него очень быстро выходит фронтенд пилить благодаря переиспользованию компонет, только успевай апихи подавать.
@komar > Не левых
Да не, я не про твоё решение, это коллега сказал, типа давай вообще что-то совершенно левое залочим (допустим, специальноую таблицу для этого сделаем). Ну, типа имитируем локи/семафоры/вотэвер:
@komar Сорь, про foo-bar'ы для базок не знаю, написал первый пример, что в голову пришёл. А вообще да, в какой-то статейке про решение именно этой задачи (другим путём совершенно, правда) использовали товары и транзакции с ними.
@je > но в оракле точно
манька кукарекает об оракле, потому что надеется, что некому обоссать будет. Вот по постгресу всегда комар обоссыт. А про оракл можно и покукарекать, нихуя про него не зная, авось прокатит.
@je > использую прослойку, одна из задач которой минимизировать и скрыть различия между бэкендами для программиста
Долбоёб, что с него взять.
@komar > Возможно, маня думает, что она так выглядит тырпрайзнее
Да так и есть, его надрачивание на скрам-хуям-корпоративный-дух уже обо всём говорит.
@anonymous >с реактом со времён, когда о нём ещё мало кто слышал
ты тама в самом фейсбуке работаешь?