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
This archive was generated by hypermail 2.0.0 : Thu Feb 01 2007 - 05:29:22 EST