DQuest - ORM framework for Qt/Sqlite

[benlau]

Hi all,

I would like to share my new OSS project for Qt and mobile to you. It is DQuest , a C++ ORM (Object-relational mapping) for Qt framework. It aims to provide a rapid development environment for application with database access. The database model declaration is very simple , just like other C++/Qt class. It is designed for mobile environment but also useful for desktop and embedded application that do not demand for maximized performance for database.

It is getting more number of application use Sqlite for their data storage. However, writing data model in SQL is complicated . Usually it need to write two set of interface : One for C/C++ and other for Sql. The work load is duplicated, and debug is troublesome.

With DQuest, you can declare a database model using C++ directly. Read / write access can be made through the C++ interface. You won't need to wbrite any SQL to gain the benefit of using Sqlite in your application.

To declare your database model, you need to:

* Create a class that inherits DQModel
* Added a DQ_MODEL macro to the class declaration
* Design your database field by using DQField template type
* Register your model with DQ_DECLARE_MODEL macro function.

Example:


#include <dqmodel.h>

/// User account database
class User : public DQModel {
DQ_MODEL
public:
DQField<QString> userId;
DQField<QDateTime> creationDate;
DQField<qreal> karma;
};

/// Declare the model and the field clause
DQ_DECLARE_MODEL(User,
"user", // the table name.
DQ_FIELD(userId , DQNotNull | DQUnique),
DQ_FIELD(creationDate , DQDefault("CURRENT_TIMESTAMP") ),
DQ_FIELD(karma)
);


The declaration is equivalent to make this SQL table for SQLITE



CREATE TABLE user (
id INTEGER PRIMARY KEY AUTOINCREMENT,
userId TEXT NOT NULL UNIQUE,
creationDate DATETIME DEFAULT CURRENT_TIMESTAMP ,
karma DOUBLE
);


Remarks: QObject is rarely used in DQuest , and DQModel is not QObject-based.

Features

Database model declaration and registration is simple.

Declare model in C++/Qt way (p.s QObject is not used)
Support model inheritance
Foreign key - auto load entry

Supported operations : create table , drop table , select , delete , insert , query the existence of table , ...
Support Sqlite - usable on mobile platform
Open source (New BSD license)


Pending features

Multiple database access

The software design support to access multiple database , but it is not tested.

Multi-threading

The software design support multi-threading , but it is not tested.


Limitations

DQuest is still in alpha stage. Use at your own risk.
Not all SQL statement and options are implemented , most of them can be added upon on user request. Please join the mailing list.
Not implemented operations : create trigger , create index
Not supported operations : join select

Licensing

DQuest source code is licensed under BSD license. You may use it for open source and closed source application , you just need to obey the requirement of BSD (e.g distribute the license agreement). Moreover, if you can inform us that your application is using DQuest. It can encourage developer to further develop the software.



Links:

Project Page (http://code.google.com/p/d-quest/)
Mailing list (http://groups.google.com/group/dquest-dev)
API Document (http://d-quest.googlecode.com/svn/trunk/docs/annotated.html)

[wysota]

Remarks: DQModel is not QObject based, (QObject is rarely used in DQuest) , therefore you don't need to write setter/getter for each database field.
I don't understand this sentence. Would you explain why if a class is not based on QObject you don't need setter/getter methods?

[benlau]

When I talk this project to friend , he think that I am using QObject/moc to implement ,and use the Q_PROPERTY to declare field , then it can get the field list from meta object.

But in fact it do not use QObject . QObject require a setter /getter for each field , but DQuest do not have that requirement. So I just want to clarify it.

Anyway , I think this statement is confusing. I will remove it.

[wysota]

No, QObject doesn't require a getter and setter method for each field. Don't confuse fields and properties - you can have a field without it being a property and you can have a property without it being a physical field in a class. And you can have a read-only property that only needs a getter but not a setter.

[benlau]

I mean he think it use property to declare database "field" , not talking about member variable / attribute. I think every C++ programmer won't mix up the concept , so didn't verified the wording before send.