Hi Daniel, Daniel Shriver wrote:
Hello,
I am a bit confused about where OJB stands in terms of "auto mapping"
java classes. I am asking because I need to change the serialization
mechanism for a project with a large evolving codebase.
OK.
As such writing /Mhh. Xdoclet is a very elegant mechanism and imposes only minimal intrusion into the source code. I would at least think about it...
changing mapping files everytime the codebase changes is unacceptable;
likewise marking up the code with meta-data (which another tool like xdoclet
could use to generate a map) is also unacceptable.
Can OJB automaticallyAs of now: NO! There is no automated forward engineering java code (or classes) to XML repository and DDL.
generate mapping files reliably from Java classes?
My codebase is such thatIf want to use a standardized mechanism your code must stick to some conventions. Otherwise you need AI :-)
it would confuse many heuristics (Castor, for instance, assumes you either
have a pseudo-bean (private vars, public well named getters and setters for all vars) or pure public access var... in point of fact my codebase does not
entirely adhere to either of these methods (most classes are "partial beans"
where getters/setters might be poorly named...)).
You can allow to Reflection to access everything. We are doinf this in the PersistentFieldDefaultImpl.If I am going to have to "roll my own" map generator (a standalone application) that scans classes it is told to scan, and generates a mapping file (for OJB or whatever) what is the recommended approach? I was thinking of going through the SecurityManager... so I could hopefully grant myself direct access to any kind of variable (and hopefully also be able to list the variables and their attributes (for instance if they are transient)). I don't think I could do that with Reflection (I'd have the same restrictions that arbitrary code would have to member access).
regarding the best approach:
1. you can use source code processing a la Xdoclet.
2. you could use a source code to UML engineering (NSUML is your friend)
and then use axgen.sf.net to generate OJB repository.
(This is an approach that Jason is currently working on)
3. You can operate on compiled classes via JavaBeans or Reflection access.
IMO these are all viable solutions.
But you always face some tough questions to answer:
1. which attributes must be persisted (all, only those not marked transient, only non private attributes, only properties) ?!
2. which of these attributes is the primary key attribute?!
3. how to handle collection attributes?
java collections are not typed. that is you don't know the element type of a collection! How will you tell OJB which element-class a given collection-descriptor will have?!
4. how to identify foreign key elements if there are multiple associations between classes?!
Say class A holds two collections of B elements. B will then have two foreignkey attributes. one for the first collection, one for the second.
How can you know which FK to use for which collection?!
etc. etc.
Without answering these questions you are lost. IMO the only viable solution is to have clear code-conventions that allow automated detection of the mentioned stuff.
cheers,
Thomas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
