MySQL Bugs: #6626: Configuration Wizard does not prompt for datadir path

Bug #6626	Configuration Wizard does not prompt for datadir path
Submitted:	15 Nov 2004 8:43	Modified:	17 Aug 2017 8:18
Reporter:	Tom Metro	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S4 (Feature request)
Version:	4.1.7	OS:	Windows (Windows XP)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
The MySQL Server Instance Configuration Wizard on Windows does not prompt the user for the datadir path. It only prompts for the innodb_data_home_dir.

How to repeat:
Run Configuration Wizard.
Choose these options:
  Detailed Configuration
  Developer Machine
  Multifunctional Database

Observe that you are prompted to enter:
  InnoDB Tablespace Settings
but not the path to the MyISAM databases.

Suggested fix:
Prompt the user for the path to the MyISAM databases.

Thanks for reporting. But this behaves as planned. 

We tried to keep the Configuration Wizard as simple as possible. As the InnoDB engine is the default in most setups we decided not to present another dialog to the user prompting for the MyISAM data directory (since a new user doesn't know the different engine types during the first installation).

I realize that this may a problem on some machines. Would it be sufficient to introduce a checkbox where the user can decide to have the MyISAM data path be the same as the InnoDB data path in your case? What we cannot do is to add a new page just for the MyISAM data path. But we could add the checkbox easily.

Thanks.

Michael G. Zinner writes:
> We tried to keep the Configuration Wizard as simple as 
> possible. As the InnoDB engine is the default in most 
> setups we decided not to present another dialog...

OK, I can see the logic in that...although let me point out some flaws in it.

When I first ran through the Wizard and was faced with the "InnoDB Tablespace" question, my first thought was "why is this different from where I currently have my data files?" "Does it need to be different for some reason?"

So I ended up setting it to a different path.

Then on later inspection of my old data directory, I realized that InnoDB files were already stored in the root of my MySQL data directory.

Which leads me to ask, why prompt for this at all? Shouldn't the general case be to specify the location of the datadir  directory, and the advanced (non-Wizard) case be where an admin wants to separate the location of the two database types (in which case he can modify the config file directly to specify a different location for InnoDB)?

It seems that as long as the Wizard allows the selection of a "Multifunction" scenario, where both database types are possible, the Wizard must prompt the user for the datadir  directory, if anything. (Whether that one path is used for both types, or you prompt for two separate paths, is beside the point, though I agree that the simpler case where you just prompt for one data path is preferable. Of course the other scenario is you don't prompt for neither, and consider setting either path to be an advanced operation.) As it is now, an admin might discover, much to their surprise, that the 'data' subdirectory off of the server's install directory is filling up with data. Even though they thought they specified the data should go elsewhere.

> (since a new user doesn't know the different engine types 
> during the first installation)

Agreed. But you essentially violate your own rule by prompting them specifically for "InnoDB Tablespace," rather than just a general database storage location.

> Would it be sufficient to introduce a checkbox where the 
> user can decide to have the MyISAM data path be the same 
> as the InnoDB data path in your case?

Unless there is a technical reason otherwise, I think the model should be the inverse. The user is *only* prompted for datadir, and everything gets stored there. Optionally the Wizard could allow for specifying a separate location for InnoDB, but it would meet my requirements just fine if that was left as an advanced operation that required editing the config file.

(Is there some technical advantage to separating the two database engine storage locations, other than the usual obvious one of just partitioning storage space?)

On a related note, much of this could be simplified if the Wizard gained the capability to read in existing configuration files (someone has probably suggested this in another bug report), and used them to establish the defaults. One of the paths through the Wizard (for more advanced users) could just present a summary screen showing the current settings of the critical parameters with an "edit" button next to each, which would launch a mini-wizard to assist the user in changing a particular parameter.

 -Tom

Thanks for the report, and our apologies for not driving this to closure a long time ago. Closing now, since this is for an obsolete version of MySQL on an obsolete platform and for an obsolete component.