Inconsistencies in data type for companyNo/vismaNetCompanyId

[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

[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]

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

[Marius Bancila]

Assigning an int to a long should not be a problem. But will investigate different scenarios.

[Marius Bancila]

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]

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

[Marius Bancila]

And how would that look?

[omelhus]

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

[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]

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.

[Marius Bancila]

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

[omelhus]

Awesome