SQuirreL SQL Client

On 8/7/07, Law, Bill <blaw@...> wrote:
> Greetings,
>
> Following instructions found on your website we have downloaded and
> installed SQuirreL SQL 2.5 including its source code.  After creating an
> Eclipse 3.2.1 project from the source code as per the instructions we
> attempted to build the project using Java 5.0 compliance with Java 6.0.
> But it fails with 149 errors and 2517 warnings.  Attached below is the
> first 100 of each from the Eclipse Problems View.  What am I doing
> wrong?
>
> 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
>
>
> Errors (100 of 149 items)
> The type MockResultSet must implement the inherited abstract method
> ResultSet.getHoldability()
> squirrelsql/test/src/net/sourceforge/squirrel_sql/mo/sql
> MockResultSet.java      line 31 1186498280237   26276

This test ResultSet implementation is Java 5.  It doesn't implement
getHoldability which is specified in Java 6:

http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getHoldability()

So somehow you are compiling with Java 6 (even though you told Eclipse
to allow Java 5 compatibility).  I use Eclipse in this configuration
without any problems.  What does your Java build path specify in the
Libraries tab for "JRE System Library"? (Mine shows jars that live in
1.5.0 jdk directory)

Rob

Hi Rob,

Thank you for the response.  You are correct, it was using 6.0
libraries.  I switched to a JDK 5.0 environment and all of the build
errors are now gone.

However, there are still 2495 warnings concerning use of deprecated
methods, unread local variables, unused imports, undeclared
serialVersionUID, non-static access, and cast type safety.  Of course,
these can all be set to 'Ignore' in the Eclipse Java Compiler settings.
Is this what is needed for the SQuirreL SQL code and what the
development team recommends?

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


-----Original Message-----
From: Robert Manning [mailto:robert.m.manning@...
Sent: Friday, August 10, 2007 5:33 PM
To: Law, Bill
Cc: squirrel-sql-develop@...
Subject: Re: [Squirrel-sql-develop] Fail to build SQuirreL SQL 2.5


On 8/7/07, Law, Bill <blaw@...> wrote:
> Greetings,
>
> Following instructions found on your website we have downloaded and
> installed SQuirreL SQL 2.5 including its source code.  After creating
an
> Eclipse 3.2.1 project from the source code as per the instructions we
> attempted to build the project using Java 5.0 compliance with Java
6.0.
> But it fails with 149 errors and 2517 warnings.  Attached below is the
> first 100 of each from the Eclipse Problems View.  What am I doing
> wrong?
>
> 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
>
>
> Errors (100 of 149 items)
> The type MockResultSet must implement the inherited abstract method
> ResultSet.getHoldability()
> squirrelsql/test/src/net/sourceforge/squirrel_sql/mo/sql
> MockResultSet.java      line 31 1186498280237   26276

This test ResultSet implementation is Java 5.  It doesn't implement
getHoldability which is specified in Java 6:

http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getHoldabi
lity()

So somehow you are compiling with Java 6 (even though you told Eclipse
to allow Java 5 compatibility).  I use Eclipse in this configuration
without any problems.  What does your Java build path specify in the
Libraries tab for "JRE System Library"? (Mine shows jars that live in
1.5.0 jdk directory)

Rob

On 8/13/07, Law, Bill <blaw@...> wrote:
> Hi Rob,
>
> Thank you for the response.  You are correct, it was using 6.0
> libraries.  I switched to a JDK 5.0 environment and all of the build
> errors are now gone.
>
> However, there are still 2495 warnings concerning use of deprecated
> methods, unread local variables, unused imports, undeclared
> serialVersionUID, non-static access, and cast type safety.  Of course,
> these can all be set to 'Ignore' in the Eclipse Java Compiler settings.
> Is this what is needed for the SQuirreL SQL code and what the
> development team recommends?


We switched to JDK 5 as of 2.4 (about 7 months ago).  I would guess
that most of those warnings were exposed as of JDK 5.  While we've
been accumulating them unknowingly since 2001, I'd say we've made
great strides toward eradicating them in the last six months.  You
should checkout the source code from the trunk if you intend to do any
development or just study the code.  I think you will agree that there
are far fewer issues such as the ones you;ve mentioned - though we
still have a ways to go!  So stay tuned.

Rob

> Greetings,
>=20
We are considering using SQuirreL as the base platform for developing a
plugin which provides creating, deleting, editing, and browsing of SQL
metadata objects for one of our own database products.  Much like is
provided by the pgAdmin tool.  Of special interest is updating metadata
for foreign databases, foreign tables, regular tables, native files,
views, and users.  We would prefer to do things the SQuirreL way, and
better yet to take advantage of existing, or soon to exist, SQuirreL
features.  But SQuirreL 2.5 seems to currently be a little weak in the
areas of editing metadata.

In general, what are the SQuirreL team's plans or roadmap for providing
metadata updatability?
In particular, does the SQuirreL team recommend and plan to enhance the
Refactoring plugin?

> 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 9/12/07, Law, Bill <blaw@...> wrote:
> > Greetings,
> >
> We are considering using SQuirreL as the base platform for developing a
> plugin which provides creating, deleting, editing, and browsing of SQL
> metadata objects for one of our own database products.  Much like is
> provided by the pgAdmin tool.  Of special interest is updating metadata
> for foreign databases, foreign tables, regular tables, native files,
> views, and users.  We would prefer to do things the SQuirreL way, and
> better yet to take advantage of existing, or soon to exist, SQuirreL
> features.  But SQuirreL 2.5 seems to currently be a little weak in the
> areas of editing metadata.
>
> In general, what are the SQuirreL team's plans or roadmap for providing
> metadata updatability?
> In particular, does the SQuirreL team recommend and plan to enhance the
> Refactoring plugin?

I wrote the refactoring plugin and it meets my needs at present.  As
far as enhancements go, the features I would probably work on next
would be the ability to add/modify/drop indexes and FKs.

To support a new database, there is a bit of work to be done
developing a dialect for it.  I would need an SQL reference guide for
the database that explains the grammar for adding/dropping/modifying
columns and primary keys as well as a description of supported data
types and their precision or maximum length.  Ideally, I would be able
to connect to a running instance of the database for testing.  This
isn't strictly necessary, but it helps to speedup iterations.  You
contrasted "foreign tables" with "regular tables".  Can you explain
the difference between the two?  What is your database implementation
called?

I'm currently developing a difference plugin that will allow you to
compare all columns in two tables for differences.  I'm wrapping that
up at the moment, and I don't know at the moment when I'll get back to
adding refactorings.

Rob

> Greetings,
>=20
What is the proper way for a plugin developer to add new objects to the
SQuirreL object tree?  For example, if we have an object tree that looks
like the following:
	SUPRARAK BURRYS
	    + SYSTEM TABLE
	    + TABLE
	    + VIEW
then we would like to be able to add a new object called FOREIGN TABLE
as follows:
	SUPRARAK BURRYS
	    + SYSTEM TABLE
	    + FOREIGN TABLE
	    + TABLE
	    + VIEW

It seems that only already known types can be added, and that they can
only be added as subnodes of already existing nodes instead of as top
level nodes.  We would like to be able to add new top level nodes.  In
fact in the more general case we might like to be able to completely
control the contents of the object tree deleting all existing nodes and
adding our own.  Is this even plausible and/or reasonable?

> 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 9/26/07, Law, Bill <blaw@...> wrote:
> > Greetings,
> >
> What is the proper way for a plugin developer to add new objects to the
> SQuirreL object tree?  For example, if we have an object tree that looks
> like the following:
>         SUPRARAK BURRYS
>             + SYSTEM TABLE
>             + TABLE
>             + VIEW
> then we would like to be able to add a new object called FOREIGN TABLE
> as follows:
>         SUPRARAK BURRYS
>             + SYSTEM TABLE
>             + FOREIGN TABLE
>             + TABLE
>             + VIEW
>
> It seems that only already known types can be added, and that they can
> only be added as subnodes of already existing nodes instead of as top
> level nodes.  We would like to be able to add new top level nodes.  In
> fact in the more general case we might like to be able to completely
> control the contents of the object tree deleting all existing nodes and
> adding our own.  Is this even plausible and/or reasonable?

Have you looked at the Firebird plugin?  It creates new types in
IObjectTypes and registers top-level expanders for the object tree.
The top-level nodes I see in the ObjectTree when I connect to a
Firebird database are GENERATORS and DOMAINS.  It achieves this via
it's own DatabaseExpander which it registers as an expander for
DatabaseObjectType.SESSION in FirebirdPlugin:208.  The
DatabaseExpander then creates child nodes GENERATORS and DOMAINS.
Perhaps you could model your new object tree nodes by studying the
Firebird plugin?

Rob

On 9/27/07, Law, Bill <blaw@...> wrote:
> Hi Rob,
>
> Thank you for the pointer to the Firebird plugin for this.  It was quite
> helpful and I was able to completely replace the object tree just as we
> might desire.
>
> But, we also might wish to keep the current object tree and merely add
> new top level objects as described below.  Firebird does not seem to
> show a way to do this.  Can you help with this question also?

Here is a link to a screencap of my Firebird session's object tree:

http://squirrel-sql.sourceforge.net/downloads/firebird_object_tree.jpg

The tree has the following structure:

Firebird (local - dbcopydest)
+
+ - SYSTEM TABLE
+ - TABLE
+ - VIEW
+ - PROCEDURE
+ - UDT
+ - GENERATORS
+ - DOMAINS
+ - INDEX

DOMAINS and GENERATORS are new top-level nodes unknown to SQuirreL
except by introduction from the Firebird plugin.  Are these not
analogous to your FOREIGN TABLE
node?

Rob

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.

Cheers, Bill Law  :-)
Cincom Systems Inc.,  http://www.cincom.com

> 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