Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-05-03 16:34:14
|
That looks interesting! I didn't think about overloaded SqlParameter =
constructors before; that definitely makes sense. How to you handle the =
LobCreator lifecycle there? LobCreator.close needs to be invoked after =
PreparedStatement execution (but before transaction completion).
BTW, I've recently refined the LOB support for jdbc.core: There are =
AbstractLobCreatingPreparedStatementCallback and =
AbstractLobStreamingResultSetExtractor classes now (don't we love our =
class naming patterns!), to make LOB handling via JdbcTemplate more =
convenient. Have a look at imagedb's DefaultImageDatabase class for =
usage examples.
There's also a ClobStringType class in our Hibernate support, for =
storing String properties in CLOB fields. That allows to transparently =
store long Strings in Oracle CLOBs respectively MySQL text fields, for =
example. It registers a TransactionSynchronization for the =
LobCreator.close call, so just works within a Spring transaction.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Thomas Risberg
Sent: Monday, May 03, 2004 2:58 AM
To: spr...@li...
Subject: [Springframework-developer] Exposing LOB support to Jdbc Object
layer
I've recently started to take a closer look at Juergen's LOB handler=20
classes and they look very solid. It would be a shame not exposing them =
to the Jdbc Object package - primarily SqlUpdate. I have started to=20
test a few ideas. I added a constructor accepting a LobHandler to the=20
SqlParameter class. I also added a SqlLobValue class for holding the=20
input stream and the length. This is what the usage would look like:
LobHandler lobHandler =3D new DefaultLobHandler(); // or=20
OracleLobHandler
String sql =3D "insert into docs (doc_id, description , added,=20
document) values(?, ?, ?, ?)";
SqlUpdate su =3D new SqlUpdate(ds, sql);
su.declareParameter(new SqlParameter("id", Types.INTEGER));
su.declareParameter(new SqlParameter("desc", Types.VARCHAR));
su.declareParameter(new SqlParameter("added", Types.DATE));
su.declareParameter(new SqlParameter("lob", Types.BLOB,=20
lobHandler));
su.compile();
Object[] inval =3D new Object[4];
inval[0] =3D new Integer(newId);
inval[1] =3D "Doc One";
inval[2] =3D new java.sql.Date(new Date().getTime());
File in =3D new File("word.doc");
int len =3D (int) in.length();
FileInputStream is =3D new FileInputStream(in);
inval[3] =3D new SqlLobValue(is, len);
int count =3D su.update(inval);
is.close();
A few tweaks to the PreparedStatementCreateorImpl class and this=20
actually ran against both Oracle and PostgreSQL.
I think we could easily support all the different methods that=20
LobHandler supports:
byte[]
BinaryStream
String
AsciiStream
CharacterStream
Any thoughts or ideas?
Thomas
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =
Take an Oracle 10g class now, and we'll give you the exam FREE.=20
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-05-04 07:04:45
|
Isn't field-specific lazy loading a required feature of JDO? What does = Kodo JDO offer in that respect, for example? Can you lazily load LOB = fields in a database-independent manner with Kodo? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Mo 03.05.2004 20:18 An: spr...@li... Betreff: Re: [Springframework-developer] Exposing LOB support to Jdbc = Object layer j=FCrgen h=F6ller [werk3AT] wrote: >That looks interesting! I didn't think about overloaded SqlParameter = constructors before; that definitely makes sense. How to you handle the = LobCreator lifecycle there? LobCreator.close needs to be invoked after = PreparedStatement execution (but before transaction completion). > >BTW, I've recently refined the LOB support for jdbc.core: There are = AbstractLobCreatingPreparedStatementCallback and = AbstractLobStreamingResultSetExtractor classes now (don't we love our = class naming patterns!), to make LOB handling via JdbcTemplate more = convenient. Have a look at imagedb's DefaultImageDatabase class for = usage examples. > >There's also a ClobStringType class in our Hibernate support, for = storing String properties in CLOB fields. That allows to transparently = store long Strings in Oracle CLOBs respectively MySQL text fields, for = example. It registers a TransactionSynchronization for the = LobCreator.close call, so just works within a Spring transaction. >=20 > I've been trying to convince Gavin for ages to make it possible to lazy load columns (not just collections), which would make stuff like ClobStringType a lot more useful. Right now if you have a table with a LOB column and use something like ClobStringType you pay the price and load it even if you don't need it. Oh well... ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-05-04 11:53:01
|
I don't have the 1.0 spec handy here, but I'm pretty sure field-specific lazy loading is not part of the JDO spec. Kodo didn't have this feature when I worked with it back in late 2001/early 2002, but they've extended it a lot since then, so I wouldn't be that surprised if it supported it now. It's a bit of a bummer not being able to do it, since with the LOBs, that omission means you are forced to either load them all in via a transaparent LOB to string/byte mechanism, or use a non-transparent approach such as using the LobHandler, which has the added disadvantage that you can't use it to pass around the data once you are detached from the db. jürgen höller [werk3AT] wrote: >Isn't field-specific lazy loading a required feature of JDO? What does Kodo JDO offer in that respect, for example? Can you lazily load LOB fields in a database-independent manner with Kodo? > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Colin Sampaleanu >Gesendet: Mo 03.05.2004 20:18 >An: spr...@li... >Betreff: Re: [Springframework-developer] Exposing LOB support to Jdbc Object layer > > > >jürgen höller [werk3AT] wrote: > > > >>That looks interesting! I didn't think about overloaded SqlParameter constructors before; that definitely makes sense. How to you handle the LobCreator lifecycle there? LobCreator.close needs to be invoked after PreparedStatement execution (but before transaction completion). >> >>BTW, I've recently refined the LOB support for jdbc.core: There are AbstractLobCreatingPreparedStatementCallback and AbstractLobStreamingResultSetExtractor classes now (don't we love our class naming patterns!), to make LOB handling via JdbcTemplate more convenient. Have a look at imagedb's DefaultImageDatabase class for usage examples. >> >>There's also a ClobStringType class in our Hibernate support, for storing String properties in CLOB fields. That allows to transparently store long Strings in Oracle CLOBs respectively MySQL text fields, for example. It registers a TransactionSynchronization for the LobCreator.close call, so just works within a Spring transaction. >> >> >> >> >I've been trying to convince Gavin for ages to make it possible to lazy >load columns (not just collections), which would make stuff like >ClobStringType a lot more useful. Right now if you have a table with a >LOB column and use something like ClobStringType you pay the price and >load it even if you don't need it. > >Oh well... > > |
|
From: Colin S. <col...@ex...> - 2004-05-03 18:18:53
|
j=FCrgen h=F6ller [werk3AT] wrote: >That looks interesting! I didn't think about overloaded SqlParameter con= structors before; that definitely makes sense. How to you handle the LobC= reator lifecycle there? LobCreator.close needs to be invoked after Prepar= edStatement execution (but before transaction completion). > >BTW, I've recently refined the LOB support for jdbc.core: There are Abst= ractLobCreatingPreparedStatementCallback and AbstractLobStreamingResultSe= tExtractor classes now (don't we love our class naming patterns!), to mak= e LOB handling via JdbcTemplate more convenient. Have a look at imagedb's= DefaultImageDatabase class for usage examples. > >There's also a ClobStringType class in our Hibernate support, for storin= g String properties in CLOB fields. That allows to transparently store lo= ng Strings in Oracle CLOBs respectively MySQL text fields, for example. I= t registers a TransactionSynchronization for the LobCreator.close call, s= o just works within a Spring transaction. > =20 > I've been trying to convince Gavin for ages to make it possible to lazy=20 load columns (not just collections), which would make stuff like=20 ClobStringType a lot more useful. Right now if you have a table with a=20 LOB column and use something like ClobStringType you pay the price and=20 load it even if you don't need it. Oh well... |
|
From: <tho...@tr...> - 2004-05-03 18:59:50
|
Don't know yet where the close of the LobCreator should happen. Should be
right
after ps.executeUpdate() so we would need to qyery the PreparedStatementCreator
for LOB info somehow. I have not looked at the batch processing or
MappingSqlQuery usage yet.
I'm still in the expreimentation stage but I would like to have this ready for
1.1. We would need to test with various transaction scenarios. PostgreSQL
requires that you don't run in autocommit mode when you insert a BLOB.
Thomas
Quoting "jürgen höller [werk3AT]" <jue...@we...>:
> That looks interesting! I didn't think about overloaded SqlParameter =
> constructors before; that definitely makes sense. How to you handle the =
> LobCreator lifecycle there? LobCreator.close needs to be invoked after =
> PreparedStatement execution (but before transaction completion).
>
> BTW, I've recently refined the LOB support for jdbc.core: There are =
> AbstractLobCreatingPreparedStatementCallback and =
> AbstractLobStreamingResultSetExtractor classes now (don't we love our =
> class naming patterns!), to make LOB handling via JdbcTemplate more =
> convenient. Have a look at imagedb's DefaultImageDatabase class for =
> usage examples.
>
> There's also a ClobStringType class in our Hibernate support, for =
> storing String properties in CLOB fields. That allows to transparently =
> store long Strings in Oracle CLOBs respectively MySQL text fields, for =
> example. It registers a TransactionSynchronization for the =
> LobCreator.close call, so just works within a Spring transaction.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Thomas Risberg
> Sent: Monday, May 03, 2004 2:58 AM
> To: spr...@li...
> Subject: [Springframework-developer] Exposing LOB support to Jdbc Object
> layer
>
>
> I've recently started to take a closer look at Juergen's LOB handler=20
> classes and they look very solid. It would be a shame not exposing them =
>
> to the Jdbc Object package - primarily SqlUpdate. I have started to=20
> test a few ideas. I added a constructor accepting a LobHandler to the=20
> SqlParameter class. I also added a SqlLobValue class for holding the=20
> input stream and the length. This is what the usage would look like:
>
> LobHandler lobHandler =3D new DefaultLobHandler(); // or=20
> OracleLobHandler
> String sql =3D "insert into docs (doc_id, description , added,=20
> document) values(?, ?, ?, ?)";
> SqlUpdate su =3D new SqlUpdate(ds, sql);
> su.declareParameter(new SqlParameter("id", Types.INTEGER));
> su.declareParameter(new SqlParameter("desc", Types.VARCHAR));
> su.declareParameter(new SqlParameter("added", Types.DATE));
> su.declareParameter(new SqlParameter("lob", Types.BLOB,=20
> lobHandler));
> su.compile();
> Object[] inval =3D new Object[4];
> inval[0] =3D new Integer(newId);
> inval[1] =3D "Doc One";
> inval[2] =3D new java.sql.Date(new Date().getTime());
> File in =3D new File("word.doc");
> int len =3D (int) in.length();
> FileInputStream is =3D new FileInputStream(in);
> inval[3] =3D new SqlLobValue(is, len);
> int count =3D su.update(inval);
> is.close();
>
> A few tweaks to the PreparedStatementCreateorImpl class and this=20
> actually ran against both Oracle and PostgreSQL.
>
> I think we could easily support all the different methods that=20
> LobHandler supports:
> byte[]
> BinaryStream
> String
> AsciiStream
> CharacterStream
>
> Any thoughts or ideas?
>
> Thomas
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. =
>
> Take an Oracle 10g class now, and we'll give you the exam FREE.=20
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
