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 <[EMAIL PROTECTED]> 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.
