Rick Hillegas wrote:
> don't think you need a separate class for each foreign table. I don't
> think you even need a separate method for each foreign table. At the
> end of this message, I'm including some sample code which may help
> move this discussion forward. The code has the following features:
>
> 1) There is one user-written class with one user-written method.
>
> 2) Each foreign query is backed by two pieces of Derby DDL:
>
> a) A table function which declares the shape of the foreign ResultSet
> b) A view which supplies the connection url and query string
>
Thanks, Rick. That's exactly what I needed. The dev/devguide seemed to
imply that materialization had to be done by a static read() method with
no parameters, and involving views didn't even occur to me. Between
them, they'll allow me to pass a single class what I need to in order to
customize it.
