Support for Collections with more than 32767 elements

[kjourdan]

With the ever increasing sizes of models and information stored in these models (associations), the likelihood of having more than 32767 elements returned by a query (using GetElementSet) is almost certain.  Upon reaching this point, the automation tools used would need heavy re-work to address this limitation.  Mechanisms would need to be put in place to detect this condition and alert the users that the automation tools will not function.

To avoid this (and maintain backward compatibility), can new classes and APIs be defined that do not limit the count values to shorts (eg. GetElementSetExtended that returns and an EA.CollectionExt class which contains Count as an unsigned int). Changes to the automation tools would be done through search and replace in the majority of cases. Detection of this overflow condition could be done by comparing the count values returned in the two different collection classes. 

[Geert Bellekens]

As a workaround you can use SQLQuery to create your own list of elements similar to what I do for attributes or connectors.
Here is an example from my framework of how I use that to get connectors:

Code: [Select]

    public List<ConnectorWrapper> getRelationsByQuery(string SQLQuery){
      // get the nodes with the name "Connector_ID"
      XmlDocument xmlrelationIDs = this.SQLQuery(SQLQuery);
      XmlNodeList relationIDNodes =
      xmlrelationIDs.SelectNodes(formatXPath("//Connector_ID"));
      List<ConnectorWrapper> relations = new List<ConnectorWrapper>();
      foreach( XmlNode relationIDNode in relationIDNodes ) {
        int relationID;
        if (int.TryParse( relationIDNode.InnerText, out relationID)) {
          ConnectorWrapper relation = this.getRelationByID(relationID);
          relations.Add(relation);
        }
      }
      return relations;
    }
Geert

[kjourdan]

Thanks Geert. 

I have prototyped a similar "work-around" using SQLQuery but don't like the fact that the APIs provided don't support very large models and don't provide feedback that the Collection can not hold the number or elements returned. I would like to see the old Collection class and APIs superceded or at least updated to provide user feedback regarding error; new APIs / classes should be created to support large complex models. 

If the Count field is going to be declared as a short, return count as -1 to indicate the number of results is too great and can not be contained in a container; otherwise, why use a short to begin with?  Returning -1 would at least allow the automation to detect the condition and operate in a predictable manner (generate an error if count if <0 to indicate the tools must be updated to use SQLQuery or new APIs/Container classes).

[Geert Bellekens]

I'm not saying that you aren't right, just providing a workaround.

I can't keep my breath long enough to wait for Sparx to come up with a solution, so I'm often inclined to find a workaround myself.

Geert