Hi Peter!
Peter Ansell wrote:
> Hi Nathan,
> ----- Original Message ----
>> From: Nathan <[email protected]>
>> To: Virtuoso Users List <[email protected]>
>> Sent: Mon, 1 March, 2010 11:30:58 AM
>> Subject: [Virtuoso-users] Error reports
>>
>> Hi All,
>>
>> Just a quick update on some "new to me" errors;
>>
>> 40001 Error SR172: Transaction deadlocked
>
> I used to get this regularly for SPARUL queries before I added "define
> sql:log-enable 2" in front of all my SPARUL queries. Virtuoso can't handle
> multiple concurrent SPARUL queries without changing the transaction logging
> method as far as I know. I haven't seen the issue since I made that change.
cheers - I'll give it a go!
>> and another one (which i lost) which basically said "Generated SQL more
>> than 10000 lines" which I was getting frequently when SPARUL inserting
>> 2000-5000 triples; I've since lowered all sparul queries to be max 1000
>> triples and never seen the error since :)
>>
>> and finally, noticed more odd behaviour with in(), along the lines of
>> the transitive errors I was getting where in() basically set params to a
>> single value; as follows:
>>
>> select * where {
>> {
>> {
>> select distinct ?L1 count(?x1) as ?votes where {
>> u:49991734 t:following ?x1 . ?L1 t:following ?x1
>> }
>> group by ?L1 order by desc( ?votes ) LIMIT 500
>> }
>> FILTER( <http://bit.of/an/error> in( ?L1 ) )
>> }
>> }
>
> Why do you need to test whether a constant is the same as a parameter using
> in()? I am not saying it isn't a bug but as far as I know you can say
> FILTER(?L1 = <http://bit.of/an/error> ) and get the right result. I wouldn't
> have even been aware that you could use parameters in IN() if you hadn't of
> given that example.
>
> Does the following work or is it a different query? FILTER( ?L1 in(
> <http://bit.of/an/error> ) )
doesn't matter which order you put them in, or whether its a constant or
a variable or "whatever", it'll always reset ?L1 (or any variable) to
the value you're comparing against - thankfully in 95% of cases it can
be re-written differently; however I have came across some queries
(which the team are aware of) that cannot be written without in().
ps: i checked again and flipping the params still brings up the same
problem.
do note that it's only under specific circumstances, the rest of the
time IN() works fantastically :)
regards!
