Named Query

NOTE –Named Queries are still supported (Dublin) but will be retired since we now have a tool to create custom queries on the fly.

But what if someone just wants to collect data from a piece of a model?  Or wants to pull data that is not defined as a model?    Or would like to pull data that’s related to a model, but does not want to see the entire topology in the result set?  

Since the model was complicated enough by itself, a second mechanism, the “Named Query” was built to support these kinds of requests.  

A Named Query is similar to an SDC-Model in that it defines a topology or subgraph; but unlike models, it is made up entirely of widget-level models and does not support the kinds of rules that models need to validate data.  

It is only focused on pulling data out of the database.  It does not use "service" or "resource" level models.

Algorithm at a high level

One common feature of both models and named-queries is that they both identify a single starting point in the graph where an “instance” of this model can be identified.  

From that single starting point, a topology (really a tree) is defined which defines what other data the model or named-query relates to in the database.   

Someone might have a model for a particular kind of logical link that should always connect an l-interface on a vserver of type X with an l-interface on either a vserver of type Y or Z.

The model would use the logical-link widget to start with and would have rules that limit the things being connected (X to Y, or X to Z).  

The model captures the rules so that when we need to use it to collect or verify data, we can traverse nodes starting at the initial starting point and always knowing where we are in the topology and what are all the allowable next-steps from that point.   

At present we only allow models or named-queries to be defined which match up with our existing database rules.  

For example, you cannot currently define a customer model where a customer node connects directly to a pserver.  There is no direct relationship in the database between those two node-types, so there would never be instance data found for this model or a way to put it into the database.  In theory, we could simply define a new allowed-edge (relationship) whenever a model definition is created.  That is a longer-term goal (maybe).  

But the database needs to make sense as a whole and not just record a jumble of contradictory visions of what our network looks like.  

While designers should be able to mix and match existing models to build new things, the introduction of new types of relationships will probably need to go through some sort of review board.  

For now widget types and properties and connection rules are pre-defined but can be used in many different combinations to define service and resource models.  Widget models are defined at the time the schema is defined since they currently track our schema 1 to 1.

Model Types

Model Type:  Widget Model

A widget-model is the lowest level type of model.  

It does not point to any other widget-models/resource-models or service-models.  

Is at the “leaf-level” of what SDC cares about.  

NOTE – The name of a widget model will be identical to the name of the AAI node type that it corresponds to.    

Model Type:  Resource Model  

A Resource Model captures levels of complexity by defining a topology of widget-models and/or other resource-models.  

Its first element must be a widget-type model which represents the starting point we would use when locating a single instance of this resource in the AAI database.

Model Type: Service Model 

A Service Model groups together other service-models, resource-models and/or widget-models to define a service.    

As with a resource-model, its first element must be a widget-type model which represents the starting point we would use when locating a single instance of this service in the AAI database.

Deprecating Named Queries in Dublin Release