<div dir="ltr">We use this with great success at $work<br><br><a href="https://rubygems.org/gems/apartment">https://rubygems.org/gems/apartment</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 9:32 AM, Riccardo Tacconi <span dir="ltr"><<a href="mailto:rtacconi@gmail.com" target="_blank">rtacconi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>You should keep your target customers, in enterprise apps you have to have a different database per account and even separated queues (like RabbitMQ queues) too.</div><div><br></div><div>If your app is not too serious, as you say, may be you could have a layer where every query has to pass an account_id in order to retrieve data.</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 25 February 2016 at 09:24, Michael Pavling <span dir="ltr"><<a href="mailto:pavling@gmail.com" target="_blank">pavling@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hiya,<br>
<br>
I'm looking at the ways I can have multiple users share an app, but<br>
keep all their data separate.<br>
<br>
Now, I suppose the first way is to just make sure all queries are<br>
scoped to the user (and keep fingers crossed that no future me ever<br>
writes an unscoped `Order.all`). But there's *got* to be a range of<br>
good ways.<br>
<br>
Looking at multi-tenanting gems, they seem to either take the approach<br>
of scoping for you, or creating separate DBs/schemas for each tenant.<br>
Does anyone have any opinion on the pros and cons of the different<br>
approaches, or indeed, the specific gems?<br>
<br>
I'm leaning toward the "scope for me" approach, because it seems<br>
simplest to grok - and the app isn't *that* serious (although thinking<br>
about it... there is risk of personally identifying data being stored,<br>
so I probably should prioritise a secure approach).<br>
<br>
Michael<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">Riccardo Tacconi<br><br><a href="http://github.com/rtacconi" target="_blank">http://github.com/rtacconi</a><br><a href="http://twitter.com/rtacconi" target="_blank">http://twitter.com/rtacconi</a></div></div>
</font></span></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>