You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Les Hazlewood <le...@hazlewood.com> on 2003/03/26 17:56:10 UTC
Vertical Inheritance
Hello,
I've been looking around FOREVER for a free jdo implementaiton I can use to
begin testing jdo and how it might fit in to our application.
The closest thing I've found that meets my needs is the ojb project from
apache. I was wondering if anyone could clarify some things for me. I
tried looking in the archives for this, but the archive listed for this
mailing list on apache's website doesn't work (so please excuse this if its
been answered already).
I MUST be able to have the following features in order to even think about
using jdo - otherwise, I'm stuck with crappy entity beans and no inheritance
:(
Please note this email is intended to be viewed in a fixed-width font
(courier) for code examples.
1) I require Vertical Inheritance:
for example in sql:
table person
(
person_id char(36) primary key, -- this is a UUID/GUID
name varchar(50),
ssn varchar(20)
);
table employee
(
employee_id char(36)
foreign key references person(person_id)
primary key,
employee_num integer,
hire_date date
);
This would translate to the following java classes:
public class Person
{
private String personId;
private String name;
private String ssn;
//getters/setters for all of the above properties...
}
public class Employee extends Person
{
private String employeeId; //this is the same as its inherited personId
//because of primary key/foreign key
//constraints. That is,
// this.employeeId.equals(this.personId)
//always returns true
private int employeeNum;
private Date hireDate;
//getters/setters for the above properties....
}
Now, I'm sure almost all of the ojb folks are well aware of this vertical
mapping strategy.
Can I do this with ojb's JDO implementation? And if not, is there something
I can do to ojb to get it to work in this manner?
The most important thing here is that the underlying table structures are
not adjusted/modified/added-to in any way, and that the cooresponding java
classes are not adjusted/modified/added-to in any way. I.E. JDO should be
fully transparent.
The reason i'm not considering tjdo (http://tjdo.sourceforge.net) is becuase
I believe they don't support vertical inheritance.
In fact, I might even be open to OJB or other jdo implementation creating
its own "jdo management table" inside the database....as long as it doesn't
mess with the user-defined tables and supports vertical inheritance.
2) I don't want a JDO implementation messing with byte code. I feel this
is extremely poor design, as jvm's and jvm optimizations are certain to
change over time. There is a whole other list of why I think this is a
horrible idea, which I won't get in to now. Reflection/Introspection to
determine class functionality is a much better way to go.
3) I don't want a JDO implementation that requires I, as a developer, to
"know" about wrapper classes, or importing PersistanceCapable interfaces and
such. I want true Transparency. I don't care if the implemenation makes
its own wrappers and does what it wants. As long as I can code my business
objects without implementing jdo specific code, I'm happy. (I understand
that I'll used jdo code for doing transactions, persisting objects, and
querying....I'm just talking about class definition only).
Can anyone clarify OJB's stand on these issues?
I understand there are commercial JDO implementations that address these
issues, but I need something for development and testing that is free....I
can't afford the sometimes exuberant costs of $1000 - $6000 (per developer)
licensing fees.
Thanks so much for reading....any help in pointing me in the right direction
is greatly appreciated.
Les Hazlewood
Re: Vertical Inheritance
Posted by Les Hazlewood <le...@hazlewood.com>.
Les Hazlewood writes:
>
> Thomas,
>
> Thank you so much for a clear answer!
>
> You mentioned the release candidate addressing vertical inheritance...
>
Excuse me, I meant the 1.0 final release.
Les
Re: Vertical Inheritance
Posted by Les Hazlewood <le...@hazlewood.com>.
Thomas,
Thank you so much for a clear answer!
You mentioned the release candidate addressing vertical inheritance...
Is there any documentation on how this will work?
If not, is there internal code documentation that you can direct me to? (I'd
be happy to download the source code and poke my nose around a bit).
Les
Re: Vertical Inheritance
Posted by Thomas Mahler <th...@web.de>.
Hi Les,
Les Hazlewood wrote:
>
> Hello,
> I've been looking around FOREVER for a free jdo implementaiton I can use
> to begin testing jdo and how it might fit in to our application.
> The closest thing I've found that meets my needs is the ojb project from
> apache. I was wondering if anyone could clarify some things for me. I
> tried looking in the archives for this, but the archive listed for this
> mailing list on apache's website doesn't work (so please excuse this if
> its been answered already).
> I MUST be able to have the following features in order to even think
> about using jdo - otherwise, I'm stuck with crappy entity beans and no
> inheritance :(
> Please note this email is intended to be viewed in a fixed-width font
> (courier) for code examples.
> 1) I require Vertical Inheritance:
> for example in sql:
> table person
> (
> person_id char(36) primary key, -- this is a UUID/GUID
> name varchar(50),
> ssn varchar(20)
> );
> table employee
> (
> employee_id char(36)
> foreign key references person(person_id)
> primary key,
> employee_num integer,
> hire_date date
> );
> This would translate to the following java classes:
> public class Person
> {
> private String personId;
> private String name;
> private String ssn;
> //getters/setters for all of the above properties...
> }
> public class Employee extends Person
> {
> private String employeeId; //this is the same as its inherited personId
> //because of primary key/foreign key
> //constraints. That is,
> // this.employeeId.equals(this.personId)
> //always returns true
> private int employeeNum;
> private Date hireDate;
> //getters/setters for the above properties....
> }
>
> Now, I'm sure almost all of the ojb folks are well aware of this
> vertical mapping strategy.
This is not possible with the latest 1.0rc1 release. But we are
currently working on this feature and it will be in 1.0 the final
release. (Actually I checked in a major bulk of this code today).
> Can I do this with ojb's JDO implementation?
Once it is implemented on the OJB kernel level, it will be available for
the JDO part as well!
> And if not, is there
> something I can do to ojb to get it to work in this manner?
The workaround was to use 1:1 association to model the foreign key
reference.
> The most important thing here is that the underlying table structures
> are not adjusted/modified/added-to in any way, and that the
> cooresponding java classes are not adjusted/modified/added-to in any
> way. I.E. JDO should be fully transparent.
That's one of the OJB design goals as well!
> The reason i'm not considering tjdo (http://tjdo.sourceforge.net) is
> becuase I believe they don't support vertical inheritance.
I don't know how complete TJDO is.
> In fact, I might even be open to OJB or other jdo implementation
> creating its own "jdo management table" inside the database....as long
> as it doesn't mess with the user-defined tables and supports vertical
> inheritance.
The OJB JDO solution relies on no special tables.
> 2) I don't want a JDO implementation messing with byte code. I feel
> this is extremely poor design, as jvm's and jvm optimizations are
> certain to change over time. There is a whole other list of why I think
> this is a horrible idea, which I won't get in to now.
> Reflection/Introspection to determine class functionality is a much
> better way to go.
I agree with you that bytecode enhancement is a poor idea.
Unfortunately Java does not yet have Aspect Oriented facilities that
would make BE superfluous.
But it is not possible to write a JDO spec compliant based on
Reflection/Introspection only. You definitely need BE or any other pre-
or post processing!
The OJB JDO is a plugin to the SUN JDO Reference implementation. All the
upper layers of the JDO RI are used. This also requires to use BE.
The OJB JDO uses the JDORI Enhancer.
> 3) I don't want a JDO implementation that requires I, as a developer,
> to "know" about wrapper classes, or importing PersistanceCapable
> interfaces and such. I want true Transparency. I don't care if the
> implemenation makes its own wrappers and does what it wants. As long as
> I can code my business objects without implementing jdo specific code,
> I'm happy. (I understand that I'll used jdo code for doing
> transactions, persisting objects, and querying....I'm just talking about
> class definition only).
If you have a look at my sample (tutorial4.html and the respective code)
you will see that this is possible.
> Can anyone clarify OJB's stand on these issues?
> I understand there are commercial JDO implementations that address these
> issues, but I need something for development and testing that is
> free....I can't afford the sometimes exuberant costs of $1000 - $6000
> (per developer) licensing fees.
> Thanks so much for reading....any help in pointing me in the right
> direction is greatly appreciated.
> Les Hazlewood
cheers,
thomas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>