bruns added a comment.
In the old code, the backend was created lazily, as the associated DBus
connection was expensive, this is no longer the case. I am wondering if
creating the backend immediately/always would not solve a number of structural
problems here (though this is already *much* better than what we have
curently). We could store the properties in the backend (non-flattened), and
return the flattened map on demand. For normal property lookups, we would just
walk the interfaces and lookup the key/value.
INLINE COMMENTS
> udisksdevicebackend.cpp:111
> {
> - QDBusMessage call = QDBusMessage::createMethodCall(UD2_DBUS_SERVICE,
> m_udi, DBUS_INTERFACE_PROPS, "GetAll");
> -
> - Q_FOREACH (const QString &iface, m_interfaces) {
> - call.setArguments(QVariantList() << iface);
> - QDBusPendingReply<QVariantMap> reply =
> QDBusConnection::systemBus().call(call);
> -
> - if (reply.isValid()) {
> - auto props = reply.value();
> - // Can not use QMap<>::unite(), as it allows multiple values per
> key
> - for (auto it = props.cbegin(); it != props.cend(); ++it) {
> - m_propertyCache.insert(it.key(), it.value());
> - }
> - } else {
> - qCWarning(UDISKS2) << "Error getting props:" <<
> reply.error().name() << reply.error().message();
> + m_propertyCache.clear();
> +
Why is this always cleared? I think a `if (!m_propertyCache.isEmpty) { return;
}` would be correct here.
REPOSITORY
R245 Solid
REVISION DETAIL
https://phabricator.kde.org/D19677
To: broulik, #frameworks, bruns
Cc: apol, nicolasfella, kde-frameworks-devel, michaelh, ngraham, bruns
