1st issue: We have no concept of error handling when deserializing:
* if someone puts {{"t"}} or {{"1"}} in a boolean property, we'll interpret it as {{false}} (since we use {{Boolean.parseBoolean}}). We should probably rather throw an exception, but then it'd be a pain to have the error handling code replicated everywhere we use a boolean property in the codebase.
* if someone puts {{"foo"}} in an integer property, we'll throw a {{NumberFormatException}} (I think), and this exception won't include detailed context (in particular, the name of the property will be missing).
2nd issue: We don't validate parameters when starting the job, but only when we use them. So worst case, we may have a job that starts perfectly well, but fails right after the purge due to a wrong parameter.
3rd issue: we end up parsing strings in the hot path of the mass indexing code, for instance {{org.hibernate.search.jsr352.massindexing.impl.steps.lucene.CheckpointAlgorithm.isReadyToCheckpoint()}} or {{org.hibernate.search.jsr352.massindexing.impl.steps.lucene.EntityReader.buildScrollUsingCriteria(StatelessSession, PartitionBound, Object, JobContextData)}}. This may not impact performance a lot, but still, it's not nice. |
|
