search

CartoDB / CartoDB-basemaps

CartoDB basemaps
http://cartodb.com/basemaps
Other
55 stars 13 forks source link

2.1 release #70

Closed pnorman closed 8 years ago

pnorman commented 8 years ago

@zenitraM 2.1 involves a change to the z_order function, some views, and some other functions

The function change has to be done first, and we haven't really figured out mat view changes

To do a mat view change without downtime, we can create a new view + indexes with a different name, then in a transaction drop the old view and rename the new view.

Except for z_order being done first, none of the changes need to be synchronized with each other.

Thoughts on how to do this? We could just pull the servers one by one and do the views non-concurrently, test everything, then put it back into production

zenitraM commented 8 years ago

We could do it by renaming: create new ones named viewname_zXX_$GITSHA and then replace them with the old ones when done with a transaction as you suggest.

My bigger concern is synchronization with the styles: will old styles work with new matviews (and viceversa)?

pnorman commented 8 years ago

As I've defined versioning, a _.X upgrade can always be done without downtime or a reload.

In general I'd expect any _.X upgrade to be able to be done by loading global functions, rebuilding views, loading functions, and creating new named maps.

Adding features will generally be safe following this pattern, they just won't appear until all steps are done. Deleting features without changing columns is also safe, they'll disappear right away. Deleting columns would require reordering.

Both adding and deleting features is the only case which could be a problem, but then it becomes a major version bump if it's not possible.

pnorman commented 8 years ago

After testing, if you update a materialized view, any mat views which reference it also need to be updated even if there are no changes which make it to them, in order for them to reference the new table rather than the old one.

In this case it means updating highroad_z15plus to highroad_z12 because they have changes, then z11 and up because they reference the old tables even though the types of roads being changed are excluded from then, and then finally deleting all the old tables.