Transforming data before storage

[Pelle Braendgaard]

Congrats on the release Jon,
I have a very simple application I want to write using CloudKit. It
would be perfect in many different ways. There are just 3 things I'm
trying to get my head around.

In my app resources posted will be in a specially encoded format (x509).

I suppose a simple way of doing it would be to create a middleware
filter that transforms from that to json. This sounds easy enough.

However the 2nd issue is that some resources will also have other
resources embedded within them that I want to create on the fly.
Basically one post might create resources in 2 different collections.
Again I guess I could intercept posts to that collection and then
manually create the resources.

Thirdly each resource has a natural key I want to be its UUID. I see
that Resource allows you to pass an :id or :pk option in it's
initializer, but this seems to mainly used internally when
instantiating from the underlying store. The Resource.create method
which is what is called via a POST doesn't seem to have anyway of
manually setting this.

Now another approach would be to have some way of subclass of Resource
in the style of AR like models. I can see a number of different ways
where this could be implemented, allowing solving the above problems
using method overrides and/or before/after filters. I'm not sure if
that would be against the philosophy of cloudkit? I would be willing
to take a go at it.

P

--
http://agree2.com - Reach Agreement!
http://extraeagle.com - Solutions for the electronic Extra Legal world
http://stakeventures.com - Bootstrapping blog

[Jon Crosby]

On Mon, Mar 9, 2009 at 12:45 PM, Pelle Braendgaard <pel...@gmail.com> wrote:

Congrats on the release Jon,

Thanks, Pelle!

 

I have a very simple application I want to write using CloudKit. It
would be perfect in many different ways. There are just 3 things I'm
trying to get my head around.

In my app resources posted will be in a specially encoded format (x509).

I suppose a simple way of doing it would be to create a middleware
filter that transforms from that to json. This sounds easy enough.

A content type transformation middleware sounds like the right way to go.

 

However the 2nd issue is that some resources will also have other
resources embedded within them that I want to create on the fly.
Basically one post might create resources in 2 different collections.
Again I guess I could intercept posts to that collection and then
manually create the resources.

This could definitely be done as middleware too. I'll illustrate why below.

Thirdly each resource has a natural key I want to be its UUID. I see
that Resource allows you to pass an :id or :pk option in it's
initializer, but this seems to mainly used internally when
instantiating from the underlying store. The Resource.create method
which is what is called via a POST doesn't seem to have anyway of
manually setting this.

CloudKit does use an internal id property (mapped to :pk in Tokyo Cabinet), but it treats it more as behind-the-scenes book keeping, leaving the URI as the real key for the resource. You might benefit from using the second form of PUT in HTTP, where you can define where you want your resource to live. CloudKit supports this usage, but beware that you will need to make sure your URIs are unique. Here is an example in curl assuming you have a collection of books:

> curl -XPUT -d'{"title":"JavaScript: The Good Parts"}' http://localhost:9292/books/javascript-the-good-parts

 

Now another approach would be to have some way of subclass of Resource
in the style of AR like models. I can see a number of different ways
where this could be implemented, allowing solving the above problems
using method overrides and/or before/after filters. I'm not sure if
that would be against the philosophy of cloudkit? I would be willing
to take a go at it.

The approach you mention here is solid and would work without a doubt. However, if PUT solves the natural key issue, then I would recommend going with middleware for the dual POST (or PUT) problem. The reasoning for this is that an HTTP cache will know nothing about the other resources created behind the scenes. This isn't a show stopper by any means; it happens all of the time in web applications. However, if you do the dual split in middleware, you still have a chance to place a cache between your splitter middleware and CloudKit that *does* know about the secondary resources.

Either way you choose, I would love to hear about how it works, answering other questions you may have along the way.

-Jon