SebastianGruza commented on PR #3209: URL: https://github.com/apache/hugegraph/pull/3209#issuecomment-6017560545
**A question before round 8** Some background first. I proposed DECIMAL because I needed it in one of my own projects: sums of satoshi-scale amounts in a batch update, where a double loses digits. At that point it looked like a small addition: one more entry in `DataType`, a `BigDecimal` serializer, bounds. Eight review rounds later it is clear I underestimated it. Each round has fixed what was raised and each round has found a new path where an exact decimal behaves differently from a double: the request parser, OBJECT values, the schema serializers, SET semantics, the typed GraphSON mappers, the Store wire format, update strategies, the loader's value mapping. The last two rounds were mostly regressions of my own fixes. The honest summary is that the change has outgrown what I had in mind when I opened it, and I don't think the pattern ends on its own, because DECIMAL touches every place a property value passes through and the project has no single conversion point for that. So rather than post another round, I'd like to ask the two of you directly: 1. Is an exact DECIMAL property type something the project wants at all? If the answer is no, or "not in this form", I'd rather hear it now and close this PR together with apache/hugegraph-toolchain#771 and apache/hugegraph-doc#504, than keep taking review time. 2. If yes: would you prefer (a) one more round that fixes the five open items and then a decision, or (b) a split into a smaller first step: server-only, SINGLE cardinality, no OBJECT or SET interplay, no batch-update strategies, documented as experimental, with the rest as follow-ups? My own view is (b): the surface that keeps producing findings is the interaction with the other types, and a narrow first PR would make that interaction explicit instead of discovered round by round. Either way, thank you for the depth of these reviews; the reproductions have been precise every time, and that is the only reason the branch is as far as it is. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
