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