In the Windows command line, the 'ROUTE PRINT' command yields a tabular list of entries, with a single column labeled 'Metric'.
In the Windows Platform SDK, you can fetch the same values (more or less) via the API, through the structure MIB_IPFORWARDROW. I can correlate most of the fields in MIB_IPFORWARDROW to the one's in ROUTE PRINT's but when it comes to Metrics, MIB_IPFORWARDROW has 5 (five!) metric fields. Which one of them is ROUTE PRINT's Metric?
Oops... I missed that part in the documentation that says:
A number of members of the
MIB_IPFORWARDROW structure are not
currently used by IPv4 routing. These
members include dwForwardPolicy,
dwForwardNextHopAS, dwForwardMetric2,
dwForwardMetric3, dwForwardMetric4,
and dwForwardMetric5.
So, answering myself: In IPv4, ROUTE PRINT's Metric is dwForwardMetric1 in MIB_IPFORWARDROW.
Related
We are trying to create a #Search method in a FHIR Server to look for all the observations from a Patient. I have seen that the parameter can be subject or patient. We want that you could look for a Patient by Identifier, so the request should be something like this:
GET [base]/Observation?subject:identifier=http://acme.org/fhir/identifier/mrn|123456
or
GET [base]/Observation?patient:identifier=http://acme.org/fhir/identifier/mrn|123456
Our problem is that we only have Patient Identifiers with type. In order to look for a Patient by Identifier with type, you have to add the modifier :of-type. My question is, is correct to have a request with two modifiers? Just like the example below
GET [base]/Observation?patient:identifier:of-type=http://terminology.hl7.org/CodeSystem/v2-0203|MR|446053
Modifiers modify the default search behaviour, not the filter that you want to put on the resource type. You can only use modifier specified by FHIR. They are listed on this page: http://hl7.org/fhir/search.html.
Your first two searches above are not valid. In order to search Observations based on a patient's identifier, you would have to do a chained search:
GET [base]/Observation?patient.identifier=http://acme.org/fhir/identifier/mrn|123456
This is a shortcut for 'subject' with a resource type modifier:
GET [base]/Observation?subject:Patient.identifier=http://acme.org/fhir/identifier/mrn|123456
If you need to incorporate the 'of-type' modifier, the search could look like this:
GET [base]/Observation?patient.identifier:of-type=[codesystem_for_type]|MR|123456
I prefer to use the 'patient' parameter whenever applicable, but it would also be valid to do subject:Patient.identifier:oftype. Edit to add: for now it is valid, but see Lloyd's answer for future FHIR versions.
Based on https://jira.hl7.org/browse/FHIR-20641, the intention is to clarify that multiple modifiers are prohibited and that if you have that requirement, you need to define your own search parameter that doesn't require modifiers. Note that this decision has not yet passed ballot. In R4, there is no documented expectation for support, but there's no prohibition either. In practice, we're not aware of any standard servers that provide support and, given the planned prohibition in R5, it's unlikely such support will be built.
Tarantool java connector provides API to select/update/insert/delete/... tuples in spaces. The first argument in these API methods is a space ID. There is no documentation for this API and I don't clearly undestand how to get these IDs.
The sample code from github gets IDs evaluating box.space.<space>.id - not using API but directly "writing" command into socket... It seems this is not a good approach (?).
As I see system spaces _space/_vspace have constant IDs = 280/281. Is it good approach to use these constants to select spaces IDs?
UPD: I found constant _VSPACE = 281 in the class SQLDatabaseMetadata. It's used in Tarantool JDBC driver. It's protected.
You are right. You need to fetch space id-name mapping from _VSPACE first and then use these values to perform requests against certain spaces. Or you can lean on the fact that a first user-defined space has id 512, then next one 513, etc.
We plan to support automatic schema loading and space names, but don't support it yet: https://github.com/tarantool/tarantool-java/issues/137
I want to filter Encounters based on their first or last Encounter.location[].
FHIR REST api spec has only 1 search param related to Encounter location value: location and it doesn't specify the search behaviour in case when Cardinality is greater than 1.
I was hoping for a modifier suffix like :first or :last to support location:first, location:last i.e
{base_url}/Encounter?location:last=Location/123
but there is no such option and I don't see a way to add custom parameter modifiers.
Is there a preferred way than adding custom search params like location-last, location-first ?
Thanks!
The first thing to be aware of is that order is only significant when the base FHIR specification declares it to be significant - which it doesn't for Encounter.location. As a result, you should expect the locations to be listed in arbitrary order and the 'first' location won't mean anything special. The period of time when a location is/was relevant is conveyed by Encounter.location.period, not ordering within the collection. It's non-conformant to enforce any rules about ordering when FHIR hasn't defined any.
There are currently no qualifiers to support searching on a specific repetition. However, it is possible to define custom search parameters that can be tied to a specific repetition. E.g. If you wanted to only search on a patient's "first" name as opposed to all given names. Be aware that defining custom search parameters is only useful if you're in an environment where you can nudge both clients and servers to support the custom parameter.
You could submit a change request (use the link at the bottom of any page in the spec) proposing the :first and :last modifiers for inclusion in R5 of FHIR, but you'd have to provide several examples of places where it would be useful (constrained to places where order is actually significant)
The Place Details Responses provides an example of the address_component array, however it isn't inclusive of every possible option that can be returned. If I want to construct an actual address that includes all of the lesser-known address elements (e.g., pre-direction, post-direction), how can I determine what those options are?
It looks like the directionals are at least included in the route property. Maybe the sample result does contain all of props?
I need my chatbot to query the user for an address and therefore I need the rasa NLU to return the address components (e.g. zip code, house number, street name, etc.) contained in the messages as entities.
Of course, one obvious way to do it would be to create a training file containing appropriate training data. But since this surely is a common problem, I hoped there might be another solution. Besides, it is not obvious to me where one might get loads of labeled addresses in various formats.
In this blog post some evaluations were done which show that the entity extractor ner_crf performs quite well for addresses if you add enough training data. In the blog post addresses were annotated as follows:
Take me to [123 Washington Street](address) please
You could support the recognition by supplying some regular expressions
Depending whether you have a list of possible street names you could also use lookup tables