Re: HQLPanelController question

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: HQLPanelController question

Robert Manning
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.

Rob


On Sun, Mar 8, 2009 at 12:03 PM, Gerd Wagner <[hidden email]> wrote:

> Hi all,
>
> finally I make it to come back to the point below.
>
> As far as I understand things now the concept of CustomQueryTokenizers goes
> quite a bit beyond the three simple Session Properties we had before. So
> simply replacing the properties in Session Properties may turn out
> inadequate.
>
> On the other hand I think it is very important that what the user sees and
> what a Plugin programmer uses should be made clear an transparent.
>
> This is to say I suggest we give programmers a unique interface to
> Tokenizers but also find a way to adequately display a custom tokenizers
> configs in our Session Properties. I'm not sure yet how far this has to go.
> The furtherest would be to provide custom tokenizer dependent panels.
>
> At the moment I think it is not such a nice thing that for some RDBMS we
> display  props that aren't actually used.
>
> So far my 2 cents.
>
> Gerd
>
>
> Robert Manning wrote:
>>
>> Gerd,
>>
>> Is it necessary to override the user's preference for "remove
>> multiline comment" in HQLPanelController.onConvertToSQL (line 81) ? :
>>
>>         String statementSeparator =
>> _sess.getProperties().getSQLStatementSeparator();
>>         String startOfLineComment =
>> _sess.getProperties().getStartOfLineComment();
>>         QueryTokenizer qt = new QueryTokenizer(statementSeparator,
>> startOfLineComment, true);
>>         qt.setScriptToTokenize(hql);
>>
>> If it isn't then I'd propose we change the above to:
>>
>>         QueryTokenizer qt = _sess.getQueryTokenizer();
>>         qt.setScriptToTokenize(hql);
>>
>> It would be nice to keep the plugin overrides (via custom
>> QueryTokenizer) without transferring their values
>> to a Session's SessionProperties object.  Less potential confusion and
>> Guido's recent fix in Session would
>> be unnecessary. I would also like to give SessionProperties an
>> interface that removes these methods to
>> users of Session so that they are forced (unless they cast) to use the
>> QueryTokenizer which should be
>> treated as the authority for these properties.  If the override of
>> remove multi-line comment (the "true"
>> parameter above hard-codes remove multi-line comments to on,
>> regardless of what is in session
>> properties) is a hard requirement, then I would propose giving
>> IQueryTokenizer a clone method (or copy
>> constructor) and using that to get a new QueryTokenizer to hard-code
>> the value in.  What are your
>> thoughts on this ?
>>
>> Rob
>>
>
>

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Squirrel-sql-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
Reply | Threaded
Open this post in threaded view
|

Re: HQLPanelController question

Gerd Wagner-3
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

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Squirrel-sql-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
Reply | Threaded
Open this post in threaded view
|

Re: HQLPanelController question

Robert Manning
That is a good start.  Those 3 properties should get their own section
in the session props panel, and they should be disabled when a plugin
registers a custom tokenizer.  Also, a red label above them in that
section should indicate that these properties cannot be configured
here, but they can be in the Global Preferences Sheet tab for that
session's plugin.


Rob


On Tue, Mar 10, 2009 at 5:22 PM, Gerd Wagner <[hidden email]> wrote:

>
> 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
>

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Squirrel-sql-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop