Comments below...
> 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.
I can think of several cases where this would be good.
For starters, with existing db structures they may a single logical field
broken into several columns. For example, it is common to see phone number
split into area code and the rest.
Another reason to map a single logical field into several columns it to
implement corporate standards. At a medical company I worked at all dates
were entered as two columns. The first was the date in local time and the
second was the time zone. This is important for times like time of birth,
where a person is born at 12:01 AM CDT and if you adjust the time to another
time zone the person is born on another day.
The final reason I'll give is less obvious. Lets say you create a field
that you want mapped to a single column, but you also want functions to deal
with that column's data. In this case you would wrap your, let's say,
String with an object to opperate on that data. The problem with this is a
engine is forced to serialize the object and you end up with a binary column
in the database. I fiend ran into this when he wanted to store a formula
into a db column and have a function to calculate the formula.
> >
> > 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?
This is the problem, but not for the reasons you give. The field I am
"copying" is from the other ejb object, and it is not really copying (more
like wrapping read the code if you really want to know). We need have a
seperate place to store the entity relation data. The problem is you want to
use this foeign key field to store the data for a cmp field, which is a
member of the primary key (BTW it wouldn't work even if it weren't a memeber
of the pk).
> > 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.
Doh, this was my first suggestion. I most likely didn't explain it very
well. As a side note, the unknown pk stuff isn't implemented yet.
> > 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 !
Thanks. Sometimes I go back and read thoes early morning emails, and think,
"I have know idea that I was saying here."
-dain
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
