[#1835] Implement more types for GraphQl

[EugenMayer]

implements/ fixes #1835

[EugenMayer]

@beikov we tested this one and IMHO, this works out well.

• All output EVs are properly declared as DateTime/Date/Time and serialized by (graphql extended scalars)
• All input Create/Update views are instantiated by BP and all DateTime scalars are properly converted to OffsetLocalTime as by graphql extended scalars spec

i have 3 things still crossing my mind:

• i do not think that the extended types should be part of the MP_TYPES enum. The supported types are basically declared by 'graphql extended scalars' in all cases (MP/DGS/Spring GQL) and serialization and deserialization happens via that library. It is by no means specific to MP
• we should consider having BASIC_TYPES and ADVANCED_TYPES. The former is what we had before and IMHO we should make it possible to fallback to those for all that already using BP with GQL. The new default should be using BASIC_TYPES+ADVANCED_TYPES
• I'am yet not sure how to deal with BigInteger, which you defined to be the GQL Type for Long in MP_TYPES. I cannot really see this is a standard (any Longer), while 'graphql extended scalars' seem to support Long. IMHO we should either offer both mode configurable (big_int_mode) or stick with long as we had. Do you have any compelling arguments why moving to BigInteger would be more conform/rfc/compliant to the GQL spec?

Would be great to have those questions answered to further continue the implementation. The current implementation is very basic:

• no configuration, it is always BASIC_TYPES+MP_TYPES (no way out)
• Long is the type for 'Long', not BigInteger (no way to have BigInteger)

[EugenMayer]

@beikov any chance to get your POV on this so i can finish up the PR?

[EugenMayer]

Implemented the advanced type support using a class file test as we discussed @beikov - see https://github.com/Blazebit/blaze-persistence/pull/1836/files#diff-9f332e007d90470e77f0360a7cfbd8720be501ce3fc4f6839e237d34b20c25c9R157

Tell me if there is anything to adjust

[beikov]

Superseded by #1846

[EugenMayer]

Since i do not see any reason to not being open minded, i might as well be bold.

IMHO, it is not a good practice to throw away work and re-roll the patch instead of giving feedback and let people finish the contribution. This does not exactly motivate to contribute in general. I have no hard feelings here, always glad if thing just move on. But i cannot say i'am happy either.

Just take it as my personal feedback as a developer, not more or less :)

[beikov]

Sorry, but it would have taken us both longer if I had written down the things that weren't quite right and I just wanted to save both our time so you can get your hands on this faster.
You were splitting up the collections into "standard" and "extended" types, but the standard ones contained types that are actually not standard. The extended ones were missing a few entries and as you mentioned, giving "Long" the wrong name.
You're still the commit author, so I'm not removing credit or anything. Thanks for your feedback though.

[EugenMayer]

I'am aware that it would have taken longer, so i really see your motivation. Thanks for taking the feedback in!

But i guess, at least my POV, one has to take the route to guide the people. This way they align to the project ideas, structure, conduct and so forth - and thus contributions become better over time.

I just like open minded and of course, as written, no hard feelings. We are all pulling into the same direction in the end, that is all that matters to me / is essential to me :)