db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ken gen" <general...@gmail.com>
Subject Re: Using DRDA server but not derby SQL engine
Date Mon, 15 Oct 2007 11:01:46 GMT
>
> > I'm trying to work out how easy it would be to leverage the Derby DRDA
> > server endpoint, but instead of passing requests/queries to the SQL
> engine,
> > forward them to my application code directly. I'd like to use something
> like
> > JXPath, JoSQL or Quaere to actually generate resultsets and return them.


I think DRDAConnThread would be the best place.


This class is pretty opaque on first reading. Is there a single point at
which a SQL statement is parsed, or is the protocol/state machine much more
complicated than that? I see methods like
*parseEXCSQLIMM<http://db.apache.org/derby/javadoc/engine/org/apache/derby/impl/drda/DRDAConnThread.html#parseEXCSQLIMM%28%29>
*().  Is it feasible to split out the SQL/Derby interface from the DRDA
adapter, or are they too intertwined?  Ideally, I still like to plug and
play with query implementations, but I suppose it depends on how much SQL
knowledge is contained in the client side as well, or whether it's simply a
network end-point with text pass-through, or it understands the SQL syntax
itself.

An easier way might be
> to use table functions, which will be present in the next Derby release
> (10.4). See https://issues.apache.org/jira/browse/DERBY-716 for
> details. With table functions, your application can generate the result
> sets and you don't need to modify the Derby code. Rick recently uploaded
> some demo code to this location:
> https://issues.apache.org/jira/browse/DERBY-3129


Will take a look at the demo code, at first glance it looks like a good
option. What're the timescales on 10.4?

Are there any docs describing how (if) Derby can unload a stored procedure
(/ table function) definition, without restarting the server? I'm thinking
along the lines of independent class loaders, similar to JSPs in a servlet
engine. This would obviously allow much faster development times and be
similar to T-SQL/PLSQL procs in other DBs.

If this new functionality sounds interesting, please try it out and let
> us know what you think. (You need to download the development sources
> from http://db.apache.org/derby/dev/derby_source.html or a nightly build
> from http://dbtg.thresher.com/derby/bits/ to test it.)


Will give it a try, once I get my head around the various bits (and get it
all building).

Thanks for the advice.

Cheers.

Ken.

Mime
View raw message