Closed (fixed)
Project:
Openlayers
Version:
6.x-2.x-dev
Component:
OpenLayers Views
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 Aug 2010 at 11:17 UTC
Updated:
5 Jun 2011 at 08:22 UTC
Jump to comment: Most recent file
Comments
Comment #1
zzolo commentedThanks for the notification on this. I think the original idea was to support multiple data sources in one data overlay, but interface-wise and code-wise, it does not seem like it would be worth the trouble, since it has not been a requested feature or even noticed until now.
Comment #2
tmcw commentedFixed: http://drupal.org/cvs?commit=416648
Comment #3
strk commentedIn commit 416648 you changed too much code, it seems. Even if non-multiple the checkbox values retain the structure they had before, that is "key" => "key" when selected. At least this is what happens here.
Did you try re-saving an old view recently ?
The attached patch fixes the problem for me (one line).
Comment #4
strk commentedAfter updating the "data" display style (engine icon) and "save" ing the view again, code in HEAD is fine to handle it, while my patch clearly isn't. So no problem with HEAD except some care is required for upgrade paths.
Comment #5
zzolo commentedIt sounds like this should be reviewed for upgrade path? I'll try to check out tonight.
Comment #7
zzolo commentedGood catch, @strk. Included groups as well and committed:
http://drupal.org/cvs?commit=420186
Comment #8
tmcw commentedWait, why is this being addressed with backwards compatibility rather than an update hook? Wouldn't the latter be a better long-term solution?
Comment #9
tmcw commentedIn fact, the approach taken here has broken openlayers data views for alpha 9. zzolo: revert, fix, re-release.
Comment #10
tmcw commentedReverted: http://drupal.org/cvs?commit=420440
Comment #11
zzolo commentedI totally agree that this was not the most ideal solution, and that an update would be more appropriate, but due to the the complexity of the update, I figured this would be a little more stable fix. An update function can be addressed for next release.
As for now, I have put in a fix that addresses new code and is backwards compatible. Just wanted to get a new release out before people started upgrading. I know it is not ideal.
My apologies for not testing as best as I could. @tmcw, your code did not address people upgrading, and I thought @strk's patch addressed the new code.
Keeping open for update functionality.
Comment #12
zzolo commentedSo, an update hook would not address any Views that are in code, which means we would still need to have the backwards compatible code. Also, this is kind of low priority. I am gonna close, but if anyone wants to work on the upgrade path, please go re-open as needed.