OK, I got it set up so I can look at it.
basicPortal ( 07 in cvs) can now run war standalone,
just deploy war (so it is easy, dbcb driver is local),
and it can run unit test from a console.
When I do unit test from console I can debug and step
in via a debuger.
So I found this bug.
1 PROBLEM:
When the rowsetwriter does an updates, it creates the
prepared statment for the entire meta data.
So if I say select * from users, which is normal, it
will have a where clause for every column, say 20 columns.
Most of the columns have a null value on the retrieve.
So the prepares statment generates a where clause where
column x = null.
Of course, there are no matches to null, since null <>
null.
So the update fails if any of the columns are nullable,
which is all the time.
....
One solution is to make where column x = "*" or "%".
The other solution is just to use the PK, called "id"
allways in my case only (it would allow users to
change/write dirty data, but I can so live with that).
....
2 Very Minor problem:
It seems to go over the rowset writer 2 times to try to
update. First original than new where clause. In
general, I plan to have 40,000 concurent users with
this.... it would be nice to clean up some paths (and
reduce new(), etc).
.....
3 Very Minor problem:
If we can eliminate the bitset use, since it makes me
dependent on JDK1.4, and I like IBM VM.
.....
4 very minor problem.
The JX JDBC Postgres driver send out to many messsages,
one about not support strings. I want to use this
driver, since I will need to support BLOBs, etc.
I will CC bug in jxutil on sf.net.
tia,
eta?
Vic