Ripple model bucket namespaces

[lusis]

I was revisiting the Ripple gem with the latest beta. One thing I noticed is that Ripple isn't really multi-environment friendly. Is the intention that you'll use different Riak instances per environment?

Would it be "better" create the model namespace prepending/append the environment to each model bucket or am I missing an easy way in model definition to do that?

[lusis]

On the last part, I found in the specs how to modify the per-model bucket but I'm still curious about the first part (prepend/append environment) as the default namespace.

[lusis]

I also realized tonight after working on padrino support that the current namespace design limits you to one app per riak instance if two apps happen to share the same model names and talk to the same riak instance. It appeared, but requires a little more testing on my side, that setting the bucket name with Riak::Client doesn't push that down to the model in anyway.

Maybe it should be that if a bucket is set on Riak::Client, that value is prepended/appened to the model name to create the namespace?

[seancribbs]

I don't see any reason why we can't modify the bucket name to use the whole namespace path. i.e. Admin::User -> admin/users

[lusis]

Does this still address the issue of differing applications/environments using the same riak server?

use case 1: rails/sinatra/padrino specific environments (development, test, production, arbitrary_name) talking to the same riak server (only likely in my local environment but possible) use case 2: ruby application 1 has model Users, ruby application 2 has model Users both talking to the same riak server (more likely)

[seancribbs]

What do you suggest? This problem isn't any different than ActiveRecord's issue with multiple apps using the same model name/table.

[lusis]

I guess I'm taking the principal of least surprises. In a traditional orm+rdbms model, your namespace is the database name and you can run them all on the same database host.

With ActiveRecord and MySQL obviously the same model/table isn't an issue because I've constrained it to a database usually named _(dev|test|prod).

With the current ripple namespace model, I could inadvertently have two distinct applications I'm working on locally stepping all over each other's buckets if they happen to share some common models (User, Account, Post..whatnot).

I'm not expecting Ripple to take into account the framework environment it's running under. That's the framework adapter's job. Ripple doesn't care about RAILS_ENV/PADRINO_ENV and shouldn't.

dm-riak-adapter takes an optional namespace and uses that in Riak::Client creation otherwise it operates essentially the same as Ripple does.

I think a nice backwards compatible compromise would be for Ripple models to honor Riak::Client bucket settings and make them part of the namespace path, otherwise use the current top level method.

I can handle having padrino extend that namespace based on environment.

[seancribbs]

The need for "multi-tenancy" is known to the Riak developers, but nothing specific has been planned. In the meantime, here's some ways we can reduce the surprise:

1) Have an option of a global namespace on Ripple::Document, set at application startup time 2) Derive namespace from Module nesting 3) Strongly caveat that multiple apps using the same cluster should be careful of clobbering each other's data

[lusis]

"multi-tenancy" - I knew there was a phrase for it. Couldn't remember it off-hand.

That plan works for me. Thanks much. I'm still going to continue down the current path of self.bucket_name to finish out basic support. Changing to the new model won't be a big deal from there.

[seancribbs]

Of the first two options, which one seems most useful?

[lusis]

1 is probably the most flexible. Said global namespace is user defined, correct?

Right now I've set self.bucket_name for the models to be padrino_env+padrino_appname+model name separated by underscores. I wasn't sure how slashes would be handled and didn't want to go through the url encoding at this point.

[adamhunter]

As the best method for separating your environments is pointing them at different Riak clusters (and using the test server for a test cluster) I am going to close this issue.