A very important use case is when you are basing a table on third-party class and you are not able to add annotations. People using these classes should be able to tell the reflective adapter (that’s not its real name, but you know what I mean) how to derive a stable ordering for the fields.
There are several possible strategies: Use the natural order from the JVM. (Yes, let people do dumb things.) Order fields alphabetically Order fields alphabetically, putting inherited fields (from base classes) first Order using a list of field names, e.g. [“aid”, “name”, “birthplace”, “books”] and a boolean saying whether to fail if the list is not exhaustive. Look for annotations These strategies would be in the schema.json file (or however the schema is configured). In my opinion, that is preferable to adding annotations. I’d approach this by designing the user’s experience. That is, write the test case for the adapter. Once we have agreed the specification, the implementation is straightforward. Julian > On Feb 9, 2021, at 2:35 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > > Alessandro, thanks for pushing this. > > Frankly speaking, I don't like @CalciteField(order=42) approach. It looks > like annotating the constructor parameters makes more sense, and it is > more flexible. > A similar case is covered in Jackson with "parameter names" module: > https://github.com/FasterXML/jackson-modules-java8/tree/master/parameter-names > Just in case, Java8+ can include parameter names to the reflection info in > case user supplies `-parameters` option for the compiler. > >> NewExpression > > It might indeed be a too low-level API for that. > Could you please highlight which test relies on the order of constructor > arguments? > > By the way, SQL structs rely on the order of the fields rather than field > names. > So it might be ok to rely on the order of the constructor arguments. > > Vladimir
