Hi!
On Apr 15, Eric Prud'hommeaux wrote:
> On Mon, Apr 10, 2006 at 12:17:54PM +0200, Sergei Golubchik wrote:
> > and only after all tables are opened, MySQL calls
> > Item_field::fix_fields() for all Item_field's, and it's the method where
> > "binding" happens - a field finds what table and database it belongs to,
> > finds all metadata about itself, data type, constrains, indexes, and so
> > on.
>
> worky (and quite easily)!!! Thank you SO much for the pointer!
Glad to hear that!
> [[
> bool Item_variable::fix_fields(THD *thd, Item **reference) {
> if (primary_key)
> field_name = get_primary_key();
> return Item_field::fix_fields(thd, reference);
> }
>
> const char* sparqlFrob::get_primary_key(const char *table_name) {
> TABLE_LIST *entry = thd->main_lex.select_lex.context.table_list;
> while (entry) {
> if (!strcmp(table_name, entry->table_name)) {
> KEY *key = entry->table->key_info;
> for (unsigned i = 0; i < entry->table->s->keys; i++) { // from
> sql_show.cc::2905 get_schema_stat_record
> if (!strcmp(key[i].name, "PRIMARY")) {
> assert(key[i].key_parts == 1);
> return key[i].key_part->field->field_name;
> }
Strictly speaking, primary key is _always_ the first one, so it's enough
to check entry->table->key_info[0].
> }
> assert(0); // couldn't find PRIMARY KEY
> }
> entry = entry->next_global;
> }
> assert(0); // couldn't find table
> }
> ]]
> It brings up 2 questions:
>
> Is there a way to kill a thread ('cause something went horribly
> wrong), without killing the whole server? What's the polite way to
> assert(0)?
Usually you just throw an error (my_error(...)), and return an failure,
which is usually non-zero in MySQL source (with zero meaning success).
It assumes, of course, that the caller checks return values.
Kill a thread - technically you can do that, set THD::killed
(grep to see how it's used). But
- it was designed for asynchronous use - when a thread is killed by some
other thread
- it's "advisory" killing - a thread checks THD::killed in certain
places and returns an error if it's set. It may not die immediately.
- I would not recommend doing it anyway - users do not expect a
connection being killed on an error, they want an error message.
And if you kill the connection - be ready for bugreports "MySQL
server crashed", because not everybody will try to understand what is
the reason for the error message "Lost connection to MySQL server
during query". I saw many bugreports about "crashes" which in fact
the problem was a disconnect.
> Is there a better way to find the table_list for a thread? I feel
> like thd->main_lex.select_lex.context.table_list should really
> include some inode numbers, the process id and maybe some astrology.
Eh, this part of code has changed quite a lot recently, I'm not up to
date :(
I'll ask another developer to reply.
Regards,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Kerpen, Germany
<___/ www.mysql.com
| Thread |
|---|
| • getting table meta data (primary key, in this case) | Eric Prud'hommeaux | 1 Apr |
| • Re: getting table meta data (primary key, in this case) | SGreen | 3 Apr |
| • Re: getting table meta data (primary key, in this case) | Eric Prud'hommeaux | 3 Apr |
| • Re: getting table meta data (primary key, in this case) | Eric Prud'hommeaux | 5 Apr |
| • RE: getting table meta data (primary key, in this case) | Rick James | 5 Apr |
| • RE: getting table meta data (primary key, in this case) | Stewart Smith | 6 Apr |
| • RE: getting table meta data (primary key, in this case) | Stewart Smith | 6 Apr |
| • Re: getting table meta data (primary key, in this case) | Sergei Golubchik | 6 Apr |
| • Re: getting table meta data (primary key, in this case) | Eric Prud'hommeaux | 6 Apr |
| • Re: getting table meta data (primary key, in this case) | Sergei Golubchik | 10 Apr |
| • Re: getting table meta data (primary key, in this case) | Eric Prud'hommeaux | 15 Apr |
| • Re: getting table meta data (primary key, in this case) | Sergei Golubchik | 18 Apr |
| • Re: getting table meta data (primary key, in this case) | Sanja Byelkin | 18 Apr |
| • Re: getting table meta data (primary key, in this case) | Sergei Golubchik | 3 Apr |
| • Re: getting table meta data (primary key, in this case) | Sergei Golubchik | 10 Apr |
| • Re: getting table meta data (primary key, in this case) | Eric Prud'hommeaux | 10 Apr |
| • Re: getting table meta data (primary key, in this case) | Eric Prud'hommeaux | 11 Apr |