So another interesting case, as far as I can understand tables with two or more

required

columns, indeed require all of them in a WHERE clause? Though testing

select * from extended_attributes where path = '/usr'

works fine, though

select * from extended_attributes directory = '/'

gives an empty result (but if we confront the result from the first query, directory is '/'). So either way I would expect both query to fail, due to the

required

, or both to succeed and return something.

That's an unusual case, and I'm not sure how to handle it. Required can't be optional, and have to be specified. Perhaps they should all just be INDEX and let the tables return empty if one of the required constraints isn't present.

On the documentation we say "This will create a warning if the table is used and the column does not appear in the predicate.", though it's not clear what happens with the results indeed. Currently if I give no required columns I get the error "Error: no query solution". I would expect to get that until I put both required columns.

I'll take a look

ok! no sweat! I just noticed it because I was writing missing examples queries from the tables 🙂

okay, so the code looks right. If any of required constraints are provided, it proceeds without error. A table like hash for example, file OR directory are required. use one or the other or both.

ok, so they aren't all required. Next thing, most likely minor, is that when no constraint is put, you don't get that warning; probably because it's failing earlier in the logic?

Does it give a SQL error ? something like constraints not satisfied ?

it returns with

Error: no query solution

it seems to vary depending on SQLite version

mmm... that might end up being a bit confusing.

np. I'll try to look into the error codes later in the week