Re: [JBoss-dev] EJB 2.0 CMP
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 setfield and getfield 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
Re: [JBoss-dev] EJB 2.0 CMP
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 setfield and getfield 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
Re: [JBoss-dev] EJB 2.0 CMP
Dain Sundstrom wrote:
Dave,
After reviewing these comments I think we are making this way more
complicated than it has to be. As far as I am concerned we should only
need the relationship stuff in jbosscmp-jdbc.xml for relationships that
use a relation table (ex. self relation employee/manager, just to
control the name and fields ) or for primary keys that are composite.
Relax. The only reason you need the jbosscmp-jdbc.xml file is that you are
tiring to exactly specify the foreign key field. If you just let the system
define the foreign key field for you, you would not have any problems. I
have a test case that closely matches what you have coded except my case
uses a general oid for the line item and the order fk is auto generated.
Ahh... lights on.
Is this how the majority of end users are going to use this? It would
seem within a larger shop the people doing the data modeling are not the
people building the J2EE apps. I would think that the data modeling or
db's would say here are the tables build your objects. I know it's not
*object oriented* but we should code for the masses.
Time Passes
So let me understand the order case above. Would the database schemas
look like this?
create table order (
objectid int default nextval('some sequence') primary key,
other fields ...
);
create table order_detail (
objectid int default nextval('some sequence') primary key,
order_oid int references order,
line_numint
other fields ...
);
Still having a hard time why you have to auto generate fk fields for
this case. It would seem this is what a dba would give you ... and if
the order/order_detail objects had all of the fields above nothing to
generate?
I think that your code is handling all of the difficult cases and is
ramming the easy ones into it. We really should have a waterfall type
style where we assume that it is the simple case and then have the
program add what's missing or have the user define it.
We should avoid creating tables if all possible. I would see only 3
cases where you need a third table
Many to Many
1 to Many (unidirectional. I can not come up with an example but it
would be valid)
Self referencing entry
A relation table is only required for a many-to-many relationship. A
unidirectional many-to-one relationship can always use foreign keys. The
trick is that the database mapping of the relationship does not have to
match the object level navigability. A self-referencing entity can also use
a foreign key to itself.
Time passes ...
I'm am really trying hard to not have to use this jboss-jdbc.xml ... For
composite foreign keys would could also the jdbc method
getImportedKeys() to figure out composite keys. This would mean the jdbc
driver would have to support the DatabaseMetaData method and the dba
would have to use the references in their table definition. We could
always fall back to the xml file if it did not exsist. So with a good
jdbc driver we really would only have to create an xml entry if we had a
specfic relation table we had already predefined.
This is a good idea but, would only work if there were only a single
relationship between the two entities. The problem is that it is very
common for entities to have multiple relationships. For example, order has
a shipping address and a billing address.
So what. There are two foriegn keys on a table. Could be hundreds ..
still do not see the problem. Let me check out getImportedKeys , I'll
get back to you ..
Maybe I'm foaming at the mouth, but I feel this is a HUGE feature for
people writing business apps and it should be as simple as possible. I
really think this could be simpler for the developers and users.
I agree. It think the configuration is very complicated. I was thinking of
writing a took that could generate the jbosscmp-jdbc.xml file based on the
system defaults. Then the user could modify the default configuration. This
utility could also read in the current config and fill in the unspecified
options. Something like this or a gui could make configuration very easy.
Have I missed something? Do you have a counter point or suggestion?
As a side note, I am happy to see someone challenging my design decisions.
I have been known to be full of it (and my self). Please keep the criticism
up, and don't worry about ticking me off (it takes a lot).
Thanks a lot,
-dain
I think a database schema of your case would help my understanding. I still believe
there is overkill for the simple cases
which will be the majority of cases. This is something that many
business aps will use and I in my day have written tons of this
collection handling shit and it would be nice to get it right once and
for all.
Writting is not my strong point , so I'm not trying to be cruft just
trying to make JBOSS better. Tear in my eye ... beatles songs running
Re: [JBoss-dev] EJB 2.0 CMP
Sorry if this is posted twice!
Dain Sundstrom wrote:
Dave,
After reviewing these comments I think we are making this way more
complicated than it has to be. As far as I am concerned we should only
need the relationship stuff in jbosscmp-jdbc.xml for relationships that
use a relation table (ex. self relation employee/manager, just to
control the name and fields ) or for primary keys that are composite.
Relax. The only reason you need the jbosscmp-jdbc.xml file is that
you are
tiring to exactly specify the foreign key field. If you just let the
system
define the foreign key field for you, you would not have any problems. I
have a test case that closely matches what you have coded except my case
uses a general oid for the line item and the order fk is auto generated.
Ahh... lights on.
Is this how the majority of end users are going to use this? It would
seem within a larger shop the people doing the data modeling are not the
people building the J2EE apps. I would think that the data modeling or
db's would say here are the tables build your objects. I know it's not
*object oriented* but we should code for the masses.
Time Passes
So let me understand the order case above. Would the database schemas
look like this?
create table order (
objectid int default nextval('some sequence') primary key,
other fields ...
);
create table order_detail (
objectid int default nextval('some sequence') primary key,
order_oid int references order,
line_numint
other fields ...
);
Still having a hard time why you have to auto generate fk fields for
this case. It would seem this is what a dba would give you ... and if
the order/order_detail objects had all of the fields above nothing to
generate?
I think that your code is handling all of the difficult cases and is
ramming the easy ones into it. We really should have a waterfall type
style where we assume that it is the simple case and then have the
program add what's missing or have the user define it.
We should avoid creating tables if all possible. I would see only 3
cases where you need a third table
Many to Many
1 to Many (unidirectional. I can not come up with an example but it
would be valid)
Self referencing entry
A relation table is only required for a many-to-many relationship. A
unidirectional many-to-one relationship can always use foreign keys. The
trick is that the database mapping of the relationship does not have to
match the object level navigability. A self-referencing entity can
also use
a foreign key to itself.
Time passes ...
I'm am really trying hard to not have to use this jboss-jdbc.xml ... For
composite foreign keys would could also the jdbc method
getImportedKeys() to figure out composite keys. This would mean the jdbc
driver would have to support the DatabaseMetaData method and the dba
would have to use the references in their table definition. We could
always fall back to the xml file if it did not exsist. So with a good
jdbc driver we really would only have to create an xml entry if we had a
specfic relation table we had already predefined.
This is a good idea but, would only work if there were only a single
relationship between the two entities. The problem is that it is very
common for entities to have multiple relationships. For example,
order has
a shipping address and a billing address.
So what. There are two foriegn keys on a table. Could be hundreds ..
still do not see the problem. Let me check out getImportedKeys , I'll
get back to you ..
Maybe I'm foaming at the mouth, but I feel this is a HUGE feature for
people writing business apps and it should be as simple as possible. I
really think this could be simpler for the developers and users.
I agree. It think the configuration is very complicated. I was
thinking of
writing a took that could generate the jbosscmp-jdbc.xml file based
on the
system defaults. Then the user could modify the default
configuration. This
utility could also read in the current config and fill in the unspecified
options. Something like this or a gui could make configuration very
easy.
Have I missed something? Do you have a counter point or suggestion?
As a side note, I am happy to see someone challenging my design
decisions.
I have been known to be full of it (and my self). Please keep the
criticism
up, and don't worry about ticking me off (it takes a lot).
Thanks a lot,
-dain
I think a database schema of your case would help my understanding. I
still believe there is overkill for the simple cases
which will be the majority of cases. This is something that many
business aps will use and I in my day have written tons of this
collection handling shit and it would be nice to get it right once and
for all.
Writting is not my strong point , so I'm not trying to be cruft just
RE: [JBoss-dev] EJB 2.0 CMP
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. 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? 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? 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. 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. Ok that was a lot of babble. I need to stop writting emails before I get my first cup of coffee. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] EJB 2.0 CMP
|I still believe there is overkill for the simple cases | |which will be the majority of cases. This is something that many hmmm I am a cretin when it comes to db stuff but anything that makes the lives of *most* people better as opposed to the lives of everyone blah is a good thing. Never design for everyone, that is what kills design, design for the majority. | beatles songs running |through my head Trumpets raising in the background, heroic music helping men marching to the front, crazed up frenchman playing the fiddle in the back...yes... deja-vu all over again... is there a glitch in the matrix? There was a black rabbit a second ago and then a second one *just* like it! regards marcf | | | | | | | | | | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJB 2.0 CMP
Dave, Ok, I see the misunderstanding now. I thought you were talking about the jbosscmp-jdbc.xml file and you were talking about the ejb-jar.xml file. You are correct in that a single relation can only have one cmr field on each side of the relationship. From my perspective these are object layer cmr fields and not relational level foreign keys. To specify how a relationship maps, you need to add a relationships section to the jbosscmp-jdbc.xml file. relationships ejb-relation ejb-relation-nameOrder-OrderDetail/ejb-relation-name foreign-key-mapping ejb-relationship-role ejb-relationship-role-nameOrder-has-OrderDetail/ejb-relationship-role-nam e foreign-key-fields/ /ejb-relationship-role ejb-relationship-role ejb-relationship-role-nameOrderDetail- belongsTo-Order/ejb-relationship-role-name foreign-key-fields foreign-key-field field-nameorder_oid/field-name column-nameorder_oid/column-name /foreign-key-field /foreign-key-fields /ejb-relationship-role /foreign-key-mapping /ejb-relation /relationships I'm not sure that this will work. The code may try to create a table with 2 order_oid columns because you trying to reuse a column mapped to a cmp field to store a relation foreign key. You may need to create the table by hand. I need to check this, because I think it will be a common mapping. I'd also like to take a moment to explain why the foreign key field is generated the way it is. I can't just a cmp field has the same name as the pk related ejb becasue of the case of a self related entity such as an employee/manager relationship in the employee object. I always have to prepend the ejb name of the related ejb to the fk, because it is common to have all beans to have a generic pk name such as oid (I do this). I hope this helps you, -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJB 2.0 CMP
I am playing with the current sources and testing a 1 to many relationship. I have the following two tables order with pk: int objectid ok and orderdetail pk: int order_oid,int line_num Does order detail have a compund key using both order_oid and line_num? The link.. order_oid=objectid Ok, foriegn-key style mapping. There is a 1 to many relationship between Order and orderdetail. When you go to access the collection it tries to look up the orderdetail lines with order_oid_objectid. Yep, that is the auto generated foreign key name. In org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationshipRoleMetaData.java it always appends the the other side of the relationships field to the query fieldname. The goal is to generate a unique field name. This does not seem right, if there is another field name that is the forgien key then I should specify it otherwise it should default to the selected field. What do you mean by selected field? I guess you would run into problems if the key was a composite and you had to match the two up. Flips through the spec Nope the spec only alllows for 1 field to be the forgein key What spec? If the parent table has a compound key or a single key field that maps to multiple columns (dependent value class), you will need multiple foreign key fields. As aside I can see the next problem coming. Really this collection should be loaded ordered by line_num but there is no way to specify this in the EJB 2.0 spec. (order is not defined) Maybe something for jbosscmp-jdbc.xml? Ordering is another issue. I will be working this later. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
