[LRUG] Scoping sequences to a parent

[Cam Allen]

>
> Redis certainly sounds good here.  I'm a little surprised that there
> doesn't seem to be a standard pattern for doing this in the database
> because it doesn't seem like such an unusual use case.


I'd recommend Redis as well or any datastore with atomic updates that can
deal with the parent counter for you.


On 2 September 2016 at 11:38, Andrew Stewart <boss at airbladesoftware.com>
wrote:

> > For this type of thing I really love Redis. You can create a counter per
> parent and atomically increment without worrying about concurrency. It's
> also blazingly fast, so you don't have to worry about bulk imports and
> performance problems, and unlike memcached you can add persistence so
> you'll never lose your counters.
> >
> > Chances are you are already using in your system, maybe for caching,
> maybe as a dependency for sidekiq, or as the actioncable backend, so you
> might not even need to install a new component. And if you have to install
> it, Redis is very clean to install, easy to monitor, and very robust.
> >
> > You would still use the callback as you are doing now, but you would
> increment without having to read first. A side effect you might get is
> having gaps in the sequence if a model increases the counter and then rolls
> back the transaction. If that's not a problem for you, then I'd strongly
> recommend to go with Redis.
>
> Redis certainly sounds good here.  I'm a little surprised that there
> doesn't seem to be a standard pattern for doing this in the database
> because it doesn't seem like such an unusual use case.
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20160902/974cf1ac/attachment-0002.html>