Hi Andrus, Being new to Cayenne my understanding of the framework may still be too superficial, but it seems to me the issue comes down to a disparity between CayenneModeler and the capabilities of the Runtime object. Modeler manipulates one project at a time, but the Runtime can bring together multiple projects. If CayenneModeler could open multiple projects simultaneously and work with the combined entity set in the same way the Runtime can, then that would pretty much solve the problem as I see it.
I don't think I understand the "version control" and other portability issues you mention. Aren't those same issues faced by code that combines projects in the Runtime? It's the responsibility of the programmer/user to ensure that related projects are available when needed through whatever build or execution systems they're using. And so it would be in CayenneModeler when opening Cayenne projects that relate to each other. CayenneModeler would only need to recognize when an opened project requires a related project and offer the user a way for the user to locate it. (Some reasonable default behavior could make this quite painless.) If there's concern that it'd be too difficult to locate dependencies that are managed externally (say those managed by Maven, for example), it wouldn't be unreasonable to offer the concept of a project search path with sensible defaults to help with the process. But this seems like a secondary requirement to me. It's much more important for CayenneModeler to focus on its primary function of modeling databases and relationships, even if complex models require a little more work on the user's part. It's better to need a little more work than to be unable to accomplish the task at all. And this "small" change (I realize it's probably a big code change) needn't impact anyone who doesn't use that functionality. Does this make sense, and am I missing something? Thanks, -- Paul > On Jan 21, 2023, at 8:48 AM, Andrus Adamchik <aadamc...@gmail.com> wrote: > > [You don't often get email from aadamc...@gmail.com. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > Hi Paul, > > You are right. If your models are in different Cayenne projects, they are > only combined in runtime, and there's no easy way of creating relationships > between them. And looks like you've already found the workarounds. > > I've had a case like yours, where I ended up creating those relationships > dynamically in the code using "generic" properties. Technically it works, but > takes away from the dev experience. So I'd go with one of the alternatives > that you mentioned if possible. > > In the future I'd like to see such a feature in Cayenne. When we looked at it > previously, we ran into a design problem - how can CayenneModeler discover > those upstream models are in a portable way. I.e. it should would work with > version control, should resolve the same way on any developer machine, and be > agnostic of the IDE and build tools. Be happy to brainstorm this further. > > Thanks, > Andrus > > >> On Jan 20, 2023, at 4:26 PM, Paul L. Merchant Jr. >> <paul.l.merchant...@dartmouth.edu> wrote: >> >> Hi again, >> >> I have another question coming from EnterpriseObjects land: I have a >> situation where two different applications each have their own application >> specific set of tables in their own schemas and share a third set of tables >> in another schema. Each application has tables with relationships to the >> shared tables, but the applications are not related to each other. >> >> In EnterpriseObjects it's possible to create separate models of the shared >> tables and each application's private tables so that one copy of the model >> of the shared tables can be shared between the applications. >> >> Can something similar be done in Cayenne? It appears that multiple projects >> can be imported into a runtime easily enough, but I'm missing how I can >> create relationships between objects in two different projects. The >> alternatives I see are to either duplication the model of the shared tables >> in each application's project or including all the models in one project, >> both of which are less than ideal. Maybe I've missed something? >> >> Thanks! >> >> -- Paul >
