|
Monday 22 September 2003 11:02:05 am
Yep, there are quite a lot of "offending lines" in dbupdate 3.2.0-2-to-3.2-1. This script does not fit in the upgrade sequence at all.
The mystery is twofold:
After having cleansed dbupdate 3.2.0-2-to-3.2-1 from each superfluous line, the cleansed script has just the following lines: ___________________________________
create index ezsearch_word_object_count on ezsearch_word(object_count);
create index ezcontentobject_status on ezcontentobject( status );
create index ezcontentobject_tree_path_depth on ezcontentobject_tree( path_string, depth );
create index ezurlalias_source_md5 on ezurlalias( source_md5 );
create index ezpreferences_name on ezpreferences( name );
ALTER TABLE ezcontentobject_attribute ADD index ( sort_key_int );
ALTER TABLE ezcontentobject_attribute ADD index ( sort_key_string );
ALTER TABLE ezsite_data DROP COLUMN id;
ALTER TABLE ezsite_data ADD PRIMARY KEY ( name );
INSERT INTO ezsite_data (name, value) VALUES('ezpublish-version', '3.2');
INSERT INTO ezsite_data (name, value) VALUES('ezpublish-release', '1'); ___________________________________________________ Now, if you compare this remainder dbupdate script for ezp 3.2 beta 2 upgrades to ezp 3.2 release with the complete kernel_schema file of ezp 3.2 release, the CREATE INDEX statements of the update script are not part of the kernel_schema.sql.
In other words: Upgrading from ezp 3.1 to 3.2 does not exactly produce the ezp 3.2. kernel schema.
Since the differences are just about indices, they won't do any harm except that one might encounter differences in database performance and resource allocation.
The thing remains strange, though. One does not know which procedure to choose in order to obtain a ezp 3.2 kernel_schema as intended by ez systems ;-)
|
