Inheritance in ORMLite
tbull
Looking for a persistence tool which fits my needs, I'm pretty
optimistic ORMLite could be it. There's only one point: It does not
appear to support inheritance. The entire documentation does not
mention the subject. What I understand from
http://groups.google.com/group/ormlite-dev/msg/f04653f00793ab23?hl=en
is that classes of a hierarchy are treated in a completely independent
manner.
What I need is: If I have class A as a superclass, and I have direct
subclasses B and C, and I run a query for all records/objects of class
A, I do want to have all objects of class A, B and C returned. And if
I then ask (record instanceof B), I want the correct answer, so I can
cast it to the correct subclass type, should I feel the urge.
Are there any intentions to add such functionality to ORMLite? If so,
what is the current status?
Do you think it is possible to create such functionality purely with
user-side code, i.e. without messing in the ORMLite internals,
possibly by providing an appropriate implementation of the Dao
interface and some helper classes? Could you give me some starting
pointers? I'm pretty ambitious to provide such code if the amount of
work stays in a reasonable frame.
So long, tbull
Gray Watson
> There's only one point: It does not appear to support inheritance.
> What I understand [...] is that classes of a hierarchy are treated in a completely independent manner.
Yes. Fields from base classes are treated the same as fields in the sub-classes but that's all.
> What I need is: If I have class A as a superclass, and I have direct subclasses B and C, and I run a query for all records/objects of class A, I do want to have all objects of class A, B and C returned.
Yeah, ORMLite does not do this and currently I have no plans to support it. The complexity of this, unless I am mistaken on how to accomplish this, is outside of what I'd say was "Lite". The way Hibernate supports such constructs, is by having foreign keys, multiple tables, and magic joins.
> Do you think it is possible to create such functionality purely with user-side code, i.e. without messing in the ORMLite internals, possibly by providing an appropriate implementation of the Dao interface and some helper classes?
I see 2 ways you could do something like this. It depends how strongly that you feel about your class hierarchy.
1) You could have class A and an associated table -- so it can't be abstract. Then you could have have B and C which subclass A and have all of As fields each in a separate table. You could then create a special DAO for A which would also query for B and C and add them into your results for A.
2) Another way to do it is you could make classes B and C _not_ be subclasses but instead have a foreign object to A. You can then query all of the As and some of them would be B's A part and some C's A part and some just A. You then could also query Bs and Cs and use the A DAO to refresh and get the A's fields you would not be able to cast. A could also have some sort of enum which said whether it was a A, B, or C. You could also do some magic where you could say getSubClassObject(), if would look at the enum and query the B or C dao for the associated object with the right foreign key for the A object.
3) Anyone want to throw out some other ways?
> Could you give me some starting pointers? I'm pretty ambitious to provide such code if the amount of
> work stays in a reasonable frame.
I'm not sure this would (or could) be a generic solution but I'd certainly be interested to see what you did and whether it could be folded into a feature.
gray
tbull
> Yeah, ORMLite does not do this and currently I have no plans to support it. The complexity of this, unless I am mistaken on how to accomplish this, is outside of what I'd say was "Lite".
> The way Hibernate supports such constructs, is by having foreign keys, multiple tables, and magic joins.
http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/inheritance.html
> 1) You could have class A and an associated table -- so it can't be abstract. Then you could have have B and C which subclass A and have all of As fields each in a separate table. You could then create a special DAO for A which would also query for B and C and add them into your results for A.
behaviour (superclass fields are already repeated in subclass tables).
Downsides are the data replication (repetition of A's fields in all
subclasses) and the multiplication of queries. Probably has its
strengths in very limited hierarchies (only few subclasses) where
superclasses have few fields and subclasses have many.
> 2) Another way to do it is you could make classes B and C _not_ be subclasses but instead have a foreign object to A. You can then query all of the As and some of them would be B's A part and some C's A part and some just A. You then could also query Bs and Cs and use the A DAO to refresh and get the A's fields you would not be able to cast. A could also have some sort of enum which said whether it was a A, B, or C. You could also do some magic where you could say getSubClassObject(), if would look at the enum and query the B or C dao for the associated object with the right foreign key for the A object.
> 3) Anyone want to throw out some other ways?
per-class-hierarchy strategy, where all subclass records are stored in
one table together with the root class of a hierarchy. The table would
have to provide columns for all fields of all subclasses as well as a
discriminator column which maps a record to a particular subclass.
Consequently, subclass fields cannot be declared NOT NULL. Also, this
produces lots of empty fields. On the plus side you only need one
query for the entire hierarchy.
This should be best suited for very extensively (deeply and broadly)
distinguished hierarchies, where each subclass adds only few fields.
However, this approach seems to be rather complicated to implement.
> I'm not sure this would (or could) be a generic solution but I'd certainly be interested to see what you did and whether it could be folded into a feature.
Well, I have to do some thinking and code digging. So far I haven't
used ORMLite, only read some of the docs. So this will take some time.
I tend to go for the first approach for a first shot.
Thanks for the advice.
Gray Watson
> So rename it to ORMMedium, I don't mind. ;-)
Might as well go to ORMHeavy. :-)
> Actually, Hibernate has several approaches to this, as laid out in
> http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/inheritance.html
Thanks. I was guessing. Thanks for calling me on it.
>> 2) Another way to do it is you could make classes B and C _not_ be subclasses but instead have a foreign object to A.
> Doesn't look very sexy to me. ;-)
I guess that's hibernate's "Table per subclass".
> My approach would have been what the Hibernate guys call the one-table-
> per-class-hierarchy strategy, where all subclass records are stored in
> one table together with the root class of a hierarchy.
I get it. Any idea how it would be configured? Right now I have 1 class per DAO. Maybe some extra annotation or field on the abstract class?
> This should be best suited for very extensively (deeply and broadly)
> distinguished hierarchies, where each subclass adds only few fields.
> However, this approach seems to be rather complicated to implement.
Yeah. It means that everywhere where I do refreshes and the like I'd have to know which of the subclasses I was dealing with. Do-able but I don't see a good cost benefit right now.
> Well, I have to do some thinking and code digging. So far I haven't
> used ORMLite, only read some of the docs. So this will take some time.
> I tend to go for the first approach for a first shot.
Thanks for the feedback. Let me know how it goes or if there is anything ORMLite can do to help.
gray
Francis Novello Santos
1) Create an abstract superclass thats not an ORMLite database table
but has some database fields used by all subclasses
public abstract class Event {
@DatabaseField(columnName="id", generatedId = true)
protected int _id;
@DatabaseField(columnName="name")
protected String name;
@DatabaseField(columnName="date")
protected Date date;
@DatabaseField(columnName="type")
protected String type;
public abstract void setName(String name);
public abstract void setDate(Date date);
public abstract void setType(String type);
}
2) Create a class that inherits it and add some fields (thats a
Database Table)
@DatabaseTable(tableName="atividade")
public class Atividade extends Event {
@DatabaseField(columnName="ala")
protected String ala;
public String getAla() {
return ala;
}
public void setAla(String ala) {
this.ala = ala;
}
public Atividade(String name, Date date,
String type, String ala) {
this.setName(name);
this.setDate(date);
this.setTipo(type);
this.setAla(ala);
}
Atividade(){
}
@Override
public void setName(String name) {
this.name = name;
}
@Override
public void setDate(Date date) {
this.date = date;
}
@Override
public void setType(String type) {
this.type = type;
}
}
