On Jan 31, 2007, at 11:31 PM, Malcolm Edgar wrote:
My thinking on design would be to keep it a simple (80/20 rule solution), in which I think a simple comment attribute to the mapping XML elements.
We can treat comments and properties as two separate features .... or not? They share these characteristics though - (a) the data is arbitrary and not linked to any Cayenne functions (except for reverse- engineering DB comments); (b) they may optionally be excluded from runtime; (c) users want both of them :-)
In an XML attribute we have to take care encoding the value.
Just sticking it in a CDATA section should take care of it.
With a simple optional attribute, I would think it would be a pretty safe bet that there would not be any performance impact on the initial startup time. I think we are also talking about a trivial amount of memory.
We are talking about BLOBS of text. Consider people using this for javadocs, with each attribute having a 100 char comment field. For the model of 50 entities with 20 attributes each, we have (50 + 50*20) * 100 = 102K. Not crucial, but still keeping this stuff around in runtime seems wrong. Those things add up over time, resulting in framework becoming heavier with every new release.
I wouldn't mind storing the data in the main XML file, as the parser can skip it in runtime. So how about a simple solution - a single parameter passed to Configuration on load that includes or excludes optional metadata - no lazy loading hassle, still gives lots of flexibility (cgen will include it, runtime will exclude it by default).
Andrus
