Error using UpdateHandler (probably configuration)

I'm doing some refactoring, and so have two extremely similar versions of the same routine, which does very little of interest except insert a structure into a JChem structure table. They are not currently targeting the same table, but I am inserting the same structures, and in one case it works, and the other I get the error below:





java.lang.NullPointerException


at chemaxon.reaction.Standardizer.standardizeComponent(Standardizer.java:1281)


at chemaxon.reaction.Standardizer.standardize(Standardizer.java:1371)


at chemaxon.jchem.db.TableInfo.standardize(TableInfo.java:1092)


at chemaxon.jchem.db.UpdateHandler.init(UpdateHandler.java:762)


at chemaxon.jchem.db.UpdateHandler.execute(UpdateHandler.java:1409)


at com.nrgn.core.JChemRepository.insertStructure(JChemRepository.java:169)


at unitTest.com.nrgn.core.SaltStructureRepositoryTest.testInsertStructure(SaltStructureRepositoryTest.java:350)





I assume there's some minor difference either between the way the tables are set up or between the two subroutines, but with an error that deep into library code, I really haven't the foggiest idea where to start looking. Any suggestions?





This is using JChem 3.1.4 (probably relevant) and Oracle 9 (probably not).

Quote:

This is using JChem 3.1.4 (probably relevant)

I would say essential :)





After some investigation it seems there is a problem with specifying the structure to insert. The Molecule object that stores the structure is null, and by sheer luck this problem only surfaces in a deeper level in the code.





1. Please check you specify the structure correctly and it's not null


2. If #1 does not help please copy here the relevant code where you specify the structure (and check the value of the arguments).





Best regards,





Szilard

Well, I went in and added some trace statements, and didn't get any less confused--the molecule is non-null, and appears to contain a valid structure (I dumped out the formula and MW, just to make sure there was somebody there). I did find a way to make the problem go away, however: if I change

Code:

uh.setInputMolecule(mol);

to

Code:

uh.setValuesForFixColumns(mol.toFormat("mol"));

then the function completes normally. Seems strikingly inelegant, however. Is that what I have to do, or is this indicative of some other problem with the way I'm setting things up? I'm getting the molecule object from a MolHandler, using the structure (a MOL formatted string) passed to the function:

Code:

mh = new MolHandler(sdf); Molecule mol = mh.getMolecule();

Hi,





UpdateHandler.setInputMolecule() is only for speeding up things if you already have the Molecule object to spare an other conversion.


However, you must specify the structure as a String either way, as a string must be inserted into the cd_srtucture column as the original structure string.





We will make this clearer in the API, and also throw a more readable exception (if we don't already ... 3.1.4 is really an old version, I suggest an upgrade any way)





If you only have a Molecule object, then one should use Molecule.toFormat(), although using the "mrv" format is better, since this format can also store all Daylight features as well.





As you create the Molecule from a String, you should specify that very String instead. If you do not use the Molecule for anything, you should only specify the String.





Note: Please do not modify the Molecule object in any way, the Standardization should be performed automatically according to the table options.





Best regards,





Szilard

Szilard wrote:

Hi, UpdateHandler.setInputMolecule() is only for speeding up things if you already have the Molecule object to spare an other conversion. However, you must specify the structure as a String either way, as a string must be inserted into the cd_srtucture column as the original structure string.

Ah, I see. That would do it. Thank you!

Quote:

We will make this clearer in the API, and also throw a more readable exception (if we don't already ... 3.1.4 is really an old version, I suggest an upgrade any way)

I'd love to upgrade, but I'm somewhat afraid to deal with it--we've just lost a lot of technical staff, here (including the person who would normally be coordinating that upgrade), and I'm not sure how much time and effort we can afford to put into that right now. I'll bring it up with the relevant managerial types, though.

Quote:

As you create the Molecule from a String, you should specify that very String instead. If you do not use the Molecule for anything, you should only specify the String. Note: Please do not modify the Molecule object in any way, the Standardization should be performed automatically according to the table options.

This is an interesting point. We are in fact doing something with the molecule (changing the aromatization, and running a 2-D clean if it came in as a smiles string), which is why the original string isn't getting passed in. I'll have to look into that. Though that also falls in the "if it ain't broke" category of maintenance, which as noted I'm a little leery of taking on at the moment.





Thanks again!

Quote:

We are in fact doing something with the molecule (changing the aromatization, and running a 2-D clean if it came in as a smiles string), which is why the original string isn't getting passed in.

In this case you should create a String from the Molecule again (via Molecule.toFormat()) opposed to inserting the original string.


Otherwise the string and the Molecule might differ.


In this case the search works with data calculated using the modified Molecule. If the table is re-generated (e.g. during upgrade), the calculations will use the original string stored in cd_structure : you may get different hits for the same query.





But maybe there is no real need for you to manipulate the structure before import:





From the search point of view you can control the aromatization method by specifying a a Standardizer XML at table creation or re-generation.


(in the JChemManager GUI or in jcman command-line)


The only difference is that actions performed by the table standardization rule are only "visible" to the search process, the original structure will be stored in cd_structure and displayed.





Cleaning is only important if you are not using MarvinView for display - otherwise Marvin cleans the 0D structures on display aromatically.








Best regards,





Szilard

Problem successfully resolved. Thank you! As it happens, we don't apply this particular set of standardizations to all input structures (only the ones that come in as SMILES), and we do sometimes use something other than MarvinView to display the structures, so it looks like the current technique will have to stay, at least for this system. Just as well--one more thing that we could change but don't really need to change, I can happily do without.