[Improvement]: Define DataObject table datatype more clear

[vmalyk]

Improvement description

For some cases table and structure table require specific handling, but no way to clarify that , because in generated typename - it contains parent type (object,field collection), class name, fieldname.
As suggestion, If adding additionally field type - it'll be helpful for improve field handling on integration side.

[fashxp]

Hi, not sure I can follow you. Can you please elaborate a bit more or provide a more specific example. Thx

[vmalyk]

@fashxp , so, based on changes datatype name looks like:

[fashxp]

I see ... would that be a BC break? As it changes the type name?

[vmalyk]

@fashxp , not sure about BC break. Firstly, previous class name looks like more generic and no idea how it's used now - after applying fix it'll be clear. Secondly, Changes aren't update fields - that more critical for as BC. And last but not least, As I see you've couple the same PRs and issues with likely looks with type names changes (Ex. PR #876) as it's not BC.

Ofc, as suggestion, include these changes to next coming release 1.8.0 - it'll be easier track dependency of might be some potential changes that linked with using old/new field type name.

[fashxp]

@vmalyk I'm looking at it from API consumer perspective and just asking 😄.
I'm just wondering, if the type name is part of some GraphQL query ... which might not work afterwards anymore since the name changed.
Of if someone generated an API SDK based on the graphql schema...might that be a problem when the type name changes?

[fashxp]

#876 is somehow different, as it seems that the type name changes on every request anyway...

[vmalyk]

@fashxp, but it's only 1 way how to clarify field types that important for API consumers and tracking that should be easier as it's present now - and it's 1 way by type name.
How about another approach and adding interface to type with additional fields - cols and rows - will it helps clarify field type and might be helpful for processing data on client side ?
in this case, it won't be BC regarding type and current fields, but it'll be add more ways for manipulate data on "client" side?

[fashxp]

I'm not against the change, just wanted to clarify!
Because when we agree to do it that way, we need to label it as be break, add an upgrade note and wait for the next major - which we eventually could to starting next year...