You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the history mechanisms assume that attachment serialization and storage (if enabled) must be managed by the history store itself.
It would be nice if attachment handling (and possibly body content handling too) were a separate service coordinated by the history store, rather than an intrinsic part of the history store itself. This way, the consuming application could provide an alternate attachment store (like a file system store).
Ability to provide an implementation of an attachment handler to any history store
History store would delegate serialization and storage to the handler
History packages would provide a native attachment handler for storing the attachment with the rest of the history data (in the DB for the EF SQL package)
Customers and other packages could provide alternate handlers (like a file system handler) instead.
The text was updated successfully, but these errors were encountered:
Currently, the history mechanisms assume that attachment serialization and storage (if enabled) must be managed by the history store itself.
It would be nice if attachment handling (and possibly body content handling too) were a separate service coordinated by the history store, rather than an intrinsic part of the history store itself. This way, the consuming application could provide an alternate attachment store (like a file system store).
The text was updated successfully, but these errors were encountered: