Another weird backtrace related to cover drawing

[Daniel Winter]

On Tuesday 22 July 2008 18:22:25 Maximilian Kossick wrote:
> We can easily get rid of BlockingQuery inside SqlMeta by using sql
> directly, the queires aren't complicated after all. I'm not sure about
> Nepomuk.

Would be possible, but I do not really like that idea of spreading sparql 
querys all over the place. 

That will make changes in the future a lot of extra work. (Also I am planing 
to use lucene Querys where possible to). The thing is SPARQL is not good 
enough to support all possible needed querys (or some are slow there). So only 
make the needed changes at one place. 

The same applies for the SQL Collection. When for some reason the DB structure 
changes it will be much easier (and propably with less bugs in the meantime) 
to make the switch only in the QueryMaker.

Also I believe there are other places where something like a BlockingQuery is 
needed. Scripts for example or Dynamic Playlists could need them. (aren't the 
biased playlist using them?)

If the BQ could not be fixed (do not know enough about the workings of the Qt 
event system),  I would propose a workaround by changing the QueryMaker Api.

a new method  
void QueryMaker::blocking( bool )  (witout calling it, it is non blocking,  
with true the QueryMaker itself will block).

and
DataList QueryMaker::results( void )  to get the result in that case.

Sure that would mean to change all QueryMakers, but in terms of code reuse and 
also just to have that feature it would be a better solution in the longterm. 
(if bq can not get fixed)

DanielW