Updates to user derived parameters
Bob Watzlavick
derived parameters. When you import a desktop, it looks like a new
derived parameter is successfully imported but if the parameter already
exists, it doesn't get updated. Can someone confirm this behavior?
Thanks, Bob
Jim Bretz
Correct... This is an on going discussion about "who can overwrite whom".
For now, I wanted to stay on the safe side of the discussion and "only add
the parameter and never overwrite"
So if you want the equations updated, I suggest you clear out all of the
parameters from the PD table before importing... This still doesn't solve
the problem, as the first dekstop that you import will now be "king" if the
parameter is used on another subsequent desktop (and the equation was
changed).
I agree, this is a serious issue. We all need to brainstorm for some good
ideas.
Some suggestions were to:
1) Ask the user
2) Add permissions
3) Compare some kind of date and update with the newest version
4) Go 100% Source control like and do some kind of "checkout" to edit a
parameter
Any ideas??
Jim
Jim Bretz
> Correct... This is an on going discussion about "who can overwrite whom".
> For now, I wanted to stay on the safe side of the discussion and "only add
> the parameter and never overwrite"
I forgot to mention that there is a fairly simple way to force the derived
parameters to overwrite.
It involves a simple modification of the iadsDt import file contents,
Jim
Pat
1) Always overwrite
2) Never overwrite (default)
3) Ask the user
-Pat
Watzlavick, Robert L
Where would you access this property? Would it pop up in a dialog when
you do the import or will it be an option in a configuration page
somewhere?
I'd rather have the default option to "always" or "ask". If somebody
sends me a desktop and they've changed their deriveds, why wouldn't I
want to update them? The way it is now, you're almost guaranteeing a
problem unless you go in before hand and whack all the existing user
deriveds for that user.
If you implement "always" or "ask", I assume it will only modify the
user deriveds that exist in the desktop right? It shouldn't delete any
user deriveds that don't exist in the new desktop.
-Bob
Jim Bretz
Sorry... I'm going to "inject" myself in here..
> Where would you access this property? Would it pop up in a dialog when
> you do the import or will it be an option in a configuration page
> somewhere?
Ya... Something like that... User preferences..
> I'd rather have the default option to "always" or "ask". If somebody
> sends me a desktop and they've changed their deriveds, why wouldn't I
> want to update them? The way it is now, you're almost guaranteeing a
> problem unless you go in before hand and whack all the existing user
> deriveds for that user.
I agree totally with that statement... But the real problem is this:
How do you know that the derived was "theirs"? How does IADS tell that this
derived parameter "belongs only to that user and no one else is using it". I
suppose we could check to see if it's used on any other engineer's desktop,
and if not then overwrite... But..
What if you and I are using the same derived parameter (say
"StandardDayTemp") and I go and change the equation to suit my liking? We
both export our desktop, you with the old equation, me with the tweeked
equation. Now upon importing both of the desktops, who's version wins?
>
> If you implement "always" or "ask", I assume it will only modify the
> user deriveds that exist in the desktop right? It shouldn't delete any
> user deriveds that don't exist in the new desktop.
Ahhhhhh.... Now I see why you're having a problem with this.... ;)
Derived equations are *global* assets (among other things in the PD table).
That means that the equations *always* comes from the PD Table. So there's
really only one version of it.
You can understand why we did this I'm sure. Imagine a user looking at a
display that has saved an old equation (an incorrect or outdated one)...
That possibility is just too dangerous, so we killed that possibility.
Jim
Watzlavick, Robert L
by placing each group's deriveds in a separate ParamSubGroup. We tell
people who use somebody else's derived that they are at their own risk
if the controlling group changes the derived. For deriveds that are
widely shared between groups, we put them in a separate "system_derived"
list and maintain control of them ourselves.
Having an option when importing a desktop would satisfy our needs.
-Bob
-----Original Message-----
From: ia...@googlegroups.com [mailto:ia...@googlegroups.com] On Behalf Of
Jim Bretz
Sent: Wednesday, September 06, 2006 1:55 PM
To: ia...@googlegroups.com
Subject: [IADS] Re: Updates to user derived parameters
Jim Bretz
> I can see your point about shared derived parameters. We partition them
> by placing each group's deriveds in a separate ParamSubGroup. We tell
> people who use somebody else's derived that they are at their own risk
> if the controlling group changes the derived. For deriveds that are
> widely shared between groups, we put them in a separate "system_derived"
> list and maintain control of them ourselves.
Ok... Thanx... That helps... So you kinda are assigning ownership. I agree
that this is a good direction to go.
> Having an option when importing a desktop would satisfy our needs.
So all you need to do then is just "always overwrite" and you'd be kinda ok
then...
Like I said, there is a easy way to modify the "iadsDt" file so that this
will happen. All you need to do is to write a little code that do this:
1) Finds all the "updat3" statements in the file that operate on the
"ParameterDefaults" table... Here's a cut off example of a line in the
iadsDt file:
updat3 ParameterDefaults set * = ParameterSet1|fm|||||.....
2) Replace the "updat3" statement with "update" so you get:
update ParameterDefaults set * = ParameterSet1|fm|||||.....
That's it! Now when you do an import, all the "update" statements will write
over the existing entries in the PD table. No questions asked.
The topic still needs more thought... Any one else have any ideas? (Pax???)
Jim
Watzlavick, Robert L
That workaround will do the trick for us now. We'll just run a short
Perl script on the .iadsDt file before importing it. Long term it would
be better to have it native in the program.
Thanks, Bob
-----Original Message-----
From: ia...@googlegroups.com [mailto:ia...@googlegroups.com] On Behalf Of
Jim Bretz
Sent: Wednesday, September 06, 2006 3:31 PM
To: ia...@googlegroups.com
Subject: [IADS] Re: Updates to user derived parameters
Jim Bretz
> Perl script on the .iadsDt file before importing it. Long term it would
> be better to have it native in the program.
>
> Thanks, Bob
Totally agree ;) We'll try to get this resolved ASAP.
My brain is just too tired right now to come up with a viable solution,
Jim
MattM
discussion we had about a month ago when I brought up this problem.
Bob and Pat's idea I like, where you ask the user if they want to
over-write the old entries. If the user understands all the problems
with this (that Jim pointed out), then simply allow them to use the new
entries. Sort of like when you do a copy in windows of multiple files,
and when an existing file already exists, it asks you if you want to
over-write it or not. You can then do it one at a time (maybe with the
dialog displaying both the old and new versions of the derived
equation, to help in the decision making) or a "Yes to all" button that
just replaces all of them.... A little bit more complex that the other
solution...For what it's worth...
Matt Menard
Andy
I was in some meetings this week with some IADS users. The way one
particular organization worked their Config file was to keep seperate
config files for the approve project parameters and another config file
that had all the approved derived parameters for the project. All
updates were controlled by a CM process.
The Config file process for each flight was:
1. Copy the CM Controlled Main Config file that has the Project
approved
Parameters to the control area.
2. Copy the approved CM controlled Derived config file contents to
the bottom of
the Main Config File. This means that only the derived
parameters that have
followed the correct CM process will be allowed in the flight
config file.
3. Import all the Desktops that have been approved by the FTE's
This means that any changes to derived parameters will not
over write the
CM approved derived for the Project.
4. Perform the validation check and correct all problems.
5. This Config file becomes the IADS Config file for the next
flight
I think this is a good process for keeping the Conffig file clean for
each flight. It also prevents the duplicting of parameter names when
you import an analysis window to replace one in the config file with
the same name.
So, there is some logical reason why the imports should not overwrite a
derived parameter already in the config file.
Jim Bretz
> I was in some meetings this week with some IADS users. The way one
> particular organization worked their Config file was to keep seperate
> config files for the approve project parameters and another config file
>Matt wrote:
> Sorry for getting in on this one so late. This is similar to the
> discussion we had about a month ago when I brought up this problem.
> Bob and Pat's idea I like, where you ask the user if they want to
Thank you everyone for all the feedback ;) Having all this input makes
things a *lot* easier.
We'll get back to you soon on some solution ideas soon,
Jim
Pat
Your reply points out why it's important for us as the "tool" builder
to provide options. It's this forum that helps us determine what the
set of options are and how they get presented to the end user. In
addition, we don't want to kill-off the techniques that you all have
already developed.
This applies for the IADS Load Set (ZBall) as well.