Role inversion in RelationChangesLog entries

0 views
Skip to first unread message

Damián

unread,
Jun 30, 2009, 11:28:04 AM6/30/09
to Fénix Framework
I have observed that when logging changes to 1-to-N relations, the
roles are inverted. A use case follows.

DML:

relation DummyObjectRootHasDummyObjects {
DummyObjectRoot playsRole root;
DummyObject playsRole instance {
multiplicity *;
}
}

Log entry:

RelationChangelog("DummyObjectRootHasDummyObjects",
net.blackmamba.persistence.DummyObject@136d9d8,
net.blackmamba.persistence.DummyObjectRoot@5a3923, false)

From my understanding, here the first object should indeed be logged
in the second role and vice-versa. Is it the case?


Damián

Joao Cachopo

unread,
Jul 2, 2009, 9:38:30 AM7/2/09
to fenix-f...@googlegroups.com
Damián <damian....@gmail.com> writes:

To better understand why this is happening, note that there are actually
two generated relations: one in the class DummyObject and another one in
the class DummyObjectRoot.

One of the relations is the inverse of the other, and calling one of
them dispatches to the other. One is an instance of a DirectRelation
and the other is an instance of an InverseRelation.

The logging is performed by the DirectRelation and what happens is that
the DirectRelation is on the class playing the second role.

That is, given a relation such as:

relation R {
A playsRole a;
B playsRole b;
}

there is a static slot A.R, of type Relation<A,B>, and another one B.R,
of type Relation<B,A> (note that the parametric types are exchanged).

What happens is that it is the B.R that is the DirectRelation and that
performs the logging.


I agree that it would probably more user-friendly to have the
DirectRelation in the other class, but currently it is not easy to
change that because there is already a significant portion of code that
depends on the current place of the DirectRelation (code that adds
listeners to a relation).

So, until we find time to change that code, I'm afraid that I will have
to leave it like this.

Still, provided that the RelationChangesLog contains the fully-qualified
name of which Relation object it is being used, it doesn't matter which
order the elements appear in the log if the order is consistent with the
that particular relation.

That is, in this particular case, with my last commit, your logs will
have the DummyObject instances first, but the fully-qualified name of
the relation will be
"net.blackmamba.persistence.DummyObject.DummyObjectRootHasDummyObjects",
which corresponds to a static slot which holds a relation that receives
first a DummyObject and then a DummyObjectRoot.

Do you agree that it is ok like this (even if not the most intuitive)?

Best regards,
--
João Cachopo

Damián

unread,
Jul 3, 2009, 9:16:13 AM7/3/09
to Fénix Framework
I have just a minor problem with the proposed approach. I can't use
the fully qualified name to retrieve the relation from the domain
model:

FenixFramework.getDomainModel.findRelation(relationChangelog.relation)
returns null.

It appears that relations are not stored in the model with their
fully qualified name.


Damián



On 2 juil, 15:38, Joao Cachopo <joao.cach...@ist.utl.pt> wrote:

Joao Cachopo

unread,
Jul 3, 2009, 4:44:52 PM7/3/09
to fenix-f...@googlegroups.com
Damián <damian....@gmail.com> writes:

> I have just a minor problem with the proposed approach. I can't use
> the fully qualified name to retrieve the relation from the domain
> model:
>
> FenixFramework.getDomainModel.findRelation(relationChangelog.relation)
> returns null.
>
> It appears that relations are not stored in the model with their
> fully qualified name.

Unlike in Java, in DML, relations are first-class citizens.

So, the name of a relation is the name that you put in front of the
"relation" keyword.

When they are transformed into Java code, however, a single relation in
the DML corresponds to two different relations in the Java code. One in
each of the participating classes in the DML relation.

So, there is no fully-qualified name of a relation in DML.

I use a fully-qualified name (after your email requesting it) in the
RelationsChangeLog entries to distinguish between the two Java
relations, as I explained in one of my previous emails.

If you want to get to the DML relation from that, then you need to use
only what's after the last dot ('.') in the fully-qualified name, which
is not very elegant, I agree. Probably a RelationsChangeLog entry
should have two slots: one for the class containing the relation, and
another for the name of the slot containing the relation (that matches
the relation name).

Any comments?

--
João Cachopo

Damián

unread,
Jul 6, 2009, 5:05:49 AM7/6/09
to Fénix Framework
On 3 juil, 22:44, Joao Cachopo <joao.cach...@ist.utl.pt> wrote:
> If you want to get to the DML relation from that, then you need to use
> only what's after the last dot ('.') in the fully-qualified name, which
> is not very elegant, I agree.  Probably a RelationsChangeLog entry
> should have two slots: one for the class containing the relation, and
> another for the name of the slot containing the relation (that matches
> the relation name).
>
> Any comments?

The idea is to get enough information in the RelationChangesLog
entries to be able to replay them properly. Right now I'm retrieving
the relation using the suffix of the fully qualified name, and
inverting the first and second roles since, as you pointed out, the
inverse relation is indeed being logged. This is good enough. Please
note that I still have a use for the fully qualified name, since it
allows me to selectively process relations on a per-package basis.

Damián
Reply all
Reply to author
Forward
0 new messages