Обсуждение: Migration to Hibernate 3.5 final
I´ve an application running in hibernate 3.3.2 and the applications works fine, with all blob fields using oid (byte[] in java),
Migrating to hibernate 3.5 all blob fields not work anymore, and the server log shows
ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: column "preferencia" is of type oid but expression is of type bytea
But I'm cann't change the tables struct for use bytea instead oid, because I lost all data.
How I can solve it? Or How can I migrate de OID field to bytea field.
regards
--
Serhmatica
Visite www.serhmatica.com.br
Esta mensagem foi verificada pelo sistema de antivírus e
acredita-se estar livre de perigo.
Migrating to hibernate 3.5 all blob fields not work anymore, and the server log shows
ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: column "preferencia" is of type oid but expression is of type bytea
But I'm cann't change the tables struct for use bytea instead oid, because I lost all data.
How I can solve it? Or How can I migrate de OID field to bytea field.
regards
--
Rafael Guzi Felix da Silva
Desenvolvedor de Sistemas
Serhmatica Sistemas e Serviços de Informática
Telefone: (49) 3566 1303
Rafael Guzi Felix da Silva
Desenvolvedor de Sistemas
Serhmatica Sistemas e Serviços de Informática
Telefone: (49) 3566 1303
--
Serhmatica
Visite www.serhmatica.com.br
Esta mensagem foi verificada pelo sistema de antivírus e
acredita-se estar livre de perigo.
I had similar problems, try use on byte[] field following Hibernate annotation @Type(type="org.hibernate.type.PrimitiveByteArrayBlobType") Dnia sobota 10 kwiecień 2010 o 13:36:42 Craig Ringer napisał(a): > Rafael Felix wrote: > > I´ve an application running in hibernate 3.3.2 and the applications > > works fine, with all blob fields using oid (byte[] in java), > > Do you mean you're using the literal type `oid' in the Pg fields? Or are > you using the `lo' contrib type? > > By using the `oid' type you're using out-of-line large objects, > referenced by object id (oid). > > If you use `oid' directly, then when you delete a row from your table > the corresponding large object will NOT be deleted. The `lo' wrapper > contrib type provides that. It's not in mainline yet (alas), perhaps > because it can't guarantee correctness - in particular a TRUNCATE TABLE > will still leak large objects. > > > Migrating to hibernate 3.5 all blob fields not work anymore, and the > > server log shows > > > > ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: column > > "preferencia" is of type oid but expression is of type bytea > > OK, so you're now mapping byte[] to the Pg type 'bytea' instead of to pg > large objects. > > You can change this mapping in your hibernate settings if you want > things to go back to how they were. See large object mapping in the > Hibernate documentation. > > > But I'm cann't change the tables struct for use bytea instead oid, > > because I lost all data. > > Do you mean "because you've lost all your data" or "because by doing so > you will lose all your data"? > > I presume the latter. > > What I'd do would be: > > a) Change hibernate's mapping for byte[] back to large object instead of > bytea by overriding it in the Hibernate configuration > > b) Evaluate whether bytea or large object is actually better for you by > reading the postgresql documentation and thinking a about your needs. > Consider how often you update the data, how big the maximum size of > object you need to store is, etc. > > c) Decide whether you should migrate to bytea or stick with large objects. > > d) If you stick to large objects, switch from raw oid types to `lo' > types, so you get proper large object cleanup on delete/update. Consider > using vacuumlo . > > -- > Craig Ringer >
Radoslaw and Craig,
Thanks for ansewers, the @Type annotations was worked for me.
About the Craig questions, I'm using the literal oid field.
Thanks for all
regards
Em 10/4/2010 09:58, Radosław Smogura escreveu:
--
Serhmatica
Visite www.serhmatica.com.br
Esta mensagem foi verificada pelo sistema de antiv�rus e
acredita-se estar livre de perigo.
Thanks for ansewers, the @Type annotations was worked for me.
About the Craig questions, I'm using the literal oid field.
Thanks for all
regards
Em 10/4/2010 09:58, Radosław Smogura escreveu:
I had similar problems, try use on byte[] field following Hibernate annotation @Type(type="org.hibernate.type.PrimitiveByteArrayBlobType") Dnia sobota 10 kwiecień 2010 o 13:36:42 Craig Ringer napisał(a):Rafael Felix wrote:I´ve an application running in hibernate 3.3.2 and the applications works fine, with all blob fields using oid (byte[] in java),Do you mean you're using the literal type `oid' in the Pg fields? Or are you using the `lo' contrib type? By using the `oid' type you're using out-of-line large objects, referenced by object id (oid). If you use `oid' directly, then when you delete a row from your table the corresponding large object will NOT be deleted. The `lo' wrapper contrib type provides that. It's not in mainline yet (alas), perhaps because it can't guarantee correctness - in particular a TRUNCATE TABLE will still leak large objects.Migrating to hibernate 3.5 all blob fields not work anymore, and the server log shows ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: column "preferencia" is of type oid but expression is of type byteaOK, so you're now mapping byte[] to the Pg type 'bytea' instead of to pg large objects. You can change this mapping in your hibernate settings if you want things to go back to how they were. See large object mapping in the Hibernate documentation.But I'm cann't change the tables struct for use bytea instead oid, because I lost all data.Do you mean "because you've lost all your data" or "because by doing so you will lose all your data"? I presume the latter. What I'd do would be: a) Change hibernate's mapping for byte[] back to large object instead of bytea by overriding it in the Hibernate configuration b) Evaluate whether bytea or large object is actually better for you by reading the postgresql documentation and thinking a about your needs. Consider how often you update the data, how big the maximum size of object you need to store is, etc. c) Decide whether you should migrate to bytea or stick with large objects. d) If you stick to large objects, switch from raw oid types to `lo' types, so you get proper large object cleanup on delete/update. Consider using vacuumlo . -- Craig Ringer
--
Rafael Guzi Felix da Silva
Desenvolvedor de Sistemas
Serhmatica Sistemas e Serviços de Informática
Telefone: (49) 3566 1303
Rafael Guzi Felix da Silva
Desenvolvedor de Sistemas
Serhmatica Sistemas e Serviços de Informática
Telefone: (49) 3566 1303
--
Serhmatica
Visite www.serhmatica.com.br
Esta mensagem foi verificada pelo sistema de antiv�rus e
acredita-se estar livre de perigo.
Hi, I shuold give few words of explanation, which I didn't wrote because of tragedy that was on 10th Apr in Smolensk. This generaly isn't bug in PG JDBC, but change of default implementation of Hibernate in 3.5 version (it should not happen, because some old legacy application, without support or source code can't be migrated to Hibernate 3.5 and so to J2EE6). In my situation setting compatible property on connection didn't helped. Much more this what I saw in 3.5 - beta 2, and i don't know if this was fixed is Hibernate - without @Type annotation - will auto-create column of type oid (correct!) , but will try to read this as bytea (SIC!) Dnia poniedziałek 12 kwiecień 2010 o 13:45:49 Rafael Felix napisał(a): > Radoslaw and Craig, > > Thanks for ansewers, the @Type annotations was worked for me. > > About the Craig questions, I'm using the literal oid field. > > Thanks for all > > regards > > Em 10/4/2010 09:58, Radosław Smogura escreveu: > > I had similar problems, try use on byte[] field following Hibernate > > annotation @Type(type="org.hibernate.type.PrimitiveByteArrayBlobType") > > > > Dnia sobota 10 kwiecień 2010 o 13:36:42 Craig Ringer napisał(a): > >> Rafael Felix wrote: > >>> I´ve an application running in hibernate 3.3.2 and the applications > >>> works fine, with all blob fields using oid (byte[] in java), > >> > >> Do you mean you're using the literal type `oid' in the Pg fields? Or are > >> you using the `lo' contrib type? > >> > >> By using the `oid' type you're using out-of-line large objects, > >> referenced by object id (oid). > >> > >> If you use `oid' directly, then when you delete a row from your table > >> the corresponding large object will NOT be deleted. The `lo' wrapper > >> contrib type provides that. It's not in mainline yet (alas), perhaps > >> because it can't guarantee correctness - in particular a TRUNCATE TABLE > >> will still leak large objects. > >> > >>> Migrating to hibernate 3.5 all blob fields not work anymore, and the > >>> server log shows > >>> > >>> ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: column > >>> "preferencia" is of type oid but expression is of type bytea > >> > >> OK, so you're now mapping byte[] to the Pg type 'bytea' instead of to pg > >> large objects. > >> > >> You can change this mapping in your hibernate settings if you want > >> things to go back to how they were. See large object mapping in the > >> Hibernate documentation. > >> > >>> But I'm cann't change the tables struct for use bytea instead oid, > >>> because I lost all data. > >> > >> Do you mean "because you've lost all your data" or "because by doing so > >> you will lose all your data"? > >> > >> I presume the latter. > >> > >> What I'd do would be: > >> > >> a) Change hibernate's mapping for byte[] back to large object instead of > >> bytea by overriding it in the Hibernate configuration > >> > >> b) Evaluate whether bytea or large object is actually better for you by > >> reading the postgresql documentation and thinking a about your needs. > >> Consider how often you update the data, how big the maximum size of > >> object you need to store is, etc. > >> > >> c) Decide whether you should migrate to bytea or stick with large > >> objects. > >> > >> d) If you stick to large objects, switch from raw oid types to `lo' > >> types, so you get proper large object cleanup on delete/update. Consider > >> using vacuumlo . > >> > >> -- > >> Craig Ringer >