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 <[email protected]> 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 <[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 >>> >>> > > -- > 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 > >
