Error with all-any-atom cyclic query molecules

[James Davidson]

Hi,

I have found what looks like a bug with substructure queries for cyclic molecules that only contain query atoms.  I first noticed with a MOL query, but have reproduced here with SMILES in the interest of space:

select molregno from bingo_structures where

bingo_binary @ ('*1*******1','')::bingo.sub;

********** Error **********

ERROR: error: bingo: molecule search engine: error while matching binary target with ctid='(1977,3)'::tid: 

SQL state: XX000

Adding a single C into the ring system gives a successful query:

select molregno from bingo_structures where

bingo_binary @ ('*1***C***1','')::bingo.sub;

Total query runtime: 4631 ms.

24361 rows retrieved.

Kind regards

James

[Bingo 1.7.7.0 win64; postgresql 9.2]

[Mikhail Rybalkin]

Hello James,

Thank you for the bug report! We missed this case in our code and fixed it. The next version will be published on this week.

Best regards,

Mikhail

[Savelyev Alexander]

Dear James,

We have released the new Bingo version (1.7.8 b2). The issue with the
incorrect aromatization was fixed. Also, there is a new feature not to
create errors while matching a query (only warnings in the log). Thus,
user queries will not interrupt because of internal matching errors.
One more useful feature is multi-threading support for index building
(the feature increases index building speed, therefore it should be
useful for large databases) Thanks for the bug report again and let us
know if any issues appear.

With best regards,
Alexander

[James Davidson]

Great - thanks Alexander! Two quick (naive) questions - do I have to do anything special to invoke the multithreading for CREATE INDEX, and do any tables of bingo binary molecules (or corresponding indexes) need to be dropped/rebuilt between versions of the cartridge?

Kind regards

James

[Savelyev Alexander]

Dear James,

Let me answer from the end. No, there is no much difference between
the cartridge versions (1.7.7 and 1.7.8 b2), therefore you don't need
to rebuilt your tables. But be careful, if you run
bingo_uninstall.sql, all your indexes will be removed by PostgreSQL
automatically. Thus, all you need to do (if you want to save indexes)
is to close all client sessions, replace bingo_postgres.dll (or .so)
by the newest version and restart the database. Next, you don't have
to do anything special to invoke the multithreading for the index
creating. You need only launch the default CREATE INDEX query. You can
see the full core's loading(please, let us know if not) in the task
manager (or any other utility).

With best regards,
Alexander

[James Davidson]

Hi Alexander,

I just tried a manual drop of the bingo schema (actually a delete/drop cascaded due to errors with dependencies) in one database, and have found that I cannot now successfully run the bingo_install.sql.  I see the following error:

psql:bingo_install.sql:853: ERROR:  duplicate key value violates unique constrai

nt "pg_am_name_index"

DETAIL:  Key (amname)=(bingo_idx) already exists.

I also cannot run the bingo_uninstall.sql now that I have dropped the bingo schema.  I expect that I can work around this with a bit of looking through bingo_uninstall.sql, but wanted to post this in case it is a general problem for others(?)

Kind regards

James

[Savelyev Alexander]

Hi James,

Thanks for reporting the problem but it is not a general issue. If you
open bingo_uninstall.sql, you can see the following sql:

BEGIN;
drop schema bingo cascade;
delete from pg_am where amname='bingo_idx';
COMMIT;

There is a transaction of dropping schema and removing a row from the
pg_am table. So if you manually drop schema, you perform a first step
(of two) to remove bingo from the database. You need only remove the
row from 'pg_am' to process the complete uninstalling. Therefore, you
need to specify a unique schema name while the bingo install (there is
a schema uniqueness validation in sql script)

With best regards,
Alexander