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. In an XML attribute we have to take care encoding the
value.
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.
With regard to the UI I was thinking that we add a free text "Comment"
or "Description" column to the attribute and relationship tables. We
could get fancy attach double click event handler to the field to
display a dialog which provides more room for text editing.
The Entity tab would have a simple "Description" JTextField as the
last item in the "Configuration"
I think this would be the easiest solution to implement, and would be
really hitting the sweat spot in terms of user needs.
regards Malcolm Edgar
On 2/1/07, Tore Halset <halse..vv.ntnu.no> wrote:
> Hello.
>
> An extra file like that will probably make refactoring and keeping
> things in sync more complicated. My app have millions of cayenne
> objects laying around (will be better with 3.0), each with a HashMap,
> so those Strings with documentation will take minimal - if not zero -
> space and cpu. This will of course depend on the nature of your project.
>
> Good luck Malcolm, this will be a great cayenne feature!
>
> - Tore.
>
> On Jan 31, 2007, at 15:06, Andrus Adamchik wrote:
>
> > I also had performance concerns. So maybe store all that bulky
> > optional metadata (be it just comments or some arbitrary key value
> > pairs) in a separate properties file sitting next to the project
> > descriptor (cayenne.properties?). Each property name will be
> > prefixed with a location of the property-owning node in the project
> > tree. E.g.:
> >
> > map:mymap1.dbentity:myentity1.abc.comment = ABC...
> > map:mymap2.objentity:myentity2.abc.comment = XYZ...
> >
> > ... or something. Properties can be loaded lazily on first access
> > and CayenneModeler would take care of building the proper keys.
>
>
This archive was generated by hypermail 2.0.0 : Wed Jan 31 2007 - 16:32:37 EST