Migration issues from Geofield db storage updates

I also get the NDR error when I tried the latest dev-version. I only wanted to see how the openlayers widget works, added a field, opened the add new content form to see the widget, but didn't even create any content. Then I deleted the field but the error happened in the front page.
Exception: Only NDR (little endian) SKB format is supported at the moment in WKB->getGeometry() (line 48 of /Users/joonasmerilainen/Sites/srv/sites/all/libraries/geoPHP/lib/adapters/WKB.class.php).

@Joel MMCC, apologies for the difficulty. I think I found the issue in geofield_update_7201 and I'm going to do some additional testing locally first to ensure we don't bork any more sites. I'll have an update momentarily.

@mErilainen, this may be a separate issue. Did you upgrade from a previous version, or install fresh?

@Joel MMMC, can you try updating to the latest dev, then applying the attached patch? It looks like the update hook was missing a library call, which is weird in that I ran the update locally fine a few dozen times, but it probably shouldn't have worked without that call. Probably already loaded from a previous update hook or something.

I also just updated to the new core and am now receiving the following error when I click the link to my formerly functional Map page: Fatal error: Call to a member function out() on a non-object in mysite/sites/all/modules/geofield/modules/geofield_map/includes/geofield_map_plugin_style_map.inc on line 121.
Have applied the above patch, but still no dice. Any other suggestions?

Have applied the above patch, but still no success, here is my case:

geofield module

    7201 - Converts the wkt field into a geom field. Converts already existing data from wkt storage to wkb. Much inspiration for this implementation comes from taxonomy_update_7005.

This is the result if I apply

geofield module
Update #7201

    Failed: DatabaseSchemaObjectExistsException: Cannot add field <em class="placeholder">field_data_field_myfield_map</em>.<em class="placeholder">field_myfield_map_geom</em>: field already exists. in DatabaseSchema_mysql->addField() (line 328 of /home/user/public_html/includes/database/mysql/schema.inc).

It is happening after a Core 7.14 to 7.15 upgrade, it may be related to some changes done on fields in this version, see http://drupal.org/node/1708292

My site does not show any maps at this point.

An update, I've committed a few more bug fixes towards the cleanup of #1648976: Make it simpler to programmatically add Geofield data, which is the root cause of the issues being discussed here. I'm going to do my best to ensure a clean update, but as 2.x is still in dev, I can't guarantee the ongoing stability of the branch until we start releasing stables from the 2.x branch (which should be soon).

@nferrer, it sounds to me that your database updated properly, but I missed some changes that needed to happen on geofield map. That should be functional in the current 2.x-dev branch. Let me know if you have any other issues.

@vanderland, it sounds like you attempted to update twice, with the first update failing. Can you reply with environment information (Apache? php version? database version?). Also, try restoring your database from a copy before your update and running the update again.

My map works again. Happiness! Thank you!

@Brandonian I did not apply the update twice, not intentionally, This is what I did: I upgrade to 7.15, and after that I run update.php, that is when the upgrade became available the first time I run it, and it failed.
I will gather the versions for you soon.

Thanks
Van Der

@Brandonian, he is the versions of my system

Apache: 2.2.22 
CentOS: CentOS release 6.3 (Final)
cPanel: 11.32.3 (build 23)
Curl: 7.12.1
MySQL 5.5.23
phpMyAdmin: 3.4.10.1
Python: 2.6.6
Perl: 5.8.8
PHP: 5.2.17
ionCube Loader: 4.2.2
Zend Optimizer: 3.3.9
Ruby: 1.8.7
Rails: 2.3.14
OpenSSL: 1.0.0-fips

Thanks
Van Der

I just encountered the NDR & unpack errors when updating a node with a geofield (latest dev). Going to it's edit page and saving sorted it and it has not happened again, I'll report back if I can reproduce it.

just for iformation

7074 - This update has been removed and will not run.

is generated by system/system.install

see http://drupal.org/node/1711388

OK, I can reproduce the errors I mentioned every time I attempt to save a field collection (attached to a node with a geofield) programatically. Maybe we need to load the field before the save? (said without looking at any code)

I now lose nodes from the OpenLayers Locator view; see post here: http://drupal.org/node/1721370

I did upgrade to the 8/5 dev version yesterday and I assume this is all related somehow - it looks to me like the new version of Geofield isn't working with OL Proximity. Any ideas? Boy, I'd be happy just to go back to the most recent version, where everything seemed to work, at least for me.

Any possibilities for a rollback? Thanks!

Update: Tried with some earlier commits, deleted location nodes, de-installed and re-installed OL Proximity - it looks like the new Geofield isn't recognized by Proximity. Disabling the great-circle filter shows the XML in the preview, so the data is there. Proximity seems to be totally broken after the update... yikes!

Hi bcobin,

We won't be doing a rollback - no way to go but forward!

I suspect many of these problems will be related to moving to a WKB field instead of a WKT field and a change in the schema. Many of these integration modules will need to to be updated to take into account our new schema.

We won't be doing a rollback - no way to go but forward!

Ever onwards! Thanks for the sanity check and for all the work you're doing here. I'd suspect that OL Proximity isn't picking up the change; I've filed an issue over there which I'll now update. Any other guidance you may be able to supply here would be helpful - thanks again and I'll look forward to having everything play nice together again soon!

Confirmed that 2.x doesn't work with OL Proximity and likely with other modules as well. The schema change also means that you can't roll back; Geofield needs to be uninstalled, which means the field must be removed from all content types first.

I would definitely post an advisory on the project page that the 2.x branch represents a significant change and that users should think carefully before performing the upgrade at this point.

Thanks - rock on!

Personally, I would wait until the 2.x branch is officially supported by other modules, unless you're willing to test and debug. For example, OL Locator (a Feature module that uses various OpenLayer modules) is currently incompatible with the 2.x branch and will be until there's a 2.x version of Geofield the developer deems "solid."

See: http://drupal.org/node/1721370

Unless there's functionality you deem essential that exists only in the 2.x branch (and you're willing to try and fix incompatibilities in other modules), I would strongly suggest you stay on the 1.x branch. On account of the schema change, 2.x Geofield needs to be uninstalled to revert back to 1.x; the somewhat wonky process of deletion of unused fields in Drupal can make this a somewhat arduous process.

I've fixed this bug:

Warning: unpack() [function.unpack]: Type c: not enough input, need 1, have 0 in WKB->getGeometry()

I'm seeing the same problem as mErilainen after an upgrade.

Joel MMCC,

What version of geoPHP are you running?

Hi Joel,
not sure if my workaround will be suitable for you, but thought I could share it anyway.

My case:
Same trouble as described above when updated to 7.x-2.x version:

My setup:
address field, geocoder, geofield. the geofield's widget is set up to geocode from another field "address field".

So what I did in order to get over the troubles with the geofield in database:
1/ Using Rules, I first exported all the addresses I have saved in the address field to a temporary set of fields.
2/ Delete of the problematic geofield - completely.
3/ Creation of another geofield with exactly the same machine name (to preserve all the views dependencies). At this point, the geofield contains no data what so ever (freshly made).
4/ Using Rules, copied all entries from the temporary set of fields back to the address field. - this automatically populates the Geofield back.
5/ cache clear, run cron all seems to work without any trouble.

Hope it helps. Cheers

I think this issue could be closed, given that this process works fine now.
I've made some tests last days and it worked always.

Marking as fixed. If someone consider that this issue persists, it can be reopened.

Regards.

Hi
this problem still exists for me with the latest --dev version, the error is the same as above:

The following updates returned messages

geofield module

Update #7201
Failed: DatabaseSchemaObjectExistsException: No se pudo añadir el campo <em class="placeholder">field_data_field_localizacion</em>.<em class="placeholder">field_localizacion_geom</em>: El campo ya existe. en DatabaseSchema_mysql->addField() (línea 328 de /srv/www/drupal7/includes/database/mysql/schema.inc).

I removed and uninstalled Geofield and took the actual Drupal module with drush.

Still the same!

Notice: Undefined index: wkt in openlayers_proximity_build_proximity_index() (linr 248

Sorry

hi, is there a fix now?
i still geting this error with 2.1:

The following updates returned messages

geofield module

Update #7201
Failed: DatabaseSchemaObjectExistsException: Cannot add field <em class="placeholder">field_data_field_project_location</em>.<em class="placeholder">field_project_location_geom</em>: field already exists. in DatabaseSchema_sqlsrv->addField() (line 349 of ...\includes\database\sqlsrv\schema.inc).

I ran into the same issues. However, I am using https://drupal.org/project/field_sql_norevisions because I am trying to avoid doubling up on the amount of data I have stored in my database (have very large datasets). What happened I believe is when it tried working with the revision table it killed the script however it already created the _geom field in the table. I removed that field from the culprit table and removed all the revision based changes and re-ran the script and things seem to be updating now.

**UPDATE** Batch stopped processing after 1000 results of the first field. Not sure what it is doing.

-Jesse