requinix

If you ever need functions like MAX or SUM or COUNT and you don't want to count the entire table at once then you need a GROUP BY clause. If you want to select a column and then use those functions on others, you should probably be GROUPing BY that first column.

For a regular index, that "col2" would be the name of it. For a primary key (which I forgot was different) that doesn't use a name, that "col2" would be the index type. Of course "col2" and "merchandise" are not valid index types so I would have expected at least a warning. And I don't have a MySQL lying around to test with. So I'm thinking it's (accidentally?) ignored for sake of compatibility with other types of indexes.

Where there any warnings with the "ALTER TABLE mytable ADD PRIMARY KEY merchandise (merchandise)" statement?

Are you sure? What was the output?

Okay, so I thought a SHOW CREATE TABLE would include the indexes. Do the other SHOW INDEX FROM.

Try more like a SHOW INDEX FROM TableX SHOW CREATE TABLE TableX

Use your browser to watch the AJAX request happen, and see what the response to it was.

This may be a bit more technical than you're expecting, but it answers essentially what you're asking about. Have MySQL describe the table and its indexes for you after each command. Look for the difference.

1. Because MySQL updates the index automatically. After all, having to manually rebuild the index every time data changes would be incredibly tedious. 2. Same thing. One key is named automatically, one key is named manually. And no, the name does not matter. But adding the primary key after the table is created is annoying - do it when the table is created, inside the table definition.

What is your real problem? Because allowing there to be HTML markup in the query string that you then display on the page is very much not the right solution.

e is an event object. e.target is the object firing the event (the select). You can get the files from it.

Help for what? I told you not to run it from the command line, which you're still doing, but now you've posted part of your kernel log which I can only assume you're doing for a reason that I can't figure out.

Can you decouple the storage mechanism from the chart? Entirely? The general chart service would lookup the basic chart information, determine the data source, and inject that into the chart.

RemoteChart sounds like it's more of a data thing than a chart thing. Sounds like you need to abstract out the data retrieval/storage process. Probably specialized for the way charts will use it, but more or less separate from the actual chart business.

"Service" is probably a more accurate term. It may be functioning like a controller in that it has various actions called for requests, but it isn't directly interacting with the request or response so it's not quite entirely a controller. You're talking about single-responsibility with the chart creation bit? You're still observing it: the single responsibility of creating charts is in one central location. Your method seems more or less right: single place to look up chart data, chart identifier maps into a class through a factory, class handles the precise work of the various operations. Chart types are not dynamically created (eg, no user-defined types) so hardcoding identifiers and class names is acceptable.