OPENJPA-320 opened to address this problem.
On 8/16/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > > 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 > > > >
