Transient properties are excluded from the introspection

[lcavadas]

Hi 👋

I'd like to start a discussion around the treatment of Transient fields. As it stands now, the transient fields are simply "removed" from the introspection. While this as a perfectly reasonable approach I am wondering if it should somehow be different.

As I understand it, the whole point of the Transient annotation is simply to exclude it from the database. At the moment it ends up doing quite a bit more than that since the property won't be serialized (it doesn't exist in the introspection).

My question is: Could excluding a transient property from the introspection be excessive and actually have more consequences than intended?

An easy example of this is when using a shared class for both the DB and the API. This simply can't work at the moment if there is anything marked as Transient. By marking a property as Transient I will not get it on the API when the object is serialized. If I don't mark the property as Transient then the database interactions will be invalid. The openapi definition actually shows the Transient properties but they are not retrievable.

I understand that this might be more work than it's worth since it would probably involve quite a bit of changes on micronaut-data but wouldn't the ideal scenario be that Transient excludes the property from the database but not from the serialization?

[graemerocher]

In general it is not great practise to use a shared class from the DB and the API but perhaps this is overreach. Eitherway we can't change this for the 3.x line so it would be something to consider for Micronaut 4.x (or at least make it configurable)

[lcavadas]

Thanks for the quick reply @graemerocher!

I agree the example I'm giving is semi-controversial since, as you stated, can be considered bad practice. It is however a pretty simple one that illustrates the point I'm trying to make - The mere existence (and support) of the annotation in question would indicate that it is a valid use-case to access a property that isn't stored on the database. This becomes quite hard if you use an abstraction in which the type is unknown and you rely on the introspection.

I am curious about what advantages you envision for making it configurable. If you have the time I would love to read about your reasoning for the choice.

In any case, if you consider it worthwhile, I can try and help out. Would more projects (besides core and data) be affected by this potential change?