When using the revision call in the dropbox python sdk, is the returned json of revision metadata ordered by date (most to least recent)? I can't seem to find anything mentioned in the specs that guarantee this.
The docs don't currently guarantee that, but I'm quite sure that's the current behavior (and very unlikely to change). I'll confirm and see if we can update the documentation to state this explicitly.
Related
I want to fetch complete metadata of the given dataset through API call. Can anyone please suggest how to fetch metadata
You actually already manipulate and interact with various forms of metadata inside your Transforms Python builds today, but in a way that is structured to be safe when reading and writing.
While not all forms of metadata are possible to access today, this generally is because of the desire to ensure product stability and good version controls of your builds.
That said, if there's a certain interaction with metadata you'd like to see in the product, I'd recommend reaching out to your support engineers with a feature request so they can understand your request more specifically and discuss with our product teams.
As part of our application, we're building an ability to integrate with Azure DevOps' REST API. One key component that we're interested in is being able to see actual diffs of specific commits, so that we can look at and analyze the line content. We've already created this integration for GitHub, GitLab, and Bitbucket, and each time it was easy: There's a fairly simple diff endpoint for each that takes in a specific commit ID and diffs it (sometimes with a specific parent commit).
I've not had much luck finding this same functionality in Azure DevOps, however: The diffs endpoint has some data related to this, but it is really just an overview of which files changed and the high-level nature of those changes, along with the IDs of specific blobs that represent the files in each state (before and after).
It's theoretically possible to use those blobs to manually construct what I'm after, and indeed I've been able to query for the before and after blobs to get a diff on each file. But that's two separate endpoint queries per file -- take a twenty-file commit, and suddenly we'd need 40 API calls just to construct a reasonable diff. That doesn't really fit our performance needs, unfortunately.
Is there a separate API endpoint or technique that lets us get to the raw diff? It doesn't need to be a raw diff a la git diff directly, just anything that lets us see the before and after state of each line (rather than each file) with minimal API calls (preferably just one). I've done much scouring through the docs and here on StackOverflow, and not found anything that accomplishes this.
There is no existing Rest API to meet your needs. But you could refer to the following steps to get the content of the git diff.
Step1: You could use the Rest API to get the commit id.
GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/commits?api-version=5.0
Step2: You could use the Rest API to get the commit by commit id.
GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/commits/{commitId}?changeCount={changeCount}&api-version=5.0
In the Rest API Result, you need to record the value of “parentsid”, “path”.
Step3: You could use the following API to get the diff content.
Post https://dev.azure.com/Organization/Project /_api/_versioncontrol/fileDiff?__v=5&diffParameters={value}&repositoryId={repositoryid}
The {value} is Json type.
Here is an example:
{"originalPath":"filepath","originalVersion":"Parentsid","modifiedPath":"filepath","modifiedVersion":"commitid","partialDiff":true,"includeCharDiffs":true}
You could add the value to the API URL.
Then run the API and the result will contains the git diff content. (2 means remove, 1 means add)
Here is a result sample:
This is the ticket I refer to, hope it helps you.
I'm currently trying to do some magic using the VSTS api, but something is a little bit surprising me.
Using the method described here: https://learn.microsoft.com/en-us/rest/api/vsts/build/definitions/get?view=vsts-rest-4.1, I made a call an receive my response.
Despite the documentation, I'm not able to read the revision counter, who is simply missing from the response. That's my goal, overwrite this counter using an homemade powershell...
Is there something I shoud know about the VSTS api, like an admin restriction or something else?
Did someone met the current issue?
To get the build definition's revision counter, you should use the REST API Get definition revisions:
GET https://{accountName}.visualstudio.com/{project}/_apis/build/definitions/{definitionId}/revisions?api-version=4.1
Then you can get all the revisions ids and counts.
When creating an instance of REST API (an application), a version (appearing as a prefix) has then to be included in the URL when calling it.
Is there a way to manager several versions (at the same time) of an API? Are we able to change the version number or how is it changed?
The only link I have found is : https://docs.marklogic.com/guide/rest-dev/intro#id_64988
But it is not pretty clear to me.
Thank you for your help
As the link says, "The version number is only updated when resource addresses and/or parameters have changed. It is not updated when resource addresses and/or parameters are added or removed."
In other words, the REST API will increment the version step if it ever becomes necessary to rename or restructure the addresses of resources. Ideally, that will never need to happen. If incrementing becomes necessary, the goal will be to maintain a deprecated interface if possible at the old address for one release.
In addition to David's good suggestion, you could also build your own version numbers into the name of the resource service extension if it's better to support multiple versions of an extension in a single modules database.
If this is to have versions of your rest extensions and use the V# in that process, then I think you could have multiple sets of your code deployed in different modules databases (per version) and dynamically switch modules database based on the version and then rewrite the URL after that to play well with MarkLogic's REST API.
http://developer.marklogic.com/features/enhanced-http
I'm using Meteor and have a question about overriding the default behavior of what type Meteor uses for User ID's.
I would like users to be uniquely identified by a _id field of type ObjectId instead of whatever type Meteor defaults to (string?). Is there something like a configuration parameter somewhere I can set in order to have this be the case?
Short answer:
You cannot use Objectd for the _id property of the users collection.
Long answer:
This has been posted as a bug report at github but unfortunately rejected.
The rationale for the rejection is, while open to debate, that core packages need some design decisions towards simplicity and robustness. They do have a point, so do the developers who +1 this bug report (I'm one of them).
There has also been a pull request to resolve another issue, while addressing this one, but that also got rejected due to some incompatibilities.
If you are really in need of a solution that requires ObjectId's all over, your safest bet is to create your own accounts package, which you can do by forking the original one towards your needs.
In fact my comment at that issue suggests a quick and dirty fix on the source code where the user's id is checked during the login flow which expects a string. You can for the package and change that check to accept ObjectId.