FieldBuilder phase 2 improvement

[sima-zhu]

1. Give field builder unsupported type a default value instead of throw error.
   Field builder and Field annotation. #10500 (comment)

2. Use collection base class. + Fix the array type.
   Field builder and Field annotation. #10500 (comment)

3. Name property override.
   Field builder and Field annotation. #10500 (comment)

4. Fixed the problem of not taking inner class.

[conniey]

Is a whitelist easier to maintain than a blacklist?

[heaths]

Regarding the name override, instead to align with mapping actual fields from a document payload (from a query) to index names, we should instead support our respective frameworks' attributes that would already be used. For example, in .NET we use (in track 2) JsonPropertyName from the built-in System.Text.Json. That way, we're not duplicating (or forcing devs to duplicate, rather) property<-> field renames. Since, IIRC, you're using Jackson maybe it's a BeanProperty given a different name that you use.

[sima-zhu]

Give field builder unsupported type a default value
#10500 (comment)

@conniey Regarding this question, FieldBuilder will convert property without annotation to complex field. This is recursive call.
If customer use the following code:

private char something;

Our logic will fall into parsing all properties in char.class. Whitelist is not enough as we do not know if this is a real complex type or the type we do not parse.

Solutions:

1. Map all blacklist to search DataType.
   @heaths what's your proposal on this?

[sima-zhu]

Regarding the name override, instead to align with mapping actual fields from a document payload (from a query) to index names, we should instead support our respective frameworks' attributes that would already be used. For example, in .NET we use (in track 2) JsonPropertyName from the built-in System.Text.Json. That way, we're not duplicating (or forcing devs to duplicate, rather) property<-> field renames. Since, IIRC, you're using Jackson maybe it's a BeanProperty given a different name that you use.

This might introduce complexity in near future. Java is working on adding plugin layer for json library. Customer will have the choice of which library to use.
In this case, we can either only allow Jackson library user to override the name. Or use some other complex helper to get the overridden property name.

[heaths]

Maybe it's a progression, then: we support name overrides in our attributes, then check common ones, then fall back to the name as-is. It's important to remember that Search is case-sensitive. Probably not an issue for Java or JavaScript if people use Java/Script-like field names (examples show this, so probably most common), but an issue for .NET (CamelCase) and Python (snake_case).

As for the DataType question, I'm not sure what you mean.

[sima-zhu]

Fixed bugs for preview 4.
#11532

[sima-zhu]

Move to preview 5 for additions.