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 <malcolm.edga..mail.com> 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 <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:58:07 EST