Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues

Поиск
Список
Период
Сортировка
От Radosław Smogura
Тема Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues
Дата
Msg-id 1472223.7TltgQ0Nt7@localhost
обсуждение исходный текст
Ответ на Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues  (Alban Hertroys <haramrae@gmail.com>)
Ответы Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues  (Alban Hertroys <haramrae@gmail.com>)
Re: [JDBC] Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues  (Oliver Jowett <oliver@opencloud.com>)
Список pgsql-general
Dnia poniedziałek, 9 stycznia 2012 o 15:52:23 Alban Hertroys napisał(a):
> On 9 January 2012 14:55, Radosław Smogura <rsmogura@softperience.eu> wrote:
> > So responsible for this is database, but database doesn't have
> > "real" BLOBs, this what is made in PG JDBC driver is just "not perfect"
> > way to add this functionality to PostgreSQL.
>
> I think you should elaborate on what you mean when you say that
> Postgres doesn't have "real" BLOBs.
>
> This discussion did make me wonder about something in Postgres'
> LOB-support though. As explained earlier, the current implementation
> allows for dedubbing LOB's, so that it's not necessary to store the
> same large(!) object multiple times. That is also what's causing this
> issue with the JDBC driver, or perhaps Hybernate in particular.
>
> However, shouldn't it be up to the application designer to dedup large
> objects or not?
>
> The current implementation is probably rather convenient for projects
> where duplicate large objects are common, but - as it turns out - it
> can be quite inconvenient when that's opposite to expectations.
>
> ISTMT this behaviour should at least be optional. Of course that
> raises the question what should happen with an existing set of LOB's
> when that setting gets changed.
In real world BLOBs are transfered as references, and those references are
managed in way as the trigger does. Nacked PG doesn't support deletion, Oid is
universal type so it can't be used by GC approach, unles collector will know
which Oid is LOB oid.

Oid is like void*, it's abstarct pointer. If you get void* you don't know if
data referenced by it represent person row, or car row, you don't know if
void* is even reference or just 64 bit number. Current implementation is not
type safe. You can't just write UPDATE TABLE x SET blob = 'aadfasfasfda' which
in current times should be supported, but you may write (if are not fully
familiar with db) UPDATE table X set varchar_d = blob_column;

In fact LOB's id may be stored even as varchar. So true is that PG supports
LOBs, but due to missing functionality LOBs are quite hard to manage. It's
like car withot steering wheel - you may drive, but it's little bit hard.

Regards,
Radek




В списке pgsql-general по дате отправления:

Предыдущее
От: Thomas Markus
Дата:
Сообщение: Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues
Следующее
От: akp geek
Дата:
Сообщение: queries timeout during backup postgres database