Issue:

Issues with Learning DB – unable to successfully Learn the database due to old fields in the Database

Applies to v3.0.2.0

Note: This is a known Issue when working with FuzzyDB.

When trying to learn new field types for the FuzzyDB extraction, users will sometimes get an error stating that Ephesoft was not able to successfully learn the Database. This is due to fields from previous batches are still present in the table responsible for learning the Database for ephesoft. This table name is batch_class_dynamic_plugin_config. When a Batch Class or Doc type is deleted these old fields are still kept in the database. When the Learn DB button is pressed Ephesoft applies the Database Learning to all Batch Classes, including the deleted ones and causes the error to occur.

Sample Error:

2013-02-25 12:36:16,190 ERROR http-8080-3 org.hibernate.util.JDBCExceptionReporter – Invalid column name ‘Address1’.

2013-02-25 12:36:16,190 ERROR http-8080-3 org.hibernate.util.JDBCExceptionReporter – Invalid column name ‘Address2’.

2013-02-25 12:36:16,190 ERROR http-8080-3 org.hibernate.util.JDBCExceptionReporter – Invalid column name ‘PostalCode’.

2013-02-25 12:36:16,190 ERROR http-8080-3 org.hibernate.util.JDBCExceptionReporter – Invalid column name ‘City’.

2013-02-25 12:36:16,190 ERROR http-8080-3 org.hibernate.util.JDBCExceptionReporter – Invalid column name ‘PhoneNumber’.

2013-02-25 12:36:16,190 ERROR http-8080-3 org.hibernate.util.JDBCExceptionReporter – Invalid column name ‘State’.

2013-02-25 12:36:16,190 ERROR http-8080-3 org.hibernate.util.JDBCExceptionReporter – Invalid column name ‘BusinessUnitName’.

2013-02-25 12:36:16,191 ERROR http-8080-3 com.ephesoft.dcma.fuzzydb.service.FuzzyDBSearchServiceImpl – Uncaught Exception in learnDataBase method could not execute query

Solution:

Manual workaround:

· Delete all such entries from the database. Follow the below instructions for doing that. NOTE: Queries are My SQL specific

· For deleting invalid entries for a deleted document type:

· Get the batch class dynamic plugin config id for those document types.

· select batch_class_dynamic_plugin_config.id from batch_class_dynamic_plugin_config where batch_class_dynamic_plugin_config.config_name = ‘document.type’ && batch_class_dynamic_plugin_config.config_desc in (<COMMA SEPARATED LIST OF SUCH DOC TYPES>);

· e.g. select batch_class_dynamic_plugin_config.id from batch_class_dynamic_plugin_config where batch_class_dynamic_plugin_config.config_name = ‘document.type’ && batch_class_dynamic_plugin_config.config_desc in (‘abc’,’xyz’);

· e.g. if the query returns “id: 11,12” as result.

· Delete all the children of these configs.

· delete from batch_class_dynamic_plugin_config where batch_class_dynamic_plugin_config.parent_id in (<Comma separated list of id’s returned by 1st query>);

· e.g. delete from batch_class_dynamic_plugin_config where batch_class_dynamic_plugin_config.parent_id in (11,12);

· Delete the actual dynamic configs.

· delete from batch_class_dynamic_plugin_config where batch_class_dynamic_plugin_config.id in (<Comma separated list of id’s returned by 1st query>);

· delete from batch_class_dynamic_plugin_config where batch_class_dynamic_plugin_config.id in (11,12);

· For deleting invalid entries for a deleted field type:

Delete all such field type entries:

· select batch_class_dynamic_plugin_config.id from batch_class_dynamic_plugin_config where batch_class_dynamic_plugin_config.config_name = ‘ field.type’ && batch_class_dynamic_plugin_config.config_desc in (<COMMA SEPARATED LIST OF SUCH FIELD TYPES>);

· select batch_class_dynamic_plugin_config.id from batch_class_dynamic_plugin_config where batch_class_dynamic_plugin_config.config_name = ‘ field.type’ && batch_class_dynamic_plugin_config.config_desc in (‘field1’,’field2’)

Following these steps you can eliminate unnecessary fuzzy mappings.

Automatic workaround:

Adding the functionality to remove the Batch class dynamic plugin configs of a document type/field type whenever it is removed. This change will take care of the situation that you don’t have to manually un-map the fuzzy mappings upon a change in the document type.

 

We have implemented the automated fix which will cater such a situation and will make sure to remove any such mappings in future but we’ll have to follow the manual workaround for any such backlog entries.

Please find the fix for this issue in the following link. This fix is for 3.0.2.0 SP3 and above.

Download

NOTE: Please be sure that whenever you remove/change your fuzzy table outside the application, you also set the mappings accordingly.

learndb

Was this article helpful to you?

Walter Lee