Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Dali » Couple of problems with generated ddl
Couple of problems with generated ddl [message #433970] Wed, 24 May 2006 10:11 Go to next message
Kevin Sutter is currently offline Kevin Sutter
Messages: 104
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 #433975 is a reply to message #433970] Thu, 25 May 2006 17:06 Go to previous messageGo to next message
Shaun Smith is currently offline Shaun Smith
Messages: 197
Registered: July 2009
Senior Member
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?

Your thoughts?

I'd like to open this topic up for community feedback so I'll crosspost
this question to the dali-dev mailing list.

Shaun
Re: Couple of problems with generated ddl [message #433976 is a reply to message #433975] Fri, 26 May 2006 09:33 Go to previous messageGo to next message
Kevin Sutter is currently offline Kevin Sutter
Messages: 104
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 13:05 Go to previous message
Shaun Smith is currently offline 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 #588830 is a reply to message #433970] Thu, 25 May 2006 17:06 Go to previous message
Shaun Smith is currently offline Shaun Smith
Messages: 197
Registered: July 2009
Senior Member
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?

Your thoughts?

I'd like to open this topic up for community feedback so I'll crosspost
this question to the dali-dev mailing list.

Shaun
Re: Couple of problems with generated ddl [message #588837 is a reply to message #433975] Fri, 26 May 2006 09:33 Go to previous message
Kevin Sutter is currently offline Kevin Sutter
Messages: 104
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 13:05 Go to previous message
Shaun Smith is currently offline 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
Previous Topic:@ManyToMany kind of working...
Next Topic:problems with jdt...
Goto Forum:
  


Current Time: Thu Aug 28 05:22:16 EDT 2014

Powered by FUDForum. Page generated in 0.12759 seconds