Selection of a shard based on server name or subdomain

[György Frivolt]

Hi,

I am not sure whether octopus will be the right solution for the
problem I am trying to tackle. Let me describe what I am addressing.

I have an application, which I would like to provide for more
clients. The clients would be distinguished based on the server name/
subdomain which they access. Let's say if one accesses
client1.foo.com, than a shard for the first client would be used by
the models, in case of client2.foo.com the shard for the second.

My current idea how to approach this is this:
1) I catch and store the actual request to the current thread:
Thread.current[:current_request] = request. This catching could be
done at different places.. middleware, application/action controller
or maybe by routing.. I did not decide yet which would be the best
2) When one tries to access a model, it behaves differently based
on the server name, the current request comes from, i.e. uses a
different shard for different server name in the request.
- When there is no http request (the model is accessed from
console,etc.) it will be necessary to think over, what to do, I did
not decide on the strategy yet here too.

There are things I would like to know about octopus.

- creating shards dynamically - the new applications for the
clients would be necessary to create dynamically. So I will need to
create the shards during the execution of the application... Probably
this means using something like https://github.com/tchandy/octopus/wiki/Dynamic-shard-configuration,
but not in the initializer but rather in a controller action. The
changes on shards would be necessary to be incremental. How to do this
with octopus?

- I am thinking that creating a multi-app based solution would
be initially realized on a single database (for relational db based
models), where the tables would have different prefix. Is it possible
to define a shard using a table prefix?

- Did anyone try octopus with Heroku? I am asking that, because
Heroku needs to be configured through its variables to access the Db,
database.yml is not considered by Heroku. And I don't know what
pitfalls could come on the way when I would try to deploy an app with
octopus on Heroku.

I am still not quite sure, whether octopus is the right tool for
the job. I like to way how octopus works and is implemented very much.
However, if you think I am trying to use it for an unintended purpose,
please refer me to another solution. Maybe I am trying to shot a
mosquito with a cannon, and the right solution is much simpler.

Thank you very much for the answer and any suggestions.

Best wishes,

George

[G. Sobrinho]

Hi George,

The first question is: why a one database for each client?

--
Cheers,

Gabriel Sobrinho

[Thiago Pradi]

Hi George,

I have the same question. I'm developing a application that has subdomain per user, and all we need is a scope on controller. Using Octopus on this context doesn't makes sense... It appears to me that you are inserting complexity when things could be simpler...

Obs: Yey! First message on Octopus mailing list :)

--
Att,

Thiago Pradi
Blog: http://blog.thiagopradi.net/
http://twitter.com/thiagopradi

[György Frivolt]

Hi Gabriel,

It is not necessary to have one Db for each client, the data set
could be selected by table prefix in the same database. The projects I
use were from the beginning developed for one client.
Other possibility would be to distinguish the data by adding a
column to every table, which would identify every client. Somewhat I
am not confident with that solution as this is not a generic one, and
I have a feeling tweaking the original code like that would be quite
laborious.

Thank you,

George

[György Frivolt]

Maybe you are right, I am still wondering whether I am adding or
taking complexity away. Still I dont want to force an octopus to do
anything it is not supposed to be for..

On Mar 14, 5:32 pm, Thiago Pradi <thiago.pr...@gmail.com> wrote:
> Hi George,
>
> I have the same question. I'm developing a application that has subdomain
> per user, and all we need is a scope on controller. Using Octopus on this
> context doesn't makes sense... It appears to me that you are inserting
> complexity when things could be simpler...
>
> Obs: Yey! First message on Octopus mailing list :)
>

> On Mon, Mar 14, 2011 at 1:21 PM, G. Sobrinho <gabriel.sobri...@gmail.com>wrote:
>
>
>
>
>
>
>
>
>
> > Hi George,
>
> > The first question is: why a one database for each client?
>

[Thiago Pradi]

hm, Octopus supports it, you could use a around_filter on controller, the code will be like this:

class ApplicationController < ActionController::Base
  around_filter :select_shard      

  def select_shard(&block)
    Octopus.using(request.subdomain.to_sym, &block)
  end    
end

This will select the client shard for every request, and load/write data on the current shard. 

I'm not so sure about creating new shards on-the-fly, maybe this won't work, I didn't tested this yet. Octopus supports changing the shards list using ruby code, but creating new databases means that you will need to create all tables... but, feel free to build your solution :-)

Thiago