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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> 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 > > > > > > > > > > > > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
