[OJB-developers] mapping flexibility

[<syl...@be...>]

Hi Thomas

I'm using Ojb to read data from a existing database I didn't design. 
There is a repeating case where I can't find a possibility with Ojb current mapping possibilities
to map my classes with my Object.

I have, up to now, used a specific RowReader, but this has a lot of disadvantage. 
I have to write the same code all over again and I can not use standard feature out of the box, 
proxy, cascade delete,...
So I would like to have your opinion on the best way to implement the feature I need in OJB.

Basicaly, the foreign key of the "foreign table" contains information that doesn't come 
from the fields of the primary table.

This happens mainly in 2 cases
A)the foreign table is used to store different type of information.
One example could be when a inheritance hierachy is represented by storing all the base 
class in the same table with one column used for the type of the record.
Such contruct exist a lot in existing database when the designer decided to store a 
lot of simple entity mainly used in lookups in the same table, currency code, language, ....
In such a case, the type column is part of the primary key of the foreign table but the 
value for the type is not stored in the fields of the primary table, it is basically a 
constant.
B)The foreign table store information in different language: french, english, dutch. Once again 
the language 
column is part of the pk of the foreign table but its value is not a field of the 
primary table, but a runtime value.

Right now in ReferenceDescriptor or CollectionDescriptor you can only give a list of 
id of the fields used to build the foreign key.

I see different possibilities here.
A) We allow fake fields, they would be member of the class, but they would not map to a 
column in a database table, so they would not be read or saved. Their value could
be set at object creation. fk_descriptor_ids could list those fake fields.
B) We change the fk_descriptor_ids to allow to put not only field ids, but also
member variable name, or member method, or directly some values, or any method or ...
How far should we go.
C) Use somethink like what is describe in mapping all classes on the same table.
for the foreign table. The probem is that I don't control the value used for the type-columns, 
most
of the time it's a number or something like EN, FR, DU. 
The problem is that the type column is also part of the key and indexes for the foreign column 
and 
I think that Ojb will not use that column to retreive only interresting row but will read all 
rows with equality
on other fk fields and instantiate different object type. The indexes might not be used, too many 
rows will be read
and too many objects will be created.

I don't really like solution A.
Solution B will have impact on the repository format,metadata classes and code to fetch 
references 
and collection needed to be changed. 

Solution C could be usefull for more flexible way to map class hierachy, but I'm not sure on how 
much code
will be involved. It probably will have impact on the extent definition mechanism.

What do you think about this. Do you think it can be added to the todo list for version 1.0?
What's your preffered solution, do you have another, better one?

I also think that it should be possible to have field id attribute to be anything, not just a 
number, 
like class id are. 
The documentation is not very clear with it, but fields id are really column number
so that if there are 5 fields, valid id value are 1 2 3 4 5 (in any order). OJB dosn't really
check this when reading the repository, but if you don't respect this and use 1 3 4 5 6 or 1 2 3 
4 4
and reference those fields in a fk_descriptor_ids (e.g. 1 5 ),the wrong field will be used to 
build 
the indentity for the foreign object. (respectively 1 and 6 and 1 and one of the 4).

BTW I don't really understand why people want to "kill" the repository file. 
It's only there if you want to use it. You can directly contruct the mapping
with classes of the ojb.metadata package if you want to.


I think that a xml repository file is very important for OJB because 

-It is an easy entry point for people that discover OJB. The jars file 
and a few text file is all that is needed to download and setup for people 
that just want to have a look. 
-In a text file you can also easely embbed comment that can help
occasionnal user.
-In bug reporting, it can be much easier to describe a small test case and 
E-mail it if it's a xml file.
-Finally if the repository need to change, some smart guy can write an xsl file 
that will do the convertion.

A visual tool is also great, and I might even try to contribute one in the future,
but I think that it can be a nice idea to have it manipulate the repository.xml
file. I think that using something like Jdom, you can even preserve formatting 
and comments without too much work if you are carrefull. 

If you want to use the tool directly on the java classes, we will have to change the way they 
work. I think that you need the java classes that represent the object before you start
the mapping, the metadata classes check the existence of classes and member variables. 
I think it could be nice to generate the DDL needed to created the tables, we will need extra 
information
like the size of column but it could also be nice to have the tool to generate java classes for an
existing database.

This is not a big contraint either because if you are not using the repository, 
some class within OJB can be responsible to unmarshall the mapping to xml, 
you can then edit it, marshall it back to java, everything is almost there, 
then you can unmarshall it to your prefered format.


Have a good day

Bertrand