|
From: Fabrice G. <Fab...@hc...> - 2006-02-17 16:17:46
|
Hi, Squirrel is a fabulous product and last version with choice to integrate oracle plugin is very nice. Great work guy's ;o) I have a question: There is in Squirrel the graph vizualisation (very good). Is it planned or does exist a Designer plugin ? Because it is able to do a reverse representation, wuld it be easy to create a graph, and then to applicate it to a database ?? Or does somebody know a product that could do so ? There is a market for it because it seems that DBdesigner4 is no more supported :-( and Druid does work only to create and doesn't have reverse design... If so, Squirrel would be the best product for databases client queries AND design. Thank's again for your so good contribution. Fabrice. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** |
|
From: Glenn G. <gw...@co...> - 2006-02-17 18:09:36
|
Hi Fabrice,
That sounds like a very nice feature. Would you like to build it? :-)
The following random thoughts come to mind:
- This should be do-able as a plug-in. As with any plug-in, we may need
to add some hooks to the core code for it to work, but that should not
be a problem.
- A graphical user interface for input is usually an order of magnitude
more difficult to build than a display-only interface because the user
needs to be able to not only grab and move objects, but also create
objects, insert things into them, resize them, etc. Sounds like a lot
of work, though the result could be worth it.
- Automatically generating CREATE and ALTER statements is much more
complicated than generating SELECTs because databases are much less
standardized in defining the names of their data types and how they are
defined. I'm guessing that the kind of tool you are describing would
need to have a strictly-maintained division between two sections:
- DB-agnostic code that handles the user interface and makes calls
to the.....
- DB-specific code (in plugins?) that understands the data types in
the particular DB.
For example, when the user wants to add a field to a table:
- DB-agnostic code shows the "add field" button and gets the action
command when the user clicks, and then calls the...
- DB-specific code which returns a list of the names of all the data
types within this DB...
- so the DB-agnostic code can present that list to the user for
selection
There will also be issues such as what options are allowed/required for
each data type (null/not-null, field size, etc) and, in some cases, the
exact syntax needed by the CREATE statement.
- I recall from a long time ago that some DBs did not allow ALTER on
tables after they were created. May not be a problem any more, but
something to look into.
- A decision will be needed on what to do with the result of the
design. Is it output to text files for use by another tool, or is it
executed by SQuirreL directly on the DB? What happens to data already
in the DB? What kinds of warnings should be generated about changing
the DB and possible loss of data?
- It would be good to include comments on the fields and the ability to
view and print the schema details, eg:
integer uid // unique user id
VARCHAR(6) userId // login and screen name
VARCHAR(30) userName // full name of the user
etc. Those comments can be critical to remind people of the format,
range, limits or expected use of the fields.
While it would probably be a lot of work, this could be a cool feature
for the product!
Glenn
Fabrice GONNON wrote:
>Hi,
>
>Squirrel is a fabulous product and last version with choice to
>integrate oracle plugin is very nice.
>Great work guy's ;o)
>
>I have a question:
>There is in Squirrel the graph vizualisation (very good).
>Is it planned or does exist a Designer plugin ? Because it is able to
>do a reverse representation, wuld it be easy to create a graph, and then
>to applicate it to a database ??
>Or does somebody know a product that could do so ?
>There is a market for it because it seems that DBdesigner4 is no more
>supported :-( and Druid does work only to create and doesn't have
>reverse design...
>
>If so, Squirrel would be the best product for databases client queries
>AND design.
>
>Thank's again for your so good contribution.
>
>Fabrice.
>
>**********************************************************************
>This email and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they
>are addressed. If you have received this email in error please notify
>the system manager.
>**********************************************************************
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>_______________________________________________
>Squirrel-sql-users mailing list
>Squ...@li...
>https://lists.sourceforge.net/lists/listinfo/squirrel-sql-users
>
>
>
|
|
From: Gerd W. <bir...@t-...> - 2006-02-20 21:13:43
|
Hi, I've been thinking about a designer since I finished the Graph plugin but I didn't have the time to start it. All the things Glenn mentions are true. That's why I thought of starting with something that for a first step allows you to - create new tables - create / delete foreign key constraints - create / delete indexes - add nullable columns to existing tables My idea is that the designer should not be part of the Graph plugin or a new plugin but part of the SQL-Script plugin. My hope was the design could be done in a dialog window that could be opened either from the Object Tree or a Graph. Since the designer dialog is placed in the SQL-Script plugin it will simply creates DDL-Scripts in the SQL-Editor. The designer dialog only works with one table at a time. Within the Graph plugin the user should be able to design more than one table before creating a DDL-Script. To do so the designer dialog needs to allow exports and imports of its state. The Graph plugin must be able to interpret this state and display it. Within a Graph the user should be able to: - Open the designer dialog for a table (tell the SQL-Script plugin to open the dialog and display the import data provided by the Graph) - Script all changes done in the designer (tell the SQL-Script plugin to script all import data the Graph provides). Perhaps those ideas can give you, Fabrice, or someone else the feeling that it shouldn't be too hard to begin. Of course your own ideas are needed and wanted too. As Glenn mentioned some changes to the core will be needed. Especially some extensions to the way SQuirreL allows plugins to communicate would be necessary. Best would be if the one who does the work does the needed changes on the core too. I would surely be available for questions and advice. Gerd Glenn Griffin wrote: > Hi Fabrice, > > That sounds like a very nice feature. Would you like to build it? :-) > > The following random thoughts come to mind: > > - This should be do-able as a plug-in. As with any plug-in, we may need > to add some hooks to the core code for it to work, but that should not > be a problem. > > - A graphical user interface for input is usually an order of magnitude > more difficult to build than a display-only interface because the user > needs to be able to not only grab and move objects, but also create > objects, insert things into them, resize them, etc. Sounds like a lot > of work, though the result could be worth it. > > - Automatically generating CREATE and ALTER statements is much more > complicated than generating SELECTs because databases are much less > standardized in defining the names of their data types and how they are > defined. I'm guessing that the kind of tool you are describing would > need to have a strictly-maintained division between two sections: > - DB-agnostic code that handles the user interface and makes calls to > the..... > - DB-specific code (in plugins?) that understands the data types in > the particular DB. > For example, when the user wants to add a field to a table: > - DB-agnostic code shows the "add field" button and gets the action > command when the user clicks, and then calls the... > - DB-specific code which returns a list of the names of all the data > types within this DB... > - so the DB-agnostic code can present that list to the user for > selection > There will also be issues such as what options are allowed/required for > each data type (null/not-null, field size, etc) and, in some cases, the > exact syntax needed by the CREATE statement. > > - I recall from a long time ago that some DBs did not allow ALTER on > tables after they were created. May not be a problem any more, but > something to look into. > > - A decision will be needed on what to do with the result of the > design. Is it output to text files for use by another tool, or is it > executed by SQuirreL directly on the DB? What happens to data already > in the DB? What kinds of warnings should be generated about changing > the DB and possible loss of data? > > - It would be good to include comments on the fields and the ability to > view and print the schema details, eg: > integer uid // unique user id > VARCHAR(6) userId // login and screen name > VARCHAR(30) userName // full name of the user > etc. Those comments can be critical to remind people of the format, > range, limits or expected use of the fields. > > While it would probably be a lot of work, this could be a cool feature > for the product! > > Glenn > > Fabrice GONNON wrote: > >> Hi, >> >> Squirrel is a fabulous product and last version with choice to >> integrate oracle plugin is very nice. Great work guy's ;o) >> >> I have a question: >> There is in Squirrel the graph vizualisation (very good). >> Is it planned or does exist a Designer plugin ? Because it is able to >> do a reverse representation, wuld it be easy to create a graph, and then >> to applicate it to a database ?? >> Or does somebody know a product that could do so ? >> There is a market for it because it seems that DBdesigner4 is no more >> supported :-( and Druid does work only to create and doesn't have >> reverse design... >> >> If so, Squirrel would be the best product for databases client queries >> AND design. >> >> Thank's again for your so good contribution. >> >> Fabrice. >> >> ********************************************************************** >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the system manager. >> ********************************************************************** >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log >> files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >> _______________________________________________ >> Squirrel-sql-users mailing list >> Squ...@li... >> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-users >> >> >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Squirrel-sql-users mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squirrel-sql-users > |
|
From: Glenn G. <gw...@co...> - 2006-02-21 16:14:38
|
Hi Gerd, I would suggest that the Designer function not be included in the SQL Script plugin. My reasoning is that the Designer could become a major functionality on its own, and putting it in the Script plugin would have two negative effects. One is that people who want the Scripts plugin may not want the Designer and all of its complexity, and the other is that the potentially huge amount of Designer code could make it difficult to maintain the Scripts plugin. Just my two bits. (I don't know if 2 bits is worth less than two cents, but it is certainly more international :-)). Gerd Wagner wrote: > Hi, > > I've been thinking about a designer since I finished the Graph plugin > but I didn't have the time to start it. All the things Glenn mentions > are true. That's why I thought of starting with something that for a > first step allows you to > > - create new tables > - create / delete foreign key constraints > - create / delete indexes > - add nullable columns to existing tables > > My idea is that the designer should not be part of the Graph plugin or > a new plugin but part of the SQL-Script plugin. My hope was the design > could be done in a dialog window that could be opened either from the > Object Tree or a Graph. Since the designer dialog is placed in the > SQL-Script plugin it will simply creates DDL-Scripts in the > SQL-Editor. The designer dialog only works with one table at a time. > > Within the Graph plugin the user should be able to design more than > one table before creating a DDL-Script. To do so the designer dialog > needs to allow exports and imports of its state. The Graph plugin must > be able to interpret this state and display it. > > Within a Graph the user should be able to: > - Open the designer dialog for a table (tell the SQL-Script plugin to > open the dialog and display the import data provided by the Graph) > - Script all changes done in the designer (tell the SQL-Script plugin > to script all import data the Graph provides). > > > Perhaps those ideas can give you, Fabrice, or someone else the feeling > that it shouldn't be too hard to begin. Of course your own ideas are > needed and wanted too. > > As Glenn mentioned some changes to the core will be needed. Especially > some extensions to the way SQuirreL allows plugins to communicate > would be necessary. Best would be if the one who does the work does > the needed changes on the core too. I would surely be available for > questions and advice. > > > Gerd > > > Glenn Griffin wrote: > >> Hi Fabrice, >> >> That sounds like a very nice feature. Would you like to build it? :-) >> >> The following random thoughts come to mind: >> >> - This should be do-able as a plug-in. As with any plug-in, we may >> need to add some hooks to the core code for it to work, but that >> should not be a problem. >> >> - A graphical user interface for input is usually an order of >> magnitude more difficult to build than a display-only interface >> because the user needs to be able to not only grab and move objects, >> but also create objects, insert things into them, resize them, etc. >> Sounds like a lot of work, though the result could be worth it. >> >> - Automatically generating CREATE and ALTER statements is much more >> complicated than generating SELECTs because databases are much less >> standardized in defining the names of their data types and how they >> are defined. I'm guessing that the kind of tool you are describing >> would need to have a strictly-maintained division between two sections: >> - DB-agnostic code that handles the user interface and makes calls >> to the..... >> - DB-specific code (in plugins?) that understands the data types >> in the particular DB. >> For example, when the user wants to add a field to a table: >> - DB-agnostic code shows the "add field" button and gets the >> action command when the user clicks, and then calls the... >> - DB-specific code which returns a list of the names of all the >> data types within this DB... >> - so the DB-agnostic code can present that list to the user for >> selection >> There will also be issues such as what options are allowed/required >> for each data type (null/not-null, field size, etc) and, in some >> cases, the exact syntax needed by the CREATE statement. >> >> - I recall from a long time ago that some DBs did not allow ALTER on >> tables after they were created. May not be a problem any more, but >> something to look into. >> >> - A decision will be needed on what to do with the result of the >> design. Is it output to text files for use by another tool, or is it >> executed by SQuirreL directly on the DB? What happens to data >> already in the DB? What kinds of warnings should be generated about >> changing the DB and possible loss of data? >> >> - It would be good to include comments on the fields and the ability >> to view and print the schema details, eg: >> integer uid // unique user id >> VARCHAR(6) userId // login and screen name >> VARCHAR(30) userName // full name of the user >> etc. Those comments can be critical to remind people of the format, >> range, limits or expected use of the fields. >> >> While it would probably be a lot of work, this could be a cool >> feature for the product! >> >> Glenn >> >> Fabrice GONNON wrote: >> >>> Hi, >>> >>> Squirrel is a fabulous product and last version with choice to >>> integrate oracle plugin is very nice. Great work guy's ;o) >>> >>> I have a question: >>> There is in Squirrel the graph vizualisation (very good). >>> Is it planned or does exist a Designer plugin ? Because it is able to >>> do a reverse representation, wuld it be easy to create a graph, and >>> then >>> to applicate it to a database ?? >>> Or does somebody know a product that could do so ? >>> There is a market for it because it seems that DBdesigner4 is no more >>> supported :-( and Druid does work only to create and doesn't have >>> reverse design... >>> >>> If so, Squirrel would be the best product for databases client queries >>> AND design. >>> >>> Thank's again for your so good contribution. >>> >>> Fabrice. >>> >>> ********************************************************************** >>> This email and any files transmitted with it are confidential and >>> intended solely for the use of the individual or entity to whom they >>> are addressed. If you have received this email in error please notify >>> the system manager. >>> ********************************************************************** >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through >>> log files >>> for problems? Stop! Download the new AJAX search engine that makes >>> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >>> >>> _______________________________________________ >>> Squirrel-sql-users mailing list >>> Squ...@li... >>> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-users >>> >>> >>> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >> _______________________________________________ >> Squirrel-sql-users mailing list >> Squ...@li... >> https://lists.sourceforge.net/lists/listinfo/squirrel-sql-users >> > > |
|
From: Robert M. <rob...@gm...> - 2006-02-21 18:33:54
|
Glenn, Gerd: Just a thought: The standard and optional plugins are all available in the installer now. However, we don't currently have any inter-dependencies between plugins. If we introduce one, we'll probably want to update the installer to not allow the user to install one plugin without the plugin that it depends on. In a related topic, functionality that is common to multiple plugins might best be moved to core, no? So, if scripting support is required by multipl= e plugins, would it make sense to work out a generic API and relocate it to FW? Rob On 2/21/06, Glenn Griffin < gw...@co...> wrote: > > Hi Gerd, > I would suggest that the Designer function not be included in the SQL > Script plugin. My reasoning is that the Designer could become a major > functionality on its own, and putting it in the Script plugin would have > two negative effects. One is that people who want the Scripts plugin > may not want the Designer and all of its complexity, and the other is > that the potentially huge amount of Designer code could make it > difficult to maintain the Scripts plugin. > > |
|
From: Gerd W. <bir...@t-...> - 2006-02-21 20:18:55
|
Robert Manning wrote: > Glenn, Gerd: > > Just a thought: > > The standard and optional plugins are all available in the installer now. > However, we don't currently have any inter-dependencies between > plugins. If we introduce one, we'll probably want to update the installer > to not allow the user to install one plugin without the plugin that it > depends on. There already is a dependence between the Graph and the Script Plugin. It works like this: If you use the Graph Plugin without the SQL-Script Plugin and if you try to script a table from within a Graph the Plugin tells you that it needs the SQL-Script Plugin to perform this task. Though this is the user list a little hint to the sources: See PluginManager.bindExternalPluginService(). I see the problem you are talking about. But I think it's not black and white. There are several ways to deal with the problem. The ones I see right now are: - Introduce inter-dependencies within the installer as you suggested - Move things to core as you suggested - Tell the user when a Plugin is missing to preform a task. - Declare Plugins as standard There may even be more. I'm not yet sure which one or which combination is best. At the moment I tend to just see how things are going to evolve. Perhaps the users will tell us, perhaps we are going to find out when we go on building SQuirreL's core and SQuirreL Plugins. > > In a related topic, functionality that is common to multiple plugins might > best be moved to core, no? So, if scripting support is required by > multiple > plugins, would it make sense to work out a generic API and relocate it to > FW? See above. > > Rob > > On 2/21/06, *Glenn Griffin* < gw...@co... > <mailto:gw...@co...>> wrote: > > Hi Gerd, > I would suggest that the Designer function not be included in the SQL > Script plugin. My reasoning is that the Designer could become a major > functionality on its own, and putting it in the Script plugin would > have > two negative effects. One is that people who want the Scripts plugin > may not want the Designer and all of its complexity, and the other is > that the potentially huge amount of Designer code could make it > difficult to maintain the Scripts plugin. Glenn, I see your point. The designer dialog I described could be a Plugin of its own. But I still think it would be good if it worked only on one table at a time and if you could invoke it from the Object Tree. Nonetheless, the one who's going to write it will do most of the deciding. Gerd |
|
From: Robert M. <rob...@gm...> - 2006-02-22 10:52:31
|
On 2/21/06, Gerd Wagner <bir...@t-...> wrote: > > Robert Manning wrote: > > Glenn, Gerd: > > > > Just a thought: > > > > The standard and optional plugins are all available in the installer > now. > > However, we don't currently have any inter-dependencies between > > plugins. If we introduce one, we'll probably want to update the > installer > > to not allow the user to install one plugin without the plugin that it > > depends on. > There already is a dependence between the Graph and the Script Plugin. > It works like this: If you use the Graph Plugin without the SQL-Script > Plugin and if you try to script a table from within a Graph the Plugin > tells you that it needs the SQL-Script Plugin to perform this task. Gerd, Thanks for correcting me on this. I like that behavior. Now that there is the "super" / unified installer - that contains the plugins - versioning isn't as much of an issue as it could be. Even so, I'll take a look and see what can be done with the installer when I have a chance. Rob |
