Well, I've fixed my own problem. Here is a run down for anyone else who
maybe using DB2/400 (IBM's DB2 database for the AS400) with Turbine.
Since the Torque had no implementation for DB2/400, I had to peice it
together from what had been set up already for regular DB2. Here is where
the big sticking point was. The db.props for DB2 specifies to use a BLOB
for VARBINARY like so:
VARBINARY = BLOB (16777215)
So I just figured I would duplicate that for DB2/400 (However, I did have to
shorten the length due to system specific considerations)
VARBINARY = BLOB (10728640)
I ran "ant init" and voila! I had a Turbine system running on DB2/400.
We'll kind of. I was able to log in fine using turbine/turbine but
everytime I tried to create a new user I would get an "SQL Exception: type
mismatch." After a little digging, I came upon some one discussing DB2/400
and VARBINARY fields in JDBC. From what I gathered, to create a VARBINARY
in DB2/400, you do not use a BLOB (which I have determined was causing by
type mismatch error) you use a "VARCHAR FOR BIT DATA" defined like so in
db.props:
VARBINARY = VARCHAR (32000) FOR BIT DATA
After re-running "ant init" everythings humming along fine.
p.s.
One more thing. I was having problems with the Village API seeing all my
columns in my tables as "read-only" which will cause inserts/updates in
village to fail. This is due to a possible bug in the
AS400ResultSetMetaData.isReadonly() method which seems to always return
true. To fix this I altered the source code for
com.workingdogs.village.Column.populate() like so:
void populate (ResultSetMetaData rsmd, int colNum, String tableName)
{
...
if(rsmd.getClass().getName().equals("com.ibm.as400.access.AS400JDBCResultSet
MetaData"))
{
this.readOnly = false;
}
else
{
this.readOnly = rsmd.isReadOnly (columnNumber);
}
...
}
This is just a temp work-around until I find out why
AS400ResultSetMetaData.isReadonly() always returns read-only.
Regards,
Scott
-----Original Message-----
From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 19, 2001 1:28 PM
To: '[EMAIL PROTECTED]'
Subject: RE: OBJECTDATA column in the Turbine base tables...
I removed it (OBJECTDATA) from the turbine-schema.xml and re-built. I have
found that it is required because when I tried to sign on to the newapp I
received an error and the logs alerted me to the fact (via SQL exception)
that OBJECTDATA could not be found.
The real reason I asked this question in the first place is that every time
I create a new user I get an SQL exception saying that their is a type
mismatch. This only happens when I attempt to create a User and not when I
create Roles, Permissions and Groups. I'm using a DB2/400 as the target
database. I have a sneaky suspicion that this is being caused by OBJECTDATA
column and the fact that it is a BLOB. Any help on the cause of this would
be greatly appreciated.
Here is a stack trace from the turbine.log:
[Wed Sep 19 11:44:17 EDT 2001] -- ERROR --
Exception: java.lang.reflect.InvocationTargetException
Stack Trace follows:
java.lang.reflect.InvocationTargetException: java.sql.SQLException:
Statement was INSERT INTO TURBINE_USER ( USER_ID, LOGIN_NAME,
PASSWORD_VALUE, FIRST_NAME, LAST_NAME, EMAIL, LAST_LOGIN, OBJECTDATA )
VALUES ( ?, ?, ?, ?, ?, ?, ?, ? ) SQL Error:Data type mismatch.
at com.workingdogs.village.Record.saveWithInsert(Unknown Source)
at com.workingdogs.village.Record.save(Unknown Source)
at com.workingdogs.village.Record.save(Unknown Source)
at
org.apache.turbine.om.peer.BasePeer.insertOrUpdateRecord(BasePeer.java:860)
at org.apache.turbine.om.peer.BasePeer.doInsert(BasePeer.java:764)
at org.apache.turbine.om.peer.BasePeer.doInsert(BasePeer.java:657)
at
org.apache.turbine.services.security.db.DBUserManager.createAccount(DBUserMa
nager.java:399)
rethrown as org.apache.turbine.util.security.DataBackendException: Failed to
create account 'foo': Statement was INSERT INTO TURBINE_USER ( USER_ID,
LOGIN_NAME, PASSWORD_VALUE, FIRST_NAME, LAST_NAME, EMAIL, LAST_LOGIN,
OBJECTDATA ) VALUES ( ?, ?, ?, ?, ?, ?, ?, ? ) SQL Error:Data type mismatch.
at
org.apache.turbine.services.security.db.DBUserManager.createAccount(DBUserMa
nager.java:404)
at
org.apache.turbine.services.security.BaseSecurityService.addUser(BaseSecurit
yService.java:392)
at
org.apache.turbine.services.security.TurbineSecurity.addUser(TurbineSecurity
.java:430)
at
org.apache.turbine.flux.modules.actions.user.FluxUserAction.doInsert(FluxUse
rAction.java:133)
at java.lang.reflect.Method.invoke(Native Method)
... Miscellanous stack info removed for clarity :)
Thanks,
Scott
-----Original Message-----
From: John McNally [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 19, 2001 12:45 PM
To: [EMAIL PROTECTED]
Subject: Re: OBJECTDATA column in the Turbine base tables...
In the user table it is used to store the hashtable of user attributes.
If you store nothing using User.setPerm(), then you do not need it. I
do not think the objectdata columns in the other tables are used, but
could be wrong. There are probably references to the user objectdata
column due to its being used as I described, but you are free to chop
away on your local versions of turbine all you want.
john mcnally
"Weaver, Scott" wrote:
>
> is it really necessary? Could someone explain what it is used for? Can I
> remove it from the turbine-schema.xml and rebuild? If I do that will
> Turbine still function correctly?
>
> Thanks,
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
