View source for Qt-contributors-summit-2011-Qt Object Relational Mapping

{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
[[Category:QtCS2011]]
=Rough agenda/plan=

1. Ideas<br /> 2. Existing Qt/C++ <span class="caps">ORM</span> implementations<br /> 3. QObject, QMetaObject, moc enhancements needed for <span class="caps">ORM</span><br /> 4. What to avoid for a good <span class="caps">ORM</span> framework<br /> 5. What’s the relationship between QtSql and Qt <span class="caps">ORM</span><br /> 6. What’s your dream Qt <span class="caps">ORM</span> code look like?

=Notes from session=

''(currently just a braindump, needs work)''

==Rough overview==

Two main flavors of <span class="caps">ORM</span>

# write application for existing database
#* From reading DB schema can generate C++ classes.
# use database for storage for existing application
#* From reading metaobjects can generate schema etc

Some relational databases do not use primary keys (compound/natural keys, or stored procedures to actually manipulate/retrieve data if paranoid <span class="caps">DBA</span>s). Writing a persistence framework that uses relational DB technology is different from writing a framework that can handle all relational DB technology.

Very different use cases. Try to collect them all. Two main approaches (hibernate for app to db, or writing an app for the db)

==Random ideas==

* Add something to moc/QObject meta system (e.g. annotations, or property attributes)
** <span class="caps">MOC</span> – add property attribute (<span class="caps">STORE</span>? <span class="caps">DESIGNABLE</span>)
** Probably makes more sense to design an object for serialization from the start
** compile time type safety really needs generated code (uic? moc? ormc?)
* using qvariant etc is kinda clunky but for pure run time dynamism is needed
* <span class="caps">QML</span> can do metaobjects fairly easily
** <span class="caps">QML</span> is a much more flexible environment with less code generation requirements (since JS is not strongly typed).
* Have a lazy smart pointer class – serializes as id, dereferences as class. What happens when it fails (default ctor classes?)
* lots of backends (<span class="caps">XML</span>, <span class="caps">JSON</span>, web etc based, <span class="caps">SQL</span>, NoSQL, <span class="caps">LDAP</span>, …)
* Might be nice to support non QObject based, particularly for large numbers
* Asynchronous? Incremental/windowed retrieval
* Querying nice (e.g. qdjango)
* Schema evolution good in a lot of cases (versioned properties? defaults set by ctor)
* Custom reader/writer functions for objects (what are the inputs or outputs? but makes sense)
* Should the framework allow creating stores? (e.g. creating tables based on schema, altering schema)
* Partial object retrieval (e.g. for speed/memory consumption) would be good.

==Random issues==

* Dependent properties cause big problems on restoring (e.g. r,g,b values or layout)<br /> With ormc can embed schemas and perhaps the modifications needed for upgrades (passing to engine, but do there need to be instructions for each engine)
* Usual experience is that generated code needs tweaks.

==Mapping between store and objects==

* Hibernate mapping file can resolve problems (db schema, object definitions and mapping between). Hibernate uses <span class="caps">XML</span>, we could use <span class="caps">QML</span>/JSON.
* Perhaps a tool to try to autogenerate mapping from database, and then the mapping can be tweaked.
* Different views may need different C++ classes (with different mappings).
* Is C++ mapping necessary? Can we just use JS (persistence.js?). It most likely is.
* A generator for dynamic meta objects is basically the same code as a generator for dynamic typesafe function calls.

==Mapping between objects and store==

* Creating schemas from QObject (possibly with more annotations) is useful.
* Hierarchical objects and relational databases (customers with addresses, normalization of data is needed for relational databases).
** Might need extra non-schema information
** Maybe be able to use pointer address as ids
* Can use preexisting QObjects (of certain types – with typename, object name, metaproperties etc)
* Extra constraints beyond types is probably necessary (e.g. enums or even worse inter property constraints)
* Hibernate – Setters can set dirty flags (for lazy writes)
* Have to register objects with the persistence framework. Java works differently (similar to d pointer, can track dirtiness/non const derefs)

==Nightmares – what can we avoid==

(e.g. some parts of hibernate work well but <span class="caps">MSSQL</span> only?)

The perfect is the enemy of the good

=Action plan=

Qt5 mailing list to start with, record conclusions on wiki page.