A Problem in Designing Binary Properties in stork-odm
I wrote a little application in node with couchdb behind the curtain. I enjoyed the exercise and used nano by Nuno Job. That’s like building a Web application with the ASP.NET pipeline and ADO.NET: a really good exercise to understand the technologies in detail but I wouldn’t want to do it again.
Now, I want to rebuild it bigger and better. And, I need a better way to persist my objects’ states.
The beginning of stork-odm
I started off with the flatiron “adaptable framework for building modern Web applications.” However, the two years since my series of articles on flatiron doesn’t really seem to have made better that specific tool bag.
I found that of the stuff in flatiron, I really had a lot of respect for resourceful, their “engine agnostic interface to JSON document stores.” Unfortunately, the architecture of my application relied on a multitenant database infrastructure, something couchdb does fantastically.
I went poking around the code and found a glaring singleton just sitting there mocking me. One database “connection” in resourceful. So, I went to log an issue to ask them about changing that and found their own issue Remove global state #149. At the time, the issue had an age seven months and commits appeared few and far between. I could fix it for them; however, I only wanted the couchdb target, didn’t want to have to read all of their code, and really didn’t think I’d have the wherewithal to accomplish that reëngineering feat.
So, as all good developers would do…
… I wrote my own object-document mapper. While Bryan didn’t have any direct commits into the code, he did influence it heavily in the design through our conversations. Thanks, Bryan Ray! (And, watch for his involvement in Blog-a-Day May!)
It still uses nano under the covers, but organizes things better. A document in couchdb merely represents the state of an object (or its references) at a moment in time.
Getting rid of the pain
Instead of writing a couchdb design document similar to the following and
saving it in source as a separate file and curl
-ing it into the database for
a deploy…
1 | { |
… and having to get the results with something like…
1 | var nano = require('nano')('http://localhost:5984/test_database'); |
… I can be object-y.
Using stork, instead
Now, in my project, I declare an entity like this:
1 | var stork, Org; |
And, I deploy it like this:
1 | Org.to(couchdbUrl).sync(function (err) { |
And I use it like this:
1 | Org.from(couchdbUrl).byUri(function (err, orgs) { |
Now, the problem: binary properties
In couchdb, we store binary stuff as attachments to documents, normally. When I declare a property in stork as binary, how do I attach it? How do I delete it? How do I provie a MIME type?
Right now, I have a crappy implementation. It goes something like this:
1 | var stork, Org, redcross, fs; |
But, that doesn’t specify the MIME type of the binary data. So, it will also accept this:
1 | var stork, Org, redcross, fs; |
which will associate the MIME.
But, I don’t like it. It looks and feels clunky.