Author Topic: How to access ForeignKey Constraint via automation (Read 10056 times)

chrvi · « **on:** July 23, 2007, 01:16:55 am »

Hi,

could anyone please help me access the Foreign Key Constraint via automation interface?
Is it through Connector Constraints collection?
And if so, how are the source columns (i.e. foreign key) and the target columns (i.e. the primary key of the target table) represented in such a connector constraint object?

Thanks.

«Midnight» · « **Reply #1 on:** July 23, 2007, 01:46:07 am »

AFAIK they are stereotyped operations.

[EDIT: The columns are the parameters, I think. Doing it this way allows the connectors to reference the appropriate source and target roles, thus 'joining' the tables.]

chrvi · « **Reply #2 on:** July 23, 2007, 07:16:25 am »

Yes, when creating a FK (manually) a new method is automatically created in the source table having the fk columns as its parameters, nevertheless to see (and set) the FK columns of the source table with the related primary key columns from the target table you had to use a Foreign Key Constraint window first. The question is what kind of data I have to set via automation to create a functional FK...
Creating only a method with columns as parameters and setting a connector's stereotype doesn't seem to be enough.

By the way, when I place my tables (created via automation) on a diagram, I can see "FK" to the left of each column name. But in fact, there's just one FK column and I have just one method called FK_tableA_tableB having just one parameter (i.e. the mentioned column). So what could I have set wrong that on the diagram all the columns have the "FK" next to them?
All those columns have stereotype <<column>> (of course) so where is the "FK" information next to column names taken from?

«Midnight» · « **Reply #3 on:** July 23, 2007, 08:09:19 am »

First, it is the association roles you need to set to link the keys together. You should be able to get at these through the AssociationEnd objects exposed by the association.

As to the second, I cannot say without seeing the table code itself.

David

chrvi · « **Reply #4 on:** July 23, 2007, 10:59:43 pm »

At http://muj3.edisk.cz:8080/7/772d490ded64c7c680d49579fece67b6/FK.png you can see a screenshot of my project generated through automation.
You can see there a diagram where both tables have "FK" next to their column name (which really amazes and annoys me).
You can also see that I have (just) one <<FK>> operation called "f1" with (just) one parameter. Nevertheless the Foreign Key Constraint window doesn't contain any source FK columns nor any related PK columns...
So I think I have to populate these somehow but don't know how to access it via automation and set the relationship among the source and target columns...

The code used to generate all the tables, their attributes and methods and connectors is rather large and complicated so I don't attach it here.
I was just wondering if I made some obvious mistake that all the table columns display the "FK" next to them (but this is happening ONLY on diagrams)

P.S. the diagram was created manually in EA simply by moving the two tables from Project Browser. The connector between them and other stuff had been set via automation before.

P.P.S. the table where the unwanted "FK"s are marked out (i.e. table ac_pair_cis) has, in fact, no <<FK>> operation at all.
I'd have rather marked all the "FK"s and "pfK"s of the second table (ac_pair_den) since this table content is displayed in the Project Browser and it is also the source table of the foreign key. However, the problem of "FK"s is actually the same in both tables displayed in the diagram...

«Midnight» · « **Reply #5 on:** July 24, 2007, 01:44:40 am »

I'm completely perplexed Radek.

BTW, are you using 7.0? I had some minor issues with keys in the first betas, but they were pretty much cleared up.

The only thing I can think of is to make a copy of the project, then either correct some of the strange tables by hand, or recreate them from scratch. Then compare the contents of the database to see where they differ. This might give some clues.

David

chrvi · « **Reply #6 on:** July 24, 2007, 04:23:11 am »

Yes, I'm using 7.0 but I don't think there's a bug in EA.
I just think I might have set something wrong but I don't have any idea what it could be...

BTW the "FK"s placed next to column names is just a tiny problem (although it drives me mad ;-) ).

The main problem is I can't set the connection between the source table FK columns and the target PK columns (as I easily would do manually in the Foreign Key Constraint window) and thus create a correct Foreign Key.
I believe there must be a way of accessing this from automation interface but I don't know how... :-(

chrvi · « **Reply #7 on:** July 26, 2007, 12:02:01 am »

Sooo...

Here is some news (in case somebody is interrested in this topic ;-) ):

1) To create a mapping from the source (FK) columns to the target (PK) columns you have to:
- create a connector between the source and target table (of course)
- create a new operation myFKOperation with the stereotype <<FK>> and parameters equal to FK columns (not a surprise)
- !!! populate myFKConnector.StyleEx attribute with data in the following way:
fkConnector.StyleEx = "FKINFO=SRC=" + myFKOperationName + ":DST=" + pkOperationName + ":;"
(where pkOperationName is a name of the method with stereotype <<PK>> in the target table which serves as primary key)

If you create a diagram now with the source and target tables and display Foreign Keys for the <<FK>> connector, you should see source FK columns associated to PK columns as desired. :-)

However, I still don't get the link label describing the related FK and PK columns as I would get if I created the FK manually in EA.
I mean the label "(fkColumnA = pkColumnA)"...

2) There is a bug in the dll for Java - if you call myAttribute.SetIsCollection(booleanValue) then myAttribute.IsCollection will always be TRUE. It doesn't metter whether booleanValue was TRUE or FALSE. It means once you call SetIsCollection method then you'll always have TRUE in IsCollection... Very funny :-)
...and the IsCollection attribute is the one displayed next to the column names as "FK".
My problem of "FK" displayed next to each column in the diagram was simply that I called SetIsCollection method for each column (either with FALSE or with TRUE parameter) and the value was always set to TRUE (due to the bug). Now I simply call SetIsCollection method only when the column IS part of foreign key. Otherwise the default (false) value remain in IsCollection and the behaviour is correct...

«Midnight» · « **Reply #8 on:** July 26, 2007, 04:03:18 am »

Well done Radek,

Still, this is progress.

When I get the chance I'll see if I can get the other part working. Since I don't go through the Java interface layer perhaps I can figure out how is should work, and you can then chip away at a known target.

David

Jeff Odell · « **Reply #9 on:** July 29, 2007, 03:31:50 pm »

At one point I was working on an add-in to get the link labels the way I wanted them on data models. I inquired to tech support at EA and got this answer. You have to set the Geometry field on a Diagram Link object.

This might help you get your diagram labels:

split on the dollar sign to split connector geometry and label info.

split on the semi-colons (;) to get an array of labels.

split on the first equals sign to split the label name and the attributes.

split on the colons (:) to get to the labels attributes.

The "HDN" attribute controls the visibility of each label.

When writing back to the Geometry field, you need to re-assemble the string. Any missing information may cause unexpected results.

«Midnight» · « **Reply #10 on:** July 30, 2007, 02:14:59 am »

Thanks Jeff,

These 'hidden' tweaks are golden.

David

Jeff Odell · « **Reply #11 on:** August 31, 2007, 11:04:05 am »

FWIW I did get the label visibility implemented in my add-in. It was tedious parsing out the string but it did work.

«Midnight» · « **Reply #12 on:** August 31, 2007, 11:17:05 am »

Jeff,

Take a look at the EA SDK. It is currently in beta, but they seem to be pushing new API tweaks and improved documentation into the SDK rather than the main user docs.

Do a search of recent (past 6-8 weeks) posts with SDK and beta. You'll find the link.

David

Jeff Odell · « **Reply #13 on:** September 03, 2007, 03:17:21 am »

I have the SDK (unless I'm missing something, the "SDK" is really reorganized information from the help file, plus a couple additional topics), but I didn't see any information on parsing the Geometry field in there.

Am I missing something?

Thanks - jlo

«Midnight» · « **Reply #14 on:** September 03, 2007, 04:54:14 am »

No Jeff,

I guess they just haven't gotten that far yet. The SDK seems to be the preferred place to document new API stuff, including new functionality. It also seems that Sparx is trying to extend the documentation to cover such things as these mysterious fields and formats.

So the message is to watch the SDK, and hope it achieves production status (and hopefully regular updates) soon.

Meanwhile, I remember seeing a post a while ago (within the past few months) from someone who had 'decoded' a lot of the line geometry. See if you can find it via the search function. Unfortunately I cannot remember anything about the thread name, nor how it was phrased. You'll have to get lucky with keywords.

David

Sparx Systems Forum

News: