Opened 9 months ago

Closed 9 months ago

#1343 closed defect (fixed)

Rasql_Slicing error with multiple slices expression

Reported by: bphamhuu Owned by: gmerticariu
Priority: major Milestone: 9.3
Component: rasql Version: development
Keywords: Cc: dmisev, vmerticariu
Complexity: Medium

Description

the slice expression in WCPS: slice(COVERAGE, {interval})

here is the result from WCPS 1.0, WCPS 1.5 and Rasql (3D -> 2D -> 1D)

for c in (eobstest) return encode(slice(c[t(0:5), Lat(25:70), Long(30:60)], {t(0)}), "csv")
WCPS 1.0
select csv((c) [0,10:70,11:101]) from eobstest AS c where oid(c)=1537
WCPS 1.5
SELECT encode(c[0:5,30:60,25:70][0,30:60,25:70], "csv" ) FROM eobstest AS c


for c in (eobstest) return encode(slice ( slice(c[t(0:5), Lat(25:70), Long(30:60)], {t(0)}), {Lat(30)} ), "csv")
WCPS 1.0
select csv((c) [0,10:70,91]) from eobstest AS c where oid(c)=1537
WCPS 1.5
SELECT encode(c[0:5,30:60,25:70][0,30:60,25:70][30:60,30], "csv" ) FROM eobstest AS c

According to Vlad, WCPS 1.0 returns wrong result, WCPS 1.5 return correct result, however it has error in Rasql:

rasql -q 'SELECT c[0:5,30:60,25:70][0,30:60,25:70][30:60,30] FROM eobstest AS 'c
rasql: rasdaman query tool v1.0, rasdaman v9.2.1-gff4f8d4 -- generated on 10.05.2016 14:57:56.
opening database RASBASE at localhost:7001...ok
Executing retrieval query...rasdaman error 362: 
Execution error 362 in line 1, column 8, near token c: 
Specified domain dimensionality does not equal defined dimensionality of MDD.
aborting transaction...ok
rasql done.

Change History (7)

comment:1 Changed 9 months ago by dmisev

Ok that is a bug in rasql indeed.

comment:2 Changed 9 months ago by dmisev

  • Milestone changed from 10.0 to 9.3
  • Priority changed from major to critical

comment:3 Changed 9 months ago by dmisev

  • Owner set to gmerticariu
  • Status changed from new to assigned

George, can you please have a look at this issue? It's critical for the release of WCPS 1.5.

comment:4 Changed 9 months ago by dmisev

The error is thrown in source:qlparser/qtvariable.cc (line 258)

comment:5 Changed 9 months ago by vmerticariu

Ok, George found the problem and fixed it for now (patch is being submitted), however we will have to revisit this at some point.

The issue is in optimize load, which was designed with a single subset application in mind.

For example, if c is a 3d object, c[0,0:100,0:100] will have a loadDomain of [0,0:100,0:100] so only this data is read from disk.

With the current implementation, optimizeload() ignores any subset interval if one is already set for the current node.
So c[0, 0:100, 0:100][0:10,0:10] will start evaluation with [0:10,0:10]. It sets the loadDomain to [0:10,0:10] then moves on to [0,0:100,0:100]. It sees that a subset is already set for the node and ignores the new one, so the loadDomain stays [0:10,0:10]. When trying to load c[0:10,0:10] an error occurs since c is 3d.

What George did is to change optimezeload() to consider the latest domain only, instead
of ignoring it.

So c[0,0:100,0:100][0:10,0:10] will now have a loadDomain of [0,0:100,0:100]. So the data at this domain is now read into memory, then [0:10,0:10] is applied on it. This works, but is not optimal. In a future iteration, the loadDomain can be considered the intersection of all domains, so c[0,0:10,0:10] only is loaded into memory. This however means modifying the tree to remove subsequent domain operations.

Anyway, now it works. It is optimal for a single subset application, and non-optimal for cascading operations (in that it loads the data indicated in the first subset, then it trims it accordingly to the following ones).

comment:6 Changed 9 months ago by dmisev

  • Priority changed from critical to major

It's good enough for now, and WC(P)S has been updated to merge the subsets so it only generates a single subset.

comment:7 Changed 9 months ago by gmerticariu

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.