You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Nacho Cánovas Rejón <n....@gesconsultor.com> on 2015/05/21 12:19:09 UTC
1:N Relationships aren't persisted on DB DN4
Hi.
Since we updated to DataNucleus 4 we have some issue about 1:N
relationships.
In DB is not persisted when we add to the collection an element.
I show you one code example of 1:N relationship that fails and to
explain it better:
public abstract class Node extends ActiveStructureElement {
// {{ HostContainer (property)
private Node hostContainer;
@Column(allowsNull = "true")
public Node getHostContainer() {
return this.hostContainer;
}
public void setHostContainer(
final Node node) {
this.hostContainer = node;
}
// }}
// {{ DeployedHosts (Collection)
@Persistent(mappedBy = "hostContainer", dependentElement = "false")
private SortedSet<Node> deployedHosts = new TreeSet<Node>();
public SortedSet<Node> getDeployedHosts() {
return this.deployedHosts;
}
public void setDeployedHosts(
final SortedSet<Node> deployedHosts) {
this.deployedHosts = deployedHosts;
}
public void addToDeployedHosts(
final Node host) {
this.getDeployedHosts().add(host);
this.getContainer().flush();
}
// }}
// {{ addDeployedHost (action)
@MemberOrder(name = "deployedHosts", sequence = "010")
public void addDeployedHost(
@XMSBulkParam @XMSActionField(locales = { @XMSLocale(locale
= "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
this.wrap(this).addToDeployedHosts(host);
}
// }}
}
And we have a test that does:
// when
this.wrap(hypervisor).addDeployedHost(host);
// then
assertThat(hypervisor.getDeployedHosts(), contains((Node) host));
assertThat(host.getHostContainer(), is((Node) hypervisor));
The strange behavior is that this test works well, but when you see if
is persisted on our DB (postgresql), isn't it, and I'm a bit lost
because host.getHostContainer() is finding well the object.
I don't know if it will be some ISIS configuration or DN, but it does
the same in tests and in our app, and it appeared when we update to DN4.
N:M relationships works well and it's important for us to solve it, so
if you need any more information or some ideas to test it, I'll be
available.
Cheers and thanks very much.
--
Ignacio Cánovas Rejón
Tel. 902 900 231
Fax 96 353 19 09
n.canovas@gesconsultor.com
www.gesconsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P. 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Nacho Cánovas Rejón <n....@gesconsultor.com>.
Hi Dan.
I find out where was the problem and doesn't was a wrap problem.
When we setHostContainer(), this executed a CollectionDomainEvent and
then it called a method that I'll put the relevant code.
/if (value != null) {//
// // If it's a Collection ...//
// if (value instanceof Collection) {//
// switch (action) {//
// case DELETE://
// ((Collection)
value).remove(assetToUpsert);//
// break;//
// case UPSERT://
////*((Collection) value).add(assetToUpsert);*//
// break;//
// default://
// break;//
// }//
// } else {//
// // If it's a simple property ...//
// switch (action) {//
// case DELETE://
//PropertyUtils.setSimpleProperty(assetWithProperties,
currentPropertyName, null);//
// break;//
// case UPSERT://
//PropertyUtils.setSimpleProperty(assetWithProperties,
currentPropertyName, assetToUpsert);//
// break;//
// default://
// break;//
// }//
// }//
// }/
You can see that before setHostContainer was completly done, red code is
executed *"this.getDeployedHosts().add(host);**"* and you told me "The
upshot is that you should NEVER programmatically add the child object to
the parent's collection if using JDO Objectstore.".
So the reason was, after *"this.getDeployedHosts().add(host);**"* has
done, *"setHostContainer()*" is called and it seems DN doesn't seems
that some change is done and is like he doesn't tries to persist on DB.
What I don't know is why it worked before...
Cheers.
El 22/05/2015 a las 12:47, Dan Haywood escribió:
> Hi Nacho,
> ok, well this is good news in that it's part of the Isis code and so
> fixable, rather than perhaps our usage of DN4 or a problem in DN4 itself.
>
> I'll see if I can reproduce the case myself given what you've said so far.
>
> And yes, let me know if you find out anything further
>
> Cheers
> Dan
>
>
> On 22 May 2015 at 11:40, Nacho Cánovas Rejón <n....@gesconsultor.com>
> wrote:
>
>> It seems that wrap is hiding exceptions and doesn't throw us errors.
>>
>> First I had a @Disable on hostContainer, so when setting this with wrap(),
>> I didn't receive any information. I don't know if there has been some
>> change in this aspect, because it always notified this case before, there
>> is some configuration for this?.
>>
>> Right now isn't working, but I assume it will be some other exception that
>> doesn't shows.
>>
>> I'll keep you posted.
>>
>>
>> El 22/05/2015 a las 10:28, Dan Haywood escribió:
>>
>>> On 21 May 2015 at 18:28, Nacho Cánovas Rejón <n....@gesconsultor.com>
>>> wrote:
>>>
>>> I have more information Dan.
>>>> I get simpleapp from isis code and put the same relationship type and*it
>>>> worked well*.
>>>>
>>>>
>>>> ok, well that's good news.
>>>
>>>
>>> Then I changed *this.wrap(host).setHostContainer(this);* to
>>>> *host.setHostContainer(this);* (without wrap) in our code and it worked
>>>> well too.
>>>>
>>>> So, right now I assume it can be some library or configuration
>>>>
>>> I don't understand your reasoning here, can you explain?
>>>
>>> if it fails with:
>>>
>>> wrap(host).setHostContainer(this)
>>>
>>> but works with:
>>>
>>> host.setHostContainer(this)
>>>
>>> then doesn't it make sense to trace through the proxy (that wrap(...)
>>> creates) to figure out what's going on?
>>>
>>> I have a couple of ideas...
>>>
>>> 1. perhaps the proxy is detecting a veto of the property modification but
>>> isn't correctly throwing an exception and instead just silently does
>>> nothing; or
>>> 2. perhaps the proxy is detecting a veto of the property modification and
>>> is correctly throwing an exception, but your app (and test?) is somehow
>>> ignoring that exception, or
>>> 3. perhaps (I think this is the most likely) the proxy is setting itself,
>>> still wrapped, as the value of the reference and that is causing DN4 to
>>> fail even though DN3 tolerated it.
>>>
>>>
>>> *** Do we know if the simpleapp fails if you start doing the wrapping?
>>> ****
>>>
>>>
>>> I'd like to understand that before looking into configuration differences
>>> or library issues.
>>>
>>> Thx
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>> (I put same properties to testConfiguration on simpleapp as our tests)
>>>> that is not the same (DN and ISIS libraries are the same but could be
>>>> some
>>>> conflict and use different libraries versions).
>>>>
>>>> Do you know where it can be the problem?
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> El 21/05/2015 a las 14:08, Nacho Cánovas Rejón escribió:
>>>>
>>>> Hi have same issue changing the code like you said
>>>>> (host.setHostContainer(this);) and with
>>>>>
>>>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>>>> , so next step is your sample app.
>>>>>
>>>>>
>>>>> El 21/05/2015 a las 13:00, Dan Haywood escribió:
>>>>>
>>>>> Just looking at the DN documentation on this, where for 1:m managed
>>>>>> bidirectional relationship it says [1]
>>>>>>
>>>>>> "When forming the relation please make sure that you set the relation
>>>>>> at
>>>>>> BOTH sides since DataNucleus would have no way of knowing which end is
>>>>>> correct if you only set one end."
>>>>>>
>>>>>> On the other hand, in our Isis documentation we have the advice [2]:
>>>>>>
>>>>>> "So long as the parent's children collection is a java.util.Set (rather
>>>>>> than a Collection or a List), the JDO Objectstore will automatically
>>>>>> maintain both sides of the relationship. All that is necessary is to
>>>>>> set
>>>>>> the child to refer to the parent."
>>>>>>
>>>>>> I also say:
>>>>>>
>>>>>> "The upshot is that you should NEVER programmatically add the child
>>>>>> object
>>>>>> to the parent's collection if using JDO Objectstore."
>>>>>>
>>>>>> which is what your code does, actually.
>>>>>>
>>>>>> This was on the basis of this thread [3] with Oscar a year or two ago.
>>>>>>
>>>>>> ~~~
>>>>>> So, perhaps you could change your code from:
>>>>>>
>>>>>>
>>>>>> public void addToDeployedHosts(
>>>>>> final Node host) {
>>>>>>
>>>>>> * this.getDeployedHosts().add(host);* this.getContainer().flush();
>>>>>> }
>>>>>>
>>>>>> to:
>>>>>>
>>>>>>
>>>>>> public void addToDeployedHosts(
>>>>>> final Node host) {
>>>>>> * host.setHostContainer(this);*
>>>>>> this.getContainer().flush();
>>>>>> }
>>>>>>
>>>>>>
>>>>>> and see what happens?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thx
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>> http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_collection.html#fk_bi
>>>>>> [2]
>>>>>>
>>>>>>
>>>>>> https://isis.apache.org/components/objectstores/jdo/managed-1-to-m-relationships.html
>>>>>> [3] http://markmail.org/message/agnwmzocvdfht32f
>>>>>>
>>>>>>
>>>>>> On 21 May 2015 at 11:49, Nacho Cánovas Rejón <
>>>>>> n.canovas@gesconsultor.com
>>>>>> wrote:
>>>>>>
>>>>>> Hi Dan.
>>>>>>
>>>>>>> Issue appears in booth places, so isn't UI a problem.
>>>>>>>
>>>>>>> I'll follow your thought and I'll let you now.
>>>>>>>
>>>>>>> Another step I can do is see if this happens in one ISIS sample.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>> El 21/05/2015 a las 12:44, Dan Haywood escribió:
>>>>>>>
>>>>>>> One other thought...
>>>>>>>
>>>>>>>> in Isis a while back we disabled persistenceByReachability in
>>>>>>>> persistor_datanucleus.properties:
>>>>>>>>
>>>>>>>> #
>>>>>>>> # Require explicit persistence (since entities are Comparable and
>>>>>>>> using
>>>>>>>> ObjectContracts#compareTo).
>>>>>>>> # see
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
>>>>>>>> #
>>>>>>>>
>>>>>>>>
>>>>>>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>>>>>>>
>>>>>>>>
>>>>>>>> As the comment says, this was mostly a workaround to the relatively
>>>>>>>> "dumb"
>>>>>>>> way that ObjectContracts#compareTo works.... this is documented on
>>>>>>>> our
>>>>>>>> site
>>>>>>>> [1]
>>>>>>>>
>>>>>>>> I know that persistence by reachability relates to newly created
>>>>>>>> objects,
>>>>>>>> I
>>>>>>>> wonder if it also has a role to play in dirty objects. Almost
>>>>>>>> certainly
>>>>>>>> not, but (if you aren't using ObjectContracts) you could perhaps
>>>>>>>> reenable
>>>>>>>> this setting and see if there's any different behaviour?
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Nacho,
>>>>>>>>
>>>>>>>> Is the issue arising in the running app, or in the test, or both?
>>>>>>>>> Also, if you reproduce in a vanilla simple app based on the Isis
>>>>>>>>> simpleapp
>>>>>>>>> archetype, does that fail too? (In other words, can we eliminate
>>>>>>>>> your
>>>>>>>>> custom UI from the equation?)
>>>>>>>>>
>>>>>>>>> Thx
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 21 May 2015 at 11:19, Nacho Cánovas Rejón <
>>>>>>>>> n.canovas@gesconsultor.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>> Since we updated to DataNucleus 4 we have some issue about 1:N
>>>>>>>>>> relationships.
>>>>>>>>>>
>>>>>>>>>> In DB is not persisted when we add to the collection an element.
>>>>>>>>>>
>>>>>>>>>> I show you one code example of 1:N relationship that fails and to
>>>>>>>>>> explain
>>>>>>>>>> it better:
>>>>>>>>>>
>>>>>>>>>> public abstract class Node extends ActiveStructureElement {
>>>>>>>>>>
>>>>>>>>>> // {{ HostContainer (property)
>>>>>>>>>>
>>>>>>>>>> private Node hostContainer;
>>>>>>>>>>
>>>>>>>>>> @Column(allowsNull = "true")
>>>>>>>>>> public Node getHostContainer() {
>>>>>>>>>> return this.hostContainer;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> public void setHostContainer(
>>>>>>>>>> final Node node) {
>>>>>>>>>> this.hostContainer = node;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> // }}
>>>>>>>>>>
>>>>>>>>>> // {{ DeployedHosts (Collection)
>>>>>>>>>>
>>>>>>>>>> @Persistent(mappedBy = "hostContainer", dependentElement =
>>>>>>>>>> "false")
>>>>>>>>>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>>>>>>>>>
>>>>>>>>>> public SortedSet<Node> getDeployedHosts() {
>>>>>>>>>> return this.deployedHosts;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> public void setDeployedHosts(
>>>>>>>>>> final SortedSet<Node> deployedHosts) {
>>>>>>>>>> this.deployedHosts = deployedHosts;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> public void addToDeployedHosts(
>>>>>>>>>> final Node host) {
>>>>>>>>>> this.getDeployedHosts().add(host);
>>>>>>>>>> this.getContainer().flush();
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> // }}
>>>>>>>>>>
>>>>>>>>>> // {{ addDeployedHost (action)
>>>>>>>>>> @MemberOrder(name = "deployedHosts", sequence = "010")
>>>>>>>>>> public void addDeployedHost(
>>>>>>>>>> @XMSBulkParam @XMSActionField(locales = {
>>>>>>>>>> @XMSLocale(locale =
>>>>>>>>>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>>>>>>>>>> this.wrap(this).addToDeployedHosts(host);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> // }}
>>>>>>>>>>
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> And we have a test that does:
>>>>>>>>>> // when
>>>>>>>>>> this.wrap(hypervisor).addDeployedHost(host);
>>>>>>>>>>
>>>>>>>>>> // then
>>>>>>>>>> assertThat(hypervisor.getDeployedHosts(),
>>>>>>>>>> contains((Node)
>>>>>>>>>> host));
>>>>>>>>>> assertThat(host.getHostContainer(), is((Node)
>>>>>>>>>> hypervisor));
>>>>>>>>>>
>>>>>>>>>> The strange behavior is that this test works well, but when you see
>>>>>>>>>> if
>>>>>>>>>> is
>>>>>>>>>> persisted on our DB (postgresql), isn't it, and I'm a bit lost
>>>>>>>>>> because
>>>>>>>>>> host.getHostContainer() is finding well the object.
>>>>>>>>>>
>>>>>>>>>> I don't know if it will be some ISIS configuration or DN, but it
>>>>>>>>>> does
>>>>>>>>>> the
>>>>>>>>>> same in tests and in our app, and it appeared when we update to
>>>>>>>>>> DN4.
>>>>>>>>>>
>>>>>>>>>> N:M relationships works well and it's important for us to solve it,
>>>>>>>>>> so
>>>>>>>>>> if
>>>>>>>>>> you need any more information or some ideas to test it, I'll be
>>>>>>>>>> available.
>>>>>>>>>>
>>>>>>>>>> Cheers and thanks very much.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ignacio Cánovas Rejón
>>>>>>>>>> Tel. 902 900 231
>>>>>>>>>> Fax 96 353 19 09
>>>>>>>>>> n.canovas@gesconsultor.com
>>>>>>>>>> www.gesconsultor.com
>>>>>>>>>>
>>>>>>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>>>>>>> contienen información reservada que no puede ser difundida. Si
>>>>>>>>>> usted
>>>>>>>>>> ha
>>>>>>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo
>>>>>>>>>> de
>>>>>>>>>> su
>>>>>>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>>>>>>> electrónica;
>>>>>>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna
>>>>>>>>>> persona.
>>>>>>>>>>
>>>>>>>>>> Su dirección de correo electrónico junto a sus datos personales
>>>>>>>>>> constan
>>>>>>>>>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad
>>>>>>>>>> es
>>>>>>>>>> la de
>>>>>>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>>>>>>> disponemos
>>>>>>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
>>>>>>>>>> enviando un
>>>>>>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>>>>>>> siguiente
>>>>>>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C,
>>>>>>>>>> C.P.
>>>>>>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que
>>>>>>>>>> este
>>>>>>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y
>>>>>>>>>> en
>>>>>>>>>> caso
>>>>>>>>>> que los tuvieran eliminarlos.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> Este mensaje no contiene virus ni malware porque la protección de
>>>>>>>>>> avast!
>>>>>>>>>> Antivirus está activa.
>>>>>>>>>> http://www.avast.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>> Ignacio Cánovas Rejón
>>>>>>> Tel. 902 900 231
>>>>>>> Fax 96 353 19 09
>>>>>>> n.canovas@gesconsultor.com
>>>>>>> www.gesconsultor.com
>>>>>>>
>>>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>>>> contienen información reservada que no puede ser difundida. Si usted
>>>>>>> ha
>>>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de
>>>>>>> su
>>>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>>>> electrónica;
>>>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna
>>>>>>> persona.
>>>>>>>
>>>>>>> Su dirección de correo electrónico junto a sus datos personales
>>>>>>> constan
>>>>>>> en
>>>>>>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la
>>>>>>> de
>>>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>>>> disponemos
>>>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando
>>>>>>> un
>>>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>>>> siguiente
>>>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>>>>> caso
>>>>>>> que los tuvieran eliminarlos.
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> Este mensaje no contiene virus ni malware porque la protección de
>>>>>>> avast!
>>>>>>> Antivirus está activa.
>>>>>>> http://www.avast.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> --
>>>> Ignacio Cánovas Rejón
>>>> Tel. 902 900 231
>>>> Fax 96 353 19 09
>>>> n.canovas@gesconsultor.com
>>>> www.gesconsultor.com
>>>>
>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>> contienen información reservada que no puede ser difundida. Si usted ha
>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>> electrónica;
>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>>>
>>>> Su dirección de correo electrónico junto a sus datos personales constan
>>>> en
>>>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>> disponemos
>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>> siguiente
>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>> caso
>>>> que los tuvieran eliminarlos.
>>>>
>>>>
>>>>
>>>> ---
>>>> Este mensaje no contiene virus ni malware porque la protección de avast!
>>>> Antivirus está activa.
>>>> http://www.avast.com
>>>>
>>>>
>> --
>> Ignacio Cánovas Rejón
>> Tel. 902 900 231
>> Fax 96 353 19 09
>> n.canovas@gesconsultor.com
>> www.gesconsultor.com
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted ha
>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales constan en
>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>> mantener el contacto con Ud. Si quiere saber de qué información disponemos
>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
>> que los tuvieran eliminarlos.
>>
>>
>> ---
>> Este mensaje no contiene virus ni malware porque la protección de avast!
>> Antivirus está activa.
>> http://www.avast.com
>>
>>
--
Ignacio Cánovas Rejón
Tel. 902 900 231
Fax 96 353 19 09
n.canovas@gesconsultor.com
www.gesconsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P. 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Nacho,
ok, well this is good news in that it's part of the Isis code and so
fixable, rather than perhaps our usage of DN4 or a problem in DN4 itself.
I'll see if I can reproduce the case myself given what you've said so far.
And yes, let me know if you find out anything further
Cheers
Dan
On 22 May 2015 at 11:40, Nacho Cánovas Rejón <n....@gesconsultor.com>
wrote:
> It seems that wrap is hiding exceptions and doesn't throw us errors.
>
> First I had a @Disable on hostContainer, so when setting this with wrap(),
> I didn't receive any information. I don't know if there has been some
> change in this aspect, because it always notified this case before, there
> is some configuration for this?.
>
> Right now isn't working, but I assume it will be some other exception that
> doesn't shows.
>
> I'll keep you posted.
>
>
> El 22/05/2015 a las 10:28, Dan Haywood escribió:
>
>> On 21 May 2015 at 18:28, Nacho Cánovas Rejón <n....@gesconsultor.com>
>> wrote:
>>
>> I have more information Dan.
>>>
>>> I get simpleapp from isis code and put the same relationship type and*it
>>> worked well*.
>>>
>>>
>>> ok, well that's good news.
>>
>>
>>
>> Then I changed *this.wrap(host).setHostContainer(this);* to
>>> *host.setHostContainer(this);* (without wrap) in our code and it worked
>>> well too.
>>>
>>> So, right now I assume it can be some library or configuration
>>>
>>
>> I don't understand your reasoning here, can you explain?
>>
>> if it fails with:
>>
>> wrap(host).setHostContainer(this)
>>
>> but works with:
>>
>> host.setHostContainer(this)
>>
>> then doesn't it make sense to trace through the proxy (that wrap(...)
>> creates) to figure out what's going on?
>>
>> I have a couple of ideas...
>>
>> 1. perhaps the proxy is detecting a veto of the property modification but
>> isn't correctly throwing an exception and instead just silently does
>> nothing; or
>> 2. perhaps the proxy is detecting a veto of the property modification and
>> is correctly throwing an exception, but your app (and test?) is somehow
>> ignoring that exception, or
>> 3. perhaps (I think this is the most likely) the proxy is setting itself,
>> still wrapped, as the value of the reference and that is causing DN4 to
>> fail even though DN3 tolerated it.
>>
>>
>> *** Do we know if the simpleapp fails if you start doing the wrapping?
>> ****
>>
>>
>> I'd like to understand that before looking into configuration differences
>> or library issues.
>>
>> Thx
>> Dan
>>
>>
>>
>>
>>
>> (I put same properties to testConfiguration on simpleapp as our tests)
>>> that is not the same (DN and ISIS libraries are the same but could be
>>> some
>>> conflict and use different libraries versions).
>>>
>>> Do you know where it can be the problem?
>>>
>>> Thanks!
>>>
>>>
>>>
>>> El 21/05/2015 a las 14:08, Nacho Cánovas Rejón escribió:
>>>
>>> Hi have same issue changing the code like you said
>>>> (host.setHostContainer(this);) and with
>>>>
>>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>>> , so next step is your sample app.
>>>>
>>>>
>>>> El 21/05/2015 a las 13:00, Dan Haywood escribió:
>>>>
>>>> Just looking at the DN documentation on this, where for 1:m managed
>>>>> bidirectional relationship it says [1]
>>>>>
>>>>> "When forming the relation please make sure that you set the relation
>>>>> at
>>>>> BOTH sides since DataNucleus would have no way of knowing which end is
>>>>> correct if you only set one end."
>>>>>
>>>>> On the other hand, in our Isis documentation we have the advice [2]:
>>>>>
>>>>> "So long as the parent's children collection is a java.util.Set (rather
>>>>> than a Collection or a List), the JDO Objectstore will automatically
>>>>> maintain both sides of the relationship. All that is necessary is to
>>>>> set
>>>>> the child to refer to the parent."
>>>>>
>>>>> I also say:
>>>>>
>>>>> "The upshot is that you should NEVER programmatically add the child
>>>>> object
>>>>> to the parent's collection if using JDO Objectstore."
>>>>>
>>>>> which is what your code does, actually.
>>>>>
>>>>> This was on the basis of this thread [3] with Oscar a year or two ago.
>>>>>
>>>>> ~~~
>>>>> So, perhaps you could change your code from:
>>>>>
>>>>>
>>>>> public void addToDeployedHosts(
>>>>> final Node host) {
>>>>>
>>>>> * this.getDeployedHosts().add(host);* this.getContainer().flush();
>>>>> }
>>>>>
>>>>> to:
>>>>>
>>>>>
>>>>> public void addToDeployedHosts(
>>>>> final Node host) {
>>>>> * host.setHostContainer(this);*
>>>>> this.getContainer().flush();
>>>>> }
>>>>>
>>>>>
>>>>> and see what happens?
>>>>>
>>>>>
>>>>>
>>>>> Thx
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>> http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_collection.html#fk_bi
>>>>> [2]
>>>>>
>>>>>
>>>>> https://isis.apache.org/components/objectstores/jdo/managed-1-to-m-relationships.html
>>>>> [3] http://markmail.org/message/agnwmzocvdfht32f
>>>>>
>>>>>
>>>>> On 21 May 2015 at 11:49, Nacho Cánovas Rejón <
>>>>> n.canovas@gesconsultor.com
>>>>> wrote:
>>>>>
>>>>> Hi Dan.
>>>>>
>>>>>> Issue appears in booth places, so isn't UI a problem.
>>>>>>
>>>>>> I'll follow your thought and I'll let you now.
>>>>>>
>>>>>> Another step I can do is see if this happens in one ISIS sample.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> El 21/05/2015 a las 12:44, Dan Haywood escribió:
>>>>>>
>>>>>> One other thought...
>>>>>>
>>>>>>> in Isis a while back we disabled persistenceByReachability in
>>>>>>> persistor_datanucleus.properties:
>>>>>>>
>>>>>>> #
>>>>>>> # Require explicit persistence (since entities are Comparable and
>>>>>>> using
>>>>>>> ObjectContracts#compareTo).
>>>>>>> # see
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
>>>>>>> #
>>>>>>>
>>>>>>>
>>>>>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>>>>>>
>>>>>>>
>>>>>>> As the comment says, this was mostly a workaround to the relatively
>>>>>>> "dumb"
>>>>>>> way that ObjectContracts#compareTo works.... this is documented on
>>>>>>> our
>>>>>>> site
>>>>>>> [1]
>>>>>>>
>>>>>>> I know that persistence by reachability relates to newly created
>>>>>>> objects,
>>>>>>> I
>>>>>>> wonder if it also has a role to play in dirty objects. Almost
>>>>>>> certainly
>>>>>>> not, but (if you aren't using ObjectContracts) you could perhaps
>>>>>>> reenable
>>>>>>> this setting and see if there's any different behaviour?
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Nacho,
>>>>>>>
>>>>>>> Is the issue arising in the running app, or in the test, or both?
>>>>>>>>
>>>>>>>> Also, if you reproduce in a vanilla simple app based on the Isis
>>>>>>>> simpleapp
>>>>>>>> archetype, does that fail too? (In other words, can we eliminate
>>>>>>>> your
>>>>>>>> custom UI from the equation?)
>>>>>>>>
>>>>>>>> Thx
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 21 May 2015 at 11:19, Nacho Cánovas Rejón <
>>>>>>>> n.canovas@gesconsultor.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> Since we updated to DataNucleus 4 we have some issue about 1:N
>>>>>>>>> relationships.
>>>>>>>>>
>>>>>>>>> In DB is not persisted when we add to the collection an element.
>>>>>>>>>
>>>>>>>>> I show you one code example of 1:N relationship that fails and to
>>>>>>>>> explain
>>>>>>>>> it better:
>>>>>>>>>
>>>>>>>>> public abstract class Node extends ActiveStructureElement {
>>>>>>>>>
>>>>>>>>> // {{ HostContainer (property)
>>>>>>>>>
>>>>>>>>> private Node hostContainer;
>>>>>>>>>
>>>>>>>>> @Column(allowsNull = "true")
>>>>>>>>> public Node getHostContainer() {
>>>>>>>>> return this.hostContainer;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public void setHostContainer(
>>>>>>>>> final Node node) {
>>>>>>>>> this.hostContainer = node;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // }}
>>>>>>>>>
>>>>>>>>> // {{ DeployedHosts (Collection)
>>>>>>>>>
>>>>>>>>> @Persistent(mappedBy = "hostContainer", dependentElement =
>>>>>>>>> "false")
>>>>>>>>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>>>>>>>>
>>>>>>>>> public SortedSet<Node> getDeployedHosts() {
>>>>>>>>> return this.deployedHosts;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public void setDeployedHosts(
>>>>>>>>> final SortedSet<Node> deployedHosts) {
>>>>>>>>> this.deployedHosts = deployedHosts;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> public void addToDeployedHosts(
>>>>>>>>> final Node host) {
>>>>>>>>> this.getDeployedHosts().add(host);
>>>>>>>>> this.getContainer().flush();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // }}
>>>>>>>>>
>>>>>>>>> // {{ addDeployedHost (action)
>>>>>>>>> @MemberOrder(name = "deployedHosts", sequence = "010")
>>>>>>>>> public void addDeployedHost(
>>>>>>>>> @XMSBulkParam @XMSActionField(locales = {
>>>>>>>>> @XMSLocale(locale =
>>>>>>>>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>>>>>>>>> this.wrap(this).addToDeployedHosts(host);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // }}
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> And we have a test that does:
>>>>>>>>> // when
>>>>>>>>> this.wrap(hypervisor).addDeployedHost(host);
>>>>>>>>>
>>>>>>>>> // then
>>>>>>>>> assertThat(hypervisor.getDeployedHosts(),
>>>>>>>>> contains((Node)
>>>>>>>>> host));
>>>>>>>>> assertThat(host.getHostContainer(), is((Node)
>>>>>>>>> hypervisor));
>>>>>>>>>
>>>>>>>>> The strange behavior is that this test works well, but when you see
>>>>>>>>> if
>>>>>>>>> is
>>>>>>>>> persisted on our DB (postgresql), isn't it, and I'm a bit lost
>>>>>>>>> because
>>>>>>>>> host.getHostContainer() is finding well the object.
>>>>>>>>>
>>>>>>>>> I don't know if it will be some ISIS configuration or DN, but it
>>>>>>>>> does
>>>>>>>>> the
>>>>>>>>> same in tests and in our app, and it appeared when we update to
>>>>>>>>> DN4.
>>>>>>>>>
>>>>>>>>> N:M relationships works well and it's important for us to solve it,
>>>>>>>>> so
>>>>>>>>> if
>>>>>>>>> you need any more information or some ideas to test it, I'll be
>>>>>>>>> available.
>>>>>>>>>
>>>>>>>>> Cheers and thanks very much.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ignacio Cánovas Rejón
>>>>>>>>> Tel. 902 900 231
>>>>>>>>> Fax 96 353 19 09
>>>>>>>>> n.canovas@gesconsultor.com
>>>>>>>>> www.gesconsultor.com
>>>>>>>>>
>>>>>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>>>>>> contienen información reservada que no puede ser difundida. Si
>>>>>>>>> usted
>>>>>>>>> ha
>>>>>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo
>>>>>>>>> de
>>>>>>>>> su
>>>>>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>>>>>> electrónica;
>>>>>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna
>>>>>>>>> persona.
>>>>>>>>>
>>>>>>>>> Su dirección de correo electrónico junto a sus datos personales
>>>>>>>>> constan
>>>>>>>>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad
>>>>>>>>> es
>>>>>>>>> la de
>>>>>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>>>>>> disponemos
>>>>>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
>>>>>>>>> enviando un
>>>>>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>>>>>> siguiente
>>>>>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C,
>>>>>>>>> C.P.
>>>>>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que
>>>>>>>>> este
>>>>>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y
>>>>>>>>> en
>>>>>>>>> caso
>>>>>>>>> que los tuvieran eliminarlos.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> Este mensaje no contiene virus ni malware porque la protección de
>>>>>>>>> avast!
>>>>>>>>> Antivirus está activa.
>>>>>>>>> http://www.avast.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>> Ignacio Cánovas Rejón
>>>>>> Tel. 902 900 231
>>>>>> Fax 96 353 19 09
>>>>>> n.canovas@gesconsultor.com
>>>>>> www.gesconsultor.com
>>>>>>
>>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>>> contienen información reservada que no puede ser difundida. Si usted
>>>>>> ha
>>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de
>>>>>> su
>>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>>> electrónica;
>>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna
>>>>>> persona.
>>>>>>
>>>>>> Su dirección de correo electrónico junto a sus datos personales
>>>>>> constan
>>>>>> en
>>>>>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la
>>>>>> de
>>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>>> disponemos
>>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando
>>>>>> un
>>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>>> siguiente
>>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>>>> caso
>>>>>> que los tuvieran eliminarlos.
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Este mensaje no contiene virus ni malware porque la protección de
>>>>>> avast!
>>>>>> Antivirus está activa.
>>>>>> http://www.avast.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>> Ignacio Cánovas Rejón
>>> Tel. 902 900 231
>>> Fax 96 353 19 09
>>> n.canovas@gesconsultor.com
>>> www.gesconsultor.com
>>>
>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>> contienen información reservada que no puede ser difundida. Si usted ha
>>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>>> sistema y avisar al remitente mediante reenvío a su dirección
>>> electrónica;
>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>>
>>> Su dirección de correo electrónico junto a sus datos personales constan
>>> en
>>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>>> mantener el contacto con Ud. Si quiere saber de qué información
>>> disponemos
>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>> siguiente
>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>> caso
>>> que los tuvieran eliminarlos.
>>>
>>>
>>>
>>> ---
>>> Este mensaje no contiene virus ni malware porque la protección de avast!
>>> Antivirus está activa.
>>> http://www.avast.com
>>>
>>>
>
> --
> Ignacio Cánovas Rejón
> Tel. 902 900 231
> Fax 96 353 19 09
> n.canovas@gesconsultor.com
> www.gesconsultor.com
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
> que los tuvieran eliminarlos.
>
>
> ---
> Este mensaje no contiene virus ni malware porque la protección de avast!
> Antivirus está activa.
> http://www.avast.com
>
>
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Nacho Cánovas Rejón <n....@gesconsultor.com>.
It seems that wrap is hiding exceptions and doesn't throw us errors.
First I had a @Disable on hostContainer, so when setting this with
wrap(), I didn't receive any information. I don't know if there has been
some change in this aspect, because it always notified this case before,
there is some configuration for this?.
Right now isn't working, but I assume it will be some other exception
that doesn't shows.
I'll keep you posted.
El 22/05/2015 a las 10:28, Dan Haywood escribió:
> On 21 May 2015 at 18:28, Nacho Cánovas Rejón <n....@gesconsultor.com>
> wrote:
>
>> I have more information Dan.
>>
>> I get simpleapp from isis code and put the same relationship type and*it
>> worked well*.
>>
>>
> ok, well that's good news.
>
>
>
>> Then I changed *this.wrap(host).setHostContainer(this);* to
>> *host.setHostContainer(this);* (without wrap) in our code and it worked
>> well too.
>>
>> So, right now I assume it can be some library or configuration
>
> I don't understand your reasoning here, can you explain?
>
> if it fails with:
>
> wrap(host).setHostContainer(this)
>
> but works with:
>
> host.setHostContainer(this)
>
> then doesn't it make sense to trace through the proxy (that wrap(...)
> creates) to figure out what's going on?
>
> I have a couple of ideas...
>
> 1. perhaps the proxy is detecting a veto of the property modification but
> isn't correctly throwing an exception and instead just silently does
> nothing; or
> 2. perhaps the proxy is detecting a veto of the property modification and
> is correctly throwing an exception, but your app (and test?) is somehow
> ignoring that exception, or
> 3. perhaps (I think this is the most likely) the proxy is setting itself,
> still wrapped, as the value of the reference and that is causing DN4 to
> fail even though DN3 tolerated it.
>
>
> *** Do we know if the simpleapp fails if you start doing the wrapping? ****
>
>
> I'd like to understand that before looking into configuration differences
> or library issues.
>
> Thx
> Dan
>
>
>
>
>
>> (I put same properties to testConfiguration on simpleapp as our tests)
>> that is not the same (DN and ISIS libraries are the same but could be some
>> conflict and use different libraries versions).
>>
>> Do you know where it can be the problem?
>>
>> Thanks!
>>
>>
>>
>> El 21/05/2015 a las 14:08, Nacho Cánovas Rejón escribió:
>>
>>> Hi have same issue changing the code like you said
>>> (host.setHostContainer(this);) and with
>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>> , so next step is your sample app.
>>>
>>>
>>> El 21/05/2015 a las 13:00, Dan Haywood escribió:
>>>
>>>> Just looking at the DN documentation on this, where for 1:m managed
>>>> bidirectional relationship it says [1]
>>>>
>>>> "When forming the relation please make sure that you set the relation at
>>>> BOTH sides since DataNucleus would have no way of knowing which end is
>>>> correct if you only set one end."
>>>>
>>>> On the other hand, in our Isis documentation we have the advice [2]:
>>>>
>>>> "So long as the parent's children collection is a java.util.Set (rather
>>>> than a Collection or a List), the JDO Objectstore will automatically
>>>> maintain both sides of the relationship. All that is necessary is to set
>>>> the child to refer to the parent."
>>>>
>>>> I also say:
>>>>
>>>> "The upshot is that you should NEVER programmatically add the child
>>>> object
>>>> to the parent's collection if using JDO Objectstore."
>>>>
>>>> which is what your code does, actually.
>>>>
>>>> This was on the basis of this thread [3] with Oscar a year or two ago.
>>>>
>>>> ~~~
>>>> So, perhaps you could change your code from:
>>>>
>>>>
>>>> public void addToDeployedHosts(
>>>> final Node host) {
>>>>
>>>> * this.getDeployedHosts().add(host);* this.getContainer().flush();
>>>> }
>>>>
>>>> to:
>>>>
>>>>
>>>> public void addToDeployedHosts(
>>>> final Node host) {
>>>> * host.setHostContainer(this);*
>>>> this.getContainer().flush();
>>>> }
>>>>
>>>>
>>>> and see what happens?
>>>>
>>>>
>>>>
>>>> Thx
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>> [1]
>>>>
>>>> http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_collection.html#fk_bi
>>>> [2]
>>>>
>>>> https://isis.apache.org/components/objectstores/jdo/managed-1-to-m-relationships.html
>>>> [3] http://markmail.org/message/agnwmzocvdfht32f
>>>>
>>>>
>>>> On 21 May 2015 at 11:49, Nacho Cánovas Rejón <n.canovas@gesconsultor.com
>>>> wrote:
>>>>
>>>> Hi Dan.
>>>>> Issue appears in booth places, so isn't UI a problem.
>>>>>
>>>>> I'll follow your thought and I'll let you now.
>>>>>
>>>>> Another step I can do is see if this happens in one ISIS sample.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> El 21/05/2015 a las 12:44, Dan Haywood escribió:
>>>>>
>>>>> One other thought...
>>>>>> in Isis a while back we disabled persistenceByReachability in
>>>>>> persistor_datanucleus.properties:
>>>>>>
>>>>>> #
>>>>>> # Require explicit persistence (since entities are Comparable and using
>>>>>> ObjectContracts#compareTo).
>>>>>> # see
>>>>>>
>>>>>>
>>>>>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
>>>>>> #
>>>>>>
>>>>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>>>>>
>>>>>>
>>>>>> As the comment says, this was mostly a workaround to the relatively
>>>>>> "dumb"
>>>>>> way that ObjectContracts#compareTo works.... this is documented on our
>>>>>> site
>>>>>> [1]
>>>>>>
>>>>>> I know that persistence by reachability relates to newly created
>>>>>> objects,
>>>>>> I
>>>>>> wonder if it also has a role to play in dirty objects. Almost certainly
>>>>>> not, but (if you aren't using ObjectContracts) you could perhaps
>>>>>> reenable
>>>>>> this setting and see if there's any different behaviour?
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>> http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Nacho,
>>>>>>
>>>>>>> Is the issue arising in the running app, or in the test, or both?
>>>>>>>
>>>>>>> Also, if you reproduce in a vanilla simple app based on the Isis
>>>>>>> simpleapp
>>>>>>> archetype, does that fail too? (In other words, can we eliminate your
>>>>>>> custom UI from the equation?)
>>>>>>>
>>>>>>> Thx
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 21 May 2015 at 11:19, Nacho Cánovas Rejón <
>>>>>>> n.canovas@gesconsultor.com
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>>> Since we updated to DataNucleus 4 we have some issue about 1:N
>>>>>>>> relationships.
>>>>>>>>
>>>>>>>> In DB is not persisted when we add to the collection an element.
>>>>>>>>
>>>>>>>> I show you one code example of 1:N relationship that fails and to
>>>>>>>> explain
>>>>>>>> it better:
>>>>>>>>
>>>>>>>> public abstract class Node extends ActiveStructureElement {
>>>>>>>>
>>>>>>>> // {{ HostContainer (property)
>>>>>>>>
>>>>>>>> private Node hostContainer;
>>>>>>>>
>>>>>>>> @Column(allowsNull = "true")
>>>>>>>> public Node getHostContainer() {
>>>>>>>> return this.hostContainer;
>>>>>>>> }
>>>>>>>>
>>>>>>>> public void setHostContainer(
>>>>>>>> final Node node) {
>>>>>>>> this.hostContainer = node;
>>>>>>>> }
>>>>>>>>
>>>>>>>> // }}
>>>>>>>>
>>>>>>>> // {{ DeployedHosts (Collection)
>>>>>>>>
>>>>>>>> @Persistent(mappedBy = "hostContainer", dependentElement =
>>>>>>>> "false")
>>>>>>>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>>>>>>>
>>>>>>>> public SortedSet<Node> getDeployedHosts() {
>>>>>>>> return this.deployedHosts;
>>>>>>>> }
>>>>>>>>
>>>>>>>> public void setDeployedHosts(
>>>>>>>> final SortedSet<Node> deployedHosts) {
>>>>>>>> this.deployedHosts = deployedHosts;
>>>>>>>> }
>>>>>>>>
>>>>>>>> public void addToDeployedHosts(
>>>>>>>> final Node host) {
>>>>>>>> this.getDeployedHosts().add(host);
>>>>>>>> this.getContainer().flush();
>>>>>>>> }
>>>>>>>>
>>>>>>>> // }}
>>>>>>>>
>>>>>>>> // {{ addDeployedHost (action)
>>>>>>>> @MemberOrder(name = "deployedHosts", sequence = "010")
>>>>>>>> public void addDeployedHost(
>>>>>>>> @XMSBulkParam @XMSActionField(locales = {
>>>>>>>> @XMSLocale(locale =
>>>>>>>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>>>>>>>> this.wrap(this).addToDeployedHosts(host);
>>>>>>>> }
>>>>>>>>
>>>>>>>> // }}
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> And we have a test that does:
>>>>>>>> // when
>>>>>>>> this.wrap(hypervisor).addDeployedHost(host);
>>>>>>>>
>>>>>>>> // then
>>>>>>>> assertThat(hypervisor.getDeployedHosts(), contains((Node)
>>>>>>>> host));
>>>>>>>> assertThat(host.getHostContainer(), is((Node) hypervisor));
>>>>>>>>
>>>>>>>> The strange behavior is that this test works well, but when you see
>>>>>>>> if
>>>>>>>> is
>>>>>>>> persisted on our DB (postgresql), isn't it, and I'm a bit lost
>>>>>>>> because
>>>>>>>> host.getHostContainer() is finding well the object.
>>>>>>>>
>>>>>>>> I don't know if it will be some ISIS configuration or DN, but it does
>>>>>>>> the
>>>>>>>> same in tests and in our app, and it appeared when we update to DN4.
>>>>>>>>
>>>>>>>> N:M relationships works well and it's important for us to solve it,
>>>>>>>> so
>>>>>>>> if
>>>>>>>> you need any more information or some ideas to test it, I'll be
>>>>>>>> available.
>>>>>>>>
>>>>>>>> Cheers and thanks very much.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ignacio Cánovas Rejón
>>>>>>>> Tel. 902 900 231
>>>>>>>> Fax 96 353 19 09
>>>>>>>> n.canovas@gesconsultor.com
>>>>>>>> www.gesconsultor.com
>>>>>>>>
>>>>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>>>>> contienen información reservada que no puede ser difundida. Si usted
>>>>>>>> ha
>>>>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de
>>>>>>>> su
>>>>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>>>>> electrónica;
>>>>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna
>>>>>>>> persona.
>>>>>>>>
>>>>>>>> Su dirección de correo electrónico junto a sus datos personales
>>>>>>>> constan
>>>>>>>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es
>>>>>>>> la de
>>>>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>>>>> disponemos
>>>>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
>>>>>>>> enviando un
>>>>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>>>>> siguiente
>>>>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C,
>>>>>>>> C.P.
>>>>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>>>>>> caso
>>>>>>>> que los tuvieran eliminarlos.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> Este mensaje no contiene virus ni malware porque la protección de
>>>>>>>> avast!
>>>>>>>> Antivirus está activa.
>>>>>>>> http://www.avast.com
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>> Ignacio Cánovas Rejón
>>>>> Tel. 902 900 231
>>>>> Fax 96 353 19 09
>>>>> n.canovas@gesconsultor.com
>>>>> www.gesconsultor.com
>>>>>
>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>> contienen información reservada que no puede ser difundida. Si usted ha
>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>> electrónica;
>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>>>>
>>>>> Su dirección de correo electrónico junto a sus datos personales constan
>>>>> en
>>>>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>> disponemos
>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>> siguiente
>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>>> caso
>>>>> que los tuvieran eliminarlos.
>>>>>
>>>>>
>>>>> ---
>>>>> Este mensaje no contiene virus ni malware porque la protección de avast!
>>>>> Antivirus está activa.
>>>>> http://www.avast.com
>>>>>
>>>>>
>>>>>
>>>
>> --
>> Ignacio Cánovas Rejón
>> Tel. 902 900 231
>> Fax 96 353 19 09
>> n.canovas@gesconsultor.com
>> www.gesconsultor.com
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted ha
>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales constan en
>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>> mantener el contacto con Ud. Si quiere saber de qué información disponemos
>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
>> que los tuvieran eliminarlos.
>>
>>
>>
>> ---
>> Este mensaje no contiene virus ni malware porque la protección de avast!
>> Antivirus está activa.
>> http://www.avast.com
>>
--
Ignacio Cánovas Rejón
Tel. 902 900 231
Fax 96 353 19 09
n.canovas@gesconsultor.com
www.gesconsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P. 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 21 May 2015 at 18:28, Nacho Cánovas Rejón <n....@gesconsultor.com>
wrote:
> I have more information Dan.
>
> I get simpleapp from isis code and put the same relationship type and*it
> worked well*.
>
>
ok, well that's good news.
> Then I changed *this.wrap(host).setHostContainer(this);* to
> *host.setHostContainer(this);* (without wrap) in our code and it worked
> well too.
>
> So, right now I assume it can be some library or configuration
I don't understand your reasoning here, can you explain?
if it fails with:
wrap(host).setHostContainer(this)
but works with:
host.setHostContainer(this)
then doesn't it make sense to trace through the proxy (that wrap(...)
creates) to figure out what's going on?
I have a couple of ideas...
1. perhaps the proxy is detecting a veto of the property modification but
isn't correctly throwing an exception and instead just silently does
nothing; or
2. perhaps the proxy is detecting a veto of the property modification and
is correctly throwing an exception, but your app (and test?) is somehow
ignoring that exception, or
3. perhaps (I think this is the most likely) the proxy is setting itself,
still wrapped, as the value of the reference and that is causing DN4 to
fail even though DN3 tolerated it.
*** Do we know if the simpleapp fails if you start doing the wrapping? ****
I'd like to understand that before looking into configuration differences
or library issues.
Thx
Dan
> (I put same properties to testConfiguration on simpleapp as our tests)
> that is not the same (DN and ISIS libraries are the same but could be some
> conflict and use different libraries versions).
>
> Do you know where it can be the problem?
>
> Thanks!
>
>
>
> El 21/05/2015 a las 14:08, Nacho Cánovas Rejón escribió:
>
>> Hi have same issue changing the code like you said
>> (host.setHostContainer(this);) and with
>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>> , so next step is your sample app.
>>
>>
>> El 21/05/2015 a las 13:00, Dan Haywood escribió:
>>
>>> Just looking at the DN documentation on this, where for 1:m managed
>>> bidirectional relationship it says [1]
>>>
>>> "When forming the relation please make sure that you set the relation at
>>> BOTH sides since DataNucleus would have no way of knowing which end is
>>> correct if you only set one end."
>>>
>>> On the other hand, in our Isis documentation we have the advice [2]:
>>>
>>> "So long as the parent's children collection is a java.util.Set (rather
>>> than a Collection or a List), the JDO Objectstore will automatically
>>> maintain both sides of the relationship. All that is necessary is to set
>>> the child to refer to the parent."
>>>
>>> I also say:
>>>
>>> "The upshot is that you should NEVER programmatically add the child
>>> object
>>> to the parent's collection if using JDO Objectstore."
>>>
>>> which is what your code does, actually.
>>>
>>> This was on the basis of this thread [3] with Oscar a year or two ago.
>>>
>>> ~~~
>>> So, perhaps you could change your code from:
>>>
>>>
>>> public void addToDeployedHosts(
>>> final Node host) {
>>>
>>> * this.getDeployedHosts().add(host);* this.getContainer().flush();
>>> }
>>>
>>> to:
>>>
>>>
>>> public void addToDeployedHosts(
>>> final Node host) {
>>> * host.setHostContainer(this);*
>>> this.getContainer().flush();
>>> }
>>>
>>>
>>> and see what happens?
>>>
>>>
>>>
>>> Thx
>>> Dan
>>>
>>>
>>>
>>>
>>> [1]
>>>
>>> http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_collection.html#fk_bi
>>> [2]
>>>
>>> https://isis.apache.org/components/objectstores/jdo/managed-1-to-m-relationships.html
>>> [3] http://markmail.org/message/agnwmzocvdfht32f
>>>
>>>
>>> On 21 May 2015 at 11:49, Nacho Cánovas Rejón <n.canovas@gesconsultor.com
>>> >
>>> wrote:
>>>
>>> Hi Dan.
>>>>
>>>> Issue appears in booth places, so isn't UI a problem.
>>>>
>>>> I'll follow your thought and I'll let you now.
>>>>
>>>> Another step I can do is see if this happens in one ISIS sample.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> El 21/05/2015 a las 12:44, Dan Haywood escribió:
>>>>
>>>> One other thought...
>>>>>
>>>>> in Isis a while back we disabled persistenceByReachability in
>>>>> persistor_datanucleus.properties:
>>>>>
>>>>> #
>>>>> # Require explicit persistence (since entities are Comparable and using
>>>>> ObjectContracts#compareTo).
>>>>> # see
>>>>>
>>>>>
>>>>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
>>>>> #
>>>>>
>>>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>>>>
>>>>>
>>>>> As the comment says, this was mostly a workaround to the relatively
>>>>> "dumb"
>>>>> way that ObjectContracts#compareTo works.... this is documented on our
>>>>> site
>>>>> [1]
>>>>>
>>>>> I know that persistence by reachability relates to newly created
>>>>> objects,
>>>>> I
>>>>> wonder if it also has a role to play in dirty objects. Almost certainly
>>>>> not, but (if you aren't using ObjectContracts) you could perhaps
>>>>> reenable
>>>>> this setting and see if there's any different behaviour?
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>> http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk>
>>>>> wrote:
>>>>>
>>>>> Hi Nacho,
>>>>>
>>>>>> Is the issue arising in the running app, or in the test, or both?
>>>>>>
>>>>>> Also, if you reproduce in a vanilla simple app based on the Isis
>>>>>> simpleapp
>>>>>> archetype, does that fail too? (In other words, can we eliminate your
>>>>>> custom UI from the equation?)
>>>>>>
>>>>>> Thx
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 21 May 2015 at 11:19, Nacho Cánovas Rejón <
>>>>>> n.canovas@gesconsultor.com
>>>>>> wrote:
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>>> Since we updated to DataNucleus 4 we have some issue about 1:N
>>>>>>> relationships.
>>>>>>>
>>>>>>> In DB is not persisted when we add to the collection an element.
>>>>>>>
>>>>>>> I show you one code example of 1:N relationship that fails and to
>>>>>>> explain
>>>>>>> it better:
>>>>>>>
>>>>>>> public abstract class Node extends ActiveStructureElement {
>>>>>>>
>>>>>>> // {{ HostContainer (property)
>>>>>>>
>>>>>>> private Node hostContainer;
>>>>>>>
>>>>>>> @Column(allowsNull = "true")
>>>>>>> public Node getHostContainer() {
>>>>>>> return this.hostContainer;
>>>>>>> }
>>>>>>>
>>>>>>> public void setHostContainer(
>>>>>>> final Node node) {
>>>>>>> this.hostContainer = node;
>>>>>>> }
>>>>>>>
>>>>>>> // }}
>>>>>>>
>>>>>>> // {{ DeployedHosts (Collection)
>>>>>>>
>>>>>>> @Persistent(mappedBy = "hostContainer", dependentElement =
>>>>>>> "false")
>>>>>>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>>>>>>
>>>>>>> public SortedSet<Node> getDeployedHosts() {
>>>>>>> return this.deployedHosts;
>>>>>>> }
>>>>>>>
>>>>>>> public void setDeployedHosts(
>>>>>>> final SortedSet<Node> deployedHosts) {
>>>>>>> this.deployedHosts = deployedHosts;
>>>>>>> }
>>>>>>>
>>>>>>> public void addToDeployedHosts(
>>>>>>> final Node host) {
>>>>>>> this.getDeployedHosts().add(host);
>>>>>>> this.getContainer().flush();
>>>>>>> }
>>>>>>>
>>>>>>> // }}
>>>>>>>
>>>>>>> // {{ addDeployedHost (action)
>>>>>>> @MemberOrder(name = "deployedHosts", sequence = "010")
>>>>>>> public void addDeployedHost(
>>>>>>> @XMSBulkParam @XMSActionField(locales = {
>>>>>>> @XMSLocale(locale =
>>>>>>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>>>>>>> this.wrap(this).addToDeployedHosts(host);
>>>>>>> }
>>>>>>>
>>>>>>> // }}
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> And we have a test that does:
>>>>>>> // when
>>>>>>> this.wrap(hypervisor).addDeployedHost(host);
>>>>>>>
>>>>>>> // then
>>>>>>> assertThat(hypervisor.getDeployedHosts(), contains((Node)
>>>>>>> host));
>>>>>>> assertThat(host.getHostContainer(), is((Node) hypervisor));
>>>>>>>
>>>>>>> The strange behavior is that this test works well, but when you see
>>>>>>> if
>>>>>>> is
>>>>>>> persisted on our DB (postgresql), isn't it, and I'm a bit lost
>>>>>>> because
>>>>>>> host.getHostContainer() is finding well the object.
>>>>>>>
>>>>>>> I don't know if it will be some ISIS configuration or DN, but it does
>>>>>>> the
>>>>>>> same in tests and in our app, and it appeared when we update to DN4.
>>>>>>>
>>>>>>> N:M relationships works well and it's important for us to solve it,
>>>>>>> so
>>>>>>> if
>>>>>>> you need any more information or some ideas to test it, I'll be
>>>>>>> available.
>>>>>>>
>>>>>>> Cheers and thanks very much.
>>>>>>>
>>>>>>> --
>>>>>>> Ignacio Cánovas Rejón
>>>>>>> Tel. 902 900 231
>>>>>>> Fax 96 353 19 09
>>>>>>> n.canovas@gesconsultor.com
>>>>>>> www.gesconsultor.com
>>>>>>>
>>>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>>>> contienen información reservada que no puede ser difundida. Si usted
>>>>>>> ha
>>>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de
>>>>>>> su
>>>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>>>> electrónica;
>>>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna
>>>>>>> persona.
>>>>>>>
>>>>>>> Su dirección de correo electrónico junto a sus datos personales
>>>>>>> constan
>>>>>>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es
>>>>>>> la de
>>>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>>>> disponemos
>>>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
>>>>>>> enviando un
>>>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>>>> siguiente
>>>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C,
>>>>>>> C.P.
>>>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>>>>> caso
>>>>>>> que los tuvieran eliminarlos.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> Este mensaje no contiene virus ni malware porque la protección de
>>>>>>> avast!
>>>>>>> Antivirus está activa.
>>>>>>> http://www.avast.com
>>>>>>>
>>>>>>>
>>>>>>> --
>>>> Ignacio Cánovas Rejón
>>>> Tel. 902 900 231
>>>> Fax 96 353 19 09
>>>> n.canovas@gesconsultor.com
>>>> www.gesconsultor.com
>>>>
>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>> contienen información reservada que no puede ser difundida. Si usted ha
>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>> electrónica;
>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>>>
>>>> Su dirección de correo electrónico junto a sus datos personales constan
>>>> en
>>>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>> disponemos
>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>> siguiente
>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>> caso
>>>> que los tuvieran eliminarlos.
>>>>
>>>>
>>>> ---
>>>> Este mensaje no contiene virus ni malware porque la protección de avast!
>>>> Antivirus está activa.
>>>> http://www.avast.com
>>>>
>>>>
>>>>
>>
>>
>
> --
> Ignacio Cánovas Rejón
> Tel. 902 900 231
> Fax 96 353 19 09
> n.canovas@gesconsultor.com
> www.gesconsultor.com
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
> que los tuvieran eliminarlos.
>
>
>
> ---
> Este mensaje no contiene virus ni malware porque la protección de avast!
> Antivirus está activa.
> http://www.avast.com
>
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Nacho Cánovas Rejón <n....@gesconsultor.com>.
I have more information Dan.
I get simpleapp from isis code and put the same relationship type and*it
worked well*.
Then I changed *this.wrap(host).setHostContainer(this);* to
*host.setHostContainer(this);* (without wrap) in our code and it worked
well too.
So, right now I assume it can be some library or configuration (I put
same properties to testConfiguration on simpleapp as our tests) that is
not the same (DN and ISIS libraries are the same but could be some
conflict and use different libraries versions).
Do you know where it can be the problem?
Thanks!
El 21/05/2015 a las 14:08, Nacho Cánovas Rejón escribió:
> Hi have same issue changing the code like you said
> (host.setHostContainer(this);) and with
> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
> , so next step is your sample app.
>
>
> El 21/05/2015 a las 13:00, Dan Haywood escribió:
>> Just looking at the DN documentation on this, where for 1:m managed
>> bidirectional relationship it says [1]
>>
>> "When forming the relation please make sure that you set the relation at
>> BOTH sides since DataNucleus would have no way of knowing which end is
>> correct if you only set one end."
>>
>> On the other hand, in our Isis documentation we have the advice [2]:
>>
>> "So long as the parent's children collection is a java.util.Set (rather
>> than a Collection or a List), the JDO Objectstore will automatically
>> maintain both sides of the relationship. All that is necessary is to set
>> the child to refer to the parent."
>>
>> I also say:
>>
>> "The upshot is that you should NEVER programmatically add the child
>> object
>> to the parent's collection if using JDO Objectstore."
>>
>> which is what your code does, actually.
>>
>> This was on the basis of this thread [3] with Oscar a year or two ago.
>>
>> ~~~
>> So, perhaps you could change your code from:
>>
>>
>> public void addToDeployedHosts(
>> final Node host) {
>>
>> * this.getDeployedHosts().add(host);* this.getContainer().flush();
>> }
>>
>> to:
>>
>>
>> public void addToDeployedHosts(
>> final Node host) {
>> * host.setHostContainer(this);*
>> this.getContainer().flush();
>> }
>>
>>
>> and see what happens?
>>
>>
>>
>> Thx
>> Dan
>>
>>
>>
>>
>> [1]
>> http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_collection.html#fk_bi
>>
>> [2]
>> https://isis.apache.org/components/objectstores/jdo/managed-1-to-m-relationships.html
>>
>> [3] http://markmail.org/message/agnwmzocvdfht32f
>>
>>
>> On 21 May 2015 at 11:49, Nacho Cánovas Rejón
>> <n....@gesconsultor.com>
>> wrote:
>>
>>> Hi Dan.
>>>
>>> Issue appears in booth places, so isn't UI a problem.
>>>
>>> I'll follow your thought and I'll let you now.
>>>
>>> Another step I can do is see if this happens in one ISIS sample.
>>>
>>> Thanks.
>>>
>>>
>>> El 21/05/2015 a las 12:44, Dan Haywood escribió:
>>>
>>>> One other thought...
>>>>
>>>> in Isis a while back we disabled persistenceByReachability in
>>>> persistor_datanucleus.properties:
>>>>
>>>> #
>>>> # Require explicit persistence (since entities are Comparable and
>>>> using
>>>> ObjectContracts#compareTo).
>>>> # see
>>>>
>>>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
>>>>
>>>> #
>>>>
>>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>>>
>>>>
>>>> As the comment says, this was mostly a workaround to the relatively
>>>> "dumb"
>>>> way that ObjectContracts#compareTo works.... this is documented on our
>>>> site
>>>> [1]
>>>>
>>>> I know that persistence by reachability relates to newly created
>>>> objects,
>>>> I
>>>> wonder if it also has a role to play in dirty objects. Almost
>>>> certainly
>>>> not, but (if you aren't using ObjectContracts) you could perhaps
>>>> reenable
>>>> this setting and see if there's any different behaviour?
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>> [1]
>>>>
>>>> http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk>
>>>> wrote:
>>>>
>>>> Hi Nacho,
>>>>> Is the issue arising in the running app, or in the test, or both?
>>>>>
>>>>> Also, if you reproduce in a vanilla simple app based on the Isis
>>>>> simpleapp
>>>>> archetype, does that fail too? (In other words, can we eliminate
>>>>> your
>>>>> custom UI from the equation?)
>>>>>
>>>>> Thx
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 21 May 2015 at 11:19, Nacho Cánovas Rejón
>>>>> <n.canovas@gesconsultor.com
>>>>> wrote:
>>>>>
>>>>> Hi.
>>>>>> Since we updated to DataNucleus 4 we have some issue about 1:N
>>>>>> relationships.
>>>>>>
>>>>>> In DB is not persisted when we add to the collection an element.
>>>>>>
>>>>>> I show you one code example of 1:N relationship that fails and to
>>>>>> explain
>>>>>> it better:
>>>>>>
>>>>>> public abstract class Node extends ActiveStructureElement {
>>>>>>
>>>>>> // {{ HostContainer (property)
>>>>>>
>>>>>> private Node hostContainer;
>>>>>>
>>>>>> @Column(allowsNull = "true")
>>>>>> public Node getHostContainer() {
>>>>>> return this.hostContainer;
>>>>>> }
>>>>>>
>>>>>> public void setHostContainer(
>>>>>> final Node node) {
>>>>>> this.hostContainer = node;
>>>>>> }
>>>>>>
>>>>>> // }}
>>>>>>
>>>>>> // {{ DeployedHosts (Collection)
>>>>>>
>>>>>> @Persistent(mappedBy = "hostContainer", dependentElement =
>>>>>> "false")
>>>>>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>>>>>
>>>>>> public SortedSet<Node> getDeployedHosts() {
>>>>>> return this.deployedHosts;
>>>>>> }
>>>>>>
>>>>>> public void setDeployedHosts(
>>>>>> final SortedSet<Node> deployedHosts) {
>>>>>> this.deployedHosts = deployedHosts;
>>>>>> }
>>>>>>
>>>>>> public void addToDeployedHosts(
>>>>>> final Node host) {
>>>>>> this.getDeployedHosts().add(host);
>>>>>> this.getContainer().flush();
>>>>>> }
>>>>>>
>>>>>> // }}
>>>>>>
>>>>>> // {{ addDeployedHost (action)
>>>>>> @MemberOrder(name = "deployedHosts", sequence = "010")
>>>>>> public void addDeployedHost(
>>>>>> @XMSBulkParam @XMSActionField(locales = {
>>>>>> @XMSLocale(locale =
>>>>>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>>>>>> this.wrap(this).addToDeployedHosts(host);
>>>>>> }
>>>>>>
>>>>>> // }}
>>>>>>
>>>>>> }
>>>>>>
>>>>>> And we have a test that does:
>>>>>> // when
>>>>>> this.wrap(hypervisor).addDeployedHost(host);
>>>>>>
>>>>>> // then
>>>>>> assertThat(hypervisor.getDeployedHosts(), contains((Node)
>>>>>> host));
>>>>>> assertThat(host.getHostContainer(), is((Node)
>>>>>> hypervisor));
>>>>>>
>>>>>> The strange behavior is that this test works well, but when you
>>>>>> see if
>>>>>> is
>>>>>> persisted on our DB (postgresql), isn't it, and I'm a bit lost
>>>>>> because
>>>>>> host.getHostContainer() is finding well the object.
>>>>>>
>>>>>> I don't know if it will be some ISIS configuration or DN, but it
>>>>>> does
>>>>>> the
>>>>>> same in tests and in our app, and it appeared when we update to DN4.
>>>>>>
>>>>>> N:M relationships works well and it's important for us to solve
>>>>>> it, so
>>>>>> if
>>>>>> you need any more information or some ideas to test it, I'll be
>>>>>> available.
>>>>>>
>>>>>> Cheers and thanks very much.
>>>>>>
>>>>>> --
>>>>>> Ignacio Cánovas Rejón
>>>>>> Tel. 902 900 231
>>>>>> Fax 96 353 19 09
>>>>>> n.canovas@gesconsultor.com
>>>>>> www.gesconsultor.com
>>>>>>
>>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>>> contienen información reservada que no puede ser difundida. Si
>>>>>> usted ha
>>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo
>>>>>> de su
>>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>>> electrónica;
>>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna
>>>>>> persona.
>>>>>>
>>>>>> Su dirección de correo electrónico junto a sus datos personales
>>>>>> constan
>>>>>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya
>>>>>> finalidad es
>>>>>> la de
>>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>>> disponemos
>>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
>>>>>> enviando un
>>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>>> siguiente
>>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C,
>>>>>> C.P.
>>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que
>>>>>> este
>>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos,
>>>>>> y en
>>>>>> caso
>>>>>> que los tuvieran eliminarlos.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Este mensaje no contiene virus ni malware porque la protección de
>>>>>> avast!
>>>>>> Antivirus está activa.
>>>>>> http://www.avast.com
>>>>>>
>>>>>>
>>> --
>>> Ignacio Cánovas Rejón
>>> Tel. 902 900 231
>>> Fax 96 353 19 09
>>> n.canovas@gesconsultor.com
>>> www.gesconsultor.com
>>>
>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>> contienen información reservada que no puede ser difundida. Si usted ha
>>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>>> sistema y avisar al remitente mediante reenvío a su dirección
>>> electrónica;
>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>>
>>> Su dirección de correo electrónico junto a sus datos personales
>>> constan en
>>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es
>>> la de
>>> mantener el contacto con Ud. Si quiere saber de qué información
>>> disponemos
>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
>>> enviando un
>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>> siguiente
>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y
>>> en caso
>>> que los tuvieran eliminarlos.
>>>
>>>
>>> ---
>>> Este mensaje no contiene virus ni malware porque la protección de
>>> avast!
>>> Antivirus está activa.
>>> http://www.avast.com
>>>
>>>
>
>
--
Ignacio Cánovas Rejón
Tel. 902 900 231
Fax 96 353 19 09
n.canovas@gesconsultor.com
www.gesconsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P. 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Nacho Cánovas Rejón <n....@gesconsultor.com>.
Hi have same issue changing the code like you said (host.setHostContainer(this);) and with isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false , so next step is your sample app.
El 21/05/2015 a las 13:00, Dan Haywood escribió:
> Just looking at the DN documentation on this, where for 1:m managed
> bidirectional relationship it says [1]
>
> "When forming the relation please make sure that you set the relation at
> BOTH sides since DataNucleus would have no way of knowing which end is
> correct if you only set one end."
>
> On the other hand, in our Isis documentation we have the advice [2]:
>
> "So long as the parent's children collection is a java.util.Set (rather
> than a Collection or a List), the JDO Objectstore will automatically
> maintain both sides of the relationship. All that is necessary is to set
> the child to refer to the parent."
>
> I also say:
>
> "The upshot is that you should NEVER programmatically add the child object
> to the parent's collection if using JDO Objectstore."
>
> which is what your code does, actually.
>
> This was on the basis of this thread [3] with Oscar a year or two ago.
>
> ~~~
> So, perhaps you could change your code from:
>
>
> public void addToDeployedHosts(
> final Node host) {
>
> * this.getDeployedHosts().add(host);* this.getContainer().flush();
> }
>
> to:
>
>
> public void addToDeployedHosts(
> final Node host) {
> * host.setHostContainer(this);*
> this.getContainer().flush();
> }
>
>
> and see what happens?
>
>
>
> Thx
> Dan
>
>
>
>
> [1]
> http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_collection.html#fk_bi
> [2]
> https://isis.apache.org/components/objectstores/jdo/managed-1-to-m-relationships.html
> [3] http://markmail.org/message/agnwmzocvdfht32f
>
>
> On 21 May 2015 at 11:49, Nacho Cánovas Rejón <n....@gesconsultor.com>
> wrote:
>
>> Hi Dan.
>>
>> Issue appears in booth places, so isn't UI a problem.
>>
>> I'll follow your thought and I'll let you now.
>>
>> Another step I can do is see if this happens in one ISIS sample.
>>
>> Thanks.
>>
>>
>> El 21/05/2015 a las 12:44, Dan Haywood escribió:
>>
>>> One other thought...
>>>
>>> in Isis a while back we disabled persistenceByReachability in
>>> persistor_datanucleus.properties:
>>>
>>> #
>>> # Require explicit persistence (since entities are Comparable and using
>>> ObjectContracts#compareTo).
>>> # see
>>>
>>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
>>> #
>>>
>>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>>
>>> As the comment says, this was mostly a workaround to the relatively "dumb"
>>> way that ObjectContracts#compareTo works.... this is documented on our
>>> site
>>> [1]
>>>
>>> I know that persistence by reachability relates to newly created objects,
>>> I
>>> wonder if it also has a role to play in dirty objects. Almost certainly
>>> not, but (if you aren't using ObjectContracts) you could perhaps reenable
>>> this setting and see if there's any different behaviour?
>>>
>>> Dan
>>>
>>>
>>>
>>> [1]
>>>
>>> http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
>>>
>>>
>>>
>>>
>>> On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk>
>>> wrote:
>>>
>>> Hi Nacho,
>>>> Is the issue arising in the running app, or in the test, or both?
>>>>
>>>> Also, if you reproduce in a vanilla simple app based on the Isis
>>>> simpleapp
>>>> archetype, does that fail too? (In other words, can we eliminate your
>>>> custom UI from the equation?)
>>>>
>>>> Thx
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>> On 21 May 2015 at 11:19, Nacho Cánovas Rejón <n.canovas@gesconsultor.com
>>>> wrote:
>>>>
>>>> Hi.
>>>>> Since we updated to DataNucleus 4 we have some issue about 1:N
>>>>> relationships.
>>>>>
>>>>> In DB is not persisted when we add to the collection an element.
>>>>>
>>>>> I show you one code example of 1:N relationship that fails and to
>>>>> explain
>>>>> it better:
>>>>>
>>>>> public abstract class Node extends ActiveStructureElement {
>>>>>
>>>>> // {{ HostContainer (property)
>>>>>
>>>>> private Node hostContainer;
>>>>>
>>>>> @Column(allowsNull = "true")
>>>>> public Node getHostContainer() {
>>>>> return this.hostContainer;
>>>>> }
>>>>>
>>>>> public void setHostContainer(
>>>>> final Node node) {
>>>>> this.hostContainer = node;
>>>>> }
>>>>>
>>>>> // }}
>>>>>
>>>>> // {{ DeployedHosts (Collection)
>>>>>
>>>>> @Persistent(mappedBy = "hostContainer", dependentElement = "false")
>>>>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>>>>
>>>>> public SortedSet<Node> getDeployedHosts() {
>>>>> return this.deployedHosts;
>>>>> }
>>>>>
>>>>> public void setDeployedHosts(
>>>>> final SortedSet<Node> deployedHosts) {
>>>>> this.deployedHosts = deployedHosts;
>>>>> }
>>>>>
>>>>> public void addToDeployedHosts(
>>>>> final Node host) {
>>>>> this.getDeployedHosts().add(host);
>>>>> this.getContainer().flush();
>>>>> }
>>>>>
>>>>> // }}
>>>>>
>>>>> // {{ addDeployedHost (action)
>>>>> @MemberOrder(name = "deployedHosts", sequence = "010")
>>>>> public void addDeployedHost(
>>>>> @XMSBulkParam @XMSActionField(locales = {
>>>>> @XMSLocale(locale =
>>>>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>>>>> this.wrap(this).addToDeployedHosts(host);
>>>>> }
>>>>>
>>>>> // }}
>>>>>
>>>>> }
>>>>>
>>>>> And we have a test that does:
>>>>> // when
>>>>> this.wrap(hypervisor).addDeployedHost(host);
>>>>>
>>>>> // then
>>>>> assertThat(hypervisor.getDeployedHosts(), contains((Node)
>>>>> host));
>>>>> assertThat(host.getHostContainer(), is((Node) hypervisor));
>>>>>
>>>>> The strange behavior is that this test works well, but when you see if
>>>>> is
>>>>> persisted on our DB (postgresql), isn't it, and I'm a bit lost because
>>>>> host.getHostContainer() is finding well the object.
>>>>>
>>>>> I don't know if it will be some ISIS configuration or DN, but it does
>>>>> the
>>>>> same in tests and in our app, and it appeared when we update to DN4.
>>>>>
>>>>> N:M relationships works well and it's important for us to solve it, so
>>>>> if
>>>>> you need any more information or some ideas to test it, I'll be
>>>>> available.
>>>>>
>>>>> Cheers and thanks very much.
>>>>>
>>>>> --
>>>>> Ignacio Cánovas Rejón
>>>>> Tel. 902 900 231
>>>>> Fax 96 353 19 09
>>>>> n.canovas@gesconsultor.com
>>>>> www.gesconsultor.com
>>>>>
>>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>>> contienen información reservada que no puede ser difundida. Si usted ha
>>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>>> electrónica;
>>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>>>>
>>>>> Su dirección de correo electrónico junto a sus datos personales constan
>>>>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es
>>>>> la de
>>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>>> disponemos
>>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>>> siguiente
>>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>>> caso
>>>>> que los tuvieran eliminarlos.
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> Este mensaje no contiene virus ni malware porque la protección de avast!
>>>>> Antivirus está activa.
>>>>> http://www.avast.com
>>>>>
>>>>>
>> --
>> Ignacio Cánovas Rejón
>> Tel. 902 900 231
>> Fax 96 353 19 09
>> n.canovas@gesconsultor.com
>> www.gesconsultor.com
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted ha
>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales constan en
>> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>> mantener el contacto con Ud. Si quiere saber de qué información disponemos
>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
>> que los tuvieran eliminarlos.
>>
>>
>> ---
>> Este mensaje no contiene virus ni malware porque la protección de avast!
>> Antivirus está activa.
>> http://www.avast.com
>>
>>
--
Ignacio Cánovas Rejón
Tel. 902 900 231
Fax 96 353 19 09
n.canovas@gesconsultor.com
www.gesconsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P. 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Just looking at the DN documentation on this, where for 1:m managed
bidirectional relationship it says [1]
"When forming the relation please make sure that you set the relation at
BOTH sides since DataNucleus would have no way of knowing which end is
correct if you only set one end."
On the other hand, in our Isis documentation we have the advice [2]:
"So long as the parent's children collection is a java.util.Set (rather
than a Collection or a List), the JDO Objectstore will automatically
maintain both sides of the relationship. All that is necessary is to set
the child to refer to the parent."
I also say:
"The upshot is that you should NEVER programmatically add the child object
to the parent's collection if using JDO Objectstore."
which is what your code does, actually.
This was on the basis of this thread [3] with Oscar a year or two ago.
~~~
So, perhaps you could change your code from:
public void addToDeployedHosts(
final Node host) {
* this.getDeployedHosts().add(host);* this.getContainer().flush();
}
to:
public void addToDeployedHosts(
final Node host) {
* host.setHostContainer(this);*
this.getContainer().flush();
}
and see what happens?
Thx
Dan
[1]
http://www.datanucleus.org/products/datanucleus/jdo/orm/one_to_many_collection.html#fk_bi
[2]
https://isis.apache.org/components/objectstores/jdo/managed-1-to-m-relationships.html
[3] http://markmail.org/message/agnwmzocvdfht32f
On 21 May 2015 at 11:49, Nacho Cánovas Rejón <n....@gesconsultor.com>
wrote:
> Hi Dan.
>
> Issue appears in booth places, so isn't UI a problem.
>
> I'll follow your thought and I'll let you now.
>
> Another step I can do is see if this happens in one ISIS sample.
>
> Thanks.
>
>
> El 21/05/2015 a las 12:44, Dan Haywood escribió:
>
>> One other thought...
>>
>> in Isis a while back we disabled persistenceByReachability in
>> persistor_datanucleus.properties:
>>
>> #
>> # Require explicit persistence (since entities are Comparable and using
>> ObjectContracts#compareTo).
>> # see
>>
>> http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
>> #
>>
>> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>>
>> As the comment says, this was mostly a workaround to the relatively "dumb"
>> way that ObjectContracts#compareTo works.... this is documented on our
>> site
>> [1]
>>
>> I know that persistence by reachability relates to newly created objects,
>> I
>> wonder if it also has a role to play in dirty objects. Almost certainly
>> not, but (if you aren't using ObjectContracts) you could perhaps reenable
>> this setting and see if there's any different behaviour?
>>
>> Dan
>>
>>
>>
>> [1]
>>
>> http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
>>
>>
>>
>>
>> On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk>
>> wrote:
>>
>> Hi Nacho,
>>>
>>> Is the issue arising in the running app, or in the test, or both?
>>>
>>> Also, if you reproduce in a vanilla simple app based on the Isis
>>> simpleapp
>>> archetype, does that fail too? (In other words, can we eliminate your
>>> custom UI from the equation?)
>>>
>>> Thx
>>> Dan
>>>
>>>
>>>
>>>
>>> On 21 May 2015 at 11:19, Nacho Cánovas Rejón <n.canovas@gesconsultor.com
>>> >
>>> wrote:
>>>
>>> Hi.
>>>>
>>>> Since we updated to DataNucleus 4 we have some issue about 1:N
>>>> relationships.
>>>>
>>>> In DB is not persisted when we add to the collection an element.
>>>>
>>>> I show you one code example of 1:N relationship that fails and to
>>>> explain
>>>> it better:
>>>>
>>>> public abstract class Node extends ActiveStructureElement {
>>>>
>>>> // {{ HostContainer (property)
>>>>
>>>> private Node hostContainer;
>>>>
>>>> @Column(allowsNull = "true")
>>>> public Node getHostContainer() {
>>>> return this.hostContainer;
>>>> }
>>>>
>>>> public void setHostContainer(
>>>> final Node node) {
>>>> this.hostContainer = node;
>>>> }
>>>>
>>>> // }}
>>>>
>>>> // {{ DeployedHosts (Collection)
>>>>
>>>> @Persistent(mappedBy = "hostContainer", dependentElement = "false")
>>>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>>>
>>>> public SortedSet<Node> getDeployedHosts() {
>>>> return this.deployedHosts;
>>>> }
>>>>
>>>> public void setDeployedHosts(
>>>> final SortedSet<Node> deployedHosts) {
>>>> this.deployedHosts = deployedHosts;
>>>> }
>>>>
>>>> public void addToDeployedHosts(
>>>> final Node host) {
>>>> this.getDeployedHosts().add(host);
>>>> this.getContainer().flush();
>>>> }
>>>>
>>>> // }}
>>>>
>>>> // {{ addDeployedHost (action)
>>>> @MemberOrder(name = "deployedHosts", sequence = "010")
>>>> public void addDeployedHost(
>>>> @XMSBulkParam @XMSActionField(locales = {
>>>> @XMSLocale(locale =
>>>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>>>> this.wrap(this).addToDeployedHosts(host);
>>>> }
>>>>
>>>> // }}
>>>>
>>>> }
>>>>
>>>> And we have a test that does:
>>>> // when
>>>> this.wrap(hypervisor).addDeployedHost(host);
>>>>
>>>> // then
>>>> assertThat(hypervisor.getDeployedHosts(), contains((Node)
>>>> host));
>>>> assertThat(host.getHostContainer(), is((Node) hypervisor));
>>>>
>>>> The strange behavior is that this test works well, but when you see if
>>>> is
>>>> persisted on our DB (postgresql), isn't it, and I'm a bit lost because
>>>> host.getHostContainer() is finding well the object.
>>>>
>>>> I don't know if it will be some ISIS configuration or DN, but it does
>>>> the
>>>> same in tests and in our app, and it appeared when we update to DN4.
>>>>
>>>> N:M relationships works well and it's important for us to solve it, so
>>>> if
>>>> you need any more information or some ideas to test it, I'll be
>>>> available.
>>>>
>>>> Cheers and thanks very much.
>>>>
>>>> --
>>>> Ignacio Cánovas Rejón
>>>> Tel. 902 900 231
>>>> Fax 96 353 19 09
>>>> n.canovas@gesconsultor.com
>>>> www.gesconsultor.com
>>>>
>>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>>> contienen información reservada que no puede ser difundida. Si usted ha
>>>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>>>> sistema y avisar al remitente mediante reenvío a su dirección
>>>> electrónica;
>>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>>>
>>>> Su dirección de correo electrónico junto a sus datos personales constan
>>>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es
>>>> la de
>>>> mantener el contacto con Ud. Si quiere saber de qué información
>>>> disponemos
>>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la
>>>> siguiente
>>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en
>>>> caso
>>>> que los tuvieran eliminarlos.
>>>>
>>>>
>>>>
>>>> ---
>>>> Este mensaje no contiene virus ni malware porque la protección de avast!
>>>> Antivirus está activa.
>>>> http://www.avast.com
>>>>
>>>>
>>>
>
> --
> Ignacio Cánovas Rejón
> Tel. 902 900 231
> Fax 96 353 19 09
> n.canovas@gesconsultor.com
> www.gesconsultor.com
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
> que los tuvieran eliminarlos.
>
>
> ---
> Este mensaje no contiene virus ni malware porque la protección de avast!
> Antivirus está activa.
> http://www.avast.com
>
>
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Nacho Cánovas Rejón <n....@gesconsultor.com>.
Hi Dan.
Issue appears in booth places, so isn't UI a problem.
I'll follow your thought and I'll let you now.
Another step I can do is see if this happens in one ISIS sample.
Thanks.
El 21/05/2015 a las 12:44, Dan Haywood escribió:
> One other thought...
>
> in Isis a while back we disabled persistenceByReachability in
> persistor_datanucleus.properties:
>
> #
> # Require explicit persistence (since entities are Comparable and using
> ObjectContracts#compareTo).
> # see
> http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
> #
> isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
>
> As the comment says, this was mostly a workaround to the relatively "dumb"
> way that ObjectContracts#compareTo works.... this is documented on our site
> [1]
>
> I know that persistence by reachability relates to newly created objects, I
> wonder if it also has a role to play in dirty objects. Almost certainly
> not, but (if you aren't using ObjectContracts) you could perhaps reenable
> this setting and see if there's any different behaviour?
>
> Dan
>
>
>
> [1]
> http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
>
>
>
>
> On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>> Hi Nacho,
>>
>> Is the issue arising in the running app, or in the test, or both?
>>
>> Also, if you reproduce in a vanilla simple app based on the Isis simpleapp
>> archetype, does that fail too? (In other words, can we eliminate your
>> custom UI from the equation?)
>>
>> Thx
>> Dan
>>
>>
>>
>>
>> On 21 May 2015 at 11:19, Nacho Cánovas Rejón <n....@gesconsultor.com>
>> wrote:
>>
>>> Hi.
>>>
>>> Since we updated to DataNucleus 4 we have some issue about 1:N
>>> relationships.
>>>
>>> In DB is not persisted when we add to the collection an element.
>>>
>>> I show you one code example of 1:N relationship that fails and to explain
>>> it better:
>>>
>>> public abstract class Node extends ActiveStructureElement {
>>>
>>> // {{ HostContainer (property)
>>>
>>> private Node hostContainer;
>>>
>>> @Column(allowsNull = "true")
>>> public Node getHostContainer() {
>>> return this.hostContainer;
>>> }
>>>
>>> public void setHostContainer(
>>> final Node node) {
>>> this.hostContainer = node;
>>> }
>>>
>>> // }}
>>>
>>> // {{ DeployedHosts (Collection)
>>>
>>> @Persistent(mappedBy = "hostContainer", dependentElement = "false")
>>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>>
>>> public SortedSet<Node> getDeployedHosts() {
>>> return this.deployedHosts;
>>> }
>>>
>>> public void setDeployedHosts(
>>> final SortedSet<Node> deployedHosts) {
>>> this.deployedHosts = deployedHosts;
>>> }
>>>
>>> public void addToDeployedHosts(
>>> final Node host) {
>>> this.getDeployedHosts().add(host);
>>> this.getContainer().flush();
>>> }
>>>
>>> // }}
>>>
>>> // {{ addDeployedHost (action)
>>> @MemberOrder(name = "deployedHosts", sequence = "010")
>>> public void addDeployedHost(
>>> @XMSBulkParam @XMSActionField(locales = { @XMSLocale(locale =
>>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>>> this.wrap(this).addToDeployedHosts(host);
>>> }
>>>
>>> // }}
>>>
>>> }
>>>
>>> And we have a test that does:
>>> // when
>>> this.wrap(hypervisor).addDeployedHost(host);
>>>
>>> // then
>>> assertThat(hypervisor.getDeployedHosts(), contains((Node) host));
>>> assertThat(host.getHostContainer(), is((Node) hypervisor));
>>>
>>> The strange behavior is that this test works well, but when you see if is
>>> persisted on our DB (postgresql), isn't it, and I'm a bit lost because
>>> host.getHostContainer() is finding well the object.
>>>
>>> I don't know if it will be some ISIS configuration or DN, but it does the
>>> same in tests and in our app, and it appeared when we update to DN4.
>>>
>>> N:M relationships works well and it's important for us to solve it, so if
>>> you need any more information or some ideas to test it, I'll be available.
>>>
>>> Cheers and thanks very much.
>>>
>>> --
>>> Ignacio Cánovas Rejón
>>> Tel. 902 900 231
>>> Fax 96 353 19 09
>>> n.canovas@gesconsultor.com
>>> www.gesconsultor.com
>>>
>>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>>> contienen información reservada que no puede ser difundida. Si usted ha
>>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>>> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
>>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>>
>>> Su dirección de correo electrónico junto a sus datos personales constan
>>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>>> mantener el contacto con Ud. Si quiere saber de qué información disponemos
>>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
>>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
>>> que los tuvieran eliminarlos.
>>>
>>>
>>>
>>> ---
>>> Este mensaje no contiene virus ni malware porque la protección de avast!
>>> Antivirus está activa.
>>> http://www.avast.com
>>>
>>
--
Ignacio Cánovas Rejón
Tel. 902 900 231
Fax 96 353 19 09
n.canovas@gesconsultor.com
www.gesconsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P. 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
One other thought...
in Isis a while back we disabled persistenceByReachability in
persistor_datanucleus.properties:
#
# Require explicit persistence (since entities are Comparable and using
ObjectContracts#compareTo).
# see
http://www.datanucleus.org/products/accessplatform_3_0/jdo/transaction_types.html
#
isis.persistor.datanucleus.impl.datanucleus.persistenceByReachabilityAtCommit=false
As the comment says, this was mostly a workaround to the relatively "dumb"
way that ObjectContracts#compareTo works.... this is documented on our site
[1]
I know that persistence by reachability relates to newly created objects, I
wonder if it also has a role to play in dirty objects. Almost certainly
not, but (if you aren't using ObjectContracts) you could perhaps reenable
this setting and see if there's any different behaviour?
Dan
[1]
http://isis.apache.org/components/objectstores/jdo/disabling-persistence-by-reachability.html
On 21 May 2015 at 11:38, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Hi Nacho,
>
> Is the issue arising in the running app, or in the test, or both?
>
> Also, if you reproduce in a vanilla simple app based on the Isis simpleapp
> archetype, does that fail too? (In other words, can we eliminate your
> custom UI from the equation?)
>
> Thx
> Dan
>
>
>
>
> On 21 May 2015 at 11:19, Nacho Cánovas Rejón <n....@gesconsultor.com>
> wrote:
>
>> Hi.
>>
>> Since we updated to DataNucleus 4 we have some issue about 1:N
>> relationships.
>>
>> In DB is not persisted when we add to the collection an element.
>>
>> I show you one code example of 1:N relationship that fails and to explain
>> it better:
>>
>> public abstract class Node extends ActiveStructureElement {
>>
>> // {{ HostContainer (property)
>>
>> private Node hostContainer;
>>
>> @Column(allowsNull = "true")
>> public Node getHostContainer() {
>> return this.hostContainer;
>> }
>>
>> public void setHostContainer(
>> final Node node) {
>> this.hostContainer = node;
>> }
>>
>> // }}
>>
>> // {{ DeployedHosts (Collection)
>>
>> @Persistent(mappedBy = "hostContainer", dependentElement = "false")
>> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>>
>> public SortedSet<Node> getDeployedHosts() {
>> return this.deployedHosts;
>> }
>>
>> public void setDeployedHosts(
>> final SortedSet<Node> deployedHosts) {
>> this.deployedHosts = deployedHosts;
>> }
>>
>> public void addToDeployedHosts(
>> final Node host) {
>> this.getDeployedHosts().add(host);
>> this.getContainer().flush();
>> }
>>
>> // }}
>>
>> // {{ addDeployedHost (action)
>> @MemberOrder(name = "deployedHosts", sequence = "010")
>> public void addDeployedHost(
>> @XMSBulkParam @XMSActionField(locales = { @XMSLocale(locale =
>> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
>> this.wrap(this).addToDeployedHosts(host);
>> }
>>
>> // }}
>>
>> }
>>
>> And we have a test that does:
>> // when
>> this.wrap(hypervisor).addDeployedHost(host);
>>
>> // then
>> assertThat(hypervisor.getDeployedHosts(), contains((Node) host));
>> assertThat(host.getHostContainer(), is((Node) hypervisor));
>>
>> The strange behavior is that this test works well, but when you see if is
>> persisted on our DB (postgresql), isn't it, and I'm a bit lost because
>> host.getHostContainer() is finding well the object.
>>
>> I don't know if it will be some ISIS configuration or DN, but it does the
>> same in tests and in our app, and it appeared when we update to DN4.
>>
>> N:M relationships works well and it's important for us to solve it, so if
>> you need any more information or some ideas to test it, I'll be available.
>>
>> Cheers and thanks very much.
>>
>> --
>> Ignacio Cánovas Rejón
>> Tel. 902 900 231
>> Fax 96 353 19 09
>> n.canovas@gesconsultor.com
>> www.gesconsultor.com
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted ha
>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales constan
>> en un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
>> mantener el contacto con Ud. Si quiere saber de qué información disponemos
>> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
>> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
>> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
>> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
>> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
>> que los tuvieran eliminarlos.
>>
>>
>>
>> ---
>> Este mensaje no contiene virus ni malware porque la protección de avast!
>> Antivirus está activa.
>> http://www.avast.com
>>
>
>
Re: 1:N Relationships aren't persisted on DB DN4
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Nacho,
Is the issue arising in the running app, or in the test, or both?
Also, if you reproduce in a vanilla simple app based on the Isis simpleapp
archetype, does that fail too? (In other words, can we eliminate your
custom UI from the equation?)
Thx
Dan
On 21 May 2015 at 11:19, Nacho Cánovas Rejón <n....@gesconsultor.com>
wrote:
> Hi.
>
> Since we updated to DataNucleus 4 we have some issue about 1:N
> relationships.
>
> In DB is not persisted when we add to the collection an element.
>
> I show you one code example of 1:N relationship that fails and to explain
> it better:
>
> public abstract class Node extends ActiveStructureElement {
>
> // {{ HostContainer (property)
>
> private Node hostContainer;
>
> @Column(allowsNull = "true")
> public Node getHostContainer() {
> return this.hostContainer;
> }
>
> public void setHostContainer(
> final Node node) {
> this.hostContainer = node;
> }
>
> // }}
>
> // {{ DeployedHosts (Collection)
>
> @Persistent(mappedBy = "hostContainer", dependentElement = "false")
> private SortedSet<Node> deployedHosts = new TreeSet<Node>();
>
> public SortedSet<Node> getDeployedHosts() {
> return this.deployedHosts;
> }
>
> public void setDeployedHosts(
> final SortedSet<Node> deployedHosts) {
> this.deployedHosts = deployedHosts;
> }
>
> public void addToDeployedHosts(
> final Node host) {
> this.getDeployedHosts().add(host);
> this.getContainer().flush();
> }
>
> // }}
>
> // {{ addDeployedHost (action)
> @MemberOrder(name = "deployedHosts", sequence = "010")
> public void addDeployedHost(
> @XMSBulkParam @XMSActionField(locales = { @XMSLocale(locale =
> "es", caption = "Host") }) @Named("Host") final LogicalNode host) {
> this.wrap(this).addToDeployedHosts(host);
> }
>
> // }}
>
> }
>
> And we have a test that does:
> // when
> this.wrap(hypervisor).addDeployedHost(host);
>
> // then
> assertThat(hypervisor.getDeployedHosts(), contains((Node) host));
> assertThat(host.getHostContainer(), is((Node) hypervisor));
>
> The strange behavior is that this test works well, but when you see if is
> persisted on our DB (postgresql), isn't it, and I'm a bit lost because
> host.getHostContainer() is finding well the object.
>
> I don't know if it will be some ISIS configuration or DN, but it does the
> same in tests and in our app, and it appeared when we update to DN4.
>
> N:M relationships works well and it's important for us to solve it, so if
> you need any more information or some ideas to test it, I'll be available.
>
> Cheers and thanks very much.
>
> --
> Ignacio Cánovas Rejón
> Tel. 902 900 231
> Fax 96 353 19 09
> n.canovas@gesconsultor.com
> www.gesconsultor.com
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de GESDATOS SOFTWARE S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: GESDATOS SOFTWARE S.L. Av. Cortes Valencianas 50-1º-C, C.P.
> 46015 de Valencia. Asimismo, es su responsabilidad comprobar que este
> mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso
> que los tuvieran eliminarlos.
>
>
>
> ---
> Este mensaje no contiene virus ni malware porque la protección de avast!
> Antivirus está activa.
> http://www.avast.com
>