to get a personalized navigation.
to get a personalized navigation.
Hey,
I have this query where I need to use both useCompany, and fetch some things from the company table on useCustomer. Turns out the data type for "no" on useCompany is Int, whilst vismaNetCompanyId on the company table is Long. This means that I have to use two variables to get what I want.
- Ole
Solved! Go to Solution.
Yes, the two are inconsistent. I would invoke historical reasons for this. But I suppose we can make no in useCompany an argument of the type Long too. I don't think this would have breaking changes for anyone.
Wouldn't that break all queries ala "query x($cid: Int!) { useCompany(no: $cid)..."? Not sure how this can be done backwards compatible.
Assigning an int to a long should not be a problem. But will investigate different scenarios.
Unfortunately, I was wrong. Assigning an Int to a Long is not possible. GraphQL specification prohibits coercing one scalar type into another.
Therefore, changing this would be a significant breaking change.
An alternative would be to have yet another argument, of type Long, with the same meaning of the arg no. I'm afraid such an approach would lead to lot of confusion (even if we deprecate the existing one).
An alternative is adding coercing in @export. Let @export coerce from Int to Long, and Int/Long to Boolean using truthy and falsy.
And how would that look?
Just allow @export to export an Int to a Long. Pretty sure this doesn't work today.
Yes, you can do that with @export, but it doesn't work because of way we read the no argument in useCompany/useCustomer.
This doesn't currently work:
query companies_and_all($cid : Int = 0)
{
availableCompanies(customerNo : ...)
{
totalCount
items
{
vismaNetCompanyId @export(as : "cid")
name
}
}
useCompany(no : $cid)
{
generalLedgerAccount(first :5)
{
items
{
name
accountNo
}
}
}
}
But can easily be made to work.
Would also be great if useModel could take a numeric languageNo instead of (or in addition to) lang: Enum. This would let me fetch the correct translations based on the languageNo on an associate. If no match, fall back to the value provided in lang or something that makes sense.
This is now available. See https://docs.business.visma.net/docs/schema/queries/modelinfo#language-selection
Just read the docs. Would be useful if when both parameters are defined it would use the lang: NORWEGIAN as a fallback if langNo is not defined or invalid.
We can add an additional numeric parameter langNo, as alternative to lang.
Copyright © 2022 Visma.com. All rights reserved.