Ми то тия проблеми са класически, сесията (айде id-то й) e направено точно с цел да идентифицираш поредица от http заявки, самия http се води stateless. Т.е. когато имаш два обекта - например атачната картинка в един пост и мнение в друг пост, общото между тях е че са в една сесия, т.е. session id-то е еднакво. Сега че има вариант да не я ползваш - има, е Стюито си прави собствени идентификатори, ти искаш да ползваш md5 на файл, лошо няма.

аз съм за на Дон Реба решението, защото бях предложил същото в другата тема :)

Stilgar

Чакам да ви видя кога ще дойдете на моето. Само да кажа, че преди съм минавал по тоя път.

Ами може, но от предишният ти пост, аз всъщност нищо не разбрах. Така че и да дойда на твоето, това може да стане само случайно, ако сам се сетя.

johnfound

Stilgar

Чакам да ви видя кога ще дойдете на моето. Само да кажа, че преди съм минавал по тоя път.

Ами може, но от предишният ти пост, аз всъщност нищо не разбрах. Така че и да дойда на твоето, това може да стане само случайно, ако сам се сетя.

Какво има за разбиране? Когато потребителят качи картинка я записваш където там я записваш на сървъра и и даваш id. После от него правиш линк и го слагаш в поста. Това че някой можело да не публикува поста няма никакво значение за нищо.

Джон го е страх да не се напълни с орфанизирани файлове. То така или иначе, като се трие пост ( въобще имате ли намерение да триете постове някога?) няма ли да има нужда от същия код(механизъм) който да гледа за орфанизирани файлове и да трие и тях. Приемам, че файловете не се държат в BLOB полета на базата, а във файловата система.

Delegate

Джон го е страх да не се напълни с орфанизирани файлове. То така или иначе, като се трие пост ( въобще имате ли намерение да триете постове някога?) няма ли да има нужда от същия код(механизъм) който да гледа за орфанизирани файлове и да трие и тях. Приемам, че файловете не се държат в BLOB полета на базата, а във файловата система.

Не съм гледал как е направено, но предполагам в базата трябва да се пази пътя към файла. Така при триене на пост първо ще се вземат тези пътища, ще се изтрият файловете и чак тогава ще се затрие от ескюлайта

Да, предполагам е така, и другия въпрос е едно към много ли е релацията (пост/урл-и на атачмънти) в друга таблица или са набухани всички пътища към атачнатите файлове с разделител в едно поле. Залагам на първото.

Delegate

Да, предполагам е така, и другия въпрос е едно към много ли е релацията (пост/урл-и на атачмънти) в друга таблица или са набухани всички пътища към атачнатите файлове с разделител в едно поле. Залагам на първото.

Това ме кара да се замисля за следния казус - как е по-добре- отделна таблица за файловите връзки в отношение много към едно, или връзките да са в таблицата в постовете в JSONB колона ?

Elim Garak

Това ме кара да се замисля за следния казус - как е по-добре- отделна таблица за файловите връзки в отношение много към едно, или връзките да са в таблицата в постовете в JSONB колона ?

Моето лично мнение, което ползвам и ако трябва да имам nvarchar(max) или нещо, което отдолу е blob. Винаги слагам това тежко нещо в отделна таблица и после правя 1-1 или 1-* релация. Причината е, че съм виждал доста често как дейтабейс админа побеснява, когато някой аналитик направи select * на такава таблица. MSSMS слага top 1000 по дефоулт, но и често си го махат аналитиците. Отделно ми обяснява, че така съм правил и page-а по поносим и правя селекта по- лесен на основната таблица, но не съм толкова добре с бази данни, не мога да го обясня с точност в момента. Четох го и някъде в нета. Е, това е ако държиш файл или голям текст в БД.

ПС: почнах да пиша преди да разбера какво казваш...

тук казуса е друг, и nvarchar  няма общо с JSONB. Като цяло базата на меките е леееко смотана (все пак е сайбейз)

Stilgar

johnfound

Stilgar

Чакам да ви видя кога ще дойдете на моето. Само да кажа, че преди съм минавал по тоя път.

Ами може, но от предишният ти пост, аз всъщност нищо не разбрах. Така че и да дойда на твоето, това може да стане само случайно, ако сам се сетя.

Какво има за разбиране? Когато потребителят качи картинка я записваш където там я записваш на сървъра и и даваш id. После от него правиш линк и го слагаш в поста. Това че някой можело да не публикува поста няма никакво значение за нищо.

Хм, нещо не можем да се разберем. Потребителят качва на сървъра картинките като част от целият процес на постване на отговор в тема. Така че, тогава вече е късно. А по-рано как да кача картинката (а въобще какъвто и да е файл) - с отделна форма и 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 ли да слагам там? И как при създаване на поста после да идентифицирам кои атачменти са за него?

johnfound

Хм, нещо не можем да се разберем. Потребителят качва на сървъра картинките като част от целият процес на постване на отговор в тема. Така че, тогава вече е късно. А по-рано как да кача картинката (а въобще какъвто и да е файл) - с отделна форма и JS ли?

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

Туй си е проблем, че не може да имаш атачмънт инфо без да имаш пост...

johnfound

Stilgar

johnfound

Stilgar

Чакам да ви видя кога ще дойдете на моето. Само да кажа, че преди съм минавал по тоя път.

Ами може, но от предишният ти пост, аз всъщност нищо не разбрах. Така че и да дойда на твоето, това може да стане само случайно, ако сам се сетя.

Какво има за разбиране? Когато потребителят качи картинка я записваш където там я записваш на сървъра и и даваш id. После от него правиш линк и го слагаш в поста. Това че някой можело да не публикува поста няма никакво значение за нищо.

Хм, нещо не можем да се разберем. Потребителят качва на сървъра картинките като част от целият процес на постване на отговор в тема. Така че, тогава вече е късно. А по-рано как да кача картинката (а въобще какъвто и да е файл) - с отделна форма и 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

Golden Gega

1) Картинките ги постваш с отделна форма 2) Слагаш още една колона sessionId и записваш там session id 3) При главния пост на съобщението по текущото session id попълваш postID

Хм, да, така би трябвало да стане. А ако има и външен ключ към Sessions.id то при изтриване на сесията и изоставените файлове ще се трият...

johnfound

Golden Gega

1) Картинките ги постваш с отделна форма 2) Слагаш още една колона sessionId и записваш там session id 3) При главния пост на съобщението по текущото session id попълваш postID

Хм, да, така би трябвало да стане. А ако има и външен ключ към Sessions.id то при изтриване на сесията и изоставените файлове ще се трият...

Може да се спори доколко ефективно ще е триенето, класическия вариант е да се направи job/cron или квото е там и да триеш всички файлове без postId и по-стари от ден да кажем

Golden Gega

Може да се спори доколко ефективно ще е триенето, класическия вариант е да се направи job/cron или квото е там и да триеш всички файлове без postId и по-стари от ден да кажем

Какво значи доколко ефективно???

create table Attachments (
  ....
  sid integer references Sessions(id) on delete cascade
}

решава проблема на 100% винаги и гарантира, че никакви орфаннати файлове няма да има.

Какво ти стартира изтичането на сесията?

Golden Gega

Какво ти стартира изтичането на сесията?

Ами точната логика не я помня, а ме мързи да погледна, но със сигурност logout-a и започването на нова сесия при пореден login.

johnfound

Golden Gega

Какво ти стартира изтичането на сесията?

Ами точната логика не я помня, а ме мързи да погледна, но със сигурност logout-a и започването на нова сесия при пореден login.

Това е добро начало, да кажем че не се логаутнеш и затвориш браузера, или просто отебеш всичко до утре?