[Qt-interest] Qt5 and SQL

[Jason H]

Well, you make valid points. Ultimately, the engineer should decide if he wants 
to use a QObject or a lighter weight definition. Let me explain. 


For most things, and given some kind of usable definition (*.hbm.xml) a class 
generator is fine and dandy. But occasionally you need some run-time 
flexibility. Currently, I do a lot of reporting with NHibernate in a .Net 
project I inherited. Due to some Hibernate's aliasing features (table and column 
names, a blessing and a curse really), it makes it hard to switch between SQL 
and HQL (Hibernate Query Language, similar to SQL) Any time I have to drop back 
to SQL is a failure on NHibernate's part, because one of the stated goals is 
true database abstraction. But if I have to drop to SQL, I don't know that my 
project will have that, thus defeating the stated goals.

 It is simply too much work to account for every possible reporting parameter 
and schema. You should be able to statically define those that are used commonly 
and in high numbers. But if you need an adhoc query in database-abstract HQL, 
you should be able to do that too. So yes, the run-time definition won't scale, 
but you don't have to use it if you don't want to. 


The desire to have ad-hoc HQL comes up in a simple query builder or any 
reporting system. If you have a lot of reports (my current project has over 50 
distinct reports, not including variations) then I don't want to have to define 
50 (plus variants) HQL object definitions. Rather, the mapping should happen at 
run-time. Then it can be left to the developer to define the static definitions 
for the larger (row counts) or more common reports. 


Someone posted recently about a ORM layer on top of Qt. I asked about 
NHibernate. It seemed his project was 1/2 of the way there, but not trying to 
replicate the cooler Hibernate functions.




----- Original Message ----
From: Andre Somers <andre at familiesomers.nl>
To: Qt-Interest <qt-interest at trolltech.com>
Sent: Wed, May 18, 2011 8:38:00 AM
Subject: Re: [Qt-interest] Qt5 and SQL


Op Wo, 18 mei, 2011 2:28 pm, schreef Jason H:
> While I absolutely despise [N]Hiberbate, it sounds like that is what you
> are asking for.
There are alternatives out there, but none of them implement what I'd like
to see for Qt.

> I think a QHibernate could be cool, and we could improve on the hibernate
> at the
> same time. For instance, I despise Hibernate because it violates DRY
> principals.
> It requires a XML definition and a code (object) definition, not to
> mention the actual change to the source.
I did not study Hibernate much, but I have looked at a few ORM systems
before. I don't think defining the structure in an XML file is wrong, but
that should then lead to code generation. You should not need to implement
the same structure yourself again.

> If we could use QMetaObject to construct the object
> definition at run- or compile- time, then we'd have a less despicable
> version.
Please, no. Don't make this depend on QMetaObject. Having to have all your
data objects be QObjects makes all this stuff *way* too heavy weight. Nice
if you can make it generate QObjects when that is reasonable, but please
don't force it on people.

> (Basically I imagine a file to have a field type preference and lay out
> the relational structure, like the *.hbm.xml files, but we could run it
> through a
> proxy generator or QMetaObject would create a meta type and register it at
> run time.)
I came to the conclusion that compile time code generation is the only
scalable and flexible solution I could see. But perhaps I overlooked some
things.

André


_______________________________________________
Qt-interest mailing list
Qt-interest at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-interest