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_num int
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
through my head ....
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
