Monday, October 13, 2008

FemtORM of opera (part2)

We described shortly the structure of FemtORM in the previous post. We now have to face to different scenari, which may show the limits of the approach.

We may start with the following instances :
c1.1 => c3.1 , ie a first instance of Class1 refering to the first instance of Class3
c1.2 => c3.1 , ie a second instance of Class1 refering to the first instance of Class3
c2 => c3.2 , ie a first instance of Class2 refering to the second instance of Class3

Example1 :
This is the simplest case we can face to. We have a table for each class we have defined in our domain model, eg one table for Class1, one for Class2, and one for Class3.
Each instance of these class has an ID which enables to make references from table records to other table records.
The store methods in MysqlProxy are roughly the ones:
protected void storeClass3(IDBAccess aClass3) {
if(aClass3.getID()<0)>INSERT INTO Class3(integer1,integer2) VALUES (");
strBuf.append(aClass3.getInteger1());
strBuf.append(aClass3.getInteger2());
strBuf.append(")");
}

protected void storeClass1(IDBAccess aClass2) {
if(aClass2.getID()<0)>
strBuf.append("INSERT INTO Class2(float,string) VALUES (");
strBuf.append(aClass2.getFloat());
strBuf.append(aClass2.getString());
strBuf.append(")");

}

protected void storeClass2(IDBAccess aClass1) {
if(aClass1.getID()<0)>
strBuf.append("INSERT INTO Class1(integer,string) VALUES (");
strBuf.append(aClass1.getInteger());
strBuf.append(aClass1.String());
strBuf.append(")");

}
Thanks to the marking algorithm, the c3.1 instance is stored only once. We can also add another guard by testing is the ID number has already been set or not. The ID number is actually assigned to the instances once stored in the database.

Example2:
In order to improve the database querying, we may want to merge the Class1 and Class3 , and also Class2 and Class3.
We then obtain the following tables :
Class1 (id integer string integer1 integer1 class3_id)
Class2 (id float string integer1 integer2 class3_id)
Make notice that by doing this we consider of course that we face to a kind of relation named aggregation instead of association in the sense of inter-classes object relations.

The store methods look like the following from now :
protected void storeClass3(IDBAccess aClass3) {
//nothing to do

}

protected void storeClass1(IDBAccess aClass2) {
if(aClass2.getID()<0)>
strBuf.append("INSERT INTO Class2(float,string,integer1,integer2) VALUES (");
strBuf.append(aClass2.getFloat());
strBuf.append(aClass2.getString());
strBuf.append(aClass2.getClass3().getInteger1());
strBuf.append(aClass2.
getClass3().getInteger2());
strBuf.append(")");
}

protected void storeClass2(IDBAccess aClass1) {
strBuf.append("INSERT INTO Class1(integer,string,integer1,integer2) VALUES (");
strBuf.append(aClass2.getInteger());
strBuf.append(aClass2.getString());
strBuf.append(aClass2.getClass3().getInteger1());
strBuf.append(aClass2.
getClass3().getInteger2());
strBuf.append(")");
}



We will speak about updating and retrieving data in future posts.

No comments: