Tricky to use without SPM

[simme]

Unless I'm missing something it's kind of tricky to use GRDBCombine today if the project is not setup to use SPM for everything.

I'm currently using GRDB through a git submodule and adding the project file to my workspace and building the framework as a dependency to my app.

The dependency on GRDB defined in the package manifest makes it so that GRDB is downloaded as a package when generate-xcodeproj is run to generate a Xcode project to use in a similar manner to how I'm currently using GRDB.

That same dependency also means that Xcode starts fetching a second copy of GRDB when the package is added to the workspace.

The only solution (except for switching to SPM for everything) that doesn't result in two downloads of GRDB in my project is to download the source files and import them directly into the project. Which becomes hard to maintain instead.

I can't say I have a good solution for this. Could a project without any references to SPM be included in the repo perhaps?

[groue]

Hi @simme!

Indeed today GRDBCombine is SPM-only.

I can't say I have a good solution for this.

I don't see many.

Could a project without any references to SPM be included in the repo perhaps?

Thats one solution, which could lead to something similar to the existing GRDB manual installation. Ideally, this project would contain one target per supported platform. I don't quite know how it would itself integrate with GRDB.

You can also copy GRDBCombine sources in your own app.

A last solution would be to merge GRDBCombine inside GRDB itself. That's indeed a trend: many libraries come with built-in publishers, instead of shipping a separate library.

[simme]

I don't quite know how it would itself integrate with GRDB.

Since the source files of GRDBCombine import GRDB it seems like that would be up to the developer in the manual installation case? Just make sure GRDB is also linked and included in the app bundle it shouldn't be a problem. Right?

You can also copy GRDBCombine sources in your own app.

This is what I'm probably going to do now, since I really want to play around more with GRDB and combine in this data layer refactor I'm doing. Maintaining the dependency will be a little more error-prone, that's ok though.

A last solution would be to merge GRDBCombine inside GRDB itself.

From my perspective I could see this being nice. Seeing as Combine is a "first class citizen" of Apples platforms now. Although the modular approach is clean, for sure.

I can also understand that there's a certain hesitancy since GRDBCombine isn't considered a 1.0 yet.

[groue]

I can also understand that there's a certain hesitancy since GRDBCombine isn't considered a 1.0 yet.

Fortunately, GRDB has the Experimental flag: we can break anything at this level ;-)

[groue]

In short, I think this is the way to go. Until GRDBCombine is merged in the main repo, I'm sorry it's not that easy to use it without SPM.

[simme]

Fortunately, GRDB has the Experimental flag: we can break anything at this level ;-)

What are we waiting for!? :D

In short, I think this is the way to go. Until GRDBCombine is merged in the main repo, I'm sorry it's not that easy to use it without SPM.

Yeah, that's what I'll do. Thanks for the response, as usual! :)

---

Maybe I should create a new issue for this, but while we're at it: What do you feel is missing from GRDBCombine to make it into a 1.0 now that Combine is out of beta?

[groue]

What do you feel is missing from GRDBCombine to make it into a 1.0 now that Combine is out of beta?

Well,

• I can't do proper QA. My personal experience with Combine and SwiftUI is too thin. I don't know how well the existing GRDBCombine APIs fit with other practices (and not only the trivial ones).
• The @DatabasePublished property wrapper suffers from multiple known issues. It only supports the main queue (and does not prevent misuses). It can't grab the DatabaseQueue or Pool from the SwiftUI environment, as @FetchRequest does, and this may the sign of a dependency injection problem. It exposes a Result (not very handy to use), unlike @FetchRequest. That's two big differences from the "official" Core Data property wrapper, and this raises an alert (one can dislike Core Data, but one should carefully look at programming patterns vetted by Apple). And there's #18.

So... This is all still very much experimental, and we're not at 1.0 😅

[simme]

That makes perfect sense.

I'm going to try and use it a bit in my app and see what happens. I immediately ran in to issues with @DatabasePublished though, since it needs some static/global reference to a Database to be initialized.

I'll report any other findings or bugs!

[groue]

I immediately ran in to issues with @DatabasePublished though, since it needs some static/global reference to a Database to be initialized.

Yep, that's exactly the issue about "dependency injection" I was talking about. Related: https://github.com/groue/GRDBCombine/issues/17#issuecomment-536248985

In all honesty, my advice would be to pick one of those two paths:

• Forget about DatabasePublished, use plain observation publishers, and build your app.
• Clone GRDBCombine, try to make DatabasePublished able to deal with real-world problems, build your app much more slowly, and maybe reach a point where you feel comfortable setting up a pull request.

[simme]

Thanks for the input!