Return multiple in silico properties in one SQL

I wonder





1. If one can calculate boths LogP and PSA for a smiles in one SQL. E.g., return both values in a comma-separated string, so that we only need to construct the molecule object once in the backend.


Normally we do


select jc_evaluate(smiles, 'LogP') from dual


and select jc_evaluate(smiles,'PSA') from dual and pass the same smiles to the SQL twice.





I am going to calculate multiple properties for a large set of smiles, so try to speed up the calculation.





2. If one can obtain similarity score during a similarity search without calculating the score twice


Normally we do


select jc_tanimoto(db_smiles, query_smiles) as Score,Structure_ID from Structure where jc_tanimoto(db_smiles, query_smiles)>0.9


But this does the jc_tanimoto twice, seems to be a waste.





Thanks.

Quote:

select jc_evaluate(smiles, 'LogP') from dual select jc_evaluate(smiles,'PSA') from dual

The only thing I can think of right now is that we create a new operator which accepts multiple chemterm expressions and returns multiple results. Something like:

Code:

select jc_evaluate_m(smiles, 'LogP, PSA') from dual

But I am not sure about the return type. This kind of function could return one row for each of the CT expressions (two rows for the example above), but then this would prevent us from using the operator on tables. As another option, the function could return one varchar row for all of the CT expressions in its arguments with the individual results in each returned row separated by some character. But this kind of return value would be awkward to handle.

Quote:

select jc_tanimoto(db_smiles, query_smiles) as Score,Structure_ID from Structure where jc_tanimoto(db_smiles, query_smiles)>0.9

There is a feature in the Oracle Cartridge framework called "ancillary data" which appears to do (via an ancillary operator) what you would like to have. I will check if we can support this feature. I would be cautious to promise for sure that we will support it, because my experimentation with similar features (based on passing along the state of the index scan context) are not positive (they simply do not work).





Peter

What about supporting a chemterm such as





double2string(logP())+":"+double2string(PAS(), format="%.2f")+":"+integer2string(hdonor())





Then the user is expected to parse the return string himself, because that's what he asked chemterm to calculate in the first place.

We will investigate the available options and get back to you as soon as we made up our minds.





Peter