This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 138304 - Renamed an operator; change not propagated into other operators use of operator name
Summary: Renamed an operator; change not propagated into other operators use of operat...
Status: REOPENED
Alias: None
Product: soa
Classification: Unclassified
Component: IEP editor (show other bugs)
Version: 6.x
Hardware: Sun All
: P2 blocker (vote)
Assignee: pvarghese
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-26 02:31 UTC by jlautz
Modified: 2008-10-16 17:48 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
After change from TupleBasedWindow0 to 2MinuteSlidingWindow (242.42 KB, image/jpeg)
2008-06-26 02:34 UTC, jlautz 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description jlautz 2008-06-26 02:31:46 UTC 
Seen with Product Version: NetBeans IDE Dev (Build 20080624112521)
Java: 1.5.0_11; Java HotSpot(TM) Client VM 1.5.0_11-b03
System: SunOS version 5.10 running on x86; ISO646-US; en (nb)
Userdir: /Users/lautz/.netbeans/sierra

I created most of an IEP process, then decided to change the names of the 
operators to be more meaningful. Unfortunately, it looks like the name
changes were NOT propagated into the subsequent operator's "queries".

For example, after changing the name of a tuple-based window operator, the select attribute
in a relation aggregator is still the old name. Screen shot is attached.

When the user validates or updates the changes "downstream", the errors because of the name changes are flagged, but the
user needs to make all updates manually. (Painful.)
Comment 1 jlautz 2008-06-26 02:34:41 UTC 
Created attachment 63474 [details]
After change from TupleBasedWindow0 to 2MinuteSlidingWindow
Comment 2 pvarghese 2008-07-23 22:36:08 UTC 
reassigning.
Comment 3 pvarghese 2008-08-06 15:53:27 UTC 
Changing this to an enhancement, as this was never supported. This fix needs the following
1. Operator attributes definition needs to be backed by the TableModel support to generate value changed Events that has
the old and new values, when an user changed the attributes. 
Today irrespective of modification or addition the table attribute entries are always removed and added and hence value
change PropertyChange events are never generated. 
2. Need to provide attribute (SchemaAttribute) references between connected operators to propagate changes from one
operator attributes to the referenced operator. Today its maintained using string literals and this does not suffice for
this functionality.
Comment 4 pvarghese 2008-10-16 17:33:50 UTC 
As discussed will not be addressed for this release
Comment 5 pvarghese 2008-10-16 17:48:16 UTC 
Reopened to be fixed in later release