db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@gmail.com>
Subject Re: Hello!
Date Sun, 02 Sep 2018 13:26:16 GMT
Thanks for that additional information, Andy. One response inline...

On 9/1/18 10:10 PM, advirmachina@gmail.com wrote:
> Rick,
>    I want to use Derby as a DRDA gateway for temporarily allowing 
> access from z/OS  and JDBC clients during an application migration. I 
> am moving several applications into a cloud environment and will be 
> able to build a fairly large "cluster" to manage the traffic. In that 
> environment my client wants to use an elastically scalable database 
> product which does not support DRDA.
>    From what I can see reading the code, the easiest way for me to 
> solve my immediate problem is to change the definition of the 
> SYSCAT schema from being a "system" one to being a normal one. Or, 
> define the ROUTINES table at initialization.
This may be relevant: Derby does not let you define a user schema which 
begins with the SYS prefix. SYS flags a reserved schema namespace which 
can only be used for Derby-internal metadata. It probably wouldn't be 
hard to hack Derby to lift this restriction, but the devil is in the 
details. For instance, one of the side-effects of this limitation is 
that objects in the SYS* namespace have read-only access--this may not 
affect you though.

Hope this helps,
> Sent from my HTC
> ----- Reply message -----
> From: "Rick Hillegas" <rick.hillegas@gmail.com>
> To: <derby-dev@db.apache.org>
> Subject: Hello!
> Date: Sat, Sep 1, 2018 17:08
> Hi Andy,
> Welcome to derby-dev. I'm not sure what you're trying to do: 1) Replace
> a DB2/LUW server with a Derby server for use by a remote application
> which uses a DRDA driver? 2) Wire a Derby server into a distributed
> query processor based on DB2/LUW? Some responses inline...
> On 8/30/18 9:32 PM, Andy Abate wrote:
> > All,
> >    I am just introducing myself to the list. My name is Andy Abate and 
> > I have been a professional developer for over 30 years. I'm deep into 
> > parsing and systems development with Java, C/C++, Assembly and a ton 
> > of scripting languages.
> >
> >    At the moment, I am working on the DRDA portion of Derby to make it 
> > compatible with LUW. I have pretty much everything working except for 
> > the validation responses for when a remote stored procedure is being 
> > defined. The LUW instance is sending a request for a bogus entry in 
> > the syscat.routines table. It is looking for something named 
> > AMP.TESTFEDERTAION which of course won't exist. Or at least wouldn't 
> > exist if the table syscat.routines did.
> Derby stores metadata for user-defined routines in SYS.SYSALIASES, along
> with metadata for other user-defined schema objects like datatypes and
> aggregates. The intricate details of each object are kept in an
> org.apache.derby. catalog.AliasInfo object, which serializes into the
> byte array stored in the ALIASINFO column of SYS.SYSALIASES. For more
> information, see the section on that system table in the Derby Reference
> Manual:http://db.apache.org/derby/docs/10.14/ref/rrefsistabs28114.html
> You can run queries directly against the metadata catalogs, but that
> entails a lot of joining. At this point in your processing, do you have
> an active Derby session and therefore a JDBC connection? If so, it might
> be simpler to work with a java.sql.DatabaseMetaData object.
> Hope I'm not talking past your real question,
> -Rick
> >
> >    I am defining the Derby database as a DB2/LUW server so it will use 
> > the DRDA driver. I'm not really sure how else to do it because I have 
> > a specific set of database types from which to choose on the LUW server.
> >
> >    Before I do something totally ugly here, I was wondering if anyone 
> > had any ideas on how to deal with this. Or at least provide the right 
> > answer to the calling LUW. What Derby is sending back right now is 
> > TABLE/VIEW doesn't exist. I can dummy the response, but that would 
> > mean interrogating all the requests. Not something I really want to do 
> > unless I absolutely have to.
> >

View raw message