Is any way to filter a complex collection by keyword? We have a complex entity named Phase, and Phase has a property named EntityTitle, we want to filter out all the Phase whose title contains the keyword "Completed". I tried both contains and search.ismatch, but none of them support. Appreciate any idea. Thanks.
"Filter":"(Phases/any(phase: contains(phase/EntityTitle, 'Completed')))"
"Filter":"(Phases/any(phase: search.ismatch('Completed', 'phase/EntityTitle')))"
Indeed "search.ismatch" and "contains" are not supported inside lambda expressions when filtering complex types, you should instead use "eq". See https://learn.microsoft.com/en-us/azure/search/search-query-troubleshoot-collection-filters#cheat-sheet-for-collection-filter-rules
An example for your scenario would be
Phases/any(phase: phase/EntityTitle eq 'Completed')
Related
Slicing is a nice idea for defining complex or composite data elements used by several FHIR ressources.
"Within a structure definition, a slice is defined using multiple element entries that share a path but have distinct names. These entries together form a "slice group" with useful featured described in http://www.hl7.org/fhir/2015May/profiling.html.
However in the FHIR ressource "DataElement" itself the use of slicing within the ElementDefinition ist not allowed:
see https://www.hl7.org/fhir/dataelement.html
=> Definition of element, No base allowed, No slicing allowed
What is the reason for not allowing slicing within DataElements?
The purpose of DataElement is to define elements. All data elements defined are stand-alone - they don't inherit from other data elements. As such, there seemed to be no place/utility for slicing. (It exists on DataElement from its use in StructureDefinition.) Do you have a use-case for slicing when defining DataElements?
I'm trying to create an array of Regex objects, like so: Regex[] regexes;.
The compilation fails with main.d(46): Error: template std.regex.Regex(Char) is used as a type.
I find the documentation cryptic. All I understand is that templates generate code on compilation, but I don't see what's preventing me from creating an array of Regex.
There's an existing question on StackOverflow with the same problem, but it deals with C++, not D.
You cannot create a regex object without first instantiating the template with a type. this is because the actual type is generated at compile time based on the instantiation type you give. Regex itself is not an actual type, it is just a template function allowing you to generate a type when instantiated.
In this case you probably want to change:
Regex[] regexes;
into:
Regex!char[] regexes;
to tell the compiler that your regex contains chars as opposed to some derived type. This means specifically you are instantiating the Regex template with the type char.
I would like to add beginsWith (^=) and endsWith ($=).
E.g., scope.$eval('"abcd" ^= "a"') should return 'true'
According to Angular's documentation on expressions, you should use controller\filter:
No function declarations or RegExp creation with literal notation
You can't declare functions or create regular expressions from within
AngularJS expressions. This is to avoid complex model transformation
logic inside templates. Such logic is better placed in a controller or
in a dedicated filter where it can be tested properly.
I have a few questions buzzing in my head about the comprehension expression:
What is the data structure which it defines?
Was it adapted from some other language?
Where is it used in AngularJS? Does this API exist for select elements only?
From the docs:
ngOptions - comprehension_expression - in one of the following forms:
for array data sources:
label for value in array
select as label for value in array
label group by group for value in array
select as label group by group for value in array track by trackexpr
for object data sources:
label for (key , value) in object
select as label for (key , value) in object
label group by group for (key, value) in object
select as label group by group for (key, value) in object
Comprehension expression is just a string formatted in a special way to be recognized by select directive.
There's no magic behind it, just several formats of it because there are quite a few ways to process and represent your collection (data structure of your model, item/item property selection as scope's model, some other options regarding labels, grouping etc.). When you consider all these options it is not that strange for allowing complex expressions.
Let's say you have such code:
<select
ng-model="color"
ng-options="c.name group by c.shade for c in colors"></select>
In order to ditch the comprehension expression and use attributes, you would write something like this:
<select
ng-model="color"
ng-data-type="object"
ng-data="colors"
ng-select="c"
ng-label="c.name"
ng-group-by="c.shade"></select>
The attribute approach might get ugly once you expand your API. Besides, with comprehension expression it's much easier to use filters.
While in one way it's true to say that a "comprehension_expression" is "just a string" as package says, on the other hand, source code is just a string. Programming languages are just strings.
A SQL SELECT statement
– which could very well be part of the inspiration for the syntax and features of the "comprehension_expression" (but it's not obvious that it is, because it's not mentioned in the docs– perhaps if I dug into some developer conversations I might be able to find out) –
is just a string.
Sure they're just strings, but they have structure, which relates to the problem they are trying to solve. And the question is, is the structure adequately described? Is its pattern, how it relates to the problem at hand, made clear? Is its relationship to other structures that other people have designed apparent?
While the "comprehension_expression" is just a string, on the other hand, its complexity almost comes to it being a sort of sub-language in its own right.
But the way it is portrayed in the docs (https://docs.angularjs.org/api/ng/directive/ngOptions) does reflect the attitude that it is "just a string with some formatting". It is tucked away in the documentation for ng-options as the type of the ng-options directive. To some extent, it is not an entity in its own right, it is a second-class citizen.
The way the different formats are listed can give one a strange feeling, like it's sort of ad-hoc, without any pattern relating the different possible formats (although there is a pattern if you look closely). Without a formal grammar with a regular structure, it makes you wonder if they really covered all the possible options. Compared to, say, the MySQL documentation for the SQL SELECT statement: https://dev.mysql.com/doc/refman/5.7/en/select.html
Obviously such formal syntax can be quite intimidating and is maybe not necessary for the case of the "comprehension_expression", on the other hand it can be reassuring to know it is precisely defined.
I suspect the asker of the question was somewhat unsettled by how casually the "comprehension_expression" was mentioned in the docs; it can seem like a sort of floating, ghost-like entity, just mentioned briefly but not given its own page etc.
It might be worth it having its own page, being treated as an entity in its own right, because then that invites discussion as to the design of this "sub-language". How did it come about? What are the reasons for the different features of the "sub-language"? Which features, and thus syntaxes, conflict with each other? Why can this feature be used together with that feature but not another feature? Are there inspirations from e.g. SQL, in the design of this "sub-language"?
Otherwise it seems to be an invention out of the blue, unrelated to other DSLs of its kind.
In a blog post on ng-options,
https://www.undefinednull.com/2014/08/11/a-brief-walk-through-of-the-ng-options-in-angularjs/
Mr. Shidhin links to a little discussion
https://groups.google.com/forum/#!topic/angular/4EDe8xIbjLU
Where just this issue is discussed. "Matt Hughes" also expresses the opinion that "Seems like a lot of additional complexity for one directive."
Perhaps this is not that big a deal. I just wanted to put it out there though.
I have backbone collection of models and would like to retrieve the distinct values of a certain property
If I have loaded data like the following into my collection:
[{brand:'audi',id:'1234'},
{brand:'audi',id:'3456'},
{brand:'bmw',id:'3456'}]
I would now want to get the distinct brands from the collection. The result should be:
['audi','bmw']
Looking at the Backbone and Underscore API I don't see anything obvious to achieve this.
My current approach would be to use a library like jslinq
Am I missing anything obvious or does somebody have a better suggestion than jslinq?
You can use pluck and then use uniq (example: http://jsfiddle.net/sCVyN/5/)
pluck
A convenient version of what is perhaps the most common use-case for
map: extracting a list of property values.
uniq
Produces a duplicate-free version of the array, using === to test
object equality. If you know in advance that the array is sorted,
passing true for isSorted will run a much faster algorithm. If you
want to compute unique items based on a transformation, pass an
iterator function.