Open darnjo opened 1 year ago
Hi everyone, I have build out the requested E/R model which can be seen here: https://downloads.t4bi.com/RESO/RESO-Meta-Model.html
Hopefully this will help everyone visualize what we are proposing more easily.
Thank You Ivaan for helping me out in simplifying it!
Thanks for the E/R model!
I see a type/naming conflict in "Field" with the E/R Model and the RCP - where the RCP has "Definition" the E/R model has "Definitions"
Well, I did that on purpose as I think the RCP is no longer correct after our discussions.
I would like to add to the discussion that MLS Grid requires that OriginatingSystemName is submitted with requests for metadata and Lookups in order to specifically return the results that pertain to that specific MLS the request is based for. The MLS Grid provides data for 25 MLS through one end point and using one bearer token. Requiring OriginatingSystemName ensures the data consumer receives only the metadata and lookups that are valid for that specific MLS. RESO supports the use of OriginatingSystemName for the other resources but not Model, Field, and Lookup. I would like to suggest that support for OriginatingSystemName should be added, or at least made optional.
Interop requested that we also add Definition to the Lookup Resource.
Has anyone reviewed the model: MetaModel? I would like us to all agree that this is what the resources both already look like and will look like for the new ones and Field.
Question because this has been the result of very poor query performance to get it to work 'correctly'. ModificationTimestamp is required orderable, but it's not a unique field, requests that order by a non unique field don't guarantee the same order on subsequent requests so during pagination you could end up with the same record twice or some not at all. Any suggestions on how to deal with this / should it be dealt with?
To support media uploads, we would like to request a boolean field be added to the Field
and Model
resources to represent the HasStream
attribute from the EDMX. This is going to be a required attribute for Add/Edit Media using the OData stream handling. Should likely be 'HasStreamYN' to conform to other boolean fields
To support media uploads, we would like to request a boolean field be added to the
Field
andModel
resources to represent theHasStream
attribute from the EDMX. This is going to be a required attribute for Add/Edit Media using the OData stream handling. Should likely be 'HasStreamYN' to conform to other boolean fields
@grispin Is this still required based on the latest proposal? I don't think so, right?
We should add that attribute to keep the Model/Field/Lookup in sync with the EDMX.
Regarding ExpandableYN
for Field
: ideally, the proposal would qualify the suitable values for ExpandableYN in similar fashion to what has been done for ReadableYN, OrderableYN, UpdatableYN, and SearchableYN. And 'expandable field' (really, a navigation property') should be ReadableYN=false (as we are returning the expanded object(s)) and also, OrderableYN=false and UpdatableYN=false.
During the RESO Developer Conference, the group approved moving the following items forward for the proposal phase.
Background
In order to make server metadata easier to work with, as well as more Data Dictionary friendly and transport agnostic, this proposal establishes requirements on the existing Field Resource and adds a new resource called "Model" to represent models of type "Resource" or "ComplexType."
The term "Resource" is used the same way the Data Dictionary uses it now, but there can be other kinds of models as well so the terminology has been generalized.
This proposal works with both OData Web APIs and RESO Common Format, and in the latter case a non-OData server could advertise their metadata in standard format using the Model, Field, and Lookup Resources.
Field Resource
The following fields will be removed from the Field Resource:
Providers MAY still use these fields for backwards compatibility, if needed, but the standard versions of these items MUST also be present in that case. Deprecated items will be treated as local in RESO Analytics.
The following fields will be added to the Field Resource:
Model Resource
A new resource called "Model" will be created with the following fields.
Usage Requirements for RESO Web API Providers
Discussed in https://github.com/RESOStandards/transport/discussions/70