You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> on 2013/07/12 11:27:20 UTC
Managed relationships and Estatio
Hi, Dan.
We are really curious in practice, about how have you manage relationships in Estatio.
- Have you declare for each one-to-many or many-to-many relationship, the addToXXX, removeFromXXX, modifyXXX, clearXXX methods than can be generated with the Eclipse templates?
If we don't declare the previous methods nor refresh an Entity, the contents on the collection of dependent entities can be incorrect, for example.
If Apache Isis would have an annotation similar to JDO's @Element(mappedBy="xxx") nearly all one-to-many or many-to-many relationships could be automatically managed in both sides, eliminating A LOT of boiler-plate needed just for that. At least we have now automated tests for testing them, with the bidir contract tests.
I understand (but can't imagine a concrete example) that automatically managing relationships in some scenaries could not be desirable, so it could be an Isis config option.
But implementing the current "templated contracts" on the enhanced Isis classes would be a perfect solution. The code on Entities would be just "business code". In our classes, currently we are starting to have 75% code for managing bidir relationships, and 25% business rules, in some case, making it really hard to read.
We could "simplify" all Domain Models telling that they are expressed through Entities and Relationships between them, with business logic (identical to the scientific concept of "Ontology" [1]. So why not better support for Relationships, and not only for developing Entities ?
Please, what do you think? If you are not in favor of implementing managed relationships, what are the reasons in order to properly understand it?
Thanks in advance,
Oscar
[1] http://en.wikipedia.org/wiki/Ontology_(information_science)
Re: Managed relationships and Estatio
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 17 July 2013 11:40, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>
> Instead of modifying each Domain Entity, perhaps some reflection "hack" on
> the unit tests? I don't know the internals, not sure how this could be
> achieved and the effort required. If not possible, I would prefer to add
> those conditions to the tests.
>
Hmm, I can't see a way to do this, I'm afraid. There is no interception
layer to exploit if the collection is being modified directly by an action.
>
>
> Regarding "duplication" of the same object on a DN Set under some
> circumstances, the SortedSet is descending from Set, so it's curious... I
> don't know DN implementation internals neither, but, could it be a problem
> with equalTo, compare, etc contracts? It's just so strange...
>
Yeah, that's what I thought. But in fact, its not that there are two
objects that are equal in the set, it is that the SAME object instance is
in the set twice.
>
>
> All tests by now seem to work ok with just DN annotations, managing DN all
> bidir relationships.
That's good to hear. Always nice to delete code, isn't it.
> There are still some pending (we have migrated to the latest Isis
> snapshot). If anything changes, I will properly inform.
>
> OK, let me know.
Dan
>
>
Re: Managed relationships and Estatio
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
>
> Agreed, some unit tests may break (see my notes above).
>
> Given that relationships are always modified through actions, I am
> considering adding in additional code, clearly marked as being just for
> unit tests... something like:
>
> setAgreement(agreement);
> // for unit tests only; JDO will automatically maintain this
> if(!agreement.getRoles().contains(this)) { agreement.getRoles().add(this); }
>
> It's ugly, I know, but I think I'd rather one line of commented ugliness
> than all the noise of those helper methods.
>
>
>
Instead of modifying each Domain Entity, perhaps some reflection "hack" on the unit tests? I don't know the internals, not sure how this could be achieved and the effort required. If not possible, I would prefer to add those conditions to the tests.
Regarding "duplication" of the same object on a DN Set under some circumstances, the SortedSet is descending from Set, so it's curious... I don't know DN implementation internals neither, but, could it be a problem with equalTo, compare, etc contracts? It's just so strange...
All tests by now seem to work ok with just DN annotations, managing DN all bidir relationships. There are still some pending (we have migrated to the latest Isis snapshot). If anything changes, I will properly inform.
El 17/07/2013, a las 10:21, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> I'm mailing this to users@i.a.o and cc'ing to dev@i.a.o, because it's
> relevant to all, I think.
>
>
>
> On 17 July 2013 08:28, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>>
>> Just a question related to yesterday's BDD implementation (really useful
>> links on the documentation you wrote). If the relationships are going to be
>> managed by DN, there could be a lot of @unit tests (all those where bidir
>> relationships are used) that could fail, couldn't it ?
>>
>>
> Yup, that's true I think. I've just been through Estatio to remove these
> helpers. There were one or two unit tests that broke... that's probably
> more an indication that we don't have nearly enough coverage yet.
>
> What I did in the unit tests - in the given portion - is explicitly set
> both sides of the relationship; see for example [1].
>
> In one case [2] I had to remove an assert because the other side is not
> maintained automatically (more on this below)
>
> I deleted one test [3] that is now tested through the BDD spec.
>
>
>
>>
>> Just to clarify it before refactoring, an example with the Agreement -
>> Roles relationship would be refactored this way:
>>
>> Agreement.java:
>>
>> The relationship, field, getter and setter remains identical (with the
>> same DN annotation):
>> [snip]
>>
>> Remove the following bidir contract methods:
>>
>> public void addToRoles(final AgreementRole agreementRole) {
>> }
>>
>> public void removeFromRoles(final AgreementRole agreementRole) {
>> }
>>
>> correct.
>
>
>
>>
>> AgreementRole.java:
>>
>> No changes on field, getter, setter and annotations (despite the
>> @javax.jdo.annotations.Column(name = "AGREEMENT_ID") is optional, just
>> for changing the name of the generated table column, isn't it?):
>>
>
> correct.
>
>
>
>> [snip]
>>
>>
>> Remove the bidir contract methods:
>>
>> public void modifyAgreement(final Agreement<?> agreement) {
>> }
>>
>> public void clearAgreement() {
>> }
>>
>> correct.
>
>
>
>>
>>
>>
>> So, basically, with just the field, getter, setter and required DN
>> annotations on each side would be enough for production system and
>> integration tests (if the collection is a Set or SortedSet), wouldn't it?
>>
>
> correct.
>
>
>
>>
>> As I told at the beginning, also for unit tests?
>
>
>
> Agreed, some unit tests may break (see my notes above).
>
> Given that relationships are always modified through actions, I am
> considering adding in additional code, clearly marked as being just for
> unit tests... something like:
>
> setAgreement(agreement);
> // for unit tests only; JDO will automatically maintain this
> if(!agreement.getRoles().contains(this)) { agreement.getRoles().add(this); }
>
> It's ugly, I know, but I think I'd rather one line of commented ugliness
> than all the noise of those helper methods.
>
>
>
>
>> It would avoid to load all DN stuff. I've seen your InMemoryDB class and
>> the blog post commenting about it, but still not sure about if it's going
>> to be enough for testing Domain behavior / actions.
>>
>
> That class is just a utility, something I knocked up as a way to set up
> mock service/repo expectations. I don't think it has any impact on this
> discussion
>
>
>>
>> As you are currently making the tests on Estatio, which kind of tests must
>> be done as @integration with current Isis implementation, and for which
>> ones the faster @unit scope can be used?
>>
>
> for now, I'm just focusing on writing @integration specs. I know that puts
> me in conflict with JBRainsberger [4], but it mitigates the risk of
> misunderstanding what JDO/DN is doing under the hood.
>
> What I have found is that, with an @integration spec passing, then when I
> change the tag to @unit, JMock gives me useful information on the
> expectations that are missing. I can then copy these into new sections of
> the step defs. I've done this in Isis' example app [5], but haven't yet
> done so Estatio.
>
>
>
>>
>>
>> We are going to start to make some tests regarding relationships
>> (including 1-1 relationships, with needed flush() in our previous tests).
>> I'll keep you informed.
>>
>>
> I didn't take out the modify/clear helpers for 1:1 bidir relationships, on
> the basis that (a) I didn't have a test to check for regression and (b) if
> DN does maintained the opposing rel (as it probably does), then it wouldn't
> matter if Isis also set that rel with the same value also.
>
> Let me know what you find out.
>
> Thx
> Dan
>
>
>
>>
>> Thanks,
>>
>> Oscar
>>
>>
>>
> [1]
> https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-21
> [2]
> https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-23
> [3]
> https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-18
> [4] http://blog.thecodewhisperer.com/2010/10/16/integrated-tests-are-a-scam
> [5]
> https://github.com/apache/isis/blob/94ccda3a3f43665e42abb34368a513ff9dccb06f/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/specs/todoitem/ToDoItemStepDefs.java#L94
Re: Managed relationships and Estatio
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
>
> Agreed, some unit tests may break (see my notes above).
>
> Given that relationships are always modified through actions, I am
> considering adding in additional code, clearly marked as being just for
> unit tests... something like:
>
> setAgreement(agreement);
> // for unit tests only; JDO will automatically maintain this
> if(!agreement.getRoles().contains(this)) { agreement.getRoles().add(this); }
>
> It's ugly, I know, but I think I'd rather one line of commented ugliness
> than all the noise of those helper methods.
>
>
>
Instead of modifying each Domain Entity, perhaps some reflection "hack" on the unit tests? I don't know the internals, not sure how this could be achieved and the effort required. If not possible, I would prefer to add those conditions to the tests.
Regarding "duplication" of the same object on a DN Set under some circumstances, the SortedSet is descending from Set, so it's curious... I don't know DN implementation internals neither, but, could it be a problem with equalTo, compare, etc contracts? It's just so strange...
All tests by now seem to work ok with just DN annotations, managing DN all bidir relationships. There are still some pending (we have migrated to the latest Isis snapshot). If anything changes, I will properly inform.
El 17/07/2013, a las 10:21, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> I'm mailing this to users@i.a.o and cc'ing to dev@i.a.o, because it's
> relevant to all, I think.
>
>
>
> On 17 July 2013 08:28, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>>
>> Just a question related to yesterday's BDD implementation (really useful
>> links on the documentation you wrote). If the relationships are going to be
>> managed by DN, there could be a lot of @unit tests (all those where bidir
>> relationships are used) that could fail, couldn't it ?
>>
>>
> Yup, that's true I think. I've just been through Estatio to remove these
> helpers. There were one or two unit tests that broke... that's probably
> more an indication that we don't have nearly enough coverage yet.
>
> What I did in the unit tests - in the given portion - is explicitly set
> both sides of the relationship; see for example [1].
>
> In one case [2] I had to remove an assert because the other side is not
> maintained automatically (more on this below)
>
> I deleted one test [3] that is now tested through the BDD spec.
>
>
>
>>
>> Just to clarify it before refactoring, an example with the Agreement -
>> Roles relationship would be refactored this way:
>>
>> Agreement.java:
>>
>> The relationship, field, getter and setter remains identical (with the
>> same DN annotation):
>> [snip]
>>
>> Remove the following bidir contract methods:
>>
>> public void addToRoles(final AgreementRole agreementRole) {
>> }
>>
>> public void removeFromRoles(final AgreementRole agreementRole) {
>> }
>>
>> correct.
>
>
>
>>
>> AgreementRole.java:
>>
>> No changes on field, getter, setter and annotations (despite the
>> @javax.jdo.annotations.Column(name = "AGREEMENT_ID") is optional, just
>> for changing the name of the generated table column, isn't it?):
>>
>
> correct.
>
>
>
>> [snip]
>>
>>
>> Remove the bidir contract methods:
>>
>> public void modifyAgreement(final Agreement<?> agreement) {
>> }
>>
>> public void clearAgreement() {
>> }
>>
>> correct.
>
>
>
>>
>>
>>
>> So, basically, with just the field, getter, setter and required DN
>> annotations on each side would be enough for production system and
>> integration tests (if the collection is a Set or SortedSet), wouldn't it?
>>
>
> correct.
>
>
>
>>
>> As I told at the beginning, also for unit tests?
>
>
>
> Agreed, some unit tests may break (see my notes above).
>
> Given that relationships are always modified through actions, I am
> considering adding in additional code, clearly marked as being just for
> unit tests... something like:
>
> setAgreement(agreement);
> // for unit tests only; JDO will automatically maintain this
> if(!agreement.getRoles().contains(this)) { agreement.getRoles().add(this); }
>
> It's ugly, I know, but I think I'd rather one line of commented ugliness
> than all the noise of those helper methods.
>
>
>
>
>> It would avoid to load all DN stuff. I've seen your InMemoryDB class and
>> the blog post commenting about it, but still not sure about if it's going
>> to be enough for testing Domain behavior / actions.
>>
>
> That class is just a utility, something I knocked up as a way to set up
> mock service/repo expectations. I don't think it has any impact on this
> discussion
>
>
>>
>> As you are currently making the tests on Estatio, which kind of tests must
>> be done as @integration with current Isis implementation, and for which
>> ones the faster @unit scope can be used?
>>
>
> for now, I'm just focusing on writing @integration specs. I know that puts
> me in conflict with JBRainsberger [4], but it mitigates the risk of
> misunderstanding what JDO/DN is doing under the hood.
>
> What I have found is that, with an @integration spec passing, then when I
> change the tag to @unit, JMock gives me useful information on the
> expectations that are missing. I can then copy these into new sections of
> the step defs. I've done this in Isis' example app [5], but haven't yet
> done so Estatio.
>
>
>
>>
>>
>> We are going to start to make some tests regarding relationships
>> (including 1-1 relationships, with needed flush() in our previous tests).
>> I'll keep you informed.
>>
>>
> I didn't take out the modify/clear helpers for 1:1 bidir relationships, on
> the basis that (a) I didn't have a test to check for regression and (b) if
> DN does maintained the opposing rel (as it probably does), then it wouldn't
> matter if Isis also set that rel with the same value also.
>
> Let me know what you find out.
>
> Thx
> Dan
>
>
>
>>
>> Thanks,
>>
>> Oscar
>>
>>
>>
> [1]
> https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-21
> [2]
> https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-23
> [3]
> https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-18
> [4] http://blog.thecodewhisperer.com/2010/10/16/integrated-tests-are-a-scam
> [5]
> https://github.com/apache/isis/blob/94ccda3a3f43665e42abb34368a513ff9dccb06f/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/specs/todoitem/ToDoItemStepDefs.java#L94
Re: Managed relationships and Estatio
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
I'm mailing this to users@i.a.o and cc'ing to dev@i.a.o, because it's
relevant to all, I think.
On 17 July 2013 08:28, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
> Just a question related to yesterday's BDD implementation (really useful
> links on the documentation you wrote). If the relationships are going to be
> managed by DN, there could be a lot of @unit tests (all those where bidir
> relationships are used) that could fail, couldn't it ?
>
>
Yup, that's true I think. I've just been through Estatio to remove these
helpers. There were one or two unit tests that broke... that's probably
more an indication that we don't have nearly enough coverage yet.
What I did in the unit tests - in the given portion - is explicitly set
both sides of the relationship; see for example [1].
In one case [2] I had to remove an assert because the other side is not
maintained automatically (more on this below)
I deleted one test [3] that is now tested through the BDD spec.
>
> Just to clarify it before refactoring, an example with the Agreement -
> Roles relationship would be refactored this way:
>
> Agreement.java:
>
> The relationship, field, getter and setter remains identical (with the
> same DN annotation):
> [snip]
>
> Remove the following bidir contract methods:
>
> public void addToRoles(final AgreementRole agreementRole) {
> }
>
> public void removeFromRoles(final AgreementRole agreementRole) {
> }
>
> correct.
>
> AgreementRole.java:
>
> No changes on field, getter, setter and annotations (despite the
> @javax.jdo.annotations.Column(name = "AGREEMENT_ID") is optional, just
> for changing the name of the generated table column, isn't it?):
>
correct.
> [snip]
>
>
> Remove the bidir contract methods:
>
> public void modifyAgreement(final Agreement<?> agreement) {
> }
>
> public void clearAgreement() {
> }
>
> correct.
>
>
>
> So, basically, with just the field, getter, setter and required DN
> annotations on each side would be enough for production system and
> integration tests (if the collection is a Set or SortedSet), wouldn't it?
>
correct.
>
> As I told at the beginning, also for unit tests?
Agreed, some unit tests may break (see my notes above).
Given that relationships are always modified through actions, I am
considering adding in additional code, clearly marked as being just for
unit tests... something like:
setAgreement(agreement);
// for unit tests only; JDO will automatically maintain this
if(!agreement.getRoles().contains(this)) { agreement.getRoles().add(this); }
It's ugly, I know, but I think I'd rather one line of commented ugliness
than all the noise of those helper methods.
> It would avoid to load all DN stuff. I've seen your InMemoryDB class and
> the blog post commenting about it, but still not sure about if it's going
> to be enough for testing Domain behavior / actions.
>
That class is just a utility, something I knocked up as a way to set up
mock service/repo expectations. I don't think it has any impact on this
discussion
>
> As you are currently making the tests on Estatio, which kind of tests must
> be done as @integration with current Isis implementation, and for which
> ones the faster @unit scope can be used?
>
for now, I'm just focusing on writing @integration specs. I know that puts
me in conflict with JBRainsberger [4], but it mitigates the risk of
misunderstanding what JDO/DN is doing under the hood.
What I have found is that, with an @integration spec passing, then when I
change the tag to @unit, JMock gives me useful information on the
expectations that are missing. I can then copy these into new sections of
the step defs. I've done this in Isis' example app [5], but haven't yet
done so Estatio.
>
>
> We are going to start to make some tests regarding relationships
> (including 1-1 relationships, with needed flush() in our previous tests).
> I'll keep you informed.
>
>
I didn't take out the modify/clear helpers for 1:1 bidir relationships, on
the basis that (a) I didn't have a test to check for regression and (b) if
DN does maintained the opposing rel (as it probably does), then it wouldn't
matter if Isis also set that rel with the same value also.
Let me know what you find out.
Thx
Dan
>
> Thanks,
>
> Oscar
>
>
>
[1]
https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-21
[2]
https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-23
[3]
https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-18
[4] http://blog.thecodewhisperer.com/2010/10/16/integrated-tests-are-a-scam
[5]
https://github.com/apache/isis/blob/94ccda3a3f43665e42abb34368a513ff9dccb06f/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/specs/todoitem/ToDoItemStepDefs.java#L94
Re: Managed relationships and Estatio
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
I'm mailing this to users@i.a.o and cc'ing to dev@i.a.o, because it's
relevant to all, I think.
On 17 July 2013 08:28, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
> Just a question related to yesterday's BDD implementation (really useful
> links on the documentation you wrote). If the relationships are going to be
> managed by DN, there could be a lot of @unit tests (all those where bidir
> relationships are used) that could fail, couldn't it ?
>
>
Yup, that's true I think. I've just been through Estatio to remove these
helpers. There were one or two unit tests that broke... that's probably
more an indication that we don't have nearly enough coverage yet.
What I did in the unit tests - in the given portion - is explicitly set
both sides of the relationship; see for example [1].
In one case [2] I had to remove an assert because the other side is not
maintained automatically (more on this below)
I deleted one test [3] that is now tested through the BDD spec.
>
> Just to clarify it before refactoring, an example with the Agreement -
> Roles relationship would be refactored this way:
>
> Agreement.java:
>
> The relationship, field, getter and setter remains identical (with the
> same DN annotation):
> [snip]
>
> Remove the following bidir contract methods:
>
> public void addToRoles(final AgreementRole agreementRole) {
> }
>
> public void removeFromRoles(final AgreementRole agreementRole) {
> }
>
> correct.
>
> AgreementRole.java:
>
> No changes on field, getter, setter and annotations (despite the
> @javax.jdo.annotations.Column(name = "AGREEMENT_ID") is optional, just
> for changing the name of the generated table column, isn't it?):
>
correct.
> [snip]
>
>
> Remove the bidir contract methods:
>
> public void modifyAgreement(final Agreement<?> agreement) {
> }
>
> public void clearAgreement() {
> }
>
> correct.
>
>
>
> So, basically, with just the field, getter, setter and required DN
> annotations on each side would be enough for production system and
> integration tests (if the collection is a Set or SortedSet), wouldn't it?
>
correct.
>
> As I told at the beginning, also for unit tests?
Agreed, some unit tests may break (see my notes above).
Given that relationships are always modified through actions, I am
considering adding in additional code, clearly marked as being just for
unit tests... something like:
setAgreement(agreement);
// for unit tests only; JDO will automatically maintain this
if(!agreement.getRoles().contains(this)) { agreement.getRoles().add(this); }
It's ugly, I know, but I think I'd rather one line of commented ugliness
than all the noise of those helper methods.
> It would avoid to load all DN stuff. I've seen your InMemoryDB class and
> the blog post commenting about it, but still not sure about if it's going
> to be enough for testing Domain behavior / actions.
>
That class is just a utility, something I knocked up as a way to set up
mock service/repo expectations. I don't think it has any impact on this
discussion
>
> As you are currently making the tests on Estatio, which kind of tests must
> be done as @integration with current Isis implementation, and for which
> ones the faster @unit scope can be used?
>
for now, I'm just focusing on writing @integration specs. I know that puts
me in conflict with JBRainsberger [4], but it mitigates the risk of
misunderstanding what JDO/DN is doing under the hood.
What I have found is that, with an @integration spec passing, then when I
change the tag to @unit, JMock gives me useful information on the
expectations that are missing. I can then copy these into new sections of
the step defs. I've done this in Isis' example app [5], but haven't yet
done so Estatio.
>
>
> We are going to start to make some tests regarding relationships
> (including 1-1 relationships, with needed flush() in our previous tests).
> I'll keep you informed.
>
>
I didn't take out the modify/clear helpers for 1:1 bidir relationships, on
the basis that (a) I didn't have a test to check for regression and (b) if
DN does maintained the opposing rel (as it probably does), then it wouldn't
matter if Isis also set that rel with the same value also.
Let me know what you find out.
Thx
Dan
>
> Thanks,
>
> Oscar
>
>
>
[1]
https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-21
[2]
https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-23
[3]
https://github.com/estatio/estatio/commit/2dfd0903718a3ad769a02e4908ef45edaefae0f9#diff-18
[4] http://blog.thecodewhisperer.com/2010/10/16/integrated-tests-are-a-scam
[5]
https://github.com/apache/isis/blob/94ccda3a3f43665e42abb34368a513ff9dccb06f/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/specs/todoitem/ToDoItemStepDefs.java#L94
Re: Managed relationships and Estatio
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Thanks a lot, Dan.
Relationships are "first-class Domain citizens", so this is really important :-)
Just a question related to yesterday's BDD implementation (really useful links on the documentation you wrote). If the relationships are going to be managed by DN, there could be a lot of @unit tests (all those where bidir relationships are used) that could fail, couldn't it ?
Just to clarify it before refactoring, an example with the Agreement - Roles relationship would be refactored this way:
Agreement.java:
The relationship, field, getter and setter remains identical (with the same DN annotation):
@javax.jdo.annotations.Persistent(mappedBy = "agreement")
private SortedSet<AgreementRole> roles = new TreeSet<AgreementRole>();
@MemberOrder(name = "Roles", sequence = "11")
@Disabled
@Render(Type.EAGERLY)
public SortedSet<AgreementRole> getRoles() {
return roles;
}
public void setRoles(final SortedSet<AgreementRole> actors) {
this.roles = actors;
}
Remove the following bidir contract methods:
public void addToRoles(final AgreementRole agreementRole) {
// check for no-op
if (agreementRole == null || getRoles().contains(agreementRole)) {
return;
}
// associate new
getRoles().add(agreementRole);
agreementRole.setAgreement(this);
}
public void removeFromRoles(final AgreementRole agreementRole) {
// check for no-op
if (agreementRole == null || !getRoles().contains(agreementRole)) {
return;
}
// dissociate existing
getRoles().remove(agreementRole);
agreementRole.setAgreement(null);
}
AgreementRole.java:
No changes on field, getter, setter and annotations (despite the @javax.jdo.annotations.Column(name = "AGREEMENT_ID") is optional, just for changing the name of the generated table column, isn't it?):
@javax.jdo.annotations.Column(name = "AGREEMENT_ID")
private Agreement<?> agreement;
@Title(sequence = "3", prepend = ":")
@MemberOrder(sequence = "1")
@Hidden(where = Where.REFERENCES_PARENT)
public Agreement<?> getAgreement() {
return agreement;
}
public void setAgreement(final Agreement<?> agreement) {
this.agreement = agreement;
}
Remove the bidir contract methods:
public void modifyAgreement(final Agreement<?> agreement) {
Agreement<?> currentAgreement = getAgreement();
// check for no-op
if (agreement == null || agreement.equals(currentAgreement)) {
return;
}
// delegate to parent to associate
if (currentAgreement != null) {
currentAgreement.removeFromRoles(this);
}
agreement.addToRoles(this);
}
public void clearAgreement() {
Agreement<?> currentAgreement = getAgreement();
// check for no-op
if (currentAgreement == null) {
return;
}
// delegate to parent to dissociate
currentAgreement.removeFromRoles(this);
}
So, basically, with just the field, getter, setter and required DN annotations on each side would be enough for production system and integration tests (if the collection is a Set or SortedSet), wouldn't it?
As I told at the beginning, also for unit tests? It would avoid to load all DN stuff. I've seen your InMemoryDB class and the blog post commenting about it, but still not sure about if it's going to be enough for testing Domain behavior / actions.
As you are currently making the tests on Estatio, which kind of tests must be done as @integration with current Isis implementation, and for which ones the faster @unit scope can be used?
We are going to start to make some tests regarding relationships (including 1-1 relationships, with needed flush() in our previous tests). I'll keep you informed.
Thanks,
Oscar
El 17/07/2013, a las 08:20, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 15 July 2013 12:42, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>>
>> On 12 July 2013 10:27, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>>
>>>
>>>
>>
>>> Please, what do you think? If you are not in favor of implementing
>>> managed relationships, what are the reasons in order to properly understand
>>> it?
>>>
>>
>> [snip]
>> rather than get Isis to do this, perhaps all we need to do is to figure
>> out a way to make JDO do the heavy lifting for us. All the JDO docs [4]
>> are a little confusing, it does seem to me that the combination of using
>> Sets/SortedSets and calling DOC#flush() ought to do the trick.
>>
>> Could you do some experiments on that and report back?
>>
>>>
>>>
> Just wanted to follow up on this. In writing the Agreement#addRole BDD
> specs for Estatio, I hit an issue with one of them [5] whereby I appeared
> to get duplicate AgreementRole's in the Lease's roles collection. You can
> reproduce this issue by changing the setXxx() to modifyXxx() in [6], and
> also by commenting out the nextTransaction() method in [7].
>
> To explain this a little more: the nextTransaction() method causes the
> transaction for the "when" (the addRole) to be committed, so that the
> assertions in the "then" start afresh. If the nextTransaction is present,
> then everything is ok.
>
> If the nextTransaction is omitted, then the "then" assertions are performed
> in the same transaction as the "when". If the addRole does a modifyXxx()
> rather than a setXxx(), then what I found was that the DataNucleus-provided
> implementation of SortedSet was no such thing: the AgreementRole for POISON
> was actually in there twice!
>
> What I think happens is that JDO/DN *does* manage the relationship, ie,
> updates the set as a side-effect of the calling
> AgreementRole#setAgreement(...). But, when calling modifyAgreement(...)
> instead of setAgreement(...), in effect Isis also puts the object into the
> so-called "set".
>
> What is odd is that it is only this one scenario that fails in this way;
> other very similar scenarios go through smoothly. Slightly worrying.
>
> But anyway, for now my advice is this:
> a) for Sets and SortedSets, you MUST use setXxx rather than modifyXxx
> b) you can (indeed must) remove all those modify/addTo helper methods.
> (Which is what you were hoping to do in the first place...)
> c) there is no need to call DomainObjectContainer#flush(); that was a red
> herring. In my experiments DN seems to update the object immediately.
>
> If you (for some perverse reason) decide that you do want to stick to using
> modifyXxx, then make sure you don't touch the collection thereafter in the
> same transaction.
>
> Please let me know if you find something that contradicts the above.
>
> Thx
> Dan
>
>
> [4]
>> http://www.datanucleus.org/products/datanucleus/jdo/orm/relationships.html
>>
>> [5]
> https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/integtests/src/test/java/org/estatio/integration/specs/agreement/AgreementSpec_manageRoles.feature#L172
> [6]
> https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/dom/src/main/java/org/estatio/dom/agreement/Agreement.java#L479
> [7]
> https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/integtests/src/test/java/org/estatio/integration/specs/agreement/AgreementStepDefs.java#L228
Re: Managed relationships and Estatio
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Thanks a lot, Dan.
Relationships are "first-class Domain citizens", so this is really important :-)
Just a question related to yesterday's BDD implementation (really useful links on the documentation you wrote). If the relationships are going to be managed by DN, there could be a lot of @unit tests (all those where bidir relationships are used) that could fail, couldn't it ?
Just to clarify it before refactoring, an example with the Agreement - Roles relationship would be refactored this way:
Agreement.java:
The relationship, field, getter and setter remains identical (with the same DN annotation):
@javax.jdo.annotations.Persistent(mappedBy = "agreement")
private SortedSet<AgreementRole> roles = new TreeSet<AgreementRole>();
@MemberOrder(name = "Roles", sequence = "11")
@Disabled
@Render(Type.EAGERLY)
public SortedSet<AgreementRole> getRoles() {
return roles;
}
public void setRoles(final SortedSet<AgreementRole> actors) {
this.roles = actors;
}
Remove the following bidir contract methods:
public void addToRoles(final AgreementRole agreementRole) {
// check for no-op
if (agreementRole == null || getRoles().contains(agreementRole)) {
return;
}
// associate new
getRoles().add(agreementRole);
agreementRole.setAgreement(this);
}
public void removeFromRoles(final AgreementRole agreementRole) {
// check for no-op
if (agreementRole == null || !getRoles().contains(agreementRole)) {
return;
}
// dissociate existing
getRoles().remove(agreementRole);
agreementRole.setAgreement(null);
}
AgreementRole.java:
No changes on field, getter, setter and annotations (despite the @javax.jdo.annotations.Column(name = "AGREEMENT_ID") is optional, just for changing the name of the generated table column, isn't it?):
@javax.jdo.annotations.Column(name = "AGREEMENT_ID")
private Agreement<?> agreement;
@Title(sequence = "3", prepend = ":")
@MemberOrder(sequence = "1")
@Hidden(where = Where.REFERENCES_PARENT)
public Agreement<?> getAgreement() {
return agreement;
}
public void setAgreement(final Agreement<?> agreement) {
this.agreement = agreement;
}
Remove the bidir contract methods:
public void modifyAgreement(final Agreement<?> agreement) {
Agreement<?> currentAgreement = getAgreement();
// check for no-op
if (agreement == null || agreement.equals(currentAgreement)) {
return;
}
// delegate to parent to associate
if (currentAgreement != null) {
currentAgreement.removeFromRoles(this);
}
agreement.addToRoles(this);
}
public void clearAgreement() {
Agreement<?> currentAgreement = getAgreement();
// check for no-op
if (currentAgreement == null) {
return;
}
// delegate to parent to dissociate
currentAgreement.removeFromRoles(this);
}
So, basically, with just the field, getter, setter and required DN annotations on each side would be enough for production system and integration tests (if the collection is a Set or SortedSet), wouldn't it?
As I told at the beginning, also for unit tests? It would avoid to load all DN stuff. I've seen your InMemoryDB class and the blog post commenting about it, but still not sure about if it's going to be enough for testing Domain behavior / actions.
As you are currently making the tests on Estatio, which kind of tests must be done as @integration with current Isis implementation, and for which ones the faster @unit scope can be used?
We are going to start to make some tests regarding relationships (including 1-1 relationships, with needed flush() in our previous tests). I'll keep you informed.
Thanks,
Oscar
El 17/07/2013, a las 08:20, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 15 July 2013 12:42, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>>
>> On 12 July 2013 10:27, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>>
>>>
>>>
>>
>>> Please, what do you think? If you are not in favor of implementing
>>> managed relationships, what are the reasons in order to properly understand
>>> it?
>>>
>>
>> [snip]
>> rather than get Isis to do this, perhaps all we need to do is to figure
>> out a way to make JDO do the heavy lifting for us. All the JDO docs [4]
>> are a little confusing, it does seem to me that the combination of using
>> Sets/SortedSets and calling DOC#flush() ought to do the trick.
>>
>> Could you do some experiments on that and report back?
>>
>>>
>>>
> Just wanted to follow up on this. In writing the Agreement#addRole BDD
> specs for Estatio, I hit an issue with one of them [5] whereby I appeared
> to get duplicate AgreementRole's in the Lease's roles collection. You can
> reproduce this issue by changing the setXxx() to modifyXxx() in [6], and
> also by commenting out the nextTransaction() method in [7].
>
> To explain this a little more: the nextTransaction() method causes the
> transaction for the "when" (the addRole) to be committed, so that the
> assertions in the "then" start afresh. If the nextTransaction is present,
> then everything is ok.
>
> If the nextTransaction is omitted, then the "then" assertions are performed
> in the same transaction as the "when". If the addRole does a modifyXxx()
> rather than a setXxx(), then what I found was that the DataNucleus-provided
> implementation of SortedSet was no such thing: the AgreementRole for POISON
> was actually in there twice!
>
> What I think happens is that JDO/DN *does* manage the relationship, ie,
> updates the set as a side-effect of the calling
> AgreementRole#setAgreement(...). But, when calling modifyAgreement(...)
> instead of setAgreement(...), in effect Isis also puts the object into the
> so-called "set".
>
> What is odd is that it is only this one scenario that fails in this way;
> other very similar scenarios go through smoothly. Slightly worrying.
>
> But anyway, for now my advice is this:
> a) for Sets and SortedSets, you MUST use setXxx rather than modifyXxx
> b) you can (indeed must) remove all those modify/addTo helper methods.
> (Which is what you were hoping to do in the first place...)
> c) there is no need to call DomainObjectContainer#flush(); that was a red
> herring. In my experiments DN seems to update the object immediately.
>
> If you (for some perverse reason) decide that you do want to stick to using
> modifyXxx, then make sure you don't touch the collection thereafter in the
> same transaction.
>
> Please let me know if you find something that contradicts the above.
>
> Thx
> Dan
>
>
> [4]
>> http://www.datanucleus.org/products/datanucleus/jdo/orm/relationships.html
>>
>> [5]
> https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/integtests/src/test/java/org/estatio/integration/specs/agreement/AgreementSpec_manageRoles.feature#L172
> [6]
> https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/dom/src/main/java/org/estatio/dom/agreement/Agreement.java#L479
> [7]
> https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/integtests/src/test/java/org/estatio/integration/specs/agreement/AgreementStepDefs.java#L228
Re: Managed relationships and Estatio
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 15 July 2013 12:42, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
> On 12 July 2013 10:27, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>>
>>
>
>> Please, what do you think? If you are not in favor of implementing
>> managed relationships, what are the reasons in order to properly understand
>> it?
>>
>
> [snip]
> rather than get Isis to do this, perhaps all we need to do is to figure
> out a way to make JDO do the heavy lifting for us. All the JDO docs [4]
> are a little confusing, it does seem to me that the combination of using
> Sets/SortedSets and calling DOC#flush() ought to do the trick.
>
> Could you do some experiments on that and report back?
>
>>
>>
Just wanted to follow up on this. In writing the Agreement#addRole BDD
specs for Estatio, I hit an issue with one of them [5] whereby I appeared
to get duplicate AgreementRole's in the Lease's roles collection. You can
reproduce this issue by changing the setXxx() to modifyXxx() in [6], and
also by commenting out the nextTransaction() method in [7].
To explain this a little more: the nextTransaction() method causes the
transaction for the "when" (the addRole) to be committed, so that the
assertions in the "then" start afresh. If the nextTransaction is present,
then everything is ok.
If the nextTransaction is omitted, then the "then" assertions are performed
in the same transaction as the "when". If the addRole does a modifyXxx()
rather than a setXxx(), then what I found was that the DataNucleus-provided
implementation of SortedSet was no such thing: the AgreementRole for POISON
was actually in there twice!
What I think happens is that JDO/DN *does* manage the relationship, ie,
updates the set as a side-effect of the calling
AgreementRole#setAgreement(...). But, when calling modifyAgreement(...)
instead of setAgreement(...), in effect Isis also puts the object into the
so-called "set".
What is odd is that it is only this one scenario that fails in this way;
other very similar scenarios go through smoothly. Slightly worrying.
But anyway, for now my advice is this:
a) for Sets and SortedSets, you MUST use setXxx rather than modifyXxx
b) you can (indeed must) remove all those modify/addTo helper methods.
(Which is what you were hoping to do in the first place...)
c) there is no need to call DomainObjectContainer#flush(); that was a red
herring. In my experiments DN seems to update the object immediately.
If you (for some perverse reason) decide that you do want to stick to using
modifyXxx, then make sure you don't touch the collection thereafter in the
same transaction.
Please let me know if you find something that contradicts the above.
Thx
Dan
[4]
> http://www.datanucleus.org/products/datanucleus/jdo/orm/relationships.html
>
> [5]
https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/integtests/src/test/java/org/estatio/integration/specs/agreement/AgreementSpec_manageRoles.feature#L172
[6]
https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/dom/src/main/java/org/estatio/dom/agreement/Agreement.java#L479
[7]
https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/integtests/src/test/java/org/estatio/integration/specs/agreement/AgreementStepDefs.java#L228
Re: Managed relationships and Estatio
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 15 July 2013 12:42, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
> On 12 July 2013 10:27, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>>
>>
>
>> Please, what do you think? If you are not in favor of implementing
>> managed relationships, what are the reasons in order to properly understand
>> it?
>>
>
> [snip]
> rather than get Isis to do this, perhaps all we need to do is to figure
> out a way to make JDO do the heavy lifting for us. All the JDO docs [4]
> are a little confusing, it does seem to me that the combination of using
> Sets/SortedSets and calling DOC#flush() ought to do the trick.
>
> Could you do some experiments on that and report back?
>
>>
>>
Just wanted to follow up on this. In writing the Agreement#addRole BDD
specs for Estatio, I hit an issue with one of them [5] whereby I appeared
to get duplicate AgreementRole's in the Lease's roles collection. You can
reproduce this issue by changing the setXxx() to modifyXxx() in [6], and
also by commenting out the nextTransaction() method in [7].
To explain this a little more: the nextTransaction() method causes the
transaction for the "when" (the addRole) to be committed, so that the
assertions in the "then" start afresh. If the nextTransaction is present,
then everything is ok.
If the nextTransaction is omitted, then the "then" assertions are performed
in the same transaction as the "when". If the addRole does a modifyXxx()
rather than a setXxx(), then what I found was that the DataNucleus-provided
implementation of SortedSet was no such thing: the AgreementRole for POISON
was actually in there twice!
What I think happens is that JDO/DN *does* manage the relationship, ie,
updates the set as a side-effect of the calling
AgreementRole#setAgreement(...). But, when calling modifyAgreement(...)
instead of setAgreement(...), in effect Isis also puts the object into the
so-called "set".
What is odd is that it is only this one scenario that fails in this way;
other very similar scenarios go through smoothly. Slightly worrying.
But anyway, for now my advice is this:
a) for Sets and SortedSets, you MUST use setXxx rather than modifyXxx
b) you can (indeed must) remove all those modify/addTo helper methods.
(Which is what you were hoping to do in the first place...)
c) there is no need to call DomainObjectContainer#flush(); that was a red
herring. In my experiments DN seems to update the object immediately.
If you (for some perverse reason) decide that you do want to stick to using
modifyXxx, then make sure you don't touch the collection thereafter in the
same transaction.
Please let me know if you find something that contradicts the above.
Thx
Dan
[4]
> http://www.datanucleus.org/products/datanucleus/jdo/orm/relationships.html
>
> [5]
https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/integtests/src/test/java/org/estatio/integration/specs/agreement/AgreementSpec_manageRoles.feature#L172
[6]
https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/dom/src/main/java/org/estatio/dom/agreement/Agreement.java#L479
[7]
https://github.com/estatio/estatio/blob/63b6df1be801a33dd73884b460b986278e1a5715/integtests/src/test/java/org/estatio/integration/specs/agreement/AgreementStepDefs.java#L228
Re: Managed relationships and Estatio
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Many Thanks Dan and Jeroen!
Great beginning of the week. Estatio and the new BDD support released! Congratulations and many thanks to Jeroen and you.
I'm in a hurry and have not yet finished to build Statio but there was a dependency problem on the web app related to the ms SQL server driver, which must be manually installed and it's not commented as in the QuickStart.
Tomorrow I plan to fully test the Estatio release.
Thanks again,
Oscar
Enviado desde mi iPhone
El 15/07/2013, a las 13:42, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 12 July 2013 10:27, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>> Hi, Dan.
>>
>> We are really curious in practice, about how have you manage relationships
>> in Estatio.
>
> Sorry not to reply sooner... I've actually been getting the Estatio source
> code up and running on github [2]. Yes, it's been open sourced! So you
> can take a look yourself at our efforts.
>
> (Would like to know if it builds ok for someone else, anyway).
>
>
>
>> - Have you declare for each one-to-many or many-to-many relationship, the
>> addToXXX, removeFromXXX, modifyXXX, clearXXX methods than can be generated
>> with the Eclipse templates?
> We've have done it for many, where the relationship is mutable.
>
>
>> If we don't declare the previous methods nor refresh an Entity, the
>> contents on the collection of dependent entities can be incorrect, for
>> example.
> Indeed, that is what we observed: that DN does not seem to actively manage
> the relationship. I seem to remember reading something to that effect
> also. I added in IsisJdoSupport [3] to provide the "refresh" method;
> perhaps you've used that.
>
> Having said that, doing some googling just now, I have found [4].[5], which
> basically says that DN *will* manage Sets (and thus, presumably SortedSets)
> but *will not* manage Lists. We have, over the last few months, been
> moving to using SortedSets exclusively; so it's possible that the issues
> that we saw were when we were using Lists.
>
> There is another factor here, though: DN will only maintain the
> relationship when it it is given some work to do, either (a) at commit time
> (framework controlled) or (b) at flush (application-controlled, using
> DomainObjectContainer#flush()). So as a bare minimum, even if DN does
> maintain Sets, you must still call flush.
>
> As I recall, Jeroen and I took the view that we would just use the
> addTo/removeFrom stuff always.
>
>
>
>> If Apache Isis would have an annotation similar to JDO's
>> @Element(mappedBy="xxx") nearly all one-to-many or many-to-many
>> relationships could be automatically managed in both sides, eliminating A
>> LOT of boiler-plate needed just for that. At least we have now automated
>> tests for testing them, with the bidir contract tests.
>
> (Rather than introduce an Isis specific annotation, I would rather just
> teach Isis to understand the JDO annotation. But that's a minor detail ...)
>
>
>
>>
>> I understand (but can't imagine a concrete example) that automatically
>> managing relationships in some scenaries could not be desirable, so it
>> could be an Isis config option.
>>
>> But implementing the current "templated contracts" on the enhanced Isis
>> classes would be a perfect solution. The code on Entities would be just
>> "business code". In our classes, currently we are starting to have 75% code
>> for managing bidir relationships, and 25% business rules, in some case,
>> making it really hard to read.
>>
>> We could "simplify" all Domain Models telling that they are expressed
>> through Entities and Relationships between them, with business logic
>> (identical to the scientific concept of "Ontology" [1]. So why not better
>> support for Relationships, and not only for developing Entities ?
>
> I hear what you are saying, but I'm wondering how this might actually be
> implemented. Right now Isis only gets to apply its semantics when the
> object is interacted with "through the UI" layer. At least in the Wicket
> viewer, all collections are immutable and so any manipulation of them is
> done in actions, ie programmatically and not through the UI layer.
>
> It could, I suppose, be done by wrapping the pojos (using the
> WrapperFactory), and have it apply the mapping; but that feels rather hacky
> to me.
>
> And, I don't think we can do the change in the bytecode enhancement process
> because that is as specified by the JDO spec, and is not extensible so far
> as I know [6]
>
>
>>
>> Please, what do you think? If you are not in favor of implementing managed
>> relationships, what are the reasons in order to properly understand it?
>
> I can see the benefit, for sure...
>
> So, where I stand on this is: rather than get Isis to do this, perhaps all
> we need to do is to figure out a way to make JDO do the heavy lifting for
> us. All the JDO docs are a little confusing, it does seem to me that the
> combination of using Sets/SortedSets and calling DOC#flush() ought to do
> the trick.
>
> Could you do some experiments on that and report back?
>
> Cheers
> Dan
>
>
>
>>
>> Thanks in advance,
>>
>> Oscar
>
>
>>
>> [1] http://en.wikipedia.org/wiki/Ontology_(information_science)
> [2] https://github.com/estatio/estatio
> [3] https://issues.apache.org/jira/browse/ISIS-386
> [4]
> http://www.datanucleus.org/products/datanucleus/jdo/orm/relationships.html
> [5]
> http://www.datanucleus.org/products/datanucleus/persistence_properties.html
> [6] http://db.apache.org/jdo/enhancement.html
Re: Managed relationships and Estatio
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 12 July 2013 10:27, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
> Hi, Dan.
>
> We are really curious in practice, about how have you manage relationships
> in Estatio.
>
Sorry not to reply sooner... I've actually been getting the Estatio source
code up and running on github [2]. Yes, it's been open sourced! So you
can take a look yourself at our efforts.
(Would like to know if it builds ok for someone else, anyway).
> - Have you declare for each one-to-many or many-to-many relationship, the
> addToXXX, removeFromXXX, modifyXXX, clearXXX methods than can be generated
> with the Eclipse templates?
>
>
We've have done it for many, where the relationship is mutable.
> If we don't declare the previous methods nor refresh an Entity, the
> contents on the collection of dependent entities can be incorrect, for
> example.
>
>
Indeed, that is what we observed: that DN does not seem to actively manage
the relationship. I seem to remember reading something to that effect
also. I added in IsisJdoSupport [3] to provide the "refresh" method;
perhaps you've used that.
Having said that, doing some googling just now, I have found [4].[5], which
basically says that DN *will* manage Sets (and thus, presumably SortedSets)
but *will not* manage Lists. We have, over the last few months, been
moving to using SortedSets exclusively; so it's possible that the issues
that we saw were when we were using Lists.
There is another factor here, though: DN will only maintain the
relationship when it it is given some work to do, either (a) at commit time
(framework controlled) or (b) at flush (application-controlled, using
DomainObjectContainer#flush()). So as a bare minimum, even if DN does
maintain Sets, you must still call flush.
As I recall, Jeroen and I took the view that we would just use the
addTo/removeFrom stuff always.
> If Apache Isis would have an annotation similar to JDO's
> @Element(mappedBy="xxx") nearly all one-to-many or many-to-many
> relationships could be automatically managed in both sides, eliminating A
> LOT of boiler-plate needed just for that. At least we have now automated
> tests for testing them, with the bidir contract tests.
>
(Rather than introduce an Isis specific annotation, I would rather just
teach Isis to understand the JDO annotation. But that's a minor detail ...)
>
> I understand (but can't imagine a concrete example) that automatically
> managing relationships in some scenaries could not be desirable, so it
> could be an Isis config option.
>
> But implementing the current "templated contracts" on the enhanced Isis
> classes would be a perfect solution. The code on Entities would be just
> "business code". In our classes, currently we are starting to have 75% code
> for managing bidir relationships, and 25% business rules, in some case,
> making it really hard to read.
>
> We could "simplify" all Domain Models telling that they are expressed
> through Entities and Relationships between them, with business logic
> (identical to the scientific concept of "Ontology" [1]. So why not better
> support for Relationships, and not only for developing Entities ?
>
I hear what you are saying, but I'm wondering how this might actually be
implemented. Right now Isis only gets to apply its semantics when the
object is interacted with "through the UI" layer. At least in the Wicket
viewer, all collections are immutable and so any manipulation of them is
done in actions, ie programmatically and not through the UI layer.
It could, I suppose, be done by wrapping the pojos (using the
WrapperFactory), and have it apply the mapping; but that feels rather hacky
to me.
And, I don't think we can do the change in the bytecode enhancement process
because that is as specified by the JDO spec, and is not extensible so far
as I know [6]
>
> Please, what do you think? If you are not in favor of implementing managed
> relationships, what are the reasons in order to properly understand it?
>
I can see the benefit, for sure...
So, where I stand on this is: rather than get Isis to do this, perhaps all
we need to do is to figure out a way to make JDO do the heavy lifting for
us. All the JDO docs are a little confusing, it does seem to me that the
combination of using Sets/SortedSets and calling DOC#flush() ought to do
the trick.
Could you do some experiments on that and report back?
Cheers
Dan
>
> Thanks in advance,
>
> Oscar
>
>
>
>
> [1] http://en.wikipedia.org/wiki/Ontology_(information_science)
>
>
[2] https://github.com/estatio/estatio
[3] https://issues.apache.org/jira/browse/ISIS-386
[4]
http://www.datanucleus.org/products/datanucleus/jdo/orm/relationships.html
[5]
http://www.datanucleus.org/products/datanucleus/persistence_properties.html
[6] http://db.apache.org/jdo/enhancement.html