Is it possible to show a keymatch result if there is a match using regex pattern?
For instance, I would like to show a result should a query begin with a certain pattern, for instance:
^cricket
I am hoping a keymatch result will then appear for queries like "cricket player", "cricket rules", "cricket stats" and so on.
If not regex, is there another method people are using?
No, the built-in KeyMatch functionality doesn't allow this. The built-in functionality is very limited. I suggest you write your own off-GSA alternative, and have it inject values for you. This is actually pretty easy to do. You'd build a web application that stores the patterns and the corresponding URLs to serve. If you're using XSLT to render the results, build a OneBox service that the GSA can invoke. Otherwise, just render the results in your application server page.
Related
I'm new to the FHIR World, I have a FHIR client, HAPI FHIR that I can use to fetch data through a restful API. I apology if I missunderstand something during my FHIR documentation journey.
I've look around the documentation and tried some requests to fetch basic data, like a list of Patient, an Observation by id etc..
In my case, I need to get a list of Patient that have the same name as its resource generalPractioner (it's unlikely to happen, it's just an example).
In regular SQL it would look like something like this :
SELECT * FROM Patient
INNER JOIN Practitioner ON Practitioner.id = Patient.practitioner_id
WHERE Patient.name = Practitioner.name
Since FHIR doesn't work that way and isn't relational database, I need to come up with a way to do the equivalent of SQL's WHERE and SQL's JOIN but through the restful API of the client.
My questions are : Is it possible to do these kind of thing directly on a FHIR Client through the API ? If yes, do I need to make new modules inside HAPI FHIR (JPA or plain server ?) (using Java) so it can understand what I really want ?(a new parser with a new route on each resource for example).
Note that the example with the SQL query is pretty simple, my project is to be able to do really nested joins and wheres, as well as the SQL's AND and OR. It doesn't have to use graphQL, this is just what matches the most with my idea while I was reading the documentation.
I'm afraid that regular _include, _filter and _search parameters aren't enough for what I need.
I found that the fhirpath thing could be use but I didn't find how to use it through the API (except with the $graphql operation).
Seems like ChatGPT want me to use the operation $fhirql which is no longer supported in the recent versions of HAPI FHIR, this seemed to be wnat I want.
Thanks !
I do not know what $fhirql is - and I think I know everything there is to know about FHIR. And Google comes up blank, so that might be ChatGPT just fantasising again. Maybe it invented that based on https://github.com/FirelyTeam/FhirQuery, which is clearly the kind of thing you're thinking about.
Or maybe Pathling is closer to what you want: https://pathling.csiro.au.
$graphql only lets you filter your data, it doesn't allow de novo new joins. _filter is the nearest to what you want, for the few servers that support it, but even then, no joins the way you want.
So it looks like you'll have to fetch the data from your API by a client, and then do something locally, which is how those tools work. Unless the server does something specific for you
Did the Explain endpoint ever support search_type: dfs_query_then_fetch? If it does now (I'm on 7.1), how do I specify it?
I was thrown for a loop when using the Explain API on two identical documents, but seeing different score calculations. Learning the documents lived in different shards, and that the TF/IDF inputs were calculated per-shard explained the difference. Using dfs_query_then_fetch on the Search API normalized the scores, but the ElasticSearch .net client (both LowLevel and NEST) don't appear to expose a way to specify it for calls to the Explain API.
I also tried to form a request manually, passing it as a querystring or request body parameter. Both fail saying the argument is invalid. I thought perhaps the Explain endpoint didn't offer a way to specify dfs_query_then_fetch, but digging through some old issues it appears that it at least did at some point:
https://github.com/elastic/elasticsearch/issues/2612
Search type is not supported on the explain API. An approach that might work would be to use the Search API with dfs_query_then_fetch and explain, with a compound query that filters only to the document you're interested in (using IdsQuery), along with the query you want the explanation for.
I'm using Google Data Studio to visualize results from various queries (from different tables within the same BigQuery-database).
For this reason, I created and use multiple data-sources-connectors. Each one of them has a SQL query included and makes use of an defined input parameter (which can be changed by report editors) - called "userid". It is the same id for all queries and resulting charts.
However, when I click "Manage URL parameters", I'm not allowed to use the same URL parameter for more than one data source (instead they are called ds0, ds1, ds2 etc - although they all end up being used as "userid").
If I add a data source under File - Report Settings, a new field "userid" appears, which I can alter - this will update ALL charts in the report with the very same userid (as expected). This works, but I do want to make use of an url which delivers an report with all updated queries depending on ONE userid.
Therefore, I guess I'm overseeing something - it should be possible to just use one query parameter to update the same "userid" for all queries in all data connectors? Or have I overlooked the possibility to fire multiple queries within one data source connector? Or is it expected to create a looong url full of redundant query parameters in this case?
I'm curious for your input!
Best regards :)
There does not seem to be any good solution for this.
For now the best workaround seems to be to just repeat the parameter multiple times -- it's ugly but it works. For example, use the URL parameter mapping screen to call the parameter u1, u2, etc., and then just pass all of them:
?params={"u1":"foo","u2":"foo"}
(URL encoded of course)
The ugliness is mostly for us developers: it violates our sense of DRY and clean code, and makes the URL much longer than it needs to be. However, most people don't care or know about the URL parameters so its irrelevant to them.
The bigger downside is that when the URL is distributed to clients (bookmarks, mobile apps), every time new data sources are added that require the same URL parameters, a new URL has to be distributed to clients for no good reason. A workaround for this is to build the URL dynamically via a simple redirector function.
This issue https://issuetracker.google.com/issues/180705297 is a feature request to implement this capability.
If you group the elements that you want to control with the same parameter (select and then shift G) then it will give you options to select the data source and the params box to apply to the group.
Is there another way to view the profiling results of MiniProfiler (I'm specifically interested in EF5 version)?
Every tutorial that I've seen uses MiniProfiler.RenderIncludes(); but since my MVC app mostly returns JSON, that is not an option for me.
Is there a way to write results to file or something like that?
You can read and write results to just about anywhere by changing the MiniProfiler.Settings.Storage to a different IStorage implementation from the default (which stores to http cache). If you wanted to, this could store to and read from a file pretty easily (you would have to write your own custom implementation for that).
The files served by RenderIncludes are the html templates for displaying the results and the script to retrieve the results from the server and render them on the client (all found here). But you are by no means obliged to use this mechanism. If you want to write your own logic for retrieving and displaying results, you should base this off of the logic found in MiniProfilerHandler.GetSingleProfilerResult. This function roughly performs the following (putting in the siginificant steps for your purposes):
Gets Id of next results to retrieve (through MiniProfiler.Settings.Storage.List())
Retrieves the actual results (MiniProfiler.Settings.Storage.Load(id))
Marks the results as viewed so that they wont be retrieved again (MiniProfiler.Settings.Storage.SetViewed(user, id))
Converts these to ResultsJson and returns it
With access to MiniProfiler.Settings.Storage, you should be able to retrieve, serve and consume the profile results in any way that you want. And if you are interested in using the RenderIncludes engine but want to mess around with the html/js being served, you can provide your own custom ui templates that will replace the default behavior.
Based on the following example URL structure:
mysite.com/mypage.aspx?a=red&b=green&c=blue
Pages in the application use ASP.net user controls and some of these controls build a query string. To prevent duplicate keys being created e.g. &pid=12&pid=10, I am researching methods of rewriting the URL:
a)
mysite.com/mypage.aspx/red/green/blue
b)
mysite.com/mypage.aspx?controlname=a,red|b,green|c,blue
Pages using this structure would be publishing content that I would like to get indexed and ranked - articles and products (8,000 products to start, with thousands more being added later)
My gut instinct tells me to go with the first method, but would it would be overkill to add all that infrastructure if the second method will accomplish my goal of getting pages indexed AND ranked.
So my question, looking at the pro's and con's, Google Ranking, time to implement etc. which method should I use?
Thanks!
From an SEO perspective you want to try and avoid the querystring, so getting it into the URL and a short form URL is going to get you a better "bang for the buck" on the implementation side of things.
Therefore, I'd recommend the first.
Why don't use MVC pattern, this way all your link will be SEO ready. Check here, you will find what is MVC and also some implementation in .net!
You can easily make SEO-friendly URLs with the help of Helicon Ape (the software which allows having basic Apache functionality on your IIS server). You'll need mod_rewrite I guess.
If you get interested, I can help you with the rules.
Can you explain in more detail your current architecture and what the parameters all mean? There's nothing really wrong with query strings if it's truly dynamic content. Rewriting ?a=red&b=green&c=blue to /red/green/blue is kinda pointless and it's unclear from the URL what might be on the page.
The key is to simplify as much as possible. Split the site into categories and give each "entity" one URL.
For example, if you are selling products, use one URL per product, with keywords in the URL - e.g. mysite.com/products/red-widget or mysite.com/products/12-red-widget if you need the product ID.