[Nepomuk] Nepomuk Core - Questions & Patches

[Vishesh Handa]

Hey Sebastian

On Mon, May 24, 2010 at 4:43 PM, Sebastian Trüg <trueg at kde.org> wrote:

>
> Yeah... I think merging determineUri into load and calling it simply
> load() is perfectly fine. The that method would only be called from
> Resource but never in ResourceData methods.
>
>
Just to be clear you want to merge determineUri() and load() and call it
load()?

Do you still want to keep the original determineUri? Cause merging it would
cause massive code duplication, if we still plan on keeping determineUri()
(which is a little buggy, btw) And if we don't plan on keeping
determineUri() what do we do with all the calls to it? It called before all
of the property, hasProperty() functions, and is called in store(), which is
called whenever you have any kind of setters( setProperty() setType() .. )

After trying to merge them. I don't think merging is that simple.

- Vishesh Handa



> Cheers,
> Sebastian
>
> > - Vishesh Handa
> >
> >
> >
> >     Be aware though that I did not look at your patch in detail yet. I
> will
> >     do that later. So I might have missed something. :)
> >
> >     Cheers,
> >     Sebastian
> >
> >     On 05/23/2010 05:54 PM, Vishesh Handa wrote:
> >     >
> >     > On Sun, May 23, 2010 at 8:20 PM, Sebastian Trüg <trueg at kde.org
> >     <mailto:trueg at kde.org>
> >     > <mailto:trueg at kde.org <mailto:trueg at kde.org>>> wrote:
> >     >
> >     >     On 05/23/2010 04:23 PM, Vishesh Handa wrote:
> >     >     >     > One way of solving both the problems is to derive
> >     >     ResourceData from
> >     >     >     > QObject. And then call deleteLater() instead of "delete
> >     >     this". (Patch
> >     >     >     > attached)
> >     >     >
> >     >     >     oh, no, please don't. Totally useless overhead. It is
> much
> >     >     simpler to
> >     >     >     make the mutex recursive.
> >     >     >
> >     >     >
> >     >     > Well then we need a better way of solving the "delete this"
> >     problem.
> >     >     > When you say moving "it" into Resource, do you mean
> >     determineUri() or
> >     >     > replaceWith() ?
> >     >
> >     >     I mean all calls of determineUri().
> >     >     Example:
> >     >     ResourceData::removeProperty calls determineUri. Instead
> >     determineUri
> >     >     should be called in Resource::removeProperty.
> >     >
> >     >
> >     > I'm sorry. I don't understand. Isn't it the same thing? If A calls
> >     B or
> >     > B is called inside A?
> >     >
> >     >
> >     >     The only problem here is load. But I recently thought that it
> >     could be
> >     >     merged into determineUri (or the other way around). After all
> most
> >     >     resources do not have more than - say - 20 properties. That is
> >     quickly
> >     >     loaded and would avoid performing yet another query. What I
> >     mean is that
> >     >     in determineUri
> >     >
> >     >     select distinct ?r ?o where {
> >     >     { ?r nie:url <uri> . }
> >     >     UNION { <uri> ?p ?o . } } LIMIT 1
> >     >
> >     >     could become something like
> >     >
> >     >     select distinct ?r ?pp ?oo where {
> >     >     { ?r nie:url <uri> .
> >     >     ?r ?pp ?oo . FILTER(?r!=<uri> . }
> >     >     UNION { <uri> ?p ?o . <uri> ?pp ?oo . }
> >     >
> >     >     to determine the URI AND load all properties at the same time.
> >     >     Just an idea I had when I thought about ways to spped it all
> up...
> >     >
> >     >
> >     > Seems logical. But then you call determineUri everywhere? I guess
> we
> >     > could make it determineAndLoad(). :-)
> >     >
> >     > ---------------------------
> >     >
> >     > I had another idea on how to get rid of the proxy mess. I was going
> to
> >     > tell you about it later, as its aim was to get rid of the nasty
> lists
> >     > and determineUri mess, but it seems as though it would solve the
> proxy
> >     > problem as well. (Nice side effect!)
> >     >
> >     > The ResourceManagerPrivate has 2 sets of lists. I'm going to call
> them
> >     > INIT-LIST (m_initializedData) and the HALF-INIT list
> >     (m_uriKickoffData &
> >     > m_idKickoffData). Whenever a Resource is created by the RMP::data()
> >     > function, it checks if it is present INIT-LIST or HALF-init list,
> and
> >     > accordingly gives us a RD (ResourceData).
> >     >
> >     > A RD can go into the HALF-INIT lists in 4 ways - (look at
> >     determineUri)
> >     > --- KickOffId
> >     > ------- nepomuk://res/ stored as a string
> >     > ------- nao:identifier
> >     >
> >     > --- KickOffUri
> >     > -------- nie:url
> >     > -------- nepomuk://res/
> >     >
> >     > *Proposal :*
> >     > Remove the KickOffId completely. And make KickOffUri contain the
> >     > nao:identifier as well. When determineUri is being called, say
> >     > m_kickOffUri is the nepomuk resource uri, it should add itself to
> the
> >     > INIT-LIST and it should add all other ways of getting Initialized
> >     to the
> >     > HALF-INIT list ( nao:identifier and nie:url ) This way RMP:data()
> will
> >     > always returns the correct RD* and a proxy wouldn't be required.
> >     >
> >     > determineUri would be a lot simpler -
> >     >
> >     > if( m_kickOffUri.isValid() ) {
> >     >       // check for nepomuk://res/
> >     >       // check for nie:url and the filex crap which I don't
> understand
> >     > } else {
> >     >      // check for nao:identifier
> >     > }
> >     >
> >     > An additional thing we could do is to make removeProperty()
> >     removing the
> >     > corresponding RD from the HALF-INIT list if the property being
> removed
> >     > is nao:identifier or nie::url. (addProperty should check for the
> >     same)/
> >     >
> >     > I hope I've been clear enough.
> >     >
> >     > - Vishesh Handa
> >     >
> >     >
> >     >     Cheers,
> >     >     Sebastian
> >     >
> >     >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100525/c3ac4da4/attachment.htm