models: add override column

[jacquerie]

Here's what I meant in #72 (comment): it's not the most elegant solution, but it's a pragmatic one.

Adding a new column requires a new Alembic recipe, which is still missing from this PR, but I wanted to have an external opinion before continuing.

[jacquerie]

Here's one reason I don't like PEP8's 79 characters hard limit... : )

[lnielsen]

I fine with the solution in this PR, I just want to highlight a similar problem in OAIServer which may or may not work in this case (and I'm not sure how much work it would be to adapt the code).

In Invenio-OAIServer, for some OAI-PMH setspecs we just want to put them manually into _oai.sets and ensure the system doesn't mess them. Example is e.g. Zenodo, where we on publish time knows exactly which OAI sets a record belongs to based on community memberships, hence it's waste to have to wait for a async process to run a query and update the record with another revision when we already know the information upfront.

The way it works in OAIServer for a setspec you want to manage manually is that you simply set the dbquery to an empty string, and then the system won't mess with the set. If a record is in an OAI setspec it will stay there, if it's not there it won't be added unless you do it yourself.

Regarding this PR, then the only thing I'm struggling a bit with is the name override that I don't think captures what the flag really means (or I don't understand the existing code, which is very likely :-))

[jacquerie]

Regarding this PR, then the only thing I'm struggling a bit with is the name override that I don't think captures what the flag really means

I don't like either, but it's the best I could come up with while rubber ducking a colleague... What I meant to say is "skip checking if the record matches the query and assume that it does", not unlike your OAIServer use case. That is, I thought, "override" the query. I also thought about "skip", but didn't like it because one might think that it means "skip adding this collection", not "skip running this query". "skipmatching" is clearer, but quite awkward...

[tiborsimko]

@jacquerie What about dbquery_skip or dbquery_skip_check or allow_dbquery_skip or something along these lines? Or even dbquery_override? Sounds a bit more explicit in this way, so it would be probably enough to clear usage doubts here... However, seeing such a field getting introduced may still feel kinda weird... referring to your elegance vs pragmatism musings.

[jacquerie]

I like dbquery_skip !

However, seeing such a field getting introduced may still feel kinda weird... referring to your elegance vs pragmatism musings.

Would you rather do something like

for name, data in iteritems(collections):
    if data['query'] == '' or _build_query(data['query']).match(record):
        yield data['ancestors']

where we currently have

invenio-collections/invenio_collections/receivers.py

Lines 68 to 70 in 3105405

	for name, data in iteritems(collections):
	if _build_query(data['query']).match(record):
	yield data['ancestors']

?

[jacquerie]

Wait, both approaches won't work! They would just add ALL the collections to ALL the records...

[jacquerie]

This proved to be too complicated to implement correctly and with the minimal impact to invenio-collections, so we're going with the route outlined in inspirehep/inspire-dojson#62.