Core Server
  1. Core Server
  2. SERVER-142

Read-only views over collection data.

    Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Major - P3 Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: planned but not scheduled
    • Component/s: Usability
    • Labels:
      None
    • # Replies:
      23
    • Last comment by Customer:
      true

      Description

      Support for read-only views will consist of providing a mechanism for binding a namespace name to a (namespace name, query) pair, where the query might be a MongoDB query or an aggregation expression. For example, if you had a collection "housing.apartments", you might create a view housing.cheapApartments = (housing.apartments, { rent:

      { $lte: 1000 }

      }). Finds on cheapApartments would only consider those elements of housing.apartments where the "rent" field was less than 1000.

      By using an aggregation expression with an unwind stage, you could produce a view over a database that had one document for every member of an array in an input document, providing another means to examine and query embedded documents.

        Issue Links

          Activity

          Hide
          Gregg Carrier
          added a comment -

          I could really use this feature in almost every project I build with Mongo. Without it, "schema" designs start to get pretty relational and a lot of the benefits of a document database tend to be lost. Would love to see this as soon as possible.

          Show
          Gregg Carrier
          added a comment - I could really use this feature in almost every project I build with Mongo. Without it, "schema" designs start to get pretty relational and a lot of the benefits of a document database tend to be lost. Would love to see this as soon as possible.
          Hide
          Colin Mollenhour
          added a comment - - edited

          10gen folks, is it safe to say this feature is basically being superseded by the new aggregation framework (SERVER-447)? It seems using $project and $unwind will give the same results being asked for here only differently and with far more flexibility. If that is the case perhaps this ticket should just be closed.

          Before anyone gets upset, I am strongly in favor of the idea of virtual collections and would use them heavily in my own projects. I am just seeing that the aggregation framework appears to be well underway (2.1.0, yay!) and provides functionality that overlaps the "virtual collection" concept and so much more. That is, pursuing this ticket would really be a waste of time.. Given the number of votes though it would be nice for everyone to know your intentions.

          Using the example in the description of the ticket, it seems a wrapper around the aggregation framework could be written that looks like this:

          // equivalent to:
          // db.foo.$bar.find(query);
          virtualFind("foo","bar",query);
          
          function virtualFind(coll, field, query){
            var project = {_id:1};
            project[field] = 1;
            return db.runCommand({ aggregate : coll, pipeline : [
              { $match : query },
              { $project : project },
              { $unwind : "$"+field },
              { $match : query }
            ]});
          }
          // returns 
          [
            { _id: <parent ObjectId>,
              bar: <subdocument>
            },{ _id: <parent ObjectId>,
              bar: <subdocument>
            }
          ]
          

          This example makes it pretty obvious that the aggregation framework is very flexible and can be bent to fit everyone's needs (parent document fields, filtering, sorting, etc).

          Show
          Colin Mollenhour
          added a comment - - edited 10gen folks, is it safe to say this feature is basically being superseded by the new aggregation framework ( SERVER-447 )? It seems using $project and $unwind will give the same results being asked for here only differently and with far more flexibility. If that is the case perhaps this ticket should just be closed. Before anyone gets upset, I am strongly in favor of the idea of virtual collections and would use them heavily in my own projects. I am just seeing that the aggregation framework appears to be well underway (2.1.0, yay!) and provides functionality that overlaps the "virtual collection" concept and so much more. That is, pursuing this ticket would really be a waste of time.. Given the number of votes though it would be nice for everyone to know your intentions. Using the example in the description of the ticket, it seems a wrapper around the aggregation framework could be written that looks like this: // equivalent to: // db.foo.$bar.find(query); virtualFind("foo","bar",query); function virtualFind(coll, field, query){ var project = {_id:1}; project[field] = 1; return db.runCommand({ aggregate : coll, pipeline : [ { $match : query }, { $project : project }, { $unwind : "$"+field }, { $match : query } ]}); } // returns [ { _id: <parent ObjectId>, bar: <subdocument> },{ _id: <parent ObjectId>, bar: <subdocument> } ] This example makes it pretty obvious that the aggregation framework is very flexible and can be bent to fit everyone's needs (parent document fields, filtering, sorting, etc).
          Hide
          Eliot Horowitz
          added a comment -

          I don't think the aggregation framework means this feature won't get done as well.
          Different use cases in my mind.

          Show
          Eliot Horowitz
          added a comment - I don't think the aggregation framework means this feature won't get done as well. Different use cases in my mind.
          Hide
          Harry Mexxian
          added a comment - - edited

          +1

          Would be nice not to have to worry about embedded docs getting too large, and having to move them back out to a traditional relational schema.

          Would it be possible to also have the virtual indices for the virtual collections? So as to not fallback to O when seeking for a specific sub-doc.

          Maybe in 2.3? It does have over 200 votes!

          Show
          Harry Mexxian
          added a comment - - edited +1 Would be nice not to have to worry about embedded docs getting too large, and having to move them back out to a traditional relational schema. Would it be possible to also have the virtual indices for the virtual collections? So as to not fallback to O when seeking for a specific sub-doc. Maybe in 2.3? It does have over 200 votes!
          Hide
          rakesh patil
          added a comment -

          This is my structure

          {
          _id: "akdjfka",
          name : "kjahkfaj",
          test : [{
          subject: "maths",
          score: "80"
          comments: [

          {name: "kerry", comment : "good score"}

          ,

          {name: "paul", comment: "keep it up"}

          ],
          }
          {
          subject : "science",
          score : "96"
          comments:[

          {name:"jerry", comment: "awesome "}

          ,

          {name:"pinto", comment: "how do u manage to do that ? "}

          ]
          }

          }

          I have a different table for each one in mysql but in mongo db i was able to create this sort of architecture and i was not able to filter out only the comment by "kerry"
          like may be for example

          db.scores.find({_id:"akdjfka",subject:"maths",test.comments.name: "paul"})
          i should be able to get

          {name: "paul", comment: "keep it up"}

          with this feature I will certainly change my database with mongo..

          if this is already possible please let me know..

          Show
          rakesh patil
          added a comment - This is my structure { _id: "akdjfka", name : "kjahkfaj", test : [{ subject: "maths", score: "80" comments: [ {name: "kerry", comment : "good score"} , {name: "paul", comment: "keep it up"} ], } { subject : "science", score : "96" comments:[ {name:"jerry", comment: "awesome "} , {name:"pinto", comment: "how do u manage to do that ? "} ] } } I have a different table for each one in mysql but in mongo db i was able to create this sort of architecture and i was not able to filter out only the comment by "kerry" like may be for example db.scores.find({_id:"akdjfka",subject:"maths",test.comments.name: "paul"}) i should be able to get {name: "paul", comment: "keep it up"} with this feature I will certainly change my database with mongo.. if this is already possible please let me know..

            People

            • Votes:
              307 Vote for this issue
              Watchers:
              189 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since reply:
                50 weeks, 1 day ago
                Date of 1st Reply: