Good point, Mike. And, I may have discovered that we already have a mechanism to skip these types of "system tables". I see that we have defined systemSchemas and systemTables that will be compared against before allowing the use of a given table definition. I haven't figured out all of the ins and outs of this approach, but it looks workable. Thanks for the idea.
Kevin On 8/16/07, Michael Dick <[EMAIL PROTECTED]> wrote: > > <snip> > > The question I have is whether this could be changed to pull the userid > from > > the Connection object, if the configured schema name is null, of course. > > This way, if the user has configured a schema name, it would be > > used. But, > > if no schema name is configured, then we would use the userid of the > > Connection object. If there is no security associated with a given > > database > > (ie. Derby), this would still default to null and we'd be processing as > we > > do today. But, in the case of secure databases (ie. DB2, Oracle, etc), > we > > would use the userid from the Connection object. > > > > Would there be a problem with this approach? > > > I think this approach would work for DB2, but I'm not convinced it's the > correct thing to do. > > I don't like the idea of assuming that the username is also the default > schema name. I believe that happens to be the case for many databases but > I > don't know whether it's mandated by the specification. > > Even if it is recommended / mandated by the SQL or JDBC spec(s) we'd be > ignoring any DB specific settings. MikesPhonyDB might allow users to > specify > a default in a properties file. This is a bad example, but in this case we > should let the Database determine the appropriate schema to use. > > That being said I haven't looked at the code in this area and there might > be > a better way to query for a table. > > -Mike >
