Accessing Tabular Attribute Linked to Hidden Table with STK?

I have a script where I am trying to access all attribute data for records in a Table. However, one of those attributes is a Linked Tabular which links to a Table which happens to be hidden.

The STK fails to instantiate the attribute in question, since the Table is not visible, with the error of KeyError: 'No table matching that name in this database'. Is this the intended behavior? Are there workarounds for this issue?

If the table itself didn't exist, I feel like that would make sense, but since it does and is just hidden, I would expect that the attribute would just populate without data, or not get returned when I attempt to access all attributes.

Find more posts tagged with

Granta STK - Streamlined Layer

Accepted answers

Andy_Grigg

Ah, I didn't realize you were using access control! That explains it. Since you're using access control, it's not really that the table is hidden, more that it doesn't exist at all (for the user running scripting toolkit).

As far as a fix goes, we'll need to investigate and get back to you. It might be as simple as just allowing the linked table and linked attribute to be None if it can't be resolved, but that might cause some other issues downstream. We'll look into it and give this scenario a test.

Andy_Grigg

Update on this: We've identified the issue and we have a fix. It should be available in the next release of Scripting Toolkit later this year.

All comments

Andy_Grigg

I can't reproduce this. I'm doing the following:

from GRANTA_MIScriptingToolkit import granta as mpy

mi = mpy.connect("localhost", autologon=True)
db = mi.get_db(db_key="MI_Training")
for t in db.tables:
    print(t.name)
print(len(db.tables))

attr: mpy.AttributeDefinitionTabular = db.get_table("Tensile Statistical Data").attributes["Tensile test data used in this rollup"]
print(attr.linking_table)

The number of tables returned in the first half of the script is always 20, as would be expected for MI Training, regardless of which tables are hidden. The attribute definition can be correctly resolved, and the attr.linking_table property correctly refers to the 'Tensile Test Data' table, even though it's hidden in MI Admin (the last two columns are 'Browseable' and 'Searchable':

Could you please confirm the version of Scripting Toolkit and Granta MI you are experiencing this issue on? A stack trace would also be useful to help determine exactly where this error is occurring (please delete any sensitive data that might be present in the stack trace).

I am struggling to understand how this could fail in the way you've described. Service Layer returns all tables regardless of their hidden setting when doing a GetTables request, and instead relies on the client to enforce whether it is displayed. The Scripting Toolkit doesn't enforce any restriction, and so all tables should be available.

noahMDMi

Hi Andy,

Unfortunately, when testing on MI_Training I also cannot recreate the issue . It only seems to happen on the specific configuration of the MI server I am running the script against. Unfortunately, I don't have a great deal of knowledge of how the database is set up, but I do know that some of the records in the hidden table have access control enabled. I can also confirm that un-hiding the table resolves the issue.

The instance of Granta MI is 2023R2, and the version of the STK being used has been 3.1, 3.2, and 3.3 (I tried to see if upgrading would resolve the issue)

Here is the stack trace from the server (sensitive information redacted)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_record_classes.py", line 824, in attributes
    self.refresh_attributes()
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_record_classes.py", line 773, in refresh_attributes
    self._create_attribute_objects()
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_record_classes.py", line 784, in _create_attribute_objects
    self._create_empty_attribute(attr)
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_record_classes.py", line 891, in _create_empty_attribute
    new_att = _AttributeValueFactory.get(def_.type)(def_, None, self.mi, self)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_attribute_value_classes.py", line 1414, in __init__
    self.__tabular = _Tabular([], [], databaseunits=attr_def.column_units)
                                                    ^^^^^^^^^^^^^^^^^^^^^
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_attribute_classes.py", line 1172, in column_units
    self._refresh_tabular_details()
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_attribute_classes.py", line 1111, in _refresh_tabular_details
    self._get_linked_attribute()
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_attribute_classes.py", line 1079, in _get_linked_attribute
    self._linked_table = current_db.get_table(
                         ^^^^^^^^^^^^^^^^^^^^^
  File "███████████████████████████████████████████████████████████████████\.venv\Lib\site-packages\GRANTA_MIScriptingToolkit\granta\mi_tree_classes.py", line 1621, in get_table
    raise KeyError("No table matching that name in this database")
KeyError: 'No table matching that name in this database'

And also worth noting, when I check database.tables it is not showing up in the list... Could it have something to do with access control?

Andy_Grigg

Update on this: We've identified the issue and we have a fix. It should be available in the next release of Scripting Toolkit later this year.