Ми то тия проблеми са класически, сесията (айде id-то й) e направено точно с цел да идентифицираш поредица от http заявки, самия http се води stateless. Т.е. когато имаш два обекта - например атачната картинка в един пост и мнение в друг пост, общото между тях е че са в една сесия, т.е. session id-то е еднакво. Сега че има вариант да не я ползваш - има, е Стюито си прави собствени идентификатори, ти искаш да ползваш md5 на файл, лошо няма.
Идея за включване на атачнатите картинки в текста на съобщението
аз съм за на Дон Реба решението, защото бях предложил същото в другата тема :)
Ами може, но от предишният ти пост, аз всъщност нищо не разбрах. Така че и да дойда на твоето, това може да стане само случайно, ако сам се сетя.
Какво има за разбиране? Когато потребителят качи картинка я записваш където там я записваш на сървъра и и даваш id. После от него правиш линк и го слагаш в поста. Това че някой можело да не публикува поста няма никакво значение за нищо.
Джон го е страх да не се напълни с орфанизирани файлове. То така или иначе, като се трие пост ( въобще имате ли намерение да триете постове някога?) няма ли да има нужда от същия код(механизъм) който да гледа за орфанизирани файлове и да трие и тях. Приемам, че файловете не се държат в BLOB полета на базата, а във файловата система.
Не съм гледал как е направено, но предполагам в базата трябва да се пази пътя към файла. Така при триене на пост първо ще се вземат тези пътища, ще се изтрият файловете и чак тогава ще се затрие от ескюлайта
Да, предполагам е така, и другия въпрос е едно към много ли е релацията (пост/урл-и на атачмънти) в друга таблица или са набухани всички пътища към атачнатите файлове с разделител в едно поле. Залагам на първото. 
Това ме кара да се замисля за следния казус - как е по-добре- отделна таблица за файловите връзки в отношение много към едно, или връзките да са в таблицата в постовете в JSONB колона ?
Моето лично мнение, което ползвам и ако трябва да имам nvarchar(max) или нещо, което отдолу е blob. Винаги слагам това тежко нещо в отделна таблица и после правя 1-1 или 1-* релация. Причината е, че съм виждал доста често как дейтабейс админа побеснява, когато някой аналитик направи select * на такава таблица. MSSMS слага top 1000 по дефоулт, но и често си го махат аналитиците. Отделно ми обяснява, че така съм правил и page-а по поносим и правя селекта по- лесен на основната таблица, но не съм толкова добре с бази данни, не мога да го обясня с точност в момента. Четох го и някъде в нета. Е, това е ако държиш файл или голям текст в БД.
ПС: почнах да пиша преди да разбера какво казваш...
тук казуса е друг, и nvarchar няма общо с JSONB. Като цяло базата на меките е леееко смотана (все пак е сайбейз)
Хм, нещо не можем да се разберем. Потребителят качва на сървъра картинките като част от целият процес на постване на отговор в тема. Така че, тогава вече е късно. А по-рано как да кача картинката (а въобще какъвто и да е файл) - с отделна форма и JS ли?
Второ - ето таблицата за атачментите:
create table Attachments (
id integer primary key autoincrement,
postID integer references Posts(id) on delete cascade,
filename text,
changed integer,
file blob,
key blob, -- the random key for xor encrypting the blob
md5sum text
);
create index idxAttachments on Attachments(postID);
create unique index idxAttachmentsUnique on Attachments(postID, md5sum);
В момента за да направя запис, трябва да сложа PostID, ако записът е предварителен, няма да има такова. NULL ли да слагам там? И как при създаване на поста после да идентифицирам кои атачменти са за него?
аз доколкото схванах да, това има в предвид, качваш картинката веднага след затварянето на брауз диалога който я селектира. вярно, може да се откаже или да направи промени, или не знам какво,аззатовасъм малко скептичен, но може да стане, да
Туй си е проблем, че не може да имаш атачмънт инфо без да имаш пост...
1) Картинките ги постваш с отделна форма 2) Слагаш още една колона sessionId и записваш там session id 3) При главния пост на съобщението по текущото session id попълваш postID
Хм, да, така би трябвало да стане. А ако има и външен ключ към Sessions.id то при изтриване на сесията и изоставените файлове ще се трият...
Може да се спори доколко ефективно ще е триенето, класическия вариант е да се направи job/cron или квото е там и да триеш всички файлове без postId и по-стари от ден да кажем
Какво значи доколко ефективно???
create table Attachments (
....
sid integer references Sessions(id) on delete cascade
}
решава проблема на 100% винаги и гарантира, че никакви орфаннати файлове няма да има.
Какво ти стартира изтичането на сесията?
Ами точната логика не я помня, а ме мързи да погледна, но със сигурност logout-a и започването на нова сесия при пореден login.
Това е добро начало, да кажем че не се логаутнеш и затвориш браузера, или просто отебеш всичко до утре?