I've an application within the works best for use internally like a project/task tracker in the organization that I am employed by. Experimenting with MongoDB atm. I've the next pseudo-schema in your mind:

task
    _id
    name
    project
    initial_notes
    versions
        number
        versions
            version_1
                worker
                status
                date(if submitted)
                review_notes(if rejected)
                reply_on(if accepted/rejected)
            (version_n)(if any)

The issue that I am getting is by using versioning the job. I have read numerous good ways but I am falling lacking understanding them completely through. I just read something which I loved here and extremely such as the way mongoid does it's versioning

Considering it better I'd favour it something similar to this

task
    _id
    versions
        number_of_versions: 3
        current_version
            version_no: 3
            worker: bob
            status: accepted
        old_versions
            version
                version_no: 2
                worker: bob

I must show the newest version only if exhibiting an accumulation of tasks and I must show all versions of the particular task when entering the more information page for your particular task. Would this structure work? If so, an amount be some queries required to run to be able to achieve things i need?

Thanks ahead of time for the time reading through this and perhaps responding to it. status: declined version version_no: 1 worker: cruz status: declined

Yes, why don't you. That plan works. Also, have you thought about something similar to this:

task 
    ...
    versions = [       # MongoDB array 
        {   version_id 
            worker
            status
            date(if submitted)
            review_notes(if rejected)
            reply_on(if accepted/rejected)
        },
        { version_id : ... }, 
        ... 

Possible version insertion query:

tasks.update( { # a query to locate a particular task}, 
              { '$push' : { 'versions', { # new version } } } )

Note, that locating the final version in the versions array within this situation is performed through the program, not by Mongo.

You could also think about a model such as this:

task
    _id
    ...
    old_versions [
        {
            retired_on
            retired_by
            ...
        }
    ]

It has the benefit that the current information is always at the very top level (you don't have to track the present version clearly, the document is its very own current version), and you will easily track history if you take the present version, getting rid of the old_versions area, and $pushing it towards the old_versions area within the db.

Because you appeared to wish to reduce network IO, this allows you easily avoid loading the old_versions when you do not need them:

> db.tasks.find({...}, {old_versions: 0})

You might get more inticate and store a listing of old versions only of fields which have transformed. This involves more delicate code inside your application layer, and might not be necessary if you do not expect many revisions or these documents to be really large.