You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Ramiro Aparicio <ra...@prot-on.com> on 2012/10/24 13:19:57 UTC
Splitting model
Hi,
After upgrading to 3.1 it is now more evident that you can split the
data model and data nodes as it is needed so the model can span several
DBs or several models can be in the same DB.
I am a big fan of making everything as modular as possible, and this
configuration helps, but what I think it would be perfect is being able
to put the diferent model files in diferent modules and just orchestrate
DB nodes and model composition in the project file, like a maven project.
I understand that there is nothing like that currently on 3.1 but I
wanted to know if any of you had experience of something like that.
Indeed I am not sure if it can be done as probably path to other modules
models will not be the same when developing or at runtime, but I think
it will be a very interesting feature for big projects.
Ramiro Aparicio
Re: Splitting model
Posted by Andrus Adamchik <an...@objectstyle.org>.
ServerRuntime runtime = new ServerRuntime(new String[] {
"com/example/cayenne-project.xml",
"org/foo/cayenne-library1.xml",
"org/foo/cayenne-library2.xml"
});
There is also a "Merging Multiple Projects" chapter in cayenne-guide.pdf included with 3.1B1 release. It has some more details.
Andrus
On Oct 24, 2012, at 2:58 PM, Ramiro Aparicio <ra...@prot-on.com> wrote:
> Umm I thougth a ServerRuntime could load only one configuration file, can you point me how can I load several?
>
> If thats possible even if the configuration must be done in a Java class (I would prefer XML but it is better that nothing) the only failing point is relationship between models of diferent modules, if they are 1-N it can be easily handled but N-1 or M-N are not that easy (first term is submodule model entity).
>
> Currently I am starting a new project very simple with low entity count so I will try this kind of setting as it makes a lot more sense to me.
>
> Ramiro
>
> El 24/10/2012 13:47, Andrus Adamchik escribió:
>>> I am a big fan of making everything as modular as possible,
>> me too :)
>>
>>> and this configuration helps, but what I think it would be perfect is being able to put the diferent model files in diferent modules and just orchestrate DB nodes and model composition in the project file, like a maven project.
>>> I understand that there is nothing like that currently on 3.1 but I wanted to know if any of you had experience of something like that.
>> Actually I think you can do that in 3.1. There many possible scenarios. One would be a bunch of modules containing mapping-only projects, and then each "leaf" module in the dependency tree (e.g. a webapp project) would include them all when starting its ServerRuntime, and then configure a default DataNode (per CAY-1679 this is possible in 3.1 - dataDomain.setDefaultNode(..)).
>>
>> So I think a combination of DataNode-agnostic mapping projects and Java-based stack assembly (that is made easy in 3.1) should give us ultimate mapping modularity. If there are scenarios not well covered by this, let's discuss.
>>
>> Andrus
>>
>>
>> On Oct 24, 2012, at 2:19 PM, Ramiro Aparicio <ra...@prot-on.com> wrote:
>>
>>> Hi,
>>>
>>> After upgrading to 3.1 it is now more evident that you can split the data model and data nodes as it is needed so the model can span several DBs or several models can be in the same DB.
>>> I am a big fan of making everything as modular as possible, and this configuration helps, but what I think it would be perfect is being able to put the diferent model files in diferent modules and just orchestrate DB nodes and model composition in the project file, like a maven project.
>>> I understand that there is nothing like that currently on 3.1 but I wanted to know if any of you had experience of something like that.
>>> Indeed I am not sure if it can be done as probably path to other modules models will not be the same when developing or at runtime, but I think it will be a very interesting feature for big projects.
>>>
>>> Ramiro Aparicio
>>>
>
>
Re: Splitting model
Posted by Ramiro Aparicio <ra...@prot-on.com>.
My idea was something like model import capabilities, so you can import
models inside models, this needs to have 2 different paths: file path
for modeler and runtime paths
Still this forces to have some special project layout between modules
wich is not the best thing to enforce.
The main use case I can think of is a Core module + extra optional
modules that expands the model with new entities (and usually this needs
relationships with core).
Ramiro
El 24/10/2012 14:24, Andrus Adamchik escribió:
> On Oct 24, 2012, at 2:58 PM, Ramiro Aparicio <ra...@prot-on.com> wrote:
>
>> If thats possible even if the configuration must be done in a Java class (I would prefer XML but it is better that nothing) the only failing point is relationship between models of diferent modules, if they are 1-N it can be easily handled but N-1 or M-N are not that easy (first term is submodule model entity).
> Yeah, relationships would be an issue. It probably warrants a separate discussion with analysis of the real use cases. The problem is more at the mapping level - how do you reference an entity from another module when modeling your dependent module.
>
> Andrus
>
Re: Splitting model
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Oct 24, 2012, at 2:58 PM, Ramiro Aparicio <ra...@prot-on.com> wrote:
> If thats possible even if the configuration must be done in a Java class (I would prefer XML but it is better that nothing) the only failing point is relationship between models of diferent modules, if they are 1-N it can be easily handled but N-1 or M-N are not that easy (first term is submodule model entity).
Yeah, relationships would be an issue. It probably warrants a separate discussion with analysis of the real use cases. The problem is more at the mapping level - how do you reference an entity from another module when modeling your dependent module.
Andrus
Re: Splitting model
Posted by Ramiro Aparicio <ra...@prot-on.com>.
Umm I thougth a ServerRuntime could load only one configuration file,
can you point me how can I load several?
If thats possible even if the configuration must be done in a Java class
(I would prefer XML but it is better that nothing) the only failing
point is relationship between models of diferent modules, if they are
1-N it can be easily handled but N-1 or M-N are not that easy (first
term is submodule model entity).
Currently I am starting a new project very simple with low entity count
so I will try this kind of setting as it makes a lot more sense to me.
Ramiro
El 24/10/2012 13:47, Andrus Adamchik escribió:
>> I am a big fan of making everything as modular as possible,
> me too :)
>
>> and this configuration helps, but what I think it would be perfect is being able to put the diferent model files in diferent modules and just orchestrate DB nodes and model composition in the project file, like a maven project.
>> I understand that there is nothing like that currently on 3.1 but I wanted to know if any of you had experience of something like that.
> Actually I think you can do that in 3.1. There many possible scenarios. One would be a bunch of modules containing mapping-only projects, and then each "leaf" module in the dependency tree (e.g. a webapp project) would include them all when starting its ServerRuntime, and then configure a default DataNode (per CAY-1679 this is possible in 3.1 - dataDomain.setDefaultNode(..)).
>
> So I think a combination of DataNode-agnostic mapping projects and Java-based stack assembly (that is made easy in 3.1) should give us ultimate mapping modularity. If there are scenarios not well covered by this, let's discuss.
>
> Andrus
>
>
> On Oct 24, 2012, at 2:19 PM, Ramiro Aparicio <ra...@prot-on.com> wrote:
>
>> Hi,
>>
>> After upgrading to 3.1 it is now more evident that you can split the data model and data nodes as it is needed so the model can span several DBs or several models can be in the same DB.
>> I am a big fan of making everything as modular as possible, and this configuration helps, but what I think it would be perfect is being able to put the diferent model files in diferent modules and just orchestrate DB nodes and model composition in the project file, like a maven project.
>> I understand that there is nothing like that currently on 3.1 but I wanted to know if any of you had experience of something like that.
>> Indeed I am not sure if it can be done as probably path to other modules models will not be the same when developing or at runtime, but I think it will be a very interesting feature for big projects.
>>
>> Ramiro Aparicio
>>
Re: Splitting model
Posted by Andrus Adamchik <an...@objectstyle.org>.
> I am a big fan of making everything as modular as possible,
me too :)
> and this configuration helps, but what I think it would be perfect is being able to put the diferent model files in diferent modules and just orchestrate DB nodes and model composition in the project file, like a maven project.
> I understand that there is nothing like that currently on 3.1 but I wanted to know if any of you had experience of something like that.
Actually I think you can do that in 3.1. There many possible scenarios. One would be a bunch of modules containing mapping-only projects, and then each "leaf" module in the dependency tree (e.g. a webapp project) would include them all when starting its ServerRuntime, and then configure a default DataNode (per CAY-1679 this is possible in 3.1 - dataDomain.setDefaultNode(..)).
So I think a combination of DataNode-agnostic mapping projects and Java-based stack assembly (that is made easy in 3.1) should give us ultimate mapping modularity. If there are scenarios not well covered by this, let's discuss.
Andrus
On Oct 24, 2012, at 2:19 PM, Ramiro Aparicio <ra...@prot-on.com> wrote:
> Hi,
>
> After upgrading to 3.1 it is now more evident that you can split the data model and data nodes as it is needed so the model can span several DBs or several models can be in the same DB.
> I am a big fan of making everything as modular as possible, and this configuration helps, but what I think it would be perfect is being able to put the diferent model files in diferent modules and just orchestrate DB nodes and model composition in the project file, like a maven project.
> I understand that there is nothing like that currently on 3.1 but I wanted to know if any of you had experience of something like that.
> Indeed I am not sure if it can be done as probably path to other modules models will not be the same when developing or at runtime, but I think it will be a very interesting feature for big projects.
>
> Ramiro Aparicio
>