db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From siss...@insession.com
Subject Re: Documentation questions for admin manual
Date Thu, 11 Nov 2004 05:19:27 GMT
Thanks Army for the help regarding the schema error.

I have raised http://nagoya.apache.org/jira/browse/DERBY-65 for the 
encryption problem.



Army <army@golux.com> wrote on 11/11/2004 04:44:58 AM:

> sissonj@insession.com wrote:
> > Is this a bug?  Should error 42X05 have been returned even on the 
> > insert attempt?
> Technically speaking, no, I don't think is a "bug" per se, because 
> the 42Y07 that you're seeing corresponds to the 
> expected Derby behavior in the scenario you described.  What's the 
> expected behavior?  Well, it's pretty much exactly 
> what you described, which is reiterated in the following post, which
> is copy-pasted from a post to the user's list back 
> on 09/29 by Dan Debrunner: (anything I've added/marked up is 
> enclosed in square brackets)
> [ Begin quote ]
> The current schema for any connection defaults to a schema 
> corresponding to the user name, in this case [WKPOINT]. If no 
> user name is supplied then the user name (and hence current schema) 
> defaults to APP. [ NOTE: User name defaults to APP 
> for _embedded_ Derby--but for Network Server, one isn't supposed to 
> be able to connect without a user name, so there is 
> no "default"--schema will always be the user name. ]
> However even though the current schema is set to the user name, that
> schema may not exist. A schema is only created by 
> CREATE SCHEMA or creating an object (table etc.) in that schema 
> (this is implicit schema creation). Thus in your case 
> the schema [WKPOINT] does not exist.
> The one exception to this is the APP schema, which is always 
> created, though applications should not depend on that.
> So you will see the schema not exists error if your application 
> tries to access the current schema before any objects 
> have been created in it.
> [ end quote]
> So in a word, we _expect_ to see 42Y07 the first time, because the 
> it IS in fact the case that the schema does not 
> exist.  Once you create a table, the schema is created implicitly--
> so subsequent attempts to reference a non-existent 
> table will pass the "42Y07" check (because the schema now exists) 
> and then fail with 42X05.
> I.e. it's a matter of precedence: Derby checks for the schema first,
> and _then_ checks for the table name, which makes 
> sense since we can't verify the existence of the table unless we 
> know what schema it's in.  It's possible (and valid) to 
> just return a "table not found" error if the schema doesn't exist, 
> but "schema not found" is a more accurate description 
> of the problem...
> >>**Q2** Is the documentation for the section "Encrypted UserID and 
> >>Password" out of date?  Do you need the IBM JCE if you are running the 

> > Sun JRE 1.4?
> While Derby embedded supports the "encryptionProvider" connection 
> attribute to specify a non-IBM encryption provider 
> (such as Sun's), the Network Server currently does not.  A glance at
> the java/drda/org/apache/derby/impl/drda file shows 
> that "IBMJCE" is actually hardcoded into the server.
> That is something that will need to change at some point; not sure 
> how hard/easy it would be to change the Server to 
> accept other encryption providers, but it might be worth filing a 
> JIRA enhancement request...?
> Army

View raw message