should study.exists check by id?

[antgonza]

Currently you instantiate a study by Study(id_) but you check if a study exists by Study.exists(study_title), which is confusing. What we want to do? Everything by id_, study_title or both (exists_by_id).

[josenavas]

My vote goes to both, because we have said that cannot be duplicate study titles on the DB.

[wasade]

Could we just get rid of the ID then? If the study title is a natural
primary key then there isn't a need for both, right?

On Sun, Apr 19, 2015 at 2:04 PM, josenavas notifications@github.com wrote:

My vote goes to both, because we have said that cannot be duplicate study
titles on the DB.

—
Reply to this email directly or view it on GitHub
#1078 (comment).

[antgonza]

Not sure. I agree on the idea but in practice having FKs to the full name might not be ideal. BTW having unique names is great!

[squirrelo]

I agree unique names are great. For this issue, however, if you look at Job and Reference objects you see that exists should never take an ID. What exists does is check, given the data it takes in, whether something already exists with that data. This Study exists is consistent with that philosophy.

[josenavas]

That is a great point @squirrelo
The exist was used to avoid data duplicates in the DB, e.g. avoid running 2 jobs that have been applied with the same options on the same data; similarly it is used to avoid 2 studies with the same name. In some other cases, like RawData is tricky to use, probably we can use md5 sums to check if it exists or not.

That being said, I think the current implementation follows the expected behavior and this is correct. If any function needs to check for the id, it can use the private function _check_id implemented in the base class.

[antgonza]

Closing as it seems that we agree that the current implementation is fine.