а главное я чего не пойму... он говорит что имена файлов привязаны к id, а потом же говорит что зачем то пишет их в базу... а зачем ?! писать их в базу если они зависят от id, закинули в базу строку, выкусили id, в соответствии с ним записали 2 файла: 'blabla'.$id и 'albalb'.$id... и нафик нам их имена внутри записи ?

bE(o0L, да нет, просто "звучит" мощно … эээ... меня просто такой способ привел в ступор на некоторое время.
vexoid, ну да. А если есть беспокойство о том, не будет ли обращение к записи, файлов для которой еще нет, то это можно легко и просто проконтролировать введением одного булевского флага.

@TSV, э какой способ?

vexoid, мне и нужно чтоб они были как ID

господа, ну неужели никто не знает? ну должно же быть чтонить типа show_current_id() или схожее!

bE(o0L, а это я не тормоз, а медленный газ. Дошло.
Так в том-то и дело, что нужен не current, а future id, а это нельзя, потому что будущее еще не написано, а какой будет следующий id после 100-го - хрен его знает. То ли 101, то ли 157, если за время от его получения до использования кто-то другой еще 56 записей добавит! Нельзя такую всегда и быстро работающую функцию написать, принципиально нельзя.

bE(o0L, я повторю тезисы еще раз. Медленно. Итак:

1. Определить следующий уникальный ID можно.
2. При параллельной работе этот ID вполне может быть заюзан другим потоком до того, как ты его используешь.
3. Чтобы не было конфликтов ты будешь вынужден применить блокировки.
4. Применение блокировок даст такое снижение суммарной скорости, что ты забудешь навсегда о своем файловом торможении.

мн..нуда...
ЭХ
Ж А Л Ь.

@TSV,

не ну всё равно future id палюбому пригодится где-нибудь

bE(o0L, потому что у тебя "глаз замылился".

bE(o0L, "съесть-то он съесть, да хто ж ему дасть"
Crazy, 5. При неаккуратном применении блокировки возможна ситуация конфликта двух и более процессов, при которой все из них "висят", и ждут друг друга.

Я настаиваю.

@TSV писал(а):

При неаккуратном применении блокировки возможна ситуация конфликта двух и более процессов, при которой все из них "висят", и ждут друг друга.

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

Цитата:

Я настаиваю.

Crazy, хочешь попасть в Америку?
Два пользователя - A и B. Две таблицы - T1 и T2. Изменения оба два пользователя хотят сделать в обеих таблицах. И оба хотят их лочить. Схему клинча нарисовать? В 99% случаев люди, которые ранее с этим не сталкивались, смачно прикладываются фейсом об швабру. И не сразу находят ошибку. Это классическая проблема реляционных баз данных. Лучше давить такие баги в зародыше.

@TSV, рассказывать мне про клинчи не надо. Типа намек.

Crazy, Какие мы вааажные.
Чего заканчивал-то? И чего делаешь сейчас в смысле работы? (ФУПМ МФТИ у меня).

@TSV писал(а):

Чего заканчивал-то?

Среднюю школу N 114.

Цитата:

И чего делаешь сейчас в смысле работы?

Ну вот так сразу обсуждать столь личные вопросы...

Цитата:

(ФУПМ МФТИ у меня).

Так чему, говоришь, равно значение М(ФТИ)?

P.S. Что до клинчей, то, IMHO, нужно учить людей сознательно их разрешать, а не избегать вообще всех ситуаций, где они технически возможны.

Crazy, M(A) = Б. Партизан.

Ну дык. Так для того, чтобы сознательно разрешать, нужно знать, когда они появляются - и почему. Ситуация, которую я описал, как раз ИМХО и есть "шаблон клинча", все остальные ситуации - это вариации на тему.

@TSV писал(а):

Crazy, M(A) = Б. Партизан.

Не. Я не партизан. Я не поступил. Но погостить ездил.

Цитата:

Ситуация, которую я описал, как раз ИМХО и есть "шаблон клинча"

В таком случае для понятности к ситуации стоит добавить упоминание о "лочат в разном порядке".

Crazy, Ну да. В разном порядке.