Mike Kienenberger wrote:
> On 2/2/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
>> I think this was more of a lack of personal motivation among current
>> committers. I can speak for myself - I think this feature is cool,
>> but I never needed it badly enough.
>
> I also haven't needed this featu
On 2/2/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
I think this was more of a lack of personal motivation among current
committers. I can speak for myself - I think this feature is cool,
but I never needed it badly enough.
I also haven't needed this feature until the last couple of months.
I suppose I am actuall reitterating what you said earlier. Please
assign CAY-659 to me.
regards Malcolm Edgar
On 2/2/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
As I mentioned I don't see a problem with comments being done as a
separate feature (CAY-659). I posted a list of similarities bet
As I mentioned I don't see a problem with comments being done as a
separate feature (CAY-659). I posted a list of similarities between
comments and properties in my previous message, but there are
differences as well.
Anyways, I am +1 on Malcolm's proposal as long as MapLoader can be
conf
I think the requirements for user properties (CAY-400) and
comments/description (CAY-659) are different.
While CAY-400 could be used to support comments, and other things like
meta-data, I think getting the comments/description done as a modeler
enhancement is better done separately. Editing a s
On 01/02/2007, at 9:28 PM, Andrus Adamchik wrote:
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 stil
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 c
On Jan 31, 2007, at 11:57 PM, Mike Kienenberger wrote:
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.
BTW, this is somewhat sim
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
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
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
Andrus Adamchik wrote:
> I guess the term "comment" is too narrow and misleading here. I was
> thinking more of a CAY-400 approach:
>
> https://issues.apache.org/cayenne/browse/CAY-400
>
> I.e. a list of key/value pairs rather than a single comment.
While technically comments could be represente
Andrus Adamchik wrote:
> Hi Dirk,
>
> 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 b
Read the entire post.
Of course I did :).
The discussion is about how to avoid
loading/parsing of all that stuff in runtime.
I just thought that skipping XML nodes is not a performance overhead,
but transforming those nodes into objects would be.
At least with the few fast XML parsers I used
Read the entire post. The discussion is about how to avoid loading/
parsing of all that stuff in runtime.
Andrus
On Jan 31, 2007, at 4:15 PM, Ahmed Mohombe wrote:
I also had performance concerns.
Why should performance be a problem in this case?
Comments are not required at runtime, just a
I also had performance concerns.
Why should performance be a problem in this case?
Comments are not required at runtime, just at "design/develop" time.
Ahmed.
Hi Dirk,
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
I guess the term "comment" is too narrow and misleading here.
Maybe, but what I'm missing from Cayenne(+modeler) are really "comments"
in the simple form, not annotations or other fancy things: just comments.
Depending on the working procedure, to be able to propagate them(or override).
E.g.:
> Hi All,
Hi,
> We use Cayenne day in day out for a lot of our work, and the Cayenne
> Modeler has a pretty central place in maintaining the database design,
> and hence the application design.
Documentation for the database model has been an issue that I was
interested in since the EOF days.
>
I guess the term "comment" is too narrow and misleading here. I was
thinking more of a CAY-400 approach:
https://issues.apache.org/cayenne/browse/CAY-400
I.e. a list of key/value pairs rather than a single comment.
Andrus
On Jan 31, 2007, at 3:17 PM, Ahmed Mohombe wrote:
I can better comme
I can better comment on specifics if we decide on a visual solution
first. Since comments can be added to almost any mapping element
-[Obj|Db] [Entity|Attribute|Relationship] Query (?), my first thought is
to add an info button (same as the one used on relationships panels) to
the rest of the m
Excellent! I am glad to see you stepping in to do that. We promised
this feature so many times that I blush every time somebody asks for
it again :-)
As for the Modeler architecture, it is a bit eclectic, as we tried a
number of approaches over time, not always fully cleaning up the
depre
22 matches
Mail list logo
