We are making an updated to our RAML 0.8 specification and we want to mark a method as deprecated and point to another method in the same API. Is that possible in RAML? I read some articles but it is not clear if it is implemented yet
RAML 0.8 lacks this concept. RAML 1.0 added the Annotations to the global section to convey such meta data.
P.S.: A sample deprecation annotation
deprecated:
properties:
replaceWith:
type: string
description: |
Describe the alternative resource/method that can be used as a substitute.
required: true
since:
type: string
pattern: (0[1-9]|10|11|12)/20[0-9]{2}
required: true
description: Describe when the resource/method became deprecated in the format (mm/YYYY)
allowedTargets: [Resource, Method]
displayName: Deprecated
description: |
A deprecated resource or method is *not* recommended for new work.
The resource or method will be removed in a future version of the API.
Deprecation does NOT mean it is not supported anymore in the current version.
Related
As described in this document(https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/Message.Builder.html#buildPartial--) Like MessageLite.Builder.build(), but does not throw an exception if the message is missing required fields. Instead, a partial message is returned
I guess that's a legacy API from proto2? since required keyword is removed in proto3, but they're not marking this API as deprecated, then in which case we should use this?
This allows to easily supply class instance to the unit test environment. Allowing to avoid complex mocking/class construction.
At the begining we have schema
type User {
id: ID!
name: String!
birthday: String!
}
After some time it was decided that birthday is not mandatory for new users, so the schema should change to
type User {
id: ID!
name: String!
birthday: String
}
This is breaking change.
How to versioning case like this in GraphQL?
As mentionned in these official best practices under the section versioning, it isn't recommanded to do traditional API versioning in GraphQL even though there isn't any technical problems in doing so. I would feel that we are corrupting our model since it would introduce a technical field in a business API... which is definitely not ideal.
To help manage the API's evolution, they introduced the concept of field deprecation as described in this link.
To summarize in a few words, I would say that you have basically two solutions:
Do versioning anyway;
Set your field birthday as deprecated and add a new one with an equivalent name (birthday_date maybe?). Obviously, don't forget to tell your api clients to use this new field. In the long run, remove the deprecated field.
I am modelling an API with RAML and I am wondering if it’s possible to model dependencies between a query parameters.
Let’s say we’ve got a collection of objects. A user can narrow the query results down by specifying an object type and a state. Here’s a bit of RAML that should do what I just said:
/objects:
- searchable:
queryParameters:
object-type:
enum: [Type1, Type2, Type3]
object-state:
enum: [State1, State2, State3]
Now above definition may make the users feel that it's possible to use any combination they want - what is not quite right, as:
- object of 'Type1' can take just 'State1',
- object of 'Type2' can take 'State2' and 'State3',
- object of 'Type3' can take 'State1', 'State2', 'State3'.
Does anyone know how to model that with RAML?
AFAIK that's not possible in RAML. RAML is intended to describe an API, and that is more oriented to be business logic.
Nevertheless, I've heard about this question from a lot of people, and I think that it could be treated in RAML 1.0
Cheers!
I am writing a brand new custom doclet using JDK 1.7. These are the problems I have found so far:
Doc methods isAnnotationType(), isAnnotationTypeElement(), isEnum() and isEnumConstant() do not work. They always return false.
PackageDoc method enums() does not work. It always returns an empty array. Enums are included in the result of methods allClasses() and ordinaryClasses().
ClassDoc method enumConstants() does not work. It always returns an empty array. Enum constants are included in the result of method fields().
PackageDoc method annotationTypes() does not work. It always returns an empty array. Annotations are included in the result of method interfaces(), so I could implement the following work-around:
AnnotationTypeDoc annotationDoc;
ClassDoc[] interfaces = packageDoc.interfaces();
for (ClassDoc classDoc : interfaces) {
if (classDoc instanceof AnnotationTypeDoc) {
annotationDoc = (AnnotationTypeDoc) classDoc;
} else {
continue;
}
process(annotationDoc);
}
Based on something that I found in the "What's New in Javadoc 5.0" page (http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/whatsnew-1.5.0.html) I am guessing that, even though I am writing it with JDK 1.7, my doclet is working in some kind of pre-5.0 compatibility mode. This is what I found in the "What's New in Javadoc 5.0" page:
Incompatibilities with Custom Doclets
Custom doclets written prior to 5.0 will have compatibility problems when run on source files that use new language features in 5.0.
New Language Features: The Doclet API and standard doclet were revised to handle the new 5.0 language features -- generics, enums, varargs and annotations.
To handle these features, custom doclets would also need to be revised.
The Javadoc tool tries -- to the extent possible -- to present so-called "legacy" doclets with a view of the program that
1) continues to work with pre-5.0 source code, and
2) matches their expectations for 5.0 source code.
So, for example, type parameters and type arguments are stripped from generic constructs, type variables and wildcard types are replaced by their erasures, and ClassDoc.fields() will return enum constants.
Solved! It really was working in pre-5.0 compatibility mode. All I had to do to was to add the following method to my custom doclet:
public static LanguageVersion languageVersion() {
return LanguageVersion.JAVA_1_5;
}
Property 'Latitude' is a scalar type on class 'LatitudeLongitude'. Cannot generate a setter method for it.
When I generated codes for my managed object, I got a message whether I want scalar properties for primitive data type. should I use it? I want to make this application compatible with iPhone 3 - 5
is there any issues with this problem?
When you use scalar properties you have to provide implementations of getters and setters for those properties by yourself, as described in documentation:
"You can declare properties as scalar values, but for scalar values Core Data cannot dynamically generate accessor methods—you must provide your own implementations (see “Managed Object Accessor Methods”). Core Data automatically synthesizes the primitive accessor methods (primitiveLength and setPrimitiveLength:), but you need to declare them to suppress compiler warnings."
Documentation
At this place I would recommend you to check this post core-data-scalars.
I hope I have helped.
This is not true, scalars have been supported in Core Data out of the box for a long time. You do not have to implement custom accessors as many blog posts out there indicate.