Home » Eclipse Projects » Dali » Couple of problems with generated ddl
| Couple of problems with generated ddl [message #433970] |
Wed, 24 May 2006 14:11  |
 Kevin Sutter
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
Hi,
Now that I have the Kodo tutorial examples properly loading into Eclipse
(thanks to the workaround for bug 143301), I attempted to generate the ddl
for these examples. I ran into the following problems and am wondering
whether these are known conditions or not.
o The SPECIES field didn't get generated. My code looks like this. The
Persistence Properties panel looks good, so the Discriminator column is
being recognized. But, the ddl didn't create the SPECIES field.
//@Entity(name="Animal") // Bug 143301
@Entity
@Table(name="JPA_TUT_ANIMAL")
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name="SPECIES", length=100)
public abstract class Animal
:
o The GENDER and EXPIRED fields were generated as BIT fields, instead of
CHAR fields as required by Derby. I have my Derby database attached to
this Project, but somehow the DDL generator didn't know which database it
was processing against and created invalid field types. From the Rabbit
class, here's the annotated source:
@Basic @Column(name="GENDER")
private boolean isFemale = false;
@Basic @Column(name="EXPIRED")
private boolean isDead = false;
o The EATER_ID field was not generated at all. This is also part of the
Rabbit class. It's part of the @ManyToOne relationship. I can't remember
if that is fully supported yet or not...
@ManyToOne @JoinColumn(name="EATER_ID")
private Snake eater;
o I also told the DDL generator to generate fully-qualified names
(checkbox on the ddl generator wizard), but I got syntax that dropped the
schema name. Derby didn't like this (not sure if other databases are more
lenient).
CREATE TABLE .JPA_TUT_ANIMAL ( ...
CREATE TABLE .RABBIT_CHILDREN ( ...
ALTER TABLE .JPA_TUT_ANIMAL ADD CONSTRAINT JPA_TUT_ANIMAL_pk PRIMARY
KEY
(ID);
Thanks,
Kevin
|
|
| |
| Re: Couple of problems with generated ddl [message #433976 is a reply to message #433975] |
Fri, 26 May 2006 13:33  |
Kevin Sutter
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
Shaun Smith wrote:
> Hi Kevin,
> Have you tried using Kodo's mapppingtool to generate the DDL? I've
> used TopLink Essentials DDL generation and it works great. The reason I'm
> asking is that the availability of DDL generation from the JPA runtimes
> begs the question of why is it being built again in Dali? Perhaps a
> better solution is to provide support for running the DDL tools of the
> runtimes?
Shaun,
Yes, I have used the mappingtool from Kodo to generate the database
tables. It does work quite nicely. I have not tried the Toplink
offering. Does their DDL generation come with the Glassfish project, or
is this part of the purchased Toplink product?
I like having a tooling environment that is not dependent on any
particular runtime environment. I suppose that's why I am interested in
getting the Dali tooling provide this function. And, from what I have
learned, this ddl generation is already part of the eclipse dtp (rdb)
components, so it's more or less a "freebie". I suppose it's just a
matter of feeding in the right metadata so that the ddl gets generated
appropriately.
I think if your environment is set on one particular runtime (Kodo,
Toplink, etc), then using their DDL Generator would be the way to go.
But, if you are looking to develop independent applications, then it might
be nice to have the ddl generated independently.
Kevin
|
|
|
| Re: Couple of problems with generated ddl [message #433977 is a reply to message #433976] |
Mon, 29 May 2006 17:05 |
Shaun Smith
Messages: 197
Registered: July 2009 |
Senior Member |
|
|
Hi Kevin,
Thanks for your comments! I've inlined mine below.
Kevin wrote:
> Yes, I have used the mappingtool from Kodo to generate the database
> tables. It does work quite nicely. I have not tried the Toplink
> offering. Does their DDL generation come with the Glassfish project, or
> is this part of the purchased Toplink product?
DDL generation included in TopLink Essentials. "TopLink Essentials" is
the open source community edition of TopLink that's the JPA reference
implementation available both with Glassfish and separately
http://otn.oracle.com/jpa.
> I like having a tooling environment that is not dependent on any
> particular runtime environment. I suppose that's why I am interested in
> getting the Dali tooling provide this function. And, from what I have
> learned, this ddl generation is already part of the eclipse dtp (rdb)
> components, so it's more or less a "freebie". I suppose it's just a
> matter of feeding in the right metadata so that the ddl gets generated
> appropriately.
I understand your point about not being dependent on a runtime but
unfortunately, as you've discovered ;-), DDL generation is not entirely
free. Effort is required to update and maintain the Dali code base that
feeds it.
> I think if your environment is set on one particular runtime (Kodo,
> Toplink, etc), then using their DDL Generator would be the way to go.
This is what I've been thinking. Right now we don't have a way to
configure a runtime for DDL gen but it's something that could be done in a
nice pluggable fashion.
> But, if you are looking to develop independent applications, then it might
> be nice to have the ddl generated independently.
Yeah, it just comes down to the cost of supporting this feature when it
seems every runtime provides it. This is the big question--does it make
sense to build this functionality when it's available? Who's really going
to be building Entities and generating DDL if they don't have a runtime
when there are currently two open source implementations and a third on
the way?
--Shaun
|
|
| |
| Re: Couple of problems with generated ddl [message #588837 is a reply to message #433975] |
Fri, 26 May 2006 13:33 |
Kevin Sutter
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
Shaun Smith wrote:
> Hi Kevin,
> Have you tried using Kodo's mapppingtool to generate the DDL? I've
> used TopLink Essentials DDL generation and it works great. The reason I'm
> asking is that the availability of DDL generation from the JPA runtimes
> begs the question of why is it being built again in Dali? Perhaps a
> better solution is to provide support for running the DDL tools of the
> runtimes?
Shaun,
Yes, I have used the mappingtool from Kodo to generate the database
tables. It does work quite nicely. I have not tried the Toplink
offering. Does their DDL generation come with the Glassfish project, or
is this part of the purchased Toplink product?
I like having a tooling environment that is not dependent on any
particular runtime environment. I suppose that's why I am interested in
getting the Dali tooling provide this function. And, from what I have
learned, this ddl generation is already part of the eclipse dtp (rdb)
components, so it's more or less a "freebie". I suppose it's just a
matter of feeding in the right metadata so that the ddl gets generated
appropriately.
I think if your environment is set on one particular runtime (Kodo,
Toplink, etc), then using their DDL Generator would be the way to go.
But, if you are looking to develop independent applications, then it might
be nice to have the ddl generated independently.
Kevin
|
|
|
| Re: Couple of problems with generated ddl [message #588847 is a reply to message #433976] |
Mon, 29 May 2006 17:05 |
Shaun Smith
Messages: 197
Registered: July 2009 |
Senior Member |
|
|
Hi Kevin,
Thanks for your comments! I've inlined mine below.
Kevin wrote:
> Yes, I have used the mappingtool from Kodo to generate the database
> tables. It does work quite nicely. I have not tried the Toplink
> offering. Does their DDL generation come with the Glassfish project, or
> is this part of the purchased Toplink product?
DDL generation included in TopLink Essentials. "TopLink Essentials" is
the open source community edition of TopLink that's the JPA reference
implementation available both with Glassfish and separately
http://otn.oracle.com/jpa
> I like having a tooling environment that is not dependent on any
> particular runtime environment. I suppose that's why I am interested in
> getting the Dali tooling provide this function. And, from what I have
> learned, this ddl generation is already part of the eclipse dtp (rdb)
> components, so it's more or less a "freebie". I suppose it's just a
> matter of feeding in the right metadata so that the ddl gets generated
> appropriately.
I understand your point about not being dependent on a runtime but
unfortunately, as you've discovered ;-), DDL generation is not entirely
free. Effort is required to update and maintain the Dali code base that
feeds it.
> I think if your environment is set on one particular runtime (Kodo,
> Toplink, etc), then using their DDL Generator would be the way to go.
This is what I've been thinking. Right now we don't have a way to
configure a runtime for DDL gen but it's something that could be done in a
nice pluggable fashion.
> But, if you are looking to develop independent applications, then it might
> be nice to have the ddl generated independently.
Yeah, it just comes down to the cost of supporting this feature when it
seems every runtime provides it. This is the big question--does it make
sense to build this functionality when it's available? Who's really going
to be building Entities and generating DDL if they don't have a runtime
when there are currently two open source implementations and a third on
the way?
--Shaun
|
|
|
Goto Forum:
Current Time: Sat Apr 20 01:41:04 GMT 2024
Powered by FUDForum. Page generated in 0.03457 seconds |
] 
Search
Help
Register
Login
Home
