data_dictionary_builder.php unique constraint fix

[laemtl]

Fix the data_dictionary_builder.php script
by enforcing the unique key constraint Name + SourceFrom.
by reducing the scope of the main query to instruments. Instruments have unique parameter names, and the script is intended to build a dictionary for instruments.

Error below was encountered with EEG/MRI parameter_file fields.

Error seen when 2 parameter_type entries share the same Name:

lorisadmin@smathew-dev:/var/www/loris/project/tools/exporters$ php data_dictionary_builder.php
Could not execute Select Name, ParameterTypeID from parameter_type. Stack trace#0 /var/www/loris/project/tools/exporters/data_dictionary_builder.php(60): Database->pselectColWithIndexKey()
#1 {main}
PHP Fatal error:  Uncaught DatabaseException: The uniqueKey supplied to pselectColWithIndexKey() does not 
                    appear to be unique or is nullable. This function expects the 
                    key to be both UNIQUE and NOT NULL. in /var/www/loris/php/libraries/Database.class.inc:971
Stack trace:
#0 /var/www/loris/project/tools/exporters/data_dictionary_builder.php(60): Database->pselectColWithIndexKey()

[sruthymathew123]

Tesed and looks good

[ridz1208]

@laemtl what is the usecase here? In my DB, the Name parameter includes the "sourceFrom" basically on my end Name = sourcefrom+sourcefield

[laemtl]

@ridz1208 Some EEG/MRI pipelines use parameters with the same Name, different SourceFrom since they both import BIDS file parameters. We experienced this issue on HBCD.

I guess it's all about how the different pipelines will decide to name the parameters but our only uniqueness guarantee is the one enforced by the db (Name + SourceFrom)

[ridz1208]

@driusan I think the better fix here would be to make sure this script is looking at instrument fields in parameter_type. What do you think?

[driusan]

I still don't understand. There are 2 issues:

1. What do EEG/MRI pipelines have to do with this script? This script parses and generates parameter_type entries for the Instruments category and pipelines shouldn't be categorized as Instruments.
2. I don't see why the the constraint is (SourceFrom, Name) in the parameter_type schema. That change appears to have been introduced without explanation in PR#7503 (which only talks about the same parameter being duplicated across different IDs, not different IDs having the same name.) "SourceFrom" is just a table name for the "SourceField" which is a field name database field name. They have nothing to do with the name (other than the name sometimes being derived from the table/field name for instruments.) SourceFrom is not a pipeline name which it seems like is being incorrectly assumed here.

[cmadjar]

@driusan in the PR description you mention, it is written that this was discussed during a roadmap meeting so this does not come out of nowhere ;).

How do you categorize things as instrument in the parameter_type table? Maybe from the sourceFrom, if the sourceFrom comes from an instrument table, then build data dictionary?

[cmadjar]

@driusan also, sourcefrom is linking to parameter_file in the case of MRI and physiological_parameter_file tables in the case of EEG. So there are no pipeline names specified in this field but tables used by the imaging pipelines. Maybe the phrasing caused some confusion.

[laemtl]

@cmadjar We can join the table parameter_type_category to filter the instruments.

[laemtl]

@driusan

What do EEG/MRI pipelines have to do with this script? This script parses and generates parameter_type entries for the Instruments category and pipelines shouldn't be categorized as Instruments.

Current script implementation does not distinguish instruments vs other parameters in the first query that collects all the parameters, so the first select in the script is failing since we use pselectColWithIndexKey with a non unique key. This is as far as EEG/MRI is involved.