Got it now ... but it is still not seeing eye to eye ... comments below ..
Dain Sundstrom wrote:
> Dave,
>
> We still don't see eye-to-eye, and I think I made the problem worse with my
> example.
>
> I think the most common type of relationship will be something like 'a cd
> has an artist' or 'a cd has a publisher.' In this cases, the foreign key
> for the artist or publisher would be just another column in the cd table.
> So we would have something like:
>
> String idbn pk
> String title
> ...
> Oid cd_artist fk
> Oid cd_publisher fk
>
> The oid is a place holder for what ever the pk for cd and artist (don't let
> it confuse you). I will argue that this is the most common relationship
> type and is auto created by the system.
>
Sure, Oid could be artist number, name
> Now your mapping is very different from what we have above. Your mapping
> mapps a foreign key to one of the pk columns (multi-key). This is a very
> difficult mapping because of the way the cmp engine is architected. The CMP
> engine is field oriented as apposed to column oriented. A field can map to
> multiple columns (a feature that existed in jaws).
>
> Follow so far?
Not a good database practice to have one field name map to multiple
database columns, but you have to support it. I would suggest though
most IDE's would map 1 column in the database to 1 field in the entity
and that case should be the rule, not the exception.
>
> Now each entity is composed of a collection of cmp field field objects and a
> collection of foreign key fields (or relation table key fields). I'm only
> going to address foreign key fields here. When the system starts it
> initializes the cmp fields for every entity. After that is complete it
> initializes the relationships. For each cmr field in an entity, it locates
> the related entity and creates a set of foreign-keys that are a copy of the
> related entitie's pk field(s).
>
> Still with me?
>
I'm with you but I think this is the rub. Why are we creating a copy of
the related keys? Since you alredy have to create the actual
implementation of the data for the entity bean, you must have code to
map set<field> and get<field> calls into a set/retrive data out of
the entity. Why not map the reference in the foreign key object to the
entiy field and then just get it when you need it? Do they both not have
to be in sync at all times anyway?
> The problem you mapping presents is you want to use a field for both an
> entity cmp and a relation foreign key field. In the current code these
> fields are different object. The caching code is also field oriented, so
> you would end up with two distinct caches of the code. Which could be a big
> problem.
>
See above.
> Ok let's take a step back and examine the mapping from the spec perspecitve.
> Using a pk field as a relationship foreign key presents a problem because
> the spec requres that a pk never change after ejbCreate but also requires
> that a relationship can not be set until ejbPostCreate. This leads to the
> question, how exactly are you going to set the relationship?
>
> Any way, I don't think any of the above text is that important. Although I
> think what you ask will make your code not spec compliant, I also think this
> type of mapping is important. I will look into adding support for this type
> of mapping, but it won't happen soon. I am focusing on the features
> required for spec compliance. Then I am going to add performance
> enhancements. And finally additional features.
>
Yup, thats a problem. Looks like we would have to use 10.8.3 to get
around it. I would not have a problem sticking in an primary key oid to
get around it but it is just extra table space. I would agree though
that unless it is easy to implement this would be a low priority.
> Ok that was a lot of babble. I need to stop writting emails before I get my
> first cup of coffee.
>
Oh, you just must be so excited when you get my e-mails you just have to
type! Not bad babbling without caffeine !
> -dain
dave
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
