ken gen wrote:
> 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?
Hi Ken,
Currently 10.4 is targetted for release late in February. Please see the
10.4 release page for more details:
http://wiki.apache.org/db-derby/DerbyTenFourRelease I'm guessing that
date will slip into March because the community also wants to spend some
cycles on a 10.3 maintenance release.
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.
Please let me know if I'm garbling your question: The user-written Java
code for functions (including table functions) lives either on the VM's
classpath or in jar files loaded into the database. If the user-written
code lives in a jar file in the database, then you can dyamically reload
the jar file in order to update the user-written code. The server stays
up and running while you reload the jar file. For the details, please
see the "Loading classes from a database" topic in the Derby Developer's
Guide at http://db.apache.org/derby/docs/dev/devguide/
More information on table functions can be found in the same manual
under the topic "Programming Derby-style table functions".
Hope this helps,
-Rick
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/
<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.
