Question: Generated Entity Info to include framework models

[BergerBytes]

This is more of a specific question than an overall issue. I am wondering if there is a way for the generate_sources script to also include models included in a framework, In this case, a cocoapod. I am working on a project that has two apps with an internal pod used within both apps. Both apps shared most of the models so they are included within the core framework.

Is there a way I can have Sourcery also generate entity info for the models included in a different module?

[uli-objectbox]

Using ObjectBox both in a framework and the application is not a problem, however mixing entities from the framework and the host app might be more difficult. The entities from the framework will likely end up in a different namespace/module than the ones from the app. So you can't just export the classes and expect them to work.

I can't try any of these at the moment, but things I would try is:

1. Change the script build phase to pass --xcode-module with the same module name for both to Sourcery (you'll probably have to copy the script's contents into the build phase for that). That might be enough to make it all work.
2. Pass the --sources option to Sourcery to provide a folder or individual source files containing the framework's model classes to have the code generated a second time for the app.
3. You might also have to make sure the --model-json option for both runs uses the same model.json file path.

I think those options should let you do what you want, but I haven't tried those yet. Let me know if any of that works or doesn't, there might be a quick way to fix it.

[BergerBytes]

Hey, Thanks for the response!

I've been trying your suggestions with little luck. I'm sure I'm doing something incorrectly.

First, I want to clarify that I don't need to mix entities between the host apps and the framework, they call all be contained within the framework. Hopefully, this will make it easier.

I'm not sure I completely understand your first suggestion. I've tried changing the --xcode-module "${PRODUCT_MODULE_NAME}" argument but since the framework module that I am attempting to use belongs to the Pods project I'm not sure it's available/working.

I also attempted to use the --sources flag but any path I added seemed to not affect the result.

I did get the file to generate when using the Pods project as the value for the --xcode-project flag. I would need to add the generated file to the Pods project which makes that solution very fragile and not automated.

[uli-objectbox]

Oh, if you're just using ObjectBox in the framework and in the app, but not mixing, you need to add the build phase to the framework, too. They're completely separate, and each need their own generated code and model.json file.

That would need to be done before you package up the pod and submit it to CocoaPods (or your own Pods repo, if you have a private one), in the Frameworks project.

You would basically follow the steps the docs outline, but run the Pods/ObjectBox/setup.rb script with the framework project as the parameter, to add the file and build phase. If any step from there to build somehow doesn't work, it would help if you could post any error messages and whether any of the generated files are actually written and contain anything.

[BergerBytes]

Ah, I think I may have misspoke, I want to generate models that are located in the framework for use within the host apps. But the host apps don't need to also generate models.

[BergerBytes]

Just wanted to give an update and ask a follow-up question. I believe I have found a solution to the problem I was having regarding getting the entity generation file to be created. Instead of trying to run the build script phase as part of the host apps target, I add it as a build phase on the frameworks target via the pod spec file. This works well as it is guaranteed to generate the file before the pod's code is compiled. However, there is still a problem with this approach. Because EntityInfo.generated.swift belongs to the framework, anything that is not explicitly marked as public has its access level set to internal. This causes some compilation errors:

Type alias 'EntityType' must be declared public because it matches a requirement in public protocol '__EntityRelatable'

Property 'entityInfo' must be declared public because it matches a requirement in public protocol 'EntityInspectable'

Property '_id' must be declared public because it matches a requirement in public protocol '__EntityRelatable'

These errors are happening because my models are set to be public.

A second issue along the same line, is the convenience init for the Store object is also internal. So it cannot be used in the host apps.

I don't believe I can fix this on my end. If any property/function/type alias that is not private could be marked as public explicitly, that would allow for this setup to work. If that's not something that should be standard, it would also work as a passable arg to sourcery. Let me know your thoughts.

There could be another way to set this up, but I would imagine if the generated file belonged to the host target then it would need to import the framework to have access to the model files, which would also require changes to the generation.

[uli-objectbox]

Sadly, the code generator has no flag to change the access control of the generated code right now.

Which source files are you currently exporting from the framework? Sounds like you are exporting your entities, and also the generated code and ObjectBox itself?

I wonder whether a quick workaround would be to implement methods in your framework that call the non-public methods (everything ObjectBox, basically), and make those public?

I.e. Add a class that owns a store, and creates it based on parameters it is given, and has put methods etc. to write objects out and look them up. That might not work for everything (Query operators might need some extra work from us to be exportable, and you probably don't want to write code equivalent to that wrapping our queries), but you could at least export your actual model classes that way and still take advantage of ObjectBox internally.

Would that work, or is that what you are currently doing, and Swift still notices the non-public protocol conformance declarations and complains about them, even though nothing else outside really uses them?

[BergerBytes]

I don't believe it will be possible to create a wrapper around the generated file. Swift would still notice and wouldn't compile. Without being able to change the access level for the generated properties / functions I don't believe we can use ObjectBox, which is a huge bummer.

[uli-objectbox]

Do you perhaps have an example project that shows your issues? Github link?

[uli-objectbox]

I've exported objects from frameworks that have internal protocol conformances and internal methods in categories just this morning, so seeing what your code does could help clear up where the snag is.

Maybe you're trying to export too much? What I'm suggesting is you mark your model classes as public (your entities). But leave all the generated code internal to the framework. Then add a Database object that takes objects of these classes and (internally) uses ObjectBox to create an ObjectBox database and write the changed objects out.

Your Database object would have a handful of methods like put(_: Entity1), put(_: Entity2), maybe delete(_: Entity1), delete(_: Entity2) and entity1s() -> [Entity1], entity2s() -> [Entity2] for adding, retrieving or removing objects. The one thing they'd do would be call through to ObjectBox (to put(), remove() and query()), but nothing of ObjectBox is visible to users of your framework.

One important detail: Don't make your entities conform to the ObjectBox.Entity protocol, use the // objectbox: Entity annotation, so the conformance to ObjectBox.Entity is defined in the internal code, not publicly to any user of the framework, and you don't have to re-export ObjectBox.Entity to users of your framework either.

[BergerBytes]

I've set up the bare bones project setup that we are using. It can be found here: https://github.com/BergerBytes/ProjectSetup Just a note, This has no Objectbox implementation yet so it's a clean slate. I can add what I've tried in a branch, but I have a feeling I was incorrectly setting it up.

[uli-objectbox]

Ignore my previous message (I've deleted it).

I just had some time to try this myself, and of course you would need to add the ID property, which in turn is defined in the ObjectBox framework. So obviously it's not possible right now to export a class used as an entity. So you would definitely need some changes made to ObjectBox for that to be viable.

So the best you can do with our current Swift release is use ObjectBox internally, and copy the contents of the exported object into the entity, which is a bit awkward, I have to admit. I've amended our internal bug ticket with that information, maybe I can sneak a fix/workaround into a future release.

[uli-objectbox]

Hi,

just wanted to let you know that we've added flags to the code generator that should let you exert the control you need to export ObjectBox entities from a framework. You can find the documentation here: https://swift.objectbox.io/advanced/sourcery#passing-options-to-the-code-generator

Let me know whether that covers your use cases. It works in my test setup, but one never knows :)

We've also modified the setup script so you can point it at a specific target or project to ensure the preprocessor build phase is set up for your framework.

Cheers,
-- Uli

[uli-objectbox]

Hi, the 0.8.0 release has added another improvement for frameworks: You can now define your id field as

var id: UInt64 // objectbox: entityId

so you don't have to expose ObjectBox's Id<> type to your users. Of course that means you could accidentally pass an Id for a Foo to a call that expects the Id for a Bar, so this is only recommended for use cases like frameworks where you may not wish ObjectBox to become part of your public, published API.