|
|
| Line 1: |
Line 1: |
| =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.
| |