Previously, it was the QtTimeZoneType::DontConvert that implied the
Qt::LocalTime timezone spec.
Setting this to the Qt::UTC by default is the only way to have the
maximum level of interoperability between TinyORM and other libraries
and services.
- updated comments in docs and source code
It allows to call eg. getRelationValue() inside these callbacks and
an user can also use const Model *const if needed, so it's much more
flexible.
Also I left const Model * in documentations, I didn't remove the const
from docs, it's on pupropse to show that it's possible.
Missing the PivotType to correctly serialize models collection
with belongs-to-many relations only, eg. after calling the getRelation()
or getRelationValue().
Fix the null QVariant bug for QJsonDocument, replace null QVariant-s
with the QVariant(nullptr).
The QJsonValue should return null for null QVariant-s but it doesn't,
even if the Qt's QJsonValue::fromVariant() documentation explicitly
states this behavior, it says: "If QVariant::isNull() returns true,
a null QJsonValue is returned or inserted into the list or object,
regardless of the type carried by QVariant.".
But this is not happening, it returns 0 for numbers, "" for QString and
QDateTime. 🫤
- updated unit tests
- added unit test method to test this behavior, to test null for all
QVariant types
Thanks to the CRTP the user doesn't have to define operator==() in every
model, the u_xyz data members are compared here. I don't like it though,
one caveat of this is that if a user defines the operator==() then these
data members will be compared twice.
I have to write a note here, this !relation.name.contains(DOT) bugfix
was unbelievable, it took me a whole day of debugging, writing unit
tests, and figuring out how to solve this problem. I wrote dozen of
lines to make it work but at the end I started removing what was not
needed and ended with this one condition. 😮🙃 If the relation name is a
nested relation, then the select constraints lambda will not be
generated and will be nullptr, so will be skipped here, the problem was
that the getRelatedTableForBelongsToManyWithVisitor() could not be
invoked correctly because it's a nested relation. The
getRelatedTableForBelongsToManyWithVisitor() will be visited or resolved
later, right before it will be needed and it will be done during
relation->getQuery().with(std::move(nested)); in the
eagerLoadRelationVisited(), the magic is done in the
relationsNestedUnder() when the nested relation is unwrapped.
- added bunch of unit tests for this case
silverqx