breeze metadata when multiple types has/share the same short name - metadata

I generate the metadata from the database following the http://www.breezejs.com/documentation/load-metadata-script
My question is : How can I generate the metadata for two entities that has the same name but a different shema in the database ?
I tried to use a qualified name for my entities like this : ...
"entityType": [
{
"name": "Admin.RefactorColumn",
"key": {
"propertyRef": {
"name": "Id"
}
},
"property": [
{
"name": "Id",
"type": "Edm.Int32",
"nullable": "false",
"annotation:StoreGeneratedPattern": "Identity"
}, ...
...
the problem is that when I make entityManager.saveChanges() and return the saveResult(also made by hand) from server breeze look for an entity with the name RefactorColumn:#Admin ... instead of Admin.RefactorColumn:#...
I have no issue if name is just "RefactorColumn" instead of "Admin.RefactorColumn"
Can I solve this issue changing the metadata format or the saveResult format ?
Thank for any help !

All breeze EntityTypes have a concept of a namespace qualified name. This name is a composition of a 'shortName' and a 'namespace'. As of breeze 1.4.16 a qualified name can be created by calling the EntityType.qualifyTypeName static function. i.e.
var shortName = "Employee";
var namespace = "My.Qualified.Namespace";
var qualifiedName = breeze.EntityType.qualifyTypeName(shortName, namespace);
// qualifiedTypeName will be => "Employee:#My.Qualified.Namespace"
In general, all breeze APIs will accept either a shortName OR a qualified name. If a shortName is provided then breeze will internally convert it to a qualified name by finding the first qualified name within the local metadataStore with a matching shortName.
Breeze metadata for each entity type can either be retrieved from a server or defined on the client. If defined on the client your entityType would be defined something like this:
myMetadataStore.addEntityType({
shortName: "RefactorColumn",
namespace: "Admin",
autoGeneratedKeyType: breeze.AutoGeneratedKeyType.Identity,
dataProperties: {
id: { dataType: DataType.Int32, isPartOfKey: true, isNullable: false },
// additional properties here:
},
});
There are several examples of this technique in the DocCode sample in the breeze.js.samples GitHub repo.
Alternatively, if you are defining metadata by returning json from the server you have two options, you can either return a valid OData metadata definition ( which it appears to be what you are trying to return above) OR you can use breeze's native metadata format, which is MUCH simpler. The simplest way to see what this would look like is to create the metadata on the client as shown above and the call
var exportedMetadata = myMetadataStore.exportMetadata();
The contents of the exportedMetadata will be in 'native' breeze metadata format, which is basically just a jsonified version of the internal entityType definition.

Related

OpenAPI parameter description vs parameter schema description

In OpenAPI 3.0, I'm wondering what the difference is when describing parameters. For example, what is the difference between descriptions "Foo" and "Bar" below? Is the one for "Foo" more for the semantics of the parameter and the one for "Bar" more for the syntax, if that makes sense? Should just one be used generally (and which if so)?
{
"name": "someParameter",
"in": "query",
"description": "Foo",
"schema": {
"type": "string",
"description": "Bar"
}
}
The parameter description is specified by the description in the parameter itself.
It just so happens that parameters use a schema to define the data type, and schemas can have their own description. In the context of parameters, you can think of the schema-level description as the description of the parameter's data type.
The two descriptions are semantically separate. Schema-level decription is NOT a fallback for missing parameter description.
Here's another example:
paths:
/users/{id}:
delete:
summary: Delete a user
parameters:
- in: path
name: id
required: true
description: The ID of the user you want to delete.
schema:
type: string
format: uuid
description: >-
A unique identifier in the format "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx".
In practice, parameters usually don't have a schema-level description specified because it's often redundant.

Compound queries

I have a RESTful service that accepts a custom query, like this:
/entities/User?actions=
{
"$link": {
"entityType": "Manager",
"entity": {
"name": "John Smith"
},
"linkName": "managers",
"backLinkName": "account",
"$set": {
"propertyName": "aclWrite",
"propertyValue": {
"$ref": {
"propertyName": "entityId"
}
}
}
}
}
Which simply means:
Create a new Entity of type User
Create a new Entity of type Manager with the field name, linking the User to be created to this Manager through link name "managers"
Then back-linking the Manager entity to be created to the User with a link name "account" and setting the Manager entity write ACL (Access Control List) to the ID of the User to be created.
I created this query structure because I can't find any suitable Query language that can seem to support such action/procedure.
The question here is are there any Query language that can support such compound action/procedure or can GraphQL handle such?
As a specification, GraphQL doesn't care what fields your schema defines, what arguments those fields take or what your field resolvers do with those arguments. So it's perfectly feasible to design a schema that would let the client compose an equivalent mutation:
mutation {
link(
entityType: "Manager"
entity: {
name: "John Smith"
}
linkName: "managers"
backLinkName: "account"
set: {
propertyName: "aclWrite"
propertyValue: {
ref: {
propertyName: "entityId"
}
}
}
) {
# some fields here to return in the response
}
}
GraphQL does not support references to other nodes inside the same query, so you would still probably want a single mutation whose input mirrored your existing API. That said, using GraphQL for this may still be preferable because of request validation, which is all the more important with complex requests like this. Having an IDE like GraphiQL or GraphQL Playground that lets you write your queries using autocomplete is a big plus too.

API Mapping Templates with Serverless

When using http-event with serverless-framework multiple response status are created by default.
In case of error a Lambda returns an error message stringified in the errorMessage property, so you need a mapping template such as
$input.path('$.errorMessage')
for any status code you want to use. F.e.:
"response": {
"statusCodes": {
"200": {
"pattern": ""
},
"500": {
"pattern": ".*\"success\":false.*",
"template": "$input.path('$.errorMessage')"
}
}
}
But the serverless-framework does not create one by default, thus rendering the default status codes useless. If I would create a mapping template myself, the default response status would be overwritten by my custom ones.
What is the correct way of mapping with the default status codes created by the serverless-framework#1.27.3?

Spring-Data-Cassandra map with UDT as value not mapped to java map.

Cassandra Table Column:
pickuploc map<text, frozen<location>>
Java entity:
#Column("pickuploc")
protected Map<String,Location> pickupLocation;
When execute select query from the table column "pickuploc" not exactly getting mapped to pickupLocation attribute in defined in the entity.
Here is the response I got:
"pickupLocation": {
"4171": {
"type": {
"name": "UDT",
"keyspace": "delivery",
"typeName": "location",
"frozen": true,
"fieldNames": [
"buid"],
"typeArguments": [],
"collection": false
}
}
}
Using Spring-Data-Casandra-1.5.8
Spring Data Cassandra supports as of 1.5 and 2.0 only primitive types within maps. There's already a ticket to improve Map support. Leave your vote to increase the demand to get it implemented.
Should be fixed in version 2.2.
See https://jira.spring.io/browse/DATACASS-487

Is it possible to extract a set of database rows with RestTemplate?

I am having difficulties getting multiple datasets out of my database with RestTemplate. I have many routines that extract a single row, with a format like:
IndicatorModel indicatorModel = restTemplate.getForObject(URL + id,
IndicatorModel.class);
and they work fine. However, if I try to extract a set of data, such as:
Map<String, List<S_ServiceCoreTypeModel>> coreTypesMap =
restTemplate.getForObject(URL + id, Map.class);
this returns values in a
Map<String, LinkedHashMap<>>
format. Is there an easy way to return a List<> or Set<> in the desired format?
Fundamentally the issue is that your Java object model does not match the structure of your json document. You are attempting to deserialize a single json element into a java List. Your JSON document looks like:
{
"serviceCoreTypes":[
{
"serviceCoreType":{
"name":"ALL",
"description":"All",
"dateCreated":"2016-06-23 14:46:32.09",
"dateModified":"2016-06-23 14:46:32.09",
"deleted":false,
"id":1
}
},
{
"serviceCoreType":{
"name":"HSI",
"description":"High-speed Internet",
"dateCreated":"2016-06-23 14:47:31.317",
"dateModified":"2016-06-23 14:47:31.317",
"deleted":false,
"id":2
}
}
]
}
But you cannot turn a serviceCoreTypes into a List, you can only turn a Json Array into a List. For instance if you removed the unnecessary wrapper elements from your json and your input document looked like:
[
{
"name": "ALL",
"description": "All",
"dateCreated": "2016-06-23 14:46:32.09",
"dateModified": "2016-06-23 14:46:32.09",
"deleted": false,
"id": 1
},
{
"name": "HSI",
"description": "High-speed Internet",
"dateCreated": "2016-06-23 14:47:31.317",
"dateModified": "2016-06-23 14:47:31.317",
"deleted": false,
"id": 2
}
]
You should be able to then deserialize THAT into a List< S_ServiceCoreTypeModel>. Alternately if you cannot change the json structure, you could create a Java object model that models the json document by creating some wrapper classes. Something like:
class ServiceCoreTypes {
List<ServiceCoreType> serviceCoreTypes;
...
}
class ServiceCoreTypeWrapper {
ServiceCoreType serviceCoreType;
...
}
class ServiceCoreType {
String name;
String description;
...
}
I'm assuming you don't actually mean database, but instead a restful service as you're using RestTemplate
The problem you're facing is that you want to get a Collection back, but the getForObject method can only take in a single type parameter and cannot figure out what the type of the returned collection is.
I'd encourage you to consider using RestTemplate.exchange(...)
which should allow you request for and receive back a collection type.
I have a solution that works, for now at least. I would prefer a solution such as the one proposed by Ben, where I can get the HTTP response body as a list of items in the format I chose, but at least here I can extract each individual item from the JSON node. The code:
S_ServiceCoreTypeModel endModel;
RestTemplate restTemplate = new RestTemplate();
JsonNode node = restTemplate.getForObject(URL, JsonNode.class);
JsonNode allNodes = node.get("serviceCoreTypes");
JsonNode oneNode = allNodes.get(1);
ObjectMapper objectMapper = new ObjectMapper();
endModel = objectMapper.readValue(oneNode.toString(), S_ServiceCoreTypeModel.class);
If anyone has thoughts on how to make Ben's solution work, I would love to hear it.