Czy na postgresql istnieje odpowiednik MSSQL.FIleStream

Witajcie,

Mam nietypowe pytanko. Co prawda googlałem i znalazłem odpowiedź negatywną ale może macie pomysł jak zrealizować funkcjonalność MSSQL.FileStream na postgresql? Chodzi mi o to, że jak ktoś usunie rekord z bazy (w którym jest nazwa pliku - a dokładnie lokalizacja do pliku) aby baza sama z siebie usunęła ten plik? Ja póki co użyłem do tego plpythonu ale nie chroni mnie to np przed ręcznym usunięciem pliku z dysku - na bazie i tak wpis zostanie, a taką funkcjonalność zapewnia np filestream na mssql. Obejść problemu jest kilka np cykliczne sprawdzanie w pythonie lokalizacji czy plik istnieje i samoczynne usuwanie pliku ale ja bym raczej oponował za odwrotną sytuacją aby baza sama z siebie blokowała usunięcie takiego pliku. OID'y nie wchodzą w grę bo nie chcę trzymać plików w bazie tylko ich "ścieżki".

Skoro użyłeś plpythonu, to użyj go w triggerze.

Baza danych nie do tego jest. Jest do przechowywania DANYCH.
W moim przekonaniu otwieranie bazy danych na świat zewnętrzny jest ryzykowne (z 10 lat temu był wirus na MS-SQL), narusza regułę odpowiedzialności itd...

Powinien za to odpowiadać jakiś moduł:repozytorium biznesowe, warstwa, service, jak zwał, tak zwał. W Twoim projekcie każdy może se-tak skasować wiersz?

Musiałbyś mieć otwarte dowiązanie do pliku by go zablokować ew nadawać odpowiednie prawa do pliku.

Google < pl/pgsql io operation at file

AnyKtokolwiek napisał(a):

Baza danych nie do tego jest. Jest do przechowywania DANYCH.

Ekhm... a pliki binarne to nie dane?
A ja np. mam pliki excela, które są skorelowane z custom-code i trzymane w FileStream.
Pewnie to nie są dane?
No, ale dla biznesu klienta to są kluczowe dane.

W moim przekonaniu otwieranie bazy danych na świat zewnętrzny jest ryzykowne (z 10 lat temu był wirus na MS-SQL), narusza regułę odpowiedzialności itd...

Chyba nie rozumiesz jak działa FileStream w MSSQL, bo jest dokładnie odwrotnie - o jakim otwarciu na świat piszesz?
FileStream to taki miły dodatek, który fajnie zarządza plikami binarnymi z zachowaniem reguły odpowiedzialności, ale nie wpycha tych danych do pól BLOB-like, a zarządza nimi z poziomu bazy danych. Tak skrócie.
Poza tym, to działa nawet z bardzo dużymi plikami i pozwala nawet na strumieniowanie, no i można tym zarządzać z poziomu czystego SQL'a.

Rozumiem, że to idiotyczne @hzmzp ?

Powinien za to odpowiadać jakiś moduł:repozytorium biznesowe, warstwa, service, jak zwał, tak zwał. W Twoim projekcie każdy może se-tak skasować wiersz?

Pewnie każdy, kto ma do tego uprawnienia na poziomie bazy danych.
Co nie znaczy, że ja ma lub że aplikacja na to pozwoli.
Równie dobrze mógłbyś mieć pretensje, że baza danych pozwala na usuwanie wierszy

W zasadzue @wlochacz @Panczo i @somekind wyjaśnili zalety filestream i w moim przypadku właśnie chodzi o to, że developerom gui łatwiej jest pobierać plik poprzez sambę niż jako blob'a z bazy. Nie pytajcie dlaczego bo ja nauczyłem się nie zadawać takich pytań (śpię spokojniej). Chcą sambę ... mają sambę tylko ja mam teraz "zgryz" ponieważ tak jak pisał @Marcin.Miga usuwanie krotek z tabeli uruchamia mi z automatu skrypt w pythonie (nie zrobiłem tego na triggerze tylko poprzez funkcję ale to szczegół techniczny), który usuwa również plik z dysku. Problemem jest to, że z poziomu bazy nie mam kontroli nad fizycznym plikiem na dysku czyli można go przenieść, usunąć, zmienić. Niby nie powinno być takiej sytuacji ale jeśli np ktoś coś "przestawi" na sambie i da odpowiednie uprawnienia to wtedy rozjadą mi się dane w bazie z rzeczywistymi plikami na dysku. Stąd potrzebowałbym oraclowego bfile lub mssqlowego filestream. Jakiś pomysł?

Pomysł z otwieraniem pliku w celu jego zablokowania może i nie jest najgorszy ale nie wiem jak sobie linux poradzi z tysiącami / setkami tysięcy takich "otwartych" plików. W windowsie jeśli mnie pamięć nie myli jest chyba ograniczenie na 1000 otwartych handli.

Ale czy ty nie implementujesz czegoś czego nie ma w FILESYSTEM? Bo to nie jest tak, że usuniecie danych z tabeli powoduje natychmiastowe usuniecie danych z dysku, to jest robione cyklicznie prze Garbage Collector i można ewentualnie wymusić; sp_filestream_force_garbage_collection dla SQL >=2012

Nie mam teraz gdzie tego sprawdzić, ale wydaje mi się, że jak sie postarasz to też możesz usunąć pliki binarne należące do FILESTREAM

woolfik napisał(a):

Pomysł z otwieraniem pliku w celu jego zablokowania może i nie jest najgorszy ale nie wiem jak sobie linux poradzi z tysiącami / setkami tysięcy takich "otwartych" plików. W windowsie jeśli mnie pamięć nie myli jest chyba ograniczenie na 1000 otwartych handli.

skoro linux to moze hard link w katalogu do którego tylko postgres ma dostęp?