My Products
Help
omelhus
PARTNER

Inconsistencies in data type for companyNo/vismaNetCompanyId

by omelhus

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

14 REPLIES 14

by Marius Bancila

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.

omelhus
PARTNER

by omelhus

Wouldn't that break all queries ala "query x($cid: Int!) { useCompany(no: $cid)..."? Not sure how this can be done backwards compatible.

by Marius Bancila

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).

omelhus
PARTNER

by omelhus

An alternative is adding coercing in @export.  Let @export coerce from Int to Long, and Int/Long to Boolean using truthy and falsy.

 

 

by Marius Bancila

And how would that look?

omelhus
PARTNER

by omelhus

Just allow @export to export an Int to a Long. Pretty sure this doesn't work today.

by Marius Bancila

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.

omelhus
PARTNER

by omelhus

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.

Accepted solution
Marius Bancila
VISMA
omelhus
PARTNER

by omelhus

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.

omelhus
PARTNER

by omelhus

Awesome, thanks!

by Marius Bancila

We can add an additional numeric parameter langNo, as alternative to lang.

omelhus
PARTNER

by omelhus

Awesome