gortiz commented on issue #10381: URL: https://github.com/apache/pinot/issues/10381#issuecomment-1752628239
I don't understand these properties. I would expect that in V2 there is no nullability query property. The engine should treat nullability as any other type property. The same we don't have properties to treat strings as binaries, we should not have properties to enable/disable nullability. I think we have a clear way to define null column nullability: to set that in the schema. For compatibility reasons, we also have a way to define table level nullability in table config. We can treat the latter as the default column level nullability. ## enableNullhandling Why do we need that? Ideally the table config nullability will tell us the default nullability. Do we expect users changing nullability at runtime? Why? That is not a normal flag in other databases. Are you proposing this property in order to keep backward compatibility so if it is not enabled, V1 ignores column level nullability? My proposal is to do not have this. There is no backward compatibility issue given that column level nullability is a new feature. 1. If users do not define column level nullability in the schema, v1 will honor `tableConfig.getIndexingConfig().isNullHandlingEnabled `, which is backward compatible. 2. If users do define column level nullability, then they have changed the schema, so it is backward compatible to return different values. ## enableNullHandlingIfColumnIsNullable In which situation we want this disabled? I mean, in which cases we expect users to define a column as nullable but want to skip that? It sounds super confusing to understand. -- 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]
