Qt-contributors-summit-2011-Qt Object Relational Mapping

From Qt Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Rough agenda/plan

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

Notes from session

(currently just a braindump, needs work)

Rough overview

Two main flavors of ORM

  1. write application for existing database
    • From reading DB schema can generate C++ classes.
  2. 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 DBAs). 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)
    • MOC – add property attribute (STORE? DESIGNABLE)
    • 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
  • QML can do metaobjects fairly easily
    • QML 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 (XML, JSON, web etc based, SQL, NoSQL, LDAP, …)
  • 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)
    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 XML, we could use QML/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 MSSQL only?)

The perfect is the enemy of the good

Action plan

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

Retrieved from "https://wiki.qt.io/index.php?title=Qt-contributors-summit-2011-Qt_Object_Relational_Mapping&oldid=29579"