[Qt-interest] RFC : QDjango, a Qt-based C++ ORM

[André Fillipe]

Hi, Jeremy!

This is good news! I wish there was something like that when we
first looked around. There wasn't, however, and we developed our own
solution in-house. I think that based on our experience, I can humbly
give you a few points to think about:

Automatically versioning the model schema and providing tools to ease
schema evolution is a good thing to consider. We only thought about
this when the second version of our app shipped, full of changes in
the model. We had little time to perfect the schema evolution.

Consider using Q_CLASSINFO as well as setFieldOption() to set the
attributes of database fields and the model class in general. You
probably want that information to be static.

Supporting dynamic properties would be nice. The use case: plug-ins
might want to add extra information to "core" model classes.

Creating classes to help support 1..1, 1..n, m..n relationships is a
good thing. We initially had no explicit support for this and had to
code our relationships in the model classes using queries. That lead
to a lot of repeated code and unexpected errors until we finally
decided to create those classes. We did it by implementing m..n
(using a relationship table) and constrained the foreing keys to get
1..n and 1..1. Might not be optimal for every case, but it did a good
job for us. Bonus: attributes on the relationships.

Don't go for the Hibernate goal of being able to represent legacy
database models. It will complicate your API, your design, and your
code.

Consider that some users might want to do storage related stuff in a
worker thread. How would the library behave, then? We did not think
about it beforehand, believing SQLite would never slow us down and we
could always access the storage from the GUI thread. Well, we were
wrong.

When we started, I also had this lofty goal of separating the model
representation from the model classes and allowing the client code to
use a generic DataModel class to access the storage and only derive
from it if it was really necessary. Too complicated, too little time
to do it, postponed forever. But it would be a terrific feature to
have.

As a final suggestion, take a look at Apple's Core Data library. It's
not Active Record like Django, but it's a very simple API and has
some neat features, like integration with the Cocoa undo manager. Our
solution borrows a lot from Core Data's design.

Thank you for sharing your work and I wish you all the success.
Expect some patches from me! :)

-- 
André Fillipe