PR# 15470 EiffelStore's hashtable key comparison fails due to '~' operator

Problem Report Summary
Submitter: bherlig
Category: EiffelStore
Priority: Medium
Date: 2009/03/06
Class: Bug
Severity: Critical
Number: 15470
Release: 6.4.7.7440
Confidential: No
Status: Closed
Responsible:
Environment: EiffelStudio: 6.4.7.7440 OS: Kubuntu 8.10, 32bit DB: MySQL, Ver 14.12 Distrib 5.0.67, for debian-linux-gnu (i486) using readline 5.2
Synopsis: EiffelStore's hashtable key comparison fails due to '~' operator

Description
As stated in the Release notes to release 6.4.7.6313, using the '~' operator in EiffelBase breaks the hashtable mechanism used in EiffelStore.

The mapping mechanism (e.g. feature `set_map_name' in class STRING_HDL used by DB_SELECTION) for parametrizing SQL queries uses a hashtable for holding key-value pairs. Upon retrieving these mapped values when building the SQL-query (feature `replacement_string' in class SQL_SCAN), the default key-comparison using `same_keys' fails because it compares a STRING to a DATABASE_SELECTION[ODBC] (as i use ODBC) object. Mappings do not get inserted properly, and are replaced in the query by "NULL". 
Thus, queries like
  "SELECT * FROM :table_name"
get changed to
  "SELECT * FROM NULL"


I provided a minimal invasive patch for this bug for your consideration. It changes the call for retrieving the hashtable's item by creating a new, proper STRING instead of using the subclass DATABASE_SELECTION[ODBC].
To Reproduce
1. Setup a database and enter some values
2. Connect using EiffelStore
3. Retrieve the previously entered values by using the mapping-mechanism, e.g. 
	l_selection.set_map_name (an_id, "id_map")
	create l_query.make_from_string ("SELECT * FROM `test_table` WHERE id=:id_map")
	l_selection.query (l_query)
4. inspect the retrieved data


Note: Attached (in the "src" subfolder) is a small program presenting the bug, follow the instructions in the README to setup the application.
Problem Report Interactions
From:manus_eiffel    Date:2009/03/06    Status: Closed    Download   
Fixed in rev#77622.

From:manus_eiffel    Date:2009/03/06    Status: Analyzed    Download   
Thanks for providing the patch. Unfortunately, I'm not sure it is sufficient because you do not have a guarantee that items inserted in the HASH_TABLE are always of type STRING. I'm proposing a different patch which will simply use `same_string' rather than `~' for comparing STRING objects all the time.

The benefit is that is should as efficient as the original solution (no need to create a temporary object for lookup.

The next 6.4 release will have the patch included. Let me know if it also works for you.

From:bherlig    Date:2009/03/06    Download   
Attachments for problem report #15470

Attachment: EiffelStore_Bugreport.tar.gz     Size:3204