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