Jak zapisac zdjecia do bazy PostgreSQL
Tomasz
nie tylko ich adresy? Czy istnieje taka mozliwosc w Postgres?
--
Tomasz
Tomasz Myrta
> Czy mozecie mi poradzic jak zapisac zdjecia bezposrednio w bazie danych a
> nie tylko ich adresy? Czy istnieje taka mozliwosc w Postgres?
Poczytaj w dokumentacji o "Large Objects".
Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie jako
normalne pliki?
--
TM
Tomasz
Użytkownik "Tomasz Myrta" <tm.nie...@klaster.spamerzy.net> napisał
>
> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie jako
> normalne pliki?
>
Mam kartoteke towarow i chcialbym zdjecie towaru podpiac pod kartoteke
towaru w sposob jednoznaczny. Martwia mnie rozne backupy bazy.
Jesli zdjecia beda poza baza w jakichs tam katalogach to istnieje wieksza
szansa ze mi sie z czasem wszystko rozjedzie. Nie bede w stanie upilnowac
administratora u klienta aby mi to trzymal w kupie.
Moja aplikacja dziala na kompie klienta a baza jest na serwerze gdzies w
internecie.
Aplikacja laczy sie z baza Postgres przez jdbc.
Nie wiem na razie jak by to mozna zorganizowac aby pobierac do aplikacji
zdjecia umieszczone w jakims katalogu na tym samym serwerze co baza.
Co mi sie jedynie kojarzy to w polu kartoteki towaru na bazie umiescic adres
FTP
i z tego adresu sciagal by sie obraz danego towaru na komp klienta.
--
Tomasz
Tomasz Myrta
> Użytkownik "Tomasz Myrta" <tm.nie...@klaster.spamerzy.net> napisał
>> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie jako
>> normalne pliki?
>>
> Wydaje mi sie ze mam.
> Mam kartoteke towarow i chcialbym zdjecie towaru podpiac pod kartoteke
> towaru w sposob jednoznaczny. Martwia mnie rozne backupy bazy.
> Jesli zdjecia beda poza baza w jakichs tam katalogach to istnieje wieksza
> szansa ze mi sie z czasem wszystko rozjedzie. Nie bede w stanie upilnowac
> administratora u klienta aby mi to trzymal w kupie.
Odpowiedni skrypt robiący backup może również robić kopię zdjęć. Zdjęcia
się dobrze archiwizują przy pomocy rsync, z bazą już nie jest tak łatwo.
> Moja aplikacja dziala na kompie klienta a baza jest na serwerze gdzies w
> internecie.
> Aplikacja laczy sie z baza Postgres przez jdbc.
> Nie wiem na razie jak by to mozna zorganizowac aby pobierac do aplikacji
> zdjecia umieszczone w jakims katalogu na tym samym serwerze co baza.
> Co mi sie jedynie kojarzy to w polu kartoteki towaru na bazie umiescic adres
> FTP
> i z tego adresu sciagal by sie obraz danego towaru na komp klienta.
Może http?
Raczej unika się przechowywania binarnych danych w bazie, chyba że:
- muszą działać transakcyjnie,
- stanowią pomijalną wielkość w stosunku do samej bazy (szkoda zachodu
na inne rozwiązanie),
- nie ma technicznej możliwości zestawienia innego połączenia z serwerem
niż do bazy
--
TM
wloochacz
> Użytkownik "Tomasz Myrta" <tm.nie...@klaster.spamerzy.net> napisał
>> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie jako
>> normalne pliki?
>>
> Wydaje mi sie ze mam.
> Mam kartoteke towarow i chcialbym zdjecie towaru podpiac pod kartoteke
> towaru w sposob jednoznaczny. Martwia mnie rozne backupy bazy.
> Jesli zdjecia beda poza baza w jakichs tam katalogach to istnieje wieksza
> szansa ze mi sie z czasem wszystko rozjedzie. Nie bede w stanie upilnowac
> administratora u klienta aby mi to trzymal w kupie.
> Moja aplikacja dziala na kompie klienta a baza jest na serwerze gdzies w
> internecie.
> Aplikacja laczy sie z baza Postgres przez jdbc.
> Nie wiem na razie jak by to mozna zorganizowac aby pobierac do aplikacji
> zdjecia umieszczone w jakims katalogu na tym samym serwerze co baza.
W Javie to się "chyba" da zrobić - co?
BTW - PG ma coś na kształt MS SQLowwego FileStream?
http://www.microsoft.com/poland/technet/article/art0133.mspx
> Co mi sie jedynie kojarzy to w polu kartoteki towaru na bazie umiescic adres
> FTP
> i z tego adresu sciagal by sie obraz danego towaru na komp klienta.
Proste, ale zerowa synchronizacja.
--
wloochacz
ethanak
> Tomasz napisal 2008-12-04 12:21:
>> Czy mozecie mi poradzic jak zapisac zdjecia bezposrednio w bazie danych
>> a nie tylko ich adresy? Czy istnieje taka mozliwosc w Postgres?
>
> Poczytaj w dokumentacji o "Large Objects".
Piszesz książkę o historii baz danych?
Słyszałeś o bytea?
>
> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie jako
> normalne pliki?
Dyskusja o tym już tu kiedyś była - odsyłam do archiwum.
ethanak
--
mailto=window.atob('ZXRoYW5ha0Bwb2xpcC5jb20=');
http://milena.polip.com/ - nie czekam na Ivo!
Tomasz
Użytkownik "wloochacz" <nospam.w...@nospam.dgbit.pl> napisał >
> BTW - PG ma coś na kształt MS SQLowwego FileStream?
> http://www.microsoft.com/poland/technet/article/art0133.mspx
No wlasnie nie wiem.
>> Co mi sie jedynie kojarzy to w polu kartoteki towaru na bazie umiescic
>> adres FTP
>> i z tego adresu sciagal by sie obraz danego towaru na komp klienta.
> Proste, ale zerowa synchronizacja.
Dlatego tez zadalem to pytanie na grupie w nadziei ze jest jakis sposob na
trzymanie zdjec bezposrednio w tabelach bazy Postgres.
--
Tomasz
Cezary Statkiewicz
> BTW - PG ma coś na kształt MS SQLowwego FileStream?
> http://www.microsoft.com/poland/technet/article/art0133.mspx
Nie, ale pozwala na definiowanie własnych typów:
http://www.postgresql.org/docs/8.3/interactive/extend-type-system.html
Pozdrawiam,
CS
--
Cezary Statkiewicz - http://thelirium.net
rlu#280280 gg#5223219
jabber://ce...@jabber.org
Tomasz Myrta
> Dnia Thu, 04 Dec 2008 12:47:41 +0100, Tomasz Myrta napisał(a):
>
>> Tomasz napisal 2008-12-04 12:21:
>>> Czy mozecie mi poradzic jak zapisac zdjecia bezposrednio w bazie danych
>>> a nie tylko ich adresy? Czy istnieje taka mozliwosc w Postgres?
>> Poczytaj w dokumentacji o "Large Objects".
>
> Piszesz książkę o historii baz danych?
Dlaczego? W dokumentacji nie widzę żadnych informacji o rezygnacji z
tego sposobu przechowywania danych.
>
> Słyszałeś o bytea?
Znam i używam.
Pytający wspomniał o bazie "gdzieś w internecie". Funkcje lo_ może nie
są zbyt popularne, dają za to dwie przydatne rzeczy przy kiepskim
połączeniu:
- dane można wysyłać/ściągać po kawałku, co daje nam możliwość
dorobienia paska postępu,
- po zerwanym połączeniu można kontynuować pobieranie pliku od
ostatniego miejsca
>> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie jako
>> normalne pliki?
>
> Dyskusja o tym już tu kiedyś była - odsyłam do archiwum.
np.
http://www.depesz.com/index.php/2006/09/05/przechowywanie-obrazkow-w-bazie-tak-czy-nie-i-dlaczego/
--
TM
ethanak
> [...]
> Pytający wspomniał o bazie "gdzieś w internecie". Funkcje lo_ może nie
> są zbyt popularne, dają za to dwie przydatne rzeczy przy kiepskim
> połączeniu:
> - dane można wysyłać/ściągać po kawałku, co daje nam możliwość
> dorobienia paska postępu,
> - po zerwanym połączeniu można kontynuować pobieranie pliku od
> ostatniego miejsca
Pliku. Pliku. PLIKU!
A kolega pytał o bazę danych, a nie bazę danych + miejsce na pliki dla
lo_export + interfajans do ściągania tych plików.
Tomasz Myrta
> Dnia Thu, 04 Dec 2008 14:23:44 +0100, Tomasz Myrta napisał(a):
>
>> [...]
>> Pytający wspomniał o bazie "gdzieś w internecie". Funkcje lo_ może nie
>> są zbyt popularne, dają za to dwie przydatne rzeczy przy kiepskim
>> połączeniu:
>> - dane można wysyłać/ściągać po kawałku, co daje nam możliwość
>> dorobienia paska postępu,
>> - po zerwanym połączeniu można kontynuować pobieranie pliku od
>> ostatniego miejsca
>
> Pliku. Pliku. PLIKU!
...przechowywanego jako largeobject.
> A kolega pytał o bazę danych, a nie bazę danych + miejsce na pliki dla
> lo_export + interfajans do ściągania tych plików.
No właśnie, czyli nie lo_export, tylko lo_write (zapis po kawałku),
lo_read (odczyt po kawałku) i lo_lseek (przewijanie).
--
TM
Filip Rembiałkowski
> BTW - PG ma coś na kształt MS SQLowwego FileStream?
> http://www.microsoft.com/poland/technet/article/art0133.mspx
interfejs large objects jest właśnie zbudowany z myślą o przetwarzaniu strumieniowym.
http://www.postgresql.org/docs/8.3/static/largeobjects.html
http://jdbc.postgresql.org/documentation/83/largeobjects.html
wloochacz
--
wloochacz
Paweł Matejski
> Tomasz napisal 2008-12-04 13:12:
>> Użytkownik "Tomasz Myrta" <tm.nie...@klaster.spamerzy.net> napisał
>>> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie
>>> jako normalne pliki?
A jest jakiś powód, żeby danych nie trzymać w bazie *danych*? :)
>> Wydaje mi sie ze mam.
>> Mam kartoteke towarow i chcialbym zdjecie towaru podpiac pod kartoteke
>> towaru w sposob jednoznaczny. Martwia mnie rozne backupy bazy.
>> Jesli zdjecia beda poza baza w jakichs tam katalogach to istnieje
>> wieksza szansa ze mi sie z czasem wszystko rozjedzie. Nie bede w
>> stanie upilnowac administratora u klienta aby mi to trzymal w kupie.
>
> Odpowiedni skrypt robiący backup może również robić kopię zdjęć. Zdjęcia
> się dobrze archiwizują przy pomocy rsync, z bazą już nie jest tak łatwo.
Pierwszy dodatkowy element.
>> Moja aplikacja dziala na kompie klienta a baza jest na serwerze gdzies
>> w internecie.
>> Aplikacja laczy sie z baza Postgres przez jdbc.
>> Nie wiem na razie jak by to mozna zorganizowac aby pobierac do
>> aplikacji zdjecia umieszczone w jakims katalogu na tym samym serwerze
>> co baza.
>> Co mi sie jedynie kojarzy to w polu kartoteki towaru na bazie umiescic
>> adres FTP
>> i z tego adresu sciagal by sie obraz danego towaru na komp klienta.
>
> Może http?
Drugi dodatkowy element.
> Raczej unika się przechowywania binarnych danych w bazie, chyba że:
To jest zaszłość historyczna. Nie twierdzę, że przechowywanie binariów w bazie danych ma same zalety (a tak naprawdę
chodzi o duże obiekty, nie o binaria). Po prostu trzeba się zastanowić jakie rozwiązanie będzie najlepsze w konkretnych
warunkach. Sam fakt danych binarnych nie wystarcza. A pytający nawet nie powiedział jak duże i ile tych obrazków będzie
miał. Za to można wysnuć wniosek, że klientów nie będzie dużo, a baza nie będzie obciążona.
> - muszą działać transakcyjnie,
> - stanowią pomijalną wielkość w stosunku do samej bazy (szkoda zachodu
> na inne rozwiązanie),
> - nie ma technicznej możliwości zestawienia innego połączenia z serwerem
> niż do bazy
Piszesz, jakby przechowywanie w plikach było ideałem, a przechowywanie w bazie było złem koniecznym. A takie wady
przechowywania w plikach, jak zajmowanie się dodatkowym protokołem w aplikacji klienckiej, dodatkowym systemem na
serwerze, dodatkowymi skryptami przy backupie, dodatkowym zarządzaniem bezpieczeństwem dostępu do danych? Dla mnie
przechowywani danych w plikach jest złem koniecznym! :)
Moim zdaniem, pisząc aplikację klient-serwer nawet nie opłaca się rozważać przechowywania danych w plikach. Przede
wszystkim w takim wypadku operowanie na danych jest wygodniejsze dla programisty. Jedynym argumentem za rozważeniem
plików mogą być w takim przypadku problemy z bardzo dużymi backupami.
W aplikacjach 3 warstwowych, gdzie istnieje dodatkowa warstwa pośrednicząca, wady przechowywania plików w bazie nie są
już tak dotkliwe. Ale czy się opłaca czy nie, to się nie wypowiem, bo nie mam doświadczeń. :)
Natomiast w aplikacjach internetowych, sytuacja jest odwrotna. Tu bardziej się opłaca się przechowywać duże obiekty w
plikach, przede wszystkim dlatego, że już używamy protokołu http, a serwery http świetnie sobie radzą z serwowaniem
plików. Natomiast przechowywanie dużych obiektów w bazie danych należy rozważyć, gdy chcemy zapewnić ich bezpieczeństwo
i musimy restrykcyjnie przestrzegać dostępu do danych. Również gdy duże obiekty nie są takie duże, a tylko binarne, a
nasza aplikacja mała, wygodniej może być pisać nasza aplikacje, przy założeniu że dane mamy w bazie (zależy jak kto
lubi). :)
P.S. Piszę głównie aplikacje klient serwer i tylko bardzo proste aplikacje internetowe o ograniczonej liczbie klientów.
--
P.M.
Paweł Matejski
> ethanak napisal 2008-12-04 13:51:
>> Dnia Thu, 04 Dec 2008 12:47:41 +0100, Tomasz Myrta napisał(a):
>>
>>> Tomasz napisal 2008-12-04 12:21:
>>>> Czy mozecie mi poradzic jak zapisac zdjecia bezposrednio w bazie danych
>>>> a nie tylko ich adresy? Czy istnieje taka mozliwosc w Postgres?
>>> Poczytaj w dokumentacji o "Large Objects".
>>
>> Piszesz książkę o historii baz danych?
>
> Dlaczego? W dokumentacji nie widzę żadnych informacji o rezygnacji z
> tego sposobu przechowywania danych.
http://www.postgresql.org/docs/8.3/static/lo-intro.html
"partialy obsolete" ;)
Tam są wymienione jeszcze 2 przypadki gdzie może opłacać się używać LO.
>>
>> Słyszałeś o bytea?
>
> Znam i używam.
>
> Pytający wspomniał o bazie "gdzieś w internecie".
Ale przecież wcześniej zaznaczył, że chodzi mu o problemy administracyjne, nie o kłopoty z transferem (teraz to już
raczej stawia się baz "gdzieś w intenecie" na serwerach ze słabym łączem!).
> Funkcje lo_ może nie
> są zbyt popularne, dają za to dwie przydatne rzeczy przy kiepskim
> połączeniu:
> - dane można wysyłać/ściągać po kawałku, co daje nam możliwość
> dorobienia paska postępu,
> - po zerwanym połączeniu można kontynuować pobieranie pliku od
> ostatniego miejsca
>
>>> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie jako
>>> normalne pliki?
>>
>> Dyskusja o tym już tu kiedyś była - odsyłam do archiwum.
>
> np.
> http://www.depesz.com/index.php/2006/09/05/przechowywanie-obrazkow-w-bazie-tak-czy-nie-i-dlaczego/
Moim zdaniem depesz patrzy z punktu widzenia osoby zajmującej się przede wszystkim aplikacjami internetowymi (czego nie
zaznaczenie w takim tekście jest moim zdaniem błędem). A to nie jedyny przypadek zastosowania baz danych, a przede
wszystkim nie przypadek pytającego.
--
P.M.
Tomasz Myrta
> Tomasz Myrta wrote:
>> Tomasz napisal 2008-12-04 13:12:
>>> Użytkownik "Tomasz Myrta" <tm.nie...@klaster.spamerzy.net> napisał
>>>> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie
>>>> jako normalne pliki?
>
> A jest jakiś powód, żeby danych nie trzymać w bazie *danych*? :)
Gdzieś obok podawałem link do blogu depesza, gdzie z większością
argumentów się zgadzam.
W moim przypadku główną uciążliwość stanowią backupy.
> Piszesz, jakby przechowywanie w plikach było ideałem, a przechowywanie w bazie było złem koniecznym.
Wcale nie cieszy mnie konieczność budowania oddzielnego interfejsu do
przesyłania tych danych. Wolałbym przechowywanie blobów na serwerze jako
normalne pliki i przesyłanie ich tym samym kanałem co pozostałe dane z
bazy. Niestety Postgres tego nie ma.
> A takie wady
> przechowywania w plikach, jak zajmowanie się dodatkowym protokołem w aplikacji klienckiej, dodatkowym systemem na
> serwerze, dodatkowymi skryptami przy backupie, dodatkowym zarządzaniem bezpieczeństwem dostępu do danych? Dla mnie
> przechowywani danych w plikach jest złem koniecznym! :)
Złem koniecznym z powodu samej idei czy braku odpowiedniej
funkcjonalności Postgresa? Gdyby była dostępna - z powyższej listy
zostałby tylko jeden argument - oddzielne backupowanie plików.
--
TM
Paweł Matejski
> Paweł Matejski napisal 2008-12-04 16:45:
>> Tomasz Myrta wrote:
>>> Tomasz napisal 2008-12-04 13:12:
>>>> Użytkownik "Tomasz Myrta" <tm.nie...@klaster.spamerzy.net> napisał
>>>>> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie
>>>>> jako normalne pliki?
>>
>> A jest jakiś powód, żeby danych nie trzymać w bazie *danych*? :)
>
> Gdzieś obok podawałem link do blogu depesza, gdzie z większością
> argumentów się zgadzam.
I gdzieę obok się do tego odniosłem. ;)
> W moim przypadku główną uciążliwość stanowią backupy.
Ale jaki jest Twój przypadek?
>> Piszesz, jakby przechowywanie w plikach było ideałem, a przechowywanie
>> w bazie było złem koniecznym.
>
> Wcale nie cieszy mnie konieczność budowania oddzielnego interfejsu do
> przesyłania tych danych. Wolałbym przechowywanie blobów na serwerze jako
> normalne pliki i przesyłanie ich tym samym kanałem co pozostałe dane z
> bazy. Niestety Postgres tego nie ma.
Jeśli Ci zależy na samy użyciu kanału postgresa, to napisz odpowiednie procedury w plperlu lub C. Ale musisz to napisać
i dalej backupem musisz zajmować się osobno.
>> A takie wady
>> przechowywania w plikach, jak zajmowanie się dodatkowym protokołem w
>> aplikacji klienckiej, dodatkowym systemem na
>> serwerze, dodatkowymi skryptami przy backupie, dodatkowym zarządzaniem
>> bezpieczeństwem dostępu do danych? Dla mnie
>> przechowywani danych w plikach jest złem koniecznym! :)
>
> Złem koniecznym z powodu samej idei czy braku odpowiedniej
> funkcjonalności Postgresa? Gdyby była dostępna - z powyższej listy
> zostałby tylko jeden argument - oddzielne backupowanie plików.
Ale nie ma. Jak uważasz, że to dobre rozwiązanie, to je zaimplementuj, w końcu postgres jest opensource. Puki co, żaden
z developerów postgresa nie uznał tego za warte jego pracy.
Ja staje na stanowisku, że do przechowywania danych binarnych w postgresie jest typ bytea. Jeśli komuś ten sposób
przechowywania nie odpowiada, niech mówi, co mu sprawia problemy, to zaproponuje się sposób rozwiązani tego problemu -
być może nawet przechowywania danych w plikach. Ale na teksty "dane binarne przechowuje się w plikach nie w bazie
danych" reaguje trochę alergicznie.
--
P.M.
Tomasz
Użytkownik "Paweł Matejski" <ma...@spam.madej.pl.eu.org> napisał
A pytający nawet nie powiedział jak duże i ile tych obrazków będzie
> miał. Za to można wysnuć wniosek, że klientów nie będzie dużo, a baza nie
> będzie obciążona.
>
Szacuje maksymalnie do 5 tys zdjec po ok 30KB kazde.
Wszystkich klientow (majacych dostep do serwera) jest ok 20.
Jednoczesnie moze sie zdarzyc max 5 klientow a i to wyjatkowo.
Normalnie 1 do 2 jednoczesnie. Aplikacja nie wymaga codziennego wklepywania
duzej ilosci danych a raczej kilka razy na miesiac.
Wydaje mi sie z dotyczczasowej dyskusji ze moje dane pasuja do umieszczenia
na bazie. Prosilbym jedynie o jakies wskazowki za co sie zabrac aby nie
tracic czasu na zbedne eksperymenty.
--
Tomasz
Zygmunt M. Zarzecki
>> Czy mozecie mi poradzic jak zapisac zdjecia bezposrednio w bazie
>> danych a nie tylko ich adresy? Czy istnieje taka mozliwosc w Postgres?
>
> Poczytaj w dokumentacji o "Large Objects".
>
> Masz jakiś dobry powód, żeby te zdjęcia przechowywać w bazie, a nie jako
> normalne pliki?
Milion plików po 50kB, czy baza 1mln rekordów??
zyga
halski103
Najpierw przygotować pole typu bytea.
Potem dane, w php mniej więcej po uploadzie:
$fh = fopen($_FILES['tmp_name'], "rb");
$bytea_data = '';
while (!feof($fh))
{
$bytea_data .= fread($fh, $rozmiar_pliku);
}
fclose($fh);
i potem przy zapisie do bazy
pg-escape-bytea
http://pl2.php.net/manual/pl/function.pg-escape-bytea.php
Przy odczycie pg-unescape-bytea
http://pl2.php.net/manual/pl/function.pg-unescape-bytea.php
Tomasz
Użytkownik "halski103" <luka...@gmail.com> napisał
> Najpierw przygotować pole typu bytea.
> Potem dane, w php mniej więcej po uploadzie:
> $fh = fopen($_FILES['tmp_name'], "rb");
> $bytea_data = '';
> while (!feof($fh))
> {
> $bytea_data .= fread($fh, $rozmiar_pliku);
> }
> fclose($fh);
>
> i potem przy zapisie do bazy
> pg-escape-bytea
> http://pl2.php.net/manual/pl/function.pg-escape-bytea.php
>
> Przy odczycie pg-unescape-bytea
> http://pl2.php.net/manual/pl/function.pg-unescape-bytea.php
Dzieki za konkretne informacje i linki.
Co prawda przyklady sa dla php a ja pisze w javie ale teraz wiem
przynajmniej czego szukac w javie. Mam nadzieje ze uda mi sie wykorzystac
ten typ danych "bytea".
A moze ktos z Was zna jakies przyklady obslugi pol typu bytea z poziomu
javy?
--
Tomasz
Filip Rembiałkowski
> U¿ytkownik "halski103" <luka...@gmail.com> napisa³
>
>> Najpierw przygotowaæ pole typu bytea.
>> Potem dane, w php mniej wiêcej po uploadzie:
>> $fh = fopen($_FILES['tmp_name'], "rb");
>> $bytea_data = '';
>> while (!feof($fh))
>> {
>> $bytea_data .= fread($fh, $rozmiar_pliku);
>> }
>> fclose($fh);
>>
>> i potem przy zapisie do bazy
>> pg-escape-bytea
>> http://pl2.php.net/manual/pl/function.pg-escape-bytea.php
>>
>> Przy odczycie pg-unescape-bytea
>> http://pl2.php.net/manual/pl/function.pg-unescape-bytea.php
>
> Dzieki za konkretne informacje i linki.
> Co prawda przyklady sa dla php a ja pisze w javie ale teraz wiem
> przynajmniej czego szukac w javie. Mam nadzieje ze uda mi sie wykorzystac
> ten typ danych "bytea".
> A moze ktos z Was zna jakies przyklady obslugi pol typu bytea z poziomu
> javy?
wszystko jest tu: http://jdbc.postgresql.org/
konkretnie http://jdbc.postgresql.org/documentation/83/binary-data.html
chyba że jakiś ORM/warstwa pośrednia (np. hibernate - to wtedy w jego docach)
>
> --
> Tomasz
>
>
Tomasz
Użytkownik "Filip Rembiałkowski" <plk....@gmail.com> napisał
> konkretnie http://jdbc.postgresql.org/documentation/83/binary-data.html
> chyba że jakiś ORM/warstwa pośrednia (np. hibernate - to wtedy w jego
> docach)
>
Dzieki za konkretny przyklad.
Zapis zdjecia do tabeli jest dla mnie jasny.
Nie za bardzo wiem co zrobic z przykladem na pobranie danych:
W jaki sposob z powrotem zrobic z tego plik "GIF"?
PreparedStatement ps = conn.prepareStatement("SELECT img FROM images WHERE
imgname = ?");
ps.setString(1, "myimage.gif");
ResultSet rs = ps.executeQuery();
while (rs.next()) {
byte[] imgBytes = rs.getBytes(1);
// use the data in some way here
}
rs.close();
ps.close();
--
Tomasz
halski103
i echo pg_unesca.....
w java nie mam zielonego pojęcia :)
halski103
<img src="/db/imgage/asd.php">
asd.php:
//cos tam
header('Content-Type: image/jpeg');
echo pg_unescape_bytea($content_z_bazy);
i tyle
Paweł Matejski
To jest problem nie bazy danych a javy. Jak zapisać byte[] do pliku.
--
P.M.