Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Related to Issue #200, slight code clean-up. #243
This is a trivial pull request, it (naturally) still passes all tests, but is intended to allow me to more easily extend the SlugGenerator class, and borrow the behaviour which helps me writing my own implementation (
I'm planning to take the short route, to implementing my own Redis backed option, and would like to see this come upstream so that I might determine the best places to hook/override behaviour.
added a commit
this pull request
Feb 27, 2012
Pulled. A few things to keep in mind:
So if you set up your own Redis sequencer, as a separate library right now, my changes in 4.1 will very likely break it, though it's also very likely that I'll expose a public API that would allow you to implement your own sequencing strategy (using for example, Redis, Hadoop, or a cluster of Cray supercomputers), and that would then be a stable API that you could count on me not breaking.
Thanks! Great response time.
Absolutely acknowledged, I have a special case here, that the table has tens of millions of records, and the read locks kill me. Also when you have a Redis hammer, everything looks like a nail, that really ought to stay my problem, and no go upstream!
I hadn't thought about that, something I need to amend my case to check for, that is
No problem for me, I won't release my stuff publicly right now, I have enough open source that requires maintenance, and regarding 4.1, that's the contract we all opt-into when using semver, or similar.
It might be worth pointing out that the name
Cool, that's at least an interesting problem to have. :) Also an even better argument for making a real API for this so that people with special needs like you have a reasonably straightforward way to implement special-case solutions.
Still, there's no excuse for FriendlyId not being able to handle this without concurrency problems out of the box, even if it's slow. You should only have to optimize for performance in your case, not for correctness.
Totally agree, it should be changed.
You're right - but I still think that for /most people/ who're using
I'm quite happy with my redis implementation now, I haven't tried it in action yet - but unless I'm mistaken I've tested all but the timeout cases, testing timeouts is something I don't really want to bite off right now, and that's more for covering my ass. If you are curious (and I would genuinely appreciate your insight, if you have a moment to read through) - Including tests all inline at https://gist.github.com/c014dfcc24f80f803621, and the blog post I wrote detailing my thought process http://lee.hambley.name/2012/2/27/friendly_id-and-parallel-processes/