-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BinaryFormatter removal #2324
Comments
Thank you for taking the interest in Quartz and its binary formatter issues! I'll give some background first which might help with other answers... From version 1.0 onwards the binary formatter has been the solution to store state in database and also to communicate with remote Quartz scheduler. User's have been able to export While serialization of custom calendars and triggers is possible (when database schema cannot handle their data), I'd think it's quite rare. I can't remember issues about such serialization - I might well be wrong too as billion dollar companies rarely come back telling about their successes. Binary serialization for database was the natural choice when porting from Java version where it was also the way to go (as bad as it is in hindsight). Users can store anything that just serializes, but there's configuration switch which is recommended From version 3.0 (released in 2017) onwards Quartz has required you to do an informed decision about the serializer being used, scheduler throwing error when persistence is configured without serialization implementation: quartznet/src/Quartz/Impl/StdSchedulerFactory.cs Lines 709 to 716 in bf813bc
The 3.x is somewhat in maintenance mode and v4 development (
I believe you have found the most use cases, mainly it's the job data map that allows persisting state for a job/trigger between invocations and this state resides in database for cluster workers/failure resistance (
I'm not aware of custom implementations (or NuGet packages offering those). Calendar serializer and others will probably be useful when Newtonsoft.Json will go (at least tried) sunsetting phase. System.Text.Json implementation is still missing but I think v8 of STJ if mature enough to work here. I just haven't had the time.
It could be anything. Quartz documentation suggests that it's better to store only primitive types, but it's not enforced by default. For migration scenarios I would probably create custom
No data for this either, but I'd say a rare case and could be considered as breakable for v4 and then later think how to support if needed by the billion dollar companies behind the curtains 😉 So as a short summary, think v4 in progress should probably not support binary serialization at all, but allow people to write migrating serializer reading data and writing JSON. It's all open for discussion though. |
Hello!
I am trying to wrap my head about the dependency on
BinaryFormatter
and I need some help.BinaryFormatter
in non-test source code is the usage in BinaryObjectSerializer.BinaryObjectSerializer
implementsIObjectSerializer
, it's spread in multiple places in the source code, but it seems thatStdAdoDelegate
is the only type that actually uses it (other places just store it to pass it somewhere else):quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.cs
Line 60 in 72fce9c
quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.cs
Line 477 in 72fce9c
quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.cs
Line 568 in 72fce9c
StdAdoDelegate
is used to:a) Serialize all implementations of public interface
ICalendar
:quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.Calendars.cs
Line 14 in 72fce9c
quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.Calendars.cs
Line 31 in 72fce9c
b) Serialize
NameValueCollection
(more or less aDictionary<string, string>
provided by BCL):quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.cs
Lines 507 to 508 in 72fce9c
c) Serialize sealed
JobDataMap
(more or less a custom wrapper forDictionary<string, object>
)quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.Jobs.cs
Line 272 in 72fce9c
d) Serialize all implementations of public interface
IOperableTrigger
:quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.Triggers.cs
Line 328 in 72fce9c
quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.Triggers.cs
Line 442 in 72fce9c
e) Try to find what is not serializable in
JobDataMap
by trying to serialize all values and stopping on first that fails to serialize.quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.Jobs.cs
Lines 270 to 276 in 72fce9c
quartznet/src/Quartz/Impl/AdoJobStore/StdAdoDelegate.cs
Lines 482 to 489 in 72fce9c
My questions:
ICalendar
implementations and persist it? Do all of the users have to implement ICalendarSerializer?JobDataMap
? Just primitive types likeint
andstring
or perhaps this can be literally anything that is[Serializable]
, including user-defined types?IOperableTrigger
says that it's internal despite being public. Does it mean that users should not derive from this interface and we can focus only on theIOperableTrigger
implementations provided by the library?quartznet/src/Quartz/SPI/IOperableTrigger.cs
Line 4 in 72fce9c
AbstractTrigger
(that implementsIOperableTrigger
) and persist it?quartznet/src/Quartz/Impl/Triggers/AbstractTrigger.cs
Lines 55 to 56 in 72fce9c
Thanks!
The text was updated successfully, but these errors were encountered: