Hei!

I've filed a bug report:
https://sourceforge.net/tracker/index.php?func=detail&aid=614312&group_id=36
044&atid=415990

Thanks for the thorough description of the problem. I'll have to think about
this for a while before I solve it. -Unless someone else solves it before
me.

Aslak

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Kristoffer Moe
> Sent: 23. september 2002 14:18
> To: [EMAIL PROTECTED]
> Subject: [Middlegen-user] Relationship name clash with single many2many
> combined with single one2many
>
>
> Seems like middlegen handles cases where two tables have more than one FK
> relationship in the same direction by adding the FK field to the
> relationship names, whereas a single relationship bewteen two tables
> results in a relationship name put together by the two table
> names and some
> stuff in between. However, if I have, between my two tables, one one-to-
> many and one many-to-many, middlegen doesn't bother doing the name
> mangling, thereby creating two relationships with the same name.
> This makes
> xdoclet very angry. Example:
>
> 1) A -< B >- C
> 2) A >- C
>
> Relationship names becomes:
> 1) A-cmp20-C-cmp20
> 2) A-cmp20-C-cmp20
>
> One workaround seems to be adding a dummy one-to-many relationship with a
> ditto FK in the child table of the one-to-many, which makes middlegen
> produce relationship names which are more unique for the one-to-manys, as
> they are mangled with the foreign key name at the end, thus:
>
> 1) A -< B >- C
> 2) A >- C
> 3) A >- C  (by dummy FK)
>
> Relationship names:
> 1) A-cmp20-C-cmp20 (still unmangled many2many)
> 2) A-cmp20-C-cmp20-csforeignkeytoa (mangled one2many)
> 3) A-cmp20-C-cmp20-csdummyforeignkeytoa (mangled one2many)
>
> Since relationship names in 1) and 2) above now are different, xdoclet is
> happy go lucky. However, this adds garbage to the database schema. In
> addition, the getter naming scheme is somewhat altered, as 'get'
> <foo> 'By'
> <bar> is used instead of 'get'<foo>.
>
> Gnerally, the getter (and setter) naming scheme does not take the actual
> roles into account when creating names. (yes, my database is modeled as an
> ORM model). So if I have two or more relationships between two tables, it
> is semantically confusing if they have the same name when it comes to EJB
> getter/setter methods. This fact is taken care of, however, by the
> getFooByBar naming scheme above, but if my FK is named e.g. aId (which I
> beleive is a common practice) my getter ends up as getBByAid. Ok. Bad
> example. From the real world:
> Solution::getActorByApproveActorId(). Ideally
> this should have been Solution::getApprovingActor() or something. In
> essence; it would be nice if it were be possible to specify actual method
> names, e.g. in the *-prefs.properties file.
>
> Any comments?
>
>
> Regards,
>
>
> Kristoffer Moe
> Senior Consultant
> Elan It ReSource
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> middlegen-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/middlegen-user



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
middlegen-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/middlegen-user

Reply via email to