Does anyone know how to get the type of context variable in Watson Assistant?
Are there types like int, Array, String, Object for context variable inside Watson Assistant in the first place?
Within the Watson Assistant context you will only find a regular json. Its data is strings, arrays, objects, integers, dates or booleans. But you always will have to serialize and deserialize the context to be able to work with it using any programming code.
For you to know the data type you have to parse the json to an object (JSON.parse in Javascript) and then you can obtain the data type.
here you can find more information https://cloud.ibm.com/docs/assistant?topic=assistant-api-client-get-context&locale=en&programming_language=javascript
Watson Assistant uses Autoboxing to process a context variable.
So ”123” and 123 can be a number or a string depending on how it is referenced.
The safest approach is to treat everything as a fixed type depending on the variable name. But if user interaction is involved there is a chance what they type can break that.
Maybe expand on the “why” for this. If it is to generate business rules or API output, it’s a better pattern to have the application layer handle this.
Related
Chrome Developer Console is console.loging this:
Your JSON sent is>> {yourVariable: "nothing yet"}
So i know the value "nothing yet" in the {yourVariable: "nothing yet"} JSON object is a string. But how do I know the type of the key yourVariable?
Is there a way how to find that out using the Chrome console only?
All object keys are strings with quotes or without quotes. Try this way to see it. May be you are confused with console print because console print it without quotes and we usually write with quotes.
var jsonObj = {person:"me","age":"30", 123:"123"};
Object.keys(jsonObj).forEach(function(key){
console.log(typeof key)}
);
I have a slightly different take on this question which does not invalidate the comments or answer that you received, but is worth considering.
Because you are talking about JSON, there is no intrinsic datatype in your example. As stated on the JSON.org page:
JSON (JavaScript Object Notation) is a lightweight data-interchange
format. It is easy for humans to read and write. It is easy for
machines to parse and generate.
The point is, that there is a difference between JSON, which is a representation of javascript objects, arrays etc., and variables of those types in javascript.
If you remind yourself that JSON is a form of serialization it makes a lot more sense. Javascript objects for example, can include functions, but a javascript function is not a portable thing, so in rendering some JSON from a javascript object, it is up to the language creating the JSON to do whatever it it needs to in order to convert the data it needs to represent, and that may include simplification and in many cases removal of elements that are incompatible JSON.
The other thing to keep in mind, is that all modern languages have functions or libraries that can parse JSON and turn them into variables or objects that work in those languages. In doing so, they have arguments that can completely change the way the JSON is converted back into instance variables.
For example, in PHP you can choose to have the JSON create one or more PHP objects, or an array of php variables.
In summary, JSON doesn't have variables with datatypes at all. It is a representation of data, that is portable across languages, but the languages must decode the JSON and create objects or variables that are valid in their own runtime.
We want to send some events to Application Insights with data showing which features a user owns, and are available for the session. These are variable, and the list of items will probably grow/change as we continue deploying updates. Currently we do this by building a list of properties dynamically at start-up, with values of Available/True.
Since AI fromats each event data as JSON, we thought it would be interesting to send through custom data as JSON so it can be processed in a similar fashion. Having tried to send data as JSON though, we bumped into an issue where AI seems to send through escape characters in the strings:
Eg. if we send a property through with JSON like:
{"Property":[{"Value1"},..]}
It gets saved in AI as:
{\"Property\":[{\"Value1\"},..]} ).
Has anyone successfully sent custom JSON to AI, or is the platform specifically trying to safeguard against such usage? In our case, where we parse the data out in Power BI, it would simplify and speed up a lot some queries by being able to send a JSON array.
AI treats custom properties as strings, you'd have to stringify any json you want to send (and keep it under the length limit for custom property sizes), and then re-parse it on the other side.
I'd like to create an Apigility REST service which accepts POSTs of, for example, a user object which has a field containing an array of address objects. I can define the field without validators and process the raw JSON in my code, but I'm wondering if there is a better way to do this where the nested objects can also be validated by Apigility?
Apigility has a module called content-validation -- it allows you to configure input filters for your services, and request data will be passed through the input filter for validation and an appropriate ApiProblem response is returned when validation fails. (see https://apigility.org/documentation/api-primer/content-validation)
That still leaves the onus on you to configure an input filter that will suit your needs.
I would check packagist.org for a JSON Schema validator library which can take a JSON schema and a JSON payload and verify that the payload is well formed according to the schema. Then you can easily implement a custom InputFilter and bind it to your services. This will give you validation that the main object and sub objects are well formed (ie: user has name, email, birth date and address field contains objects that all have address/street/zip/etc).
I am attempting to consume an API that I do not have control over which is somewhat poorly documentented and somewhat inconsistent. This means that sometimes, the API returns a different type than what is documented or what you would normally see. For this example, we'll look at a case when an array was returned in a place where I would normally see a string. That makes a crappy API, but my real problem is: How can I more easily track those things down? Right now, the errors look something like this:
No usable value for identifier
Do not know how to convert JArray(List(JString(3c8723eceb1a), JString(cba8849e7a2f))) into class java.lang.String
After deciphering the problem (why JValue::toString doesn't emit a JSON string is utterly perplexing to me), I can figure out the API returned an array when I made my case class only able to deal with Strings. Great. My issue is that finding this discrepancy between my object model and the contents of the JSON seems significantly more difficult than it should be.
Currently, this is my workflow for hunting down decoding errors:
Hope bad data has some sort of identifying marker. If this is not true, then it is way more guesswork and you will have to repeat the following steps for each entry that looks like the bad bits.
Go through the troubles of converting the JArray(List(JString(...), ...)) from the error message into valid JSON, hoping that I encode JSON the same way at the API endpoint I got the data from does. If this is not true, then I use a JSON formatter (jq) to format all data consistently.
Locate the place in the source data where the decoding error originates from.
Backtrack through arrays and objects to discover how I need to change my object model to more accurately represent what data is coming back to me from the API.
Some background: I'm coming from C++, where I rolled my own JSON deserialization framework for this purpose. The equivalent error when using the library I built is:
Error decoding value at result.taskInstances[914].subtasks[5].identifier: expected std::string but found array value (["3c8723eceb1a","cba8849e7a2f"]) at 1:4084564
This is my process when using my hand-rolled library:
Look at the expected type (std::string) compared with the data that was actually found (["3c8723eceb1a","cba8849e7a2f"]) and alter my data model for the path for the data in the source (result.taskInstances[914].subtasks[5].identifier)
As you can see, I get to jump immediately to the problem that I actually have.
My question is: Is there a way to more quickly debug inconsistencies between my data model and the results I'm getting back from the API?
I'm using json4s-native_2.10 version 3.2.8.
A simplified example:
{ "property": ["3c8723eceb1a", "cba8849e7a2f"] }
Does not mesh with Scala class:
case class Thing(property: String)
The best solution would be to use Try http://www.scala-lang.org/api/current/#scala.util.Try in Scala, but unfortunately json4s API cannot.
So, I think you should use Scala Option type http://www.scala-lang.org/api/current/#scala.Option .
In Scala, and more generally in functional languages, Options are used to represent an object that can be there or not (like à nil value).
For handle parsing failures, you can use parse(str).toOption, which is a function that return an Option[JValue], and you can doing a pattern matching on the resulting value.
For handling extraction of data extraction into case classes, you can use extractOpt function, to do pattern matching on the value.
You can read this answer : https://stackoverflow.com/a/15944506/2330361
I am developing the distributed application in CORBA Using the Java IDL provided by default in JDK , and of course , both client and server developed in Java.
I am maintaining the some object state on server.
Now, on client side I want to bring whole state (snapshot) of that object from server side.
and this is object is of some Java type .
As I cannot pass the whole object of any Java type from server to client, because of IDL definition and of course CORBA feature as it is language neutral.
One way I found, is using JSON
I will flatten the whole Java Object of any type into string and pass same to client using string data type, later on client I can deflatten the object from string.
also I can define the string type in idl.
but this adds the some processing for flattening/ deflattening on both sides
is there any other way to pass object from client? or may be I missed something?
Update:
Objects of Following types are transferred
class MyObject{ Map<String,String> object; }
CORBA already has the concept of Objects-By-Value, so you could use that if your ORB supports it. Put your state variables in a valuetype and go from there.
Keep in mind that CORBA is not Java. CORBA can be used with many languages so if you find yourself trying to figure out how to send Java-only things across a CORBA system, you're going to find that very difficult. To transmit anything in CORBA it's got to be representable in IDL first and foremost. If valuetype doesn't meet your needs then use the struct approach that the other answer suggested.
You just have to define your MyObjects as CORBA objects. For that you'll use the IDL. Your Map is a simple name,value list.
module Foo {
struct MapEntry {
string name;
string value;
};
sequence<MapEntry> MyMap;
};
};
This will create an Array of MapEntry Objects in Java. If you want to remap them into a Java Map, feel free. This is the CORBA way of transferring a map of something. Create a struct, put it into a sequence, done.
This also works properly for other languages supported by CORBA (e.g., C++)
That sounds as if you want to have the object state become part of the interface (because if you actually transfer the state, being able to recreate the object depends on the receiver to understand the transmitted state, hence it becomes an interface).
Thus, define a struct containing the data fields in the IDL, and add a method to the object interface to return the state in this form. The transfer is then handled by the regular CORBA marshaller.