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
