First get in touch with Comega

Test.cw

using System;

public class Test {

class Address {
struct {
string text;
};
}

static void Main() {
Address a = <Address><text>test</text></Address>;
Console.WriteLine("Comega says hello!");
Console.WriteLine(a.text);
Console.ReadLine();
}
}

The above code results:

Comega says hello!
test

@Inherited won't work with Interface (JDK 1.5)

In my early code of SQLWarp, I created the annotation ConnectionInfo to be annotated on an interface, and I need it for an interface, not a class.

@Retention(RUNTIME)
@Inherited
public @interface ConnectionInfo {
public String driver();
public String url();
public String userID() default "";
public String password() default "";
}

The JDK doc says that @Inherited won't work with an Interface, so this is my work around to get annotation from the class that implements the interface which is annotated by @ConnectionInfo.

ConnectionInfo c = (ConnectionInfo)obj
.getClass()
.getInterfaces()[0]
.getAnnotation(ConnectionInfo.class);

Annotion-Based SQL Maps: Part II (JDK 1.5)

I show you the code sample from iBatis SQL Maps 2.0 last post.
I continue realizing the idea:

public interface MyDAO {

@Sql(expr="
SELECT
ADR_ID as id,
ADR_DESCRIPTION as description,
ADR_STREET as street,
ADR_CITY as city,
ADR_PROVINCE as province,
ADR_POSTAL_CODE as postalCode
FROM ADDRESS
WHERE ADR_ID = ?value
")
public Address getAddress(int value);

}

Q: We need code genraotor to create a class from the SQL expression.
A: MiddleGen could help.
Q: Implement the above method using a proxy class, a runtime class-wrapper.
A: CGLIB or Javassist.
Q: Need parsing parameters in the SQL expression, and bind to method's parameters.
A: I think this can be done using in-house parser, or hacked from iBatis SQL Maps.

My Draft Notes on Class Versioning, O/R Mapping and Separation of Concerns

Review Rashid's works:

class Person<2.0> {
private String firstName;
private String surName;
}

class Person<1.0> {
private String firstName;
private String lastName;
}

Next step?
Separate, then later weave.
this means
+ We seperate when design --> yield easier design
+ We weave when use --> it must be complex enough to serve all business logics
+ Modification to EJB3 should be great (it's same to OODBMS, dont care RDBMS layer)

Why?
+ It's not possible to change all RBMS invesment to OODB
+ It seems that implementing virtual databases over the tranditional RDBMs is better
+ A virtual database (in my case OR/mapping - Hibernate, Ejb3) can be fully applied with AOSD
+ class versioning schema manager (Rashid 2002-2004)
+ annotation
+ concern
+ data alignment concern

This is an idea for separating Object and Relation concerns:

// teacher data concern
@Entity("Teacher", "1.0")
class Teacher {
private int teacherID;
private String firstName;
private String lastName;
}

@Entity("Student", "1.0")
class Student {
private studentID;
private firstName;
private lastName;
}

// separate advisor concern
@Entity("Teacher", "2.0")
class Advisor {
private List adviseeLists;
}

// separate advisor concern
@Entity("Student", "2.0")
class Advisee {
private Advisor advisor;
}

Teacher t = entityManager.load(Teacher.class,
new Integer(1));
Advisor a = versioningManager.morph(t,
Advisor.class);

---

This is a new idea for field substitution
How the developer access this code?
possible answer: IoC?

@Version(2.0)
class Student {
@Substitute(version="1.0", name="lastName")
private surName;
}

class StudentDAO {

public Student findById(int id) {
// codes go here ...
}

@Conform("th.ac.sut.ent.Student", "2.0")
public static void main(String args[]) {

Student s = new StudentDAO().findById(10);
// not found, throw exception
System.out.println(s.getLastName());
// should be ok
System.out.println(s.getSurName());
}
}