Skip to main content

Filtering and views vs containers

  • July 30, 2025
  • 2 replies
  • 40 views
R
Practitioner ⭐️

Had a chance to experiment with streams and records and it seems to be working well.  Couple of questions based on what I found:

  1. Are any of the filtering options that are available for general data modeling queries but not available with records likely to be supported in future?  Specifically, I am thinking of queries like Fetch me all of the records in the last week where the `asset` property is below `Facility-ABC` (i.e. it contains `Facility-ABC` in asset.path).  I think this would require us to use the nested filter unless the total number of assets that were below Facility-ABC was small enough to pass them directly into the filter.  I can imagine that this kind of filter is more difficult to implement and a more expensive operation, but I think it could be valuable.
  2. Is there a reason why containers rather than views must be used when creating/querying records?  It seems like a view with a specific version is nothing more than a set of containers with a (possibly incomplete) list of properties that is used in each container.  I think it is possible to translate any request for a view into a request for a list of containers, but having support for directly referencing views would likely make the api easier to use.

      2 replies

      T
      Expert ⭐️⭐️⭐️⭐️
      Forum|alt.badge.img

      Hi ​@Richard Booth,

      Are any of the filtering options that are available for general data modeling queries but not available with records likely to be supported in future?

      We can’t support “JOIN” like operations in Records, so we’re looking to the integration with Data Modeling (reverse direct relations and “filter views”) for the query pattern you’re describing. A “temporary” workaround would be to include the asset path in the record itself and build filters around the combinations. But, as stated, this _is_ a workaround for the query you’re describing.

       

      Is there a reason why containers rather than views must be used when creating/querying records?

       

      Not per se, but we wanted to use a similar/identical schema approach for defining records as we have in Data Modeling. Views are in our longer term plans, but not strictly necessary to ship the Records API in December.

        R
        Practitioner ⭐️
        • Richard Booth
        • Author
        • Practitioner ⭐️
        • August 1, 2025

        Thanks Thomas - fully understand that 1) will be technically difficult to achieve and I think between passing a list of assets to filter on or maintaining the asset path in the record itself we have some options for a workaround.  For 2) I don’t think there is anything that we would be prevented from doing by using containers so makes sense to include views as a later development.

          Terms & ConditionsAccessibility statement