Keskustelu: Nettisivujen teko: Sarakkeen tyypin muokkaus MySQLissä

Tässä tuli pieniä pulmia sarakkeen tyypin muokkauksessa joillakin palvelimilla.
Virhettä pukkaava sarake on tämä:

ALTER TABLE `product_description` CHANGE `description` `description` TEXT COLLATE `utf8_general_ci` NOT NULL

Minun omalla palvelimella tuo toimii, mutta joissakin ei. Onko tämä täysin serverikohtainen ongelma. Voiko sitä kiertää?
Erikoista on että tämä hiukan aikaisempi koodi toimii:

ALTER TABLE `category_description` CHANGE `description` `description` TEXT COLLATE `utf8_general_ci` NOT NULL

Virhe on tällainen:

Notice: Error: Column 'description' cannot be part of FULLTEXT index
Error No: 1283
ALTER TABLE `product_description` CHANGE `name` `name` VARCHAR(255) COLLATE `utf8_general_ci` NOT NULL

tuo sarake 'name' on edellinen, jota muokataan, ennen kuin homma pysähtyy.

pistemies kirjoitti:

Voiko sitä kiertää?

Tarkoitan tällä kiertää ongelma aavistuksen erilaisella sql-lauseella.
Ajatuksissani on homma millä sen kiertää niin että tuon 'product_description' taulun jättää ksäittelemättä tuossa silmukassa ja myöhemmin poimii siitä tuon sarakkee 'name' käsittelyyn.

Voisit edes googlettaa virheilmoituksella ja tutkia asiaa hieman itsekin. Olet ilmeisesti valmis käyttämään tolkuttomasti aikaa sähellykseen ja arpomiseen, niin asian oikeaoppinen lähestymistapa ei ole pois mistään.

The Alchemist kirjoitti:

(01.04.2016 20:53:21): Voisit edes googlettaa virheil­moi­tuk­sella ja...

Yep. Jotakin löytyi. Tämä on aikaisemminkin ollut aika kiusallinen ongelma.
http://www.opencart60s.com/opencart/error-1283-107535.html
http://forum.opencart.com/viewtopic.php?t=96267#p385213

Ainoa muutosehdotus tuossa on se, että sarakkeen name tyypin vaihtoon lisätään tuo 'AFTER `language_id`.
Haiskahtaa jonkilaiselta bugilta tuon taulun rakenteessa.
Alkuperäisen vanhan taulun rakenne vuodelta 2012;

CREATE TABLE `oc_product_description` (
  `product_id` int(11) NOT NULL AUTO_INCREMENT,
  `language_id` int(11) NOT NULL,
  `name` varchar(255) COLLATE utf8_bin NOT NULL,
  `description` text COLLATE utf8_bin NOT NULL,
  `meta_description` varchar(255) COLLATE utf8_bin NOT NULL,
  `meta_keyword` varchar(255) COLLATE utf8_bin NOT NULL,
  `tag` text COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`product_id`,`language_id`),
  KEY `name` (`name`),
  FULLTEXT KEY `description` (`description`),
  FULLTEXT KEY `tag` (`tag`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Nykyinen taulun rakenne, johon tulisi päivittää:

CREATE TABLE `oc_product_description` (
  `product_id` int(11) NOT NULL,
  `language_id` int(11) NOT NULL,
  `name` varchar(255) NOT NULL,
  `description` text NOT NULL,
  `tag` text NOT NULL,
  `meta_title` varchar(255) NOT NULL,
  `meta_description` varchar(255) NOT NULL,
  `meta_keyword` varchar(255) NOT NULL,
  PRIMARY KEY (`product_id`,`language_id`),
  KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;

Eli pitäisi ensin, ennen sarakkeen tyypin muuttamista, poistaa nuo FULLTEXT indeksit jotenkin.

pistemies kirjoitti:

Ainoa muutosehdotus tuossa on se, että sarakkeen name tyypin vaihtoon lisätään tuo 'AFTER `language_id`.

Nyt olet lukenut ihan omiasi. Ei kukaan ole tarjonnut sellaista muutosta ratkaisuksi.

pistemies kirjoitti:

Haiskahtaa jonkilaiselta bugilta tuon taulun rakenteessa.

Haiskahtaa lähinnä siltä, että et tiedä itsekään, mitä tietokannassasi on.

Kuten virheilmoitus ja ihan yksinkertainen googletus kertovat, teksti-indeksi ei voi sisältää tuota muutettua saraketta, koska indeksin sarakkeilla tulee olla kaikilla sama järjestystapa (kollaatio). Virheestä voi päätellä, että sinulla on taulussasi jokin useamman sarakkeen indeksi, eli selvästi taulu ei ole tuollainen, kuin edellä väität.

Selvitä taulun sarakkeet ja indeksit SHOW CREATE TABLE -kyselyllä. Muuta kaikkien teksti-indekseihin kuuluvien sarakkeiden merkistöt ja kollaatiot yhdellä ALTER TABLE -kyselyllä.

Varmuuden vuoksi ihan testasin, että näin muutos onnistuu. Testikyselyni:

CREATE TABLE testi (
  a TEXT COLLATE utf8_bin,
  b TEXT COLLATE utf8_bin,
  FULLTEXT KEY ab_index (a, b)
);
ALTER TABLE testi
  CHANGE COLUMN a a TEXT COLLATE utf8_swedish_ci,
  CHANGE COLUMN b b TEXT COLLATE utf8_swedish_ci;
DROP TABLE testi;

Jos jostain syystä et saa tälläkään muutosta tehtyä, voit ihan helposti poistaa kaikki indeksit (ja lisätä ne myöhemmin takaisin) tai hätätilassa vaikka luoda koko taulun uudestaan.

Thanks.
Selvitin tämän eilen tutkimalla tarkemmin kyseisellä palvelimella olevan taulun rakennetta.
Huomasin, että se ei ollut tuo edellä mainitsemani rakenne (joka on Opencartin alkuperäinen rakenne kyseiseen tauluun, versioon 1.5.4.1), vaan sitä oli muokattu tai sitten siinä oli jäänteitä jostakin vielä vanhemmasta versiosta, kentässä 'name' oli myös FULLTEXT index kun taas sarakkeessa 'tag' sitä ei ollut.

Ps. Tässä vielä tämä ongelmallinen rakenne:

CREATE TABLE IF NOT EXISTS `oc_product_description` (
  `product_id` int(11) NOT NULL,
  `language_id` int(11) NOT NULL,
  `name` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `meta_keyword` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `meta_description` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  `description` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `custom_title` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT '',
  PRIMARY KEY (`product_id`,`language_id`),
  KEY `name` (`name`),
  FULLTEXT KEY `ft_namerel` (`name`,`description`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8;

Olen 'virittänyt' skriptin nyt näin:

  if( substr(VERSION,0,3) == '1.5' ){
              $drop = "ALTER TABLE `" . DB_PREFIX . "product_description` DROP INDEX ft_namerel";
              $index_query1 = $this->upgradetool->indexes('product_description','name');
              $column_query = $this->upgradetool->columns('product_description','custom_title');
               if( !$this->simulate && !$this->demo ) {
               	if($index_query1 == true && $column_query == true){
                      $this->db->query( $drop );
               	}
              }
 // ------------
}

Arvelen että tuo ylimääräinen sarake 'custom_title' liittyy tuohon laajennukseen, joka on tehnyt tuon muutoksen tauluun.
Minkälaisella kyselyllä voisi saada selville, onko tässä taulussa indeksi nimeltä ft_namerel? Nyt olen ainoastaan tutkinut pelkän sarakkeen 'name' COLUMN_KEY tiedon + sarakkeen 'custom_title' on/off.

pistemies kirjoitti:

Minkälaisella kyselyllä voisi saada selville, onko tässä taulussa indeksi nimeltä ft_namerel?

”Selvitä taulun sarakkeet ja indeksit SHOW CREATE TABLE -kyselyllä.” Luetko edes näitä vastauksia?

Toisaalta yllä esittämässäsi CREATE TABLE -kyselyssä mainitaan FULLTEXT KEY ft_namerel, jonka sarakkeet ovat name ja description. Kuten edellä totesin, et voi muuttaa tällaisen teksti-indeksin sarakkeista vain yhtä, vaan molempien kollaatio pitää muuttaa samalla kertaa.

Oikeastaan voisit saman tien korjata kaikkien tekstisarakkeiden kollaatiot. Uskoisin, että on turvallista ajaa kollaatioiden päivitys käsin ja sitten ajaa perään alkuperäinen päivitysskripti ilman mitään virittelyä. Sen sijaan päivitysskriptin virittelyyn ei kannata lähteä kuin aivan viimeisenä keinona.

Thanks

Sain tuon toimimaan tuolla SHOW CREATE TABLE lauseella.

Ps.

Metabolix kirjoitti:

Kuten edellä totesin, et voi muuttaa tällaisen teksti-indeksin sarakkeista vain yhtä, vaan molempien kollaatio pitää muuttaa samalla kertaa.

Tässä ei ole kyse pelkkien kollaatioiden muuttamisesta (vaikka ongelma käynnistyikin sitä tehessä) vaan myös taulun / taulujen indeksit pitää muuttaa vastaamaan nykyistä Oc versiota.