Can we make it lazy load property? IIUC this requires querying the mapping table, but don't use referenced endpoint count for every use case.

The endpoint count can be removed - we can infer this with the length of the mappings present in the model binding table. This is safe to delete.

Why do we need to store this within the mapping entity?

The goal here is to minimize the query complexity on the front-end. Without having this embedded within this entity (we use it directly in the UI when populating the model information card for an endpoint), we would have N queries for each model that attached to an endpoint and then perform client-side joins to populate the page.
While this wouldn't be my choice in design for SDK / cli APIs, I intentionally went with this approach here for the UI in order to minimize the front end complexity and to reduce page render time.

example: EndpointDetailsPage.tsx directly accesses the result of the return of this entity.

I think this should also be queried lazily

The primary use of this in the UI is to display critical information in order to populate the reference fields that are directly displayed. We don't really have a use case in the UI display for non-eager return of this in the main endpoint listing page.
Where we directly need this:

1. Provider filtering (providers are mapped to models, not to endpoints as an endpoint can fallback to using a model from a different provider)
2. Displayed model contents for each endpoint for link references to the models details page entries
3. Rendering of named models and underlying provider model names

If scale is a concern, I think we can introduce pagination in the future (i.e. users create thousands of endpoints), but the alternative (lazy loading) for the UI would be many queries being issued in order to populate the required aspects of the list page, dramatically increasing the front end complexity and forcing spin-loading elements within the page.

Thanks for the clarification! It makes sense to include model mapping in the entity to show the model names on UI and allow filter based on it.

Where do we plan to display this?

The endpoint name is displayed on the main list page, in the model mappings detail pages, and in the key mapping details pages.

Why is this a part of a binding entity?

This was originally intended to fulfill the 'filter the models for a single-model use resource_id' but it's overly complicated and doesn't need to be overloaded in this. We don't use this field in the UI and splitting out the resource-based binding information into a separate API is far simpler and more tailored to what is needed. I'm going to simplify this and then add the dedicated API for resources to fetch their binding information.

Can we name this gateway_endpoint.py or add a docstring at the top explain these models are used within Gateway? The term "endpoint" "model" "resource" is pretty generic without that context.

yeah I'll preface these with gateway so that it's easier to see their relationships ontologically

What is the purpose of these entities? I casually read through the remaining stack but didn't find a usage. If we need these, can we define this somewhere in more limited scope than general entities to avoid confusion with ModelDefinition and Endpoint entities?

These are the interfaces for the downstream access of decrypted secrets server-side. They won't be exposed in the rest interface (non-public). The sql store will have the implementation that returns these with an internal RPC.

Can we move these entities into different module? All classes under mlflow/entities are for public interface. Also it doesn't need to be _MlflowObject subclass then cuz we probably want to be stricter about the print and serde method, rather than using its base methods.

yep! Since these are entirely UI-only I'll migrate them to make it clear that they're isolated. Good call.

I'm not sure these tests (test_endpoint.py and test_secrets.py) are meaningful.... they are basically only testing default dataclass constructor right...?

Yeah in this PR they're nonsense stubs. The full test suite is added with the addition of the from_proto() / to_proto() methods in the rest branch.

Can we remove these tests? I saw rest branch adds more tests, but my point was we don't want to have non-useful tests, because that makes the code lengthy and can hide important details.

Minor documentation inconsistency: Line 11 says "Store encrypted API keys..." while the identical class in gateway_secrets.py says "Secrets store encrypted API keys...". While mlflow/entities/secrets.py exists, it's not imported in __init__.py - only gateway_secrets.py is imported. This file appears to be unused and should likely be removed to avoid confusion, or the import should be updated to use this file instead.

Let's remove this file

There's a typo in the docstring: "cryptopgraphic" should be "cryptographic".

@BenWilson2 What does the unit of weight here? Is it percentage?