lwhay / asterixdb

Automatically exported from code.google.com/p/asterixdb
0 stars 0 forks source link

Disjunctive conditions in a sub query does not work #862

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
Download two attached files and execute AQLs in the disjunctive_AQL.txt file. 
It will show some results. FYI, the AQL is the same the below:

// Create a dataverse - deliber
drop dataverse deliber if exists;
create dataverse deliber;
use dataverse deliber;

// Dish served by a restaurant
create type DishesType as open {
    name: string,
    price: double
}

// Restaurant's information
create type RestaurantsType as open {
    restr_id: int64,
    name: string,
    address: string,
    bank_account: BankAccountType,
    last_bank_transaction_datetime: datetime,
    cuisine: {{ string }},
    dish: {{ DishesType }}
}

// Creating datasets for Users, Restaurants, and Orders
create dataset Restaurants(RestaurantsType)
primary key restr_id;

// Loading data into Restaurants dataset
load dataset Restaurants using localfs
    (("path"="127.0.0.1://./restaurants.adm"),("format"="adm"));

for $r in dataset Restaurants
where some $c in $r.cuisine satisfies $c = "Mexican" or $c = "Italian" 
order by $r.name
return {"name":$r.name, "cuisines":$r.cuisine}

-----------
What is the expected output? What do you see instead?
It needs to return a tuple that contains only "Italian" or "Mexican". However, 
it returns every row in a dataset.
(e.g., 
incorrect - { "name": "55 Done", "cuisines": {{ "American" }} }
correct - { "name": "Cit Spicy", "cuisines": {{ "Italian" }} }
) 

Original issue reported on code.google.com by wangs...@gmail.com on 10 Mar 2015 at 4:48

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for verifying and filing this, Taewoo!  A couple of notes.  First, if we 
can't fix it, we can always change our motto from "More Engine, Less Trunk" to 
something else, like "Satisfaction Guaranteed or Double Your Data Back!" More 
seriously, on the repro side, the query does the right thing if you remove the 
disjunction - so it's the disjunction that's the issue - correlated disjunctive 
subqueries are broken.  Also, thinking I was being clever, I tried rewriting 
this into a count-based subquery and checking for count > 0 - the system won 
the cleverness battle and gave the identical wrong answer to this.  So it's not 
just the existential predicate - it really seems to be disjunction related.  
@Yingyi, could you have a quick first peek? (I am thinking that you might spot 
something obvious there.  Also cc'ing Jules since he's dealing with 
subquery/related issues in his SQL++ work.

Original comment by dtab...@gmail.com on 10 Mar 2015 at 6:41