[Nepomuk] Nepomuk Core - Questions & Patches
Vishesh Handa
handa.vish at gmail.com
Tue May 25 20:40:53 CEST 2010
Hey Sebastian
On Tue, May 25, 2010 at 11:18 PM, Sebastian Trüg <trueg at kde.org> wrote:
> Hi Vishesh,
>
> no, I do not want to keep determineUri. That is the whole point. And why
> is it buggy?
>
>
Minor things.
1. If I call Resource( QString("file:/whatever") ) and whatever is actually
a filex:/ url. It won't get identified, cause the filex:/ searching is only
applicable to QUrls.
2. Code like this is perfectly legal, and works (no modifications required)
Resource r1( KUrl("nepomuk:/res/blah-blah") );
r1.setRating( 5 );
qDebug() << r1.rating();
This is because determineUri() accepts uris whose scheme is "nepomuk", but
don't really exist in the database. Should this be allowed?
3. When checking if the the m_kickoffUri is a nie:url for a resource. The
nieUrl is assigned to be equal to the uri. This however gets fixed in the
load(). And nieUrl isn't used anywhere, so it doesn't matter that much.
-----------
I'll start combing them ( The code becomes ugly! :-( )
- Vishesh Handa
> 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
> > > >
> > > >
> > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100526/086e945f/attachment-0001.htm
More information about the Nepomuk
mailing list