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

[Jeremy Lainé]

Hi André,

Thanks a lot for your feedback!

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

What kind of capabilities are you thinking of? I have a feeling it is going to be pretty hard to capture this is in a generic way, but if you have some pointers I'd be interested.

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

This is definitely something I'd like to do. I think that once a Q_CLASSINFO-based method is available, the QDjangoModel::setFieldOption() method should be removed altogether, it would not make sense to have two ways to do it. Do you have any suggestions as to what key/values to use, possibly pointers to opensource projects which do something similar? If we go down this road we will need to freeze the format of the options early on.

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

Hm, I'm not too sure about this, but why not.

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

Admittedly, this is one of the points where the code is still in its early stages.

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

Could you describe in a bit more detail what your requirements are? One thing I have considered is to make QDjango::database() return a handle which is specific to the current thread (by cloning the reference database connection). Would this be sufficient for you?

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


OK will do!

I you want to discuss QDjango in more detail, may I suggest we move the discussion to the QDjango mailing list?

http://lists.bolloretelecom.eu/mailman/listinfo/qdjango

-- 
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris