-
Notifications
You must be signed in to change notification settings - Fork 652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
viz.json v2 compatibility #9550
Comments
The v2 vizjson can be still generated form the API and will do something, usually just execute the query in the original dataset, before any analyses are applied. If it is the same data type, styling should be mostly alright. We considered adding a warning the first time you open a map with the builder before, but I think we discarded it in favour of warning in the invitation email to join builder early access. |
the thing is, if there is some analysis the map will not show anything. In the other hand if we change infowindows, legends or something it will break so we should do something to warn the user about this. We should also provide a migration path, that's it, a way to replace cartodb.js v3 with v4 in order to upgrade the app. cc @alonsogarciapablo |
ping |
@xavijam we might need to take a look at this |
hey @gfiorav, one question, with mapcaps, could we froze visualizations just for v2? |
Hey @javisantana, Short answer: no Long answer: Mpacaps store enough info to generate a memory (not persisted) instance of a visualisation. Vizjson 3 and (most notably) Named map generators had to be rewritten to be able to work with non-persisted visualisations (no calls to the db that would fetch actual persisted data should be performed, relying instead solely on the memory object). We could make the vizjson 2 generator compatible with Mapcaps but I don't know how attainable this is until I try. An alternative way to solve this: When we activate the builder, all new visualisations are made with the builder. Old ones still open in editor. There is a way to bring old visualisations to the builder (and ideally a copy is made instead of porting it over). This way we have the best of both worlds: we still push to go forward, but maintain maintain compatibility with old apps (unless the user decides to update). Moreover, I'd even take away the chance to deactivate the builder entirely. It would also be nice to have a visual element in the dashboard that makes it obvious which maps live in the editor. |
Closing this one due to the fact we have everything under control and ticketed :). |
Think about this usecase:
Should we ping the user about the fact the app could break?
cc @xavijam @juanignaciosl
The text was updated successfully, but these errors were encountered: