[Nepomuk] Review Request: Remove special handling for rdf:type

[Sebastian Trueg]

> On July 12, 2012, 9:49 a.m., Sebastian Trueg wrote:
> > libnepomukcore/resource/resourcedata.h, line 92
> > <http://git.reviewboard.kde.org/r/105517/diff/1/?file=72089#file72089line92>
> >
> >     hasType(const Types::Class& type)
> >     would be cool instead. Internally it could use property()
> 
> Vishesh Handa wrote:
>     In ResourceData? Or did you mean in Resource?

I meant Resource, yes.


> On July 12, 2012, 9:49 a.m., Sebastian Trueg wrote:
> > libnepomukcore/resource/resourcedata.cpp, line 71
> > <http://git.reviewboard.kde.org/r/105517/diff/1/?file=72090#file72090line71>
> >
> >     Why do you still need variable m_types when the point is to remove the special handling?
> 
> Vishesh Handa wrote:
>     For new resources. When you create a new Resource via Resource( QUrl(), NCO::Contact() ), the type needs to be saved when the resource is created. Though I think I could simplify the code by making it a simple QUrl instead of a list.
>     
>     I'll try it out.

Can't you just put it into the cache and save everything in the cache in ResourceData::store()?


- Sebastian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105517/#review15719
-----------------------------------------------------------


On July 11, 2012, 8:41 p.m., Vishesh Handa wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105517/
> -----------------------------------------------------------
> 
> (Updated July 11, 2012, 8:41 p.m.)
> 
> 
> Review request for Nepomuk and Sebastian Trueg.
> 
> 
> Description
> -------
> 
> Remove special handling for rdf:type
> 
> This includes storing the maintype when loading all the properties. This
> simplifies the code base, and actually improves performace.
> 
> Because the type deduction is done during load time, the relevant types
> needed to be loaded into memory by Types::EntityPrivate, this increases
> the load time for each resource by an order of 5x. This extra load
> eventually goes down when all the required types are loaded, but it's
> there.
> 
> Also, the additional cost of infering the type each time doesn't seem to
> have any performance loss. Mainly cause everything is already in memory.
> 
> Another reason for this patch is the planned refactoring of the class
> internals to use shared memory. Every extra variable in ResourceData
> adds an overhead.
> 
> 
> Diffs
> -----
> 
>   Info.plist.template PRE-CREATION 
>   includes/CMakeLists.txt 4ac2d7cfcba1522eb73b432533a08b3fd1e148b3 
>   includes/Query/ResultIterator PRE-CREATION 
>   libnepomukcore/CMakeLists.txt 066c8986dfa2b3150072dbd96a71caf8873cea06 
>   libnepomukcore/datamanagement/createresourcejob.h 7abf51d4c9c3a4bd0c4036234dae006c7b10bfb8 
>   libnepomukcore/query/resultiterator.h PRE-CREATION 
>   libnepomukcore/query/resultiterator.cpp PRE-CREATION 
>   libnepomukcore/resource/resource.cpp c237f44c1420929143299aab391a0f2a7709f894 
>   libnepomukcore/resource/resourcedata.h 370889700cb93dbf93bc6cb4b498fab2470cafba 
>   libnepomukcore/resource/resourcedata.cpp 6fa262f955936637f48c81b0cce6ac9069f37167 
> 
> Diff: http://git.reviewboard.kde.org/r/105517/diff/
> 
> 
> Testing
> -------
> 
> Manual + Unit Testing :)
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120712/844e1abb/attachment.html>