Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

pgsql-jdbc by date

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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group