Everything and nothing in particular about Modeling, Architecture, Software engineering,...

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 Class3c1.2 => c3.1 , ie a second instance of Class1 refering to the first instance of Class3c2 => 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:

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.