Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDifferentiate between BINARY and CHAR #724
Conversation
When looking up the database type name, we now check the character set for the following field types: * CHAR * VARCHAR * BLOB * TINYBLOB * MEDIUMBLOB * LONGBLOB If the character set is 63 (which is the binary pseudo character set), we return the binary names, which are (respectively): * BINARY * VARBINARY * BLOB * TINYBLOB * MEDIUMBLOB * LONGBLOB If any other character set is in use, we return the text names, which are (again, respectively): * CHAR * VARCHAR * TEXT * TINYTEXT * MEDIUMTEXT * LONGTEXT To facilitate this, mysqlField has been extended to include a uint8 field for character set, which is read from the appropriate packet. Column type tests have been updated to ensure coverage of binary and text types.
|
A note on test coverage: Although coveralls is claiming reduced test coverage based on LOC, test coverage has actually improved when looking at cases covered, as the missed cases are now 2-5 lines long, whereas they were 1 line each in the previous revision. The missed cases are either unusual data types that are trickier to test (but with behaviour very close to cases we do test), such as Fortunately, these unused field types are handled in exactly the same way as types that we can test, so we can still be fairly confident they will work as expected. The list of column types we now test with the latest revision is:
|
|
Thanks for contributing! |
* Differentiate between BINARY and CHAR When looking up the database type name, we now check the character set for the following field types: * CHAR * VARCHAR * BLOB * TINYBLOB * MEDIUMBLOB * LONGBLOB If the character set is 63 (which is the binary pseudo character set), we return the binary names, which are (respectively): * BINARY * VARBINARY * BLOB * TINYBLOB * MEDIUMBLOB * LONGBLOB If any other character set is in use, we return the text names, which are (again, respectively): * CHAR * VARCHAR * TEXT * TINYTEXT * MEDIUMTEXT * LONGTEXT To facilitate this, mysqlField has been extended to include a uint8 field for character set, which is read from the appropriate packet. Column type tests have been updated to ensure coverage of binary and text types. * Increase test coverage for column types
When looking up the database type name, we now check the character set
for the following field types:
If the character set is 63 (which is the binary pseudo character set),
we return the binary names, which are (respectively):
If any other character set is in use, we return the text names, which
are (again, respectively):
To facilitate this, mysqlField has been extended to include a uint8
field for character set, which is read from the appropriate packet.
Column type tests have been updated to ensure coverage of binary and
text types.
Description
This is a pull request to support differentiating between BINARY and CHAR, as discussed under issue #723.
Checklist