SQuirreL SQL Client

> Greetings,
>=20
We are beginning development of prototype code for a SQuirreL plugin
which adds a new tree object called FOREIGN TABLE and we need to move
child nodes to it.  This cannot be done automatically by SQuirreL
because all of our tables, both TABLE and FOREIGN TABLE, come back as
being type TABLE and then an additional proprietary JDBC call must be
made for each table to determine whether it is a TABLE or a FOREIGN
TABLE.  This means that initially they are all listed by SQuirreL under
TABLE and none are listed under FOREIGN TABLE.  It appears we can use
methods of the classes ObjectTreeAPI and ObjectTreeNode to move the
appropriate child nodes from TABLE to FOREIGN TABLE.

Our question is where should this code be placed?  Putting it in the
plugin sessionStarted() method is too soon because the tree has not been
populated yet.  And of course it must be placed appropriately such that
if the tree is refreshed at any time in the future by the user then it
should retain proper node parentage.  Any pointers would be greatly
appreciated.

> Cheers, Bill Law  :-)
> Cincom Systems Inc.,  http://www.cincom.com
There are 10 different kinds of people in the world -- those who
understand binary and those who don't

> Greetings,
>=20
SQuirreL has objects it uses for database metadata.  SchemaInfo gets
metadata and populates a SchemaInfoCache to cache the metadata.
Interestingly, plug-ins do not seem to use these objects.  The Expander
objects in a plug-in just get meta-data directly when expanding a tree.
Why don't plug-ins seem to use the architecture?

> Cheers, Bill Law  :-)
> Cincom Systems Inc.,  http://www.cincom.com
> There are 10 different kinds of people in the world -- those who
> understand binary and those who don't
>=20

On 10/2/07, Law, Bill <blaw@...> wrote:
> > Greetings,
> >
> We are beginning development of prototype code for a SQuirreL plugin
> which adds a new tree object called FOREIGN TABLE and we need to move
> child nodes to it.  This cannot be done automatically by SQuirreL
> because all of our tables, both TABLE and FOREIGN TABLE, come back as
> being type TABLE and then an additional proprietary JDBC call must be
> made for each table to determine whether it is a TABLE or a FOREIGN
> TABLE.  This means that initially they are all listed by SQuirreL under
> TABLE and none are listed under FOREIGN TABLE.  It appears we can use
> methods of the classes ObjectTreeAPI and ObjectTreeNode to move the
> appropriate child nodes from TABLE to FOREIGN TABLE.
>
> Our question is where should this code be placed?  Putting it in the
> plugin sessionStarted() method is too soon because the tree has not been
> populated yet.  And of course it must be placed appropriately such that
> if the tree is refreshed at any time in the future by the user then it
> should retain proper node parentage.  Any pointers would be greatly
> appreciated.

Let's backup a moment and re-frame the problem.  If SQuirreL (or any
JDBC tool for that matter) asks the database driver for a list of
tables of type TABLE, then I would think that the appropriate response
would be a list of TABLE objects that did not include FOREIGN TABLE's.
 Is that not the case?  Hence, there should only ever be TABLE objects
in the object tree beneath the TABLE node.  This would greatly
simplify the mission of the plugin and wouldn't require special-case
handling code in SQuirreL's core feature set.

Rob

On 10/2/07, Law, Bill <blaw@...> wrote:
> > Greetings,
> >
> SQuirreL has objects it uses for database metadata.  SchemaInfo gets
> metadata and populates a SchemaInfoCache to cache the metadata.
> Interestingly, plug-ins do not seem to use these objects.  The Expander
> objects in a plug-in just get meta-data directly when expanding a tree.
> Why don't plug-ins seem to use the architecture?

The CodeCompletion plugin relies heavily on it.  I believe the code
completion plugin was a driving reason for the cache architecture's
creation.

Rob

On 10/1/07, Law, Bill <blaw@...> wrote:
> Greetings,
>
> In order to help us to create/design/implement a new plugin for SQuirreL
> we need to know the class hierarchy.  Is there a class hierarchy drawing
> and/or document available?  Of course we don't need to know every single
> class, there are way too many of them, but we do need a high level
> architecture.  What classes are available to be extended?  What objects,
> like _app and _session, are available?  What other special classes, like
> DatabaseExpander and SquirrelAction and BaseSessionInternalFrame, are
> there?  The questions go on and on, but one good class hierarchy diagram
> might address them all.

There is no such diagram, but I would agree that it would be helpful.
I started a wiki page here

http://squirrel-sql.wiki.sourceforge.net/SQuirreL+SQL+Client+Plugin+API

Sadly, it is not close to being complete.  Contributions are welcome
and greatly appreciated :)

Rob

On 10/3/07, Law, Bill <blaw@...> wrote:
> Hi Rob,
>
> For a JDBC call asking for tables of type TABLE I agree that the
> appropriate response would be a list of TABLE objects that did not
> include FOREIGN TABLE's.  However, that is not the case.  All of our
> tables, both TABLE and FOREIGN TABLE, come back as being type TABLE and
> then an additional proprietary JDBC call must be made for each table to
> determine whether it is a TABLE or a FOREIGN TABLE.  This is an
> architectural constraint that I am forced to live with.  The reasoning
> for this behavior is to have maximum compatibility with existing JDBC
> tools that have never heard of FOREIGN TABLE.

You mean tools like SQuirreL?  SQuirreL uses JDBC, which has never
introduced the concept of FOREIGN TABLEs.  Unfortunately, I believe
this "compatibility" scheme is difficult for us to handle without
treating it as special case :)

> We certainly do wish to avoid requiring special-case handling code in
> SQuirreL's core feature set.  In fact that's the reason for this
> question.  I was hoping you could point us to where and how to implement
> this in plugin code.  It seems either we could intercept the populating
> of the TABLE node and redirect certain tables to the FOREIGN TABLE node
> based on our proprietary JDBC call, or we could make use of methods of
> the classes ObjectTreeAPI and ObjectTreeNode to move the appropriate
> tables from the TABLE node to the FOREIGN TABLE node after the fact.  A
> concern with doing it after the fact is being sure the moves survive a
> tree refresh.  Is this possible?

It would, in my opinion, spread the concern of FOREIGN TABLES
throughout much of the framework code and bleed into other plugins as
well.  Perhaps an alternative is to write a proxy driver that SQuirreL
could use (in chorus with the actual driver) to intercept calls to
DatabaseMetaData, that would strip out the FOREIGN TABLEs from the
result of DatabaseMetaData.getTables?  This would allow the plugin
then to create them fresh in the location that you desire.

Rob