You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by mad <ma...@madworld.com> on 2002/03/08 16:41:44 UTC
Oracle CLOB
I'm trying to use the TDK (Turbine 2.1) to create an application that hits
an Oracle 8i db. One of my fields is a CLOB...
...
<column name="VALUE" type="CLOB"/>
...
When I try to do a doSelect() on this Table I get this Exception...
Turbine: init
Turbine: Turbine: init() Ready to Rumble!
java.lang.NumberFormatException: 4294967295
at java.lang.Integer.parseInt(Integer.java:438)
at java.lang.Integer.parseInt(Integer.java:476)
at oracle.jdbc.driver.OracleResultSetMetaData.getPrecision(OracleResultSetMetaData.java:297)
at com.workingdogs.village.Column.populate(Column.java:154)
at com.workingdogs.village.Schema.populate(Schema.java:385)
at com.workingdogs.village.QueryDataSet.<init>(QueryDataSet.java:114)
at org.apache.turbine.om.peer.BasePeer.executeQuery(BasePeer.java:1288)
at org.apache.turbine.om.peer.BasePeer.executeQuery(BasePeer.java:1251)
at org.apache.turbine.om.peer.BasePeer.executeQuery(BasePeer.java:1202)
at org.apache.turbine.om.peer.BasePeer.doSelect(BasePeer.java:1131)
at edu.westga.tdkapp.om.BaseTextCriteriaValuePeer.doSelectVillageRecords(BaseTextCriteriaValuePeer.java:206)
at edu.westga.tdkapp.om.BaseTextCriteriaValuePeer.doSelect(BaseTextCriteriaValuePeer.java:176)
at Test.testTextCriteriaValue(Test.java:28)
at Test.main(Test.java:18)
I did download the updated db.props...
...\build\bin\torque\templates\sql\base\oracle\db.props
from CVS since the version I had didn't map CLOBS to anything.
I'm assuming that village or peers (or whatever does the actual select)
doesn't know how to deal with a CLOB.
What do I need to modify to make it work?
Thanks,
-madison
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by Bill Schneider <bs...@vecna.com>.
> was >1.3MB.. My simple jdbc-sql-browser shows me a "[B@12345", just
> > like with a real blob..
> > This indeed is a very bad thing and I will have to use a separate
> > table for my raw-field.
> >
> > Thanks for the hint!
>
> Is there any Torque change that needs to come out of this discussion?
Not much that can be done about it short of fixing the underlying village
code to work properly with LOBs, which would be heavily db dependent. RAW
columns seem to be much more portable at the DB level. It seems to be
mostly a schema thing--when you make a schema, isolate RAW columns by
themselves.
-- Bill
-- Bill
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Florian Lindauer <fl...@secure-net.de> writes:
> Bill Schneider wrote:
> >
>> I've had similar experience with both Oracle BLOBs and PostgreSQL OIDs.
>>
>> Size limitation is not the only difference between LOBs and RAW columns,
>> though. RAW data is stored in line with the row and BLOBs are stored out of
>> row, meaning a LOB identifier is stored with the row and the data is stored
>> somewhere else. What this means is, a "select id, description from
>> table_with_blob" will be much faster than a "select id, description from
>> table_with_raw"
>
> Oops - you are right. I just sniffed how much data is coming over
> the net on a simple select on a line with a 1.3MB "blob" - and it
> was >1.3MB.. My simple jdbc-sql-browser shows me a "[B@12345", just
> like with a real blob..
> This indeed is a very bad thing and I will have to use a separate
> table for my raw-field.
>
> Thanks for the hint!
Is there any Torque change that needs to come out of this discussion?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by Florian Lindauer <fl...@secure-net.de>.
Bill Schneider wrote:
>
> I've had similar experience with both Oracle BLOBs and PostgreSQL OIDs.
>
> Size limitation is not the only difference between LOBs and RAW columns,
> though. RAW data is stored in line with the row and BLOBs are stored out of
> row, meaning a LOB identifier is stored with the row and the data is stored
> somewhere else. What this means is, a "select id, description from
> table_with_blob" will be much faster than a "select id, description from
> table_with_raw"
Oops - you are right. I just sniffed how much data is coming over
the net on a simple select on a line with a 1.3MB "blob" - and it
was >1.3MB.. My simple jdbc-sql-browser shows me a "[B@12345", just
like with a real blob..
This indeed is a very bad thing and I will have to use a separate
table for my raw-field.
Thanks for the hint!
--
Florian Lindauer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by Bill Schneider <bs...@vecna.com>.
I've had similar experience with both Oracle BLOBs and PostgreSQL OIDs.
Size limitation is not the only difference between LOBs and RAW columns,
though. RAW data is stored in line with the row and BLOBs are stored out of
row, meaning a LOB identifier is stored with the row and the data is stored
somewhere else. What this means is, a "select id, description from
table_with_blob" will be much faster than a "select id, description from
table_with_raw"
If you use RAW columns you should put them in a table all by themselves with
just an ID pointing to the object they're associated with.
-- Bill
> My solution now was mapping the Turbine-BLOB to LONG RAW in
> db.props. As I understand it, the only difference is that BLOBs
> can have max. 4GB, LONG RAWs only 2GB. Should be enough :)
> Hope it really works in the long run.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by mad <ma...@madworld.com>.
> You do not really need the source from there - you have the jar.
> And with the java-decompiler "jad" you can get quite nice
> code from this.
True, but in-source documentation would be nice:)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by Florian Lindauer <fl...@secure-net.de>.
> My next step is to look at the Village code to see if I can make it
> support CLOBS. Unfortunately I can't get to working-dogs.com. Is anybody
> else having this problem? Is there a mirror site/CVS?
I also tried to get there today, it seems they are no longer
online - perhaps we must fear the worst ;)
But at least the turbine developers who are using it should
know about..
You do not really need the source from there - you have the jar.
And with the java-decompiler "jad" you can get quite nice
code from this.
--
Florian Lindauer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by mad <ma...@madworld.com>.
> > My assumption also is, that village can't handle BLOBs/CLOBs.
> > If anyone uses these successfully, it would be of interest!
> >
> > My solution now was mapping the Turbine-BLOB to LONG RAW in
> > db.props. As I understand it, the only difference is that BLOBs
> > can have max. 4GB, LONG RAWs only 2GB. Should be enough :)
> > Hope it really works in the long run.
>
> Thanks Florian! I thought about using a LONG but I need to be able to
> use a WHERE clause against it and LONGs don't support WHERE clauses.
>
> My next step is to look at the Village code to see if I can make it
> support CLOBS.
OK, here is my solution...
Download village from the CVS...
http://share.whichever.com/index.php?SCREEN=village
To fix the NumberFormatException you must change Column.java in the method
populate...
this.precision = rsmd.getPrecision (columnNumber);
...replace it with...
try {
this.precision = rsmd.getPrecision(columnNumber);
}catch ( NumberFormatException nfe ) {
// This may happen if the precision is too large for an int
// see bug #4625851 in the JDC (http://developer.java.sun.com/developer/bugParade/bugs/4625851.html)
this.precision = Integer.MAX_VALUE;
}
I believe that the Village developers are making a patch for it...
http://share.whichever.com/pipermail/village-dev/2002-March/000044.html
The second problem is that Village doesn't know how to select a Clob into
a com.workingdogs.village.Value Object. Where Value.java checks the type
I've added CLOB...
public Value(ResultSet rs, int columnNumber, int type) throws SQLException {
...
switch (type()) {
case Types.CLOB: //
valueObject = readClob(rs,columnNumber);
break;
case Types.BIT:
String tmp = rs.getString(columnNumber);
...
...and then the readClob method...
public static String readClob(ResultSet rs, int i) throws java.sql.SQLException {
Clob clob = (Clob)rs.getObject(i);
BufferedReader br = new BufferedReader(clob.getCharacterStream());
StringBuffer sb = new StringBuffer();
String nextLine = "";
try{
while((nextLine = br.readLine()) != null){
char[] ca = nextLine.toCharArray();
sb.append(nextLine+"\n");
}
}catch(IOException e){
e.printStackTrace();
}
String ColumnValue = sb.toString();
return ColumnValue;
}
-----------
Then build the jar to replace the village library in WEB-INF/lib and poof
it works. I'm assuming that a BLOB would be very similar.
Hope this helps.
-mad
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by mad <ma...@madworld.com>.
> > I'm trying to use the TDK (Turbine 2.1) to create an application that
> > hits an Oracle 8i db. One of my fields is a CLOB...
> > <column name="VALUE" type="CLOB"/> When I try to do a doSelect() on
> > this Table I get this Exception... java.lang.NumberFormatException:
> > 4294967295
> My assumption also is, that village can't handle BLOBs/CLOBs.
> If anyone uses these successfully, it would be of interest!
>
> My solution now was mapping the Turbine-BLOB to LONG RAW in
> db.props. As I understand it, the only difference is that BLOBs
> can have max. 4GB, LONG RAWs only 2GB. Should be enough :)
> Hope it really works in the long run.
Thanks Florian! I thought about using a LONG but I need to be able to
use a WHERE clause against it and LONGs don't support WHERE clauses.
Right now I'm using a Varchar2 while I'm developing the rest of the
app but before it goes into production I'll have to find a way to store it
in a larger field.
My next step is to look at the Village code to see if I can make it
support CLOBS. Unfortunately I can't get to working-dogs.com. Is anybody
else having this problem? Is there a mirror site/CVS?
Thanks,
-madison
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Oracle CLOB
Posted by Florian Lindauer <fl...@secure-net.de>.
> I'm trying to use the TDK (Turbine 2.1) to create an application that hits
> an Oracle 8i db. One of my fields is a CLOB...
> <column name="VALUE" type="CLOB"/>
> When I try to do a doSelect() on this Table I get this Exception...
> java.lang.NumberFormatException: 4294967295
Hi,
I was just getting the exactly same Exception trying to work with
a BLOB on Oracle - using turbine-2.2-dev (from Jun 2001). Upgrading
village to 1.5.3-dev did not help.
With me, it was on saving an object, but it happened (see this
with network sniffer) on the "select .. where 1=-1" which seems
to be used to get the columns, even before an insert was tried.
So its quite the same thing, obviously.
My assumption also is, that village can't handle BLOBs/CLOBs.
If anyone uses these successfully, it would be of interest!
My solution now was mapping the Turbine-BLOB to LONG RAW in
db.props. As I understand it, the only difference is that BLOBs
can have max. 4GB, LONG RAWs only 2GB. Should be enough :)
Hope it really works in the long run.
A bit late for you, madison, but hopefully this mail saves
others some time. And if there is some statement in here that
someone would like to correct, please do so..
--
Florian Lindauer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>