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 >> > >
