Canonical IDs references vs proxy references

[Julio_R_Ferrari (Julio Ferrari)]

Hi!
I'm using XData with a legacy database where almost all tables have compound primary keys, so most of them are not modeled with unique id fields, and some associations do not encapsule/hide all foreign-key fields.

Is there a way to force some references to show as canonical id references i/o proxy references?

It generates:

"Cuenta@xdata.proxy": "Operacion(1%2C1%2C1%2C0%2C1000157%2C130%2C201%2C44317%2C0)/Cuenta",
"Sucursal@xdata.proxy": "Operacion(1%2C1%2C1%2C0%2C1000157%2C130%2C201%2C44317%2C0)/Sucursal",
"Estado@xdata.proxy": "Operacion(1%2C1%2C1%2C0%2C1000157%2C130%2C201%2C44317%2C0)/Estado",
"Moneda@xdata.proxy": "Operacion(1%2C1%2C1%2C0%2C1000157%2C130%2C201%2C44317%2C0)/Moneda",

none of them are manyvalued associations, and I believe it could simply be:

"Cuenta@xdata.ref": "Cuenta(1%2C1000157)",
"Sucursal@xdata.ref": "Sucursal(1%2C1)",
"Estado@xdata.ref": "Estado(0)",
"Moneda@xdata.ref": "Moneda(1),

It seems like it's generating canonical id references only when the associated entity field is part of the child table ID, as for this table:

"TipoDocumento@xdata.ref": "TipoDocumento(1)",
  "Pais@xdata.ref": "Pais(586)",
  "PersonaFisica@xdata.proxy": "Persona(586%2C1%2C'663551')/PersonaFisica",

None of them are manyvalued associations, the only difference is that TipoDocumento & Pais are part of Persona IDs list.

[wlandgraf (Wagner Landgraf)]

It generates proxy references simply because the proxy is not loaded, thus for performance purposes.
The client can ask for references by expanding the value using the $expand filter option.

[Julio_R_Ferrari (Julio Ferrari)]

@wlandgraf

The client can ask for references by expanding the value using the $expand filter option

In this specific case, it's a service response object, a custom class which one of it's fields is an Aurelius entity object. How could I force references? Accesing the associated entities before filling the result object would be enough?

[Julio_R_Ferrari (Julio Ferrari)]

@Julio_R_Ferrari

Accesing the associated entities before filling the result object would be enough?

Yes! It does the job ! (and takes some miliseconds more)

...
  xReg.Operacion.Cuenta;
  xReg.Operacion.Sucursal;
  xReg.Operacion.Moneda;
...
Result.Add(xReg);

Response:

"Cuenta@xdata.ref": "Cuenta(1%2C1067081)",
"Sucursal@xdata.ref": "Sucursal(1%2C1)",
"Moneda@xdata.ref": "Moneda(1)",

[wlandgraf (Wagner Landgraf)]

That's a pretty valid one approach. You have other options as well, as described here:

Control expand level and proxy in service implementation

Have you tried using the three options at the same time? It should work. Note that the xdata-expand-level header should be set in the request, not in the response. Alternatively you can force the proxies to be loaded using the manager (setting xdata-expand-level is still needed): Result := TXDataOperationContext.Current.GetManager .Find<TReparateur> .FetchEager('ReparateurContactList') .FetchEager('SiteLlist') .Where(TLinq.Eq('reparateur_id', Id)).UniqueResult; TXDataOperationContext.…

[Julio_R_Ferrari (Julio Ferrari)]

By using expand-level and/or FetchEager, the associated objects will be loaded and it'll take the same additional time, right?
I don't know if there are further technical reasons that cannot allow us to make a brute force request to generate xdata.refs in some cases at our own risk in benefit of both sides performance. I posted a feature request about it.

[wlandgraf (Wagner Landgraf)]

@Julio_R_Ferrari

By using expand-level and/or FetchEager, the associated objects will be loaded and it'll take the same additional time, right?

No, in the case Aurelius will mostly add a JOIN to the SQL and single-valued associations will be loaded in a single SQL statement.