Pull all db (mongo) functions into another file to enable easier replacement

[dmitchell]

Builds on the other PR for using computed ObjectId

@cpennington @singingwolfboy please review or delegate

[looks like I need to rebase]

[dmitchell]

The only test failure was a flakey acceptance test.

[dmitchell]

As to the abstraction, I think this may be a reasonable first step. Other options are

• instead of passing dicts to the CRUD functions, create 3 models: index, structure, definition which are lightweight data transfer objects that support only .update .insert .delete methods. However, there's no simple equivalent for get.
• instead of get_foo, get_bar, ... methods, have a get(type, id) and get(type, query) methods. etc for update, delete,.... The downside to this is that there should be no callers to update on definitions (update_structure is purely for the i-know-what-i'm-doing-single-version-transaction interface)

[singingwolfboy]

Seems reasonable to me. 👍

[sarina]

@dmitchell - what's the status of this PR?

[dmitchell]

Ask Cale. He stated that he objects but no actionable reason

On Nov 18, 2013, at 9:27 AM, Sarina Canelake notifications@github.com wrote:

@dmitchell - what's the status of this PR?

—
Reply to this email directly or view it on GitHub.

[sarina]

@cpennington ?

[cpennington]

+1. Ultimately, I think this is the wrong level to be abstracting at, but
until we have the stuff needed to so it the right way, this at least
consolidates the places we depend on a specific db.
On Nov 18, 2013 9:42 AM, "Sarina Canelake" notifications@github.com wrote:

@cpennington https://github.com/cpennington ?

—
Reply to this email directly or view it on GitHubhttps://github.com/edx/edx-platform/pull/1333#issuecomment-28702604
.

[dmitchell]

Rebased. I agree w/ @cpennington that the abstraction is not quite right. I intended this purely as a quick and dirty first step toward separation but the real abstraction would require trying to implement another db connector.