[Nepomuk] Nepomuk Core - Questions & Patches
Sebastian Trüg
trueg at kde.org
Tue May 25 19:48:40 CEST 2010
Hi Vishesh,
no, I do not want to keep determineUri. That is the whole point. And why
is it buggy?
Cheers,
Sebastian
On 05/25/2010 07:36 PM, Vishesh Handa wrote:
>
> Hey Sebastian
>
> On Mon, May 24, 2010 at 4:43 PM, Sebastian Trüg <trueg at kde.org
> <mailto: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>>
> > > <mailto: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
> > >
> > >
> >
> >
>
>
More information about the Nepomuk
mailing list