Currently, I've hacked up the 1.2 Modeler to support my own client needs. I added a Description field to DbEntity and DbAttribute for comments. I also ended up needing a few other fields attached to ObjEntity, ObjRelationship, DbEntity, and DbRelationship, so my personal preference would be a solution that handled user properties. I also need access to these fields during template generation.
To me, the best UI solution would be to do as Malcolm suggests, but make it handle an arbitrary number of user properties. As for the overhead, maybe we can configure each user property as something that should or should not be loaded. Perhaps specify which load situations are appropriate: MODELER_ONLY, MODELER_PLUS_CGEN, or ALWAYS. I also think the user properties should be part of the DataMap and not stored in a separate file. I honestly don't see the time to parse the datamap as being significant -- what use case parses the datamap frequently enough that the parsing time matters in terms of overall performance time? I'm willing to contribute to making this happen -- I've mostly been holding off until the Eclipse/Maven/Ant/Java 1.5 build environment for 3.0 settled down enough that I could do Cayenne work without having to learn Maven. On 1/31/07, Malcolm Edgar <[EMAIL PROTECTED]> 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. 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. > >
