elastic search admin API preparePutIndexedScript does not exist anymore - elasticsearch

I need to use exactly this method on the adminClusterApi,
client.preparePutIndexedScript()
.setScriptLang("painless")
.setId("script1")
.setSource("script", "_score * doc['my_numeric_field'].value")
.execute()
.actionGet();
I tried the following elastic-search-client version.
* 5.6.1
* 5.3.1
* 5.3.3
but sadly I can't find this method and even the preparePutIndexedScript on the Java Api anymore, does someone have any idea?
according with the documentation this class still exists -> https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/indexed-scripts.html

I found the answer
All the methods related to interacting with indexed scripts have been
removed. The Java API methods for interacting with stored scripts have
been added under ClusterAdminClient class. The sugar methods that used
to exist on the indexed scripts API methods don’t exist on the methods
for stored scripts. The only way to provide scripts is by using
BytesReference implementation, if a string needs to be provided the
BytesArray class should be used.
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/breaking_50_scripting.html#_indexed_scripts_java_apis
would be nice though if the other documentation part that i mentioned would be upgrade was a bit hard to find this.

Related

Joomla4: howto create a controller via MVCFactory

I am in the process to cleanup the code of my extensions to fit the requirements for the joomla4 API.
Unfortunately there are no migration documentations available to support this effort. I also could not find any refrences or
implementations with the current joomla4 code. If you look into this code you will find mostly the use of depecated (old) methods.
Also searching the web did not help either. Would be fine if someone could help with some hints - especially with this
topic below:
Create a controller instance version 3.0 API:
$controller = BaseController::getInstance($prefix);
I get a hint for the deprecated "getInstance":
Joomla\CMS\MVC\Controller\BaseController::getInstance(string $prefix, array $config=[]) : static
Deprecated. 5.0 Get the controller through the MVCFactory instead
Unfortunately there are no docs nor any samples how to create my controller via MVCFactory - can somebody help with this issue?

Laravel 7 Api incomplete?

I started with Laravel 7 a few weeks ago. It happened to me multiple times that after reading about a topic on the Laravel website, I wanted to check the details of a function, for example:
Illuminate\Support\Facades\Route::group()
So I went to the Laravel API, and could find the Route facade, but not the group function.
What am I doing wrong? Where do you check for example the exact signature of a function?
Thanks!
The method group in Route::group() is inherited from another class, RegistrarGroup.
See the docblock method in the source file, vendor/laravel/framework/src/Illuminate/Support/Facades/Route.php:
#method static \Illuminate\Routing\Router|\Illuminate\Routing\RouteRegistrar group(\Closure|string|array $attributes, \Closure|string $routes)
so, this is what you look for in the API documentation:
https://laravel.com/api/7.x/Illuminate/Contracts/Routing/Registrar.html#method_group
That is because a Facade, by definition, is only an 'interface' to the methods exponed by another object, so you will not find the actual methods available by visiting the facade code.
Usually you can find the actual class that a facade resolves to (when not mocked) by checking the docblock in the source code and navigate to that class.
A very useful tool to overcome this problem and provide autocompletion (and inspection) for facades on your IDE is the package https://github.com/barryvdh/laravel-ide-helper

Getting xAPI statements from an xAPI package

I'm trying to get my head around the workings of an xAPI package authored in Rise which has been supplied to me so I can build a test PoC app.
I can see the functions built into the index.html page, and that things like progress and quiz scores are genrated, but where do I find the end-point for a LRS within the package?
I have incorporated the package into a test app I built, but rather than generate and send statements myself I would like use what comes as part of the package.
If I import and play the package in SCORM Cloud, I get generated statements returned.
The only thing I can see is an entry in the tincan.js file, this.recordStores=[] other than that I'm unsure where to go next, any suggestions?
Generally this kind of package implements a set of guidelines that were released with the 0.9 version of the specification (at the time named the Tin Can API and then later changed to xAPI). Those guidelines provide for a packaging and launch mechanism which is what Rise has implemented. The launch mechanism indicates that the endpoint and authentication credentials will be passed on the query string to the launched content where it can retrieve them. The TinCanJS library used by Rise implements functionality to digest the query string and set up objects, those you find in this.recordStores to communicate with the xAPI LRS identified in the query string parameters.
You have two primary options,
Get the query string parameters directly from the launch URL and
process it yourself, potentially using the same global library objects
(TinCan.LRS) already available to get an LRS object that you can
then interact with as you see fit,
Leverage the object already created for you via the this.recordStores list that is already prepared by the package itself
There are pros/cons to both methods and they largely depend on your familiarity with JavaScript and how flexible you need/want to be.

Wagtail alongside Django Rest Framework drf-yasg?

I am implementing a Wagtail powered blog within a larger (primarily DRF) driven app. I'm attempting to use drf-yasg for my documentation.
Since installing wagtail, the docs are now throwing
'Request' object has no attribute 'wagtailapi_router'
It looks to be related to the introspection that drf-yasg does, and all I can find about excluding views from drf-yasg is done at the code level. Being an installed module obviously I want to avoid that.
Has anyone got these 2 (3) components playing nicely together?
It's been a very long time since you asked this question, but as I found this while looking for an answer myself, I thought I might share what worked for me.
Note that I'm not using drf-yasg, but rather DRF's own schema generator. They do however have a lot in common.
The problem in my case was that the schema generator URL was defined like this:
path(
"schema/",
get_schema_view(title="My API Schema"),
name="openapi-schema",
),
What I needed to add was a patterns= argument that referenced my API specifically, leaving out the other non-API urls (like Wagtail):
path(
"v3/schema/",
get_schema_view(title="My API Schema", patterns=router.urls),
name="openapi-schema",
),
I hope that helps... someone :-D

Serverless deploying multiple functions

I've recently updated my serverless project, and I've found that many things have changed in the last few updates.
https://serverless.com/
I don't fully understand whats the correct way to have multiple lambda functions and api gateway endpoints related to the same project. With the old serverless I have every lambda and endpoint as a completely seperate function, this worked pretty well for me.
I can't seem to do this anymore, if I try my second lambda function overrides my first, presumably because my "service name" for both is the same. My service name is the same because I want both rest endpoints in the same API in API Gateway. Since serverless creates the API name based on the service name.
So then I tried to add both functions to the same "Service". this worked for the most part, except that now I need to include my custom role statement for all my functions into the same role (because this one role is now being linked to all my functions). Effectively giving more permissions to each individual function than it should have. The other issue is that all my handler files for the different functions are being put into each functions deployment bundle.
So basically, I'm not sure what is the correct approach to have multiple functions that relate to the same project but are separate in functionality. It used to make sense, now doesn't.
If anybody can give me some pointers please
Thanks
I understand your frustration. I had the same feeling until I looked deeper into the new version and formed a better understanding. One thing to note though, is the new version is not completely finished yet. So if something is completely missing, you can file an issue and have it prioritized before 1.0 is out.
You are supposed to define multiple functions under the same service under the functions: section of serverless.yml. To package these functions individually (exclude code for other functions) you will have to set individually: true under package: section. You can then use include and exclude options at the root level and at the function level as well. There's an upcoming change that will let you use glob syntax in your include and exclude options (example **/*-fn.js). You can find more about packaging here https://www.serverless.com/framework/docs/providers/aws/guide/deploying.
Not sure how to use different roles for different functions under the same service.. How did you do it with 0.5?
I was trying to find a solution for individual iam roles per function as well. I couldn't find a way to do it, but while I was looking through the documentation I found the line: "Support for separate IAM Roles per function is coming soon." on this page, so at least we know they are working on it.
The "IAM Roles Per Function" plugin for Serverless allows you to do exactly what it says on the tin: specify roles for each function. You can still use the provider-level roles as well:
By default, function level iamRoleStatements override the provider level definition. It is also possible to inherit the provider level definition by specifying the option iamRoleStatementsInherit: true
EDIT: You can also apply a predefined AWS role at both the provider and function level.

Resources