The only difference between my code and the examples are that I'm using version 1.5.4 and the examples use 1.5.3.
var query = new breeze.EntityQuery.from('resourcemgt/providers').orderByDesc('Edi').skip(0).take(10);
unitOfWork.providers.executeQuery(query).then(function (data) {
$scope.providers = data
});
heres an example of the code.
data.results gives me duplicates
data.httpresponse.data is correct.
Anyone venture to guess why this would happen?
Breeze released a new version last night. Version 1.5.5 appears to have fixed this issue.
Related
I am trying to use the attributeService.getEntityAttributes function to obtain some server attributes of my device. I was using the .getEntityAttributesValues function when working with the 2.x version of Thingsboard and it was working fine. With the current version I am using the following code:
var conf = {
ignoreLoading: false,
ignoreErrors: true,
resendRequest: true
};
var myattr = attributeService.getEntityAttributes(entityID,'SERVER_SCOPE',["myattribute"],conf);
But I get no data or error back. I was using the .getEntityAttributesValues with .then() method but it doesn't seem to work anymore. It says ".then is not a function".
What am I doing wrong? Please help and tell me how to use the new function properly. I am using TB v.3.1.1 CE.
Thingsboard 2.x UI was made with AngularJS.
Thingsboard 3.x UI now uses Angular.
One of the key differences between these frameworks in regards of your problem is the move from Promise based services, to Observable based services.
Let's look at the source of the getEntityAttributes function:
https://github.com/thingsboard/thingsboard/blob/2488154d275bd8e6883baabba5519be78d6b088d/ui-ngx/src/app/core/http/attribute.service.ts
It's mostly a thin wrapper around a network call made with the http.get method from Angular.
Therefore, if we have a look at the official documentation: https://angular.io/guide/http#requesting-data-from-a-server, it is mentioned that we must subscribe to the observable in order to handle the response. So something along the lines of:
attributeService.getEntityAttributes(entityID,'SERVER_SCOPE',["myattribute"],conf).subscribe((attributes) => {…})
We are using the BuildHTTPClient to programmatically create a copy of a build definition, update the variables in memory and then save the updated object as a new definition.
I'm using Microsoft.TeamFoundation.Build2.WebApi.BuildHTTPClient 16.141. The TFS version is 17 update 3 (rest api 3.x)
This is a similar question to https://serverfault.com/questions/799607/tfs-buildhttpclient-updatedefinition-c-example but I'm trying to stay within using the BuildHttpClient libraries and not go directly to the RestAPIs.
The problem is the Steps list is always null along with other properties even though we have them in the build definition.
UPDATE Posted as an answer below
After looking at #Daniel Frosts attempt below we started looking at using older versions of the NuGet package. Surprisingly the supported version 15.131.1 does not support this but we have found out that the version="15.112.0-preview" does.
After rolling back all of our Dlls to match that version the steps were cloned when saving the new copy of the build.
All of the code examples we used work when you are using this package. We were unable to get Daniel's example working but the version of the Dll was the issue.
We need to create a GitHub issue and report it to MS
First Attempt - GetDefinitionAsync:
VssConnection connection = new VssConnection(DefinitionTypesDTO.serverUrl, new VssCredentials());
BuildHttpClient bdClient = connection.GetClient<BuildHttpClient>();
Task <BuildDefinition> resultDef = bdClient.GetDefinitionAsync(DefinitionTypesDTO.teamProjectName, buildID);
resultDef.Wait();
BuildDefinition updatedDefinition = UpdateBuildDefinitionValues(resultDef.Result, dr, defName);
updatedTask = bdClient.CreateDefinitionAsync(updatedDefinition, DefinitionTypesDTO.teamProjectName);
The update works on the variables and we can save the updated definition back to TFS but there are not any tasks in the newly created build definition. When we look at the object that is returned from GetDefinitionAsync we see that the Steps list is empty. It looks like GetDefinitionAsync just doesn't get the full object.
Second Attempt - Specific Revision:
int rev = 9;
Task <BuildDefinition> resultDef = bdClient.GetDefinitionAsync(DefinitionTypesDTO.teamProjectName, buildID, revision: rev);
resultDef.Wait();
BuildDefinition updatedDefinition = UpdateBuildDefinitionValues(resultDef.Result, dr, defName);
Based on SteveSims post we were thinking we are not getting the correct revision. So we added revision to the request. I see the same issue with the correct revision. Similarly to SteveSims post I can open the DefinitionURL in a browser and I see that the tasks are in the JSON in the browser but the BuildDefinition object is not populated with them.
Third Attempt - GetFullDefinition:
So then I thought to try getFullDefinition, maybe that's that "Full" means of course with out any documentation on these libraries I have no idea.
var task2 = bdClient.GetFullDefinitionsAsync(DefinitionTypesDTO.teamProjectName, "MyBuildDefName","$/","TfsVersionControl");
task2.Wait();
Still no luck, the Steps list is always null even though we have steps in the build definition.
Fourth Attempt - Save As Template
var task2 = bdClient.GetTemplateAsync DefinitionTypesDTO.teamProjectName, "1_Batch_Dev");
task2.Wait();
I tried saving the Build Definition off as a template. So in the Web UI I chose "Save as Template", still no steps.
Fifth Attempt: Using the URL as mentioned in SteveSims post:
Finally i said ok, i'll try the solution SteveSims used, using the webclient to get the object from the URL.
var client = new WebClient();
client.UseDefaultCredentials = true;
var json = client.DownloadString(LastDefinitionUrl);
//Convert the JSON to an actual builddefinition
BuildDefinition result = JsonConvert.DeserializeObject<BuildDefinition>(json);
This also didn't work. The build definition steps are null. Even when looking at the Json object (var json) i see the steps. But the object is not loaded with them.
I've seen this post which seems to add the Steps to the base definition, i've tried this but honestly I'm having an issue understanding how he has modified the BuildDefinition Object when referencing that via NuGet?
https://dennisdel.com/blog/getting-build-steps-with-visual-studio-team-services-.net-api/
After looking at #Daniel Frosts attempt below we started looking at using older versions of the NuGet package. Surprisingly the supported version 15.131.1 does not support this but we have found out that the version="15.112.0-preview" does.
After rolling back all of our Dlls to match that version the steps were cloned when saving the new copy of the build.
All of the code examples above work when you are using this package. We were unable to get Daniel's example working but we didn't try hard as we had working code.
We need to create a GitHub issue for this.
Found this in my code, which works.
Use this package, not sure if it could have an impact (joke).
...packages\Microsoft.TeamFoundationServer.Client.15.112.1\lib\net45\Microsoft.TeamFoundation.Build2.WebApi.dll
private Microsoft.TeamFoundation.Build.WebApi.BuildDefinition GetBuildDefinition(string projectName, string buildDefinitionName)
{
var buildDefinitionReferences = _buildHttpClient.GetFullDefinitionsAsync(projectName, "*", null, null, DefinitionQueryOrder.DefinitionNameAscending, top: 1000).Result;
return buildDefinitionReferences.SingleOrDefault(x => x.Name == buildDefinitionName && x.DefinitionQuality != DefinitionQuality.Draft);
}
With the newer clients Steps will always be empty. In newer api-versions (which are used by the newer clients) the steps have moved to Phases. If you use GetDefinitions or GetFullDefinitions and look in
definition.Process.Phases[0].Steps
you'll find them. (GetDefinitions gets shallow references so the process won't be included.)
The Steps collection still exists for compatibility reasons (we don't want apps to crash with stuff like MethodNotFoundExceptions) but it won't be populated.
I was having this problem, although I able to get Phases[0] information at runtime, but could not get it at design time. I solved this problem using dynamic type.
dynamic process = buildDefTemplate.Process;
foreach (BuildDefinitionStep tempStep in process.Phases[0].Steps)
{
// do some work here
}
Not, it is working!
Microsoft.TeamFoundationServer.Client version 16.170.0 I can get build steps through process.Phases[0].Steps only with process and step being dynamic as #whitecore above stated
var definitions = buildClient.GetFullDefinitionsAsync(project: project.Name);
foreach (var definition in definitions.Result)
{
Console.WriteLine(string.Format("\n {0} - {1}:", definition.Id, definition.Name));
dynamic process = definition.Process;
foreach (dynamic step in process.Phases[0].Steps)
{
Console.WriteLine(step.DisplayName);
}
}
I've got this query:
https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json?conditions[krs_podmioty.nip]=7282827109
In a browser, it works OK, showing data specific for the given nip number.
But in Indy, I get a response as if the query part was omitted:
https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json
I've tried this so far:
BurL = "https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json?conditions[krs_podmioty.nip]=7282827109";
BurL = TIdURI::URLEncode("https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json?conditions[krs_podmioty.nip]=7282827109");
End even raw urlencoded data:
BurL= "https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json?conditions%5Bkrs_podmioty.nip%5D=7282827109";
Code:
try {
Resp = IdHTTPKrs->Get(BurL);
} catch (EIdHTTPProtocolException& e) {
ShowMessage(e.Message);
}
What's wrong, and how can I fix this? Or, maybe I am too tired already and am missing something obvious?
I suspect there is something with the [] part of the query, but I am just guessing here. Similar queries without the [] work OK.
I am using C++Builder XE6 pro, with Indy 10.6.0.512
Your Indy version is out of date. The latest version, at the time of this writing, is 10.6.2.5448. Using the latest version, I can't reproduce your issue. Both URL encodings return the same data for me. As they should be, since a web server is required to decode urlencoded characters when processing the requested URL. conditions%5Bkrs_podmioty.nip%5D=7282827109 and conditions[krs_podmioty.nip]=7282827109 should be getting processed the exact same way by the server, as they are sematically identical data.
Below code worked for Dataflow 1.9 sdk, migrating to 2.X
PCollection<TableRow> tableRow = ...
tableRow.apply(BigQueryIO.Write()
.to(String.format("%1$s:%2$s.%3$s",projectId, bqDataSet, bqTable))
.withSchema(schema)
.withWriteDisposition(BigQueryIO.Write.WriteDisposition.WRITE_APPEND));
I get
The method apply(PTransform<? super PCollection<TableRow>,OutputT>) in the type PCollection<TableRow> is not applicable for the arguments (BigQueryIO.Write<Object>)
Release notes are not much of a help here and documentation on 2.X is non existant redirects to beam API page.
Have you tried using BigqueryIO.writeTableRows()?
Apache Beam 2.1.0 BigqueryIO documentation
https://beam.apache.org/documentation/sdks/javadoc/2.1.0/org/apache/beam/sdk/io/gcp/bigquery/BigQueryIO.html
You can try providing TableRow type explicitly (BigQuery.<TableRow>write()...) or use BigQuery.writeTableRows() as suggested above.
Looks like the interface was made generic in 2.x. Earlier version had TableRow hard coded.
I'm not sure what I'm doing wrong here, and am hoping someone else has the same problem. I don't get any error, and my json matches what should be correct both on Jira's docs and jira-python questions online. My versions are valid Jira versions. I also have no problem doing this directly through the API, but we are re-writing everything to go through jira-python for cleanliness/ease of use.
This just completely clears the fixVersions field in Jira.
issue=jira.issue("TKT-100")
issue.update(fields={'fixVersions':[{'add': {'name': 'add_me'}},{'remove': {'name': 'remove_me'}}]})
I can add a new version to fixVersions using issue.add_field_value(), but this won't work, because I need to add and remove in one request for the history of the ticket.
issue.add_field_value('fixVersions', {'name': 'add_me'})
Any ideas?
Here's a code example of how I got it working for anyone who comes across this later...
fixVersions = []
issue = jira.issue('issue_key')
for version in issue.fields.fixVersions:
if version.name != 'version_to_remove':
fixVersions.append({'name': version.name})
fixVersions.append({'name': 'version_to_add'})
issue.update(fields={'fixVersions': fixVersions})
I did it other way:
Create version in the target project.
Update ticket.
ver = jira.create_version(name='version_name', project='PROJECT_NAME')
issue = jira.issue('ISSUE_NUM')
i.update(fields={'fixVersions': [{'name': ver.name}]})}
In my case that worked.
A little bit more pythonic version of user797963 solution, may look like that.
def change_fix_version(tickets, remove_versions=[], add_versions=[]):
fix_versions={version.name for version in ticket.fields.fixVersions}
fix_versions.difference_update(set(remove_versions))
fix_versions.update(set(add_versions))
ticket.update(fields={'fixVersions':fix_versions})
You would call it like that:
change_fix_versions(jira.issue('my_issue'), remove_versions=['draft'], add_versions=['master', 'release'])