XMLSchedulingDataProcessorPlugin incompatible with StdAdoDelegate when useProperties=true

[Jawvig]

I'm playing around with Quartz.net and adding support for a persistent job store via the ADO.NET Job Store. As per the recommendation in tutorial 9, I'm instructing the job store to persist job parameters in plain text rather than BLOBs, using the configuration:

Unfortunately in triggering a simple job, which has no explicit job data map, I receive this error:

JobDataMap values must be Strings when the 'useProperties' property is set. Key of offending value: LAST_MODIFIED_TIME

When looking in the debugger at the JobDataMap object provided to the job I scheduled, there is no LAST_MODIFIED_TIME present. Digging a bit deeper, it seems that there is another job running called FileScanJob, scheduled by the XMLSchedulingDataProcessorPlugin (used to read the job and trigger configuration from an XML file). This job adds the LAST_MODIFIED_TIME entry to its JobDataMap during job execution, which is of type DateTime rather than string.

This raising an exception due to the implementation of the StdAdoDelegate class. When the quartz.jobStore.useProperties configuration value is set to true it will deliberately fail to write to the job store database any job data that does not use string for both key and value. Despite this restriction, it still uses binary serialization to store the data after this check (in the form of a NameValueCollection).

To come back to the original reason for setting this property, the tutorial advises to use it to avoid serializing complex types and getting into versioning issues after type upgrades. I'd contest that this objective could be simply achieved by supporting all the primitive .NET types whose serialization is not likely to change. The change to StdAdoDelegate would be to perform a type validation of each name/value pair to ensure only simple types are in use in the case of quartz.jobStore.useProperties being true and convert it to System.Collections.Hashtable to allow for changes to the JobDataMap class to be made in Quartz without causing serialization issues.

Another solution could be to have an XmlAdoDelegate that used XML serialization instead of binary serialization.

Maybe I am missing some extra design constraint here?

[skurdiukov]

I think having ability to choose serializer for JobDataMap is a good option.

[skurdiukov]

I found that you can use property "quartz.serializer.type" and define any custom serializer that implement IObjectSerializer interface.

[lahma]

I agree that some relaxations could be made for the basic types as their serialization is well tested and known, the problem just is that serialized implementation is a NameValueCollection that cannot have any other types.

I think that UseProperties can well be false if one acknowledges the possible issues with serialization if non-primitive types are being used.

[lahma]

Well that didn't take long. Now binary serialization is used for job data map that is detected to be from FileScanJob. Kind of a hack, but gets the job done without too much worries.