Sorry, i'm abusing abbreviations. By dds I meant deployment descriptors.
If you're putting together something that can read sql CREATE TABLE
statements and create ejb with XDoclet tags, I think that's great! Means
that if I make a gui tool for e-r (entity-relation) modelling, I could
concentrate on SQL generation, and I wouldn't be surprised if that exists
already. I'm pretty sure it does. Still, I think I'll have to write my own
because of relations. Please read on.
I have the impression that most of the XDoclet people are also JBoss
people, but I am (at least for the time being) working mostly with WLS 6.1.
My recent experience with CMR (Container Managed Relations) and EJBGen are
great,, but falls short of the opportunity to extend the code generation
functionality since EJBGen is closed source. If/when XDoclet/JBoss gets CMR
and EJB-QL support, I'll consider switching. -And now to my point:
With CMR, a Customer EJB could have a CMR method like java.util.Collection
getAccounts() managed by the container. The Account EJB could have a
Customer getCustomer() method. Further, it is possible to make relations
unidirectional (in the example, the Account.getCustomer() might not be
defined). If I make a gui tool that spits out SQL, and your tool generates
XDoclet EJBs, I think your tool could be able to figure out the CMR stuff
by looking at the SQL and the foreign keys. It wouldn't be able to know
whether or not to make the relations unidirectional or bidirectional, since
SQL doesn't say anything about that. It could still be possible if we agree
on some special comments in the SQL that your tool understands, which is
the reason I think I'll have to write my own tool. An other issue would be
many-to-many relationships. I haven't thought much about it, but your tool
should be able to figure that out too. Are you targeting any particular
database, or are you trying to make it general enough to use with MySQL,
Oracle, Informix etc...?
I'd be glad to hear comments on this.
(I'll be away from the civilization for two weeks from today)
|--------+------------------------>
| | Dmitri |
| | Colebatch |
| | <[EMAIL PROTECTED]|
| | et.au> |
| | |
| | 17.08.2001 |
| | 03:03 |
| | |
|--------+------------------------>
>-----------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc: [EMAIL PROTECTED]
|
| Subject: Re: [Xdoclet-devel] request: sql generation
|
>-----------------------------------------------------------------------------------------------------------------------|
sql generator based on what? at first reading your email I thought you
meant an ORMapper, but then when you say you want to generate dds
(ddl?) I'm assuming the table doesn't exist.
I'm currently putting together something that will read a table and output
the appropriate ejb source with xdoclet comments... is this what you're
after? this could also include mass data queries, done via jdbc rather
than ejbFinder, and should be a lot cheaper... not sure if this is
relevant though.
cheers
dim
On Fri, 17 Aug 2001 [EMAIL PROTECTED] wrote:
> i'd like to see a sql generator!
>
> i'm thinking about writing a swing program for entity-relationship
> modelling that could output java source files with xdoclet tags for cmp,
> cmr and sql. then xdoclet could generate ejbs with dds and database table
> creation sql. even tags to insert test data into the tables would be
> feasible. this would make it soo quick to develop ejb solutions!
>
> i realise that the xdoclet team probably has scheduled tasks with higher
> priority, but i just wanted to share my ideas. if anybody likes the idea,
> please contact me, and i'll join in as a contributor.
>
> bye bye
>
> B | aslak helles�y, senior consultant
> E | +47 982 19 432, [EMAIL PROTECTED]
> K | bekk consulting as, pb. 134 sentrum, 0102 oslo, norway
> K | www.bekk.no
>
>
> _______________________________________________
> Xdoclet-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/xdoclet-devel
