I'm still fumbling in the dark but I think I have a smell:
Does somebody know what supportsLobValueChangePropogation according to
the current JDBC specs?
There's an interesting note there:
> NOTE : I do not know the correct answer currently for databases which (1) are
> not part of the cruise co
On 10 January 2012 06:57, Radosław Smogura wrote:
> 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 Oi
On 9 Jan 2012, at 18:57, Radosław Smogura wrote:
> 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
> whic
Dnia poniedziałek, 9 stycznia 2012 o 15:52:23 Alban Hertroys napisał(a):
> On 9 January 2012 14:55, Radosław Smogura 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 functionali
Hi,
thats not a bug its a feature ;)
the combination hibernate/pgjdbc uses pg large objects for byte[] and
Blob properties so only oids are referenced. Use 'vacuumlo' to free up
your space.
regards
Thomas
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
On 9 January 2012 14:55, Radosław Smogura 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 tha
On Mon, 9 Jan 2012 00:40:08 +0100, Stefan Keller wrote:
2012/1/8 Radosław Smogura wrote:
Not quite, PostgreSQL doesn't have LOB, nor OID type that is only
reference> to LOB. In fact, BLOB behaviour in JDBC> is just thin
wrapper for this what is missing in PostgreSQL - BLOBs.
I can't follow:
On 10 January 2012 00:29, Oliver Jowett wrote:
> So I'm still confused about what you'd like to see changed in the JDBC
> driver. Can you explain?
Perhaps what you're looking for here is "it all just works out of the
box". In that case, the missing piece seems to be that the DDL that
Hibernate e
On 10 January 2012 00:06, Stefan Keller wrote:
> 2012/1/9 Oliver Jowett :
>> Otherwise, what should JDBC do differently here? Be specific. It would
>
> First, I pretty sure that Hibernate nor the Tomcat/Java GC are
> misconfigured - since it works now after having installed the trigger
> by hand.
2012/1/9 Oliver Jowett :
> Otherwise, what should JDBC do differently here? Be specific. It would
First, I pretty sure that Hibernate nor the Tomcat/Java GC are
misconfigured - since it works now after having installed the trigger
by hand.
To become more specific read the first two sections as a
2012/1/9 Oliver Jowett :
> As a LO is independent storage that might have multiple references to> it
> (the OID might be stored in many places), without explicit deletion> you need
> a GC mechanism to collect unreferenced LOs eventually -> that's what vacuumlo
> etc are doing.
I can follow that.
On 9 January 2012 14:29, Stefan Keller wrote:
> 2012/1/9 Oliver Jowett :
>> As a LO is independent storage that might have multiple references to> it
>> (the OID might be stored in many places), without explicit deletion> you
>> need a GC mechanism to collect unreferenced LOs eventually -> that'
On 9 January 2012 12:40, Stefan Keller wrote:
> There's an important principle that the code which "allocates"
> resources is also responsible to release it.
That's one resource allocation model, yes. The other common model is
that resources are freed when there are no remaining references to
th
2012/1/8 Radosław Smogura wrote:
> Not quite, PostgreSQL doesn't have LOB, nor OID type that is only reference>
> to LOB. In fact, BLOB behaviour in JDBC> is just thin wrapper for this what
> is missing in PostgreSQL - BLOBs.
I can't follow: PostgreSQL has bytea and LO. I'm ok with bytea too bu
On Sun, 8 Jan 2012 21:57:37 +0100, Stefan Keller wrote:
Thanks, Radosław, for the clarification.
2012/1/8 Radosław Smogura wrote:
3. pg_largeobjects is system table, hibernate do not creates it.
4. Trigger based approach is good for this, but You need to do this
mannualy
That's exactly my
On Sun, 8 Jan 2012 18:08:09 +0100, Stefan Keller wrote:
I'd like to backup my statement below regarding in JDBC driver from
PostgreSQL:
When storing fields of type BLOB it inserts the binary string in
system table pg_largeobject (via user table). But when rows in user
table get updated or delete
Thanks, Radosław, for the clarification.
2012/1/8 Radosław Smogura wrote:
> 3. pg_largeobjects is system table, hibernate do not creates it.
>
> 4. Trigger based approach is good for this, but You need to do this mannualy
That's exactly my point:
Since JDBC manages creation of OID and pg_largeob
I'd like to backup my statement below regarding in JDBC driver from PostgreSQL:
When storing fields of type BLOB it inserts the binary string in
system table pg_largeobject (via user table). But when rows in user
table get updated or deleted it does not update nor delete
corresponding rows in tabl
Hi,
I run into a nasty behavior of current PostgreSQL JDBC.
I maintain images (from Webcams). In the Java and Hibernate (JPA) code
I specified a @Lob annotation on class MyData and a attribte/data type
"byte[] mydata;". Hibernate then generates two tables in PostgreSQL,
one called MyData with a c
19 matches
Mail list logo
