- Added 'SET NAMES <charset>" upon ::open
- Added test and results for simple UTF test
federated.test:
BUG #17044 Federated Storage Engine not UTF8 clean
New test. Using hex - pasting various charsets in the terminal doesn't work.
federated.result:
BUG# 17044 Federated Storage Engine not UTF8 clean
New test results
ha_federated.cc:
BUG# 17044 Federated Storage Engine not UTF8 clean
Upon ::open, set names to table's charset
Added HA_NULL_IN_KEY to table flags to allow for nullable unique indexes
and added test to verify
ha_federated.h:
BUG #15133 "unique index with nullable value not accepted in federated table"
added HA_NULL_IN_KEY to table flags to allow for nullable unique indexes
federated.test:
BUG #15133 "unique index with nullable value not accepted in federated table"
New test to show that nullable unique indexes work
federated.result:
BUG #15133 "unique index with nullable value not accepted in federated table"
New results for new test
The Federated storage engine used Field methods that had arbitrary limits on
the amount of data they could process, which caused problems with data
over that limit (4K). By removing those Field methods and just using
features of the String class, we can avoid this problem.
NDB table".
SQL-layer was not marking fields which were used in triggers as such. As
result these fields were not always properly retrieved/stored by handler
layer. So one might got wrong values or lost changes in triggers for NDB,
Federated and possibly InnoDB tables.
This fix solves the problem by marking fields used in triggers
appropriately.
Also this patch contains the following cleanup of ha_ndbcluster code:
We no longer rely on reading LEX::sql_command value in handler in order
to determine if we can enable optimization which allows us to handle REPLACE
statement in more efficient way by doing replaces directly in write_row()
method without reporting error to SQL-layer.
Instead we rely on SQL-layer informing us whether this optimization
applicable by calling handler::extra() method with
HA_EXTRA_WRITE_CAN_REPLACE flag.
As result we no longer apply this optimzation in cases when it should not
be used (e.g. if we have on delete triggers on table) and use in some
additional cases when it is applicable (e.g. for LOAD DATA REPLACE).
Finally this patch includes fix for bug#20728 "REPLACE does not work
correctly for NDB table with PK and unique index".
This was yet another problem which was caused by improper field mark-up.
During row replacement fields which weren't explicity used in REPLACE
statement were not marked as fields to be saved (updated) so they have
retained values from old row version. The fix is to mark all table
fields as set for REPLACE statement. Note that in 5.1 we already solve
this problem by notifying handler that it should save values from all
fields only in case when real replacement happens.
When building the UPDATE query to send to the remote server, the
federated storage engine built the query incorrectly if it was updating
a field to be NULL.
Thanks to Bjrn Steinbrink for an initial patch for the problem.
new file
mysql_fix_privilege_tables.sql, mysql_create_system_tables.sh:
Adding true BINARY/VARBINARY: fixing "password" type, not to be 0x00-padding.
Many files:
Adding true BINARY/VARBINARY: fixing tests not to output 0x00 bytes.
Adding true BINARY/VARBINARY: new pad_char structure member.
ctype-bin.c:
Adding true BINARY/VARBINARY: new pad_char structure member.
New strnxfrm, with two trailing length bytes.
field.cc:
Adding true BINARY/VARBINARY.
Changes to a test with a update to a table with 1001 columns, the last being a blob.
On HP, the test worked properly, but on other OSs, there's a problem with using the
blob column in an update where clause. The field method val_string(String *, char *)
should work, but doesn't seem to deal with blobd, and for some reason, cannot get
the correct value of the blob column from the byte pointer in update_row, "*old_data"
which is a byte pointer to the row in mysql format, that will be replaced with
"*new_data" (which conveniently has a field pointer to use to get values from).
Will document this.
Konstja and Georg, change sets 1.1806, 1.1805. These changes has been successfully
tested on both my own workstation (Suse 9.0) and production.mysql.com.
Patch #2, all coding style changes per Kostja's review
(as requested to keep style changes separate from functionality changes),
as well as changes to the test suit to no longer use hard-coded port
values in foreign table creation statement
This patch contains all that my previous patch (1.1814) contained, with the addition of using cli_fetch_lengths for
handling binary data (Bar noted this on the review of 1.1814, Guilhem suggested using cli_fetch_lenghts by
making available via removal of static in method definition and declaration in mysql.h, but
Konstantin had some reservations, but he said to commit the patch using this anyway,
and I suppose this can be discussed. I abandoned 1.1814 because Monty made a couple
fixes to my code as well as formatting changes, and I thought it would just be easier
to hand-edit my changes into a fresh clone and then make a patch.
The reason for using cli_fetch_lengths is so that I can correctly get the length of
the field I am setting into the field. I was previously using 'strlen' but Bar pointed out this
won't correctly get the length of binary data and is also less effecient. Upon testing,
it was in fact verified that binary data in a blob table was being inserted correctly,
but not being retrieved correctly, all due to not having the correct value for the
field:
(*field)->store(row[x], strlen(row[x]), &my_charset_bin);
was changed to:
(*field)->store(row[x], lengths[x], &my_charset_bin);
lengths being a unsigned long pointer to the values of the field lengths from a
MYSQL_ROW.
Since the server doesn't have the function "mysql_fetch_lengths" available, I tried
to use "result->lengths", but this isn't set, so I finally successfully used
cli_fetch_lenghts, which does give the correct lengths, and now the binary data gets
retrieved correctly.
I've also run the code through indent-ex and am using Brian's vimrc to ensure correct formatting!
This code passes the entire test suite, without any errors or warning on both my
workstation and build.mysql.com
-New tests and results
logging_ok:
Logging to logging@openlogging.org accepted
ha_federated.h:
removed quote_data and type_quote (now in the Field class)
ha_federated.cc:
moved quote_data and type_quote to field class
field.h:
new methods quote_data and needs_quotes declared
field.cc:
new field class methods quote_data and needs_quotes (per Monty's request)
federated.test:
more tests, joins, index tests
have_federated_db.require:
new name of federated system var
federated.result:
new test results for federated handler
have_federated_db.inc:
changed name of variable in test due to change in vars
sql_analyse.cc:
over-ridden append_escaped to take (String *, char *, uint) per requirements of 'create_where_from_key' method in federated handler.
mysql_priv.h:
define over-ridden append_escaped to take arguments from 'create_where_from_key' method in federated handler
ha_federated.cc:
implemented "create_where_from_key" to deal properly with two-byte prefix and multi keys. Initial testing shows it works, but I still need to move quoting to field class and also look at changes per Segei's suggestions.
