Как привязать картинки к товару, если id товара еще не создан?

У меня в системе есть страницы добавления и изменения товара. Товар имеет изображения, которые загружаются с помощью ajax+php скрипта, без перезагрузки страницы. Картинки привязываются к товару по его id. В случае изменения товара id известен, и картинки легко можно привязать. Но в случае добавления товара, id не известен, картинки не к чему привязывать, ведь товар еще не добавлен в БД. Посоветуйте как быть в такой ситуации?
Можно ли узнать будущий id товара? Хотя если узнаю будущий id, и привяжу картинки, остальные данные по данному товару, пользователь может не сохранить.

Rooner
Можно поступить так - найти максимальное значение id в таблице (SELECT MAX(id) FROM table_name), увеличить на +1 и считать это возможным значением для нового id. Обратите внимание - строка еще не добавлена в таблицу. После этого, если пользователь сделает все до конца - то Вы добавите строку в таблицу именно с этим, уже вычисленным id. Если же нет - то ничего не делаете (ведь строки еще нет).

Чем это плохо: тем, что если у Вас параллельно будет несколько добавлений, то будут коллизии при вычислении. Как решить? Вероятно, все же добавлять строку в таблицу и сделать поле "завершен". По умолчанию 0. Когда пользователь доводит процесс до конца - выставлять "завершен" в 1. Если пользователь ушел со страницы - то строка так и останется с "завершен" равным 0. Очищать такие строки, например, по крону с периодом в 1 минуту/час/день.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

EuGen, а если последний элемент в БД был удален, то надо увеличить на 2, а не на 1, если я правильно понял работу счетчика в mysql. А если их было удалено 50...

Ваша задача - сделать так, чтобы id был уникален. MAX(id)+1 всегда будет удовлетворять этому условию (ведь id, на 1 больше максимального, в таблице не существует именно в силу того, что MAX(id) - максимален)

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Или записывать файлы во временную директорию, фиксировать их наличие в сессии. При создании записи - перенести файлы в нужное место.
Кроном вычищать временные файлы, старше максимального времени жизни сессии.

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

-----
PostgreSQL DBA

EuGen, id в БД у меня всегда уникален. Например вот такая ситуация:
В базе 5 записей с id (1,2,3,4,5)
Удаляем последнюю
Теперь в базе id (1,2,3,4)
Определяем max id, он равен 5, а счетчик в базе равен уже 6
Соответственно картинки я привяжу к id = 5, а все остальное привяжется к id = 6
(Добавление)
Мелкий, хм, муторно, но вариант, спасибо.

я делаю так: загружаю картинки аналогичным способом, при этом даю им имена вида tmp_123dsda1.ext и они благополучно сохраняются у меня в скрытых полях
после сохранения товара я переименовываю эти временные файлы в нужное мне название

-----
Just do it

Panoptik, хммм в скрытых полях хранить пути к картинкам, а как понять когда их нужно удалить?
Вот с сессией понятно: загрузили картинки, записали их в сессию, а потом кроном их удаляем, когда сессия закончена.(только с кроном я пока почти не знаком)

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

-----
Just do it

Вычищать гораздо позже. Дисковое место дёшево, можно через месяц. Если пользователь каким-то чудом умудрился за месяц не сохранить товар - можно памятник ставить. Если не нашёлся файлик из пришедших с формы - вернуть "извините, мы потеряли файлик, прикрепите его ещё раз"

Panoptik, хороший вариант, мне нравится. Простой, не надо ничего изобретать, если пользователь откроет 2 вкладки добавления товара. Стоит только внимательно отнестись к валидации приходящих имён файлов.

-----
PostgreSQL DBA

mysql_insert_id а чем это плохо??? Или я задачу не правильно понял???

инсерта никакого не было ещё: товар то не создан.

Буквально вчера реализовал аналогичную вашей задачу:
необходимо было дать юзеру загружать фотографии к объявлению AJAXом до публикации объявления (до получения id).

Реализовал просто: писал во временную таблицу. По получению id-шника - переносил данные из временной таблицы в место постоянного хранения. Способ с угадыванием следующего по счету id-шника в моем случае не подошел (не совсем рационален).

upd.
Дочитал до конца первый пост. Я всегда если загружаю файл, то сразу на свое родное и постоянное место: ибо дальнейшие операции с ним обычно дорогие. В моем случае класс для работы с картинками присваивает файлу уникальное имя и заносит в базу. А все прочие имена и поля "заводите в базе какие хотите".
пример -
на входе супер_фото.jpg
сохраняем rfjrrfed3.jpg
в директорию /files/orig/r/f/j/rfjrrfed3.jpg

(Отредактировано автором: 19 Октября, 2012 - 10:40:07)

Кроны, сессии, скрытые поля. Решил я сделать несколько иначе, через флаг temp:
1. Юзер заходит на страницу добавления материала
2. Сразу удаляю все картинки из базы и с сервера у которых temp = 1
3. Юзер например загружает картинки. Записываю их в базу и ставлю им temp = 1
4. Далее проверяю, если нажата кнопка сохранить, то меняю статус картинкам на temp = 0
Получается, что если юзер добавил картинки, а потом вышел, то они удалятся при следующем посещении страницы добавления материала.

Если юзер открыл страницу добавления, загрузил картинки, а потом открыл еще одну страницу добавления, то картинки удалятся, ибо нефиг открывать столько страниц
Вроде все ок.

У меня реализовано как-то было следующим образом:
при переходе на страницу добавления товара, сразу же проверяется не существует-ли уже запись с пустым полем наименования товара
и если нет, то осуществляется запись в соответствующую таблицу с пустыми полями и возвращается id записи.
В противном случае просто возвращается ID существующей записи с пустым полем наименования товара.
Далее, по ходу дела, просто обновляются соответсвующие поля.

armancho7777777, тоже вариант, но свой я уже реализовал