Add property to table objects determining if they are a view or not

AlfredBaldenweck

Related: How to Determine if the item in geodatabase is a view or not? 

Related Idea: Catalog: Add view icon

There is no way in arcpy to determine if an object is a view or a real table, or, for that matter, no easy way period to tell if an object is a view or not, even in Catalog.

Adding an isView() property would make things very easy; we would not have to resort to checking if the table is editable (error-prone) or using a naming convention ("recent_nests_VIEW") to verify our inventory of tables.

Please add some sort of property to Describe to let us do this.

Hayden Welch

Huh, I've never really used views and usually just use layer definition queries. Seems like a useful feature if it was made clear that a view is defined by a query. The view definition is even transparent to da.Describe. It lists the View as a `DEFeatureClass` and not a

You can see that a featureclass is a view if you open the properties, but that means there is an internal API that can tell that it's a view.

To add to this proposal, there should be a subtype of `DEFeatureClass`/`DETable` called `DEFeatureView`/`DETableView` or something similar. These types should have a definition property that clarifies the type.

 

Changes to arcpy/typing/describe/base.pyi:

class Table(TableBase, EditorTracking): ...
class FeatureClass(FeatureClassBase, EditorTracking): ...

+ class TableView(Table):
+     @property
+     def definition(self) -> str:
+         """The SQL Definition of the TableView"""
+         
+ class FeatureClassView(FeatureClass):
+     @property
+     def definition(self) -> str:
+         """The SQL Definition of the FeatureClassView"""

 

Changes to /arcpy/typing/describe/__init__.py

... 
DescribeDataTypes: TypeAlias = Literal[
     ...
     "VPFTable",
     "Workspace",
+    "TableView",
+    "FeatureClassView",
 ]

 

Because the code that interfaces with the View is not part of the public API currently, just adding this here and still treating the View as a `DEFeatureClass`/`DETable` internally should be very backwards compatible while allowing developers to quickly retrieve the View definitions. Because the View definition isn't editable anyways, keeping the definition property R/O is fine, this will just allow tools that pull an old definition, update the query, and replace the View with a new View.