You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 24, 2026. It is now read-only.
I read through JsonToProtoMessage and would like refactor it as my first contribution. I'd like to know your opinion about the proposed changes and ask for some explanations.
All the fields should be final and CAPITALIZED (they are all deeply constant)
We should migrate from import org.threeten.bp to java.time. This would require migration of com.google.cloud.bigquery.storage.v1.CivilTimeEncoder. As we support Java 8, we should not need it anymore.
Code like /*ignoreUnknownFields*/ false should be replaced with DONT_IGNORE_UNKNOWN_FIELDS field
The topLevel parameter should be removed
fillField and filRepeatedField switch options should be extracted into methods. And even divided more to help JIT optimise the code.
The failing mechanism in fillRepeatedField should be replaced with throwing exception immediately. Otherwise one may think something can happen along the way to fix the situation. The call should be extracted into method
Two variants of convertJsonToProtoMessage method should be removed as they are used only in tests. The conversion should not support null in TableFieldSchema and FieldDescriptor. I think there is no case when it happens except tests. Is there? If yes, then it should be marked @Nullable
Comparing "true" with toLowerCase() should be replaced by equalsIgnoreCase()
The test should not use asterisks for imports
We should prefer for(X x: xs) over for (int i = 0; i < xs.length; i++) {X x = xs[i];}
The JsonDataHasUnknownFieldException should not be final and have protected constructor at the same time. It should be renamed to DataHasUnknownFieldException to be used by developers for other transformers.
Should we support conversion from JSON strings to booleans, ints, etc.?
Should we allow each element on the list to be of different type? Now it is allowed for some elements in the list to be "true" and some can be true.
For nested fields, there is no need to create additional message builder and ignoring it immediately. Is there?
There is no need to repeatedly check field descriptor type for repeated fields. The loop should be inside of each case. We can further optimise by checking the type of the first element on the list and assume all the files are of the same type.
I read through
JsonToProtoMessageand would like refactor it as my first contribution. I'd like to know your opinion about the proposed changes and ask for some explanations.import org.threeten.bptojava.time. This would require migration ofcom.google.cloud.bigquery.storage.v1.CivilTimeEncoder. As we support Java 8, we should not need it anymore./*ignoreUnknownFields*/ falseshould be replaced withDONT_IGNORE_UNKNOWN_FIELDSfieldtopLevelparameter should be removedfillFieldandfilRepeatedFieldswitch options should be extracted into methods. And even divided more to help JIT optimise the code.fillRepeatedFieldshould be replaced with throwing exception immediately. Otherwise one may think something can happen along the way to fix the situation. The call should be extracted into methodconvertJsonToProtoMessagemethod should be removed as they are used only in tests. The conversion should not support null in TableFieldSchema and FieldDescriptor. I think there is no case when it happens except tests. Is there? If yes, then it should be marked@Nullable"true"withtoLowerCase()should be replaced byequalsIgnoreCase()for(X x: xs)overfor (int i = 0; i < xs.length; i++) {X x = xs[i];}JsonDataHasUnknownFieldExceptionshould not be final and have protected constructor at the same time. It should be renamed toDataHasUnknownFieldExceptionto be used by developers for other transformers."true"and some can betrue.Please tell me what you think.