I'm using Google Analytics Core Reporting API v4. When I query using the dimensions: ga:userAgeBracket & ga:userGender, I get the following error:
Restricted dimension(s): ga:userAgeBracket, ga:userGender can only be queried under certain conditions
Can someone tell me why this error occurs?
Not all dimensions and metrics can be queried together. This can be for several reasons it may not make sense to have them mixed. It may also be that a relation between them does not exist.
My guess would be that there is no relation between ga:userAgeBracket, ga:userGender. Gender came from double click cookie.
Related
I am building team velocity chart in ADO in power BI. it requires planned and completed work items for each sprint.
I am unable to get planned work items for previous sprints.
I tried using workitemrevision details through OData feed, but it gives me error while i try to expand iterationpath and areapath details.
Can anyone help me out to solve this issue?
Here are the details of error are as follow, initially I used the simple query .=OData.feed("https://analytics.dev.azure.com/organization/project/_odata/V3.0-preview/workitemrevisions?$filter=workitemtype in ('User Story')",null,[implementation="2.0"])
It give error as:
Data source error:A null value was found. For the property named 'AreaPath'which has expected type'EDM.string[nullable=false]'does not allow null values.
After that I used (Omitvalues=ODataOmitValues.nulls,ODataversion=4].
But after that it gives error as:
DataFormat.error=We expected property 'Iterationpath',but the OData service omitted it from the response data.This can occur for number of reasons and does not necessarily imply that the data does not exists or is of default value.
Details: IterationPath
To create custom error handling I would like to switch at the errorcode property of a MongoDbException.
Is there any official list of error codes?
I know 112 is a WriteConflict, 16608 means division by 0 and 16610 is a modulo by zero.
error_codes.yml is incomplete and lacks of 16608 and 16610.
I found a list here (the same as yours)link.
In my case, We launched a lot of test scenarios and then i searched in logs all the possible codes. The ones that i found are :
112 write conflict (when a transaction is failed)
11000 Duplicate Key (when a unique constraint index is violated)
211 or 11600 When mongo is down or i have a bad config
So If we don't have a better solution. All we can do is handling the most redundant cases. The other cases are handled as 500 server error.
MongoDB server source code is publicly available, if you want to get information about a particular error, or get a list of all errors, going through the source is going to be your best bet.
Per Daemon Painter's comment, there is an open docs ticket to provide a list of error codes.
One challenge with such a list is the server does not guarantee when it will produce a particular error code. Therefore a comprehensive list of error codes either would be not very useful (if it only tells you what error codes exist but not when you would get them) or it would be labor-intensive to maintain.
The drivers generally look for certain error codes in certain situations only (see for example here). They don't have a complete list of error codes.
I'm currently facing a dilemma in choosing the most appropriate response for a REST API that GET multiple entities, when one of the entities has a data corruption error. Say I have a REST API like the following:
GET /employees?department=&manager=
that returns a list of employees, perhaps with some filtering applied.
When getting the data from upstream (a DB, or another web service, etc.), I discover that the data for one of the employees that match the condition is corrupted. For example, the data cannot be parsed or does not meet some precondition that is necessary for that data entity.
What would be the most appropriate (from an API point of view) RESTful response to this? Should I continue processing all the other employees and simply ignore the error and omit it in the response, or error out with 500 Internal Server Error, or include the error in the response in a separate field while returning the other "good" employees?
I know this is somewhat opinion-based, but some advice would be greatly appreciated.
If you want to return an error, this (to me) is a server-error and I think that 500 is indeed the most appropriate error.
Whether you want to return an error, or an incomplete list with warnings depends on what your application requires it to do.
Using Acumatica ERP 2018R (V18.112.0019) which is the latest version as of this question.
I've been trying to find a way to download contact address records in batch -- not one at a time, and it seems that everything I try, I get an error from the optimizer about a BQL delegate.
I've tried using the Default/17.200.001 endpoint to go after the Contact entity and use the $expand=Address parameter.
Often suggested as a workaround is to create a Generic Inquiry, so I've also tried extending the endpoint and get the results from a GI, but no matter how basic I make that GI, I get the same BQL delegate error. For the DAC, I've tried using PX.Objects.CR.Address, PX.Objects.CR.ContactExtAddress, PX.Objects.AR.ARAddress, and went so far as to return just the AddressID field. No other tables, relations, parameters, conditions, etc. Just a very basic GI to try and get to an address. Even if the GI worked, there's issues with being able to page the results (I get a method not allowed error when trying to do a Put to a GI, but that could just be me doing it wrong).
Looking that differences between the old endpoint Contract versions, it looks like V1 was more forgiving with sub-optimal queries than V3? Maybe the REST API needs to have a URL parameter or a way to specify to allow a non-optimized query to run? Or if it has that feature, I can't seem to locate it.
Any insight or examples that anyone could add would be greatly appreciated. I can't imagine having to download contacts and/or contact address records one at a time - that would be a ridiculous number of round trips/requests and would be much slower and more of a resource hog than a single non-optimized query.
I think I was able to solve my own problem by expanding the Contacts in the following manner:
Customer?$expand=ShippingContact/Address,MainContact/Address,Contacts,Contacts/Contact/Address
You should be able to do PUT to a Generic Inquiry entity, and in that way you should not get a delegate-related optimization error.
I don't expect to get an answer on this but if anyone can help it would be greatly appreciated.
We're using HP Application Lifecycle Management 12.2 (ALM or QC/QualityCenter as it's called). I'm trying to retrieve test resources from the project using the REST api but I suspect I've come across a defect in the API.
I'm trying to filter the response by using a query, and any other query works fine but when I try to use the 'folder-name' field it fails with the following message:
Failed to set params in the parametrized query
It doesn't matter what format I try to escape the query with, I've tried the following:
/resources/?query={folder-name[%27folder%27]}
/resources/?query={folder-name['folder']}
/resources/?query=%7bfolder-name%5b%27folder%27%5d%7d
I've also reproduced this on an 11.52 QC instance so it's not just our environment. I've double checked the customization collection using the ?can-filter=true param and folder-name is supposed to be filterable.
I'm currently using the parent-id for filtering instead which works but it requires me to do another request to get the parent-id first which I would like to refrain from.
Any suggestions, patches?
Thanks
As I wrote in the comments, the error is reproducable here, and I agree that it is strange. The folder-name exists as a field in resource, and should be filterable. It seems to be a bug.
But there is another approach that I offer as a substitute solution. The resource entity offer a relation directly to the folder entity, and you can get the exact result you were looking for, by using a cross join with that table:
/resources/?query={resource-folder.name['folder']}
This is probably too late to help you with your work, but it might help others.