[SERVER-29354] add ability to atomically replace view definition Created: 24/May/17  Updated: 27/Oct/23  Resolved: 25/May/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Asya Kamsky Assignee: Backlog - Query Team (Inactive)
Resolution: Works as Designed Votes: 0
Labels: read-only-views
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates DOCS-9446 Document which commands work (or don'... Closed
Related
related to SERVER-22541 Aggregation plan executors should be ... Closed
Assigned Teams:
Query
Backwards Compatibility: Fully Compatible
Participants:

 Description   

New description:
Allow existing queries to continue running when view definition is updated via "collMod" command.

Old description:
There's a common pattern used in reporting where all applications point to collection1 and meanwhile a new version called collection2 is being populated. When it's done, DBAs want to atomically "replace" collection1 with collection2.

This can be done with views, but since we don't support updating view definitions or creating views while dropping existing view definition, they would have to drop view and then re-create view which is not transparent to the applications.

This ticket is to track adding an option to createView to drop/overwrite existing view definition.



 Comments   
Comment by Asya Kamsky [ 25/May/17 ]

Resolving as I don't believe there is engineering work left to do, and remaining work should be handled by DOCS-9446

Comment by Asya Kamsky [ 25/May/17 ]

We discovered via some testing that in 3.4 while it's possible to replace the definition of a view, it kills all currently running operations on it (i.e. invalidates the cursor queries are iterating over).

However, due to work done to fix SERVER-22541 in master the same thing does not happen and existing cursors can continue fetching more batches of data while the view is successfully repointed to a new collection or view via collMod.

I believe this resolves this ticket, but it should possibly be documented that there's a change in behavior between 3.4 and 3.6.

Comment by Asya Kamsky [ 25/May/17 ]

Re-opening.

Comment by Asya Kamsky [ 25/May/17 ]

I'm closing this as basically dup of DOCS-9446 since the functionality already exists.

Comment by Asya Kamsky [ 25/May/17 ]

The use case is specifically to re-point a "logical" collection to a different physical collection. I don't think it's intended to do so "destructively" (i.e. renaming collection2 to collection would lose previous version/view of the collection). This is more analogous to there being a view called "yesterday" and it's pointing at a different collection after midnight than before, but physical collections don't change.

If what Charlie listed is a feature that's meant to work then we just need to document it and then close this ticket.

Comment by Charlie Swanson [ 25/May/17 ]

Isn't this what collMod does?

> db.foo.find()
{ "_id" : 0, "date" : ISODate("2017-05-23T17:37:06.897Z"), "a" : 3 }
{ "_id" : 1, "date" : ISODate("2017-05-23T16:12:05.916Z"), "a" : 3 }
> db.createView("view", "foo", [])
{ "ok" : 1 }
> db.view.find()
{ "_id" : 0, "date" : ISODate("2017-05-23T17:37:06.897Z"), "a" : 3 }
{ "_id" : 1, "date" : ISODate("2017-05-23T16:12:05.916Z"), "a" : 3 }
> db.bar.find()
> db.runCommand({collMod: "view", viewOn: "bar"})
{ "ok" : 1 }
> db.view.find()

Comment by Andy Schwerin [ 24/May/17 ]

Sharding may make this tricky. If renameCollection in sharding worked atomically, would there be any point to doing this with views?

Generated at Thu Feb 08 04:20:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.