Re: [Squirrel-sql-develop] HQLPanelController question

[Gerd W. <ger...@t-...>]

Robert Manning wrote:
> Gerd,
> 
> I agree that it is not ideal that these three properties (statement
> separator / start of line comment / remove multi-line comments) are
> displayed in the session properties as well as the plugin preferences
> sheet (each plugin that defines a custom querytokenizer provides these
> settings in that plugins preferences sheet).  And beyond that, it is
> also not ideal that changing the session properties sheet doesn't
> affect the custom query tokenizer's settings.  Perhaps a compromise
> would be to apply the settings in session properties to a session's
> query tokenizer. The main trouble that I see with this is that custom
> tokenizer's are specific to a type of session (one with a plugin that
> registers a custom tokenizer).  But "New Session Properties" applies
> globally to all "new" sessions, regardless of type.
> 
> I would like to illustrate this problem with an example. Suppose you
> have three different aliases (Sybase, Oracle and Ingres).  Now, you
> also probably have installed the Sybase plugin, the Oracle plugin and
> no plugin for Ingres (we don't have one).  New Session Properties only
> applies to the Ingres sessions, because the other two types of
> sessions have a plugin which registers it's own tokenizer and keeps
> it's own property values for the 3 properties (statement separator /
> start of line comment / remove multi-line comments) and stored
> procedure/function separator.  The statement separator is the chief
> culprit in making configuration a challenge for SQuirreL.  On Oracle
> it should be ";" for regular SQL statements and <eol> / <eol> for
> stored procedures, functions and anonymous blocks.  On Sybase, it
> should be <eol> GO <eol> or  <eol> go <eol> for all statement types.
> For ingres, it is whatever you want, but probably ";" for regular
> statements and go pick a character if you want to program stored
> procedures - your life is not so easy with Ingres because it doesn't
> have a plugin and therefore doesn't install a custom tokenizer where
> you can keep settings for all of your scripts that make them work.
> So, given the above setup, suppose a user launches squirrel and
> accesses the "New Session Properties" dialog and configures ";" for
> statement separator.  Which session type(s) should this setting apply
> to ? What will SQuirreL do to correctly parse stored procedures ?
> 
> I have to confess here, that I've never been a big fan of the dualism
> we have for session properties (New Session Properties vs. This
> Session's Properties) because it leads people again and again to
> configure "This Session's Properties" and they think that the change
> persists - that is until they launch a new session find out that it
> doesn't.  If we were going to make a change in favor of transparency,
> I'd like to see if somehow we could eliminate "New Session Properties"
> and have the "session properties" dialog be always persisted.  I
> suspect that we only needed a temporary "session-only" configuration
> simply to support session deviation on the statement separator.  Now
> that we can provide much better support for properly parsing most
> db-specific SQL that you are likely to want to run in SQuirreL, I
> don't see the great necessity for "temporary session-only" properties.
>  Perhaps if we eliminate this distinction, we could also allow the
> session properties to be populated from the custom tokenizer and also
> write them back to the plugin preferences from the session properties
> dialog.  Going one step further would be to provide a plugin API to
> allow custom session-specific properties to be registered in the
> session properties dialog itself, potentially eliminating the need for
> plugin preferences sheets altogether.
> 
> Sorry for the long email, I hope it is clear and let me know your thoughts.

I think I understand what you mean. Probably moving the tabs in "New Session 
Properies" to our Alias properties would come quite close to what you are 
saying. I see that this would be the most correct from a logical point of view. 
But I believe that users wouldn't appreciate this much of configuration. If that 
is true a compromise is needed and I suggest the following:

If a custom query tokenizer exists we should disable editing of
- statement separator
- start of line comment
- remove multi-line comments
(or at least those of the three that are predefined by the custom tokenizer) set 
them as well as we can on base of the custom query tokenizer and tell the user 
that they were set by a plugin.

That is a compromise but it makes things quite clear for users and is rather 
easy to implement. It clearly doesn't solve discrepancy between "New Session 
Properies" and custom tokenizers.


Would that be OK?


Gerd