[Nepomuk] Review Request: Sub-resource handling in DMS removeProperty
Christian Mollekopf
chrigi_1 at fastmail.fm
Fri Aug 5 20:06:50 UTC 2011
> On July 22, 2011, 8:04 a.m., Vishesh Handa wrote:
> >
I also think marking the thing/resource as a sub-resource would be a good solution.
But this should happen on a per application level.
I.e. application X marks a subresource, which would be automatically deleted if a links to it are removed,
and another application Y added properties to the resource we should still not delete it, since otherwise we might delete properties created by a user.
This is especially a point if Pimo:Things are marked as sub-resources of indexed resources
Other than that I fully agree with the proposed behavior that sub-resources should also be removed on removeProperty.
- Christian
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101994/#review4954
-----------------------------------------------------------
On July 18, 2011, 3:04 p.m., Sebastian Trueg wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101994/
> -----------------------------------------------------------
>
> (Updated July 18, 2011, 3:04 p.m.)
>
>
> Review request for Nepomuk.
>
>
> Summary
> -------
>
> So far we have sub-resource handling in removeResources and removeDataByApplication. It means that sub-resources are removed if their super-resources are removed, too and no other resource references them. However, this is not done in removeProperty and removeProperties. IMHO it should be done, too. As soon as the nao:hasSubResource relation is removed there is no relation between super- and sub-resource anymore rendering the sub-resource pointless.
>
> The attached patch simply adds two unit tests. It does not include the actual code which implements the sub-resource handling in removeProperty and removeProperties. The point of this review request is to determine if the behavior explained above is what we want or not.
>
>
> Diffs
> -----
>
> nepomuk/services/storage/test/datamanagementmodeltest.h a46e525
> nepomuk/services/storage/test/datamanagementmodeltest.cpp f2ca76e
>
> Diff: http://git.reviewboard.kde.org/r/101994/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Sebastian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20110805/fdcf5cee/attachment.html>
More information about the Nepomuk
mailing list