Skip to content

Add basic QueryEngine scaffolding w/ Encodable hashing #7347

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

Merged
merged 6 commits into from
Apr 10, 2024

Conversation

MaxDesiatov
Copy link
Contributor

@MaxDesiatov MaxDesiatov commented Feb 18, 2024

Motivation:

Caching of computations in SwiftPM is ad-hoc and mostly relies on in-memory ThreadSafeKeyValueStore, which utilizes locking and makes it harder to add Sendable conformances on types that have these stores as properties. To allow consistent and persistent caching when SwiftPM processes are relaunched, we can use a SQLite-backed async-first caching engine.

Modifications:

This change ports most of the current GeneratorEngine implementation from the Swift SDK Generator repository to the SwiftPM code base as QueryEngine. Since SwiftNIO is not supported on Windows, references to AsyncHTTPClient have been removed. Additionally, we can't use macros in the SwiftPM code base either, thus the Query protocol has to conform to Encodable instead of using macro-generated conformances. We don't have a consistent hashing implementation for Encodable yet, and a temporary stub for it is marked with fatalError for now.

Result:

NFC, new QueryEngine module is not used anywhere yet.

This ports most of the current `GeneratorEngine` implementation from the Swift SDK Generator to the SwiftPM code base: https://github.com/apple/swift-sdk-generator/blob/main/Sources/GeneratorEngine/Engine.swift. Since Swift NIO is not supported on Windows, references to `AsyncHTTPClient` have been removed. Additionally, we can't use macros in the SwiftPM code base either, thus the `Query` protocol has to conform to `Encodable` instead. We don't have a consistent hashing implementation for `Encodable` yet, and a temporary stub for it is marked with `fatalError` for now.
@MaxDesiatov MaxDesiatov added concurrency no functional change No user-visible functional changes included labels Feb 18, 2024
@MaxDesiatov MaxDesiatov self-assigned this Feb 18, 2024
@MaxDesiatov
Copy link
Contributor Author

@swift-ci test

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test

@MaxDesiatov MaxDesiatov enabled auto-merge (squash) February 18, 2024 21:11
@MaxDesiatov
Copy link
Contributor Author

@swift-ci test

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test windows

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test windows

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test windows

2 similar comments
@MaxDesiatov
Copy link
Contributor Author

@swift-ci test windows

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test windows

@MaxDesiatov
Copy link
Contributor Author

@swift-ci clean test windows

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test windows

…xd/query-engine-scaffolding

# Conflicts:
#	Package.swift
@MaxDesiatov
Copy link
Contributor Author

@swift-ci test

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test

@MaxDesiatov
Copy link
Contributor Author

@swift-ci test windows

@MaxDesiatov MaxDesiatov merged commit 3dc16db into main Apr 10, 2024
@MaxDesiatov MaxDesiatov deleted the maxd/query-engine-scaffolding branch April 10, 2024 17:40
MaxDesiatov added a commit that referenced this pull request Apr 11, 2024
Depends on #7347.

Previously, `QueryEngine` couldn't cache anything due to a missing
hashing implementation that could be consistent across SwiftPM
relaunches. Here `HashEncoder` is implemented on top `Codable`. While it
probably has certain performance overhead when compared to an
implementation with macros, it should be good enough for prototyping.

New `QueryEngine` now works for trivial computations, as verified by
newly added `QueryEngineTests`.
furby-tm pushed a commit to wabiverse/swift-package-manager that referenced this pull request May 15, 2024
…#7347)

### Motivation:

Caching of computations in SwiftPM is ad-hoc and mostly relies on
in-memory `ThreadSafeKeyValueStore`, which utilizes locking and makes it
harder to add `Sendable` conformances on types that have these stores as
properties. To allow consistent and persistent caching when SwiftPM
processes are relaunched, we can use a SQLite-backed async-first caching
engine.

### Modifications:

This change ports [most of the current `GeneratorEngine`
implementation](https://github.com/apple/swift-sdk-generator/blob/main/Sources/GeneratorEngine/Engine.swift)
from the Swift SDK Generator repository to the SwiftPM code base as
`QueryEngine`. Since SwiftNIO is not supported on Windows, references to
`AsyncHTTPClient` have been removed. Additionally, we can't use macros
in the SwiftPM code base either, thus the `Query` protocol has to
conform to `Encodable` instead of using macro-generated conformances. We
don't have a consistent hashing implementation for `Encodable` yet, and
a temporary stub for it is marked with `fatalError` for now.

### Result:

NFC, new `QueryEngine` module is not used anywhere yet.
furby-tm pushed a commit to wabiverse/swift-package-manager that referenced this pull request May 15, 2024
Depends on swiftlang#7347.

Previously, `QueryEngine` couldn't cache anything due to a missing
hashing implementation that could be consistent across SwiftPM
relaunches. Here `HashEncoder` is implemented on top `Codable`. While it
probably has certain performance overhead when compared to an
implementation with macros, it should be good enough for prototyping.

New `QueryEngine` now works for trivial computations, as verified by
newly added `QueryEngineTests`.
furby-tm pushed a commit to wabiverse/swift-package-manager that referenced this pull request May 15, 2024
…#7347)

### Motivation:

Caching of computations in SwiftPM is ad-hoc and mostly relies on
in-memory `ThreadSafeKeyValueStore`, which utilizes locking and makes it
harder to add `Sendable` conformances on types that have these stores as
properties. To allow consistent and persistent caching when SwiftPM
processes are relaunched, we can use a SQLite-backed async-first caching
engine.

### Modifications:

This change ports [most of the current `GeneratorEngine`
implementation](https://github.com/apple/swift-sdk-generator/blob/main/Sources/GeneratorEngine/Engine.swift)
from the Swift SDK Generator repository to the SwiftPM code base as
`QueryEngine`. Since SwiftNIO is not supported on Windows, references to
`AsyncHTTPClient` have been removed. Additionally, we can't use macros
in the SwiftPM code base either, thus the `Query` protocol has to
conform to `Encodable` instead of using macro-generated conformances. We
don't have a consistent hashing implementation for `Encodable` yet, and
a temporary stub for it is marked with `fatalError` for now.

### Result:

NFC, new `QueryEngine` module is not used anywhere yet.
furby-tm pushed a commit to wabiverse/swift-package-manager that referenced this pull request May 15, 2024
Depends on swiftlang#7347.

Previously, `QueryEngine` couldn't cache anything due to a missing
hashing implementation that could be consistent across SwiftPM
relaunches. Here `HashEncoder` is implemented on top `Codable`. While it
probably has certain performance overhead when compared to an
implementation with macros, it should be good enough for prototyping.

New `QueryEngine` now works for trivial computations, as verified by
newly added `QueryEngineTests`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
concurrency no functional change No user-visible functional changes included
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants