Couple of problems with generated ddlhttps://www.eclipse.org/forums/index.php/mv/msg/137561/433970/#msg_433970
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.

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).

Thanks,
Kevin]]>Kevin Sutter2006-05-24T14:11:16-00:00Re: Couple of problems with generated ddlhttps://www.eclipse.org/forums/index.php/mv/msg/137561/588830/#msg_588830
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]]>Shaun Smith2006-05-25T21:06:32-00:00Re: Couple of problems with generated ddlhttps://www.eclipse.org/forums/index.php/mv/msg/137561/433975/#msg_433975
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.

> 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.

> 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.

> 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?

> 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?