The issue isn’t a problem with our loading of the catalog objects. The routines’ specific names are correctly being loaded. The deficiency is in the
org.eclipse.datatools.sqltools.core.ProcIdentifier interface which doesn’t deal with specific
names.
The question is how to gain comfort with making a change that can affect other vendors’ use of the
ProcIdentifier interface. That interface is used to determine which UDF was selected when the
Edit or Run actions are being performed. The ProcIdentifier has no notion of the routines’
specific names. This is what I need to change.
The
ModelUtil.findProceduralObjectFromSchema() method is used to search for the routine described
by a ProcIdentifier to determine which routine is being operated on. Because the
ProcIdentifier doesn’t record the routine’s specific name,
findProceduralObjectFromSchema simply searches for the first routine it finds whose
getName() value equals the
ProcIdentifier.getProcName() value. This is wrong when there are multiple UDFs with the same
getName() value but are distinguished by their specific names.
I have created a new interface,
ProcIdentifier2, which extends
ProcIdentifier. I have changed
ProcIdentifierImpl to implement the extended interface. I’ve changed the search in
findProceduralObjectFromSchema to check to see if the
ProcIdentifier it’s given is an instance of
ProcIdentifier2 and, if so, includes the specific name in the determination of whether it has
found the proper routine. If it is not a ProcIdentifier2, merely a
ProcIdentifier, the current check of just the name will continue to be used which returns the
first routine with the matched name and does not necessarily return the correct overloaded routine.
I believe that my changes will not break existing code. The problem is I don’t have access to all the vendors’ databases and their implementations of the
DBHelper that provides the
ProcIdentifiers for the routines being run or edited.
So my question is how I can get greater confidence that my changes won’t be harmful? Do I commit the changes and ask the community to try the affected actions
to make sure that they work as before (or work better if they also have the problem I’m fixing)? I’m beginning to think that is about the only way to do it.
I just don’t want to break anything and have the problem be discovered after it’s too late to fix things. But as it is, things are already broken and need to
be fixed.
--Charles
From: dtp-dev-bounces@xxxxxxxxxxx [mailto:dtp-dev-bounces@xxxxxxxxxxx]
On Behalf Of Brian Payton
Sent: Friday, December 16, 2011 2:24 AM
To: DTP development mailing list
Subject: Re: [dtp-dev] Testing an extended interface
Hi Charles,
Which database type are you working with? Perhaps this is a catalog loader problem for that particular database. The SQL model includes a method "getSpecificName" on the Routine class. So if
the catalog loader loads the information properly when the SQL model is instantiated, you should be able to get the procedure's specific name. Or am I missing the problem? Perhaps this not a SQL model problem but a tooling problem?
Regards,
Brian
Brian Payton
Data Tools Development
IBM Silicon Valley Laboratory
From: "Eutsler, Charles" <Charles.Eutsler@xxxxxxxxxxxx>
To: "dtp-dev@xxxxxxxxxxx" <dtp-dev@xxxxxxxxxxx>
Date: 12/06/2011 02:36 PM
Subject: [dtp-dev] Testing an extended interface
Sent by: dtp-dev-bounces@xxxxxxxxxxx
I have made a fix for
BZ 171718. The problem is that a user-defined
function’s specific name needs to be used to resolve which UDF is referenced when multiple UDFs have the same name.
The fix involves a new interface that extends an existing one (org.eclipse.datatools.sqltools.core.ProcIdentifier in the o.e.d.s.editor.core plug-in) to add a method to get the routine’s specific
name and having ProcIdentifierImpl implement the new interface. The ModelUtil. findProceduralObjectFromSchema method checks to see if the ProcIdentifier it’s looking at is an instance of the extended interface and, if so, includes the specific name in its
search for the desired procedure.
As far as I can tell, this won’t break any vendors’ implementations of the feature. But, being new to being a committer here in DTP-land, I want to know if there is anything I can do to test
the change against other vendors’ uses of the changed classes.
I looked at IBM’s Data Studio and they seem to have solved the problem in their own code somehow. Oracle’s Enterprise Pack for Eclipse but Oracle (at least the version I tried) doesn’t support
specific names so my change shouldn’t affect them. Derby doesn’t support specific names, either.
So, before I hit that Commit button, I was wondering if anyone has any suggestions of how to go about getting a bit more confidence that I’m not going to break things.
--Charles
_______________________________________________
dtp-dev mailing list
dtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dtp-dev