On 21 May 2015 at 18:28, Nacho Cánovas Rejón <[email protected]>
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 <[email protected]
>>> >
>>> 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 <[email protected]>
>>>>> 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 <
>>>>>> [email protected]
>>>>>> 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
>>>>>>> [email protected]
>>>>>>> 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
>>>> [email protected]
>>>> 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
> [email protected]
> 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
>
