Skip to content

Conversation

mhayes853
Copy link

I prefer to use swift-log for logging over OSLog due to its flexibility (ie. custom log destinations), so I added the ability to use swift-log instead of OSLog with SyncEngine through a new package trait.

Since writing a real wrapper around OSLog seems to not be possible without giving up its built-in performance and redaction guarantees provided by the compiler, I've made this an either-or situation. That is, by enabling the SharingGRDBSwiftLog trait you lose the ability to use OSLog, but I think this is fine since the behavior is explicitly opt-in.

@stephencelis
Copy link
Member

@mhayes853 Thanks for exploring this! We have been a bit busy to consider this at the moment but will try to set aside some time to think through it soon.

@mhayes853
Copy link
Author

Hey @stephencelis, I've had some more time to explore this now, and have made some significant changes.

I've removed the "either-or" scenario by creating a Logger enum with an additional case when the swift-log trait is enabled. This way, one can choose to opt into either logger at runtime if desired. I've also added a defaultLogger property to SyncEngine that uses a swift-log Logger when the trait is enabled, and a typical OS Logger otherwise.

Each log message also had to be duplicated to support best logging practices for both OS Log and swift-log. With swift-log, we can take advantage of its metadata feature to create more structured logs. This is largely in accordance to the structured logging practices documented by this PR.

@stephencelis stephencelis deleted the branch pointfreeco:cloudkit September 17, 2025 00:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants