Hi all,
It seems that the problem was related to the database user for unit
testing having dba privileges. That was causing me other grief (more
later) so I removed it an suddenly that other error (problem reverse
engineering pk or something) went away. Cool huh?
The problem which led me to this solution was that the Oracle
getMetaData returns ALL visible tables, which for dba was all user
tables. If the test db tables existed in another user (which for me
they did), then the test setup saw them and tried to delete them, even
if the actual *test* user didn't have them. For Oracle at least (with a
schema per user), the TABLE_SCHEM returned by getMetaData is the user
name. We could filter on TABLE_SCHEM using the login name from the
connection info, but that might not be a generic way to do it for every
rdbms. Is there perhaps a need to shunt the the table list obtaining
code into the DB Adaptor, allowing Oracle at least to override it for
it's own purposes? JDBCAdaptor could just do what it the DBTest setup
does now.
Or do we need to be able to specify the schema as part of the connection
information (not sure about this option) and thus filter that way.
Obviously it's not common for the test user to have dba privs (that was
actually my mistake.. granting everything instead of actually thinking
about what was required). So, it may not be necessary to do anything.
Comments?
Craig
This archive was generated by hypermail 2.0.0 : Thu Nov 07 2002 - 21:29:17 EST