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

From: Radosław Smogura <rsmogura(at)softperience(dot)eu>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: Stefan Keller <sfkeller(at)gmail(dot)com>, pgsql-general List <pgsql-general(at)postgresql(dot)org>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues
Date: 2012-01-09 17:57:39
Message-ID: 1472223.7TltgQ0Nt7@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-jdbc

Dnia poniedziałek, 9 stycznia 2012 o 15:52:23 Alban Hertroys napisał(a):
> On 9 January 2012 14:55, Radosław Smogura <rsmogura(at)softperience(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message akp geek 2012-01-09 18:05:21 queries timeout during backup postgres database
Previous Message Thomas Markus 2012-01-09 15:13:23 Re: Binary Large Objects (LOB/BLOB) in Hibernate and JDBC: Unresolved issues

Browse pgsql-jdbc by date

  From Date Subject
Next Message Joseph Shraibman 2012-01-09 18:01:02 Re: problem: query result in jdbc is <> result in psql
Previous Message Dave Cramer 2012-01-09 17:49:44 Re: problem: query result in jdbc is <> result in psql