Hi guys,

I report the couple problems I just got on one site running the update process. I'll be upgrading many sites and if I get different errors, I will post them here too.

Note that max_filesize was created at some point. I'm not too sure why it failed with that error. Looking at the code, I could not really see how that could happen unless the xmlsitemap_sitemap_save() function from xmlsitemap.module was run which generally does not happen when you only execute code in the .install files... I would think that the map should be empty after the update anyway, shouldn't it be rebuilt from scratch to make sure it is 100% valid?

The constraint was also properly added from what I can see. Not too sure if the DROP was not necessary (i.e. if the column did not yet have a constraint?)

Thank you.
Alexis Wilke

  • warning: pg_query() [function.pg-query]: Query failed: ERROR: column "max_filesize" of relation "xmlsitemap_sitemap" does not exist LINE 1: ...p_sitemap (smid, context, updated, links, chunks, max_filesi... ^ in /usr/clients/www_html/new.m2osw.com/public_html/includes/database.pgsql.inc on line 189.
  • user warning: query: INSERT INTO xmlsitemap_sitemap (smid, context, updated, links, chunks, max_filesize) VALUES ('NXhscRe0440PFpI5dSznEVgmauL25KojD7u4e9aZwOM', 'a:0:{}', 0, 0, 0, 0) in /usr/clients/www_html/new.m2osw.com/public_html/includes/common.inc on line 3545.
  • warning: pg_query() [function.pg-query]: Query failed: ERROR: constraint "xmlsitemap_sitemap_pkey" does not exist in /usr/clients/www_html/new.m2osw.com/public_html/includes/database.pgsql.inc on line 189.
  • user warning: query: ALTER TABLE xmlsitemap_sitemap DROP CONSTRAINT xmlsitemap_sitemap_pkey in /usr/clients/www_html/new.m2osw.com/public_html/includes/database.pgsql.inc on line 811.
CommentFileSizeAuthor
#3 xmlsitemap-upgrade.drush_.txt17.29 KBaspedia
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

AlexisWilke’s picture

Okay, the failing INSERT is a problem since that's the default sitemap.xml file that does not get created and thus it makes it totally unavailable... I read a few issues where some people where saying they lost their sitemap, it could be related?

P.S. I use PostgreSQL (which shows in the error logs, but just in case)

AlexisWilke’s picture

Dave,

Hmmm... got a bit of a problem with 2.x right now! 8-}

Only the language (i18n) has an implementation of the context hooks. Are you working on the node content right now? That would be quite useful so at least I have a decent XML sitemap. Right now, it's dead. 8-(

If you want some help on that, I can try it... I'd learn the new interface that way.

Update: see #939812: "There are currently no XML sitemap contexts available." error message is confusing. and #803756: No XML sitemaps available - There are currently no XML sitemap contexts available.

Thank you.
Alexis

aspedia’s picture

I had this problem upgrading from the latest 6.x-1.x-dev release, to the current 6.x-2.x-beta3.

I've attached drush ouput below, but, the problem seems to come from xmlsitemap_update_6202(), which tries to use the max_filesize field, which, is not added until xmlsitemap_update_6203().

Manually running the failed inserts after the second drush updb worked just fine.

hanoii’s picture

Status: Active » Closed (duplicate)
Anonymous’s picture

Status: Closed (duplicate) » Active

Well, I suppose then 137488 is a duplication of this one.

hanoii’s picture

Following up what @earnie said on #1374888-4: Update from 6.x-1.2 to 6.x-2.0-rc2: user warning: Unknown column 'max_filesize' in 'field list' query which was marked as duplicate of this one.

We cannot do an update by grabbing the current schema. Each update must handle the newness as it applies to it.

But that is also apply for using function such as xmlsitemap_sitemap_save(), which is called in different places of the upgrade functions, but that function will work properly with the latest schema, so it's likely that if you will have this kind of issues now or in the future.

So I guess the only way to fix this, is to go back in time in to when those updates were added, look for what xmlsitemap_sitemap_save() does in that version of the code and 'emulate' that with plain db_queries, without using any database API functions such as drupal_write_records() which always uses the latest schema. Quite a bit time consuming task, which I might try to do it if you feel/think this is the approach to be accepted, Let me know otherwise. That function is only used in 6202 and 6204.

Anonymous’s picture

@hanoii the issue is pointed out in #3 in this ticket. The 6202 update is using max_filesize but isn't added until the 6203 update.

hanoii’s picture

@earnie I understand the issue, I was just discussing what would the the approach to fixing it, as it's not strainghtforward. 6020 is using max_file_size only because it uses an internal function to save the sitemap that will be always matching the latest schema, despite on the point where it was run. I am willing to work on a fix for this but I wanted to be sure what might be the best approach there.

Anonymous’s picture

6020 is using max_file_size only because it uses an internal function to save the sitemap that will be always matching the latest schema

I assume you mean

 611   // Add the default sitemap(s) and use language contexts if possible.
 612   if (!db_result(db_query("SELECT COUNT(smid) FROM {xmlsitemap_sitemap}"))) {
 613     // Refresh the schema and load the module if it's disabled.
 614     drupal_get_schema(NULL, TRUE);
 615     drupal_load('module', 'xmlsitemap');
 616 
 617     if (module_exists('xmlsitemap_i18n') && $languages = variable_get('xmlsitemap_languages', array())) {
 618       foreach ($languages as $language) {
 619         $sitemap = new stdClass();
 620         $sitemap->context = array('language' => $language);
 621         xmlsitemap_sitemap_save($sitemap);
 622       }
 623     }
 624     else {
 625       $sitemap = new stdClass();
 626       $sitemap->context = array();
 627       xmlsitemap_sitemap_save($sitemap);
 628     }
 629   }

We can't use xmlsitemap_sitemap_save() here. I'd suggest a global variable to indicate we need to we need to create the record in the xmlsitemap_install() function. Or maybe just move this section to the _install() function, it is filtered and by the time we execute the code the other updates would already be completed.