Unidirectional relations not compatible with external classes?

[Stephane Le Dorze]

URGENT, look below!

(From one guy of my Team - need to make him register)

---------- Forwarded message ----------
From: Régis Jean-Gilles <regis.je...@mimesis-republic.com>
Date: Tue, Feb 2, 2010 at 5:42 PM
Subject: Unidirectional relations not compatible with external classes?
To: fenix-f...@googlegroups.com
Cc: Damian Arregui <damian....@mimesis-republic.com>, Stéphane Le Dorze <stephane...@mimesis-republic.com>


Hello.

Hi have stumbled upon what looks like a small (but blocking) quirk in the Fenix code generator.

A bit of context first: we are currently trying to modularize our code, which involves being able to have separate projects with separate sets of DML.

Specifically, in project A we have a DML defining a class named "ChangeLog", which at this point is not attached to any Root type:

//==============================================
package com.A;

class ChangeLog  { 
}
//==============================================

The Fenix code generator handles this DML just fine

Then, we have project B which depends on project A, with another set of DMLs.
In the DMLs of project B, we define our Root type, and a relation that attaches the ChangeLog to the root.
Because ChangeLog was definied in another project, we define ChnageLog as an external entity:


//==============================================
package com.A;

external class ChangeLog;

relation RootToChangeLog {
  .B.Root playsRole  {
    multiplicity 1..1;
  }
 
  ChangeLog playsRole changeLog {
    multiplicity 0..1;
  } 
}
//==============================================

This setup should allow us to keep ChangeLog in project A while still being able to access it from the Root type in project B.

The problem is that we get the following compile error:

...\Root_Base.java:[21,80] cannot find symbol : variable role$$RootToChangeLog$$empty

And indeed, here is what was generated for the Root type:

...
public static dml.runtime.RoleOneFenix<com.B.Root,com.A.ChangeLog> role$$changeLog = new dml.runtime.RoleOneFenix<com.B.Root,com.A.ChangeLog>("changeLog") {
        public VBox<com.A.ChangeLog> getBox(com.B.Root o1) {
            return ((Root_Base)o1).changeLog;
        }
        public dml.runtime.Role<com.A.ChangeLog,com.B.Root> getInverseRole() {
            return com.A.ChangeLog.role$$RootToChangeLog$$empty;
        }       
    };
...

If I understand correctly, what happens is this:
when generating the Root type in project B, the generator sees that "RootToChangeLog" is unidirectional, and thus returns "com.A.ChangeLog.role$$RootToChangeLog$$empty"
for the inverse role. The generator seems to expect that this "empty" role was generated along with the ChangeLog class.
However when generating the ChangeLog class in project A, the generation was not aware of the RootToChangeLog relation, so naturally no "empty" role was ever generated.

Any idea as to how we might work around this, and when a potential fix might be released?

Thank you very much.
Regards.

NOTE: we are using version r45200.

Régis JEAN-GILLES.

[Joao Cachopo]

Régis Jean-Gilles <regis.je...@mimesis-republic.com> writes:

> Any idea as to how we might work around this, and when a potential fix
> might be released?

The fix was released on the 26th of January (on revision 45811).

That was quick, right? ;)

Best regards,
--
João Cachopo

[Stephane Le Dorze]

Lightning fast indeed ;)

2010/2/2 Joao Cachopo <joao.c...@ist.utl.pt>

--
You received this message because you are subscribed to the Google Groups "Fénix Framework" group.
To post to this group, send email to fenix-f...@googlegroups.com.
To unsubscribe from this group, send email to fenix-framewo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fenix-framework?hl=en.

[Damián Arregui]

Hi all,

We are experiencing a problem with the latest (this morning's)
version. When we compile our DMLs we get the following stack trace:

[java] Exception in thread "main" java.lang.NullPointerException
[java] at dml.CodeGenerator.print(CodeGenerator.java:1044)
[java] at dml.CodeGenerator.printWords(CodeGenerator.java:1035)
[java] at dml.CodeGenerator.printMethod(CodeGenerator.java:1000)
[java] at dml.CodeGenerator.printFinalMethod(CodeGenerator.java:1016)
[java] at dml.CodeGenerator.generateGetter(CodeGenerator.java:611)
[java] at dml.CodeGenerator.generateSlotGetter(CodeGenerator.java:606)
[java] at
dml.CodeGenerator.generateSlotAccessors(CodeGenerator.java:597)
[java] at
pt.ist.fenixframework.pstm.dml.FenixCodeGenerator.generateSlotAccessors(FenixCodeGenerator.java:351)
[java] at
dml.CodeGenerator.generateSlotsAccessors(CodeGenerator.java:592)
[java] at
dml.CodeGenerator.generateBaseClassBody(CodeGenerator.java:224)
[java] at
pt.ist.fenixframework.pstm.dml.FenixCodeGenerator.generateBaseClassBody(FenixCodeGenerator.java:77)
[java] at dml.CodeGenerator.generateBaseClass(CodeGenerator.java:199)
[java] at dml.CodeGenerator$1.doIt(CodeGenerator.java:122)
[java] at dml.CodeGenerator.writeToFile(CodeGenerator.java:96)
[java] at dml.CodeGenerator.generateOneClass(CodeGenerator.java:118)
[java] at dml.CodeGenerator.generateClasses(CodeGenerator.java:111)
[java] at dml.CodeGenerator.generateCode(CodeGenerator.java:83)

The problems appears for a TxNumber slot, which appears to have a null
slot type name, i.e. slot.getTypeName() == null.

Any ideas?

Thanks in advance,

Damián

2010/2/2 Stephane Le Dorze <stephane...@gmail.com>:

[Joao Cachopo]

Damián Arregui <damian....@mimesis-republic.com> writes:

> The problems appears for a TxNumber slot, which appears to have a null
> slot type name, i.e. slot.getTypeName() == null.

It seems that this problem was introduced with the recent change to the
two-step compilation process.

I've committed a fix to the HEAD that should solve it, even though I
would have to look deeper into this.