New Dropbox Datastore API in Python!
The Cloud Zone is brought to you in partnership with Mendix. Better understand the aPaaS landscape and how the right platform can accelerate your software delivery cadence and capacity with the Gartner 2015 Magic Quadrant for Enterprise Application Platform as a Service.
If you've been waiting to use some features from Dropbox via Python that go deeper than just storing and syncing files, today is your lucky day. Dropbox just released the beta version of the Python Datastore API SDK.
There's a wonderful tutorial already up by the good folks at Dropbox. The tutorial begins with a nice overview of all the amazing ways you can utilize Dropbox in your applications.
Here are the basic concepts that underlie the Datastore API:
- Client and datastore manager
- The client is your starting point. It lets your app start the authentication process to link with a user's Dropbox account. Once you've linked to an account, you use the client to create a datastore manager, which you can use to open datastores, get a list of datastores, wait for changes to multiple datastores, and so on.
- Datastores and tables
Datastores are containers for your app's data. Each datastore contains a set of tables, and each table is a collection of records. As you'd expect, the table allows you to query existing records or insert new ones.
A datastore is cached locally once it's opened, allowing for fast access and offline operation. Datastores are also the unit of transactions; changes to one datastore are committed independently from another datastore. After modifying a datastore, call the
commitmethod to send those changes to Dropbox. Call the
load_deltasmethod to receive new changes from Dropbox.
Records are how your app stores data. Each record consists of a set of fields, each with a name and a value. Values can be simple objects, like strings, integers, and booleans, or they can be lists of simple objects. A record has an ID and can have any number of fields.
Unlike in SQL, tables in datastores don't have a schema, so each record can have an arbitrary set of fields. While there's no requirement to have the same fields, it makes sense for all the records in a table to have roughly the same fields so you can query over them.