Menu
▾
▴
#81 On connection set up an array of features
When a connection is made it would be very useful if it set up an array of features available. These features include information from the db2 license manager and include addition checks. For example, is ATS setup for the database. I would like to add to this list. e.g. with visual explain, a new UDF that must be setup.
Additional to this, menu items should have a new tag that checks if a feature is available and give several alternative, (1) low light item (2) hide from menu (3) perform an action alternate action which may be setup feature.
It would be nice to have this available in action scripts and may be even control what columns are displayed on a table.
This may be a way to enable ssh access when the instance is down. That is, feature for ssh access and feature for instance access. May even help with versions or tailoring for different database types. That is, menu item is shown if it is db2.
I have avoided this because of the time cost involved with having to preform check every time you activate a connection on a database. I am still resistant to the idea but after playing with your work I fully understand where you are coming from. With that said I am going to try to think of a solution to this because I think this is something we will need more then just want in the future.
One of my requirements with the TE is that we place nothing with in the database. This is fine for the level I am acting on but is impossible for your work.
SSH I am looking at and am working on something for you, same with the database versions.
The cost could be minimised by by several actions. Only perform the check on initial connection. That is reconnect doesn't perform the check. Two levels of checking, basic is done synchronously detailed async. Ajax makes this easy to achieve. Lastly checks could be merged into one sql statement by the use of union, eg select 'feature1' from (values(1)) a where exists(select 1 .....) union select 'feature2' from (value(1) where exists(select 1.....)
In a way the restriction of place nothing in the database was already breached with ATS. If DB2 was enhanced to have dynamic functions it could be avoided with visual explain. Often wondered why this wasn't introduced in compound sql.
I was thinking about this and realised it would be simple to implement and could handle versioning.
Each menu item is a html row so it can be changed to hidden or a different shading. On selection (mousedown) the first part could be to verify the release or feature. That is there is an array of features that are active.
On a state change on connection or feature, a function just needs to access each menu row and test any conditions which can be stored as a hidden column. 2 attributes are added to the menu tag one for start version number and one for end version number which are then stored in the html in the hidden attribute.
A child tag is added to the menu tag called "dependentFeature", These are stored in the hidden "td" tag in the hmtl.
Don't see this as being too hard to do.
The other area of issue are actions and table tags. I suggest these just need a start version attribute as the end should be could by the referencing tag which is either a menu, table or action. Internally these could be stored in an array where the start version is the index. Then it just a matter of just searching backwards through the entries for the right version.
feature list for DB2 version is implemented as of DB2 v4.1. But feature list for different database type is not available. The later one is low priority
done should be closed